From fcorella@pomcor.com Mon Jan 3 08:19:18 2011 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 0971C3A6A31 for ; Mon, 3 Jan 2011 08:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=1.277, 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 qP9dNICWreVP for ; Mon, 3 Jan 2011 08:19:16 -0800 (PST) Received: from nm25-vm0.bullet.mail.ac4.yahoo.com (nm25-vm0.bullet.mail.ac4.yahoo.com [98.139.52.240]) by core3.amsl.com (Postfix) with SMTP id 944413A6A30 for ; Mon, 3 Jan 2011 08:19:13 -0800 (PST) Received: from [98.139.52.194] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 03 Jan 2011 16:21:17 -0000 Received: from [98.139.52.143] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 03 Jan 2011 16:21:17 -0000 Received: from [127.0.0.1] by omp1026.mail.ac4.yahoo.com with NNFMP; 03 Jan 2011 16:21:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 780716.86516.bm@omp1026.mail.ac4.yahoo.com Received: (qmail 68645 invoked by uid 60001); 3 Jan 2011 16:21:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294071677; bh=EU1Eywf4iGgfZ7jilTUi0dZtq436GnCV71bEx4wjR4E=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=PWmYVeuAvC0wh35WHdfyYlhWluRTBAn13aiidl+JY9yJ6qzUx36/6d3WByvmape0F0mTGGP58IfLRyOAZcCb1nrqInuZ3v2npr4LcEl1EIdhsyqVY2cWbUjHda+nlcx5nfgUBJt5CU4GR3OwbPHjz2zLtdlKTGTpMVkDj44iFPY= Message-ID: <558643.63263.qm@web55802.mail.re3.yahoo.com> X-YMail-OSG: C8tweUoVM1l_dDictarnPU7ctyjx51Nw_cwjJ6hb8Cr_qHz LKCHDFSgH Received: from [174.65.103.16] by web55802.mail.re3.yahoo.com via HTTP; Mon, 03 Jan 2011 08:21:17 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Mon, 3 Jan 2011 08:21:17 -0800 (PST) From: Francisco Corella To: Marius Scurtescu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-132362450-1294071677=:63263" Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jan 2011 16:19:18 -0000 --0-132362450-1294071677=:63263 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Wed, 12/29/10, Marius Scurtescu wrote: ... > I don't think it adds much complexity. And for implementors it is a > big help, much simpler to implement /.well-known/host-meta. Imagine > asking a large website to add a few HTML tags to every single request > to / as opposed to adding a special file. OK, but there is another problem: /.well-known/host-meta will usually be an http URI, and I need an https URI. On the other hand, I can use a well-known URI such as=20 /.well-known/pkauth.=A0 That's what I'm saying now in a=20 new revision of the paper. ... > > First, in OAuth the client is also a Web application, isn't > >=0A it?=A0 What else could it be? > > A native app, a JavaScript widget, a device. > https://datatracker.ietf.org/doc/draft-zeltsan-use-cases-oauth/ Ah, OK.=A0 I can see why those use cases are important, so I've been working to accommodate them over the last few days. The result is very nice :-).=A0 I can handle those clients without=20 profiling.=A0 That is, the PKAuth server does not need to know=20 whether it is talking to a traditional Web application, a native app,=20 a browser-resident application such as a Javascript widget, or an "autonomous client".=A0 I've incorporated this into the=20 new revision. > > exchange provides no security.=A0 In PKAuth there is only one > > token, which is sent to the direct callback endpoint and > > does not run the risk of falling into the wrong hands.=A0 I've > > added this argument to the paper. > > I=0A think you still have two tokens, the reference code (similar to the > authorization code in OAuth 2) and an authorization token (access / > refresh token in OAuth 2). You were right about this, but now, as a result of the changes I had to make to accommodate different kinds of clients, there is only one token. Francisco --0-132362450-1294071677=:63263 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
--- On Wed, 12/29/10, Marius Scurtescu <msc= urtescu@google.com> wrote:
...
> I don't think it adds = much complexity. And for implementors it is a
> big help, much simple= r to implement /.well-known/host-meta. Imagine
> asking a large websi= te to add a few HTML tags to every single request
> to / as opposed t= o adding a special file.

OK, but there is another problem: /.well-kn= own/host-meta
will usually be an http URI, and I need an https URI.
O= n the other hand, I can use a well-known URI such as
/.well-known/pkauth.  That's wha= t I'm saying now in a
new revision of the paper.
...
> > First, in OAuth the client is also a Web application, is= n't
> >=0A it?  What else could it be?
>
> A nati= ve app, a JavaScript widget, a device.

> https://datatracker.ietf= .org/doc/draft-zeltsan-use-cases-oauth/

Ah, OK.  I can see why = those use cases are important, so
I've been working to accommodate them = over the last few days.
The result is very nice :-).  I can handle = those clients without
profiling.  That is, the PKAuth server does = not need to know
whether it is talking to a traditional Web application= , a native app,
a browser-resident application such as a Javascript wid= get, or
an "autonomous client".  I've incorporated this into the new revision.

> > exchange provides no security.  In PK= Auth there is only one
> > token, which is sent to the direct call= back endpoint and
> > does not run the risk of falling into the wr= ong hands.  I've
> > added this argument to the paper.
>= ;
> I=0A think you still have two tokens, the reference code (similar= to the
> authorization code in OAuth 2) and an authorization token (= access /
> refresh token in OAuth 2).

You were right about thi= s, but now, as a result of the
changes I had to make to accommodate diff= erent kinds of
clients, there is only one token.

Francisco
--0-132362450-1294071677=:63263-- From fcorella@pomcor.com Mon Jan 3 22:09:03 2011 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 536333A6B27 for ; Mon, 3 Jan 2011 22:09:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.639, 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 QL5+DII+PK3F for ; Mon, 3 Jan 2011 22:09:01 -0800 (PST) Received: from nm23.bullet.mail.ac4.yahoo.com (nm23.bullet.mail.ac4.yahoo.com [98.139.52.220]) by core3.amsl.com (Postfix) with SMTP id 3A7E93A67A5 for ; Mon, 3 Jan 2011 22:09:00 -0800 (PST) Received: from [98.139.52.195] by nm23.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 06:11:05 -0000 Received: from [98.139.52.182] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 06:11:05 -0000 Received: from [127.0.0.1] by omp1065.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 06:11:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 325825.77736.bm@omp1065.mail.ac4.yahoo.com Received: (qmail 13249 invoked by uid 60001); 4 Jan 2011 06:11:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294121465; bh=xXqLVJxg3va+cMv0TnQiur4kA7emWvuReylODCLHtWw=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=ktMajzaYkCTjXW/X5TEuGEto2UPx0OoqHmbvytJGAUdQFR01pfz6OhK0AwVoXzqzZ/xGxfB6v1U+iIr/sLHV4awjvE6kE+0LQBkd3wHK4BoocKfhuQw1QC68I/qbRRCe55WrSno28xzCuJ5TpRXkKP8fycsR+jqdMjkZ6Lmhsyo= Message-ID: <210422.10811.qm@web55804.mail.re3.yahoo.com> X-YMail-OSG: WzZEPlQVM1m2ss9Gk0rj4vfxq6STmThiKx2RBQd0Rm.LFlq Wh8IjsQ84jBn4jCKwBsAt0Hk3Hmo_tRMcVGedmwZLDtFXfyvZgOtFB7DdSH_ B7p9K.5PsLVIDQumAfV349X24Qx9gGrTfVny2UT0V_Ixre_7pbxX9GZryjF2 B5AJicGsLi2rqsf.ptyaUPXjjN3ElgtN_vd59y1626Y9rvf7BEKiINDMK_2r zv5f5e52cRBIKpKiufCakKTHSVu06KtV4ObRotWBJExXgB4iGfaDtM5fyZBh xidGZ8_kwH4v4rSOyreIcmxi3LsXA8IHBrbQJUc932mYrhhbUi30DrLapTjC VpOpip7YVQfI4FTHnlK4pLg0XPouoZQ4gCsrwpoLWTPrxBm_kb.Ko6uWjjRG RPTGRO2.n7.Sx3Uuj Received: from [174.65.103.16] by web55804.mail.re3.yahoo.com via HTTP; Mon, 03 Jan 2011 22:11:05 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Mon, 3 Jan 2011 22:11:05 -0800 (PST) From: Francisco Corella To: oauth@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-808382139-1294121465=:10811" Cc: "Karen P. Lewison" Subject: [OAUTH-WG] TLS is needed for redirecting back to the client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 06:09:03 -0000 --0-808382139-1294121465=:10811 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, The OAuth spec recommends the use of TLS when sending requests to the end-user authorization endpoint and requires it when sending requests to the token endpoint.=A0 It says nothing about using TLS when redirecting the browser back to the client, which implies that it is not needed for that purpose. In fact, TLS is needed just as much when redirecting back to the client as when sending requests to the token endpoint. If TLS is not used when redirecting back, the following attack, which is easy to implement, allows the attacker to impersonate a resource owner and gain access to protected resources. The resource owner goes to an airport or a coffee house with a laptop.=A0 The attacker is sitting at the airport or coffee house with a loptop that implements a rogue Wifi access point.=A0 (Using a laptop as a rogue access point has always been easy to do, and it may have become easier with the soft access point feature of Windows 7.)=A0 The resource owner connects to the Internet through the rogue access point. The attacker can observe all traffic that is not encrypted by TLS. The resource owner tries to use a client application to access a protected resource.=A0 The client application, which implements the web server client profile, has registered with an authorization server, and has been issued a client identifier and client password credentials by the authorization server. The resource owner accesses the client application.=A0 The client application redirects the resource owner to the authorization server.=A0 The authorization server authenticates the resource owner and redirects the resource owner's browser to the redirection URI of the client application.=A0 The scheme of the redirection URI is http rather than https.=A0 The redirected request conveys the authorization code to the client application.=A0 The client application uses the authorization code and its client password credentials to obtain an access token from the authorization server. When it obtains the access token, the client application logs in the resource owner (as applications typically do) creating a session record where it stores the access token, so that it can use it later to access protected resources as requested by the resource owner.=A0 The client application sets an authentication cookie in the resource owner's browser (as applications typically do) which refers to the session record and is used to authenticate subsequent requests to the client application from the resource owner. The authentication cookie is set by the http response to the request that conveyed the authorization code to the client application.=A0 That request was sent to the redirection URI, and was not encrypted by TLS.=A0 Therefore the attacker can observe the authentication cookie.=A0 As soon as the attacker observes the cookie, it terminates the wireless connection of the resource owner, and starts using the cookie to impersonate the resource owner.=A0 The attacker uses the cookie to make requests to the application for protected resources, and the application accesses those protected resources using the access token stored in the browser record referenced by the cookie. There is a variation of the attack that uses DNS spoofing. DNS spoofing is easy to set up on a laptop that implements a rogue access point.=A0 The attacker spoofs the DNS vis-a-vis the resource-owner's laptop, mapping the domain name of the client application to the LAN-side IP address of the rogue address point.=A0 The attacker's laptop then proxies the connection from the resource owner's laptop to the client, which is possible because the connection is not protected by TLS.=A0 The attacker has thus easy access to the authentication cookie. Besides OAuth, the attack works against OpenID, which fails to recommend the use of TLS for the redirection from the OpenID Provider back to the Relying party.=A0 The attack also affected my own little PKAuth protocol (discussed in the unregistered applications thread), which also uses a double redirection mechanism.=A0 PKAuth uses TLS throughout, but I was implicitly making the claim that it provided protection even if the user ignored an invalid-certificate warning from the browser.=A0 I've now removed that claim. Francisco --0-808382139-1294121465=:10811 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

The OAuth spec recommends the = use of TLS when sending
requests to the end-user authorization endpoint = and requires
it when sending requests to the token endpoint.  It sa= ys
nothing about using TLS when redirecting the browser back to
the c= lient, which implies that it is not needed for that
purpose.

In f= act, TLS is needed just as much when redirecting back to
the client as w= hen sending requests to the token endpoint.
If TLS is not used when redi= recting back, the following
attack, which is easy to implement, allows t= he attacker to
impersonate a resource owner and gain access to protected=
resources.

The resource owner goes to an airport or a coffee hou= se with
a laptop.  The attacker is sitting at the airport or coffee=
house with a loptop that implements a rogue Wifi access
point.  (Using a laptop as a rogue access point has always
been easy to do, and it may have become easier with = the soft
access point feature of Windows 7.)  The resource owner
connects to the Inter= net through the rogue access point.
The attacker can observe all traffic= that is not encrypted
by TLS.

The resource owner tries to use a = client application to
access a protected resource.  The client appl= ication, which
implements the web server client profile, has registered<= br>with an authorization server, and has been issued a client
identifier= and client password credentials by the
authorization server.

The= resource owner accesses the client application.  The
client applic= ation redirects the resource owner to the
authorization server.  The authorization server
authenticates the resource owner and redirects= the resource
owner's browser to the redirection URI of the client
ap= plication.  The scheme of the redirection URI is http
rather than h= ttps.  The redirected request conveys the
authorization code to the= client application.  The client
application uses the authorization= code and its client
password credentials to obtain an access token from= the
authorization server.

When it obtains the access token, the = client application
logs in the resource owner (as applications typically= do)
creating a session record where it stores the access token,
so t= hat it can use it later to access protected resources as
requested by th= e resource owner.  The client application
sets an authentication co= okie in the resource owner's
browser (as applications typically do) whic= h refers to the
session record and is used to authenticate subsequent
requests to the client application from the resource owner.<= br>
The authentication cookie is set by the http response to the
requ= est that conveyed the authorization code to the client
application. = ; That request was sent to the redirection URI,
and was not encrypted by= TLS.  Therefore the attacker can
observe the authentication cookie= .  As soon as the attacker
observes the cookie, it terminates the w= ireless connection
of the resource owner, and starts using the cookie to=
impersonate the resource owner.  The attacker uses the
cookie t= o make requests to the application for protected
resources, and the appl= ication accesses those protected
resources using the access token stored= in the browser
record referenced by the cookie.

There is a varia= tion of the attack that uses DNS spoofing.
DNS spoofing is easy to set up on a laptop that implements a
rogue access point.  The atta= cker spoofs the DNS vis-a-vis
the resource-owner's laptop, mapping the d= omain name of the
client application to the LAN-side IP address of the r= ogue
address point.  The attacker's laptop then proxies the
conn= ection from the resource owner's laptop to the client,
which is possible= because the connection is not protected by
TLS.  The attacker has = thus easy access to the
authentication cookie.

Besides OAuth, the= attack works against OpenID, which fails
to recommend the use of TLS fo= r the redirection from the
OpenID Provider back to the Relying party.&nb= sp; The attack also
affected my own little PKAuth protocol (discussed in= the
unregistered applications thread), which also uses a doubleredirection mechanism.  PKAuth uses TLS throughout, but I
was implicitly making the claim that it provided protection
even i= f the user ignored an invalid-certificate warning from
the browser. = ; I've now removed that claim.

Francisco

--0-808382139-1294121465=:10811-- From SRS0=tuntU7=UC=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Mon Jan 3 23:25:19 2011 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 7158C3A6B4D for ; Mon, 3 Jan 2011 23:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.826 X-Spam-Level: X-Spam-Status: No, score=-0.826 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753] 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 KG-GVZwYQu-j for ; Mon, 3 Jan 2011 23:25:18 -0800 (PST) Received: from smtp10.bis7.eu.blackberry.com (smtp10.bis7.eu.blackberry.com [178.239.85.15]) by core3.amsl.com (Postfix) with ESMTP id 6DB2B3A6B3F for ; Mon, 3 Jan 2011 23:25:17 -0800 (PST) Received: from b1.c11.bise7.blackberry ([192.168.0.101]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p047RMwa031339; Tue, 4 Jan 2011 07:27:22 GMT Received: from ups31.c11.bise7.blackberry (cmp31.c11.bise7.blackberry [172.18.204.201]) by b1.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p047RMHO012324; Tue, 4 Jan 2011 07:27:22 GMT X-rim-org-msg-ref-id: 1547823857 Message-ID: <1547823857-1294126042-cardhu_decombobulator_blackberry.rim.net-1994637403-@b1.c11.bise7.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <210422.10811.qm@web55804.mail.re3.yahoo.com> In-Reply-To: <210422.10811.qm@web55804.mail.re3.yahoo.com> Sensitivity: Normal Importance: Normal To: fcorella@pomcor.com, oauth@ietf.org From: torsten@lodderstedt.net Date: Tue, 4 Jan 2011 07:27:20 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 07:27:12 -0000 RnJhbmNpc2NvLA0KDQp5b3UgbWFkZSBhIGdvb2QgcG9pbnQuIEhvd2V2ZXIsIHRoZSBxdWVzdGlv biBpcyBpZiB0aGlzIGJlbG9uZ3MgaW50byB0aGUgT0F1dGggc2NvcGUgc2luY2UgdGhpcyBhIGdl bmVyYWwgYXR0YWNrIG9uIGEgd2ViIGFwcCdzIHNlc3Npb24gbWFuYWdlbWVudC4gDQoNCkkgd2ls bCBpbmNvcnBvcmF0ZSB0aGUgdGhyZWF0IHlvdSBkZXNjcmliZWQgYW5kIHRoZSBhZHZpY2UgdG8g dXNlIFRMUyBpbnRvIHRoZSBPQXV0aCBzZWN1cml0eSBkb2N1bWVudC4NCg0KcmVnYXJkcywNClRv cnN0ZW4uDQpHZXNlbmRldCBtaXQgQmxhY2tCZXJyea4gV2VibWFpbCB2b24gVGVsZWtvbSBEZXV0 c2NobGFuZCAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBGcmFuY2lzY28g Q29yZWxsYSA8ZmNvcmVsbGFAcG9tY29yLmNvbT4NClNlbmRlcjogb2F1dGgtYm91bmNlc0BpZXRm Lm9yZw0KRGF0ZTogTW9uLCAzIEphbiAyMDExIDIyOjExOjA1IA0KVG86IDxvYXV0aEBpZXRmLm9y Zz4NClJlcGx5LVRvOiBmY29yZWxsYUBwb21jb3IuY29tDQpDYzogS2FyZW4gUC4gTGV3aXNvbjxr cGxld2lzb25AcG9tY29yLmNvbT4NClN1YmplY3Q6IFtPQVVUSC1XR10gVExTIGlzIG5lZWRlZCBm b3IgcmVkaXJlY3RpbmcgYmFjayB0byB0aGUgY2xpZW50DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== From stpeter@stpeter.im Tue Jan 4 08:06:35 2011 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 D90263A6CEC for ; Tue, 4 Jan 2011 08:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, 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 JGIct++FJFiI for ; Tue, 4 Jan 2011 08:06:35 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CC8233A6CD6 for ; Tue, 4 Jan 2011 08:06:34 -0800 (PST) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3538B4009B; Tue, 4 Jan 2011 09:22:57 -0700 (MST) Message-ID: <4D234607.8010805@stpeter.im> Date: Tue, 04 Jan 2011 09:08:39 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <20101213221033.77C333A6D3F@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <86C32B7E-1233-496C-8F74-490287251C16@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723441191F387A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723441191F3A34@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723441191F3A34@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040700030305090700010704" Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 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, 04 Jan 2011 16:06:35 -0000 This is a cryptographically signed message in MIME format. --------------ms040700030305090700010704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. I'll poke the chairs about accepting this as a WG item. :) Peter On 12/14/10 6:26 PM, Eran Hammer-Lahav wrote: > Prepare a new draft if needed and submit it with draft-ietf-oauth- > prefix. One of the chairs will need to approve it and it will be > published. I think we have wide consensus for this and this was > already proposed a long time ago with no objections. >=20 > EHL >=20 >> -----Original Message----- From: Brian Campbell >> [mailto:bcampbell@pingidentity.com] Sent: Tuesday, December 14, >> 2010 10:18 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth=20 >> Subject: Re: [OAUTH-WG] Fwd: New Version Notification for >> draft-campbell- oauth-saml-01 >>=20 >> I don't have any objection to it and think it's probably cleaner. >>=20 >> Previously I'd informally asked that the SAML profile be considered >> a WG item and I don't think there was any objection. What needs to >> be done to make that happen? >>=20 >> If you/we take this approach, what else will you need from me? >>=20 >> On Tue, Dec 14, 2010 at 9:23 AM, Eran Hammer-Lahav=20 >> wrote: >>> Torsten made a good argument that now that we combined assertions >>> and >> extensions into a single mechanism, it does not make sense to make >> the 'assertion' parameter required, and that some extensions will >> be confusing with such a parameter name. In addition, the recent >> document split demoted this specification from 'core' to >> 'framework' which is more friendly to extensions and companion >> specifications. >>>=20 >>> I would suggest we drop the assertion parameter from the spec, >>> but add a >> directly reference to the SAML assertion specification and give an >> example showing the parameter. This will remove the normative >> language (which really doesn't belong there - something I've long >> maintained), but will keep the SAML assertion option on equal >> ground (directly demonstrated in the spec). After all, you can't >> implement assertions just by reading the framework spec, you still >> need the SAML work. >>>=20 >>> This will require moving the SAML into a WG item (not a must but >>> best) >> which I am supportive of and would like to see happen quickly (in a >> few days). >>>=20 >>> Thoughts? >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- From: Brian Campbell >>>> [mailto:bcampbell@pingidentity.com] Sent: Tuesday, December 14, >>>> 2010 8:11 AM To: Torsten Lodderstedt Cc: Eran Hammer-Lahav; >>>> oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification >>>> for draft-campbell- oauth-saml-01 >>>>=20 >>>> Future revisions of this SAML draft will build off whatever=20 >>>> assertion/extension mechanism is provided by the core framework >>>> spec. However, some compelling reasons were previously given >>>> for keeping the 'assertion' (one thread on the topic:=20 >>>> http://www.ietf.org/mail-archive/web/oauth/current/msg04401.html) >>>> >>>>=20 parameter in core. Has the thinking on that changed? >>>>=20 >>>> On Tue, Dec 14, 2010 at 9:05 AM, Torsten Lodderstedt=20 >>>> wrote: >>>>> +1 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav >>>> : >>>>>=20 >>>>>> I think the 'assertion' parameter should be moved into this >>>>>> draft and >>>> defined there. This will also facilitate its proper definition >>>> and status (required, singular, etc.). >>>>>>=20 >>>>>> EHL >>>>>>=20 >>>=20 --------------ms040700030305090700010704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDEw NDE2MDgzOVowIwYJKoZIhvcNAQkEMRYEFNQehPDTXxmvAWNREBD58tOMfOeUMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAYgdDLRZVBoc7c/AMVA0v9HHmf8aGk/PVin4LRDnqvwWLVLOsxIE9N3iwb lVF7wzCokTUJ5rhPJqSJGG49GRfnZYBLpA+Y4BhrQVPVBCzA2VOfdMolUSv0YQhFwit4VL1R HyQT5nvVcTs2SpVo0XeolYrmE4sfrQyz8IP9nYKBts97u/YJHvWpxQPIXBQN1OoOlJ8Z+MHu MAoqtoR7PIGSH5fgo/1l17kvACjDXtj8vzjIUbsugjHgMWwJFedVhENrxpGivf9C2BDyltNa sRORYaCBEmA5K9NOJD1Bo3DuqMnkqUKcD8oV1+X2f4jlk51FnRfMlJX6daHcBfX2VdpxAAAA AAAA --------------ms040700030305090700010704-- From bcampbell@pingidentity.com Tue Jan 4 08:25:14 2011 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 6C1BB3A6CDE for ; Tue, 4 Jan 2011 08:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 OXt6vHBUEQxL for ; Tue, 4 Jan 2011 08:25:13 -0800 (PST) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with SMTP id 074EE3A6CE8 for ; Tue, 4 Jan 2011 08:25:12 -0800 (PST) Received: from source ([209.85.161.54]) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTSNKZ8v+v8eZyMfVUotO7BNExF4PD55F@postini.com; Tue, 04 Jan 2011 08:27:20 PST Received: by mail-fx0-f54.google.com with SMTP id 16so14339062fxm.27 for ; Tue, 04 Jan 2011 08:27:19 -0800 (PST) Received: by 10.223.100.4 with SMTP id w4mr986437fan.115.1294158439181; Tue, 04 Jan 2011 08:27:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.55.9 with HTTP; Tue, 4 Jan 2011 08:26:49 -0800 (PST) In-Reply-To: <4D234607.8010805@stpeter.im> References: <20101213221033.77C333A6D3F@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <86C32B7E-1233-496C-8F74-490287251C16@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723441191F387A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723441191F3A34@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D234607.8010805@stpeter.im> From: Brian Campbell Date: Tue, 4 Jan 2011 09:26:49 -0700 Message-ID: To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 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, 04 Jan 2011 16:25:14 -0000 Thanks Peter. I did update the draft and submit it with a draft-ietf-oauth- prefix. The I-D submission summary page for it is at https://datatracker.ietf.org/idst/status.cgi?submission_id=3D28905 On Tue, Jan 4, 2011 at 9:08 AM, Peter Saint-Andre wrot= e: > > > Agreed. > > I'll poke the chairs about accepting this as a WG item. :) > > Peter > > On 12/14/10 6:26 PM, Eran Hammer-Lahav wrote: >> Prepare a new draft if needed and submit it with draft-ietf-oauth- >> prefix. One of the chairs will need to approve it and it will be >> published. I think we have wide consensus for this and this was >> already proposed a long time ago with no objections. >> >> EHL >> >>> -----Original Message----- From: Brian Campbell >>> [mailto:bcampbell@pingidentity.com] Sent: Tuesday, December 14, >>> 2010 10:18 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth >>> Subject: Re: [OAUTH-WG] Fwd: New Version Notification for >>> draft-campbell- oauth-saml-01 >>> >>> I don't have any objection to it and think it's probably cleaner. >>> >>> Previously I'd informally asked that the SAML profile be considered >>> a WG item and I don't think there was any objection. What needs to >>> be done to make that happen? >>> >>> If you/we take this approach, what else will you need from me? >>> >>> On Tue, Dec 14, 2010 at 9:23 AM, Eran Hammer-Lahav >>> wrote: >>>> Torsten made a good argument that now that we combined assertions >>>> and >>> extensions into a single mechanism, it does not make sense to make >>> the 'assertion' parameter required, and that some extensions will >>> be confusing with such a parameter name. In addition, the recent >>> document split demoted this specification from 'core' to >>> 'framework' which is more friendly to extensions and companion >>> specifications. >>>> >>>> I would suggest we drop the assertion parameter from the spec, >>>> but add a >>> directly reference to the SAML assertion specification and give an >>> example showing the parameter. This will remove the normative >>> language (which really doesn't belong there - something I've long >>> maintained), but will keep the SAML assertion option on equal >>> ground (directly demonstrated in the spec). After all, you can't >>> implement assertions just by reading the framework spec, you still >>> need the SAML work. >>>> >>>> This will require moving the SAML into a WG item (not a must but >>>> best) >>> which I am supportive of and would like to see happen quickly (in a >>> few days). >>>> >>>> Thoughts? >>>> >>>> EHL >>>> >>>>> -----Original Message----- From: Brian Campbell >>>>> [mailto:bcampbell@pingidentity.com] Sent: Tuesday, December 14, >>>>> 2010 8:11 AM To: Torsten Lodderstedt Cc: Eran Hammer-Lahav; >>>>> oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification >>>>> for draft-campbell- oauth-saml-01 >>>>> >>>>> Future revisions of this SAML draft will build off whatever >>>>> assertion/extension mechanism is provided by the core framework >>>>> spec. However, some compelling reasons were previously given >>>>> for keeping the 'assertion' (one thread on the topic: >>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg04401.html) >>>>> >>>>> > parameter in core. =A0Has the thinking on that changed? >>>>> >>>>> On Tue, Dec 14, 2010 at 9:05 AM, Torsten Lodderstedt >>>>> wrote: >>>>>> +1 >>>>>> >>>>>> >>>>>> >>>>>> Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav >>>>> : >>>>>> >>>>>>> I think the 'assertion' parameter should be moved into this >>>>>>> draft and >>>>> defined there. This will also facilitate its proper definition >>>>> and status (required, singular, etc.). >>>>>>> >>>>>>> EHL >>>>>>> >>>> > > From romeda@gmail.com Tue Jan 4 09:27:04 2011 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 556723A6CE0 for ; Tue, 4 Jan 2011 09:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.099 X-Spam-Level: X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 IyZf9Zg6M4QV for ; Tue, 4 Jan 2011 09:27:02 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 7582A3A6BE0 for ; Tue, 4 Jan 2011 09:27:01 -0800 (PST) Received: by wwa36 with SMTP id 36so14556653wwa.13 for ; Tue, 04 Jan 2011 09:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=qa2zwk9KRax63tu/foOgIf6E8ulZI6bXbyWc44C1IOM=; b=cMR1dWqNeeOUm/ABSsQ87/xw9FPwayPwrcl4c2TWXlIzsfE4iUldybBn0XsIqYd/xe 3qMfq84fCWlS5pe8YMi8nF+crmceV1njML4LVFlN88IXq2xalXv8nfdTV6W3k8zXvxfz iHzooWQcpELOyL5adcXZ0QUs6nHkpoGdwX3JY= 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 :cc:content-type:content-transfer-encoding; b=um+nDbh79qxPSZrYvDeswNq1ygbVPPKEWdbG74qEQrjlDTjvXPqp1Wp2mk6XQIapO8 fEwGoQg3B6B4N8rjGNyzdgKTKImqkIUZMheq0z4Gl2MDTzu72HzalchvLsdxjFJTPaEJ 1mvCZT7bEF2BULsiqddquZ1z8wdvqe4BRASeg= Received: by 10.216.162.70 with SMTP id x48mr13221969wek.4.1294162146497; Tue, 04 Jan 2011 09:29:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.240.197 with HTTP; Tue, 4 Jan 2011 09:28:46 -0800 (PST) In-Reply-To: References: <20101213221033.77C333A6D3F@core3.amsl.com> <90C41DD21FB7C64BB94121FBBC2E72343FD431FCFC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <86C32B7E-1233-496C-8F74-490287251C16@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723441191F387A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723441191F3A34@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D234607.8010805@stpeter.im> From: Blaine Cook Date: Tue, 4 Jan 2011 09:28:46 -0800 Message-ID: To: Brian Campbell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-saml-01 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, 04 Jan 2011 17:27:04 -0000 Accepted into the tracker. Thanks, Brian! b. On 4 January 2011 08:26, Brian Campbell wrote: > Thanks Peter. =C2=A0I did update the draft and submit it with a > draft-ietf-oauth- prefix. The I-D submission summary page for it is at > https://datatracker.ietf.org/idst/status.cgi?submission_id=3D28905 > > On Tue, Jan 4, 2011 at 9:08 AM, Peter Saint-Andre wr= ote: >> >> >> Agreed. >> >> I'll poke the chairs about accepting this as a WG item. :) >> >> Peter >> >> On 12/14/10 6:26 PM, Eran Hammer-Lahav wrote: >>> Prepare a new draft if needed and submit it with draft-ietf-oauth- >>> prefix. One of the chairs will need to approve it and it will be >>> published. I think we have wide consensus for this and this was >>> already proposed a long time ago with no objections. >>> >>> EHL >>> >>>> -----Original Message----- From: Brian Campbell >>>> [mailto:bcampbell@pingidentity.com] Sent: Tuesday, December 14, >>>> 2010 10:18 AM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; oauth >>>> Subject: Re: [OAUTH-WG] Fwd: New Version Notification for >>>> draft-campbell- oauth-saml-01 >>>> >>>> I don't have any objection to it and think it's probably cleaner. >>>> >>>> Previously I'd informally asked that the SAML profile be considered >>>> a WG item and I don't think there was any objection. What needs to >>>> be done to make that happen? >>>> >>>> If you/we take this approach, what else will you need from me? >>>> >>>> On Tue, Dec 14, 2010 at 9:23 AM, Eran Hammer-Lahav >>>> wrote: >>>>> Torsten made a good argument that now that we combined assertions >>>>> and >>>> extensions into a single mechanism, it does not make sense to make >>>> the 'assertion' parameter required, and that some extensions will >>>> be confusing with such a parameter name. In addition, the recent >>>> document split demoted this specification from 'core' to >>>> 'framework' which is more friendly to extensions and companion >>>> specifications. >>>>> >>>>> I would suggest we drop the assertion parameter from the spec, >>>>> but add a >>>> directly reference to the SAML assertion specification and give an >>>> example showing the parameter. This will remove the normative >>>> language (which really doesn't belong there - something I've long >>>> maintained), but will keep the SAML assertion option on equal >>>> ground (directly demonstrated in the spec). After all, you can't >>>> implement assertions just by reading the framework spec, you still >>>> need the SAML work. >>>>> >>>>> This will require moving the SAML into a WG item (not a must but >>>>> best) >>>> which I am supportive of and would like to see happen quickly (in a >>>> few days). >>>>> >>>>> Thoughts? >>>>> >>>>> EHL >>>>> >>>>>> -----Original Message----- From: Brian Campbell >>>>>> [mailto:bcampbell@pingidentity.com] Sent: Tuesday, December 14, >>>>>> 2010 8:11 AM To: Torsten Lodderstedt Cc: Eran Hammer-Lahav; >>>>>> oauth Subject: Re: [OAUTH-WG] Fwd: New Version Notification >>>>>> for draft-campbell- oauth-saml-01 >>>>>> >>>>>> Future revisions of this SAML draft will build off whatever >>>>>> assertion/extension mechanism is provided by the core framework >>>>>> spec. However, some compelling reasons were previously given >>>>>> for keeping the 'assertion' (one thread on the topic: >>>>>> http://www.ietf.org/mail-archive/web/oauth/current/msg04401.html) >>>>>> >>>>>> >> parameter in core. =C2=A0Has the thinking on that changed? >>>>>> >>>>>> On Tue, Dec 14, 2010 at 9:05 AM, Torsten Lodderstedt >>>>>> wrote: >>>>>>> +1 >>>>>>> >>>>>>> >>>>>>> >>>>>>> Am 14.12.2010 um 04:19 schrieb Eran Hammer-Lahav >>>>>> : >>>>>>> >>>>>>>> I think the 'assertion' parameter should be moved into this >>>>>>>> draft and >>>>>> defined there. This will also facilitate its proper definition >>>>>> and status (required, singular, etc.). >>>>>>>> >>>>>>>> EHL >>>>>>>> >>>>> >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From Internet-Drafts@ietf.org Tue Jan 4 09:30:11 2011 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 3428D3A6D07; Tue, 4 Jan 2011 09:30:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 w8ayywiq7djA; Tue, 4 Jan 2011 09:30:08 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0A0E3A6D09; Tue, 4 Jan 2011 09:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110104173002.20752.72742.idtracker@localhost> Date: Tue, 04 Jan 2011 09:30:02 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-saml2-bearer-00.txt 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, 04 Jan 2011 17:30:11 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 Author(s) : B. Campbell, C. Mortimore Filename : draft-ietf-oauth-saml2-bearer-00.txt Pages : 12 Date : 2010-12-15 This specification defines the use of a SAML 2.0 bearer Assertion as means for requesting an OAuth 2.0 access token. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-saml2-bearer-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-04092407.I-D@ietf.org> --NextPart-- From fcorella@pomcor.com Tue Jan 4 13:25:20 2011 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 8F4223A6BCF for ; Tue, 4 Jan 2011 13:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 BGfa32IJ8Mm4 for ; Tue, 4 Jan 2011 13:25:19 -0800 (PST) Received: from nm6-vm0.bullet.mail.ac4.yahoo.com (nm6-vm0.bullet.mail.ac4.yahoo.com [98.139.52.70]) by core3.amsl.com (Postfix) with SMTP id 206273A6BCE for ; Tue, 4 Jan 2011 13:25:18 -0800 (PST) Received: from [98.139.52.196] by nm6.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 21:27:23 -0000 Received: from [98.139.52.145] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 21:27:23 -0000 Received: from [127.0.0.1] by omp1028.mail.ac4.yahoo.com with NNFMP; 04 Jan 2011 21:27:23 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 383219.93060.bm@omp1028.mail.ac4.yahoo.com Received: (qmail 3539 invoked by uid 60001); 4 Jan 2011 21:27:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294176443; bh=Ydrjbkw3E3PIUMn+7c/afkPuirTOCMhlITogtJV/7BQ=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hJ87GHXe3jK0u2NZS6jyyIjwjXMwpEqRKqmsdpUd0WLGJabzhg0/y7JDDJvG+IpZpeyvuQt8D7aGZzgsB5q1hhlp1Q2fdm4Hmxwc9mA99v65Sl6U20CxiSxd/8+NpB7s3tZduvBz1LwEOUJ2D42KYzkti9li1SSTBQThz+z5kN0= Message-ID: <180992.98715.qm@web55806.mail.re3.yahoo.com> X-YMail-OSG: 7VKzbRUVM1mUwA3p8q1qFRW7EWwNE14fG0gNEsLCV0m1yAE t_Yx9BXmPjCi_P.Cv847C7FOWfg6WA3vYyrEzp62N.BPTiQr9ZyPeywYrhwN .UWpeZvGCvvRV2GdXC1n4XDqqLbBNvcl7oiw723BcOfa.GJr7KaZbxxDVaI_ oie3lEaEYyC7IoOmevl29k75JKOlhBO_IMplxiR_8BtzljHUs93l_g.aKN7N a6x4KmrP4Sfv_ensPtm.au0uu1ATFmkQf9Q1Kk_g01hGG5FOmakRJaimis_I 6ETYk6.vDTK8NEtQudyegSVc2ox1XpY.ipv5dEg3kyicUocKGNZcEfByPpOT f5Hz1YzlxKDzmKRkL6kYhLqqG2ACsBPKhRlzfKjauc61JyPdDqaCTF4Wn8EM O5F8- Received: from [67.91.91.101] by web55806.mail.re3.yahoo.com via HTTP; Tue, 04 Jan 2011 13:27:22 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Tue, 4 Jan 2011 13:27:22 -0800 (PST) From: Francisco Corella To: oauth@ietf.org, torsten@lodderstedt.net In-Reply-To: <1547823857-1294126042-cardhu_decombobulator_blackberry.rim.net-1994637403-@b1.c11.bise7.blackberry> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1788708054-1294176442=:98715" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 21:25:20 -0000 --0-1788708054-1294176442=:98715 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Torsten, > you made a good point. However, the question is if this > belongs into the OAuth scope since this a general attack on > a web app's session management. I gave two variants of the attack.=A0 I agree that the first variant "looks like" an attack against session management, but the second variant is clearly an attack against the protocol. Let me recap the second variant. The attacker compromises the DNS, mapping the domain name in the redirection URI to the attacker's machine.=A0 The http request sent by the resource owner's browser to the redirection uri, which contains the authorization code, is received by the attacker's machine.=A0 The attacker forwards the request with the authorization code to the client application from the attacker's own machine, thereby impersonating the resource owner.=A0 The client application mistakenly authenticates the attacker as the resource owner after verifying that the authorization code is legitimate by using it to get an access code from the authorization server.=A0 After the mistaken authentication, the client application creates a session and gives an authentication cookie to the attacker. Let me philosophize a bit. OAuth was conceived as an authorization protocol, hence the vocabulary ("authorization server", "resource owner"), but it has morphed.=A0 Now it is also used for authentication. When you click on a button "Login with Twitter" or "Login with Facebook" you are authenticated with OAuth: Twitter and Facebook do not currently support OpenID for social login. When OAuth is used for authentication, the authorization code takes on a different role: posession of the authorization code is what authenticates the user. Therefore transmission of the authorization code must be protected by TLS. Let me philosophize some more.=A0 (Busy people should stop reading here ;-) We need a protocol that does both authentication and authorization.=A0 We can take OAuth and adapt it for authentication, or take OpenID and adapt it for authorization, or combine OpenID and OAuth (great solution for people who love complexity) or... take the best ideas from OpenID and OAuth and incorporate them into a new protocol that's designed from the start for both authentication and authorization.=A0 That's one of my motivations for proposing PKAuth. Now a political speech. Social login is going to win.=A0 (I use "social login" as Janrain uses it, I believe they coined the term, is that right?)=A0 It will win because it has tremendous advantages not just for users (that's not enough), but also for social sites and applications.=A0 Once it wins we may get into a situation where social login with the social identity provided by the dominant social site (currently Facebook) becomes the de fact standard for user authentication on the Web.=A0 If the dominant social site requires application registration, then every application on the Web will have to register with the dominant social site just to be able to authenticate its users, whether or not they have anything to do with the social site. The dominant social site would then have to power to kill any application by terminating its registration.=A0 This would be an intolerable situation for everybody, including the dominant social site.=A0 The dominant social site will not need or want this kind of power, which would call for government regulation by every government on the planet. So we need an authentication and authorization protocol where application registration is optional.=A0 But registration has an essential function in OAuth.=A0 The social site relies on registration to be able to reliably identify the application to the user.=A0 We need a protocol that can reliably identify unregistered applications to the user. That's a second motivation for PKAuth. Francisco --0-1788708054-1294176442=:98715 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <= /tr>
Torsten,

> you made a good point. H= owever, the question is if this
> belongs into the OAuth scope since = this a general attack on
> a web app's session management.

I g= ave two variants of the attack.  I agree that the first
variant "lo= oks like" an attack against session management,
but the second variant i= s clearly an attack against the
protocol.

Let me recap the second= variant.

The attacker compromises the DNS, mapping the domain name = in
the redirection URI to the attacker's machine.  The http
requ= est sent by the resource owner's browser to the
redirection uri, which c= ontains the authorization code, is
received by the attacker's machine.&n= bsp; The attacker forwards
the request with the authorization code to th= e client
application from the attacker's own machine, thereby
impersonating the resource owner.  The client application<= br>mistakenly authenticates the attacker as the resource owner
after ver= ifying that the authorization code is legitimate by
using it to get an a= ccess code from the authorization
server.  After the mistaken authe= ntication, the client
application creates a session and gives an authent= ication
cookie to the attacker.

Let me philosophize a bit.
OAuth was conceived as an authorization protocol, hence the
vocabulary = ("authorization server", "resource owner"), but
it has morphed.  No= w it is also used for authentication.
When you click on a button "Login = with Twitter" or "Login
with Facebook" you are authenticated with OAuth:= Twitter and
Facebook do not currently support OpenID for social login.<= br>
When OAuth is used for authentication, the authorization
code tak= es on a different role: posession of the
authorization code is what authenticates the user.
Therefore transmission of the authorizatio= n code must be
protected by TLS.

Let me philosophize some more.&n= bsp; (Busy people should stop
reading here ;-)

We need a protocol= that does both authentication and
authorization.  We can take OAut= h and adapt it for
authentication, or take OpenID and adapt it for
au= thorization, or combine OpenID and OAuth (great solution
for people who = love complexity) or... take the best ideas
from OpenID and OAuth and inc= orporate them into a new
protocol that's designed from the start for bot= h
authentication and authorization.  That's one of my
motivation= s for proposing PKAuth.

Now a political speech.

Social login = is going to win.  (I use "social login" as
Janrain uses it, I belie= ve they coined the term, is that
right?)  It will win because it ha= s tremendous advantages
not just for users (that's not enough), but also for social
sites and applications.  Once it wins we may g= et into a
situation where social login with the social identity
provi= ded by the dominant social site (currently Facebook)
becomes the de fact= standard for user authentication on the
Web.  If the dominant soci= al site requires application
registration, then every application on the= Web will have to
register with the dominant social site just to be able= to
authenticate its users, whether or not they have anything to
do w= ith the social site.

The dominant social site would then have to pow= er to kill
any application by terminating its registration.  This w= ould
be an intolerable situation for everybody, including the
dominan= t social site.  The dominant social site will not
need or want this= kind of power, which would call for
government regulation by every gove= rnment on the planet.

So we need an authentication and authorization protocol
where application registration is optional. = ; But
registration has an essential function in OAuth.  The social<= br>site relies on registration to be able to reliably identify
the appli= cation to the user.  We need a protocol that can
reliably identify = unregistered applications to the user.
That's a second motivation for PK= Auth.

Francisco



--0-1788708054-1294176442=:98715-- From mscurtescu@google.com Tue Jan 4 13:35:45 2011 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 C3BF93A6D34 for ; Tue, 4 Jan 2011 13:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[AWL=-2.763, 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 kM+fdfCwI+FS for ; Tue, 4 Jan 2011 13:35:44 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 7BFC23A6CE8 for ; Tue, 4 Jan 2011 13:35:44 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p04Lbov7029284 for ; Tue, 4 Jan 2011 13:37:50 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294177070; bh=mI022rFNTGBDEV23o6h2LJZ7tbs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=YKsY8/wPdxON4GSrJt+N9a/Qf1Bb/o75sU9NJ6I8iDi7s2jNtl1p9qF2s21nUyyrs X11z9E2S8dD93DuF6uZwA== Received: from yxh35 (yxh35.prod.google.com [10.190.2.227]) by wpaz24.hot.corp.google.com with ESMTP id p04Lbine019010 for ; Tue, 4 Jan 2011 13:37:49 -0800 Received: by yxh35 with SMTP id 35so6543087yxh.27 for ; Tue, 04 Jan 2011 13:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=pYv12aaUj8Vkk2/ESIvCNryL9Gtj2oarjYQL3du3Kvw=; b=Sf7T4yCCMPo+KLtoSWTUrpLEmRx5MmRiBcqbpt/nOyju1XlzigywqVOZTfeGjKasjM hXTXtjPMU4N6o1exvkWg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Qu0gKoaL0sB6AL6fliGoha0EJAzzWYKnSBz6RZ7AJIjVZOurDcjjMAV4bQV/UyxLhm oR6Qm/KQ81C9GA8Piscg== Received: by 10.100.164.1 with SMTP id m1mr13486178ane.269.1294177068886; Tue, 04 Jan 2011 13:37:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.123.14 with HTTP; Tue, 4 Jan 2011 13:37:28 -0800 (PST) In-Reply-To: <180992.98715.qm@web55806.mail.re3.yahoo.com> References: <1547823857-1294126042-cardhu_decombobulator_blackberry.rim.net-1994637403-@b1.c11.bise7.blackberry> <180992.98715.qm@web55806.mail.re3.yahoo.com> From: Marius Scurtescu Date: Tue, 4 Jan 2011 13:37:28 -0800 Message-ID: To: fcorella@pomcor.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client 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, 04 Jan 2011 21:35:45 -0000 On Tue, Jan 4, 2011 at 1:27 PM, Francisco Corella wro= te: > > We need a protocol that does both authentication and > authorization.=A0 We can take OAuth and adapt it for > authentication, or take OpenID and adapt it for > authorization, or combine OpenID and OAuth (great solution > for people who love complexity) or... take the best ideas > from OpenID and OAuth and incorporate them into a new > protocol that's designed from the start for both > authentication and authorization.=A0 That's one of my > motivations for proposing PKAuth. Are you aware of OpenIDConnect? http://openidconnect.com/ Marius From SRS0=tuntU7=UC=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Tue Jan 4 13:41:19 2011 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 C95D53A6BB4 for ; Tue, 4 Jan 2011 13:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 cSYOqplO7mSt for ; Tue, 4 Jan 2011 13:41:17 -0800 (PST) Received: from smtp05.bis7.eu.blackberry.com (smtp05.bis7.eu.blackberry.com [178.239.85.10]) by core3.amsl.com (Postfix) with ESMTP id 00F753A6AB4 for ; Tue, 4 Jan 2011 13:41:16 -0800 (PST) Received: from b1.c11.bise7.blackberry ([192.168.0.101]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p04LhLPg008833; Tue, 4 Jan 2011 21:43:22 GMT Received: from ups31.c11.bise7.blackberry (cmp31.c11.bise7.blackberry [172.18.204.201]) by b1.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p04LhHaE027197; Tue, 4 Jan 2011 21:43:17 GMT X-rim-org-msg-ref-id: 1057088666 Message-ID: <1057088666-1294177397-cardhu_decombobulator_blackberry.rim.net-1938342415-@b1.c11.bise7.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <1547823857-1294126042-cardhu_decombobulator_blackberry.rim.net-1994637403-@b1.c11.bise7.blackberry><180992.98715.qm@web55806.mail.re3.yahoo.com> In-Reply-To: Sensitivity: Normal Importance: Normal To: "Marius Scurtescu" , fcorella@pomcor.com From: torsten@lodderstedt.net Date: Tue, 4 Jan 2011 21:43:15 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jan 2011 21:41:19 -0000 V2hhdCBpcyB0aGUgc3RhdHVzIG9mIG9wZW5pZCBjb25uZWN0IGFuZCB3aGF0IG9yZ2FuaXNhdGlv biBpc3Qgc3RhbmRhcmRpemluZyBpdD8NCkdlc2VuZGV0IG1pdCBCbGFja0JlcnJ5riBXZWJtYWls IHZvbiBUZWxla29tIERldXRzY2hsYW5kICANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IE1hcml1cyBTY3VydGVzY3UgPG1zY3VydGVzY3VAZ29vZ2xlLmNvbT4NCkRhdGU6IFR1 ZSwgNCBKYW4gMjAxMSAxMzozNzoyOCANClRvOiA8ZmNvcmVsbGFAcG9tY29yLmNvbT4NCkNjOiA8 b2F1dGhAaWV0Zi5vcmc+OyA8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+OyBLYXJlbiBQLiBMZXdp c29uPGtwbGV3aXNvbkBwb21jb3IuY29tPg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gVExTIGlz IG5lZWRlZCBmb3IgcmVkaXJlY3RpbmcgYmFjayB0byB0aGUgY2xpZW50DQoNCk9uIFR1ZSwgSmFu IDQsIDIwMTEgYXQgMToyNyBQTSwgRnJhbmNpc2NvIENvcmVsbGEgPGZjb3JlbGxhQHBvbWNvci5j b20+IHdyb3RlOg0KPg0KPiBXZSBuZWVkIGEgcHJvdG9jb2wgdGhhdCBkb2VzIGJvdGggYXV0aGVu dGljYXRpb24gYW5kDQo+IGF1dGhvcml6YXRpb24uoCBXZSBjYW4gdGFrZSBPQXV0aCBhbmQgYWRh cHQgaXQgZm9yDQo+IGF1dGhlbnRpY2F0aW9uLCBvciB0YWtlIE9wZW5JRCBhbmQgYWRhcHQgaXQg Zm9yDQo+IGF1dGhvcml6YXRpb24sIG9yIGNvbWJpbmUgT3BlbklEIGFuZCBPQXV0aCAoZ3JlYXQg c29sdXRpb24NCj4gZm9yIHBlb3BsZSB3aG8gbG92ZSBjb21wbGV4aXR5KSBvci4uLiB0YWtlIHRo ZSBiZXN0IGlkZWFzDQo+IGZyb20gT3BlbklEIGFuZCBPQXV0aCBhbmQgaW5jb3Jwb3JhdGUgdGhl bSBpbnRvIGEgbmV3DQo+IHByb3RvY29sIHRoYXQncyBkZXNpZ25lZCBmcm9tIHRoZSBzdGFydCBm b3IgYm90aA0KPiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbi6gIFRoYXQncyBvbmUg b2YgbXkNCj4gbW90aXZhdGlvbnMgZm9yIHByb3Bvc2luZyBQS0F1dGguDQoNCkFyZSB5b3UgYXdh cmUgb2YgT3BlbklEQ29ubmVjdD8NCg0KaHR0cDovL29wZW5pZGNvbm5lY3QuY29tLw0KDQoNCk1h cml1cw0K From jricher@mitre.org Tue Jan 4 13:44:25 2011 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 38D063A6BD0 for ; Tue, 4 Jan 2011 13:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 10HeR3etDHE6 for ; Tue, 4 Jan 2011 13:44:24 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 208B53A6AB4 for ; Tue, 4 Jan 2011 13:44:23 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id CB1D521B022A; Tue, 4 Jan 2011 16:46:30 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C3EF021B0220; Tue, 4 Jan 2011 16:46:30 -0500 (EST) Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Tue, 4 Jan 2011 16:46:30 -0500 From: Justin Richer To: Marius Scurtescu In-Reply-To: References: <1547823857-1294126042-cardhu_decombobulator_blackberry.rim.net-1994637403-@b1.c11.bise7.blackberry> <180992.98715.qm@web55806.mail.re3.yahoo.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 4 Jan 2011 16:46:30 -0500 Message-ID: <1294177590.22074.58.camel@pulse> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client 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, 04 Jan 2011 21:44:25 -0000 > > We need a protocol that does both authentication and > > authorization. We can take OAuth and adapt it for > > authentication, or take OpenID and adapt it for > > authorization, or combine OpenID and OAuth (great solution > > for people who love complexity) or... take the best ideas > > from OpenID and OAuth and incorporate them into a new > > protocol that's designed from the start for both > > authentication and authorization. That's one of my > > motivations for proposing PKAuth. > > Are you aware of OpenIDConnect? > > http://openidconnect.com/ And also the latest drafts of OpenID Artifact Binding: http://wiki.openid.net/w/page/12995134/Artifact-Binding (Don't have a link to the latest draft spec that uses OAuth2 terminology-- Nat, do you have something?) -- Justin From torsten@lodderstedt.net Tue Jan 4 13:52:45 2011 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 9BDE83A6AB4 for ; Tue, 4 Jan 2011 13:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=0.024, 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 uoasuUjRdnpY for ; Tue, 4 Jan 2011 13:52:44 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by core3.amsl.com (Postfix) with ESMTP id D7EE63A6C1B for ; Tue, 4 Jan 2011 13:52:43 -0800 (PST) Received: from [79.253.38.144] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PaEq9-00063s-9X; Tue, 04 Jan 2011 22:54:49 +0100 Message-ID: <4D239728.7040902@lodderstedt.net> Date: Tue, 04 Jan 2011 22:54:48 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: fcorella@pomcor.com References: <180992.98715.qm@web55806.mail.re3.yahoo.com> In-Reply-To: <180992.98715.qm@web55806.mail.re3.yahoo.com> Content-Type: multipart/alternative; boundary="------------060506000802010302070209" X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client 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, 04 Jan 2011 21:52:45 -0000 This is a multi-part message in MIME format. --------------060506000802010302070209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Francisco, the attack you described sounds very similar to session fixation attacks. TLS (more specifically server authentication) is one way to cope with spoofing in general (supposed the client has a reasonably CA policy). So it should do in this case, too. Validation of the redirect_uri associated with a particular authorization code on the tokens endpoint is another way to detect/prevent such an attack. Supposed the attacker has to inject the tapped authorization code into the client application during a second authorization flow. If the client uses different redirect_uri's for every flow, the attempt to inject the code can be detected. What do you think? regards, Torsten. > Torsten, > > > you made a good point. However, the question is if this > > belongs into the OAuth scope since this a general attack on > > a web app's session management. > > I gave two variants of the attack. I agree that the first > variant "looks like" an attack against session management, > but the second variant is clearly an attack against the > protocol. > > Let me recap the second variant. > > The attacker compromises the DNS, mapping the domain name in > the redirection URI to the attacker's machine. The http > request sent by the resource owner's browser to the > redirection uri, which contains the authorization code, is > received by the attacker's machine. The attacker forwards > the request with the authorization code to the client > application from the attacker's own machine, thereby > impersonating the resource owner. The client application > mistakenly authenticates the attacker as the resource owner > after verifying that the authorization code is legitimate by > using it to get an access code from the authorization > server. After the mistaken authentication, the client > application creates a session and gives an authentication > cookie to the attacker. > > Let me philosophize a bit. > > OAuth was conceived as an authorization protocol, hence the > vocabulary ("authorization server", "resource owner"), but > it has morphed. Now it is also used for authentication. > When you click on a button "Login with Twitter" or "Login > with Facebook" you are authenticated with OAuth: Twitter and > Facebook do not currently support OpenID for social login. > > When OAuth is used for authentication, the authorization > code takes on a different role: posession of the > authorization code is what authenticates the user. > Therefore transmission of the authorization code must be > protected by TLS. > > Let me philosophize some more. (Busy people should stop > reading here ;-) > > We need a protocol that does both authentication and > authorization. We can take OAuth and adapt it for > authentication, or take OpenID and adapt it for > authorization, or combine OpenID and OAuth (great solution > for people who love complexity) or... take the best ideas > from OpenID and OAuth and incorporate them into a new > protocol that's designed from the start for both > authentication and authorization. That's one of my > motivations for proposing PKAuth. > > Now a political speech. > > Social login is going to win. (I use "social login" as > Janrain uses it, I believe they coined the term, is that > right?) It will win because it has tremendous advantages > not just for users (that's not enough), but also for social > sites and applications. Once it wins we may get into a > situation where social login with the social identity > provided by the dominant social site (currently Facebook) > becomes the de fact standard for user authentication on the > Web. If the dominant social site requires application > registration, then every application on the Web will have to > register with the dominant social site just to be able to > authenticate its users, whether or not they have anything to > do with the social site. > > The dominant social site would then have to power to kill > any application by terminating its registration. This would > be an intolerable situation for everybody, including the > dominant social site. The dominant social site will not > need or want this kind of power, which would call for > government regulation by every government on the planet. > > So we need an authentication and authorization protocol > where application registration is optional. But > registration has an essential function in OAuth. The social > site relies on registration to be able to reliably identify > the application to the user. We need a protocol that can > reliably identify unregistered applications to the user. > That's a second motivation for PKAuth. > > Francisco > > > --------------060506000802010302070209 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Francisco,

the attack you described sounds very similar to session fixation attacks. TLS (more specifically server authentication) is one way to cope with spoofing in general (supposed the client has a reasonably CA policy). So it should do in this case, too.

Validation of the redirect_uri associated with a particular authorization code on the tokens endpoint is another way to detect/prevent such an attack. Supposed the attacker has to inject the tapped authorization code into the client application during a second authorization flow. If the client uses different redirect_uri's for every flow, the attempt to inject the code can be detected.

What do you think?

regards,
Torsten.
Torsten,

> you made a good point. However, the question is if this
> belongs into the OAuth scope since this a general attack on
> a web app's session management.

I gave two variants of the attack.  I agree that the first
variant "looks like" an attack against session management,
but the second variant is clearly an attack against the
protocol.

Let me recap the second variant.

The attacker compromises the DNS, mapping the domain name in
the redirection URI to the attacker's machine.  The http
request sent by the resource owner's browser to the
redirection uri, which contains the authorization code, is
received by the attacker's machine.  The attacker forwards
the request with the authorization code to the client
application from the attacker's own machine, thereby
impersonating the resource owner.  The client application
mistakenly authenticates the attacker as the resource owner
after verifying that the authorization code is legitimate by
using it to get an access code from the authorization
server.  After the mistaken authentication, the client
application creates a session and gives an authentication
cookie to the attacker.

Let me philosophize a bit.

OAuth was conceived as an authorization protocol, hence the
vocabulary ("authorization server", "resource owner"), but
it has morphed.  Now it is also used for authentication.
When you click on a button "Login with Twitter" or "Login
with Facebook" you are authenticated with OAuth: Twitter and
Facebook do not currently support OpenID for social login.

When OAuth is used for authentication, the authorization
code takes on a different role: posession of the
authorization code is what authenticates the user.
Therefore transmission of the authorization code must be
protected by TLS.

Let me philosophize some more.  (Busy people should stop
reading here ;-)

We need a protocol that does both authentication and
authorization.  We can take OAuth and adapt it for
authentication, or take OpenID and adapt it for
authorization, or combine OpenID and OAuth (great solution
for people who love complexity) or... take the best ideas
from OpenID and OAuth and incorporate them into a new
protocol that's designed from the start for both
authentication and authorization.  That's one of my
motivations for proposing PKAuth.

Now a political speech.

Social login is going to win.  (I use "social login" as
Janrain uses it, I believe they coined the term, is that
right?)  It will win because it has tremendous advantages
not just for users (that's not enough), but also for social
sites and applications.  Once it wins we may get into a
situation where social login with the social identity
provided by the dominant social site (currently Facebook)
becomes the de fact standard for user authentication on the
Web.  If the dominant social site requires application
registration, then every application on the Web will have to
register with the dominant social site just to be able to
authenticate its users, whether or not they have anything to
do with the social site.

The dominant social site would then have to power to kill
any application by terminating its registration.  This would
be an intolerable situation for everybody, including the
dominant social site.  The dominant social site will not
need or want this kind of power, which would call for
government regulation by every government on the planet.

So we need an authentication and authorization protocol
where application registration is optional.  But
registration has an essential function in OAuth.  The social
site relies on registration to be able to reliably identify
the application to the user.  We need a protocol that can
reliably identify unregistered applications to the user.
That's a second motivation for PKAuth.

Francisco

--------------060506000802010302070209-- From torsten@lodderstedt.net Tue Jan 4 14:10:25 2011 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 DBAA13A6C14 for ; Tue, 4 Jan 2011 14:10:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.023, 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 ujOv3k1EFnOB for ; Tue, 4 Jan 2011 14:10:24 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by core3.amsl.com (Postfix) with ESMTP id 8AB393A6BD0 for ; Tue, 4 Jan 2011 14:10:24 -0800 (PST) Received: from [79.253.38.144] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PaF7F-00017U-LU; Tue, 04 Jan 2011 23:12:29 +0100 Message-ID: <4D239B4D.1040009@lodderstedt.net> Date: Tue, 04 Jan 2011 23:12:29 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: fcorella@pomcor.com References: <132020.31505.qm@web55801.mail.re3.yahoo.com> In-Reply-To: <132020.31505.qm@web55801.mail.re3.yahoo.com> Content-Type: multipart/alternative; boundary="------------030306090208040008040403" X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] unregistered applications 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, 04 Jan 2011 22:10:26 -0000 This is a multi-part message in MIME format. --------------030306090208040008040403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Francisco, just to make sure I understood your paper correctly: even native clients are required to have a backend server component, which receives the authorization results and makes it available to the native client? regards, Torsten. > Hi all, > > OAuth provides only weak security when used with > unregistered applications. OTOH compulsory registration is > a bad idea: imagine a situation where a social site becomes > dominant, social login via that site becomes the de facto > authentication standard on the Web, every application has to > register with the site, and the site can kill any > application by revoking its registration. I've written a > paper that proposes a > solution. Thanks in advance for any > comments. > > -- Francisco > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------030306090208040008040403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Francisco,

just to make sure I understood your paper correctly: even native clients are required to have a backend server component, which receives the authorization results and makes it available to the native client?

regards,
Torsten.
Hi all,

OAuth provides only weak security when used with
unregistered applications.  OTOH compulsory registration is
a bad idea: imagine a situation where a social site becomes
dominant, social login via that site becomes the de facto
authentication standard on the Web, every application has to
register with the site, and the site can kill any
application by revoking its registration.  I've written a
paper that proposes a solution.  Thanks in advance for any
comments.

-- Francisco

 

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

--------------030306090208040008040403-- From torsten@lodderstedt.net Tue Jan 4 14:21:07 2011 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 7ED043A6C32 for ; Tue, 4 Jan 2011 14:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.022, 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 JphIaTU+Gvd2 for ; Tue, 4 Jan 2011 14:21:06 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.43]) by core3.amsl.com (Postfix) with ESMTP id 250A33A6C1B for ; Tue, 4 Jan 2011 14:21:05 -0800 (PST) Received: from [79.253.38.144] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PaFHc-0000oS-3U; Tue, 04 Jan 2011 23:23:12 +0100 Message-ID: <4D239DCF.4030501@lodderstedt.net> Date: Tue, 04 Jan 2011 23:23:11 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Marius Scurtescu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension 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, 04 Jan 2011 22:21:07 -0000 +1 I have asked myself all the time why "oob" disappeared in OAuth 2.0? Does Google use this feature? regards, Torsten. Am 29.12.2010 23:53, schrieb Marius Scurtescu: > I would like to propose an OAuth 2 extension that helps native clients > close the loop after the approval page. The extension defines a > special value for the redirect URI for the case when the client does > not have such a URI and it also defines that the authorization server > should provide a default result page for this case and how to format > the result on this page. > > If a native client does not have a redirect URI then the client can > specify the special value "oob" for that parameter. > > redirect_uri=oob signals to the authorization server that it should > use a default result page to show the final result. > > In this case the authorization server cannot redirect any kind of > messages back to the client, not even error responses. > > The default result page should show the authorization code (code) and > instruct the user to copy to native application. > > The default result page should also show both the authorization code > and the passed through client state (state) in the page title, the two > parameters should be form-encoded and appear space separated at the > end of the normal title > > Example page title: > Success code=123456&state=qwerty > > Browsers will truncate the title at some browser and OS dependent > length. Ideally the whole title should be shorter than 100 characters. > The Authorization Server should use a short title prefix and it should > make the authorization codes as short as possible. Native clients > should try to pass very short state strings and only of really needed. > > If the user denies, or there are other errors, the default page should > similarly display the error code and also put the error message in the > title: > Denied error=access_denied&state=qwerty > > References: > * Section 6.3.3.2 of draft-hardt-oauth-wrap-01 > > > If there is interest and rough consensus then I can create a formal > version of this extension. > > > Thanks, > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue Jan 4 14:56:45 2011 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 628083A6A26 for ; Tue, 4 Jan 2011 14:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.447 X-Spam-Level: X-Spam-Status: No, score=-104.447 tagged_above=-999 required=5 tests=[AWL=-1.470, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 aBM1I20qp-oI for ; Tue, 4 Jan 2011 14:56:44 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 83ADB3A6A15 for ; Tue, 4 Jan 2011 14:56:44 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p04MwoFg032491 for ; Tue, 4 Jan 2011 14:58:50 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294181931; bh=A/SwOdnX86Z698ApD4SRbNRYji0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gvP7HrE1L/CY0a5pnrcZe7/TH217gbwzSNI9ZFYqAxf+LlmgZL9S0CTkEYl/HDfnz aQEW1DGixVjrSZINLJVqg== Received: from yie19 (yie19.prod.google.com [10.243.66.19]) by kpbe14.cbf.corp.google.com with ESMTP id p04MwnMS020307 for ; Tue, 4 Jan 2011 14:58:49 -0800 Received: by yie19 with SMTP id 19so3711800yie.3 for ; Tue, 04 Jan 2011 14:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=jS8+rWRAm92eejvoalVi0NwkHgu8irb3Fv7/sqVPylI=; b=G7z/6E9BGjtUZ+5uPo1L8DYECxoRdRs5NolOBxZGL1Req7caaI/DrAwthQEXkAenJY 88boQdVtPWR1mKI5DD5g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=IqMGEkg73jqVV4GdLtTVvhk4BMBeEiVASmKJHWe4eKUkZxnw9lKt7fszV3egyt24AO sHubqwZIu3DvLNyuRs7Q== Received: by 10.100.128.13 with SMTP id a13mr2414859and.235.1294181929189; Tue, 04 Jan 2011 14:58:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.123.14 with HTTP; Tue, 4 Jan 2011 14:58:29 -0800 (PST) In-Reply-To: <4D239DCF.4030501@lodderstedt.net> References: <4D239DCF.4030501@lodderstedt.net> From: Marius Scurtescu Date: Tue, 4 Jan 2011 14:58:29 -0800 Message-ID: To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension 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, 04 Jan 2011 22:56:45 -0000 On Tue, Jan 4, 2011 at 2:23 PM, Torsten Lodderstedt wrote: > +1 > > I have asked myself all the time why "oob" disappeared in OAuth 2.0? Does > Google use this feature? Yes, we are planning to support this, exactly as described in the extension. Marius From fcorella@pomcor.com Tue Jan 4 16:53:39 2011 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 C5F5C3A6DD5 for ; Tue, 4 Jan 2011 16:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, 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 2x1+hInK5yVD for ; Tue, 4 Jan 2011 16:53:38 -0800 (PST) Received: from nm14.bullet.mail.ac4.yahoo.com (nm14.bullet.mail.ac4.yahoo.com [98.139.52.211]) by core3.amsl.com (Postfix) with SMTP id BF3A23A6D3C for ; Tue, 4 Jan 2011 16:53:37 -0800 (PST) Received: from [98.139.52.197] by nm14.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 00:55:41 -0000 Received: from [98.139.52.155] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 00:55:41 -0000 Received: from [127.0.0.1] by omp1038.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 00:55:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 753766.52582.bm@omp1038.mail.ac4.yahoo.com Received: (qmail 29900 invoked by uid 60001); 5 Jan 2011 00:55:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294188941; bh=X5H4J256G8oe75DA2GNBHsTWyDZz3Yp1iPW96W9IDkg=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eaIOMPI4ke/y+y417ns/u4sgsX1PWprABuGKfRwV48DUvEnr+Wytu9WzDmQSaL2eT9LXsetE2zTv8fzyCi/mkG3enm9CYEtjTgFIdSfC4bm0iab8BV3DklEOa3dH9/qKcUKXEU2yw+wP+zTqQIw5Z+RH51xNuOUKIgoBZEhlvWA= Message-ID: <563168.29741.qm@web55806.mail.re3.yahoo.com> X-YMail-OSG: sZSDFL8VM1n0.CDpaEIdX.Fm7FoMndJ9mOAFnVLymAaCHG_ GPAGEZEXziEde7X_pl4Oyy_XWGo6tzskh2pPTRVN4OisUgV..0MT9Bk3zjnu yOYOjuCBxeDY9Mmakkt904QUK_khhJS_OrGCdrsSVY5PnQBmCu8Zfiavc6.g NOykmweB58qkS3E5MoWyJ1rHOW0FLvuu9Di2IJEhTBNHHkiU3aZul.WFDtsv NBkCJ_s7J9KRjVsKGaXckhNNKgNkb1P0Es7lbMfxNSiK9gJVfVw_1K91ynZx rem64ElFKyC0CEVk9w_QvTV2zKzqktd7tqYYX.tASaxBtIhJQAbvqmsjnSTX TOPsPe0HI5iwP0ZW1peVewB9KDPIqwjzxGhjP5bbTlSigcOIRrw9Me5NctcF nYK4Ubgqyi4wW Received: from [67.91.91.101] by web55806.mail.re3.yahoo.com via HTTP; Tue, 04 Jan 2011 16:55:41 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Tue, 4 Jan 2011 16:55:41 -0800 (PST) From: Francisco Corella To: Marius Scurtescu In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-596115854-1294188941=:29741" Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 00:53:39 -0000 --0-596115854-1294188941=:29741 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Tue, 1/4/11, Marius Scurtescu wrote: > > We need a protocol that does both authentication and > > authorization.=A0 We can take OAuth and adapt it for > > authentication, or take OpenID and adapt it for > > authorization, or combine OpenID and OAuth (great solution > > for people who love complexity) or... take the best ideas > > from OpenID and OAuth and incorporate them into a new > > protocol that's designed from the start for both > > authentication and authorization.=A0 That's one of my > > motivations for proposing PKAuth. >=20 > Are you aware of OpenIDConnect? >=20 > http://openidconnect.com/ I stumbled upon that page recently while doing a search, but didn't look at it in any detail because it looked like an abandoned draft, and another complicated combination of OpenID and OAuth. I've looked at it in more detail now, and I've found something interesting.=A0 The last section discusses unregistered applications, and it has a paragraph in italics that addresses the issue of how the server can identify an unregistered application to a user, which is the main issue that I'm trying to address with PKAuth: ---- quote ---- Maybe add client discovery here if the server wants to verify the redirect URL exists and is valid for the domain. Thinking you fetch https://domain/.well-known/host-meta and look for openid:redirect_uri. Also useful to get the client's display name and logo which the server can display to the user. The client would also use host-meta to advertise information needed for web browsers to help manage identity. ---- end of quote ---- In the paper I consider an attacker who owns the domain example.com and hosts an application at pomcor.example.com to trick the user into believing that it belongs to Pomcor. Both OpenID and OAuth will identify the application to the user as "pomcor.example.com" which I argue is not good enough.=A0 But OpenID Connect is much worse!=A0 OpenID Connect will identify the application to the user with a display name and a logo PROVIDED BY THE ATTACKER.=A0 So the attacker can just provide "Pomcor" as the display name and the Pomcor logo and the user is taken in. Francisco --0-596115854-1294188941=:29741 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
--- On Tue, 1/4/11, Marius Scurtescu <mscu= rtescu@google.com> wrote:
> > We need a protocol that does both= authentication and
> > authorization.  We can take OAuth and= adapt it for
> > authentication, or take OpenID and adapt it for<= br>> > authorization, or combine OpenID and OAuth (great solution
= > > for people who love complexity) or... take the best ideas
>= > from OpenID and OAuth and incorporate them into a new
> > pr= otocol that's designed from the start for both
> > authentication = and authorization.  That's one of my
> > motivations for prop= osing PKAuth.
>
> Are you aware of OpenIDConnect?
>
= > http://openidconnect.com/

I stumbled upon that page recently wh= ile doing a search, but
didn't look at it in any detail because it looke= d like an
abandoned draft, and another complicated combination of
Open= ID and OAuth.

I've looked at it in more detail now, and I've foundsomething interesting.  The last section discusses
unregistered a= pplications, and it has a paragraph in italics
that addresses the issue = of how the server can identify an
unregistered application to a user, wh= ich is the main issue
that I'm trying to address with PKAuth:

---= - quote ----
Maybe add client discov= ery here if the server wants to
verify the redirect URL exists and is vali= d for the
domain. Thinking you fetch
https://domain/.well-known/host-meta= and look for
openid:redirect_uri. Also useful to get the client's display
nam= e and logo which the server can display to the user. The
client would also= use host-meta to advertise information
needed for web browsers to help ma= nage identity.
---- end of quote ----

In the paper I consi= der an attacker who owns the domain
example.com and hosts an application= at pomcor.example.com
to trick the user into believing that it belongs = to Pomcor.
Both OpenID and OAuth will identify the application to theuser as "pomcor.example.com" which I argue is not good
enough.  Bu= t OpenID Connect is much worse!  OpenID Connect
will identify the a= pplication to the user with a display
name and a logo PROVIDED BY THE ATTACKER.  So the attacker
can just provide "Pomcor" as the displa= y name and the Pomcor
logo and the user is taken in.

Francisco
--0-596115854-1294188941=:29741-- From fcorella@pomcor.com Tue Jan 4 17:01:55 2011 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 826CB3A6ABD for ; Tue, 4 Jan 2011 17:01:55 -0800 (PST) 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 5hKrmED52cMs for ; Tue, 4 Jan 2011 17:01:53 -0800 (PST) Received: from nm25.bullet.mail.ac4.yahoo.com (nm25.bullet.mail.ac4.yahoo.com [98.139.52.222]) by core3.amsl.com (Postfix) with SMTP id 7FBCD3A679C for ; Tue, 4 Jan 2011 17:01:53 -0800 (PST) Received: from [98.139.52.190] by nm25.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 01:03:58 -0000 Received: from [98.139.52.167] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 01:03:58 -0000 Received: from [127.0.0.1] by omp1050.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 01:03:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 13341.50578.bm@omp1050.mail.ac4.yahoo.com Received: (qmail 88221 invoked by uid 60001); 5 Jan 2011 01:03:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294189437; bh=dOUHE1Rog2X9tpP0a4Rd1T6Uj1HMeCw7Rmm4hi+/VnE=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=thdhbwj+3+dD+zoFUmcSzKF6DCk17K/gOjgXk9eVeMyFNKLaczsMQCHl2QUl104Rg9ujl0clC6JMtiTIpAYJ4AlKlZXS1ndC/5Np2UBcuR37g/Qye4joYz6zVkZA1hE11ofoyyLePd4w3PbyesijauT9tUgUYcOJ7puiF3K+2M0= Message-ID: <891904.87955.qm@web55804.mail.re3.yahoo.com> X-YMail-OSG: ep.g4osVM1k4k0ryhEtUZ0fmufDJo.NI9kdqU2VsW29e7as i05zEAnV5VfHnrk.1BFjWWHO.x8Li_SP2cVIZ9hKbe4yijiKa_WwlcOMjrKF 1LBRrCQLq6_eAyKzhsE5XcYE26UYyIyVQ1ES6nM1G91p9kmRt6cHM_eOMplv zWb5dcNhSLky0ME8Mq3wlnztDchw5gP5DWu0tW36jw913J41_7OoRmtL8vcy 79t2KPGOtqN160yi6CLm7GImaAEh1wt2pSK1I.ZqttizRaY_yJgVgybSfqXK UJNfar66bQj5yoeOnE8nvfLD.N9iw6CeO3S94x6dWO_fy8VIILtnolqlIh8I WHMMCU8Z6n7ahTdmGWunYrtDcGAxCQaD2imw1pmxJMylvG8fi38sTeGRepvd qKGXeeRQ5Wvs- Received: from [67.91.91.101] by web55804.mail.re3.yahoo.com via HTTP; Tue, 04 Jan 2011 17:03:57 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Tue, 4 Jan 2011 17:03:57 -0800 (PST) From: Francisco Corella To: Marius Scurtescu , Justin Richer In-Reply-To: <1294177590.22074.58.camel@pulse> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-172079730-1294189437=:87955" Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 01:01:56 -0000 --0-172079730-1294189437=:87955 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Tue, 1/4/11, Justin Richer wrote: > > > We need a protocol that does both authentication and > > > authorization.=A0 We can take OAuth and adapt it for > > > authentication, or take OpenID and adapt it for > > > authorization, or combine OpenID and OAuth (great > > > solution > > > for people who love complexity) or... take the best > > > ideas > > > from OpenID and OAuth and incorporate them into a new > > > protocol that's designed from the start for both > > > authentication and authorization.=A0 That's one of my > > > motivations for proposing PKAuth. > > > > Are you aware of OpenIDConnect? > > > > http://openidconnect.com/ >=20 > And also the latest drafts of OpenID Artifact Binding: >=20 > http://wiki.openid.net/w/page/12995134/Artifact-Binding I'm not familiar with that, and I haven't been able to find a draft at the site. Francisco --0-172079730-1294189437=:87955 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
--- On Tue, 1/4/11, = Justin Richer <jricher@mitre.org> wrote:
> > > We need a = protocol that does both authentication and
> > > authorization.=   We can take OAuth and adapt it for
> > > authentication,= or take OpenID and adapt it for
> > > authorization, or combin= e OpenID and OAuth (great
> > > solution
> > > for = people who love complexity) or... take the best
> > > ideas
= > > > from OpenID and OAuth and incorporate them into a new
>= ; > > protocol that's designed from the start for both
> > &= gt; authentication and authorization.  That's one of my
> > &= gt; motivations for proposing PKAuth.
> >
> > Are you awa= re of OpenIDConnect?
> >
> > http://openidconnect.com/>
> And also the latest drafts of OpenID Artifact Binding:
> > http://wiki.openid.net/w/page/12995134/Artifact-Binding

I'm n= ot familiar with that, and I haven't been able to find
a draft at the si= te.

Francisco

--0-172079730-1294189437=:87955-- From fcorella@pomcor.com Tue Jan 4 17:16:27 2011 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 9394E3A677D for ; Tue, 4 Jan 2011 17:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.232, 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 g4M89Ej938Ho for ; Tue, 4 Jan 2011 17:16:26 -0800 (PST) Received: from nm26-vm0.bullet.mail.ac4.yahoo.com (nm26-vm0.bullet.mail.ac4.yahoo.com [98.139.52.242]) by core3.amsl.com (Postfix) with SMTP id AB96A3A66B4 for ; Tue, 4 Jan 2011 17:16:26 -0800 (PST) Received: from [98.139.52.196] by nm26.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 01:18:33 -0000 Received: from [98.139.52.169] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 01:18:33 -0000 Received: from [127.0.0.1] by omp1052.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 01:18:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 711078.21645.bm@omp1052.mail.ac4.yahoo.com Received: (qmail 95809 invoked by uid 60001); 5 Jan 2011 01:18:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294190313; bh=PbF+oE8PjF/qVaecz9Ks8qDmlr5w2uBrqKAbYltgnlQ=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EwGK3aXZIu2Y/g1MUGbBVTTbApFeB2XfsydNR1VMBVDcwLUsIzzFmrTasdEuskNrCYNHsEb88XfaneBZr1aaJ+Kdc14yTkJgmCiBrLW9V39b+5Mn18IweIbdpWS98bQIiPzyOlUlgsUhLq1/XL0NAEEvl8kHCA6Ba80xddo4l8g= Message-ID: <590899.88227.qm@web55804.mail.re3.yahoo.com> X-YMail-OSG: _kdH7EAVM1njU3YD6U5GMud3yl9szxvFI8eZOBcsN3XqLPV vWdgHPol8fFNnQc3YTbqXl4IP7GDUPAq2R6uQwJxjV8UIGkOuk25H3M..Z5W lMgJbLGyMI7W76Ovs8A9uVGMbbqaXTsagwvgisYarpA2855bwmHWsmeChGRA WOUFJqZ8gRbTwAnif60JvVdFre0iRO4djzB5B6pmHEU1aMlRqQLFhPy.fD1D fvc1wUDODa6DiTf8IcwjljOhh4U5YH0Hpahr9qZQksKbQMOY.rtIQQUp2UaC hYtRgr3fpK.GarHakANSTmsiVNVHXG538tbZlQfSRHagoO_Lsj0.2g3q8ynF wwzuK4wD8GWprqDxbaAv2q52stNm1EaBPVWyLYOofIGkQO1V5xxC7RyqBCxw HS48- Received: from [67.91.91.101] by web55804.mail.re3.yahoo.com via HTTP; Tue, 04 Jan 2011 17:18:33 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Tue, 4 Jan 2011 17:18:33 -0800 (PST) From: Francisco Corella To: Torsten Lodderstedt In-Reply-To: <4D239B4D.1040009@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-705116037-1294190313=:88227" Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 01:16:27 -0000 --0-705116037-1294190313=:88227 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Tue, 1/4/11, Torsten Lodderstedt wrote: > just to make sure I understood your paper correctly: even > native clients are required to have a backend server > component, which receives the authorization results and > makes it available to the native client? Yes, a very simple one that responds to an http post request by copying the body of the post to the body of the response. (That could be done, for example, by a simple application-independent Apache module.=A0 Apache would be configured to invoke the module for requests that target the redirection uri, and send the response with a media type that is handled by the native client application.)=A0 These days every little neighbourhood store as a Web site, so it is safe to assume that the provider of the native client application has one. Francisco --0-705116037-1294190313=:88227 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
--- On Tue, 1/4/11, Torsten Lodderstedt <t= orsten@lodderstedt.net> wrote:
> just to make sure I understood yo= ur paper correctly: even
> native clients are required to have a back= end server
> component, which receives the authorization results and<= br>> makes it available to the native client?

Yes, a very simple = one that responds to an http post request
by copying the body of the pos= t to the body of the response.
(That could be done, for example, by a si= mple
application-independent Apache module.  Apache would be
con= figured to invoke the module for requests that target the
redirection ur= i, and send the response with a media type
that is handled by the native= client application.)  These
days every little neighbourhood store = as a Web site, so it
is safe to assume that the provider of the native client
application has one.

Francisco

--0-705116037-1294190313=:88227-- From fcorella@pomcor.com Tue Jan 4 17:24:40 2011 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 16F333A677D for ; Tue, 4 Jan 2011 17:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, 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 mNKSMlw2DOtU for ; Tue, 4 Jan 2011 17:24:39 -0800 (PST) Received: from nm20-vm0.bullet.mail.ac4.yahoo.com (nm20-vm0.bullet.mail.ac4.yahoo.com [98.139.53.214]) by core3.amsl.com (Postfix) with SMTP id 16C0A3A66B4 for ; Tue, 4 Jan 2011 17:24:39 -0800 (PST) Received: from [98.139.52.196] by nm20.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 01:26:42 -0000 Received: from [98.139.52.130] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 01:26:42 -0000 Received: from [127.0.0.1] by omp1013.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 01:26:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 864752.74650.bm@omp1013.mail.ac4.yahoo.com Received: (qmail 967 invoked by uid 60001); 5 Jan 2011 01:26:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294190802; bh=BfHxpWtYSNkeGKTLL0j/4EbLWYsEazB7mOqk79duCis=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=usc3BCQM6T1org+tcymDg/oHKxn1sUiNoyC2/ql88RKlSuRcRXjZ1GQgeqTHW7CUvrLzzXl7LsdQMBIspmHNJ0SysK1ZihbpfO4+sdugBRILaVr8iM74PaNJTFKHd1Nhq80ys2bXN7HQkaCNBL7bnaTT7dainkuOASYhnkyokqw= Message-ID: <759694.928.qm@web55804.mail.re3.yahoo.com> X-YMail-OSG: A7w2LBEVM1kAc7tZFTCRPTtQngF1WxkbMrKjxx41E0CzHQs 9AEeamUQukJPPZV0xQyzmxe49zBr27T.T0MB34aLQnIMHwzid4YnVB6P7Nog rZ3p8S6Mhu0jQcCfbttvGWjsG1_x4DiGp.BVOv.sZLEIm.FUvXTbOJshSIbl .ybwIubk9igT92HqCtnoXogh6yBct3Kp9_rTV89aRgI9VhhiNZHQkispz1NG anQCDeyZnanIc.fZEQtF5li3V73cBRVZJNNI41SG3E2PZoyBJ7qNpyTV0Tgc uZsUjuwNyBQeTv05ka_rqCYmPOExqIN8ZZIG8GAepVnq2BQU09Zfl4nDx3qt A0vEgHtI3iGc3PDuIB0oR5_Fr.l2gxuKmKB19jEytcHhRXuTMkjNqR02i.f0 mCvA- Received: from [67.91.91.101] by web55804.mail.re3.yahoo.com via HTTP; Tue, 04 Jan 2011 17:26:42 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Tue, 4 Jan 2011 17:26:42 -0800 (PST) From: Francisco Corella To: Torsten Lodderstedt In-Reply-To: <4D239728.7040902@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1924675890-1294190802=:928" Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 01:24:40 -0000 --0-1924675890-1294190802=:928 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Tue, 1/4/11, Torsten Lodderstedt wrote: > the attack you described sounds very similar to session > fixation attacks. TLS (more specifically server > authentication) is one way to cope with spoofing in general > (supposed the client has a reasonably CA policy). So it > should do in this case, too. Yes, TLS is the solution for both variants of the attack. > Validation of the redirect_uri associated with a particular > authorization code on the tokens endpoint is another way to > detect/prevent such an attack. Supposed the attacker has to > inject the tapped authorization code into the client > application during a second authorization flow. If the > client uses different redirect_uri's for every flow, the > attempt to inject the code can be detected. This I don't understand.=A0 The redirect_uri is alwasy the same... Francisco --0-1924675890-1294190802=:928 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
--- On Tue, 1/4/11, Torsten Lodderstedt <t= orsten@lodderstedt.net> wrote:
> the attack you described sounds v= ery similar to session
> fixation attacks. TLS (more specifically ser= ver
> authentication) is one way to cope with spoofing in general
= > (supposed the client has a reasonably CA policy). So it
> should= do in this case, too.

Yes, TLS is the solution for both variants of= the attack.

> Validation of the redirect_uri associated with a p= articular
> authorization code on the tokens endpoint is another way = to
> detect/prevent such an attack. Supposed the attacker has to
&= gt; inject the tapped authorization code into the client
> applicatio= n during a second authorization flow. If the
> client uses different = redirect_uri's for every flow, the
> attempt to inject the code can b= e detected.

This I don't understand.  The redirect_uri is alwasy= the
same...

Francisco



--0-1924675890-1294190802=:928-- From Michael.Jones@microsoft.com Tue Jan 4 18:29:16 2011 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 5D0773A67E6 for ; Tue, 4 Jan 2011 18:29:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.573 X-Spam-Level: X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.025, 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 t1taceBnzP9O for ; Tue, 4 Jan 2011 18:29:14 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 6A70A3A67E5 for ; Tue, 4 Jan 2011 18:29:14 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 4 Jan 2011 18:31:21 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Tue, 4 Jan 2011 18:31:20 -0800 From: Mike Jones To: "openid-specs-ab@lists.openid.net" , "oauth@ietf.org" Thread-Topic: JSON Web Token (JWT) draft -01 Thread-Index: AcusgKJ+3djISrh8R1G//+yyZSLxUw== Date: Wed, 5 Jan 2011 02:31:20 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246ADB21@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246ADB21TK5EX14MBXC202r_" MIME-Version: 1.0 Cc: "specs@openid.net" Subject: [OAUTH-WG] JSON Web Token (JWT) draft -01 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, 05 Jan 2011 02:29:16 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246ADB21TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft -01 of the JSON Web Token (JWT) specification is now available. This version inco= rporates the consensus decisions reached at the Internet Identity Workshop.= The remaining open issues and to-do items are documented in Section 12. As a r= eminder, the suggested pronunciation of JWT is the same as the English word= "jot". The draft is available at these locations: - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml - http://self-issued.info/docs/draft-jones-json-web-token-01.html - http://self-issued.info/docs/draft-jones-json-web-token-01.txt - http://self-issued.info/docs/draft-jones-json-web-token-01.xml - http://self-issued.info/docs/draft-jones-json-web-token.html (will poin= t to new versions as they are posted) - http://self-issued.info/docs/draft-jones-json-web-token.txt (will point= to new versions as they are posted) - http://self-issued.info/docs/draft-jones-json-web-token.xml (will point= to new versions as they are posted) - http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Subvers= ion repository, with html, txt, and html versions available) The decisions reached at IIW are documented here: - JSON Token Spec Results at IIW: http://self-issued.info/?p=3D361 - JSON Token Encryption Spec Results at IIW: http://self-issued.info/?p= =3D378 - JSON Token Naming Spec Results at IIW: http://self-issued.info/?p=3D38= 6 - JSON Public Key Spec Results at IIW: http://self-issued.info/?p=3D390 This announcement is also posted here: - http://self-issued.info/?p=3D446 Thanks to all who provided the input that led to this draft! Feedback is h= ighly welcome. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943246ADB21TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft -01 of the JSON Web Token (JWT) specification is now available.  This version incorporates the consensus decisions= reached at the Internet Identity Workshop.  The remaining open issues and to-do items are documented in Section 12.  As a reminder, the suggested pronunciation of JWT is = the same as the English word "jot".

 

The draft is available at these locations:

  - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt

  - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml

  - http://self-issued.info/docs/draft-jones-json-web-token-01.html

  - http://self-issued.info/docs/draft-jones-json-web-token-01.txt

  - http://self-issued.info/docs/draft-jones-json-web-token-01.xml

  - http://self-issued.info/docs/draft-jones-json-web-token.html (will poin= t to new versions as they are posted)

  - http://self-issued.info/docs/draft-jones-json-web-token.txt (will point= to new versions as they are posted)

  - http://self-issued.info/docs/draft-jones-json-web-token.xml (will point= to new versions as they are posted)

  - http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Subvers= ion repository, with html, txt, and html versions available)

 

The decisions reached at IIW are documented here:

  - JSON Token Spec Results at IIW:  http://self-issued.info/?p=3D361

  - JSON Token Encryption Spec Results at II= W:  http://self-issued.info/?p=3D378

  - JSON Token Naming Spec Results at IIW:&n= bsp; http://self-issued.info/?p=3D386

  - JSON Public Key Spec Results at IIW:  = http://self-issued.info/?p=3D3= 90

 

This announcement is also posted here:

  - http://self-issued.info/?p=3D446

 

Thanks to all who provided the input that led to thi= s draft!  Feedback is highly welcome.

 

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

--_000_4E1F6AAD24975D4BA5B1680429673943246ADB21TK5EX14MBXC202r_-- From SRS0=TDS6eL=UD=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Tue Jan 4 22:13:27 2011 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 083A73A6A77 for ; Tue, 4 Jan 2011 22:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.627 X-Spam-Level: X-Spam-Status: No, score=-0.627 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 J5FKiLy5EwQ4 for ; Tue, 4 Jan 2011 22:13:26 -0800 (PST) Received: from smtp06.bis7.eu.blackberry.com (smtp06.bis7.eu.blackberry.com [178.239.85.11]) by core3.amsl.com (Postfix) with ESMTP id B8E073A6992 for ; Tue, 4 Jan 2011 22:13:25 -0800 (PST) Received: from b1.c11.bise7.blackberry ([192.168.0.101]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p056FSxL006680; Wed, 5 Jan 2011 06:15:28 GMT Received: from ups31.c11.bise7.blackberry (cmp31.c11.bise7.blackberry [172.18.204.201]) by b1.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p056FRDU000708; Wed, 5 Jan 2011 06:15:27 GMT X-rim-org-msg-ref-id: 882861908 Message-ID: <882861908-1294208127-cardhu_decombobulator_blackberry.rim.net-479628305-@b1.c11.bise7.blackberry> X-Priority: Normal References: <4D239B4D.1040009@lodderstedt.net><590899.88227.qm@web55804.mail.re3.yahoo.com> In-Reply-To: <590899.88227.qm@web55804.mail.re3.yahoo.com> Sensitivity: Normal Importance: Normal To: fcorella@pomcor.com From: torsten@lodderstedt.net Date: Wed, 5 Jan 2011 06:15:23 +0000 Content-Type: multipart/alternative; boundary="part11438-boundary-599445102-1586382467" MIME-Version: 1.0 Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 06:24:48 -0000 --part11438-boundary-599445102-1586382467 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="Windows-1252" VGhlc2UgYWxzbyBtZWFucyB0aGUgYXZhaWxhYmlsdHkgb2YgdGhlIG5hdGl2ZSBhcHAgb24gYSBk ZXZpY2UgZGVwZW5kcyBvbiB0aGUgYXZhaWxhYmlsdHkgb2YgdGhpcyBiYWNrZW5kIHNlcnZpY2Uu IEkgZG9uJ3Qga25vdyB3aGV0aGVyIHRoZSBhdmVyYWdlIHN0b3JlIHdlYnNpdGUgaGFzIGEgcmVh c29uYWJsZSBhdmFpbGFiaWxpdHkuDQoNClJlZ2FyZHMsDQpUb3JzdGVuLg0KDQoNCkdlc2VuZGV0 IG1pdCBCbGFja0JlcnJ5riBXZWJtYWlsIHZvbiBUZWxla29tIERldXRzY2hsYW5kICANCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEZyYW5jaXNjbyBDb3JlbGxhIDxmY29yZWxs YUBwb21jb3IuY29tPg0KRGF0ZTogVHVlLCA0IEphbiAyMDExIDE3OjE4OjMzIA0KVG86IFRvcnN0 ZW4gTG9kZGVyc3RlZHQ8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+DQpSZXBseS1UbzogZmNvcmVs bGFAcG9tY29yLmNvbQ0KQ2M6IDxvYXV0aEBpZXRmLm9yZz47IEthcmVuIFAuIExld2lzb248a3Bs ZXdpc29uQHBvbWNvci5jb20+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSB1bnJlZ2lzdGVyZWQg YXBwbGljYXRpb25zDQoNCi0tLSBPbiBUdWUsIDEvNC8xMSwgVG9yc3RlbiBMb2RkZXJzdGVkdCA8 dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KPiBqdXN0IHRvIG1ha2Ugc3VyZSBJIHVu ZGVyc3Rvb2QgeW91ciBwYXBlciBjb3JyZWN0bHk6IGV2ZW4NCj4gbmF0aXZlIGNsaWVudHMgYXJl IHJlcXVpcmVkIHRvIGhhdmUgYSBiYWNrZW5kIHNlcnZlcg0KPiBjb21wb25lbnQsIHdoaWNoIHJl Y2VpdmVzIHRoZSBhdXRob3JpemF0aW9uIHJlc3VsdHMgYW5kDQo+IG1ha2VzIGl0IGF2YWlsYWJs ZSB0byB0aGUgbmF0aXZlIGNsaWVudD8NCg0KWWVzLCBhIHZlcnkgc2ltcGxlIG9uZSB0aGF0IHJl c3BvbmRzIHRvIGFuIGh0dHAgcG9zdCByZXF1ZXN0DQpieSBjb3B5aW5nIHRoZSBib2R5IG9mIHRo ZSBwb3N0IHRvIHRoZSBib2R5IG9mIHRoZSByZXNwb25zZS4NCihUaGF0IGNvdWxkIGJlIGRvbmUs IGZvciBleGFtcGxlLCBieSBhIHNpbXBsZQ0KYXBwbGljYXRpb24taW5kZXBlbmRlbnQgQXBhY2hl IG1vZHVsZS6gIEFwYWNoZSB3b3VsZCBiZQ0KY29uZmlndXJlZCB0byBpbnZva2UgdGhlIG1vZHVs ZSBmb3IgcmVxdWVzdHMgdGhhdCB0YXJnZXQgdGhlDQpyZWRpcmVjdGlvbiB1cmksIGFuZCBzZW5k IHRoZSByZXNwb25zZSB3aXRoIGEgbWVkaWEgdHlwZQ0KdGhhdCBpcyBoYW5kbGVkIGJ5IHRoZSBu YXRpdmUgY2xpZW50IGFwcGxpY2F0aW9uLimgIFRoZXNlDQpkYXlzIGV2ZXJ5IGxpdHRsZSBuZWln aGJvdXJob29kIHN0b3JlIGFzIGEgV2ViIHNpdGUsIHNvIGl0DQppcyBzYWZlIHRvIGFzc3VtZSB0 aGF0IHRoZSBwcm92aWRlciBvZiB0aGUgbmF0aXZlIGNsaWVudA0KYXBwbGljYXRpb24gaGFzIG9u ZS4NCg0KRnJhbmNpc2NvDQoNCg0K --part11438-boundary-599445102-1586382467 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="Windows-1252" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4gPGh0bWw+PGhlYWQ+IDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYt OCIgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIj4gPC9oZWFkPlRoZXNlIGFsc28gbWVhbnMgdGhl IGF2YWlsYWJpbHR5IG9mIHRoZSBuYXRpdmUgYXBwIG9uIGEgZGV2aWNlIGRlcGVuZHMgb24gdGhl IGF2YWlsYWJpbHR5IG9mIHRoaXMgYmFja2VuZCBzZXJ2aWNlLiBJIGRvbid0IGtub3cgd2hldGhl ciB0aGUgYXZlcmFnZSBzdG9yZSB3ZWJzaXRlIGhhcyBhIHJlYXNvbmFibGUgYXZhaWxhYmlsaXR5 Ljxici8+PGJyLz5SZWdhcmRzLDxici8+VG9yc3Rlbi48YnIvPjxici8+PHA+R2VzZW5kZXQgbWl0 IEJsYWNrQmVycnmuIFdlYm1haWwgdm9uIFRlbGVrb20gRGV1dHNjaGxhbmQgIDwvcD48aHIvPjxk aXY+PGI+RnJvbTogPC9iPiBGcmFuY2lzY28gQ29yZWxsYSAmbHQ7ZmNvcmVsbGFAcG9tY29yLmNv bSZndDsNCjwvZGl2PjxkaXY+PGI+RGF0ZTogPC9iPlR1ZSwgNCBKYW4gMjAxMSAxNzoxODozMyAt MDgwMCAoUFNUKTwvZGl2PjxkaXY+PGI+VG86IDwvYj5Ub3JzdGVuIExvZGRlcnN0ZWR0Jmx0O3Rv cnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0OzwvZGl2PjxkaXY+PGI+UmVwbHlUbzogPC9iPiBmY29y ZWxsYUBwb21jb3IuY29tDQo8L2Rpdj48ZGl2PjxiPkNjOiA8L2I+Jmx0O29hdXRoQGlldGYub3Jn Jmd0OzsgS2FyZW4gUC4gTGV3aXNvbiZsdDtrcGxld2lzb25AcG9tY29yLmNvbSZndDs8L2Rpdj48 ZGl2PjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSB1bnJlZ2lzdGVyZWQgYXBwbGljYXRp b25zPC9kaXY+PGRpdj48YnIvPjwvZGl2Pjx0YWJsZSBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRp bmc9IjAiIGJvcmRlcj0iMCIgPjx0cj48dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJmb250OiBpbmhl cml0OyI+LS0tIE9uIFR1ZSwgMS80LzExLCBUb3JzdGVuIExvZGRlcnN0ZWR0ICZsdDt0b3JzdGVu QGxvZGRlcnN0ZWR0Lm5ldCZndDsgd3JvdGU6PGJyPiZndDsganVzdCB0byBtYWtlIHN1cmUgSSB1 bmRlcnN0b29kIHlvdXIgcGFwZXIgY29ycmVjdGx5OiBldmVuPGJyPiZndDsgbmF0aXZlIGNsaWVu dHMgYXJlIHJlcXVpcmVkIHRvIGhhdmUgYSBiYWNrZW5kIHNlcnZlcjxicj4mZ3Q7IGNvbXBvbmVu dCwgd2hpY2ggcmVjZWl2ZXMgdGhlIGF1dGhvcml6YXRpb24gcmVzdWx0cyBhbmQ8YnI+Jmd0OyBt YWtlcyBpdCBhdmFpbGFibGUgdG8gdGhlIG5hdGl2ZSBjbGllbnQ/PGJyPjxicj5ZZXMsIGEgdmVy eSBzaW1wbGUgb25lIHRoYXQgcmVzcG9uZHMgdG8gYW4gaHR0cCBwb3N0IHJlcXVlc3Q8YnI+Ynkg Y29weWluZyB0aGUgYm9keSBvZiB0aGUgcG9zdCB0byB0aGUgYm9keSBvZiB0aGUgcmVzcG9uc2Uu PGJyPihUaGF0IGNvdWxkIGJlIGRvbmUsIGZvciBleGFtcGxlLCBieSBhIHNpbXBsZTxicj5hcHBs aWNhdGlvbi1pbmRlcGVuZGVudCBBcGFjaGUgbW9kdWxlLiZuYnNwOyBBcGFjaGUgd291bGQgYmU8 YnI+Y29uZmlndXJlZCB0byBpbnZva2UgdGhlIG1vZHVsZSBmb3IgcmVxdWVzdHMgdGhhdCB0YXJn ZXQgdGhlPGJyPnJlZGlyZWN0aW9uIHVyaSwgYW5kIHNlbmQgdGhlIHJlc3BvbnNlIHdpdGggYSBt ZWRpYSB0eXBlPGJyPnRoYXQgaXMgaGFuZGxlZCBieSB0aGUgbmF0aXZlIGNsaWVudCBhcHBsaWNh dGlvbi4pJm5ic3A7IFRoZXNlPGJyPmRheXMgZXZlcnkgbGl0dGxlIG5laWdoYm91cmhvb2Qgc3Rv cmUgYXMgYSBXZWIgc2l0ZSwgc28gaXQ8YnI+aXMgc2FmZSB0byBhc3N1bWUgdGhhdCB0aGUgcHJv dmlkZXIgb2YgdGhlIG5hdGl2ZQ0KIGNsaWVudDxicj5hcHBsaWNhdGlvbiBoYXMgb25lLjxicj48 YnI+RnJhbmNpc2NvPGJyPjxicj48L3RkPjwvdHI+PC90YWJsZT4NCjwvaHRtbD4= --part11438-boundary-599445102-1586382467-- From SRS0=TDS6eL=UD=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Tue Jan 4 22:14:59 2011 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 A1BB73A6992 for ; Tue, 4 Jan 2011 22:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.671 X-Spam-Level: X-Spam-Status: No, score=-0.671 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] 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 dAfn1BfPSSXu for ; Tue, 4 Jan 2011 22:14:58 -0800 (PST) Received: from smtp03.bis7.eu.blackberry.com (smtp03.bis7.eu.blackberry.com [178.239.85.8]) by core3.amsl.com (Postfix) with ESMTP id 1A8413A6A77 for ; Tue, 4 Jan 2011 22:14:57 -0800 (PST) Received: from b1.c11.bise7.blackberry ([192.168.0.101]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p056H3Jd006071; Wed, 5 Jan 2011 06:17:03 GMT Received: from ups31.c11.bise7.blackberry (cmp31.c11.bise7.blackberry [172.18.204.201]) by b1.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p056H3ts000773; Wed, 5 Jan 2011 06:17:03 GMT X-rim-org-msg-ref-id: 2024287148 Message-ID: <2024287148-1294208223-cardhu_decombobulator_blackberry.rim.net-151514922-@b1.c11.bise7.blackberry> X-Priority: Normal References: <4D239728.7040902@lodderstedt.net><759694.928.qm@web55804.mail.re3.yahoo.com> In-Reply-To: <759694.928.qm@web55804.mail.re3.yahoo.com> Sensitivity: Normal Importance: Normal To: fcorella@pomcor.com From: torsten@lodderstedt.net Date: Wed, 5 Jan 2011 06:17:02 +0000 Content-Type: multipart/alternative; boundary="part11385-boundary-922126345-1370296547" MIME-Version: 1.0 Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 06:24:59 -0000 --part11385-boundary-922126345-1370296547 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="Windows-1252" VGhlIGNsaWVudCBjb3VsZCBqdXN0IGFkZCBhbm90aGVyIHJhbmRvbSBzdHJpbmcgd2l0aCBldmVy eSBhdXRob3JpemF0aW9uIHJlcXVlc3QuDQoNClJlZ2FyZHMsDQpUb3JzdGVuLg0KDQoNCkdlc2Vu ZGV0IG1pdCBCbGFja0JlcnJ5riBXZWJtYWlsIHZvbiBUZWxla29tIERldXRzY2hsYW5kICANCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEZyYW5jaXNjbyBDb3JlbGxhIDxmY29y ZWxsYUBwb21jb3IuY29tPg0KRGF0ZTogVHVlLCA0IEphbiAyMDExIDE3OjI2OjQyIA0KVG86IFRv cnN0ZW4gTG9kZGVyc3RlZHQ8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+DQpSZXBseS1UbzogZmNv cmVsbGFAcG9tY29yLmNvbQ0KQ2M6IDxvYXV0aEBpZXRmLm9yZz47IEthcmVuIFAuIExld2lzb248 a3BsZXdpc29uQHBvbWNvci5jb20+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBUTFMgaXMgbmVl ZGVkIGZvciByZWRpcmVjdGluZyBiYWNrIHRvIHRoZSBjbGllbnQNCg0KLS0tIE9uIFR1ZSwgMS80 LzExLCBUb3JzdGVuIExvZGRlcnN0ZWR0IDx0b3JzdGVuQGxvZGRlcnN0ZWR0Lm5ldD4gd3JvdGU6 DQo+IHRoZSBhdHRhY2sgeW91IGRlc2NyaWJlZCBzb3VuZHMgdmVyeSBzaW1pbGFyIHRvIHNlc3Np b24NCj4gZml4YXRpb24gYXR0YWNrcy4gVExTIChtb3JlIHNwZWNpZmljYWxseSBzZXJ2ZXINCj4g YXV0aGVudGljYXRpb24pIGlzIG9uZSB3YXkgdG8gY29wZSB3aXRoIHNwb29maW5nIGluIGdlbmVy YWwNCj4gKHN1cHBvc2VkIHRoZSBjbGllbnQgaGFzIGEgcmVhc29uYWJseSBDQSBwb2xpY3kpLiBT byBpdA0KPiBzaG91bGQgZG8gaW4gdGhpcyBjYXNlLCB0b28uDQoNClllcywgVExTIGlzIHRoZSBz b2x1dGlvbiBmb3IgYm90aCB2YXJpYW50cyBvZiB0aGUgYXR0YWNrLg0KDQo+IFZhbGlkYXRpb24g b2YgdGhlIHJlZGlyZWN0X3VyaSBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyDQo+IGF1dGhv cml6YXRpb24gY29kZSBvbiB0aGUgdG9rZW5zIGVuZHBvaW50IGlzIGFub3RoZXIgd2F5IHRvDQo+ IGRldGVjdC9wcmV2ZW50IHN1Y2ggYW4gYXR0YWNrLiBTdXBwb3NlZCB0aGUgYXR0YWNrZXIgaGFz IHRvDQo+IGluamVjdCB0aGUgdGFwcGVkIGF1dGhvcml6YXRpb24gY29kZSBpbnRvIHRoZSBjbGll bnQNCj4gYXBwbGljYXRpb24gZHVyaW5nIGEgc2Vjb25kIGF1dGhvcml6YXRpb24gZmxvdy4gSWYg dGhlDQo+IGNsaWVudCB1c2VzIGRpZmZlcmVudCByZWRpcmVjdF91cmkncyBmb3IgZXZlcnkgZmxv dywgdGhlDQo+IGF0dGVtcHQgdG8gaW5qZWN0IHRoZSBjb2RlIGNhbiBiZSBkZXRlY3RlZC4NCg0K VGhpcyBJIGRvbid0IHVuZGVyc3RhbmQuoCBUaGUgcmVkaXJlY3RfdXJpIGlzIGFsd2FzeSB0aGUN CnNhbWUuLi4NCg0KRnJhbmNpc2NvDQoNCg0KDQoNCg== --part11385-boundary-922126345-1370296547 Content-Transfer-Encoding: base64 Content-Type: text/html; charset="Windows-1252" PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4gPGh0bWw+PGhlYWQ+IDxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYt OCIgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIj4gPC9oZWFkPlRoZSBjbGllbnQgY291bGQganVz dCBhZGQgYW5vdGhlciByYW5kb20gc3RyaW5nIHdpdGggZXZlcnkgYXV0aG9yaXphdGlvbiByZXF1 ZXN0Ljxici8+PGJyLz5SZWdhcmRzLDxici8+VG9yc3Rlbi48YnIvPjxici8+PHA+R2VzZW5kZXQg bWl0IEJsYWNrQmVycnmuIFdlYm1haWwgdm9uIFRlbGVrb20gRGV1dHNjaGxhbmQgIDwvcD48aHIv PjxkaXY+PGI+RnJvbTogPC9iPiBGcmFuY2lzY28gQ29yZWxsYSAmbHQ7ZmNvcmVsbGFAcG9tY29y LmNvbSZndDsNCjwvZGl2PjxkaXY+PGI+RGF0ZTogPC9iPlR1ZSwgNCBKYW4gMjAxMSAxNzoyNjo0 MiAtMDgwMCAoUFNUKTwvZGl2PjxkaXY+PGI+VG86IDwvYj5Ub3JzdGVuIExvZGRlcnN0ZWR0Jmx0 O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0OzwvZGl2PjxkaXY+PGI+UmVwbHlUbzogPC9iPiBm Y29yZWxsYUBwb21jb3IuY29tDQo8L2Rpdj48ZGl2PjxiPkNjOiA8L2I+Jmx0O29hdXRoQGlldGYu b3JnJmd0OzsgS2FyZW4gUC4gTGV3aXNvbiZsdDtrcGxld2lzb25AcG9tY29yLmNvbSZndDs8L2Rp dj48ZGl2PjxiPlN1YmplY3Q6IDwvYj5SZTogW09BVVRILVdHXSBUTFMgaXMgbmVlZGVkIGZvciBy ZWRpcmVjdGluZyBiYWNrIHRvIHRoZSBjbGllbnQ8L2Rpdj48ZGl2Pjxici8+PC9kaXY+PHRhYmxl IGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYm9yZGVyPSIwIiA+PHRyPjx0ZCB2YWxp Z249InRvcCIgc3R5bGU9ImZvbnQ6IGluaGVyaXQ7Ij4tLS0gT24gVHVlLCAxLzQvMTEsIFRvcnN0 ZW4gTG9kZGVyc3RlZHQgJmx0O3RvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Jmd0OyB3cm90ZTo8YnI+ Jmd0OyB0aGUgYXR0YWNrIHlvdSBkZXNjcmliZWQgc291bmRzIHZlcnkgc2ltaWxhciB0byBzZXNz aW9uPGJyPiZndDsgZml4YXRpb24gYXR0YWNrcy4gVExTIChtb3JlIHNwZWNpZmljYWxseSBzZXJ2 ZXI8YnI+Jmd0OyBhdXRoZW50aWNhdGlvbikgaXMgb25lIHdheSB0byBjb3BlIHdpdGggc3Bvb2Zp bmcgaW4gZ2VuZXJhbDxicj4mZ3Q7IChzdXBwb3NlZCB0aGUgY2xpZW50IGhhcyBhIHJlYXNvbmFi bHkgQ0EgcG9saWN5KS4gU28gaXQ8YnI+Jmd0OyBzaG91bGQgZG8gaW4gdGhpcyBjYXNlLCB0b28u PGJyPjxicj5ZZXMsIFRMUyBpcyB0aGUgc29sdXRpb24gZm9yIGJvdGggdmFyaWFudHMgb2YgdGhl IGF0dGFjay48YnI+PGJyPiZndDsgVmFsaWRhdGlvbiBvZiB0aGUgcmVkaXJlY3RfdXJpIGFzc29j aWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXI8YnI+Jmd0OyBhdXRob3JpemF0aW9uIGNvZGUgb24gdGhl IHRva2VucyBlbmRwb2ludCBpcyBhbm90aGVyIHdheSB0bzxicj4mZ3Q7IGRldGVjdC9wcmV2ZW50 IHN1Y2ggYW4gYXR0YWNrLiBTdXBwb3NlZCB0aGUgYXR0YWNrZXIgaGFzIHRvPGJyPiZndDsgaW5q ZWN0IHRoZSB0YXBwZWQgYXV0aG9yaXphdGlvbiBjb2RlIGludG8gdGhlIGNsaWVudDxicj4mZ3Q7 IGFwcGxpY2F0aW9uIGR1cmluZyBhIHNlY29uZCBhdXRob3JpemF0aW9uIGZsb3cuIElmIHRoZTxi cj4mZ3Q7IGNsaWVudCB1c2VzIGRpZmZlcmVudCByZWRpcmVjdF91cmkncyBmb3IgZXZlcnkgZmxv dywgdGhlPGJyPiZndDsgYXR0ZW1wdCB0byBpbmplY3QgdGhlIGNvZGUgY2FuIGJlDQogZGV0ZWN0 ZWQuPGJyPjxicj5UaGlzIEkgZG9uJ3QgdW5kZXJzdGFuZC4mbmJzcDsgVGhlIHJlZGlyZWN0X3Vy aSBpcyBhbHdhc3kgdGhlPGJyPnNhbWUuLi48YnI+PGJyPkZyYW5jaXNjbzxicj48YnI+PGJyPjxi cj48L3RkPjwvdHI+PC90YWJsZT4NCjwvaHRtbD4= --part11385-boundary-922126345-1370296547-- From SRS0=TDS6eL=UD=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Tue Jan 4 22:27:26 2011 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 C6D783A6992 for ; Tue, 4 Jan 2011 22:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753] 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 9kfTwQUwy2fB for ; Tue, 4 Jan 2011 22:27:23 -0800 (PST) Received: from smtp08.bis7.eu.blackberry.com (smtp08.bis7.eu.blackberry.com [178.239.85.13]) by core3.amsl.com (Postfix) with ESMTP id 932D33A6B83 for ; Tue, 4 Jan 2011 22:27:22 -0800 (PST) Received: from b1.c11.bise7.blackberry ([192.168.0.101]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p056TS6r010482; Wed, 5 Jan 2011 06:29:28 GMT Received: from ups31.c11.bise7.blackberry (cmp31.c11.bise7.blackberry [172.18.204.201]) by b1.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p056TRtc001986; Wed, 5 Jan 2011 06:29:27 GMT X-rim-org-msg-ref-id: 631506689 Message-ID: <631506689-1294208967-cardhu_decombobulator_blackberry.rim.net-988667093-@b1.c11.bise7.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <4D239B4D.1040009@lodderstedt.net><590899.88227.qm@web55804.mail.re3.yahoo.com><882861908-1294208127-cardhu_decombobulator_blackberry.rim.net-479628305-@b1.c11.bise7.blackberry> In-Reply-To: <882861908-1294208127-cardhu_decombobulator_blackberry.rim.net-479628305-@b1.c11.bise7.blackberry> Sensitivity: Normal Importance: Normal To: "Lodderstedt, Torsten" , fcorella@pomcor.com From: torsten@lodderstedt.net Date: Wed, 5 Jan 2011 06:29:21 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 06:27:26 -0000 QW5vdGhlciBxdWVzdGlvbjogaG93IGRvZXMgdGhlIHNlcnZlciB2YWxpZGF0ZSB0aGUgaWRlbnRp dHkvYXV0aGVudGljaXR5IG9mIHRoZSBjbGllbnQ/IEluIG90aGVyIHdvcmRzLCB3aGF0IGRvZXMg YSBtYWxpY2lvdXMgYXBwIHByZXZlbnQgZnJvbSB1c2luZyB0aGUgVVJMIGFuZCBzZXJ2ZXIgb2Yg YW5vdGhlciBuYXRpdmUgYXBwPw0KDQpSZWdhcmRzLA0KVG9yc3Rlbi4NCkdlc2VuZGV0IG1pdCBC bGFja0JlcnJ5riBXZWJtYWlsIHZvbiBUZWxla29tIERldXRzY2hsYW5kICANCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0DQpTZW5kZXI6 IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcNCkRhdGU6IFdlZCwgNSBKYW4gMjAxMSAwNjoxNToyMyAN ClRvOiA8ZmNvcmVsbGFAcG9tY29yLmNvbT4NClJlcGx5LVRvOiB0b3JzdGVuQGxvZGRlcnN0ZWR0 Lm5ldA0KQ2M6IDxvYXV0aEBpZXRmLm9yZz47IEthcmVuIFAuIExld2lzb248a3BsZXdpc29uQHBv bWNvci5jb20+DQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSB1bnJlZ2lzdGVyZWQgYXBwbGljYXRp b25zDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpP QXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== From Michael.Jones@microsoft.com Wed Jan 5 09:16:22 2011 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 C47993A6CC6 for ; Wed, 5 Jan 2011 09:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.575 X-Spam-Level: X-Spam-Status: No, score=-10.575 tagged_above=-999 required=5 tests=[AWL=0.023, 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 ZU75yuuU-Lzp for ; Wed, 5 Jan 2011 09:16:20 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 6951F3A6C69 for ; Wed, 5 Jan 2011 09:16:20 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 5 Jan 2011 09:18:27 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0255.003; Wed, 5 Jan 2011 09:18:26 -0800 From: Mike Jones To: "fcorella@pomcor.com" , Marius Scurtescu , Justin Richer Thread-Topic: [OAUTH-WG] TLS is needed for redirecting back to the client Thread-Index: AQHLq9ZdC+ZaAffX60WS2Y2mu2GPZpPA8BQAgADqtACAAALSAIAAAoYAgAA3K4CAAIj/EA== Date: Wed, 5 Jan 2011 17:18:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246AE7AD@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <1294177590.22074.58.camel@pulse> <891904.87955.qm@web55804.mail.re3.yahoo.com> In-Reply-To: <891904.87955.qm@web55804.mail.re3.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246AE7ADTK5EX14MBXC202r_" MIME-Version: 1.0 Cc: John Bradley , "oauth@ietf.org" , "Nat Sakimura \(nat@sakimura.org\)" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client 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, 05 Jan 2011 17:16:22 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246AE7ADTK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You can read about the Artifact Binding at https://bitbucket.org/openid/ab/= wiki/Home. The latest draft is at https://bitbucket.org/openid/ab/raw/c1ea= ac175dc8/openid-artifact-binding-1_0.html. Nat Sakimura is actively updati= ng the specification as we speak, incorporating some of the ideas from Open= ID Connect. The merger of the specs that Nat is working on is sometimes re= ferred to as OpenID Artifact Binding/Connect or OpenID ABC for short. FYI,= specification will be using JSON Web Tokens (JWTs). -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of F= rancisco Corella Sent: Tuesday, January 04, 2011 5:04 PM To: Marius Scurtescu; Justin Richer Cc: oauth@ietf.org; Karen P. Lewison Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client --- On Tue, 1/4/11, Justin Richer > wrote: > > > We need a protocol that does both authentication and > > > authorization. We can take OAuth and adapt it for > > > authentication, or take OpenID and adapt it for > > > authorization, or combine OpenID and OAuth (great > > > solution > > > for people who love complexity) or... take the best > > > ideas > > > from OpenID and OAuth and incorporate them into a new > > > protocol that's designed from the start for both > > > authentication and authorization. That's one of my > > > motivations for proposing PKAuth. > > > > Are you aware of OpenIDConnect? > > > > http://openidconnect.com/ > > And also the latest drafts of OpenID Artifact Binding: > > http://wiki.openid.net/w/page/12995134/Artifact-Binding I'm not familiar with that, and I haven't been able to find a draft at the site. Francisco --_000_4E1F6AAD24975D4BA5B1680429673943246AE7ADTK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You can read about the Ar= tifact Binding at https://bitbucket.org= /openid/ab/wiki/Home.  The latest draft is at https://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_= 0.html.  Nat Sakimura is actively updating the specification as we= speak, incorporating some of the ideas from OpenID Connect.  The merg= er of the specs that Nat is working on is sometimes referred to as OpenID Artifact Binding/Connect or OpenID ABC for= short.  FYI, specification will be using JSON Web Tokens (JWTs).=

 <= /p>

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

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Francisco Corella
Sent: Tuesday, January 04, 2011 5:04 PM
To: Marius Scurtescu; Justin Richer
Cc: oauth@ietf.org; Karen P. Lewison
Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the cl= ient

 

--- On Tue, 1/4/11, J= ustin Richer <jricher@mitre.org= > wrote:
> > > We need a protocol that does both authentication and
> > > authorization.  We can take OAuth and adapt it for
> > > authentication, or take OpenID and adapt it for
> > > authorization, or combine OpenID and OAuth (great
> > > solution
> > > for people who love complexity) or... take the best
> > > ideas
> > > from OpenID and OAuth and incorporate them into a new
> > > protocol that's designed from the start for both
> > > authentication and authorization.  That's one of my
> > > motivations for proposing PKAuth.
> >
> > Are you aware of OpenIDConnect?
> >
> > http://openidconnect.com/
>
> And also the latest drafts of OpenID Artifact Binding:
>
> ht= tp://wiki.openid.net/w/page/12995134/Artifact-Binding

I'm not familiar with that, and I haven't been able to find
a draft at the site.

Francisco

 

--_000_4E1F6AAD24975D4BA5B1680429673943246AE7ADTK5EX14MBXC202r_-- From eran@hueniverse.com Wed Jan 5 10:24:24 2011 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 56D423A6C17 for ; Wed, 5 Jan 2011 10:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, 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 m8UEHrFuvu3d for ; Wed, 5 Jan 2011 10:24:23 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6D5BE3A6BE9 for ; Wed, 5 Jan 2011 10:24:23 -0800 (PST) Received: (qmail 16725 invoked from network); 5 Jan 2011 18:26:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 5 Jan 2011 18:26:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 5 Jan 2011 11:26:27 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 5 Jan 2011 11:26:22 -0700 Thread-Topic: Final cuts and 3 interoperable implementations Thread-Index: AcutBa0rYZve5SscSSevtm+B1K8YbA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445328CB1D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445328CB1D7P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Final cuts and 3 interoperable implementations 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, 05 Jan 2011 18:24:24 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445328CB1D7P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the next few weeks I plan to survey existing and planned implementations= of each feature of the specification and those components without at least= 3 interoperable (or compliant) implementations will be a candidate for rem= oval from the specification (can still be published as an extension). The g= oal is to publish a specification which has complete code coverage. I shoul= d strive to produce a specification that is grounded in actual deployment p= lans, not just projected theory. If you (or your company) are implementing or plan to, please let me know so= I can include you in the survey. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445328CB1D7P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the next few = weeks I plan to survey existing and planned implementations of each feature= of the specification and those components without at least 3 interoperable= (or compliant) implementations will be a candidate for removal from the sp= ecification (can still be published as an extension). The goal is to publis= h a specification which has complete code coverage. I should strive to prod= uce a specification that is grounded in actual deployment plans, not just p= rojected theory.

 

If you (or your company) are implementing or plan to, pl= ease let me know so I can include you in the survey.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723445328CB1D7P3PW5EX1MB01E_-- From fcorella@pomcor.com Wed Jan 5 11:22:04 2011 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 6696E3A6C17 for ; Wed, 5 Jan 2011 11:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.155, 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 pfn0VG6XeaDx for ; Wed, 5 Jan 2011 11:22:03 -0800 (PST) Received: from nm1-vm0.bullet.mail.ac4.yahoo.com (nm1-vm0.bullet.mail.ac4.yahoo.com [98.139.53.202]) by core3.amsl.com (Postfix) with SMTP id D4FFE3A681C for ; Wed, 5 Jan 2011 11:22:02 -0800 (PST) Received: from [98.139.52.190] by nm1.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 19:24:07 -0000 Received: from [98.139.52.175] by tm3.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 19:24:07 -0000 Received: from [127.0.0.1] by omp1058.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 19:24:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 187498.53454.bm@omp1058.mail.ac4.yahoo.com Received: (qmail 93376 invoked by uid 60001); 5 Jan 2011 19:24:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294255447; bh=vBu9w4+Ao5egBGj1zn+1ZJXL8U+KKzg8tZ/vtzqzIjw=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=OmR3SNFKAMsaiQChoHyo0q0Xe5x8lrw09CujIhGPZUNEjUBlo+R26TjIvtWzMsJrqaiMhayP+P9deq+oIx7xvtin3D4uEiYSQoia4+BnhbZbq1Quk9ZfRJhQkvCmCRkSmVdMPvcsR7iORWbVJDl4b2a4zRi9A68Qz8gm4MKn67Q= Message-ID: <55603.90714.qm@web55807.mail.re3.yahoo.com> X-YMail-OSG: ZrSDMMwVM1lZYX7MbqYPUkCNC6oc26y90qic3jJHjCPirWu sqqud5S8PE9xY.woTsMfhS69uQ6DvPNXrEUxaukiQZAMfCVrvooc0oEvU1ha qXIxuMlT3OKOixNC17f_sL5ye_G9_eNGPNp6mmfDrJHFZ2.p_68odLgO8q5i FO8pm_six0zNLlxmTI4HvdHtb8WvP1_fcRQxzUcsjajDM1oCcproNteCdd2p aXXws4y58kglxpf7bB2dksMxdUHcnqv3naL9WYb3ChS8iwrzV3qKlwU37fqS RFtj4a66vdiq_Px_VMr3K_M114VLILpMUdcA57xeuJHQJNfsK9H.7eL3n_MG 9AZ7EE4t2QAwosb3uVBZDiT305wxwNtuU5i9eJNQ0ADw3fjjaLzK6KEh38Xl s5Kk- Received: from [67.91.91.101] by web55807.mail.re3.yahoo.com via HTTP; Wed, 05 Jan 2011 11:24:06 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Wed, 5 Jan 2011 11:24:06 -0800 (PST) From: Francisco Corella To: torsten@lodderstedt.net In-Reply-To: <631506689-1294208967-cardhu_decombobulator_blackberry.rim.net-988667093-@b1.c11.bise7.blackberry> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-427138480-1294255446=:90714" Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 19:22:04 -0000 --0-427138480-1294255446=:90714 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Torsten, > Another question: how does the server validate the > identity/authenticity of the client? In other words, what > does a malicious app prevent from using the URL and server > of another native app? Let me rephrase your question (correct me if I'm wrong): can a malicious native app obtain an authcode that the user has granted to a legitimate native app, by using the ancillary server of the legitimate app?=A0 The answer is yes, but only if the user installs the malcious app on his/her own machine, in which case there can be no security.=A0 The authcode is downloaded to the browser that was used for user authentication, and it is delivered by the browser to an application running on the same machine. (From an earlier message...) > These also means the availabilty of the native app on a > device depends on the availabilty of this backend service. I > don't know whether the average store website has a > reasonable availability. Availability is not a problem these days.=A0 We use virtual servers=20 on the Amazon cloud, which are very cheap, and availability is=20 practically 100%. Regards, Francisco --0-427138480-1294255446=:90714 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Torsten,

>= Another question: how does the server validate the
> identity/authen= ticity of the client? In other words, what
> does a malicious app pre= vent from using the URL and server
> of another native app?

Le= t me rephrase your question (correct me if I'm wrong): can
a malicious n= ative app obtain an authcode that the user has
granted to a legitimate n= ative app, by using the ancillary
server of the legitimate app?  Th= e answer is yes, but only
if the user installs the malcious app on his/h= er own
machine, in which case there can be no security.  The
aut= hcode is downloaded to the browser that was used for user
authentication= , and it is delivered by the browser to an
application running on the sa= me machine.

(From an earlier message...)
> These also means th= e availabilty of the native app on a
> device depends on the availabil= ty of this backend service. I
> don't know whether the average store = website has a
> reasonable availability.

Availability is not a= problem these days.  We use virtual servers
on the Amazon cloud, = which are very cheap, and availability is
practically 100%.

Rega= rds,

Francisco

--0-427138480-1294255446=:90714-- From torsten@lodderstedt.net Wed Jan 5 13:16:30 2011 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 060483A6CD9 for ; Wed, 5 Jan 2011 13:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[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 kN5aUOvxE+tK for ; Wed, 5 Jan 2011 13:16:29 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by core3.amsl.com (Postfix) with ESMTP id D21BE3A6B8E for ; Wed, 5 Jan 2011 13:16:28 -0800 (PST) Received: from [87.142.251.161] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Paakb-0008Hw-TA; Wed, 05 Jan 2011 22:18:33 +0100 Message-ID: <4D24E029.4040401@lodderstedt.net> Date: Wed, 05 Jan 2011 22:18:33 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: fcorella@pomcor.com References: <55603.90714.qm@web55807.mail.re3.yahoo.com> In-Reply-To: <55603.90714.qm@web55807.mail.re3.yahoo.com> Content-Type: multipart/alternative; boundary="------------080402050706060009040607" X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications 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, 05 Jan 2011 21:16:30 -0000 This is a multi-part message in MIME format. --------------080402050706060009040607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Francisco, > Torsten, > > > Another question: how does the server validate the > > identity/authenticity of the client? In other words, what > > does a malicious app prevent from using the URL and server > > of another native app? > > Let me rephrase your question (correct me if I'm wrong): can > a malicious native app obtain an authcode that the user has > granted to a legitimate native app, by using the ancillary > server of the legitimate app? The answer is yes, but only > if the user installs the malcious app on his/her own > machine, in which case there can be no security. The > authcode is downloaded to the browser that was used for user > authentication, and it is delivered by the browser to an > application running on the same machine. > Agreed. So what is then the benefit of the approach you proposed with respect to native apps? > > (From an earlier message...) > > These also means the availabilty of the native app on a > > device depends on the availabilty of this backend service. I > > don't know whether the average store website has a > > reasonable availability. > > Availability is not a problem these days. We use virtual servers > on the Amazon cloud, which are very cheap, and availability is > practically 100%. > Good point. Nevertheless, it is an extra burden to the developer of an native app. regards, Torsten. > > Regards, > > Francisco > --------------080402050706060009040607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Francisco,
Torsten,

> Another question: how does the server validate the
> identity/authenticity of the client? In other words, what
> does a malicious app prevent from using the URL and server
> of another native app?

Let me rephrase your question (correct me if I'm wrong): can
a malicious native app obtain an authcode that the user has
granted to a legitimate native app, by using the ancillary
server of the legitimate app?  The answer is yes, but only
if the user installs the malcious app on his/her own
machine, in which case there can be no security.  The
authcode is downloaded to the browser that was used for user
authentication, and it is delivered by the browser to an
application running on the same machine.

Agreed. So what is then the benefit of the approach you proposed with respect to native apps? 


(From an earlier message...)
> These also means the availabilty of the native app on a
> device depends on the availabilty of this backend service. I
> don't know whether the average store website has a
> reasonable availability.

Availability is not a problem these days.  We use virtual servers
on the Amazon cloud, which are very cheap, and availability is
practically 100%.

Good point. Nevertheless, it is an extra burden to the developer of an native app.

regards,
Torsten.


Regards,

Francisco

--------------080402050706060009040607-- From fcorella@pomcor.com Wed Jan 5 14:53:33 2011 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 279B33A6D0E for ; Wed, 5 Jan 2011 14:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.133, 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 em+R0VJHh-cs for ; Wed, 5 Jan 2011 14:53:28 -0800 (PST) Received: from nm22-vm0.bullet.mail.ac4.yahoo.com (nm22-vm0.bullet.mail.ac4.yahoo.com [98.139.53.218]) by core3.amsl.com (Postfix) with SMTP id 9878E3A6C5E for ; Wed, 5 Jan 2011 14:53:26 -0800 (PST) Received: from [98.139.52.189] by nm22.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 22:55:31 -0000 Received: from [98.139.52.155] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 22:55:30 -0000 Received: from [127.0.0.1] by omp1038.mail.ac4.yahoo.com with NNFMP; 05 Jan 2011 22:55:30 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 855618.23605.bm@omp1038.mail.ac4.yahoo.com Received: (qmail 66857 invoked by uid 60001); 5 Jan 2011 22:55:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294268130; bh=p0rOJw0M00NnAQSozlSLpHCGvVltK2V8QDyo7foKRTs=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ld2syNZcRJS68RIok6fA/cOShK22MXnJg921CUr8og93Fa/FQuusMb8HV0JaL9D13KAN8NEubtFI/Qxo+lZyOQ3ztsSrgOJDebP0bHYR5aBpY248nhJeImiD79X2TTWUlSSbuskqffWtW++iBWtPvcESNE9KQKWYJO2EhCCFG4E= Message-ID: <665253.59119.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: hkRjcNwVM1kdKfrAN.zy43xL4B4Hs0qPu106i3IRbUMpEpE ugrlF1.xF37RQ0PT3nUfFhqznjveUn5IHNcuTFi1SFIrKDpfrMqtRnCA.iie 3IitVKbo54teNIUI.nzt4nfJxdG1wJ0Q84LXywwET_qre57LOzedNM7NQww3 C7ZHsr627TrDthwwvPT2hgY4Ly__g4IgyjBVYpIteEW1uzK5LBHCYUZZbzWK Li9kprXA57iXlTyAPZ.zJiZsqMog9RuH.sHtFF5qRtEAt.UILa20AvHqyJnr E2vSff9LjjsWmLsP_zvGUaAMtUrCuKIiDBOJzLWYW1r3k66l.qZr.hO86ERd hAWGCUsTRhNQIc9_.CLv7eCdNJTd_Anz7oHVgyE6edmZ2fmXvbdMoUPLzN.C FFcI- Received: from [67.91.91.101] by web55801.mail.re3.yahoo.com via HTTP; Wed, 05 Jan 2011 14:55:30 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Wed, 5 Jan 2011 14:55:30 -0800 (PST) From: Francisco Corella To: Torsten Lodderstedt In-Reply-To: <4D24E029.4040401@lodderstedt.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1519920983-1294268130=:59119" Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2011 22:53:33 -0000 --0-1519920983-1294268130=:59119 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Torsten, > Agreed. So what is then the benefit of the approach you > proposed with respect to native apps?=20 Do you mean why didn't I just choose one of the approaches in section 2.3 or the OAuth spec?=A0 Here is what the spec says: (now quoting from the spec) > Native application clients can be implemented in different > ways based on their requirements and desired end-user > experience.=A0 Native application clients can: >=20 > o Utilize the end-user authorization endpoint as described in > Section 4 by launching an external user-agent.=A0 The > client can capture the response by providing a > redirection URI with a custom URI scheme (registered > with the operating system to invoke the client > application),=20 This seems to be saying that the user's machine has a Web server running on it which is reachable from the Internet by sending an http request to the redirection URI.=A0 That's unrealistic because the user's machine won't typically have a permanent IP address reachable from the internet. > or by providing a redirection URI > pointing to a server-hosted resource under the > client's control=20 That's what you are objecting to. > which makes the response available to > the client (e.g. using the window title or other > locations accessible from outside the user-agent). This is not pretty (besides the fact that is uses an ancillary server). > o Utilize the end-user authorization endpoint as described in > Section 4 by using an embedded user-agent.=A0 The client > obtains the response by directly communicating with the > embedded user-agent. With this method the application can sniff the user's credentials when the user authenticates to the authorization server, since it controls the embedded agent.=A0 So this method does not meet the original goal of OAuth, which was to not give the user's credentials to the client application; whereas the method used in PKAuth does. > Prompt end-users for their password and use them directly to > obtain an access token.=A0 This is generally discouraged, as > it hands the end-user's password directly to the third-party > client which in turn has to store it in clear-text.=A0 It also > requires the server to support password-based > authentication. Again, this fails to meet the original goal of OAuth. Regards, Francisco --0-1519920983-1294268130=:59119 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Torsten,

> Agreed. So what is then = the benefit of the approach you
> proposed with respect to native app= s?

Do you mean why didn't I just choose one of the approaches
in= section 2.3 or the OAuth spec?  Here is what the spec
says:
(now quoting from the spec)

> Native application clients can be = implemented in different
> ways based on their requirements and desir= ed end-user
> experience.  Native application clients can:
&g= t;
> o Utilize the end-user authorization endpoint as described in> Section 4 by launching an external user-agent.  The
> cli= ent can capture the response by providing a
> redirection URI with a = custom URI scheme (registered
> with the operating system to invoke t= he client
> application),

This seems to be saying that the user's machine has a Web
server running on it which is reachable from t= he Internet by
sending an http request to the redirection URI.  Tha= t's
unrealistic because the user's machine won't typically have
a per= manent IP address reachable from the internet.

> or by providing = a redirection URI
> pointing to a server-hosted resource under the> client's control

That's what you are objecting to.

>= ; which makes the response available to
> the client (e.g. using the = window title or other
> locations accessible from outside the user-ag= ent).

This is not pretty (besides the fact that is uses an
ancill= ary server).

> o Utilize the end-user authorization endpoint as d= escribed in
> Section 4 by using an embedded user-agent.  The cl= ient
> obtains the response by directly communicating with the
>= ; embedded user-agent.

With this method the application can sniff the user's
credentials when the user authenticates to the authori= zation
server, since it controls the embedded agent.  So this
me= thod does not meet the original goal of OAuth, which was
to not give the= user's credentials to the client
application; whereas the method used i= n PKAuth does.

> Prompt end-users for their password and use them= directly to
> obtain an access token.  This is generally discou= raged, as
> it hands the end-user's password directly to the third-pa= rty
> client which in turn has to store it in clear-text.  It al= so
> requires the server to support password-based
> authentica= tion.

Again, this fails to meet the original goal of OAuth.

R= egards,

Francisco

--0-1519920983-1294268130=:59119-- From mscurtescu@google.com Wed Jan 5 15:12:10 2011 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 021513A6CD9 for ; Wed, 5 Jan 2011 15:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.489 X-Spam-Level: X-Spam-Status: No, score=-104.489 tagged_above=-999 required=5 tests=[AWL=-2.512, 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 pQW8IvUkhpSz for ; Wed, 5 Jan 2011 15:12:09 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id EAD743A6E23 for ; Wed, 5 Jan 2011 15:12:08 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p05NEEv2031241 for ; Wed, 5 Jan 2011 15:14:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294269255; bh=MIjrdsF9YhHV+fvmXMG6iYM6EDE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=HAQbMXAYXi0NGsbXmBrnruTrt3WvmdRHvKpNHi6dzuXiaYBYVgAofvgunonbzBbwh /bDgB8CMY+4pWiW0//izQ== Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by wpaz9.hot.corp.google.com with ESMTP id p05NEDW6028527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 5 Jan 2011 15:14:13 -0800 Received: by ywo7 with SMTP id 7so6637848ywo.9 for ; Wed, 05 Jan 2011 15:14:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=WQ4j4djNEfP53tGFo0xULIH1gzOQe06zmpAtVXO8KFI=; b=x71B4L5ie+xejKHgUm9BoNQ6DmZTjiWRBVfsu3kriMDXsv1932LKVbLOnxYjWMU8iE yunS9EdTapCC3QJJyD8w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=GgYI06KBXhArZU6/8T4sRmBG1Abxz1X7WqmA/C8bychT0FXYFVvSd5NsQBTglxn+Ne 97rCKA54zK0jmCGfYQjg== Received: by 10.100.128.13 with SMTP id a13mr3179906and.235.1294269253136; Wed, 05 Jan 2011 15:14:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.123.14 with HTTP; Wed, 5 Jan 2011 15:13:53 -0800 (PST) In-Reply-To: <665253.59119.qm@web55801.mail.re3.yahoo.com> References: <4D24E029.4040401@lodderstedt.net> <665253.59119.qm@web55801.mail.re3.yahoo.com> From: Marius Scurtescu Date: Wed, 5 Jan 2011 15:13:53 -0800 Message-ID: To: fcorella@pomcor.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications 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, 05 Jan 2011 23:12:10 -0000 On Wed, Jan 5, 2011 at 2:55 PM, Francisco Corella wro= te: > > > Native application clients can be implemented in different > > ways based on their requirements and desired end-user > > experience.=A0 Native application clients can: > > > > o Utilize the end-user authorization endpoint as described in > > Section 4 by launching an external user-agent.=A0 The > > client can capture the response by providing a > > redirection URI with a custom URI scheme (registered > > with the operating system to invoke the client > > application), > > This seems to be saying that the user's machine has a Web > server running on it which is reachable from the Internet by > sending an http request to the redirection URI.=A0 That's > unrealistic because the user's machine won't typically have > a permanent IP address reachable from the internet. For custom schemes you don't need a local web server. You can also use a local web server, no routable/permanent IP is needed. The authorization server can redirect to localhost perfectly fine. Marius From fcorella@pomcor.com Wed Jan 5 16:14:29 2011 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 26A413A6DC6 for ; Wed, 5 Jan 2011 16:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.116, 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 rEPz5ZaBruhg for ; Wed, 5 Jan 2011 16:14:27 -0800 (PST) Received: from nm21-vm0.bullet.mail.ac4.yahoo.com (nm21-vm0.bullet.mail.ac4.yahoo.com [98.139.53.216]) by core3.amsl.com (Postfix) with SMTP id 67E9D3A6D79 for ; Wed, 5 Jan 2011 16:14:27 -0800 (PST) Received: from [98.139.52.195] by nm21.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 00:16:31 -0000 Received: from [98.139.52.171] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 00:16:31 -0000 Received: from [127.0.0.1] by omp1054.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 00:16:31 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 810392.91194.bm@omp1054.mail.ac4.yahoo.com Received: (qmail 68635 invoked by uid 60001); 6 Jan 2011 00:16:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294272991; bh=FRiOg5bYAJ1XkSRJ0Cn5KwV4tOxnoP+k2OFJ/Ucxqxc=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Im1gkn7742wKXz3g64IkdFhUVFttQ50VSQZFFYX/dEcw2v9tFZfWw5VbHsaZtd8WUzT7mxUovQh88E9oIJ2tptzRPLoIvAlu+qViVwwh05GjtUo4Cnl6iVMpZu6xsrKWeU49IKUSMYjIXepAuFf8xHOfCDcZ3t/kNbA96WqPtoY= Message-ID: <685598.65613.qm@web55808.mail.re3.yahoo.com> X-YMail-OSG: 4Dj6W_kVM1lr.O6KnY5ocCGpn49hTKnXIaGaQnOLfV84SRS lndIbbTALb8_6k7Dd2PxcOIMKfUGpc9iHKVyhKCyRutOCmq0_MTiSf0CJyNe Jxp_6mVXhNfNXXOuVOwt3VGuKo0hGv.pWbN.DQT363ZTiviWNKuuvIESNqLh QLl1D8I6v1VO_go6TdXe3w3Q139U3Fx6QPs4qVq6Imm7TvsOLR7m5xi4bRN2 .G1noa1pH3aZNc81v1DC_2rYZJDzfj0Av2LvmbVuKhjfYauhNi1PBIeahLF. FWCZEa2xHvwQu6XCI_VS13lZEMYAzr33nJdiI93God5jg_kGMm59q6sIsmYj l6IL2tPJvJv.wkj17TkLRy4IUzFaDcaMTFfbs1A353Jv2FqwIIdNtWewyvVb g6xnuwiVaYg0W Received: from [67.91.91.101] by web55808.mail.re3.yahoo.com via HTTP; Wed, 05 Jan 2011 16:16:31 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Wed, 5 Jan 2011 16:16:31 -0800 (PST) From: Francisco Corella To: Marius Scurtescu , Justin Richer , Mike Jones In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246AE7AD@TK5EX14MBXC202.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-258972712-1294272991=:65613" Cc: John Bradley , "oauth@ietf.org" , "Nat Sakimura \(nat@sakimura.org\)" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 00:14:29 -0000 --0-258972712-1294272991=:65613 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Mike, Thank you very much for sending the links to the artifact binding home page= and spec.=A0 I've had a quick look, and maybe I'm missing something, but i= t seems that this completely ignores the problem of authenticating the rely= ing party.=A0 In section 7.4.1, the RP registers on the fly just by telling= the OP who it claims to be, and the OP takes the RP's word for it without = any verification and issues a client_secret.=A0 Same as OpenID Connect. OpenID 2.0 at least goes to the trouble of asking the user whether he/she t= rusts the realm, and then verifying the return_url against the realm.=A0 I = don't think that's sufficient, but it's better than nothing. Francisco --- On Wed, 1/5/11, Mike Jones wrote: From: Mike Jones Subject: RE: [OAUTH-WG] TLS is needed for redirecting back to the client To: "fcorella@pomcor.com" , "Marius Scurtescu" , "Justin Richer" Cc: "oauth@ietf.org" , "Karen P. Lewison" , "Nat Sakimura (nat@sakimura.org)" , "John Bradley"= Date: Wednesday, January 5, 2011, 5:18 PM =0A=0A =0A =0A=0A=0AYou can read about the Artifact Binding at=0Ahttps://bi= tbucket.org/openid/ab/wiki/Home.=A0 The latest draft is at=0A=0Ahttps://bit= bucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_0.html.=A0 = Nat Sakimura is actively updating the specification as we speak, incorporat= ing some of the ideas from OpenID Connect.=A0 The merger of the specs that = Nat is working on is=0A sometimes referred to as OpenID Artifact Binding/Co= nnect or OpenID ABC for short.=A0 FYI, specification will be using JSON Web= Tokens (JWTs). =0A =A0 =0A=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike = =0A =A0 =0AFrom: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=0AO= n Behalf Of Francisco Corella =0ASent: Tuesday, January 04, 2011 5:04 PM =0ATo: Marius Scurtescu; Justin Richer =0ACc: oauth@ietf.org; Karen P. Lewison =0ASubject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client= =0A =A0 =0A=0A=0A=0A=0A=0A--- On Tue, 1/4/11, Justin Richer wrote: =0A> > > We need a protocol that does both authentication and =0A> > > authorization.=A0 We can take OAuth and adapt it for =0A> > > authentication, or take OpenID and adapt it for =0A> > > authorization, or combine OpenID and OAuth (great =0A> > > solution =0A> > > for people who love complexity) or... take the best =0A> > > ideas =0A> > > from OpenID and OAuth and incorporate them into a new =0A> > > protocol that's designed from the start for both =0A> > > authentication and authorization.=A0 That's one of my =0A> > > motivations for proposing PKAuth. =0A> > =0A> > Are you aware of OpenIDConnect? =0A> > =0A> > http://openidconnect.com/ =0A>=20 =0A> And also the latest drafts of OpenID Artifact Binding: =0A>=20 =0A> http://wiki.openid.net/w/page/12995134/Artifact-Binding =0A =0AI'm not familiar with that, and I haven't been able to find =0Aa draft at the site. =0A =0AFrancisco =0A=0A=0A=0A=0A=0A =A0 =0A=0A =0A --0-258972712-1294272991=:65613 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Mike,

Thank you very much for sending = the links to the artifact binding home page and spec.  I've had a quic= k look, and maybe I'm missing something, but it seems that this completely = ignores the problem of authenticating the relying party.  In section 7= .4.1, the RP registers on the fly just by telling the OP who it claims to b= e, and the OP takes the RP's word for it without any verification and issue= s a client_secret.  Same as OpenID Connect.

OpenID 2.0 at least= goes to the trouble of asking the user whether he/she trusts the realm, an= d then verifying the return_url against the realm.  I don't think that= 's sufficient, but it's better than nothing.

Francisco

--- On= Wed, 1/5/11, Mike Jones <Michael.Jones@microsoft.com> = wrote:

From: Mike Jones <Michael.Jon= es@microsoft.com>
Subject: RE: [OAUTH-WG] TLS is needed for redirecti= ng back to the client
To: "fcorella@pomcor.com" <fcorella@pomcor.com&= gt;, "Marius Scurtescu" <mscurtescu@google.com>, "Justin Richer" <= jricher@mitre.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>, "Kare= n P. Lewison" <kplewison@pomcor.com>, "Nat Sakimura (nat@sakimura.org= )" <nat@sakimura.org>, "John Bradley" <ve7jtb@ve7jtb.com>
Da= te: Wednesday, January 5, 2011, 5:18 PM

=0A= =0A =0A =0A=0A
=0A

You can read about the Artifact Bi= nding at=0Ahttps://bitbucket.org/openid/ab/wiki/Home.&nbs= p; The latest draft is at=0A=0Ahttps://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-= binding-1_0.html.  Nat Sakimura is actively updating the specifica= tion as we speak, incorporating some of the ideas from OpenID Connect. = ; The merger of the specs that Nat is working on is=0A sometimes referred t= o as OpenID Artifact Binding/Connect or OpenID ABC for short.  FYI, sp= ecification will be using JSON Web Tokens (JWTs).

=0A

 

=0A

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

=0A

 

=0A

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=0AOn Behalf = Of Francisco Corella
=0ASent: Tuesday, January 04, 2011 5:04 = PM
=0ATo: Marius Scurtescu; Justin Richer
=0ACc: oauth@= ietf.org; Karen P. Lewison
=0ASubject: Re: [OAUTH-WG] TLS is need= ed for redirecting back to the client

=0A

 

=0A=0A=0A=0A=0A=0A=0A
=0A
=0A

--- On Tue, 1/4/11, Justin Richer <<= a rel=3D"nofollow" ymailto=3D"mailto:jricher@mitre.org" target=3D"_blank" h= ref=3D"/mc/compose?to=3Djricher@mitre.org">jricher@mitre.org> wrote:=
=0A> > > We need a protocol that does both authentication and<= br>=0A> > > authorization.  We can take OAuth and adapt it fo= r
=0A> > > authentication, or take OpenID and adapt it for
= =0A> > > authorization, or combine OpenID and OAuth (great
=0A&= gt; > > solution
=0A> > > for people who love complexity)= or... take the best
=0A> > > ideas
=0A> > > from O= penID and OAuth and incorporate them into a new
=0A> > > protoc= ol that's designed from the start for both
=0A> > > authenticat= ion and authorization.  That's one of my
=0A> > > motivati= ons for proposing PKAuth.
=0A> >
=0A> > Are you aware of = OpenIDConnect?
=0A> >
=0A> > http://openidconnect.com/
=0A>
=0A> And also the latest drafts of OpenID Artifact Bind= ing:
=0A>
=0A> http://wiki.openid.= net/w/page/12995134/Artifact-Binding
=0A
=0AI'm not familiar with= that, and I haven't been able to find
=0Aa draft at the site.
=0A=0AFrancisco

=0A
=0A
=0A

 =

=0A
=0A =0A
--0-258972712-1294272991=:65613-- From fcorella@pomcor.com Wed Jan 5 18:59:13 2011 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 9EE0E3A6E5D for ; Wed, 5 Jan 2011 18:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.426, 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 IgDgZAZQKElf for ; Wed, 5 Jan 2011 18:59:12 -0800 (PST) Received: from nm2.bullet.mail.ac4.yahoo.com (nm2.bullet.mail.ac4.yahoo.com [98.139.52.199]) by core3.amsl.com (Postfix) with SMTP id 8C0DC3A6E57 for ; Wed, 5 Jan 2011 18:59:12 -0800 (PST) Received: from [98.139.52.194] by nm2.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 03:01:16 -0000 Received: from [98.139.52.180] by tm7.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 03:01:16 -0000 Received: from [127.0.0.1] by omp1063.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 03:01:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 711819.82260.bm@omp1063.mail.ac4.yahoo.com Received: (qmail 88429 invoked by uid 60001); 6 Jan 2011 03:01:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294282876; bh=PcPXEFpsGf3z+8aSlDfWXpaIYvTs9gGDET8d90e7PJ8=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=C4SjF32VJjPj42WMqc9Fk3cBjDJSVuJpmKhHwl/4hr7KBA27LOlAb8cmi+ode9F7jjz5iUIm6bPktLo9c6pjpBSF0+WX+lk7kl51yLtyH60govrRu/CtQxmK3zMDm6UpEMK0vLLZlqYqIKzwFVMB5yBniw9XuHb+Wz9AToXmqi4= Message-ID: <602164.87035.qm@web55804.mail.re3.yahoo.com> X-YMail-OSG: 4_Nzt.YVM1k5ZGLBCRqQEYUbb0lVSpPwQf5urNSc3PtxAeV kUJa6VnUkEm.n9HyZUZc.cjX97rJhEjvcmfNwZKYw5GOwPgGqbkHQkT1Y1y5 503JmpmI18gXiFxyxW7J2RhhXcBNZp6_n8fhY51U_LrpEFc.rgI74MwofEh2 wEHm7_b2gB.MOPOLOyZk3wwU3ds946E5EaJ7k2CCGnShYjUg1oEAHcGJ25mG cwlo1vTejJ2zGDbZJirMB_HZPKPxn0n5K0FM3NbVmGN2chSONRM9xp.BE2.9 psIGp2gsUGS6rk39cQ99wydH5JVQcl8GYCPLueaajS5oBIgO9xzy9q7SizmT 6YrsAa7BlOp30HRBpW4awdEtbEb6S5jue3WfW5HaXBWS1Zv.qa7nycQIs7Id oykcqXPppV6ZO Received: from [174.65.103.16] by web55804.mail.re3.yahoo.com via HTTP; Wed, 05 Jan 2011 19:01:16 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Wed, 5 Jan 2011 19:01:16 -0800 (PST) From: Francisco Corella To: Marius Scurtescu In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1222109850-1294282876=:87035" Cc: oauth@ietf.org, "Karen P. Lewison" Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 02:59:13 -0000 --0-1222109850-1294282876=:87035 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --- On Wed, 1/5/11, Marius Scurtescu wrote: > > This seems to be saying that the user's machine has a Web > > server running on it which is reachable from the Internet by > > sending an http request to the redirection URI.=A0 That's > > unrealistic because the user's machine won't typically have > > a permanent IP address reachable from the internet. >=20 > For custom schemes you don't need a local web server. >=20 > You can also use a local web server, no routable/permanent IP is > needed. The authorization server can redirect to localhost perfectly > fine. Ah, ok.=A0 I'm not familiar with custom schemes, but I do understand that you can redirect to localhost.=A0 Thanks for the explanation. Francisco --0-1222109850-1294282876=:87035 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --0-1222109850-1294282876=:87035-- From dick.hardt@gmail.com Wed Jan 5 19:07:06 2011 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 155B43A6896 for ; Wed, 5 Jan 2011 19:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U53Se4CeUR0 for ; Wed, 5 Jan 2011 19:07:05 -0800 (PST) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 086D03A67E3 for ; Wed, 5 Jan 2011 19:07:05 -0800 (PST) Received: by pxi6 with SMTP id 6so3752524pxi.31 for ; Wed, 05 Jan 2011 19:09:12 -0800 (PST) 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:message-id:references:to :x-mailer; bh=PKRqGZ61G/xYwuIUq1Tw1Ls5f6zjnZwFuk4vUxVgjeU=; b=cmSE9rmLZIPCGg9fW+y+oUpKDmFF07ru2I7n4CMhc+XEBMP9FqJuGGGA1yuBwrUSdS gpX5iIxgUv17cBFE6bNZ3T1UYtT8/hFnbL5ySg+xJTcNgunuDDukupd1Lnl8odIEGGw3 bSYz98CGxpjM0s/Zuo8iQ/u4s7J2NQNK/aDEI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=C/3IdOYtJqXR0WQMgFim3Q0xT6c8IcqQfAYCj0zgA62jdTVjbzWAmZFWMqY5xUyddQ riB7IlJ9W/TqPQMU/l2MfbOXgcEv9YKxxSpuoqPi17Kd76KOrnK4i1WeZGqslNgRL4U2 WPFpJbjARIZdUAw/i2uRT7mq8h0Fkk4AKMdr8= Received: by 10.142.113.6 with SMTP id l6mr342671wfc.99.1294283351861; Wed, 05 Jan 2011 19:09:11 -0800 (PST) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id o1sm447628wfl.14.2011.01.05.19.09.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 05 Jan 2011 19:09:09 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-21-296051050 From: Dick Hardt In-Reply-To: <602164.87035.qm@web55804.mail.re3.yahoo.com> Date: Wed, 5 Jan 2011 19:09:07 -0800 Message-Id: <5899D82E-89C0-44A4-8DD3-0DBDAE63CFEB@gmail.com> References: <602164.87035.qm@web55804.mail.re3.yahoo.com> To: fcorella@pomcor.com X-Mailer: Apple Mail (2.1082) Cc: "Karen P. Lewison" , oauth@ietf.org Subject: Re: [OAUTH-WG] unregistered applications 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, 06 Jan 2011 03:07:06 -0000 --Apple-Mail-21-296051050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2011-01-05, at 7:01 PM, Francisco Corella wrote: > --- On Wed, 1/5/11, Marius Scurtescu wrote: > > > This seems to be saying that the user's machine has a Web > > > server running on it which is reachable from the Internet by > > > sending an http request to the redirection URI. That's > > > unrealistic because the user's machine won't typically have > > > a permanent IP address reachable from the internet. > >=20 > > For custom schemes you don't need a local web server. > >=20 > > You can also use a local web server, no routable/permanent IP is > > needed. The authorization server can redirect to localhost perfectly > > fine. >=20 > Ah, ok. I'm not familiar with custom schemes, but I do > understand that you can redirect to localhost. Thanks for > the explanation. An example of a custom scheme would be what Pounce popularized on the = iPhone.=20 A redirect to pounce:// would load the Pounce app and pass in the URL -- Dick= --Apple-Mail-21-296051050 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
--- On Wed, 1/5/11, Marius Scurtescu <mscu= rtescu@google.com> wrote:
> > This seems to be saying that the = user's machine has a Web
> > server running on it which is reachab= le from the Internet by
> > sending an http request to the redirec= tion URI.  That's
> > unrealistic because the user's machine = won't typically have
> > a permanent IP address reachable from the= internet.
>
> For custom schemes you don't need a local web s= erver.
>
> You can also use a local web server, no routable/pe= rmanent IP is
> needed. The authorization server can redirect to loca= lhost perfectly
> fine.

Ah, ok.  I'm not familiar with cu= stom schemes, but I do
understand that you can redirect to localhost.&nb= sp; Thanks for
the explanation.

Francisco

--- On Wed, 1/5/11, Marius Scurtescu <mscurtescu@google.com> = wrote:
> > This seems to be saying that the user's machine has = a Web
> > server running on it which is reachable from the = Internet by
> > sending an http request to the redirection = URI.  That's
> > unrealistic because the user's machine = won't typically have
> > a permanent IP address reachable from = the internet.
>
> For custom schemes you don't need a local = web server.
>
> You can also use a local web server, no = routable/permanent IP is
> needed. The authorization server can = redirect to localhost perfectly
> fine.

Ah, ok.  I'm = not familiar with custom schemes, but I do
understand that you can = redirect to localhost.  Thanks for
the = explanation.

An = example of a custom scheme would be what Pounce popularized on the = iPhone. 
A redirect to pounce:// would load the Pounce = app and pass in the URL

-- = Dick
= --Apple-Mail-21-296051050-- From fcorella@pomcor.com Thu Jan 6 13:30:13 2011 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 ABAA73A6F4B for ; Thu, 6 Jan 2011 13:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, 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 CSncJyqXbD7o for ; Thu, 6 Jan 2011 13:30:12 -0800 (PST) Received: from nm11.bullet.mail.ac4.yahoo.com (nm11.bullet.mail.ac4.yahoo.com [98.139.52.208]) by core3.amsl.com (Postfix) with SMTP id 935433A6F47 for ; Thu, 6 Jan 2011 13:30:07 -0800 (PST) Received: from [98.139.52.189] by nm11.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 21:32:11 -0000 Received: from [98.139.52.174] by tm2.bullet.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 21:32:11 -0000 Received: from [127.0.0.1] by omp1057.mail.ac4.yahoo.com with NNFMP; 06 Jan 2011 21:32:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 370619.30020.bm@omp1057.mail.ac4.yahoo.com Received: (qmail 58121 invoked by uid 60001); 6 Jan 2011 21:32:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1294349531; bh=g7+idQ6re4CWLladeQhh0J45XIiD2uEyJCY75Fjf/+E=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=KwuPGPa78SXUt0xiRUilQrnyLO+Z/n4ojyXJ/yje0ZTVxHIaF+InJJMofgXmpEPvyQ95TJI6KzkyMMcEvb5dmYFkhpV2hyYIsVfayldCTfL/o0HVOOD6JjRUFPRgQGPbbX4lAP4UDB8PeCm0QOmyyHmyBhC/+L5OIY2ii0aG1v8= Message-ID: <257581.52754.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: mJxSyNIVM1kpMH_daWmVKO6CC.BAUXIyboWtOm7ItWA9FCg mTIySM_81sZosyhOmBbq6T2.tCdjHhGQQOc3LkeVVrCeI_7L39UoR75EGx0I jnUxtVPzEq6qicbQDQCk2b82e59r4rd0wPms2M7cTcxGBFvrc9JmFl7OQvRM 5A88mlHGAICArqF30U0.3kMuxQyn60ZmsNB_nNVTJK00RrPh.rhb675cojBE y8Bgz2B9NBAVsKk_g.0Mas_0OaF5bSS.OBEO6.WQ_7kgKrMxKoU2QjB6T2FI Ap0zFx75CAdCYm5t6EXvVzqsg0X7lyuLab2mXGMPMBo8wvJFFnkFpJUtyX1P pEQ7crrtsd.Fs05sv4j9XJ_y8u370dWoyaYxnpt7K1cnLNWHvQFQ43oonQfI jxQ-- Received: from [67.91.91.101] by web55801.mail.re3.yahoo.com via HTTP; Thu, 06 Jan 2011 13:32:11 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Thu, 6 Jan 2011 13:32:11 -0800 (PST) From: Francisco Corella To: Dick Hardt In-Reply-To: <5899D82E-89C0-44A4-8DD3-0DBDAE63CFEB@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-906191930-1294349531=:52754" Cc: "Karen P. Lewison" , oauth@ietf.org Subject: Re: [OAUTH-WG] unregistered applications X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jan 2011 21:30:13 -0000 --0-906191930-1294349531=:52754 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dick, > An example of a custom scheme would be what Pounce popularized on the iPh= one.=20 > A redirect to pounce:// would load the Pounce app and pass in the URL Thanks for the tip!=A0 I'll have to look at how custom schemes are used on = iOS. Francisco --0-906191930-1294349531=:52754 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Dick,

> An example of a custom sche= me would be what Pounce popularized on the iPhone.
> A redirect to p= ounce:// would load the Pounce app and pass in the URL

Thanks for th= e tip!  I'll have to look at how custom schemes are used on iOS.
Francisco

--0-906191930-1294349531=:52754-- From progrium@twilio.com Thu Jan 6 19:27:11 2011 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 00C773A6E3B for ; Thu, 6 Jan 2011 19:27:11 -0800 (PST) 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 24wiBlhpf-ff for ; Thu, 6 Jan 2011 19:27:08 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 965C63A68A2 for ; Thu, 6 Jan 2011 19:27:07 -0800 (PST) Received: by yie19 with SMTP id 19so5220829yie.31 for ; Thu, 06 Jan 2011 19:29:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.10.21 with SMTP id 21mr2742251agj.112.1294370954089; Thu, 06 Jan 2011 19:29:14 -0800 (PST) Received: by 10.90.83.15 with HTTP; Thu, 6 Jan 2011 19:29:14 -0800 (PST) Date: Thu, 6 Jan 2011 19:29:14 -0800 Message-ID: From: Jeff Lindsay To: "oauth@ietf.org" Content-Type: multipart/alternative; boundary=0016361e890aed15ed0499393802 Subject: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01 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, 07 Jan 2011 03:27:11 -0000 --0016361e890aed15ed0499393802 Content-Type: text/plain; charset=ISO-8859-1 Hi everyone! I'm really excited about this spec (and OAuth2), as are others here at Twilio. I've been watching it since Paul implemented an early version at Facebook. We also implemented it in an early iteration of a product we're working on, but now we're coming back to it as a means of authentication that would be key to the entire Twilio API... and since our API *is* our product, we're very touchy about the details. I've only been glancing at its progress since the early drafts as various versions were integrated and issues sorted out. I was afraid that it was going to have gotten a lot more complicated, but looking at this I'm pretty happy to see most of the additions are optional. Like Paul, I'm not a fan of the short names. However, I've sort of accepted it, especially since as reserved keys they are less likely to conflict with keys we want to put in. The big problem we have, though, is that the header is required. We're debating going with JWT or our own method that is loosely based on JWT, but doesn't use JSON and results in smaller tokens and a simpler process (for example, you only do one base64url encoding of the final string). We think we'd gain better room for additions to our payload, and better readability (therefore learnability/usability) by using JSON, that it might be worth the tradeoff in token size and several encoding steps. At that point, we'd basically be JWT except for the fact we really don't need the header. Facebook's implementation and one of the original proposals let the algorithm key live in the payload. Since this is the only thing required in the header, allowing it as an optional key in the payload would allow the entire header to be optional. This would really help us out since we need a process that is as simple as humanly possible. If you need to detect if a JWT has a header, you can just check for the number of periods in the JWT. But I really think the header should be optional if you specify the alg in the payload. There may have been some issues reserving the key "algorithm", but I think if we go with short names, "alg" is much less likely to cause conflicts. -- Jeff Lindsay On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones wrote: > Draft -01 of the JSON Web Token (JWT) specificationis now available. This version incorporates the consensus decisions reached > at the Internet Identity Workshop. The remaining open issues and to-do > items are documented in Section 12. > As a reminder, the suggested pronunciation of JWT is the same as the English > word "jot". > > > > The draft is available at these locations: > > - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt > > - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml > > - http://self-issued.info/docs/draft-jones-json-web-token-01.html > > - http://self-issued.info/docs/draft-jones-json-web-token-01.txt > > - http://self-issued.info/docs/draft-jones-json-web-token-01.xml > > - http://self-issued.info/docs/draft-jones-json-web-token.html (will > point to new versions as they are posted) > > - http://self-issued.info/docs/draft-jones-json-web-token.txt (will > point to new versions as they are posted) > > - http://self-issued.info/docs/draft-jones-json-web-token.xml (will > point to new versions as they are posted) > > - http://svn.openid.net/repos/specifications/json_web_token/1.0/(Subversion repository, with html, txt, and html versions available) > > > > The decisions reached at IIW are documented here: > > - JSON Token Spec Results at IIW: http://self-issued.info/?p=361 > > - JSON Token Encryption Spec Results at IIW: > http://self-issued.info/?p=378 > > - JSON Token Naming Spec Results at IIW: http://self-issued.info/?p=386 > > - JSON Public Key Spec Results at IIW: http://self-issued.info/?p=390 > > > > This announcement is also posted here: > > - http://self-issued.info/?p=446 > > > > Thanks to all who provided the input that led to this draft! Feedback is > highly welcome. > > > > -- Mike > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016361e890aed15ed0499393802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi everyone!

I'm really excited about this spec (and= OAuth2), as are others here at Twilio. I've been watching it since Pau= l implemented an early version at Facebook. We also implemented it in an ea= rly iteration of a product we're working on, but now we're coming b= ack to it as a means of authentication that would be key to the entire Twil= io API... and since our API *is* our product, we're very touchy about t= he details. =A0

I've only been glancing at its progress since the e= arly drafts as various versions were integrated and issues sorted out. I wa= s afraid that it was going to have gotten a lot more complicated, but looki= ng at this I'm pretty happy to see most of the additions are optional.= =A0

Like Paul, I'm not a fan of the short names. Howeve= r, I've sort of accepted it, especially since as reserved keys they are= less likely to conflict with keys we want to put in.=A0

The big problem we have, though, is that the header is required. We= 9;re debating going with JWT or our own method that is loosely based on JWT= , but doesn't use JSON and results in smaller tokens and a simpler proc= ess (for example, you only do one base64url encoding of the final string). = We think we'd gain better room for additions to our payload, and better= readability (therefore learnability/usability) by using JSON, that it migh= t be worth the tradeoff in token size and several encoding steps. At that p= oint, we'd basically be JWT except for the fact we really don't nee= d the header.

Facebook's implementation and one of the original p= roposals let the algorithm key live in the payload. Since this is the only = thing required in the header, allowing it as an optional key in the payload= would allow the entire header to be optional. This would really help us ou= t since we need a process that is as simple as humanly possible.=A0

If you need to detect if a JWT has a header, you can ju= st check for the number of periods in the JWT. But I really think the heade= r should be optional if you specify the alg in the payload. There may have = been some issues reserving the key "algorithm", but I think if we= go with short names, "alg" is much less likely to cause conflict= s.=A0

--
Jeff Lindsay

On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones <Michael.Jones@microsoft.com&g= t; wrote:

Draft -01 of the JSON Web Token (JWT= ) specification is now available.=A0 This version incorporates the cons= ensus decisions reached at the Internet Identity Workshop.=A0 The remaining open issues and to-do items are documented in Section 12.=A0 As a reminder, the suggested pronunciation of JWT is the= same as the English word "jot".

=A0

The draft is available at these locations:

=A0 - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt

=A0 - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml

=A0 - http://self-issued.info/docs/draft-jones-json-web-token-01.html

=A0 - http://self-issued.info/docs/draft-jones-json-web-token-01.txt

=A0 - http://self-issued.info/docs/draft-jones-json-web-token-01.xml

=A0 - http://self-issued.info/docs/draft-jones-json-web-token.html (will poin= t to new versions as they are posted)

=A0 - http://self-issued.info/docs/draft-jones-json-web-token.txt (will point= to new versions as they are posted)

=A0 - http://self-issued.info/docs/draft-jones-json-web-token.xml (will point= to new versions as they are posted)

=A0 - http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Subvers= ion repository, with html, txt, and html versions available)

=A0

The decisions reached at IIW are documented here:

=A0 - JSON Token Spec Results at IIW:=A0 http://self-issued.info/?p=3D361

=A0 - JSON Token Encryption Spec Results at IIW:=A0 http://self-issued.info/?p=3D378

=A0 - JSON Token Naming Spec Results at IIW:=A0 http://self-issued.info/?p=3D386

=A0 - JSON Public Key Spec Results at IIW: =A0http://self-issued= .info/?p=3D390

=A0

This announcement is also posted here:

=A0 - http://self-issued.info/?p=3D446

=A0

Thanks to all who provided the input that led to thi= s draft!=A0 Feedback is highly welcome.

=A0

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


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


--0016361e890aed15ed0499393802-- From dick.hardt@gmail.com Fri Jan 7 10:40:24 2011 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 3885F3A6929 for ; Fri, 7 Jan 2011 10:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVKSmmxzFtm9 for ; Fri, 7 Jan 2011 10:40:22 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CC08F3A6921 for ; Fri, 7 Jan 2011 10:40:21 -0800 (PST) Received: by iwn40 with SMTP id 40so18565388iwn.31 for ; Fri, 07 Jan 2011 10:42:28 -0800 (PST) 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:message-id:references:to :x-mailer; bh=EyKZ3+qX4N2zUQC0Od80ekZOiPnNUGrxVR5D2dENS64=; b=TqlMhUFCVGTEefyb6tK0XyM3mBrTP/8x0pyzXGZgD3K5CVLV8zrx0+kzWzVVovB9V3 c1kDcActHZuH2v/y4S0GKKWGZ2pxvz1OXQDZvUXwWtgjtGpSSZJyV055+MSlzzFPel5y z3WeJyvh1TlbaBL2oey13RiBykjKV2/s5I1io= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=r4zYx6QWW0l/xk/Iej8WCcQeP/NkaMoKH2EnmAGJVQ+qDBzlD4fqdK0evsJadKBmcc Jceb5WXW/HNv4BcJDh26nNvVaMmQM5WaZyKK40ZF3dXIYLRgFIyGC2+XjTTwotts9Dpc 4N80mK3hGi2ivgKwvRW/lg4xQnnSATdjZbStg= Received: by 10.42.224.136 with SMTP id io8mr1235848icb.29.1294425747912; Fri, 07 Jan 2011 10:42:27 -0800 (PST) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id z4sm23186362ibg.1.2011.01.07.10.42.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 10:42:26 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-24-438447856 From: Dick Hardt In-Reply-To: Date: Fri, 7 Jan 2011 10:42:23 -0800 Message-Id: References: To: Jeff Lindsay X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01 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, 07 Jan 2011 18:40:24 -0000 --Apple-Mail-24-438447856 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jeff Thanks for the feedback. A healthy debate is how we optimize a spec! Will a slightly shorter token be significant for you? Is the rest of = the message so short that a smaller token will have a significant = impact? The hope is that if we standardize JWT, that libraries will be developed = so that the average developer does not need to deal with the details.=20 We are having to balance between a generalized solution and a simple, = specific solution.=20 Too specific and the spec does not solve a broad enough set of people's = needs, libraries don't get developed, or if they do, the code coverage = is nominal and they are not well maintained. This leads to more security = risks and higher barrier to deployment. Too generic and the complexity in the library adds more security risks, = less likely someone will implement a library and deploy. The header makes it easy for a generic library to quickly see what the = rest of the token is, enables support for encrypted payloads (can't do = that if the crypto info is in the payload), and provides a simple path = for extensions / expansion. While I can appreciate doing less encodings operations, the encoding is = already being used, so this is a slight additional computational = overhead. Your suggestion for checking the number of periods may = actually add back the computational overhead, and a separate code path = to be tested leading to less secure code. Happy to elaborate more if = that was not clear and compelling! -- Dick On 2011-01-06, at 7:29 PM, Jeff Lindsay wrote: > Hi everyone! >=20 > I'm really excited about this spec (and OAuth2), as are others here at = Twilio. I've been watching it since Paul implemented an early version at = Facebook. We also implemented it in an early iteration of a product = we're working on, but now we're coming back to it as a means of = authentication that would be key to the entire Twilio API... and since = our API *is* our product, we're very touchy about the details. =20 >=20 > I've only been glancing at its progress since the early drafts as = various versions were integrated and issues sorted out. I was afraid = that it was going to have gotten a lot more complicated, but looking at = this I'm pretty happy to see most of the additions are optional.=20 >=20 > Like Paul, I'm not a fan of the short names. However, I've sort of = accepted it, especially since as reserved keys they are less likely to = conflict with keys we want to put in.=20 >=20 > The big problem we have, though, is that the header is required. We're = debating going with JWT or our own method that is loosely based on JWT, = but doesn't use JSON and results in smaller tokens and a simpler process = (for example, you only do one base64url encoding of the final string). = We think we'd gain better room for additions to our payload, and better = readability (therefore learnability/usability) by using JSON, that it = might be worth the tradeoff in token size and several encoding steps. At = that point, we'd basically be JWT except for the fact we really don't = need the header. >=20 > Facebook's implementation and one of the original proposals let the = algorithm key live in the payload. Since this is the only thing required = in the header, allowing it as an optional key in the payload would allow = the entire header to be optional. This would really help us out since we = need a process that is as simple as humanly possible.=20 >=20 > If you need to detect if a JWT has a header, you can just check for = the number of periods in the JWT. But I really think the header should = be optional if you specify the alg in the payload. There may have been = some issues reserving the key "algorithm", but I think if we go with = short names, "alg" is much less likely to cause conflicts.=20 >=20 > -- > Jeff Lindsay >=20 > On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones = wrote: > Draft -01 of the JSON Web Token (JWT) specification is now available. = This version incorporates the consensus decisions reached at the = Internet Identity Workshop. The remaining open issues and to-do items = are documented in Section 12. As a reminder, the suggested = pronunciation of JWT is the same as the English word "jot". >=20 > =20 > The draft is available at these locations: >=20 > - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt >=20 > - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml >=20 > - http://self-issued.info/docs/draft-jones-json-web-token-01.html >=20 > - http://self-issued.info/docs/draft-jones-json-web-token-01.txt >=20 > - http://self-issued.info/docs/draft-jones-json-web-token-01.xml >=20 > - http://self-issued.info/docs/draft-jones-json-web-token.html (will = point to new versions as they are posted) >=20 > - http://self-issued.info/docs/draft-jones-json-web-token.txt (will = point to new versions as they are posted) >=20 > - http://self-issued.info/docs/draft-jones-json-web-token.xml (will = point to new versions as they are posted) >=20 > - http://svn.openid.net/repos/specifications/json_web_token/1.0/ = (Subversion repository, with html, txt, and html versions available) >=20 > =20 > The decisions reached at IIW are documented here: >=20 > - JSON Token Spec Results at IIW: http://self-issued.info/?p=3D361 >=20 > - JSON Token Encryption Spec Results at IIW: = http://self-issued.info/?p=3D378 >=20 > - JSON Token Naming Spec Results at IIW: = http://self-issued.info/?p=3D386 >=20 > - JSON Public Key Spec Results at IIW: = http://self-issued.info/?p=3D390 >=20 > =20 > This announcement is also posted here: >=20 > - http://self-issued.info/?p=3D446 >=20 > =20 > Thanks to all who provided the input that led to this draft! Feedback = is highly welcome. >=20 > =20 > -- = Mike >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-24-438447856 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Jeff

Thanks for the feedback. A healthy debate is how = we optimize a spec!

Will a slightly shorter = token be significant for you?  Is the rest of the message so short = that a smaller token will have a significant = impact?

The hope is that if we standardize JWT, = that libraries will be developed so that the average developer does not = need to deal with the details. 

We are = having to balance between a generalized solution and a simple, specific = solution. 

Too specific and the spec does = not solve a broad enough set of people's needs, libraries don't get = developed, or if they do, the code coverage is nominal and they are not = well maintained. This leads to more security risks and higher barrier to = deployment.

Too generic and the complexity in = the library adds more security risks, less likely someone will implement = a library and deploy.

The header makes it easy = for a generic library to quickly see what the rest of the token is, = enables support for encrypted payloads (can't do that if the crypto info = is in the payload), and provides a simple path for extensions / = expansion.

While I can appreciate doing less = encodings operations, the encoding is already being used, so this is a = slight additional computational overhead. Your suggestion for checking = the number of periods may actually add back the computational overhead, = and a separate code path to be tested leading to less secure code. Happy = to elaborate more if that was not clear and = compelling!

-- Dick

On = 2011-01-06, at 7:29 PM, Jeff Lindsay wrote:

Hi = everyone!

I'm really excited about this spec (and = OAuth2), as are others here at Twilio. I've been watching it since Paul = implemented an early version at Facebook. We also implemented it in an = early iteration of a product we're working on, but now we're coming back = to it as a means of authentication that would be key to the entire = Twilio API... and since our API *is* our product, we're very touchy = about the details.  

I've only been glancing at its progress since the = early drafts as various versions were integrated and issues sorted out. = I was afraid that it was going to have gotten a lot more complicated, = but looking at this I'm pretty happy to see most of the additions are = optional. 

Like Paul, I'm not a fan of the short names. = However, I've sort of accepted it, especially since as reserved keys = they are less likely to conflict with keys we want to put = in. 

The big problem we have, though, is that the header is required. = We're debating going with JWT or our own method that is loosely based on = JWT, but doesn't use JSON and results in smaller tokens and a simpler = process (for example, you only do one base64url encoding of the final = string). We think we'd gain better room for additions to our payload, = and better readability (therefore learnability/usability) by using JSON, = that it might be worth the tradeoff in token size and several encoding = steps. At that point, we'd basically be JWT except for the fact we = really don't need the header.

Facebook's implementation and one of the original = proposals let the algorithm key live in the payload. Since this is the = only thing required in the header, allowing it as an optional key in the = payload would allow the entire header to be optional. This would really = help us out since we need a process that is as simple as humanly = possible. 

If you need to detect if a JWT has a header, you can = just check for the number of periods in the JWT. But I really think the = header should be optional if you specify the alg in the payload. There = may have been some issues reserving the key "algorithm", but I think if = we go with short names, "alg" is much less likely to cause = conflicts. 

--
Jeff Lindsay

On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Draft -01 of the JSON Web Token (JWT) specification is now = available.  This version incorporates the consensus decisions = reached at the Internet Identity Workshop.  The remaining open issues and to-do items are documented in Section 12.  As a reminder, the suggested pronunciation of JWT = is the same as the English word "jot".

 

The draft is available at these locations:

  - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt<= /p>

  - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml<= /p>

  - = http://self-issued.info/docs/draft-jones-json-web-token-01.html

  - http://self-issued.info/docs/draft-jones-json-web-token-01.txt

  - http://self-issued.info/docs/draft-jones-json-web-token-01.xml

  - http://self-issued.info/docs/draft-jones-json-web-token.html (will = point to new versions as they are posted)

 = - http://self-issued.info/docs/draft-jones-json-web-token.txt (will = point to new versions as they are posted)

 = - http://self-issued.info/docs/draft-jones-json-web-token.xml (will = point to new versions as they are posted)

 = - http://svn.openid.net/repos/specifications/json_web_token/1.0/ = (Subversion repository, with html, txt, and html versions = available)

 

The decisions reached at IIW are documented = here:

  - JSON Token Spec Results at IIW:  http://self-issued.info/?p=3D361

  - JSON Token = Encryption Spec Results at IIW:  http://self-issued.info/?p=3D378

  - JSON Token Naming = Spec Results at IIW:  http://self-issued.info/?p=3D386

  - = JSON Public Key Spec Results at IIW:  http://self-issued.info/?p=3D390

 

This = announcement is also posted here:

  - http://self-issued.info/?p=3D446

 

Thanks = to all who provided the input that led to this draft!  Feedback is = highly welcome.

 

         =             &n= bsp;           &nbs= p;            =             &n= bsp;     -- Mike



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


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

= --Apple-Mail-24-438447856-- From catch-all@paulwalker.tv Fri Jan 7 16:51:07 2011 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 818373A69AD for ; Fri, 7 Jan 2011 16:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, 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 plG1kjt9pSU9 for ; Fri, 7 Jan 2011 16:51:06 -0800 (PST) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id BB52B3A68BA for ; Fri, 7 Jan 2011 16:51:06 -0800 (PST) Received: by pvc21 with SMTP id 21so4029424pvc.31 for ; Fri, 07 Jan 2011 16:53:13 -0800 (PST) Received: by 10.142.216.15 with SMTP id o15mr2215982wfg.75.1294447993574; Fri, 07 Jan 2011 16:53:13 -0800 (PST) Received: from paul.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id y42sm3391280wfd.10.2011.01.07.16.53.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 16:53:12 -0800 (PST) From: Paul Walker Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jan 2011 16:53:10 -0800 Message-Id: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> To: OAuth WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 00:51:07 -0000 As far as I can tell (which isn't very far on many Friday afternoons), = there is no way for a client to distinguish an expired access token from = a revoked, malformed, etc token as the invalid_token error parameter = value encompasses multiple scenarios. Of course, a client could parse = the error_description, but this is an optional parameter with no = guaranty of a common value among providers. Given that the client would want to make an explicit decision to request = another access token using a refresh token (if available), would it not = benefit clients if a specific error parameter value was defined for this = scenario?=20 From wmills@yahoo-inc.com Fri Jan 7 17:22:10 2011 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 18A583A693E for ; Fri, 7 Jan 2011 17:22:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.542 X-Spam-Level: X-Spam-Status: No, score=-17.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, 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 ntIJALCWAseM for ; Fri, 7 Jan 2011 17:22:09 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 5AA2D3A6938 for ; Fri, 7 Jan 2011 17:22:09 -0800 (PST) Received: from SP2-EX07CAS04.ds.corp.yahoo.com (sp2-ex07cas04.corp.sp2.yahoo.com [98.137.59.5]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p081O5w6013093; Fri, 7 Jan 2011 17:24:05 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS04.ds.corp.yahoo.com ([98.137.59.5]) with mapi; Fri, 7 Jan 2011 17:24:05 -0800 From: William Mills To: Paul Walker , OAuth WG Date: Fri, 7 Jan 2011 17:24:02 -0800 Thread-Topic: [OAUTH-WG] expired access token : deserves unique code? Thread-Index: Acuuzojitd2Co2c2TVGNv/WJyrTz7AAA9DAg Message-ID: References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> In-Reply-To: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 01:22:10 -0000 You're giving away more information than you need to here. The result is a= lmost always the same, go back to the token issuer and get a new token of t= he type you need. I think what we're playing against here is ease of debug= ging the server with your client, "Why should I get an invalid token error = with a new token?" and similar questions. I think this is something best left to implementers to put in their own deb= ugging, and not build it into the protocol. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul Walker > Sent: Friday, January 07, 2011 4:53 PM > To: OAuth WG > Subject: [OAUTH-WG] expired access token : deserves unique code? >=20 > As far as I can tell (which isn't very far on many Friday afternoons), > there is no way for a client to distinguish an expired access token > from a revoked, malformed, etc token as the invalid_token error > parameter value encompasses multiple scenarios. Of course, a client > could parse the error_description, but this is an optional parameter > with no guaranty of a common value among providers. >=20 > Given that the client would want to make an explicit decision to > request another access token using a refresh token (if available), > would it not benefit clients if a specific error parameter value was > defined for this scenario? >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From catch-all@paulwalker.tv Fri Jan 7 18:05:33 2011 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 26F703A697B for ; Fri, 7 Jan 2011 18:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 JcRHU29By4q3 for ; Fri, 7 Jan 2011 18:05:32 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 2D98D3A6966 for ; Fri, 7 Jan 2011 18:05:32 -0800 (PST) Received: by pzk5 with SMTP id 5so4566679pzk.31 for ; Fri, 07 Jan 2011 18:07:38 -0800 (PST) Received: by 10.142.82.4 with SMTP id f4mr2224749wfb.293.1294452458864; Fri, 07 Jan 2011 18:07:38 -0800 (PST) Received: from paul.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id w22sm3472924wfd.7.2011.01.07.18.07.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 18:07:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Paul Walker In-Reply-To: Date: Fri, 7 Jan 2011 18:07:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> To: William Mills X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 02:05:33 -0000 I am not concerned with simplifying client development debugging as much = as the ability for clients to have the proper production logic. The = best that clients can do is always attempt a superfluous token refresh = though the reason may be do to an end user revocation for example. On Jan 7, 2011, at 5:24 PM, William Mills wrote: > You're giving away more information than you need to here. The result = is almost always the same, go back to the token issuer and get a new = token of the type you need. I think what we're playing against here is = ease of debugging the server with your client, "Why should I get an = invalid token error with a new token?" and similar questions. >=20 > I think this is something best left to implementers to put in their = own debugging, and not build it into the protocol. >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Paul Walker >> Sent: Friday, January 07, 2011 4:53 PM >> To: OAuth WG >> Subject: [OAUTH-WG] expired access token : deserves unique code? >>=20 >> As far as I can tell (which isn't very far on many Friday = afternoons), >> there is no way for a client to distinguish an expired access token >> from a revoked, malformed, etc token as the invalid_token error >> parameter value encompasses multiple scenarios. Of course, a client >> could parse the error_description, but this is an optional parameter >> with no guaranty of a common value among providers. >>=20 >> Given that the client would want to make an explicit decision to >> request another access token using a refresh token (if available), >> would it not benefit clients if a specific error parameter value was >> defined for this scenario? >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Fri Jan 7 19:11:27 2011 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 7FE463A6987 for ; Fri, 7 Jan 2011 19:11:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.556 X-Spam-Level: X-Spam-Status: No, score=-17.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, 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 WqURIsmSjbXJ for ; Fri, 7 Jan 2011 19:11:26 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 8E3C13A6961 for ; Fri, 7 Jan 2011 19:11:26 -0800 (PST) Received: from SP2-EX07CAS03.ds.corp.yahoo.com (sp2-ex07cas03.corp.sp2.yahoo.com [98.137.59.35]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p083DQGk028129; Fri, 7 Jan 2011 19:13:26 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS03.ds.corp.yahoo.com ([98.137.59.35]) with mapi; Fri, 7 Jan 2011 19:13:25 -0800 From: William Mills To: Paul Walker Date: Fri, 7 Jan 2011 19:13:24 -0800 Thread-Topic: [OAUTH-WG] expired access token : deserves unique code? Thread-Index: Acuu2OZHdNpRjZ8rS6q82E3Z95+zMgACQnDA Message-ID: References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> In-Reply-To: <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 03:11:27 -0000 But it's not superfluous. Their token failed, the only thing they can do t= o fix it is refresh it. > -----Original Message----- > From: Paul Walker [mailto:catch-all@paulwalker.tv] > Sent: Friday, January 07, 2011 6:08 PM > To: William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >=20 > I am not concerned with simplifying client development debugging as > much as the ability for clients to have the proper production logic. > The best that clients can do is always attempt a superfluous token > refresh though the reason may be do to an end user revocation for > example. >=20 > On Jan 7, 2011, at 5:24 PM, William Mills wrote: >=20 > > You're giving away more information than you need to here. The > result is almost always the same, go back to the token issuer and get a > new token of the type you need. I think what we're playing against > here is ease of debugging the server with your client, "Why should I > get an invalid token error with a new token?" and similar questions. > > > > I think this is something best left to implementers to put in their > own debugging, and not build it into the protocol. > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> Of Paul Walker > >> Sent: Friday, January 07, 2011 4:53 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] expired access token : deserves unique code? > >> > >> As far as I can tell (which isn't very far on many Friday > afternoons), > >> there is no way for a client to distinguish an expired access token > >> from a revoked, malformed, etc token as the invalid_token error > >> parameter value encompasses multiple scenarios. Of course, a client > >> could parse the error_description, but this is an optional parameter > >> with no guaranty of a common value among providers. > >> > >> Given that the client would want to make an explicit decision to > >> request another access token using a refresh token (if available), > >> would it not benefit clients if a specific error parameter value was > >> defined for this scenario? > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth From catch-all@paulwalker.tv Fri Jan 7 19:40:18 2011 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 8C8B33A68F7 for ; Fri, 7 Jan 2011 19:40:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, 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 eG9F3Y8O56sC for ; Fri, 7 Jan 2011 19:40:17 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id A5C493A68BA for ; Fri, 7 Jan 2011 19:40:14 -0800 (PST) Received: by pzk5 with SMTP id 5so4575230pzk.31 for ; Fri, 07 Jan 2011 19:42:21 -0800 (PST) Received: by 10.142.214.9 with SMTP id m9mr2281583wfg.9.1294458140374; Fri, 07 Jan 2011 19:42:20 -0800 (PST) Received: from paul.mellmo.lan (rrcs-76-79-212-2.west.biz.rr.com [76.79.212.2]) by mx.google.com with ESMTPS id x18sm3566357wfa.23.2011.01.07.19.42.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 19:42:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Paul Walker In-Reply-To: Date: Fri, 7 Jan 2011 19:42:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> To: William Mills X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 03:40:18 -0000 It's superfluous if the reason is anything but the token expired. A = specific response code allows the client to decide not to make a request = when it is anything but. Otherwise, we are making the client attempt a = refresh that may not (from the client's perspective) succeed when this = information was already known by the provider and could have been = communicated to the client in the initial response for the resource. On Jan 7, 2011, at 7:13 PM, William Mills wrote: > But it's not superfluous. Their token failed, the only thing they can = do to fix it is refresh it. >=20 >> -----Original Message----- >> From: Paul Walker [mailto:catch-all@paulwalker.tv] >> Sent: Friday, January 07, 2011 6:08 PM >> To: William Mills >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >>=20 >> I am not concerned with simplifying client development debugging as >> much as the ability for clients to have the proper production logic. >> The best that clients can do is always attempt a superfluous token >> refresh though the reason may be do to an end user revocation for >> example. >>=20 >> On Jan 7, 2011, at 5:24 PM, William Mills wrote: >>=20 >>> You're giving away more information than you need to here. The >> result is almost always the same, go back to the token issuer and get = a >> new token of the type you need. I think what we're playing against >> here is ease of debugging the server with your client, "Why should I >> get an invalid token error with a new token?" and similar questions. >>>=20 >>> I think this is something best left to implementers to put in their >> own debugging, and not build it into the protocol. >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >> Behalf >>>> Of Paul Walker >>>> Sent: Friday, January 07, 2011 4:53 PM >>>> To: OAuth WG >>>> Subject: [OAUTH-WG] expired access token : deserves unique code? >>>>=20 >>>> As far as I can tell (which isn't very far on many Friday >> afternoons), >>>> there is no way for a client to distinguish an expired access token >>>> from a revoked, malformed, etc token as the invalid_token error >>>> parameter value encompasses multiple scenarios. Of course, a = client >>>> could parse the error_description, but this is an optional = parameter >>>> with no guaranty of a common value among providers. >>>>=20 >>>> Given that the client would want to make an explicit decision to >>>> request another access token using a refresh token (if available), >>>> would it not benefit clients if a specific error parameter value = was >>>> defined for this scenario? >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >=20 From wmills@yahoo-inc.com Fri Jan 7 20:29:26 2011 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 A968F3A698A for ; Fri, 7 Jan 2011 20:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.565 X-Spam-Level: X-Spam-Status: No, score=-17.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, 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 ymvA034cv-c5 for ; Fri, 7 Jan 2011 20:29:25 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id B184A3A6974 for ; Fri, 7 Jan 2011 20:29:22 -0800 (PST) Received: from SP2-EX07CAS04.ds.corp.yahoo.com (sp2-ex07cas04.corp.sp2.yahoo.com [98.137.59.5]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id p084VMXT098912; Fri, 7 Jan 2011 20:31:22 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS04.ds.corp.yahoo.com ([98.137.59.5]) with mapi; Fri, 7 Jan 2011 20:31:22 -0800 From: William Mills To: Paul Walker Date: Fri, 7 Jan 2011 20:31:20 -0800 Thread-Topic: [OAUTH-WG] expired access token : deserves unique code? Thread-Index: Acuu5jKprWQXNK4SSfGPBH5mzJBbMAABnzSw Message-ID: References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 04:29:27 -0000 All the cases like invalid format and validation errors are stuff I think y= ou don't want to tell a hacker trying to muck with your tokens. > -----Original Message----- > From: Paul Walker [mailto:catch-all@paulwalker.tv] > Sent: Friday, January 07, 2011 7:42 PM > To: William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >=20 > It's superfluous if the reason is anything but the token expired. A > specific response code allows the client to decide not to make a > request when it is anything but. Otherwise, we are making the client > attempt a refresh that may not (from the client's perspective) succeed > when this information was already known by the provider and could have > been communicated to the client in the initial response for the > resource. >=20 >=20 > On Jan 7, 2011, at 7:13 PM, William Mills wrote: >=20 > > But it's not superfluous. Their token failed, the only thing they > can do to fix it is refresh it. > > > >> -----Original Message----- > >> From: Paul Walker [mailto:catch-all@paulwalker.tv] > >> Sent: Friday, January 07, 2011 6:08 PM > >> To: William Mills > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? > >> > >> I am not concerned with simplifying client development debugging as > >> much as the ability for clients to have the proper production logic. > >> The best that clients can do is always attempt a superfluous token > >> refresh though the reason may be do to an end user revocation for > >> example. > >> > >> On Jan 7, 2011, at 5:24 PM, William Mills wrote: > >> > >>> You're giving away more information than you need to here. The > >> result is almost always the same, go back to the token issuer and > get a > >> new token of the type you need. I think what we're playing against > >> here is ease of debugging the server with your client, "Why should I > >> get an invalid token error with a new token?" and similar questions. > >>> > >>> I think this is something best left to implementers to put in their > >> own debugging, and not build it into the protocol. > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf > >>>> Of Paul Walker > >>>> Sent: Friday, January 07, 2011 4:53 PM > >>>> To: OAuth WG > >>>> Subject: [OAUTH-WG] expired access token : deserves unique code? > >>>> > >>>> As far as I can tell (which isn't very far on many Friday > >> afternoons), > >>>> there is no way for a client to distinguish an expired access > token > >>>> from a revoked, malformed, etc token as the invalid_token error > >>>> parameter value encompasses multiple scenarios. Of course, a > client > >>>> could parse the error_description, but this is an optional > parameter > >>>> with no guaranty of a common value among providers. > >>>> > >>>> Given that the client would want to make an explicit decision to > >>>> request another access token using a refresh token (if available), > >>>> would it not benefit clients if a specific error parameter value > was > >>>> defined for this scenario? > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing list > >>>> OAuth@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/oauth > > From catch-all@paulwalker.tv Fri Jan 7 22:37:18 2011 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 083B13A69B2 for ; Fri, 7 Jan 2011 22:37:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCPOLrlMiLqO for ; Fri, 7 Jan 2011 22:37:14 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id C6C733A69AF for ; Fri, 7 Jan 2011 22:37:11 -0800 (PST) Received: by iwn40 with SMTP id 40so18951183iwn.31 for ; Fri, 07 Jan 2011 22:39:18 -0800 (PST) Received: by 10.42.177.136 with SMTP id bi8mr630724icb.170.1294465546367; Fri, 07 Jan 2011 21:45:46 -0800 (PST) Received: from [10.0.0.3] (adsl-76-212-213-238.dsl.sndg02.sbcglobal.net [76.212.213.238]) by mx.google.com with ESMTPS id 34sm23667864ibi.20.2011.01.07.21.45.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 21:45:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Paul Walker In-Reply-To: Date: Fri, 7 Jan 2011 21:45:42 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <802874FC-5E1C-4C00-B3C0-AACF75CB8910@paulwalker.tv> References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> To: William Mills X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 06:37:18 -0000 Absolutely. I am not suggesting making specific error parameter values = for those scenarios. But there are scenarios in which a valid and = validated client can benefit from a more specific error value. if response is expired token refresh token else /* token has been revoked */ initiate authorization ... vs if token is invalid if not able to refresh token /* let's give it a shot even if = the end user revoked me */ initiate authorization ... On Jan 7, 2011, at 8:31 PM, William Mills wrote: > All the cases like invalid format and validation errors are stuff I = think you don't want to tell a hacker trying to muck with your tokens. >=20 >> -----Original Message----- >> From: Paul Walker [mailto:catch-all@paulwalker.tv] >> Sent: Friday, January 07, 2011 7:42 PM >> To: William Mills >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >>=20 >> It's superfluous if the reason is anything but the token expired. A >> specific response code allows the client to decide not to make a >> request when it is anything but. Otherwise, we are making the client >> attempt a refresh that may not (from the client's perspective) = succeed >> when this information was already known by the provider and could = have >> been communicated to the client in the initial response for the >> resource. >>=20 >>=20 >> On Jan 7, 2011, at 7:13 PM, William Mills wrote: >>=20 >>> But it's not superfluous. Their token failed, the only thing they >> can do to fix it is refresh it. >>>=20 >>>> -----Original Message----- >>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] >>>> Sent: Friday, January 07, 2011 6:08 PM >>>> To: William Mills >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique = code? >>>>=20 >>>> I am not concerned with simplifying client development debugging as >>>> much as the ability for clients to have the proper production = logic. >>>> The best that clients can do is always attempt a superfluous token >>>> refresh though the reason may be do to an end user revocation for >>>> example. >>>>=20 >>>> On Jan 7, 2011, at 5:24 PM, William Mills wrote: >>>>=20 >>>>> You're giving away more information than you need to here. The >>>> result is almost always the same, go back to the token issuer and >> get a >>>> new token of the type you need. I think what we're playing against >>>> here is ease of debugging the server with your client, "Why should = I >>>> get an invalid token error with a new token?" and similar = questions. >>>>>=20 >>>>> I think this is something best left to implementers to put in = their >>>> own debugging, and not build it into the protocol. >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf >>>>>> Of Paul Walker >>>>>> Sent: Friday, January 07, 2011 4:53 PM >>>>>> To: OAuth WG >>>>>> Subject: [OAUTH-WG] expired access token : deserves unique code? >>>>>>=20 >>>>>> As far as I can tell (which isn't very far on many Friday >>>> afternoons), >>>>>> there is no way for a client to distinguish an expired access >> token >>>>>> from a revoked, malformed, etc token as the invalid_token error >>>>>> parameter value encompasses multiple scenarios. Of course, a >> client >>>>>> could parse the error_description, but this is an optional >> parameter >>>>>> with no guaranty of a common value among providers. >>>>>>=20 >>>>>> Given that the client would want to make an explicit decision to >>>>>> request another access token using a refresh token (if = available), >>>>>> would it not benefit clients if a specific error parameter value >> was >>>>>> defined for this scenario? >>>>>>=20 >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>=20 >=20 From wmills@yahoo-inc.com Fri Jan 7 22:54:46 2011 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 CD0EA3A69B2 for ; Fri, 7 Jan 2011 22:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.403 X-Spam-Level: X-Spam-Status: No, score=-17.403 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, 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 r2-gFl0tU25V for ; Fri, 7 Jan 2011 22:54:45 -0800 (PST) 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 820E13A699D for ; Fri, 7 Jan 2011 22:54:42 -0800 (PST) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p085q3vR084416; Fri, 7 Jan 2011 21:52:03 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Fri, 7 Jan 2011 21:52:03 -0800 From: William Mills To: Paul Walker Date: Fri, 7 Jan 2011 21:52:01 -0800 Thread-Topic: [OAUTH-WG] expired access token : deserves unique code? Thread-Index: Acuu91cLJZYMBdl+SouSLi2IXoF3jwAAGsgg Message-ID: References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> <802874FC-5E1C-4C00-B3C0-AACF75CB8910@paulwalker.tv> In-Reply-To: <802874FC-5E1C-4C00-B3C0-AACF75CB8910@paulwalker.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 06:54:46 -0000 But so the round trip we're saving is the call to the refresh entrypoint wh= ich would give a failure and require a new authentication, you just want to= go straight to the authentication. Yeah, returning an "auth failed" inste= ad of token expired" would solve that, is it truly worth it? > -----Original Message----- > From: Paul Walker [mailto:catch-all@paulwalker.tv] > Sent: Friday, January 07, 2011 9:46 PM > To: William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >=20 > Absolutely. I am not suggesting making specific error parameter values > for those scenarios. But there are scenarios in which a valid and > validated client can benefit from a more specific error value. >=20 > if response is expired token > refresh token > else /* token has been revoked */ > initiate authorization > ... >=20 > vs >=20 > if token is invalid > if not able to refresh token /* let's give it a shot even if the > end user revoked me */ > initiate authorization > ... >=20 >=20 > On Jan 7, 2011, at 8:31 PM, William Mills wrote: >=20 > > All the cases like invalid format and validation errors are stuff I > think you don't want to tell a hacker trying to muck with your tokens. > > > >> -----Original Message----- > >> From: Paul Walker [mailto:catch-all@paulwalker.tv] > >> Sent: Friday, January 07, 2011 7:42 PM > >> To: William Mills > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? > >> > >> It's superfluous if the reason is anything but the token expired. A > >> specific response code allows the client to decide not to make a > >> request when it is anything but. Otherwise, we are making the > client > >> attempt a refresh that may not (from the client's perspective) > succeed > >> when this information was already known by the provider and could > have > >> been communicated to the client in the initial response for the > >> resource. > >> > >> > >> On Jan 7, 2011, at 7:13 PM, William Mills wrote: > >> > >>> But it's not superfluous. Their token failed, the only thing they > >> can do to fix it is refresh it. > >>> > >>>> -----Original Message----- > >>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] > >>>> Sent: Friday, January 07, 2011 6:08 PM > >>>> To: William Mills > >>>> Cc: OAuth WG > >>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique > code? > >>>> > >>>> I am not concerned with simplifying client development debugging > as > >>>> much as the ability for clients to have the proper production > logic. > >>>> The best that clients can do is always attempt a superfluous token > >>>> refresh though the reason may be do to an end user revocation for > >>>> example. > >>>> > >>>> On Jan 7, 2011, at 5:24 PM, William Mills wrote: > >>>> > >>>>> You're giving away more information than you need to here. The > >>>> result is almost always the same, go back to the token issuer and > >> get a > >>>> new token of the type you need. I think what we're playing > against > >>>> here is ease of debugging the server with your client, "Why should > I > >>>> get an invalid token error with a new token?" and similar > questions. > >>>>> > >>>>> I think this is something best left to implementers to put in > their > >>>> own debugging, and not build it into the protocol. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf > >>>>>> Of Paul Walker > >>>>>> Sent: Friday, January 07, 2011 4:53 PM > >>>>>> To: OAuth WG > >>>>>> Subject: [OAUTH-WG] expired access token : deserves unique code? > >>>>>> > >>>>>> As far as I can tell (which isn't very far on many Friday > >>>> afternoons), > >>>>>> there is no way for a client to distinguish an expired access > >> token > >>>>>> from a revoked, malformed, etc token as the invalid_token error > >>>>>> parameter value encompasses multiple scenarios. Of course, a > >> client > >>>>>> could parse the error_description, but this is an optional > >> parameter > >>>>>> with no guaranty of a common value among providers. > >>>>>> > >>>>>> Given that the client would want to make an explicit decision to > >>>>>> request another access token using a refresh token (if > available), > >>>>>> would it not benefit clients if a specific error parameter value > >> was > >>>>>> defined for this scenario? > >>>>>> > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>> > > From eran@hueniverse.com Fri Jan 7 23:08:23 2011 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 7448D3A699C for ; Fri, 7 Jan 2011 23:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 W5KdSCD1v8CG for ; Fri, 7 Jan 2011 23:08:22 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3B34D3A698E for ; Fri, 7 Jan 2011 23:08:22 -0800 (PST) Received: (qmail 12484 invoked from network); 8 Jan 2011 07:10:28 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 8 Jan 2011 07:10:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 8 Jan 2011 00:10:29 -0700 From: Eran Hammer-Lahav To: Paul Walker , OAuth WG Date: Sat, 8 Jan 2011 00:10:19 -0700 Thread-Topic: [OAUTH-WG] expired access token : deserves unique code? Thread-Index: AcuuznNmdSFZ829URJO7R9h7jbWxoAANKUZA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB724A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> In-Reply-To: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 07:08:23 -0000 http://www.ietf.org/mail-archive/web/oauth/current/msg03734.html > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Paul Walker > Sent: Friday, January 07, 2011 4:53 PM > To: OAuth WG > Subject: [OAUTH-WG] expired access token : deserves unique code? >=20 > As far as I can tell (which isn't very far on many Friday afternoons), th= ere is no > way for a client to distinguish an expired access token from a revoked, > malformed, etc token as the invalid_token error parameter value > encompasses multiple scenarios. Of course, a client could parse the > error_description, but this is an optional parameter with no guaranty of = a > common value among providers. >=20 > Given that the client would want to make an explicit decision to request > another access token using a refresh token (if available), would it not b= enefit > clients if a specific error parameter value was defined for this scenario= ? >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From catch-all@paulwalker.tv Fri Jan 7 23:14:27 2011 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 11F9E3A69A9 for ; Fri, 7 Jan 2011 23:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 0U2-HxBVebZK for ; Fri, 7 Jan 2011 23:14:26 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 01AD13A698E for ; Fri, 7 Jan 2011 23:14:25 -0800 (PST) Received: by iyi42 with SMTP id 42so17893088iyi.31 for ; Fri, 07 Jan 2011 23:16:33 -0800 (PST) Received: by 10.42.230.134 with SMTP id jm6mr1712424icb.375.1294466910100; Fri, 07 Jan 2011 22:08:30 -0800 (PST) Received: from [10.0.0.3] (adsl-76-212-213-238.dsl.sndg02.sbcglobal.net [76.212.213.238]) by mx.google.com with ESMTPS id ca7sm1311637icb.12.2011.01.07.22.08.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 07 Jan 2011 22:08:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Paul Walker In-Reply-To: Date: Fri, 7 Jan 2011 22:08:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <32A20FFF-CFEB-4549-891F-03814E7ADD10@paulwalker.tv> References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> <802874FC-5E1C-4C00-B3C0-AACF75CB8910@paulwalker.tv> To: William Mills X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 07:14:27 -0000 yes, exactly. i'm not really passionate about it, but noticed during = development as something i would want and felt kind of "stuck" in not = being able to communicate this specific condition to clients (other than = to parse the error_description). my feeling is that it would only add = value. On Jan 7, 2011, at 9:52 PM, William Mills wrote: > But so the round trip we're saving is the call to the refresh = entrypoint which would give a failure and require a new authentication, = you just want to go straight to the authentication. Yeah, returning an = "auth failed" instead of token expired" would solve that, is it truly = worth it? >=20 >> -----Original Message----- >> From: Paul Walker [mailto:catch-all@paulwalker.tv] >> Sent: Friday, January 07, 2011 9:46 PM >> To: William Mills >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >>=20 >> Absolutely. I am not suggesting making specific error parameter = values >> for those scenarios. But there are scenarios in which a valid and >> validated client can benefit from a more specific error value. >>=20 >> if response is expired token >> refresh token >> else /* token has been revoked */ >> initiate authorization >> ... >>=20 >> vs >>=20 >> if token is invalid >> if not able to refresh token /* let's give it a shot even if = the >> end user revoked me */ >> initiate authorization >> ... >>=20 >>=20 >> On Jan 7, 2011, at 8:31 PM, William Mills wrote: >>=20 >>> All the cases like invalid format and validation errors are stuff I >> think you don't want to tell a hacker trying to muck with your = tokens. >>>=20 >>>> -----Original Message----- >>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] >>>> Sent: Friday, January 07, 2011 7:42 PM >>>> To: William Mills >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique = code? >>>>=20 >>>> It's superfluous if the reason is anything but the token expired. = A >>>> specific response code allows the client to decide not to make a >>>> request when it is anything but. Otherwise, we are making the >> client >>>> attempt a refresh that may not (from the client's perspective) >> succeed >>>> when this information was already known by the provider and could >> have >>>> been communicated to the client in the initial response for the >>>> resource. >>>>=20 >>>>=20 >>>> On Jan 7, 2011, at 7:13 PM, William Mills wrote: >>>>=20 >>>>> But it's not superfluous. Their token failed, the only thing they >>>> can do to fix it is refresh it. >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] >>>>>> Sent: Friday, January 07, 2011 6:08 PM >>>>>> To: William Mills >>>>>> Cc: OAuth WG >>>>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique >> code? >>>>>>=20 >>>>>> I am not concerned with simplifying client development debugging >> as >>>>>> much as the ability for clients to have the proper production >> logic. >>>>>> The best that clients can do is always attempt a superfluous = token >>>>>> refresh though the reason may be do to an end user revocation for >>>>>> example. >>>>>>=20 >>>>>> On Jan 7, 2011, at 5:24 PM, William Mills wrote: >>>>>>=20 >>>>>>> You're giving away more information than you need to here. The >>>>>> result is almost always the same, go back to the token issuer and >>>> get a >>>>>> new token of the type you need. I think what we're playing >> against >>>>>> here is ease of debugging the server with your client, "Why = should >> I >>>>>> get an invalid token error with a new token?" and similar >> questions. >>>>>>>=20 >>>>>>> I think this is something best left to implementers to put in >> their >>>>>> own debugging, and not build it into the protocol. >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf >>>>>>>> Of Paul Walker >>>>>>>> Sent: Friday, January 07, 2011 4:53 PM >>>>>>>> To: OAuth WG >>>>>>>> Subject: [OAUTH-WG] expired access token : deserves unique = code? >>>>>>>>=20 >>>>>>>> As far as I can tell (which isn't very far on many Friday >>>>>> afternoons), >>>>>>>> there is no way for a client to distinguish an expired access >>>> token >>>>>>>> from a revoked, malformed, etc token as the invalid_token error >>>>>>>> parameter value encompasses multiple scenarios. Of course, a >>>> client >>>>>>>> could parse the error_description, but this is an optional >>>> parameter >>>>>>>> with no guaranty of a common value among providers. >>>>>>>>=20 >>>>>>>> Given that the client would want to make an explicit decision = to >>>>>>>> request another access token using a refresh token (if >> available), >>>>>>>> would it not benefit clients if a specific error parameter = value >>>> was >>>>>>>> defined for this scenario? >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>=20 >>>=20 >=20 From jbhate@exacttarget.com Sat Jan 8 05:57:57 2011 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 2807D28C0F0 for ; Sat, 8 Jan 2011 05:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 g+9AkxZGs0w3 for ; Sat, 8 Jan 2011 05:57:55 -0800 (PST) Received: from hub01.exacttarget.com (hub01.exacttarget.com [207.67.98.219]) by core3.amsl.com (Postfix) with ESMTP id AB08C28C0EA for ; Sat, 8 Jan 2011 05:57:55 -0800 (PST) From: Jitesh Bhate To: Paul Walker , William Mills Date: Sat, 8 Jan 2011 08:57:50 -0500 Thread-Topic: [OAUTH-WG] expired access token : deserves unique code? Thread-Index: AcuvBB6+u3aogmp1Qt+kLdFtF+t6qgAN+uAH Message-ID: References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> <802874FC-5E1C-4C00-B3C0-AACF75CB8910@paulwalker.tv> , <32A20FFF-CFEB-4549-891F-03814E7ADD10@paulwalker.tv> In-Reply-To: <32A20FFF-CFEB-4549-891F-03814E7ADD10@paulwalker.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 13:57:57 -0000 I agree with Paul , we ran into similar issue with invalid_token status and= have to rely on error_description to give/get exact cause of error.. Jitesh Bhate ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Paul Wal= ker [catch-all@paulwalker.tv] Sent: Saturday, January 08, 2011 1:08 AM To: William Mills Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? yes, exactly. i'm not really passionate about it, but noticed during devel= opment as something i would want and felt kind of "stuck" in not being able= to communicate this specific condition to clients (other than to parse the= error_description). my feeling is that it would only add value. On Jan 7, 2011, at 9:52 PM, William Mills wrote: > But so the round trip we're saving is the call to the refresh entrypoint = which would give a failure and require a new authentication, you just want = to go straight to the authentication. Yeah, returning an "auth failed" ins= tead of token expired" would solve that, is it truly worth it? > >> -----Original Message----- >> From: Paul Walker [mailto:catch-all@paulwalker.tv] >> Sent: Friday, January 07, 2011 9:46 PM >> To: William Mills >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >> >> Absolutely. I am not suggesting making specific error parameter values >> for those scenarios. But there are scenarios in which a valid and >> validated client can benefit from a more specific error value. >> >> if response is expired token >> refresh token >> else /* token has been revoked */ >> initiate authorization >> ... >> >> vs >> >> if token is invalid >> if not able to refresh token /* let's give it a shot even if the >> end user revoked me */ >> initiate authorization >> ... >> >> >> On Jan 7, 2011, at 8:31 PM, William Mills wrote: >> >>> All the cases like invalid format and validation errors are stuff I >> think you don't want to tell a hacker trying to muck with your tokens. >>> >>>> -----Original Message----- >>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] >>>> Sent: Friday, January 07, 2011 7:42 PM >>>> To: William Mills >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >>>> >>>> It's superfluous if the reason is anything but the token expired. A >>>> specific response code allows the client to decide not to make a >>>> request when it is anything but. Otherwise, we are making the >> client >>>> attempt a refresh that may not (from the client's perspective) >> succeed >>>> when this information was already known by the provider and could >> have >>>> been communicated to the client in the initial response for the >>>> resource. >>>> >>>> >>>> On Jan 7, 2011, at 7:13 PM, William Mills wrote: >>>> >>>>> But it's not superfluous. Their token failed, the only thing they >>>> can do to fix it is refresh it. >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] >>>>>> Sent: Friday, January 07, 2011 6:08 PM >>>>>> To: William Mills >>>>>> Cc: OAuth WG >>>>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique >> code? >>>>>> >>>>>> I am not concerned with simplifying client development debugging >> as >>>>>> much as the ability for clients to have the proper production >> logic. >>>>>> The best that clients can do is always attempt a superfluous token >>>>>> refresh though the reason may be do to an end user revocation for >>>>>> example. >>>>>> >>>>>> On Jan 7, 2011, at 5:24 PM, William Mills wrote: >>>>>> >>>>>>> You're giving away more information than you need to here. The >>>>>> result is almost always the same, go back to the token issuer and >>>> get a >>>>>> new token of the type you need. I think what we're playing >> against >>>>>> here is ease of debugging the server with your client, "Why should >> I >>>>>> get an invalid token error with a new token?" and similar >> questions. >>>>>>> >>>>>>> I think this is something best left to implementers to put in >> their >>>>>> own debugging, and not build it into the protocol. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf >>>>>>>> Of Paul Walker >>>>>>>> Sent: Friday, January 07, 2011 4:53 PM >>>>>>>> To: OAuth WG >>>>>>>> Subject: [OAUTH-WG] expired access token : deserves unique code? >>>>>>>> >>>>>>>> As far as I can tell (which isn't very far on many Friday >>>>>> afternoons), >>>>>>>> there is no way for a client to distinguish an expired access >>>> token >>>>>>>> from a revoked, malformed, etc token as the invalid_token error >>>>>>>> parameter value encompasses multiple scenarios. Of course, a >>>> client >>>>>>>> could parse the error_description, but this is an optional >>>> parameter >>>>>>>> with no guaranty of a common value among providers. >>>>>>>> >>>>>>>> Given that the client would want to make an explicit decision to >>>>>>>> request another access token using a refresh token (if >> available), >>>>>>>> would it not benefit clients if a specific error parameter value >>>> was >>>>>>>> defined for this scenario? >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing 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 jbhate@exacttarget.com Sat Jan 8 07:04:33 2011 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 6FD8828C0F9 for ; Sat, 8 Jan 2011 07:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 NWg-TTqnccF1 for ; Sat, 8 Jan 2011 07:04:32 -0800 (PST) Received: from hub01.exacttarget.com (hub01.exacttarget.com [207.67.98.219]) by core3.amsl.com (Postfix) with ESMTP id 30F2F28C0F0 for ; Sat, 8 Jan 2011 07:04:31 -0800 (PST) From: Jitesh Bhate To: Jitesh Bhate , Paul Walker , William Mills Date: Sat, 8 Jan 2011 10:07:26 -0500 Thread-Topic: [OAUTH-WG] expired access token : deserves unique code? Thread-Index: AcuvBB6+u3aogmp1Qt+kLdFtF+t6qgAN+uAHAAIzYUQ= Message-ID: References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> <802874FC-5E1C-4C00-B3C0-AACF75CB8910@paulwalker.tv> , <32A20FFF-CFEB-4549-891F-03814E7ADD10@paulwalker.tv>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sat, 08 Jan 2011 15:04:33 -0000 though access token gives expiration info. that can be used when server ret= urns Invalid_token code to determine need to refresh token or Initiate authorization ( but I have got requests from our many client s= ide developers to differentiate invalidate token vs expired token) Jitesh ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Jitesh B= hate [jbhate@exacttarget.com] Sent: Saturday, January 08, 2011 8:57 AM To: Paul Walker; William Mills Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? I agree with Paul , we ran into similar issue with invalid_token status and= have to rely on error_description to give/get exact cause of error.. Jitesh Bhate ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Paul Wal= ker [catch-all@paulwalker.tv] Sent: Saturday, January 08, 2011 1:08 AM To: William Mills Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? yes, exactly. i'm not really passionate about it, but noticed during devel= opment as something i would want and felt kind of "stuck" in not being able= to communicate this specific condition to clients (other than to parse the= error_description). my feeling is that it would only add value. On Jan 7, 2011, at 9:52 PM, William Mills wrote: > But so the round trip we're saving is the call to the refresh entrypoint = which would give a failure and require a new authentication, you just want = to go straight to the authentication. Yeah, returning an "auth failed" ins= tead of token expired" would solve that, is it truly worth it? > >> -----Original Message----- >> From: Paul Walker [mailto:catch-all@paulwalker.tv] >> Sent: Friday, January 07, 2011 9:46 PM >> To: William Mills >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >> >> Absolutely. I am not suggesting making specific error parameter values >> for those scenarios. But there are scenarios in which a valid and >> validated client can benefit from a more specific error value. >> >> if response is expired token >> refresh token >> else /* token has been revoked */ >> initiate authorization >> ... >> >> vs >> >> if token is invalid >> if not able to refresh token /* let's give it a shot even if the >> end user revoked me */ >> initiate authorization >> ... >> >> >> On Jan 7, 2011, at 8:31 PM, William Mills wrote: >> >>> All the cases like invalid format and validation errors are stuff I >> think you don't want to tell a hacker trying to muck with your tokens. >>> >>>> -----Original Message----- >>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] >>>> Sent: Friday, January 07, 2011 7:42 PM >>>> To: William Mills >>>> Cc: OAuth WG >>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >>>> >>>> It's superfluous if the reason is anything but the token expired. A >>>> specific response code allows the client to decide not to make a >>>> request when it is anything but. Otherwise, we are making the >> client >>>> attempt a refresh that may not (from the client's perspective) >> succeed >>>> when this information was already known by the provider and could >> have >>>> been communicated to the client in the initial response for the >>>> resource. >>>> >>>> >>>> On Jan 7, 2011, at 7:13 PM, William Mills wrote: >>>> >>>>> But it's not superfluous. Their token failed, the only thing they >>>> can do to fix it is refresh it. >>>>> >>>>>> -----Original Message----- >>>>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] >>>>>> Sent: Friday, January 07, 2011 6:08 PM >>>>>> To: William Mills >>>>>> Cc: OAuth WG >>>>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique >> code? >>>>>> >>>>>> I am not concerned with simplifying client development debugging >> as >>>>>> much as the ability for clients to have the proper production >> logic. >>>>>> The best that clients can do is always attempt a superfluous token >>>>>> refresh though the reason may be do to an end user revocation for >>>>>> example. >>>>>> >>>>>> On Jan 7, 2011, at 5:24 PM, William Mills wrote: >>>>>> >>>>>>> You're giving away more information than you need to here. The >>>>>> result is almost always the same, go back to the token issuer and >>>> get a >>>>>> new token of the type you need. I think what we're playing >> against >>>>>> here is ease of debugging the server with your client, "Why should >> I >>>>>> get an invalid token error with a new token?" and similar >> questions. >>>>>>> >>>>>>> I think this is something best left to implementers to put in >> their >>>>>> own debugging, and not build it into the protocol. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>>>> Behalf >>>>>>>> Of Paul Walker >>>>>>>> Sent: Friday, January 07, 2011 4:53 PM >>>>>>>> To: OAuth WG >>>>>>>> Subject: [OAUTH-WG] expired access token : deserves unique code? >>>>>>>> >>>>>>>> As far as I can tell (which isn't very far on many Friday >>>>>> afternoons), >>>>>>>> there is no way for a client to distinguish an expired access >>>> token >>>>>>>> from a revoked, malformed, etc token as the invalid_token error >>>>>>>> parameter value encompasses multiple scenarios. Of course, a >>>> client >>>>>>>> could parse the error_description, but this is an optional >>>> parameter >>>>>>>> with no guaranty of a common value among providers. >>>>>>>> >>>>>>>> Given that the client would want to make an explicit decision to >>>>>>>> request another access token using a refresh token (if >> available), >>>>>>>> would it not benefit clients if a specific error parameter value >>>> was >>>>>>>> defined for this scenario? >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing 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 Jan 8 22:48:04 2011 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 775143A693C for ; Sat, 8 Jan 2011 22:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 bPLIc8MdKT7D for ; Sat, 8 Jan 2011 22:47:51 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 71FCF3A693B for ; Sat, 8 Jan 2011 22:47:45 -0800 (PST) Received: (qmail 19884 invoked from network); 9 Jan 2011 06:49:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jan 2011 06:49:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 8 Jan 2011 23:49:54 -0700 From: Eran Hammer-Lahav To: Jitesh Bhate , Paul Walker , William Mills Date: Sat, 8 Jan 2011 23:49:43 -0700 Thread-Topic: [OAUTH-WG] expired access token : deserves unique code? Thread-Index: AcuvBB6+u3aogmp1Qt+kLdFtF+t6qgAN+uAHAAIzYUQAIR48MA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB729E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <2F76E3D9-B280-421F-B5B6-C516248ECA11@paulwalker.tv> <802874FC-5E1C-4C00-B3C0-AACF75CB8910@paulwalker.tv> , <32A20FFF-CFEB-4549-891F-03814E7ADD10@paulwalker.tv>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sun, 09 Jan 2011 06:48:04 -0000 We can add it back in, but put a note that invalid may mean expired in some= cases where the server cannot tell or doesn't want to tell. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Jitesh Bhate > Sent: Saturday, January 08, 2011 7:07 AM > To: Jitesh Bhate; Paul Walker; William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >=20 > though access token gives expiration info. that can be used when server > returns Invalid_token code to determine need to refresh token or Initiat= e > authorization ( but I have got requests from our many client side develo= pers > to differentiate invalidate token vs expired token) >=20 > Jitesh >=20 > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of > Jitesh Bhate [jbhate@exacttarget.com] > Sent: Saturday, January 08, 2011 8:57 AM > To: Paul Walker; William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >=20 > I agree with Paul , we ran into similar issue with invalid_token status a= nd > have to rely on error_description to give/get exact cause of error.. >=20 > Jitesh Bhate >=20 > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Paul > Walker [catch-all@paulwalker.tv] > Sent: Saturday, January 08, 2011 1:08 AM > To: William Mills > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >=20 > yes, exactly. i'm not really passionate about it, but noticed during > development as something i would want and felt kind of "stuck" in not bei= ng > able to communicate this specific condition to clients (other than to par= se the > error_description). my feeling is that it would only add value. >=20 > On Jan 7, 2011, at 9:52 PM, William Mills wrote: >=20 > > But so the round trip we're saving is the call to the refresh entrypoin= t which > would give a failure and require a new authentication, you just want to g= o > straight to the authentication. Yeah, returning an "auth failed" instead= of > token expired" would solve that, is it truly worth it? > > > >> -----Original Message----- > >> From: Paul Walker [mailto:catch-all@paulwalker.tv] > >> Sent: Friday, January 07, 2011 9:46 PM > >> To: William Mills > >> Cc: OAuth WG > >> Subject: Re: [OAUTH-WG] expired access token : deserves unique code? > >> > >> Absolutely. I am not suggesting making specific error parameter > >> values for those scenarios. But there are scenarios in which a valid > >> and validated client can benefit from a more specific error value. > >> > >> if response is expired token > >> refresh token > >> else /* token has been revoked */ > >> initiate authorization > >> ... > >> > >> vs > >> > >> if token is invalid > >> if not able to refresh token /* let's give it a shot even if > >> the end user revoked me */ > >> initiate authorization > >> ... > >> > >> > >> On Jan 7, 2011, at 8:31 PM, William Mills wrote: > >> > >>> All the cases like invalid format and validation errors are stuff I > >> think you don't want to tell a hacker trying to muck with your tokens. > >>> > >>>> -----Original Message----- > >>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] > >>>> Sent: Friday, January 07, 2011 7:42 PM > >>>> To: William Mills > >>>> Cc: OAuth WG > >>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique > code? > >>>> > >>>> It's superfluous if the reason is anything but the token expired. > >>>> A specific response code allows the client to decide not to make a > >>>> request when it is anything but. Otherwise, we are making the > >> client > >>>> attempt a refresh that may not (from the client's perspective) > >> succeed > >>>> when this information was already known by the provider and could > >> have > >>>> been communicated to the client in the initial response for the > >>>> resource. > >>>> > >>>> > >>>> On Jan 7, 2011, at 7:13 PM, William Mills wrote: > >>>> > >>>>> But it's not superfluous. Their token failed, the only thing they > >>>> can do to fix it is refresh it. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Paul Walker [mailto:catch-all@paulwalker.tv] > >>>>>> Sent: Friday, January 07, 2011 6:08 PM > >>>>>> To: William Mills > >>>>>> Cc: OAuth WG > >>>>>> Subject: Re: [OAUTH-WG] expired access token : deserves unique > >> code? > >>>>>> > >>>>>> I am not concerned with simplifying client development debugging > >> as > >>>>>> much as the ability for clients to have the proper production > >> logic. > >>>>>> The best that clients can do is always attempt a superfluous > >>>>>> token refresh though the reason may be do to an end user > >>>>>> revocation for example. > >>>>>> > >>>>>> On Jan 7, 2011, at 5:24 PM, William Mills wrote: > >>>>>> > >>>>>>> You're giving away more information than you need to here. The > >>>>>> result is almost always the same, go back to the token issuer and > >>>> get a > >>>>>> new token of the type you need. I think what we're playing > >> against > >>>>>> here is ease of debugging the server with your client, "Why > >>>>>> should > >> I > >>>>>> get an invalid token error with a new token?" and similar > >> questions. > >>>>>>> > >>>>>>> I think this is something best left to implementers to put in > >> their > >>>>>> own debugging, and not build it into the protocol. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > On > >>>>>> Behalf > >>>>>>>> Of Paul Walker > >>>>>>>> Sent: Friday, January 07, 2011 4:53 PM > >>>>>>>> To: OAuth WG > >>>>>>>> Subject: [OAUTH-WG] expired access token : deserves unique > code? > >>>>>>>> > >>>>>>>> As far as I can tell (which isn't very far on many Friday > >>>>>> afternoons), > >>>>>>>> there is no way for a client to distinguish an expired access > >>>> token > >>>>>>>> from a revoked, malformed, etc token as the invalid_token error > >>>>>>>> parameter value encompasses multiple scenarios. Of course, a > >>>> client > >>>>>>>> could parse the error_description, but this is an optional > >>>> parameter > >>>>>>>> with no guaranty of a common value among providers. > >>>>>>>> > >>>>>>>> Given that the client would want to make an explicit decision > >>>>>>>> to request another access token using a refresh token (if > >> available), > >>>>>>>> would it not benefit clients if a specific error parameter > >>>>>>>> value > >>>> was > >>>>>>>> defined for this scenario? > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> OAuth mailing list > >>>>>>>> OAuth@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> > >>> > > >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From catch-all@paulwalker.tv Sun Jan 9 00:57:14 2011 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 2D6C53A683E for ; Sun, 9 Jan 2011 00:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agNdAOLa-o3x for ; Sun, 9 Jan 2011 00:57:13 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 25D423A67F8 for ; Sun, 9 Jan 2011 00:57:13 -0800 (PST) Received: by pzk5 with SMTP id 5so4733038pzk.31 for ; Sun, 09 Jan 2011 00:59:23 -0800 (PST) Received: by 10.143.41.7 with SMTP id t7mr3310483wfj.102.1294563563392; Sun, 09 Jan 2011 00:59:23 -0800 (PST) Received: from [10.0.0.3] ([75.36.33.107]) by mx.google.com with ESMTPS id x18sm5693973wfa.23.2011.01.09.00.59.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 09 Jan 2011 00:59:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Paul Walker In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB724A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 9 Jan 2011 00:59:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <90C41DD21FB7C64BB94121FBBC2E723445A5AB724A@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sun, 09 Jan 2011 08:57:14 -0000 Brian, Eran, et all I don't understand the need to discard relevant data while the = authorization between end user and provider are valid. On Jan 7, 2011, at 11:10 PM, Eran Hammer-Lahav wrote: > http://www.ietf.org/mail-archive/web/oauth/current/msg03734.html >=20 >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Paul Walker >> Sent: Friday, January 07, 2011 4:53 PM >> To: OAuth WG >> Subject: [OAUTH-WG] expired access token : deserves unique code? >>=20 >> As far as I can tell (which isn't very far on many Friday = afternoons), there is no >> way for a client to distinguish an expired access token from a = revoked, >> malformed, etc token as the invalid_token error parameter value >> encompasses multiple scenarios. Of course, a client could parse the >> error_description, but this is an optional parameter with no guaranty = of a >> common value among providers. >>=20 >> Given that the client would want to make an explicit decision to = request >> another access token using a refresh token (if available), would it = not benefit >> clients if a specific error parameter value was defined for this = scenario? >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Sun Jan 9 09:10:46 2011 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 B59CC3A67B8 for ; Sun, 9 Jan 2011 09:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.612 X-Spam-Level: X-Spam-Status: No, score=-102.612 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, 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 ZK6osCC3JFNd for ; Sun, 9 Jan 2011 09:10:44 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 2D92E3A67A7 for ; Sun, 9 Jan 2011 09:10:43 -0800 (PST) Received: (qmail invoked by alias); 09 Jan 2011 17:12:53 -0000 Received: from a88-115-222-204.elisa-laajakaista.fi (EHLO [192.168.1.7]) [88.115.222.204] by mail.gmx.net (mp021) with SMTP; 09 Jan 2011 18:12:53 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18mpNoSONkmBAqaK3XQD1m9HB49t/RCu7DrTJAIaL iJxvg5BJ/ve2Ub From: Hannes Tschofenig Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sun, 9 Jan 2011 19:12:51 +0200 Message-Id: <1CE51FB4-DCFC-4BBF-9BE8-2CC60B0C6D2D@gmx.net> To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] IETF#80: March 27-April 1, 2011 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: Sun, 09 Jan 2011 17:10:47 -0000 Hi all,=20 we have just submitted a request for a meeting slot at the IETF#80 = meeting. So, we will have an OAuth face-to-face meeting at the upcoming = IETF in Prague. =20 Please let us know whether you would like to give a presentation at the = working group session.=20 At previous IETF meetings some of you wanted to hold an interoperability = event. Let us know if there is interest in doing so at this IETF = meeting.=20 Ciao Hannes & Blaine PS: You may want to consider to submit (or to re-submit) your draft(s) = ASAP since we will do a working group re-chartering.=20 The submission deadlines for the meeting are:=20 =95 2011-03-07 (Monday): Internet Draft Cut-off for initial document = (-00) submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using = IETF ID Submission Tool. =95 2011-03-14 (Monday): Internet Draft final submission cut-off by = 17:00 PT (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission = Tool. More information about the submission tool and other important dates can = be found here:=20 http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80= From eran@hueniverse.com Sun Jan 9 09:16:44 2011 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 827883A67C2 for ; Sun, 9 Jan 2011 09:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, 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 icBFEDy8oRle for ; Sun, 9 Jan 2011 09:16:43 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B026C3A679F for ; Sun, 9 Jan 2011 09:16:43 -0800 (PST) Received: (qmail 4905 invoked from network); 9 Jan 2011 17:18:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jan 2011 17:18:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 9 Jan 2011 10:18:52 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 9 Jan 2011 10:18:50 -0700 Thread-Topic: OAuth MAC token type draft Thread-Index: AcuwIP0QyZaR42yQR/6NQvmBuI0wlQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth MAC token type draft 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: Sun, 09 Jan 2011 17:16:44 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token Feedback appreciated, especially for section 3.2.1 (the new normalized requ= est string) which is an attempt to take the HMAC-SHA1 flow from 1.0a and si= mplify it. No body signature support yet, but will add that in -01. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://tools.ietf.or= g/html/draft-hammer-oauth-v2-mac-token

 

Feedback appreciated, especial= ly for section 3.2.1 (the new normalized request string) which is an attemp= t to take the HMAC-SHA1 flow from 1.0a and simplify it.

 

No body signature= support yet, but will add that in -01.

=  

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1P3PW5EX1MB01E_-- From jricher@mitre.org Sun Jan 9 11:46:12 2011 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 C0F183A6833 for ; Sun, 9 Jan 2011 11:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.377 X-Spam-Level: X-Spam-Status: No, score=-4.377 tagged_above=-999 required=5 tests=[AWL=-1.778, 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 Io4vTqHvuW8l for ; Sun, 9 Jan 2011 11:46:12 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id DFAF13A67D4 for ; Sun, 9 Jan 2011 11:46:11 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5751A21B01D3; Sun, 9 Jan 2011 14:48:22 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5101B21B01C2; Sun, 9 Jan 2011 14:48:22 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Sun, 9 Jan 2011 14:48:22 -0500 From: "Richer, Justin P." To: Eran Hammer-Lahav , OAuth WG Date: Sun, 9 Jan 2011 14:46:50 -0500 Thread-Topic: OAuth MAC token type draft Thread-Index: AcuwIP0QyZaR42yQR/6NQvmBuI0wlQAFPiiF Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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: Sun, 09 Jan 2011 19:46:12 -0000 I'd like to see a way to use this mechanism without tokens -- that is, the = traditional two-legged signed-http-fetch approach. Maybe have the spec here= give details of a method using pre-shared client secrets instead of OAuth = tokens would be all it'd take.=20 -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Sunday, January 09, 2011 12:18 PM To: OAuth WG Subject: [OAUTH-WG] OAuth MAC token type draft http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token Feedback appreciated, especially for section 3.2.1 (the new normalized requ= est string) which is an attempt to take the HMAC-SHA1 flow from 1.0a and si= mplify it. No body signature support yet, but will add that in -01. EHL From eran@hueniverse.com Sun Jan 9 12:37:36 2011 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 0ACBD3A684A for ; Sun, 9 Jan 2011 12:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 7jkqooGhF+-2 for ; Sun, 9 Jan 2011 12:37:35 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3825A3A6845 for ; Sun, 9 Jan 2011 12:37:35 -0800 (PST) Received: (qmail 26414 invoked from network); 9 Jan 2011 20:39:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 9 Jan 2011 20:39:45 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 9 Jan 2011 13:39:45 -0700 From: Eran Hammer-Lahav To: "Richer, Justin P." , OAuth WG Date: Sun, 9 Jan 2011 13:39:43 -0700 Thread-Topic: OAuth MAC token type draft Thread-Index: AcuwIP0QyZaR42yQR/6NQvmBuI0wlQAFPiiFAAHUBGA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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: Sun, 09 Jan 2011 20:37:36 -0000 Well, you need the token as the identifier of the secret being used. So if = you think of a token as an 'id', then it works as is. EHL > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Sunday, January 09, 2011 11:47 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: OAuth MAC token type draft >=20 > I'd like to see a way to use this mechanism without tokens -- that is, th= e > traditional two-legged signed-http-fetch approach. Maybe have the spec > here give details of a method using pre-shared client secrets instead of > OAuth tokens would be all it'd take. >=20 > -- Justin >=20 > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran > Hammer-Lahav [eran@hueniverse.com] > Sent: Sunday, January 09, 2011 12:18 PM > To: OAuth WG > Subject: [OAUTH-WG] OAuth MAC token type draft >=20 > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >=20 > Feedback appreciated, especially for section 3.2.1 (the new normalized > request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a > and simplify it. >=20 > No body signature support yet, but will add that in -01. >=20 > EHL From eran@hueniverse.com Sun Jan 9 12:39:28 2011 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 85BF13A684C for ; Sun, 9 Jan 2011 12:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 OTDCpZLPxhme for ; Sun, 9 Jan 2011 12:39:27 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 69F863A684A for ; Sun, 9 Jan 2011 12:39:27 -0800 (PST) Received: (qmail 28793 invoked from network); 9 Jan 2011 20:41:38 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 9 Jan 2011 20:41:38 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 9 Jan 2011 13:41:37 -0700 From: Eran Hammer-Lahav To: Paul Walker Date: Sun, 9 Jan 2011 13:41:33 -0700 Thread-Topic: [OAUTH-WG] expired access token : deserves unique code? Thread-Index: Acuv24OElNjVC78ZSCyP1jEKzVQsiwAYen9w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <1D14AEE5-6D2E-4FFB-9396-50E0F8FADBC8@paulwalker.tv> <90C41DD21FB7C64BB94121FBBC2E723445A5AB724A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] expired access token : deserves unique code? 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: Sun, 09 Jan 2011 20:39:28 -0000 I don't have an opinion on this. On this matter, I simply follow consensus.= If you feel strong about an expired error value, just ask for it to be put= back in and we can negotiate the language. That's all it takes. But keep i= n mind we are at the end of the process so if you want it back, we need to = do it in -12 which is coming this week. EHL > -----Original Message----- > From: Paul Walker [mailto:catch-all@paulwalker.tv] > Sent: Sunday, January 09, 2011 12:59 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] expired access token : deserves unique code? >=20 > Brian, Eran, et all >=20 > I don't understand the need to discard relevant data while the authorizat= ion > between end user and provider are valid. >=20 >=20 > On Jan 7, 2011, at 11:10 PM, Eran Hammer-Lahav wrote: >=20 > > http://www.ietf.org/mail-archive/web/oauth/current/msg03734.html > > > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Paul Walker > >> Sent: Friday, January 07, 2011 4:53 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] expired access token : deserves unique code? > >> > >> As far as I can tell (which isn't very far on many Friday > >> afternoons), there is no way for a client to distinguish an expired > >> access token from a revoked, malformed, etc token as the > >> invalid_token error parameter value encompasses multiple scenarios. > >> Of course, a client could parse the error_description, but this is an > >> optional parameter with no guaranty of a common value among > providers. > >> > >> Given that the client would want to make an explicit decision to > >> request another access token using a refresh token (if available), > >> would it not benefit clients if a specific error parameter value was d= efined > for this scenario? > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Mon Jan 10 01:02:12 2011 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 4769428C113 for ; Mon, 10 Jan 2011 01:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, 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 YlK+BhW8GyY8 for ; Mon, 10 Jan 2011 01:02:11 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id BCBF228C112 for ; Mon, 10 Jan 2011 01:02:10 -0800 (PST) Received: (qmail invoked by alias); 10 Jan 2011 09:04:22 -0000 Received: from unknown (EHLO [10.255.131.194]) [192.100.123.77] by mail.gmx.net (mp063) with SMTP; 10 Jan 2011 10:04:22 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18GNEcU7UAGDP92qBpWHh1RqfbV+Bvb0X0ndV7vO+ 9B1dcmZ1BA6ov1 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246ADB21@TK5EX14MBXC202.redmond.corp.microsoft.com> Date: Mon, 10 Jan 2011 11:04:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943246ADB21@TK5EX14MBXC202.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] JSON Web Token (JWT) draft -01 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: Mon, 10 Jan 2011 09:02:12 -0000 I was wondering whether there is some running code available as well?=20 On Jan 5, 2011, at 4:31 AM, Mike Jones wrote: > Draft -01 of the JSON Web Token (JWT) specification is now available. = This version incorporates the consensus decisions reached at the = Internet Identity Workshop. The remaining open issues and to-do items = are documented in Section 12. As a reminder, the suggested = pronunciation of JWT is the same as the English word "jot". > =20 > The draft is available at these locations: > - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt > - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml > - http://self-issued.info/docs/draft-jones-json-web-token-01.html > - http://self-issued.info/docs/draft-jones-json-web-token-01.txt > - http://self-issued.info/docs/draft-jones-json-web-token-01.xml > - http://self-issued.info/docs/draft-jones-json-web-token.html (will = point to new versions as they are posted) > - http://self-issued.info/docs/draft-jones-json-web-token.txt (will = point to new versions as they are posted) > - http://self-issued.info/docs/draft-jones-json-web-token.xml (will = point to new versions as they are posted) > - http://svn.openid.net/repos/specifications/json_web_token/1.0/ = (Subversion repository, with html, txt, and html versions available) > =20 > The decisions reached at IIW are documented here: > - JSON Token Spec Results at IIW: http://self-issued.info/?p=3D361 > - JSON Token Encryption Spec Results at IIW: = http://self-issued.info/?p=3D378 > - JSON Token Naming Spec Results at IIW: = http://self-issued.info/?p=3D386 > - JSON Public Key Spec Results at IIW: = http://self-issued.info/?p=3D390 > =20 > This announcement is also posted here: > - http://self-issued.info/?p=3D446 > =20 > Thanks to all who provided the input that led to this draft! Feedback = is highly welcome. > =20 > -- = Mike > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From hannes.tschofenig@gmx.net Mon Jan 10 01:17:00 2011 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 CDC3D28C113 for ; Mon, 10 Jan 2011 01:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, 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 7aBok0Z+5Pc7 for ; Mon, 10 Jan 2011 01:17:00 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 6FCA028C0F6 for ; Mon, 10 Jan 2011 01:16:59 -0800 (PST) Received: (qmail invoked by alias); 10 Jan 2011 09:19:11 -0000 Received: from unknown (EHLO [10.255.131.194]) [192.100.123.77] by mail.gmx.net (mp055) with SMTP; 10 Jan 2011 10:19:11 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+q4KEuepGqQJs9xScwBehDc5XzeQXqsGmG80DRL8 jMfJzYSuX7necy From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 11:19:09 +0200 Message-Id: To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] BOF about "JSON Cryptographic Syntax and Processing" 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: Mon, 10 Jan 2011 09:17:00 -0000 Hi all,=20 Mike had posted a mail about version -01 of the JSON Web Token document: http://www.ietf.org/mail-archive/web/oauth/current/msg04912.html The usage of JSON and security applied to it became crucial to the work = in OAuth. =20 As we start our re-chartering it would be logical to add it to our = charter as well.=20 While this is my first choice there may be resistance in doing so since = we expand our charter quite a bit.=20 As a backup, I would therefore like to propose to (a) try to include it = in the OAuth re-chartering and (b) at the same time request a BOF at the = next IETF meeting.=20 Here is the charter writeup for the BOF:=20 http://ietherpad.com/ce7Vc6AAay Interestingly enough there are others in the IETF who also want to = standardize JSON signing and encryption (but for other use cases). I am = in contact with them and will try to combine our effort to reach the = goal faster.=20 Your comments on the charter writeup are appreciated.=20 Ciao Hannes From hannes.tschofenig@gmx.net Mon Jan 10 01:53:40 2011 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 75F0C28C0F2 for ; Mon, 10 Jan 2011 01:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, 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 thCzXRMjOSCq for ; Mon, 10 Jan 2011 01:53:39 -0800 (PST) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id 26C4F28C11A for ; Mon, 10 Jan 2011 01:53:38 -0800 (PST) Received: (qmail invoked by alias); 10 Jan 2011 09:55:51 -0000 Received: from unknown (EHLO [10.255.131.194]) [192.100.123.77] by mail.gmx.net (mp013) with SMTP; 10 Jan 2011 10:55:51 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX184Wccx8kQ4eSbT4u+kOVAQ8DPkJFOTpQKKkgT2yS GNcuGmC5cgeA13 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jan 2011 11:55:50 +0200 Message-Id: To: oauth@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Subject: [OAUTH-WG] Re-Chartering: What Items to work on? 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: Mon, 10 Jan 2011 09:53:40 -0000 Hi all,=20 In preparing the charter text we need your feedback.=20 First, the new charter needs to include the two new items we had already = accepted, namely=20 * SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ * The OAuth 2.0 Protocol: Bearer Tokens http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ In the past (around September / October 2010 timeframe) we had also = discussed other proposals. See attachment below.=20 We cannot just add everything to the charter because we will never be = able to finish it.=20 To make it more complicated there were other proposals floating around = but no drafts are available (e.g. security, discovery). It would be great to have a complete list of documents that should be = considered.=20 We would suggest to wait till the end of the month for new document = submissions to show up.=20 Then, we will start a Doodle poll to see your preference.=20 Ciao Hannes & Blaine PS: Here are some of the other documents that people wanted to spend = time on. There are more on the OAuth WG page. * Messaging Signing Examples:=20 http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ http://www.ietf.org/mail-archive/web/oauth/current/msg04250.html * User Experience Extensions Example:=20 http://datatracker.ietf.org/doc/draft-recordon-oauth-v2-ux/ * Artifact Binding Example:=20 http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ * Dynamic Client Registration Example:=20 http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt * Token Revocation: http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ * Use Cases=20 http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ From jricher@mitre.org Mon Jan 10 05:45:10 2011 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 1688328C166 for ; Mon, 10 Jan 2011 05:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-1.600, 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 5KsJfbmxZigH for ; Mon, 10 Jan 2011 05:45:09 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 282A228C161 for ; Mon, 10 Jan 2011 05:45:09 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 89AAE21B038F; Mon, 10 Jan 2011 08:47:22 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8347421B0366; Mon, 10 Jan 2011 08:47:22 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 10 Jan 2011 08:47:22 -0500 From: "Richer, Justin P." To: Eran Hammer-Lahav , OAuth WG Date: Mon, 10 Jan 2011 08:45:56 -0500 Thread-Topic: OAuth MAC token type draft Thread-Index: AcuwIP0QyZaR42yQR/6NQvmBuI0wlQAFPiiFAAHUBGAAI9vpLQ== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> , <90C41DD21FB7C64BB94121FBBC2E723445A5AB72D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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: Mon, 10 Jan 2011 13:45:10 -0000 Right -- if you substitute "token" with "client id" and "token secret" with= "client secret", then you've got the makings for 2-legged OAuth 2.0 right = there. I think you should call out that use case explicitly in your draft. -- Justin ________________________________________ From: Eran Hammer-Lahav [eran@hueniverse.com] Sent: Sunday, January 09, 2011 3:39 PM To: Richer, Justin P.; OAuth WG Subject: RE: OAuth MAC token type draft Well, you need the token as the identifier of the secret being used. So if = you think of a token as an 'id', then it works as is. EHL > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Sunday, January 09, 2011 11:47 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: OAuth MAC token type draft > > I'd like to see a way to use this mechanism without tokens -- that is, th= e > traditional two-legged signed-http-fetch approach. Maybe have the spec > here give details of a method using pre-shared client secrets instead of > OAuth tokens would be all it'd take. > > -- Justin > > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran > Hammer-Lahav [eran@hueniverse.com] > Sent: Sunday, January 09, 2011 12:18 PM > To: OAuth WG > Subject: [OAUTH-WG] OAuth MAC token type draft > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > Feedback appreciated, especially for section 3.2.1 (the new normalized > request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a > and simplify it. > > No body signature support yet, but will add that in -01. > > EHL From torsten@lodderstedt.net Mon Jan 10 08:45:27 2011 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 067703A680B for ; Mon, 10 Jan 2011 08:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.571 X-Spam-Level: X-Spam-Status: No, score=-0.571 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 RgtzEgJeAWIn for ; Mon, 10 Jan 2011 08:45:26 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id F06493A67FA for ; Mon, 10 Jan 2011 08:45:25 -0800 (PST) Received: from [80.187.105.163] (helo=[192.168.43.164]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PcKu9-0004Hg-PF; Mon, 10 Jan 2011 17:47:38 +0100 Message-ID: <4D2B3828.9030605@lodderstedt.net> Date: Mon, 10 Jan 2011 17:47:36 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445328CB1D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445328CB1D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------010707080402030500070503" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Final cuts and 3 interoperable implementations 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: Mon, 10 Jan 2011 16:45:27 -0000 This is a multi-part message in MIME format. --------------010707080402030500070503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit please include me on behalf of Deutsche Telekom regards, Torsten. Am 05.01.2011 19:26, schrieb Eran Hammer-Lahav: > > In the next few weeks I plan to survey existing and planned > implementations of each feature of the specification and those > components without at least 3 interoperable (or compliant) > implementations will be a candidate for removal from the specification > (can still be published as an extension). The goal is to publish a > specification which has complete code coverage. I should strive to > produce a specification that is grounded in actual deployment plans, > not just projected theory. > > If you (or your company) are implementing or plan to, please let me > know so I can include you in the survey. > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010707080402030500070503 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit please include me on behalf of Deutsche Telekom

regards,
Torsten.
Am 05.01.2011 19:26, schrieb Eran Hammer-Lahav:

In the next few weeks I plan to survey existing and planned implementations of each feature of the specification and those components without at least 3 interoperable (or compliant) implementations will be a candidate for removal from the specification (can still be published as an extension). The goal is to publish a specification which has complete code coverage. I should strive to produce a specification that is grounded in actual deployment plans, not just projected theory.

 

If you (or your company) are implementing or plan to, please let me know so I can include you in the survey.

 

EHL


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

--------------010707080402030500070503-- From Michael.Jones@microsoft.com Mon Jan 10 08:45:48 2011 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 A690F28C0E5 for ; Mon, 10 Jan 2011 08:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.021, 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 fsoNrp1YGi+6 for ; Mon, 10 Jan 2011 08:45:42 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 4D9683A680B for ; Mon, 10 Jan 2011 08:45:42 -0800 (PST) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 10 Jan 2011 08:47:51 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0255.003; Mon, 10 Jan 2011 08:47:50 -0800 From: Mike Jones To: Eran Hammer-Lahav Thread-Topic: Feedback on normative issues in OAuth2 draft 11 from implementers of draft 10 Thread-Index: Acuw5hWrC4awyXf8SdenjArIbRiC8Q== Date: Mon, 10 Jan 2011 16:47:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246BAE0C@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246BAE0CTK5EX14MBXC202r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Feedback on normative issues in OAuth2 draft 11 from implementers of draft 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: Mon, 10 Jan 2011 16:45:48 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246BAE0CTK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Our implementers of draft 10 have raised the following issues with draft 11= . Please address them before publishing a draft 12. I'll send editorial = feedback in a separate message. 6.2 etc.: Specification MUST permit parameter extensibility There will be uses of OAuth2 where additional parameters need to be passed = in the messages. While some messages implicitly permit extensibility throu= gh language like 4.1's "the client constructs the request URI by adding the= following parameters to the end-user authorization endpoint URI query comp= onent" others do not. In particular, the BNF for the WWW-Authenticate Resp= onse in 6.2 appears to permit only a fixed set of parameters (scope, error,= error-desc, error-uri, token). This must be addressed. Please add language to 6.2 that explicitly allows for other arguments to be= added to the response and mandates that they be ignored if not recognized.= Also, define an IANA registration process for registering new parameter v= alues for all messages. In particular, even if the following request to add an optional "resource" = parameter is not adopted, it must be possible to add one to all relevant me= ssages so that a "resource" parameter can be added as a legal extension. 4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1: "Scope" parameter should be pa= ired with complimentary "resource" parameter It is desirable to be able to have a single service protecting multiple res= ources. To achieve that, there needs to be a parameter specifying what the= desired resource being accessed is. This is different than scope. At lea= st as we're using it, "scope" would be a space-separated list of kinds of a= ccess requested. For instance you might be requesting read access to someo= ne's calendar free/busy times and the right to post new calendar requests. = Those would be scope statements and would use URIs specifying those rights= . Therefore, we request that an additional optional "resource" parameter be a= dded to the specification in the same places that "scope" appears. "Resour= ce" would be the URI (probably a URL) of the resource being protected by th= e service. 5.1.3 etc.: The name client_credentials is confusing The name client_credentials does not refer to the same concept as the uses = of the term "Client Credentials" in 1.4.3, 3, 5.1.3, and other locations in= the document. It would be far better to rename this parameter "none" or "= implicit", to indicate that no explicit credentials are being passed in the= protocol. It might also clarify this concept if you added an example. 6.2: Token_type needed for WWW-Authenticate Response An optional token_type parameter should be added to the WWW-Authenticate Re= sponse. This, paired with adding this parameter to the authenticated token= requests in the bearer token spec, will complete the ability to communicat= e token type information for all legs of the protocol. TBDs And of course, we're very interested in seeing the write-ups for adding tok= en types in 6.1 and new credential types in 7.1 Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943246BAE0CTK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our implementers of draft 10 have raised the followi= ng issues with draft 11.  Please address them before publishing a draf= t 12.   I’ll send editorial feedback in a separate message.=

 

6.2 etc.:  Specification MUST permit paramet= er extensibility

 

There will be uses of OAuth2 where additional parame= ters need to be passed in the messages.  While some messages implicitl= y permit extensibility through language like 4.1’s “the client = constructs the request URI by adding the following parameters to the end-user authorization endpoint URI query component̶= 1; others do not.  In particular, the BNF for the WWW-Authenticate Res= ponse in 6.2 appears to permit only a fixed set of parameters (scope, error= , error-desc, error-uri, token).  This must be addressed.

 

Please add language to 6.2 that explicitly allows fo= r other arguments to be added to the response and mandates that they be ign= ored if not recognized.  Also, define an IANA registration process for= registering new parameter values for all messages.

 

In particular, even if the following request to add = an optional “resource” parameter is not adopted, it must be pos= sible to add one to all relevant messages so that a “resource” = parameter can be added as a legal extension.

 

4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1:  = ;“Scope” parameter should be paired with complimentary “r= esource” parameter

 

It is desirable to be able to have a single service = protecting multiple resources.  To achieve that, there needs to be a p= arameter specifying what the desired resource being accessed is.  This= is different than scope.  At least as we’re using it, “scope” would be a space-separated list of kinds of = access requested.  For instance you might be requesting read access to= someone’s calendar free/busy times and the right to post new calenda= r requests.  Those would be scope statements and would use URIs specifying those rights.

 

Therefore, we request that an additional optional &#= 8220;resource” parameter be added to the specification in the same pl= aces that “scope” appears.  “Resource” would b= e the URI (probably a URL) of the resource being protected by the service.<= o:p>

 

5.1.3 etc.:  The name client_credentials is = confusing

 

The name client_credentials does not refer to the sa= me concept as the uses of the term “Client Credentials” in 1.4.= 3, 3, 5.1.3, and other locations in the document.  It would be far bet= ter to rename this parameter “none” or “implicit”, to indicate that no explicit credentials are being passed in the protocol.=   It might also clarify this concept if you added an example.

 

6.2:  Token_type needed for WWW-Authenticate= Response

 

An optional token_type parameter should be added to = the WWW-Authenticate Response.  This, paired with adding this paramete= r to the authenticated token requests in the bearer token spec, will comple= te the ability to communicate token type information for all legs of the protocol.

 

TBDs

 

And of course, we’re very interested in seeing= the write-ups for adding token types in 6.1 and new credential types in 7.= 1

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thanks,

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943246BAE0CTK5EX14MBXC202r_-- From jricher@mitre.org Mon Jan 10 08:49:38 2011 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 C056B3A680B for ; Mon, 10 Jan 2011 08:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.054 X-Spam-Level: X-Spam-Status: No, score=-4.054 tagged_above=-999 required=5 tests=[AWL=-1.455, 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 DC2490zLnHoW for ; Mon, 10 Jan 2011 08:49:38 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 0C0123A67FA for ; Mon, 10 Jan 2011 08:49:37 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C0ED621B03F0; Mon, 10 Jan 2011 11:51:51 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BAD5C21B03B7; Mon, 10 Jan 2011 11:51:51 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 10 Jan 2011 11:51:51 -0500 From: "Richer, Justin P." To: Mike Jones , Eran Hammer-Lahav Date: Mon, 10 Jan 2011 11:49:45 -0500 Thread-Topic: [OAUTH-WG] Feedback on normative issues in OAuth2 draft 11 from implementers of draft 10 Thread-Index: Acuw5hWrC4awyXf8SdenjArIbRiC8QAAE2Dw Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943246BAE0C@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246BAE0C@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Feedback on normative issues in OAuth2 draft 11 from implementers of draft 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: Mon, 10 Jan 2011 16:49:38 -0000 > 5.1.3 etc.: The name client_credentials is confusing > The name client_credentials does not refer to the same concept as the use= s of the term =93Client Credentials=94 in 1.4.3, 3, 5.1.3, and other locati= ons in the document. It would be far better to rename this parameter =93no= ne=94 or =93implicit=94, to indicate that no explicit credentials are being= passed in the protocol. It might also clarify this concept if you added a= n example. There are explicit credentials here -- the client id and secret. Naming it = "none" or "implicit" would be even more confusing, IMHO, since that implies= that you're just handing out tokens to whoever asks. I agree that it needs= to be called out more in the document, though, and an example would go a l= ong way to this.=20 -- Justin= From Michael.Jones@microsoft.com Mon Jan 10 08:49:51 2011 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 4891B3A6B03 for ; Mon, 10 Jan 2011 08:49:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.579 X-Spam-Level: X-Spam-Status: No, score=-10.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, 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 OhO8BxURaCVx for ; Mon, 10 Jan 2011 08:49:49 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id C0D283A6AFF for ; Mon, 10 Jan 2011 08:49:49 -0800 (PST) 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; Mon, 10 Jan 2011 08:52:02 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Mon, 10 Jan 2011 08:52:03 -0800 From: Mike Jones To: Hannes Tschofenig Thread-Topic: [OAUTH-WG] JSON Web Token (JWT) draft -01 Thread-Index: AcusgKJ+3djISrh8R1G//+yyZSLxUwEZ8lwAAAB38PA= Date: Mon, 10 Jan 2011 16:52:02 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246BAE37@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943246ADB21@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] JSON Web Token (JWT) draft -01 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: Mon, 10 Jan 2011 16:49:51 -0000 Not that I'm aware of at present, but I expect that to change shortly. -- Mike -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Monday, January 10, 2011 1:04 AM To: Mike Jones Cc: Hannes Tschofenig; oauth@ietf.org Subject: Re: [OAUTH-WG] JSON Web Token (JWT) draft -01 I was wondering whether there is some running code available as well?=20 On Jan 5, 2011, at 4:31 AM, Mike Jones wrote: > Draft -01 of the JSON Web Token (JWT) specification is now available. Th= is version incorporates the consensus decisions reached at the Internet Ide= ntity Workshop. The remaining open issues and to-do items are documented i= n Section 12. As a reminder, the suggested pronunciation of JWT is the sam= e as the English word "jot". > =20 > The draft is available at these locations: > - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt > - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml > - http://self-issued.info/docs/draft-jones-json-web-token-01.html > - http://self-issued.info/docs/draft-jones-json-web-token-01.txt > - http://self-issued.info/docs/draft-jones-json-web-token-01.xml > - http://self-issued.info/docs/draft-jones-json-web-token.html (will po= int to new versions as they are posted) > - http://self-issued.info/docs/draft-jones-json-web-token.txt (will poi= nt to new versions as they are posted) > - http://self-issued.info/docs/draft-jones-json-web-token.xml (will poi= nt to new versions as they are posted) > - http://svn.openid.net/repos/specifications/json_web_token/1.0/=20 > (Subversion repository, with html, txt, and html versions available) > =20 > The decisions reached at IIW are documented here: > - JSON Token Spec Results at IIW: http://self-issued.info/?p=3D361 > - JSON Token Encryption Spec Results at IIW: http://self-issued.info/?= p=3D378 > - JSON Token Naming Spec Results at IIW: http://self-issued.info/?p=3D= 386 > - JSON Public Key Spec Results at IIW: =20 > http://self-issued.info/?p=3D390 > =20 > This announcement is also posted here: > - http://self-issued.info/?p=3D446 > =20 > Thanks to all who provided the input that led to this draft! Feedback is= highly welcome. > =20 > --=20 > Mike _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Mon Jan 10 08:51:20 2011 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 34BC53A69CC for ; Mon, 10 Jan 2011 08:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 qFFb21nb7nL8 for ; Mon, 10 Jan 2011 08:51:19 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 059723A6808 for ; Mon, 10 Jan 2011 08:51:18 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 10 Jan 2011 08:53:32 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Mon, 10 Jan 2011 08:53:31 -0800 From: Mike Jones To: Hannes Tschofenig , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] BOF about "JSON Cryptographic Syntax and Processing" Thread-Index: AQHLsKeD5kSBEThskEeOmjRWIR3Q+5PKbFxg Date: Mon, 10 Jan 2011 16:53:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246BAE5D@TK5EX14MBXC202.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] BOF about "JSON Cryptographic Syntax and Processing" 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: Mon, 10 Jan 2011 16:51:20 -0000 Please put me in touch with the others who are working on JSON signing and = encryption so we can coordinate our efforts. Thanks! -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Monday, January 10, 2011 1:19 AM To: oauth@ietf.org Subject: [OAUTH-WG] BOF about "JSON Cryptographic Syntax and Processing" Hi all,=20 Mike had posted a mail about version -01 of the JSON Web Token document: http://www.ietf.org/mail-archive/web/oauth/current/msg04912.html The usage of JSON and security applied to it became crucial to the work in = OAuth. =20 As we start our re-chartering it would be logical to add it to our charter = as well.=20 While this is my first choice there may be resistance in doing so since we = expand our charter quite a bit.=20 As a backup, I would therefore like to propose to (a) try to include it in = the OAuth re-chartering and (b) at the same time request a BOF at the next = IETF meeting.=20 Here is the charter writeup for the BOF:=20 http://ietherpad.com/ce7Vc6AAay Interestingly enough there are others in the IETF who also want to standard= ize JSON signing and encryption (but for other use cases). I am in contact = with them and will try to combine our effort to reach the goal faster.=20 Your comments on the charter writeup are appreciated.=20 Ciao Hannes _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From pathogenix@gmail.com Mon Jan 10 09:01:51 2011 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 698893A67B8 for ; Mon, 10 Jan 2011 09:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9Vmty7eMsTO for ; Mon, 10 Jan 2011 09:01:50 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 43DC83A67AB for ; Mon, 10 Jan 2011 09:01:50 -0800 (PST) Received: by qwi2 with SMTP id 2so4281079qwi.31 for ; Mon, 10 Jan 2011 09:04:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=7Cv5cRNXXvvyrYW0yjXeos9hzF3NithtqX+gUKr9R9A=; b=kArJSjd1dtTTu8fB6452e7ZpB4NxfSOcB7QOnO7RAM1KrlO3BQF+39vmAQ9kTTTF9b QejeHdXeq9H5Gace1YOUnWG17idJcHgkHjC8sQm+Kf9qjREjPuR3nRaJaE3YrI8od8ao 4g/MFysHHjkG5LdO7LiJhRN8u/QpL6AHy8xx0= 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 :content-type; b=CKcDIsXOyAzHlJBbXDlyz4Pts67+NZL5fZLYc+iaRdf3jOysNAe6lzyYbjjg1BdB4d GXp4kEDu1bdW0yQI5JqFZvWZLs4i2VZQi+pT02pUwLdds/jwr/U8Z3Cym7tPqRDljE2Y 83T3saycSCBg/UlJz2gDkg/Z/82/8AGV6VMpg= MIME-Version: 1.0 Received: by 10.229.185.1 with SMTP id cm1mr25354023qcb.81.1294679042962; Mon, 10 Jan 2011 09:04:02 -0800 (PST) Received: by 10.229.217.82 with HTTP; Mon, 10 Jan 2011 09:04:02 -0800 (PST) In-Reply-To: <4D2B3828.9030605@lodderstedt.net> References: <90C41DD21FB7C64BB94121FBBC2E723445328CB1D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2B3828.9030605@lodderstedt.net> Date: Mon, 10 Jan 2011 17:04:02 +0000 Message-ID: From: Bob Gregory To: OAuth WG Content-Type: multipart/alternative; boundary=00163631002f743420049980f447 X-Mailman-Approved-At: Mon, 10 Jan 2011 09:03:44 -0800 Subject: Re: [OAUTH-WG] Final cuts and 3 interoperable implementations 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: Mon, 10 Jan 2011 17:02:24 -0000 --00163631002f743420049980f447 Content-Type: text/plain; charset=ISO-8859-1 I'd like to be included on behalf of Huddle.com On Mon, Jan 10, 2011 at 4:47 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > please include me on behalf of Deutsche Telekom > > regards, > Torsten. > Am 05.01.2011 19:26, schrieb Eran Hammer-Lahav: > > In the next few weeks I plan to survey existing and planned > implementations of each feature of the specification and those components > without at least 3 interoperable (or compliant) implementations will be a > candidate for removal from the specification (can still be published as an > extension). The goal is to publish a specification which has complete code > coverage. I should strive to produce a specification that is grounded in > actual deployment plans, not just projected theory. > > > > If you (or your company) are implementing or plan to, please let me know so > I can include you in the survey. > > > > EHL > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > -- An infinite number of mathematicians walk into a bar. The first one orders a beer. The second orders half a beer. The third, a quarter of a beer. The bartender says "You're all idiots", and pours two beers. --00163631002f743420049980f447 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to be included on behalf of Huddle.com

On Mon, Jan 10, 2011 at 4:47 PM, Torsten Lodderstedt <torsten@lodderstedt= .net> wrote:
=20 =20 =20
please include me on behalf of Deutsche Telekom

regards,
Torsten.
Am 05.01.2011 19:26, schrieb Eran Hammer-Lahav:
=20 =20 =20

In the next few weeks I plan to survey existing and planned implementations of each feature of the specification and those components without at least 3 interoperable (or compliant) implementations will be a candidate for removal from the specification (can still be published as an extension). The goal is to publish a specification which has complete code coverage. I should strive to produce a specification that is grounded in actual deployment plans, not just projected theory.

=A0

If you (or your company) are implementing or plan to, please let me know so I can include you in the survey.

=A0

EHL


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




--
An infinite number of m= athematicians walk into a bar. The first one orders a beer. The second orde= rs half a beer. The third, a quarter of a beer. The bartender says "Yo= u're all idiots", and pours two beers.
--00163631002f743420049980f447-- From zachary.zeltsan@alcatel-lucent.com Mon Jan 10 09:46:36 2011 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 98FAA3A6B07 for ; Mon, 10 Jan 2011 09:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 S8xtqMZQ15fZ for ; Mon, 10 Jan 2011 09:46:35 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 6589D3A6821 for ; Mon, 10 Jan 2011 09:46:35 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0AHmleG002323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jan 2011 11:48:47 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0AHmYQW006811 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 10 Jan 2011 11:48:47 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Mon, 10 Jan 2011 11:48:38 -0600 From: "Zeltsan, Zachary (Zachary)" To: "'Hannes Tschofenig'" , "oauth@ietf.org" Date: Mon, 10 Jan 2011 11:48:38 -0600 Thread-Topic: [OAUTH-WG] IETF#80: March 27-April 1, 2011 Thread-Index: Acuw7XKfiVLbNV6yQCK9Qj2am8TQ1wAAEmaA Message-ID: <5710F82C0E73B04FA559560098BF95B12505F04080@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <1CE51FB4-DCFC-4BBF-9BE8-2CC60B0C6D2D@gmx.net> In-Reply-To: <1CE51FB4-DCFC-4BBF-9BE8-2CC60B0C6D2D@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: Re: [OAUTH-WG] IETF#80: March 27-April 1, 2011 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: Mon, 10 Jan 2011 17:46:36 -0000 Blaine, Hanes, We plan to submit the next version of the draft on the OAuth use cases for = the IETF 80. I would like to present it at the meeting. With thanks, Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H= annes Tschofenig Sent: Sunday, January 09, 2011 12:13 PM To: oauth@ietf.org Subject: [OAUTH-WG] IETF#80: March 27-April 1, 2011 Hi all,=20 we have just submitted a request for a meeting slot at the IETF#80 meeting.= So, we will have an OAuth face-to-face meeting at the upcoming IETF in Pra= gue. =20 Please let us know whether you would like to give a presentation at the wor= king group session.=20 At previous IETF meetings some of you wanted to hold an interoperability ev= ent. Let us know if there is interest in doing so at this IETF meeting.=20 Ciao Hannes & Blaine PS: You may want to consider to submit (or to re-submit) your draft(s) ASAP= since we will do a working group re-chartering.=20 The submission deadlines for the meeting are:=20 * 2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00) su= bmission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using IETF ID Sub= mission Tool. * 2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT = (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool. More information about the submission tool and other important dates can be= found here:=20 http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jan 10 09:56:42 2011 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 006293A6AFC for ; Mon, 10 Jan 2011 09:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gsttmetz6LR4 for ; Mon, 10 Jan 2011 09:56:41 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E10F13A6822 for ; Mon, 10 Jan 2011 09:56:40 -0800 (PST) Received: (qmail 23851 invoked from network); 10 Jan 2011 17:58:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jan 2011 17:58:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 Jan 2011 10:58:46 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Mon, 10 Jan 2011 10:58:41 -0700 Thread-Topic: Feedback on normative issues in OAuth2 draft 11 from implementers of draft 10 Thread-Index: Acuw5hWrC4awyXf8SdenjArIbRiC8QAB+6Jw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB740C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943246BAE0C@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246BAE0C@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Feedback on normative issues in OAuth2 draft 11 from implementers of draft 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: Mon, 10 Jan 2011 17:56:42 -0000 > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Monday, January 10, 2011 8:48 AM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Feedback on normative issues in OAuth2 draft 11 from > implementers of draft 10 >=20 > Our implementers of draft 10 have raised the following issues with draft > 11.=A0 Please address them before publishing a draft 12.=A0 =A0I'll send = editorial > feedback in a separate message. >=20 > 6.2 etc.: =A0Specification MUST permit parameter extensibility >=20 > There will be uses of OAuth2 where additional parameters need to be > passed in the messages.=A0 While some messages implicitly permit extensib= ility > through language like 4.1's "the client constructs the request URI by add= ing > the following parameters to the end-user authorization endpoint URI query > component" others do not.=A0 In particular, the BNF for the WWW- > Authenticate Response in 6.2 appears to permit only a fixed set of > parameters (scope, error, error-desc, error-uri, token).=A0 This must be > addressed. 'token' is an ABNF term, not access-token. It means you can add anything yo= u want (at least according to the ABNF). > Please add language to 6.2 that explicitly allows for other arguments to = be > added to the response and mandates that they be ignored if not > recognized. =A0Also, define an IANA registration process for registering = new > parameter values for all messages. I'm confused. You mean section 7.3? > In particular, even if the following request to add an optional "resource= " > parameter is not adopted, it must be possible to add one to all relevant > messages so that a "resource" parameter can be added as a legal extension= . What in section 7 is missing, preventing you from doing this? > 4.1, 4.2, 4.3.1, 5, 5.2, 5.3.1, 6.2, 6.2.1: =A0"Scope" parameter should b= e paired > with complimentary "resource" parameter > > It is desirable to be able to have a single service protecting multiple > resources.=A0 To achieve that, there needs to be a parameter specifying w= hat > the desired resource being accessed is.=A0 This is different than scope.= =A0 At least > as we're using it, "scope" would be a space-separated list of kinds of ac= cess > requested.=A0 For instance you might be requesting read access to someone= 's > calendar free/busy times and the right to post new calendar requests.=A0 = Those > would be scope statements and would use URIs specifying those rights. >=20 > Therefore, we request that an additional optional "resource" parameter be > added to the specification in the same places that "scope" > appears.=A0 "Resource" would be the URI (probably a URL) of the resource > being protected by the service. Already rejected by the WG due to lack of consensus. I suggest you draft an= extension and see where it goes. =20 > 5.1.3 etc.: =A0The name client_credentials is confusing >=20 > The name client_credentials does not refer to the same concept as the use= s > of the term "Client Credentials" in 1.4.3, 3, 5.1.3, and other locations = in the > document.=A0 It would be far better to rename this parameter "none" or > "implicit", to indicate that no explicit credentials are being passed in = the > protocol.=A0 It might also clarify this concept if you added an example. Both none and implicit were rejected. The current name has consensus. > 6.2:=A0 Token_type needed for WWW-Authenticate Response >=20 > An optional token_type parameter should be added to the WWW- > Authenticate Response.=A0 This, paired with adding this parameter to the > authenticated token requests in the bearer token spec, will complete the > ability to communicate token type information for all legs of the protoco= l. We don't have consensus to add support for requesting a specific token type= (by the client), or to advertise discovery information (which token types = are supported, and available for the client to request). This is not trivia= l. I suggest publishing an extension defining this and see where it goes. As a general note, both the 'resource' and 'token_type' requests lack suffi= cient detail to be added to the specification at this late stage. We have a= very stable draft that is almost ready for last-call. Adding significant n= ew functionality should only be permitted if the protocol will not be useab= le otherwise. This is, of course, just a general principal, but if somethi= ng can be defined as an extension, it should to avoid delaying the framewor= k spec. EHL From eran@hueniverse.com Mon Jan 10 11:51:41 2011 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 239CD28C0E4 for ; Mon, 10 Jan 2011 11:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.073, 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 uYchcWJ61nY0 for ; Mon, 10 Jan 2011 11:51:37 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8BCED28C106 for ; Mon, 10 Jan 2011 11:51:36 -0800 (PST) Received: (qmail 8028 invoked from network); 10 Jan 2011 19:53:50 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jan 2011 19:53:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 Jan 2011 12:53:45 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 10 Jan 2011 12:53:42 -0700 Thread-Topic: Error codes registry Thread-Index: Acuw/7fM0iwVhGdDSCuEQBgjK5iWrw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB747E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB747EP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Error codes registry 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: Mon, 10 Jan 2011 19:51:41 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB747EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am questioning the value of an explicit extension mechanism (and registry= ) for error codes. It seems like an overkill since name collisions are not = likely or as problematic (given new error codes imply some other extension = involved as well). I am going to drop notes about error code extensibility. If you have an obj= ection, please propose an extension mechanism. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB747EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am questioning= the value of an explicit extension mechanism (and registry) for error code= s. It seems like an overkill since name collisions are not likely or as pro= blematic (given new error codes imply some other extension involved as well= ).

 

I am going to drop notes about error code extensibility. If you have a= n objection, please propose an extension mechanism.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB747EP3PW5EX1MB01E_-- From torsten@lodderstedt.net Mon Jan 10 11:57:57 2011 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 A24D228C0F4 for ; Mon, 10 Jan 2011 11:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.020, 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 EjHJqRmmW-dl for ; Mon, 10 Jan 2011 11:57:56 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 8C60728B23E for ; Mon, 10 Jan 2011 11:57:56 -0800 (PST) Received: from [79.253.31.222] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PcNuO-0001p6-33; Mon, 10 Jan 2011 21:00:04 +0100 Message-ID: <4D2B6543.2090101@lodderstedt.net> Date: Mon, 10 Jan 2011 21:00:03 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian Campbell References: <4E1F6AAD24975D4BA5B168042967394324649C50@TK5EX14MBXC201.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1127AA90906@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations 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: Mon, 10 Jan 2011 19:57:57 -0000 Independent of where this items belong to, the advice to only hand out tokens to authenticated clients is stronger as required by the core spec. There is a whole class of clients (native apps), which cannot keep secrets for the purpose of authentication. Moreover, what is the benefit of authenticating clients? regards, Torsten. Am 13.12.2010 15:00, schrieb Brian Campbell: > I think James makes a good point here. > > On Thu, Dec 9, 2010 at 10:45 PM, Manger, James H > wrote: >> I think these items shouldn't be in the bearer spec at all. They are about "getting a token", not about "using a bearer token" so they should be left to the core spec. >> >> -- >> James Manger >> >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell >> Sent: Thursday, December 09, 2010 1:38 PM >> To: oauth >> Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations >> >> I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however, a couple things jumped out at me in areas that hadn't received much attention yet so I wanted to raise the questions on a separate thread. >> >> Near the end of section 3.2. Threat Mitigation, it says: >> >> " Furthermore, the resource server MUST ensure that it only hands out >> tokens to clients it has authenticated first and authorized. For >> this purpose, the client MUST be authenticated and authorized by the >> resource server. " >> >> Was the intent here to say authorization server rather than resource server? The resource server doesn't hand out tokens. Also, aren't there legitimate cases where the client isn't authenticated (anonymous or other cases where the client can't keep secrets)? >> >> Then it says: >> >> "The authorization server MUST also receive a >> confirmation (the consent of the resource owner) prior to providing a >> token to the client." >> >> Does this allow for implicit consent? On my first read of it, I interpret this as potentially being more restrictive than what is in >> draft-ietf-oauth-v2-11 >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Mon Jan 10 12:01:25 2011 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 EB9453A6B11 for ; Mon, 10 Jan 2011 12:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Mr1SWr5f+UQ4 for ; Mon, 10 Jan 2011 12:01:25 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id AAEDE3A6B27 for ; Mon, 10 Jan 2011 12:01:24 -0800 (PST) Received: from [79.253.31.222] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PcNxp-0006GF-Fc; Mon, 10 Jan 2011 21:03:37 +0100 Message-ID: <4D2B6619.9040605@lodderstedt.net> Date: Mon, 10 Jan 2011 21:03:37 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mike Jones , OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] Comments on OAuth 2.0 Bearer Token specification draft -01 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: Mon, 10 Jan 2011 20:01:26 -0000 Hi Mike, I've got some more comments on § 3.2 of your I-D. paragraph 4: "Encrypting the token contents is another alternative ..." How does token content encryption prevent the disclosure and abuse of a token? paragraph 5: "For those rare cases where the client is prevented from observing the contents of the token, token encryption has to be applied in addition to the usage of TLS protection" How did you come to the conclusion these are _rare_ cases? The token is used to pass data between authorization server and resource server via the client as a intermediary. A self-contained token may contain a lot of user-specific or service provider internal information neither end-user nor authorization server would like to disclose to the client. Therefore, here at Deutsche Telekom we encrypt token contents per default. paragraph 6: "To deal with token reuse, ... " The "reuse" appears a bit misleading, isn't this paragraph talking about capture/tap and replay attacks? regards, Torsten. From progrium@twilio.com Mon Jan 10 12:07:16 2011 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 AA1473A6B31 for ; Mon, 10 Jan 2011 12:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.476 X-Spam-Level: X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 kyv7Mqa12QN4 for ; Mon, 10 Jan 2011 12:07:14 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id E62E73A6B30 for ; Mon, 10 Jan 2011 12:07:12 -0800 (PST) Received: by gxk28 with SMTP id 28so9112301gxk.31 for ; Mon, 10 Jan 2011 12:09:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.90.10.31 with SMTP id 31mr6667435agj.85.1294690167181; Mon, 10 Jan 2011 12:09:27 -0800 (PST) Received: by 10.90.83.15 with HTTP; Mon, 10 Jan 2011 12:09:27 -0800 (PST) In-Reply-To: References: Date: Mon, 10 Jan 2011 12:09:27 -0800 Message-ID: From: Jeff Lindsay To: Dick Hardt Content-Type: multipart/alternative; boundary=0016361e7cb08253050499838b63 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01 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: Mon, 10 Jan 2011 20:07:16 -0000 --0016361e7cb08253050499838b63 Content-Type: text/plain; charset=ISO-8859-1 Dick, thanks for the response. I think I'm behind everything you've said. Perhaps the crux is in library vs user/developer implementation. I'm interested in less steps not for computational overhead, but for mental overhead and usability. I would love to have (and even contribute) standard libraries in various languages (we'll have to anyway if we do adopt this), but for now because we're an API (like Facebook) and our docs are about using our API. They assume all you need are the standard libraries in most programming environments. Right now, that means users implementing JWTs by hand. While we have libraries for our APIs, we have to design the API so that you don't *have* to use these libraries... otherwise, we might as well be a SOAP web service. So I'm wondering what people's idea are on how to start using/implementing this now without standard libraries, assuming we don't want to make the process any easier. My hypothesis is the response from you all will be, "just have the JWT process in your docs, it's easy enough. We're not worried about this odd phase of early adoption with no standard library." -jeff On Fri, Jan 7, 2011 at 10:42 AM, Dick Hardt wrote: > Hi Jeff > > Thanks for the feedback. A healthy debate is how we optimize a spec! > > Will a slightly shorter token be significant for you? Is the rest of the > message so short that a smaller token will have a significant impact? > > The hope is that if we standardize JWT, that libraries will be developed so > that the average developer does not need to deal with the details. > > We are having to balance between a generalized solution and a simple, > specific solution. > > Too specific and the spec does not solve a broad enough set of people's > needs, libraries don't get developed, or if they do, the code coverage is > nominal and they are not well maintained. This leads to more security risks > and higher barrier to deployment. > > Too generic and the complexity in the library adds more security risks, > less likely someone will implement a library and deploy. > > The header makes it easy for a generic library to quickly see what the rest > of the token is, enables support for encrypted payloads (can't do that if > the crypto info is in the payload), and provides a simple path for > extensions / expansion. > > While I can appreciate doing less encodings operations, the encoding is > already being used, so this is a slight additional computational overhead. > Your suggestion for checking the number of periods may actually add back the > computational overhead, and a separate code path to be tested leading to > less secure code. Happy to elaborate more if that was not clear and > compelling! > > -- Dick > > On 2011-01-06, at 7:29 PM, Jeff Lindsay wrote: > > Hi everyone! > > I'm really excited about this spec (and OAuth2), as are others here at > Twilio. I've been watching it since Paul implemented an early version at > Facebook. We also implemented it in an early iteration of a product we're > working on, but now we're coming back to it as a means of authentication > that would be key to the entire Twilio API... and since our API *is* our > product, we're very touchy about the details. > > I've only been glancing at its progress since the early drafts as various > versions were integrated and issues sorted out. I was afraid that it was > going to have gotten a lot more complicated, but looking at this I'm pretty > happy to see most of the additions are optional. > > Like Paul, I'm not a fan of the short names. However, I've sort of accepted > it, especially since as reserved keys they are less likely to conflict with > keys we want to put in. > > The big problem we have, though, is that the header is required. We're > debating going with JWT or our own method that is loosely based on JWT, but > doesn't use JSON and results in smaller tokens and a simpler process (for > example, you only do one base64url encoding of the final string). We think > we'd gain better room for additions to our payload, and better readability > (therefore learnability/usability) by using JSON, that it might be worth the > tradeoff in token size and several encoding steps. At that point, we'd > basically be JWT except for the fact we really don't need the header. > > Facebook's implementation and one of the original proposals let the > algorithm key live in the payload. Since this is the only thing required in > the header, allowing it as an optional key in the payload would allow the > entire header to be optional. This would really help us out since we need a > process that is as simple as humanly possible. > > If you need to detect if a JWT has a header, you can just check for the > number of periods in the JWT. But I really think the header should be > optional if you specify the alg in the payload. There may have been some > issues reserving the key "algorithm", but I think if we go with short names, > "alg" is much less likely to cause conflicts. > > -- > Jeff Lindsay > > On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones wrote: > >> Draft -01 of the JSON Web Token (JWT) specificationis now available. This version incorporates the consensus decisions reached >> at the Internet Identity Workshop. The remaining open issues and to-do >> items are documented in Section 12. >> As a reminder, the suggested pronunciation of JWT is the same as the English >> word "jot". >> >> >> The draft is available at these locations: >> >> - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt >> >> - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml >> >> - http://self-issued.info/docs/draft-jones-json-web-token-01.html >> >> - http://self-issued.info/docs/draft-jones-json-web-token-01.txt >> >> - http://self-issued.info/docs/draft-jones-json-web-token-01.xml >> >> - http://self-issued.info/docs/draft-jones-json-web-token.html (will >> point to new versions as they are posted) >> >> - http://self-issued.info/docs/draft-jones-json-web-token.txt (will >> point to new versions as they are posted) >> >> - http://self-issued.info/docs/draft-jones-json-web-token.xml (will >> point to new versions as they are posted) >> >> - http://svn.openid.net/repos/specifications/json_web_token/1.0/(Subversion repository, with html, txt, and html versions available) >> >> >> The decisions reached at IIW are documented here: >> >> - JSON Token Spec Results at IIW: http://self-issued.info/?p=361 >> >> - JSON Token Encryption Spec Results at IIW: >> http://self-issued.info/?p=378 >> >> - JSON Token Naming Spec Results at IIW: >> http://self-issued.info/?p=386 >> >> - JSON Public Key Spec Results at IIW: http://self-issued.info/?p=390 >> >> >> This announcement is also posted here: >> >> - http://self-issued.info/?p=446 >> >> >> Thanks to all who provided the input that led to this draft! Feedback is >> highly welcome. >> >> >> -- Mike >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --0016361e7cb08253050499838b63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dick, thanks for the response.

I think I'm behind ev= erything you've said. Perhaps the crux is in library vs user/developer = implementation. I'm interested in less steps not for computational over= head, but for mental overhead and usability. I would love to have (and even= contribute) standard libraries in various languages (we'll have to any= way if we do adopt this), but for now because we're an API (like Facebo= ok) and our docs are about using our API. They assume all you need are the = standard libraries in most programming environments.=A0

Right now, that means users implementing JWTs by hand. = While we have libraries for our APIs, we have to design the API so that you= don't *have* to use these libraries... otherwise, we might as well be = a SOAP web service.=A0

So I'm wondering what people's idea are on how = to start using/implementing this now without standard libraries, assuming w= e don't want to make the process any easier. My hypothesis is the respo= nse from you all will be, "just have the JWT process in your docs, it&= #39;s easy enough. We're not worried about this odd phase of early adop= tion with no standard library."

-jeff

On Fri, Jan 7, = 2011 at 10:42 AM, Dick Hardt <dick.hardt@gmail.com> wrote:
Hi Jeff

Thanks for t= he feedback. A healthy debate is how we optimize a spec!

Will a slightly shorter token be significant for you? =A0Is the rest= of the message so short that a smaller token will have a significant impac= t?

The hope is that if we standardize JWT, that libraries = will be developed so that the average developer does not need to deal with = the details.=A0

We are having to balance between a= generalized solution and a simple, specific solution.=A0

Too specific and the spec does not solve a broad enough= set of people's needs, libraries don't get developed, or if they d= o, the code coverage is nominal and they are not well maintained. This lead= s to more security risks and higher barrier to deployment.

Too generic and the complexity in the library adds more= security risks, less likely someone will implement a library and deploy.

The header makes it easy for a generic library to q= uickly see what the rest of the token is, enables support for encrypted pay= loads (can't do that if the crypto info is in the payload), and provide= s a simple path for extensions / expansion.

While I can appreciate doing less encodings operations,= the encoding is already being used, so this is a slight additional computa= tional overhead. Your suggestion for checking the number of periods may act= ually add back the computational overhead, and a separate code path to be t= ested leading to less secure code. Happy to elaborate more if that was not = clear and compelling!

-- Dick
<= /div>

On 2011-01-06, at 7:29 PM, Jeff L= indsay wrote:

Hi everyone!

I'm really excited about this spec (and OAuth2), as are others here at = Twilio. I've been watching it since Paul implemented an early version a= t Facebook. We also implemented it in an early iteration of a product we= 9;re working on, but now we're coming back to it as a means of authenti= cation that would be key to the entire Twilio API... and since our API *is*= our product, we're very touchy about the details. =A0

I've only been glancing at its progress since the e= arly drafts as various versions were integrated and issues sorted out. I wa= s afraid that it was going to have gotten a lot more complicated, but looki= ng at this I'm pretty happy to see most of the additions are optional.= =A0

Like Paul, I'm not a fan of the short names. Howeve= r, I've sort of accepted it, especially since as reserved keys they are= less likely to conflict with keys we want to put in.=A0

The big problem we have, though, is that the header is required. We= 9;re debating going with JWT or our own method that is loosely based on JWT= , but doesn't use JSON and results in smaller tokens and a simpler proc= ess (for example, you only do one base64url encoding of the final string). = We think we'd gain better room for additions to our payload, and better= readability (therefore learnability/usability) by using JSON, that it migh= t be worth the tradeoff in token size and several encoding steps. At that p= oint, we'd basically be JWT except for the fact we really don't nee= d the header.

Facebook's implementation and one of the original p= roposals let the algorithm key live in the payload. Since this is the only = thing required in the header, allowing it as an optional key in the payload= would allow the entire header to be optional. This would really help us ou= t since we need a process that is as simple as humanly possible.=A0

If you need to detect if a JWT has a header, you can ju= st check for the number of periods in the JWT. But I really think the heade= r should be optional if you specify the alg in the payload. There may have = been some issues reserving the key "algorithm", but I think if we= go with short names, "alg" is much less likely to cause conflict= s.=A0

--
Jeff Lindsay

On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

Draft -01 of the JSON Web Token= (JWT) specification is now available.=A0 This version incorporates the= consensus decisions reached at the Internet Identity Workshop.=A0 The remaining open issues and to-do items are documented in Section 12.=A0 As a reminder, the suggested pronunciation of JWT is the= same as the English word "jot".

=A0

The draft is available at thes= e locations:

=A0 - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt

=A0 - http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml

=A0 - http://self-issued.info/docs/draft-jones-json-web-token-01.html

=A0 - http://self-issued.info/docs/draft-jones-json-web-token-01.txt

=A0 - http://self-issued.info/docs/draft-jones-json-web-token-01.xml

=A0 - http://self-issued.info/docs/draft-jones-json-web-token.html (will poin= t to new versions as they are posted)

=A0 - http://self-issued.info/docs/draft-jones-json-web-token.txt (will point= to new versions as they are posted)

=A0 - http://self-issued.info/docs/draft-jones-json-web-token.xml (will point= to new versions as they are posted)

=A0 - http://svn.openid.net/repos/specifications/json_web_token/1.0/ (Subvers= ion repository, with html, txt, and html versions available)

=A0

The decisions reached at IIW are documented h= ere:

=A0 - JSON Token Spec Results at IIW:=A0 http://self-issued.info/?p=3D361

=A0 - JSON Token Encryption Spec= Results at IIW:=A0 http://self-issued.info/?p=3D378

=A0 - JSON Token Naming Spec Res= ults at IIW:=A0 http://self-issued.info/?p=3D386

=A0 - JSON P= ublic Key Spec Results at IIW: =A0http://self-issued.info/?p=3D390

=A0
<= /div>

This announcement is also posted here:

=A0 - http://self-issu= ed.info/?p=3D446

=A0

Thanks to = all who provided the input that led to this draft!=A0 Feedback is highly we= lcome.

=A0

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



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


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


--0016361e7cb08253050499838b63-- From dick.hardt@gmail.com Mon Jan 10 12:22:13 2011 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 49D4528C0E5 for ; Mon, 10 Jan 2011 12:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IfwpK8PB7v8S for ; Mon, 10 Jan 2011 12:22:11 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 8EBF828C105 for ; Mon, 10 Jan 2011 12:22:10 -0800 (PST) Received: by fxm9 with SMTP id 9so19552102fxm.31 for ; Mon, 10 Jan 2011 12:24:24 -0800 (PST) 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:message-id:references:to :x-mailer; bh=Hu7j+6GridxzDOlR91HbG7Gu4yJyrB49D4Dc2mF9JgA=; b=RPXj4rMNFxjiuF+rDev1nXpkGO67swkpu5dQiLCdoK97e4aQaishQCjGIqytJWbyr7 mTIZwNlu21CQv5K61Rr/UVk0Q7Vb9UHXpw0aQdJ7zf4ih3TD/6VXBfiYw9L04SIn3GkT 6Y/qpF46LfrpVBSEvNXJsCWrM3Oezgj3qaZc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=fVzNxTfS6tWf1HjO7DRFBM//BvpVnVXraR7BKv2fhSvWNsfq9kJmhmUHSMGJ5sjt7V hg17r3ylRhYEuqMPA9EMUlGyG9rwj86mRIvGKJdlwYNfgb+j19l96D62LmMP6wZP2kI3 nUge/gKOXIh0BYG6rTHmzODvK1AFs7HXaOz8o= Received: by 10.223.69.141 with SMTP id z13mr47893fai.9.1294691054980; Mon, 10 Jan 2011 12:24:14 -0800 (PST) Received: from [192.168.1.40] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id 21sm7130842fav.17.2011.01.10.12.24.11 (version=SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 12:24:13 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-13-703753263 From: Dick Hardt In-Reply-To: Date: Mon, 10 Jan 2011 12:24:09 -0800 Message-Id: References: To: Jeff Lindsay X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01 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: Mon, 10 Jan 2011 20:22:13 -0000 --Apple-Mail-13-703753263 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jeff FWIW: 1.5 yrs ago when I was at Microsoft working on OAuth WRAP, I = hacked up some Perl code to generate and crack JWTs using HMAC as the = signing mechanism. It was only about 10-15 lines of code.=20 =46rom my experience in building XML-DSIG libraries for = Perl/Python/PHP/Ruby -- normalization and canonicalization were the pain = points. =46rom an implementation point of view, key management is a pain = point. JWT solves the serialization / normalization / canonicalization problem. = Having one standard way to assemble and disassemble a token using = standard serialization is a HUGE plus. -- Dick On 2011-01-10, at 12:09 PM, Jeff Lindsay wrote: > Dick, thanks for the response. >=20 > I think I'm behind everything you've said. Perhaps the crux is in = library vs user/developer implementation. I'm interested in less steps = not for computational overhead, but for mental overhead and usability. I = would love to have (and even contribute) standard libraries in various = languages (we'll have to anyway if we do adopt this), but for now = because we're an API (like Facebook) and our docs are about using our = API. They assume all you need are the standard libraries in most = programming environments.=20 >=20 > Right now, that means users implementing JWTs by hand. While we have = libraries for our APIs, we have to design the API so that you don't = *have* to use these libraries... otherwise, we might as well be a SOAP = web service.=20 >=20 > So I'm wondering what people's idea are on how to start = using/implementing this now without standard libraries, assuming we = don't want to make the process any easier. My hypothesis is the response = from you all will be, "just have the JWT process in your docs, it's easy = enough. We're not worried about this odd phase of early adoption with no = standard library." >=20 > -jeff >=20 > On Fri, Jan 7, 2011 at 10:42 AM, Dick Hardt = wrote: > Hi Jeff >=20 > Thanks for the feedback. A healthy debate is how we optimize a spec! >=20 > Will a slightly shorter token be significant for you? Is the rest of = the message so short that a smaller token will have a significant = impact? >=20 > The hope is that if we standardize JWT, that libraries will be = developed so that the average developer does not need to deal with the = details.=20 >=20 > We are having to balance between a generalized solution and a simple, = specific solution.=20 >=20 > Too specific and the spec does not solve a broad enough set of = people's needs, libraries don't get developed, or if they do, the code = coverage is nominal and they are not well maintained. This leads to more = security risks and higher barrier to deployment. >=20 > Too generic and the complexity in the library adds more security = risks, less likely someone will implement a library and deploy. >=20 > The header makes it easy for a generic library to quickly see what the = rest of the token is, enables support for encrypted payloads (can't do = that if the crypto info is in the payload), and provides a simple path = for extensions / expansion. >=20 > While I can appreciate doing less encodings operations, the encoding = is already being used, so this is a slight additional computational = overhead. Your suggestion for checking the number of periods may = actually add back the computational overhead, and a separate code path = to be tested leading to less secure code. Happy to elaborate more if = that was not clear and compelling! >=20 > -- Dick >=20 > On 2011-01-06, at 7:29 PM, Jeff Lindsay wrote: >=20 >> Hi everyone! >>=20 >> I'm really excited about this spec (and OAuth2), as are others here = at Twilio. I've been watching it since Paul implemented an early version = at Facebook. We also implemented it in an early iteration of a product = we're working on, but now we're coming back to it as a means of = authentication that would be key to the entire Twilio API... and since = our API *is* our product, we're very touchy about the details. =20 >>=20 >> I've only been glancing at its progress since the early drafts as = various versions were integrated and issues sorted out. I was afraid = that it was going to have gotten a lot more complicated, but looking at = this I'm pretty happy to see most of the additions are optional.=20 >>=20 >> Like Paul, I'm not a fan of the short names. However, I've sort of = accepted it, especially since as reserved keys they are less likely to = conflict with keys we want to put in.=20 >>=20 >> The big problem we have, though, is that the header is required. = We're debating going with JWT or our own method that is loosely based on = JWT, but doesn't use JSON and results in smaller tokens and a simpler = process (for example, you only do one base64url encoding of the final = string). We think we'd gain better room for additions to our payload, = and better readability (therefore learnability/usability) by using JSON, = that it might be worth the tradeoff in token size and several encoding = steps. At that point, we'd basically be JWT except for the fact we = really don't need the header. >>=20 >> Facebook's implementation and one of the original proposals let the = algorithm key live in the payload. Since this is the only thing required = in the header, allowing it as an optional key in the payload would allow = the entire header to be optional. This would really help us out since we = need a process that is as simple as humanly possible.=20 >>=20 >> If you need to detect if a JWT has a header, you can just check for = the number of periods in the JWT. But I really think the header should = be optional if you specify the alg in the payload. There may have been = some issues reserving the key "algorithm", but I think if we go with = short names, "alg" is much less likely to cause conflicts.=20 >>=20 >> -- >> Jeff Lindsay >>=20 >> On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones = wrote: >> Draft -01 of the JSON Web Token (JWT) specification is now available. = This version incorporates the consensus decisions reached at the = Internet Identity Workshop. The remaining open issues and to-do items = are documented in Section 12. As a reminder, the suggested = pronunciation of JWT is the same as the English word "jot". >>=20 >> =20 >> The draft is available at these locations: >>=20 >> - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt >>=20 >> - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml >>=20 >> - http://self-issued.info/docs/draft-jones-json-web-token-01.html >>=20 >> - http://self-issued.info/docs/draft-jones-json-web-token-01.txt >>=20 >> - http://self-issued.info/docs/draft-jones-json-web-token-01.xml >>=20 >> - http://self-issued.info/docs/draft-jones-json-web-token.html = (will point to new versions as they are posted) >>=20 >> - http://self-issued.info/docs/draft-jones-json-web-token.txt (will = point to new versions as they are posted) >>=20 >> - http://self-issued.info/docs/draft-jones-json-web-token.xml (will = point to new versions as they are posted) >>=20 >> - http://svn.openid.net/repos/specifications/json_web_token/1.0/ = (Subversion repository, with html, txt, and html versions available) >>=20 >> =20 >> The decisions reached at IIW are documented here: >>=20 >> - JSON Token Spec Results at IIW: http://self-issued.info/?p=3D361 >>=20 >> - JSON Token Encryption Spec Results at IIW: = http://self-issued.info/?p=3D378 >>=20 >> - JSON Token Naming Spec Results at IIW: = http://self-issued.info/?p=3D386 >>=20 >> - JSON Public Key Spec Results at IIW: = http://self-issued.info/?p=3D390 >>=20 >> =20 >> This announcement is also posted here: >>=20 >> - http://self-issued.info/?p=3D446 >>=20 >> =20 >> Thanks to all who provided the input that led to this draft! = Feedback is highly welcome. >>=20 >> =20 >> -- = Mike >>=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 >=20 --Apple-Mail-13-703753263 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Jeff

FWIW: 1.5 yrs ago when I  was at Microsoft = working on OAuth WRAP, I hacked up some Perl code to generate and crack = JWTs using HMAC as the signing mechanism. It was only about 10-15 lines = of code. 

=46rom my experience in building = XML-DSIG libraries for Perl/Python/PHP/Ruby -- normalization and = canonicalization were the pain points. =46rom an implementation point of = view, key management is a pain point.

JWT = solves the serialization / normalization / canonicalization problem. = Having one standard way to assemble and disassemble a token using = standard serialization is a HUGE plus.

-- = Dick

On 2011-01-10, at 12:09 PM, Jeff = Lindsay wrote:

Dick, thanks for the response.

I think = I'm behind everything you've said. Perhaps the crux is in library vs = user/developer implementation. I'm interested in less steps not for = computational overhead, but for mental overhead and usability. I would = love to have (and even contribute) standard libraries in various = languages (we'll have to anyway if we do adopt this), but for now = because we're an API (like Facebook) and our docs are about using our = API. They assume all you need are the standard libraries in most = programming environments. 

Right now, that means users implementing JWTs by = hand. While we have libraries for our APIs, we have to design the API so = that you don't *have* to use these libraries... otherwise, we might as = well be a SOAP web service. 

So I'm wondering what people's idea are on how to = start using/implementing this now without standard libraries, assuming = we don't want to make the process any easier. My hypothesis is the = response from you all will be, "just have the JWT process in your docs, = it's easy enough. We're not worried about this odd phase of early = adoption with no standard library."

-jeff

On Fri, Jan = 7, 2011 at 10:42 AM, Dick Hardt <dick.hardt@gmail.com> = wrote:
Hi Jeff

Thanks = for the feedback. A healthy debate is how we optimize a = spec!

Will a slightly shorter token be = significant for you?  Is the rest of the message so short that a = smaller token will have a significant impact?

The hope is that if we standardize JWT, that = libraries will be developed so that the average developer does not need = to deal with the details. 

We are having = to balance between a generalized solution and a simple, specific = solution. 

Too specific and the spec does not solve a broad = enough set of people's needs, libraries don't get developed, or if they = do, the code coverage is nominal and they are not well maintained. This = leads to more security risks and higher barrier to deployment.

Too generic and the complexity in the library adds = more security risks, less likely someone will implement a library and = deploy.

The header makes it easy for a generic = library to quickly see what the rest of the token is, enables support = for encrypted payloads (can't do that if the crypto info is in the = payload), and provides a simple path for extensions / expansion.

While I can appreciate doing less encodings = operations, the encoding is already being used, so this is a slight = additional computational overhead. Your suggestion for checking the = number of periods may actually add back the computational overhead, and = a separate code path to be tested leading to less secure code. Happy to = elaborate more if that was not clear and compelling!

-- = Dick

On = 2011-01-06, at 7:29 PM, Jeff Lindsay wrote:

Hi everyone!

I'm really excited about this spec (and OAuth2), as are others here at = Twilio. I've been watching it since Paul implemented an early version at = Facebook. We also implemented it in an early iteration of a product = we're working on, but now we're coming back to it as a means of = authentication that would be key to the entire Twilio API... and since = our API *is* our product, we're very touchy about the details. =  

I've only been glancing at its progress since the = early drafts as various versions were integrated and issues sorted out. = I was afraid that it was going to have gotten a lot more complicated, = but looking at this I'm pretty happy to see most of the additions are = optional. 

Like Paul, I'm not a fan of the short names. = However, I've sort of accepted it, especially since as reserved keys = they are less likely to conflict with keys we want to put = in. 

The big problem we have, though, is that the header is required. = We're debating going with JWT or our own method that is loosely based on = JWT, but doesn't use JSON and results in smaller tokens and a simpler = process (for example, you only do one base64url encoding of the final = string). We think we'd gain better room for additions to our payload, = and better readability (therefore learnability/usability) by using JSON, = that it might be worth the tradeoff in token size and several encoding = steps. At that point, we'd basically be JWT except for the fact we = really don't need the header.

Facebook's implementation and one of the original = proposals let the algorithm key live in the payload. Since this is the = only thing required in the header, allowing it as an optional key in the = payload would allow the entire header to be optional. This would really = help us out since we need a process that is as simple as humanly = possible. 

If you need to detect if a JWT has a header, you can = just check for the number of periods in the JWT. But I really think the = header should be optional if you specify the alg in the payload. There = may have been some issues reserving the key "algorithm", but I think if = we go with short names, "alg" is much less likely to cause = conflicts. 

--
Jeff Lindsay

On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Draft -01 of the JSON Web Token (JWT) specification is now = available.  This version incorporates the consensus decisions = reached at the Internet Identity Workshop.  The remaining open issues and to-do items are documented in Section 12.  As a reminder, the suggested pronunciation of JWT = is the same as the English word "jot".

 

The draft is available = at these locations:

  - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt<= /p>

  - = http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml<= /p>

  - = http://self-issued.info/docs/draft-jones-json-web-token-01.html

  - http://self-issued.info/docs/draft-jones-json-web-token-01.txt

  - http://self-issued.info/docs/draft-jones-json-web-token-01.xml

  - http://self-issued.info/docs/draft-jones-json-web-token.html (will = point to new versions as they are posted)

 = - http://self-issued.info/docs/draft-jones-json-web-token.txt (will = point to new versions as they are posted)

 = - http://self-issued.info/docs/draft-jones-json-web-token.xml (will = point to new versions as they are posted)

 = - http://svn.openid.net/repos/specifications/json_web_token/1.0/ = (Subversion repository, with html, txt, and html versions = available)

 

The decisions = reached at IIW are documented here:

  - JSON Token Spec = Results at IIW:  http://self-issued.info/?p=3D361

  - JSON Token = Encryption Spec Results at IIW:  http://self-issued.info/?p=3D378

  - JSON Token Naming = Spec Results at IIW:  http://self-issued.info/?p=3D386

  - = JSON Public Key Spec Results at IIW:  http://self-issued.info/?p=3D390

 
<= /div>

This announcement is also posted here:

  = - http://self-issued.info/?p=3D446

 
<= /div>

Thanks to all who provided the input that = led to this draft!  Feedback is highly welcome.

 

         =             &n= bsp;           &nbs= p;            =             &n= bsp;     -- Mike



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


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



= --Apple-Mail-13-703753263-- From torsten@lodderstedt.net Mon Jan 10 13:05:36 2011 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 76EB03A6767 for ; Mon, 10 Jan 2011 13:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.017, 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 RdPpeCooGG7P for ; Mon, 10 Jan 2011 13:05:35 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 115C33A672F for ; Mon, 10 Jan 2011 13:05:34 -0800 (PST) Received: from [79.253.31.222] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PcOxw-0006ev-4g; Mon, 10 Jan 2011 22:07:48 +0100 Message-ID: <4D2B7523.5030908@lodderstedt.net> Date: Mon, 10 Jan 2011 22:07:47 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------010504070005000706030708" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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: Mon, 10 Jan 2011 21:05:36 -0000 This is a multi-part message in MIME format. --------------010504070005000706030708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eran, - Authentication schemes You propose to use the authentication scheme name "OAuth2" for the WWW-Authenticate header but another scheme name "MAC" for the authorization header. I've never seen such an asymmetric approach before. Don't you think people get confused about that? Moreover, the bearer draft also uses the name "OAuth2" in the authorization header. Why this difference? Why don't you just add some parameters to the "OAuth2" scheme? - 6.3. Spoofing by Counterfeit Servers The protocol does not support server authentication but it should prevent token abuse by the Counterfeit server, shouldn't it? regards, Torsten. Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > Feedback appreciated, especially for section 3.2.1 (the new normalized > request string) which is an attempt to take the HMAC-SHA1 flow from > 1.0a and simplify it. > > No body signature support yet, but will add that in -01. > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------010504070005000706030708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eran,

- Authentication schemes
You propose to use the authentication scheme name "OAuth2" for the WWW-Authenticate header but another scheme name "MAC" for the authorization header. I've never seen such an asymmetric approach before. Don't you think people get confused about that? Moreover, the bearer draft also uses the name "OAuth2" in the authorization header.  Why this difference? Why don't you just add some parameters to the "OAuth2" scheme?

- 6.3. Spoofing by Counterfeit Servers
The protocol does not support server authentication
but it should prevent token abuse by the Counterfeit
server, shouldn't it?

regards,
Torsten.

Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav:

http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token

 

Feedback appreciated, especially for section 3.2.1 (the new normalized request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a and simplify it.

 

No body signature support yet, but will add that in -01.

 

EHL


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

--------------010504070005000706030708-- From torsten@lodderstedt.net Mon Jan 10 13:17:12 2011 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 F355D3A6807 for ; Mon, 10 Jan 2011 13:17:11 -0800 (PST) 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.017, 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 9YOKlzhMpKJu for ; Mon, 10 Jan 2011 13:17:10 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id C35A23A67DA for ; Mon, 10 Jan 2011 13:17:10 -0800 (PST) Received: from [79.253.31.222] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PcP9A-0003lT-Cz; Mon, 10 Jan 2011 22:19:24 +0100 Message-ID: <4D2B77DB.8030409@lodderstedt.net> Date: Mon, 10 Jan 2011 22:19:23 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] BOF about "JSON Cryptographic Syntax and Processing" 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: Mon, 10 Jan 2011 21:17:12 -0000 Hannes, in my opinion, OAuth should stay a token-format independent protocol. So intuitively, I would vote to work on this topic within another group. Otherwise people might get the impression that OAuth is directly tied to a certain token format. regards, Torsten. Am 10.01.2011 10:19, schrieb Hannes Tschofenig: > Hi all, > > Mike had posted a mail about version -01 of the JSON Web Token document: > http://www.ietf.org/mail-archive/web/oauth/current/msg04912.html > > The usage of JSON and security applied to it became crucial to the work in OAuth. > As we start our re-chartering it would be logical to add it to our charter as well. > > While this is my first choice there may be resistance in doing so since we expand our charter quite a bit. > As a backup, I would therefore like to propose to (a) try to include it in the OAuth re-chartering and (b) at the same time request a BOF at the next IETF meeting. > > Here is the charter writeup for the BOF: > http://ietherpad.com/ce7Vc6AAay > > Interestingly enough there are others in the IETF who also want to standardize JSON signing and encryption (but for other use cases). I am in contact with them and will try to combine our effort to reach the goal faster. > > Your comments on the charter writeup are appreciated. > > Ciao > Hannes > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Mon Jan 10 13:28:18 2011 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 43E103A6820 for ; Mon, 10 Jan 2011 13:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.58 X-Spam-Level: X-Spam-Status: No, score=-10.58 tagged_above=-999 required=5 tests=[AWL=0.018, 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 469woBBKfzwY for ; Mon, 10 Jan 2011 13:28:16 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A87953A681E for ; Mon, 10 Jan 2011 13:28:15 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 10 Jan 2011 13:30:25 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Mon, 10 Jan 2011 13:30:23 -0800 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: Error codes registry Thread-Index: Acuw/7fM0iwVhGdDSCuEQBgjK5iWrwADc5Bg Date: Mon, 10 Jan 2011 21:30:22 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246D5C30@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB747E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB747E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246D5C30TK5EX14MBXC202r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Error codes registry 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: Mon, 10 Jan 2011 21:28:18 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246D5C30TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I believe the draft should continue to say that the error code space MAY be= extended. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, January 10, 2011 11:54 AM To: OAuth WG Subject: [OAUTH-WG] Error codes registry I am questioning the value of an explicit extension mechanism (and registry= ) for error codes. It seems like an overkill since name collisions are not = likely or as problematic (given new error codes imply some other extension = involved as well). I am going to drop notes about error code extensibility. If you have an obj= ection, please propose an extension mechanism. EHL --_000_4E1F6AAD24975D4BA5B1680429673943246D5C30TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I believe the draft sh= ould continue to say that the error code space MAY be extended.<= /span>

 

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, January 10, 2011 11:54 AM
To: OAuth WG
Subject: [OAUTH-WG] Error codes registry

 

I am questioning the value of an explicit extension = mechanism (and registry) for error codes. It seems like an overkill since n= ame collisions are not likely or as problematic (given new error codes impl= y some other extension involved as well).

 

I am going to drop notes about error code extensibil= ity. If you have an objection, please propose an extension mechanism.<= /o:p>

 

EHL

--_000_4E1F6AAD24975D4BA5B1680429673943246D5C30TK5EX14MBXC202r_-- From igor.faynberg@alcatel-lucent.com Mon Jan 10 13:29:23 2011 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 104B23A67F9 for ; Mon, 10 Jan 2011 13:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdmGsvim31Ug for ; Mon, 10 Jan 2011 13:29:21 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id BB4263A681D for ; Mon, 10 Jan 2011 13:29:21 -0800 (PST) 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 p0ALVYbx000361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 15:31:34 -0600 (CST) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p0ALVYBT008136; Mon, 10 Jan 2011 15:31:34 -0600 (CST) Message-ID: <4D2B7AB6.9070802@alcatel-lucent.com> Date: Mon, 10 Jan 2011 16:31:34 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Torsten Lodderstedt References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2B7523.5030908@lodderstedt.net> In-Reply-To: <4D2B7523.5030908@lodderstedt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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: Mon, 10 Jan 2011 21:29:23 -0000 I just wanted to bring these points up, but Torsten got there first! It only remains for me then to +1 on both. Igor Torsten Lodderstedt wrote: > Eran, > > - Authentication schemes > You propose to use the authentication scheme name "OAuth2" for the > WWW-Authenticate header but another scheme name "MAC" for the > authorization header. I've never seen such an asymmetric approach > before. Don't you think people get confused about that? Moreover, the > bearer draft also uses the name "OAuth2" in the authorization header. > Why this difference? Why don't you just add some parameters to the > "OAuth2" scheme? > > - 6.3. Spoofing by Counterfeit Servers > The protocol does not support server authentication > but it should prevent token abuse by the Counterfeit > server, shouldn't it? > > regards, > Torsten. > > Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: >> >> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >> >> >> >> Feedback appreciated, especially for section 3.2.1 (the new >> normalized request string) which is an attempt to take the HMAC-SHA1 >> flow from 1.0a and simplify it. >> >> >> >> No body signature support yet, but will add that in -01. >> >> >> >> 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 Mon Jan 10 13:44:15 2011 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 9B0463A6846 for ; Mon, 10 Jan 2011 13:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, 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 U8lCs4fWeXyC for ; Mon, 10 Jan 2011 13:44:14 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 9F96C3A679C for ; Mon, 10 Jan 2011 13:44:14 -0800 (PST) Received: (qmail 17788 invoked from network); 10 Jan 2011 21:46:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jan 2011 21:46:28 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 Jan 2011 14:46:26 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Mon, 10 Jan 2011 14:46:22 -0700 Thread-Topic: [OAUTH-WG] OAuth MAC token type draft Thread-Index: AcuxCvKIPAG8RHKbReG0rfWAAgFAUAAA/ykg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB74E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2B7523.5030908@lodderstedt.net> In-Reply-To: <4D2B7523.5030908@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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: Mon, 10 Jan 2011 21:44:15 -0000 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, January 10, 2011 1:08 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft >=20 > Eran, >=20 > - Authentication schemes > You propose to use the authentication scheme name "OAuth2" for the > WWW-Authenticate header but another scheme name "MAC" for the > authorization header. I've never seen such an asymmetric approach before. > Don't you think people get confused about that? Moreover, the bearer draf= t > also uses the name "OAuth2" in the authorization header.=A0 Why this > difference? Why don't you just add some parameters to the "OAuth2" > scheme? This was proposed by James Manger and discussed earlier on the list. I'll l= et James explain it. > - 6.3. Spoofing by Counterfeit Servers > The protocol does not support server authentication but it should prevent > token abuse by the Counterfeit server, shouldn't it? It does because the token secret is never sent. EHL >=20 > regards, > Torsten. >=20 > Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >=20 > Feedback appreciated, especially for section 3.2.1 (the new normalized > request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a > and simplify it. >=20 > No body signature support yet, but will add that in -01. >=20 > EHL >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jan 10 14:15:44 2011 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 026A43A63CA for ; Mon, 10 Jan 2011 14:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, 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 gKsKQwzhXONr for ; Mon, 10 Jan 2011 14:15:39 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1884F3A672E for ; Mon, 10 Jan 2011 14:15:39 -0800 (PST) Received: (qmail 29246 invoked from network); 10 Jan 2011 22:17:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jan 2011 22:17:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 Jan 2011 15:17:50 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Mon, 10 Jan 2011 15:17:47 -0700 Thread-Topic: Proposal to drop/relocate response_type=code_and_token Thread-Index: AcuxEC5p0+ab5JWUR76Rx/1QINxnNA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB750CP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 22:15:44 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB750CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm having some doubts about the code_and_token response type. The reason why we have both token and code response type is that each has s= pecific security characteristics. However, the mix raises questions about t= oken scope and other properties. For example, -11 states that the scope in the token request can only be equ= al or less than the scope requested in the authorization request. This mean= s the token issued in the redirection (which is considered less trusted due= to lack of client authentication) can have a greater scope than that issue= d using the code, but not the other way around which actually makes more se= nse. If there is no difference in the properties of the two tokens issued (one d= irectly in the redirection and another via the code), why do we need this c= omplexity? Why can't the client just pass along the same token to the serve= r? If there is a difference, it can only be that the token obtained using t= he code is "more powerful". Adding two scope parameter to the authorization request seems complex, but = so other ideas on asking for one authorization with two different tokens is= sued as a result. Any thoughts? It would be most useful if someone who deployed this (or is planning to) ca= n explain how they are using it. Mostly if they are issuing tokens with the= same or different security properties. In -12, I am moving back to the -05 specification structure of profiles (fl= ows). This means this code_and_token hybrid needs to be explained beyond ju= st the definition of the extra parameter and response format. But I don't k= now how to describe such a profile or what the security considerations for = such a hybrid look like. If we can't nail this down quickly, I propose we move this out of the speci= fication and let someone who has implementation experience define it as an = extension. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB750CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m having= some doubts about the code_and_token response type.

 

The reason why we ha= ve both token and code response type is that each has specific security cha= racteristics. However, the mix raises questions about token scope and other= properties.

 

For example, -11 states that the scope in the token request = can only be equal or less than the scope requested in the authorization req= uest. This means the token issued in the redirection (which is considered l= ess trusted due to lack of client authentication) can have a greater scope = than that issued using the code, but not the other way around which actuall= y makes more sense.

 

If there is no difference in the properties of the tw= o tokens issued (one directly in the redirection and another via the code),= why do we need this complexity? Why can’t the client just pass along= the same token to the server? If there is a difference, it can only be tha= t the token obtained using the code is “more powerful”.

 

Addin= g two scope parameter to the authorization request seems complex, but so ot= her ideas on asking for one authorization with two different tokens issued = as a result.

 

Any thoughts?

 =

It would be most useful if someone who deplo= yed this (or is planning to) can explain how they are using it. Mostly if t= hey are issuing tokens with the same or different security properties.=

 

In= -12, I am moving back to the -05 specification structure of profiles (flow= s). This means this code_and_token hybrid needs to be explained beyond just= the definition of the extra parameter and response format. But I don’= ;t know how to describe such a profile or what the security considerations = for such a hybrid look like.

 =

If we can’t nail this down quickly, I = propose we move this out of the specification and let someone who has imple= mentation experience define it as an extension.

 

EHL

<= /body>= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB750CP3PW5EX1MB01E_-- From beaton@google.com Mon Jan 10 14:28:29 2011 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 6BD733A67A8 for ; Mon, 10 Jan 2011 14:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJUQvUR3YsAB for ; Mon, 10 Jan 2011 14:28:28 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 5D1FE3A679F for ; Mon, 10 Jan 2011 14:28:28 -0800 (PST) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p0AMUfd7030213 for ; Mon, 10 Jan 2011 14:30:41 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294698642; bh=+dZnwYtSnFsvvhLmxCGh4Jb5y+M=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=kdiphnIeJX6xdARodHlS7y/CljabnfVS72n3NgLUIkYNUbETBaOE7/a7YDwtkcYJ6 L5PRRXu/8dtVwDVhAL2Yg== Received: from pzk27 (pzk27.prod.google.com [10.243.19.155]) by wpaz21.hot.corp.google.com with ESMTP id p0AMUaMU030453 for ; Mon, 10 Jan 2011 14:30:40 -0800 Received: by pzk27 with SMTP id 27so4783362pzk.14 for ; Mon, 10 Jan 2011 14:30:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PEONemocT8UsaiZScsCPyPJFfUETF0/bQCIXoERz/SQ=; b=vswO5xfGfvIThspA7GzcTCasXSRzRPu3+HPFufR7YYvjESULPMg0viJhJLV3Oe4AHc lvEEo6r+kMeYBI20+aug== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=d8tv8BbBX8KPw3/frvTDYQFNnOiJehjPG16pX4fvjwWgxs5FCO3SUFiq3FlDHCpXw9 YiJt9nJo5CQ/tbFDfzwA== MIME-Version: 1.0 Received: by 10.142.14.14 with SMTP id 14mr4862505wfn.340.1294698635732; Mon, 10 Jan 2011 14:30:35 -0800 (PST) Received: by 10.142.213.7 with HTTP; Mon, 10 Jan 2011 14:30:35 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 Jan 2011 14:30:35 -0800 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] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 22:28:29 -0000 On Mon, Jan 10, 2011 at 2:17 PM, Eran Hammer-Lahav wr= ote: > In -12, I am moving back to the -05 specification structure of profiles > (flows). Sweet! > This means this code_and_token hybrid needs to be explained beyond > just the definition of the extra parameter and response format. But I don= =92t > know how to describe such a profile or what the security considerations f= or > such a hybrid look like. Does this help? http://www.ietf.org/mail-archive/web/oauth/current/msg03655.html From eran@hueniverse.com Mon Jan 10 14:37:16 2011 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 48C5428C118 for ; Mon, 10 Jan 2011 14:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESMd8DW3aF24 for ; Mon, 10 Jan 2011 14:37:15 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 881DD28C11C for ; Mon, 10 Jan 2011 14:36:53 -0800 (PST) Received: (qmail 5857 invoked from network); 10 Jan 2011 22:39:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jan 2011 22:39:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 Jan 2011 15:39:07 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Mon, 10 Jan 2011 15:39:03 -0700 Thread-Topic: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token Thread-Index: AcuxFgYCE9t1VhU9S1+xfxbVeeInCQAAB11w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 22:37:16 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Monday, January 10, 2011 2:31 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=3Dcode_and_token >=20 > On Mon, Jan 10, 2011 at 2:17 PM, Eran Hammer-Lahav > wrote: > > In -12, I am moving back to the -05 specification structure of > > profiles (flows). >=20 > Sweet! >=20 > > This means this code_and_token hybrid needs to be explained beyond > > just the definition of the extra parameter and response format. But I > > don't know how to describe such a profile or what the security > > considerations for such a hybrid look like. >=20 > Does this help? >=20 > http://www.ietf.org/mail-archive/web/oauth/current/msg03655.html This explains why you want the code returned in the fragment, but not why y= ou need both code and token in the same response, as well as any difference= s in the token attributes, EHL From beaton@google.com Mon Jan 10 14:50:48 2011 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 983203A67D4 for ; Mon, 10 Jan 2011 14:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fj4x1CNkIuW5 for ; Mon, 10 Jan 2011 14:50:47 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id C247A3A67A6 for ; Mon, 10 Jan 2011 14:50:47 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p0AMr2RG010789 for ; Mon, 10 Jan 2011 14:53:02 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294699982; bh=JKdLMujvEbfjIdNjUXhuV4Sszso=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=FJhXy9+ea7N4vEDIxgMSBKYIrTWctTHQ0pnxe7UmzZgeztVvEYwHPVjNLTUcCwPYU EeEcaoHjPc9H2pR6Nmncw== Received: from pzk27 (pzk27.prod.google.com [10.243.19.155]) by wpaz9.hot.corp.google.com with ESMTP id p0AMr0en005422 for ; Mon, 10 Jan 2011 14:53:01 -0800 Received: by pzk27 with SMTP id 27so4235224pzk.28 for ; Mon, 10 Jan 2011 14:53:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=IV0+nGje6momlp1zvBk5GGhpxeXKGpNq1pH8MSekrxA=; b=H1Rm2KGRweNxpy485CL4+Ao/eqhXvpvkzmVrY3RvEJ0V4/1p8M/sKzo0x6A0XymTXK n2+5gZBdb2uw8Zr1NbkQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JLbFh+t69G4CxZ0nzbEQwY0T7ciPoSNlJAh5wBUaiy3s7JqlJDh9HplwvwjTavQ3xm abxBu99bhmaBl3EvJUJg== MIME-Version: 1.0 Received: by 10.142.115.6 with SMTP id n6mr4901612wfc.169.1294699980303; Mon, 10 Jan 2011 14:53:00 -0800 (PST) Received: by 10.142.213.7 with HTTP; Mon, 10 Jan 2011 14:53:00 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 Jan 2011 14:53:00 -0800 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] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 22:50:48 -0000 On Mon, Jan 10, 2011 at 2:39 PM, Eran Hammer-Lahav wrote: > This explains why you want the code returned in the fragment, but not why you need both code and token in the same response, as well as any differences in the token attributes, The token in the same response is a latency optimization. It is used to start rendering iframes and script with interesting content while the code is still being processed. The code is used as a short-lived token that can be swapped for a long-lived (refresh token). I would expect the attributes of the refresh token and access tokens to be equivalent. The primary difference is credential lifetime. From eran@hueniverse.com Mon Jan 10 15:04:24 2011 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 6F8E63A657C for ; Mon, 10 Jan 2011 15:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X0X5WgenQZ8 for ; Mon, 10 Jan 2011 15:04:23 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 848493A6403 for ; Mon, 10 Jan 2011 15:04:23 -0800 (PST) Received: (qmail 969 invoked from network); 10 Jan 2011 23:06:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 Jan 2011 23:06:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 10 Jan 2011 16:06:38 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Mon, 10 Jan 2011 16:06:34 -0700 Thread-Topic: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token Thread-Index: AcuxGSToaHCMBRQXRZaNorTczsTvtAAAQIXw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 23:04:24 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Monday, January 10, 2011 2:53 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=3Dcode_and_token >=20 > On Mon, Jan 10, 2011 at 2:39 PM, Eran Hammer-Lahav > wrote: > > This explains why you want the code returned in the fragment, but not > > why you need both code and token in the same response, as well as any > > differences in the token attributes, >=20 > The token in the same response is a latency optimization. It is used to = start > rendering iframes and script with interesting content while the code is s= till > being processed. >=20 > The code is used as a short-lived token that can be swapped for a long-li= ved > (refresh token). >=20 > I would expect the attributes of the refresh token and access tokens to b= e > equivalent. The primary difference is credential lifetime. What about the difference between the two access tokens? The one issued dir= ectly and the one via the code? Are those the same? Same scope? Same durati= on? I think this needs to be presented as a separate profile from the user-agen= t one because it will make it easier to better describe the security consid= eration of each. Can you offer a 1-2 paragraphs introduction of this profil= e, maybe as reference to the user-agent and server profiles? EHL From phil.hunt@oracle.com Mon Jan 10 15:21:26 2011 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 E6FBD3A67F4 for ; Mon, 10 Jan 2011 15:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 DRFZPUo9HfKd for ; Mon, 10 Jan 2011 15:21:25 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id D54253A67D3 for ; Mon, 10 Jan 2011 15:21:25 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0ANNZrY012649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Jan 2011 23:23:36 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0ANNYSR007727; Mon, 10 Jan 2011 23:23:34 GMT Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 914271781294701769; Mon, 10 Jan 2011 15:22:49 -0800 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Jan 2011 15:22:48 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 Jan 2011 15:22:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5CD15420-0309-4D44-A2F8-F256FCE2C299@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 23:21:27 -0000 What about the idea that the code is only used as a hand-off mechanism = between service components (e.g. authorization manager vs, resource = access manager). In that case, the code would not be usable for = anything except to get an access token (which still requires client = auth). A code might have a very short expiration period with a limited = number of uses (e.g. ONE).=20 The frames timing issue is interesting, but doesn't it suggest a profile = where the whole code step is bypassed (e.g. by receiving code and = token)? In general I perceive a code as being relatively simple (e.g. like an = artifact), short lived, and having almost no rights (except to obtain a = an access/refresh token). Phil phil.hunt@oracle.com On 2011-01-10, at 3:06 PM, Eran Hammer-Lahav wrote: >=20 >> -----Original Message----- >> From: Brian Eaton [mailto:beaton@google.com] >> Sent: Monday, January 10, 2011 2:53 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Proposal to drop/relocate >> response_type=3Dcode_and_token >>=20 >> On Mon, Jan 10, 2011 at 2:39 PM, Eran Hammer-Lahav >> wrote: >>> This explains why you want the code returned in the fragment, but = not >>> why you need both code and token in the same response, as well as = any >>> differences in the token attributes, >>=20 >> The token in the same response is a latency optimization. It is used = to start >> rendering iframes and script with interesting content while the code = is still >> being processed. >>=20 >> The code is used as a short-lived token that can be swapped for a = long-lived >> (refresh token). >>=20 >> I would expect the attributes of the refresh token and access tokens = to be >> equivalent. The primary difference is credential lifetime. >=20 > What about the difference between the two access tokens? The one = issued directly and the one via the code? Are those the same? Same = scope? Same duration? >=20 > I think this needs to be presented as a separate profile from the = user-agent one because it will make it easier to better describe the = security consideration of each. Can you offer a 1-2 paragraphs = introduction of this profile, maybe as reference to the user-agent and = server profiles? >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Mon Jan 10 15:23:06 2011 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 4A69B3A67E9 for ; Mon, 10 Jan 2011 15:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHdqVKABXWKu for ; Mon, 10 Jan 2011 15:23:05 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 3FDCF3A67D3 for ; Mon, 10 Jan 2011 15:23:05 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p0ANPIdj005949 for ; Mon, 10 Jan 2011 15:25:19 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294701919; bh=TKPXqoTpfYPJ5tlrgS1czNDDd98=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=UFKf0y5p3WYsdFHdnrGihs9AXZf01E6dthxlArCCGGzvks05GZq87KC+ThmHdFx4n Qn6K87g5RBL5iddbM793g== Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by wpaz29.hot.corp.google.com with ESMTP id p0ANPHoJ029018 for ; Mon, 10 Jan 2011 15:25:17 -0800 Received: by pxi11 with SMTP id 11so4634704pxi.35 for ; Mon, 10 Jan 2011 15:25:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=aUfhuJ/CyB/OG2hcWcHKyvFHaorPR7Nf4ghPuMQMJqE=; b=MxaS/XERziLRHIMGGuYkfJH+DTMzIBV34f9VNFS+XCHQG8M8tk3RWWyOiM1FxFFhXL nUnvUsSXf7Fy9ufxPfXw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KAWsNAXHSgyMkYjc76vT78qcGq44qEgjWa5YqkzBd0jPC4Z/6ZOLNPIb7FA6C6EUeR 4uUTTkCE30IkoaIe6m8w== MIME-Version: 1.0 Received: by 10.142.157.17 with SMTP id f17mr4914750wfe.226.1294701916960; Mon, 10 Jan 2011 15:25:16 -0800 (PST) Received: by 10.142.213.7 with HTTP; Mon, 10 Jan 2011 15:25:16 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 10 Jan 2011 15:25:16 -0800 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] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 23:23:06 -0000 On Mon, Jan 10, 2011 at 3:06 PM, Eran Hammer-Lahav wrote: > What about the difference between the two access tokens? The one issued directly and the one via the code? Are those the same? Same scope? Same duration? Same. > I think this needs to be presented as a separate profile from the user-agent one because it will make it easier to better describe the security consideration of each. That seems wrong, AFAICT everyone interested in implementing the user-agent profile supported the mode where a verification code is returned. From dick.hardt@gmail.com Mon Jan 10 15:28:10 2011 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 F31F83A67E9 for ; Mon, 10 Jan 2011 15:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 uAvb0OTenCHt for ; Mon, 10 Jan 2011 15:28:09 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id EE0C23A65A6 for ; Mon, 10 Jan 2011 15:28:08 -0800 (PST) Received: by ywk9 with SMTP id 9so8719018ywk.31 for ; Mon, 10 Jan 2011 15:30:23 -0800 (PST) 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=J9dcbIbK76bQvx3lZ1D0lNgv7hO72SgxDtuki2W85qY=; b=bD9SqAKhoNCZqO6Cx1KniCbmTCwA49lsfBOTuld4p0Bzds0FDqcSD2eZjS9EcfIUJn rcUnpqYTB2y/nGdO1valMlnxqxIgiverfEi+zwrWrO/dlPDk/Wi+XzcgaKaDpEkbsOie evoNK/FxyLWtxx+2C3S6l38wa8/4nWEmp8hRk= 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=ZrjrQ4hm4nfeIu2Boh37qWUroEK+eK5LvYFSpUpLA8VRlxD1RBffX3Zi6eyemHGVYr YqCTTHYLcRE1L5qQHwDBDLPHEdzhFb/saA27u5w4QOzZTps/WNX6pRzeSMHcnS7gm5nf G2pOTOJC/BMVW2ZUhZucclWWy8bTDoIrU6eeg= Received: by 10.90.62.26 with SMTP id k26mr6921475aga.1.1294702223455; Mon, 10 Jan 2011 15:30:23 -0800 (PST) Received: from [192.168.1.16] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id x31sm38121939ana.9.2011.01.10.15.30.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 10 Jan 2011 15:30:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Dick Hardt In-Reply-To: Date: Mon, 10 Jan 2011 15:30:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <07988561-A6B5-4F3C-866E-41F038A2A766@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Brian Eaton X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 23:28:10 -0000 On 2011-01-10, at 3:25 PM, Brian Eaton wrote: > On Mon, Jan 10, 2011 at 3:06 PM, Eran Hammer-Lahav = wrote: >> What about the difference between the two access tokens? The one = issued directly and the one via the code? Are those the same? Same = scope? Same duration? >=20 > Same. >=20 >> I think this needs to be presented as a separate profile from the = user-agent one because it will make it easier to better describe the = security consideration of each. >=20 > That seems wrong, AFAICT everyone interested in implementing the > user-agent profile supported the mode where a verification code is > returned. As I recall, the verification code originally was a one-time use code = that was short and could potentially be typed in the user, or could be = passed to the rich client via the page title or other, related "hacks".= From beaton@google.com Mon Jan 10 15:28:56 2011 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 762563A67D1 for ; Mon, 10 Jan 2011 15:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EocIjQA5BiO for ; Mon, 10 Jan 2011 15:28:55 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 47D563A63D3 for ; Mon, 10 Jan 2011 15:28:55 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p0ANV9Hx001353 for ; Mon, 10 Jan 2011 15:31:09 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294702269; bh=MlkyfDsVi3uj/hBUF7KHkvp9BMg=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Jtk+IQivEfWXuB/xW8XlMHn37AVG13Hj9KwSvUrbdca6aoMSx9A+cjXX+e3XSjiT2 NlGn0ErH9NMf9YuKmgg5g== Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by wpaz24.hot.corp.google.com with ESMTP id p0ANV7jV001385 for ; Mon, 10 Jan 2011 15:31:07 -0800 Received: by pxi11 with SMTP id 11so4635598pxi.35 for ; Mon, 10 Jan 2011 15:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fXEo22rBEfgwlik/J6raJBSQ65ZapQlW7xO7lPEZpuE=; b=AlXKA7Q8gZ0x4kxqykGqw3w91rrZKzBIBe9HHG7LWfKLbsVuZZoXoSbjoCHru+fLE0 /HwQxDsaYFrz9DHgXyJQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=fotPC6VBXoU5qmj+NsyATq7xYLPoEv7JfIiFi0fNZdhT58/fIzJD51qI8DwE4bZIkn rbdu7zokpMt6lUf76fDg== MIME-Version: 1.0 Received: by 10.142.14.14 with SMTP id 14mr4906307wfn.340.1294702267255; Mon, 10 Jan 2011 15:31:07 -0800 (PST) Received: by 10.142.213.7 with HTTP; Mon, 10 Jan 2011 15:31:07 -0800 (PST) In-Reply-To: <5CD15420-0309-4D44-A2F8-F256FCE2C299@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5CD15420-0309-4D44-A2F8-F256FCE2C299@oracle.com> Date: Mon, 10 Jan 2011 15:31:07 -0800 Message-ID: From: Brian Eaton To: Phil Hunt 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] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 23:28:56 -0000 On Mon, Jan 10, 2011 at 3:22 PM, Phil Hunt wrote: > What about the idea that the code is only used as a hand-off mechanism be= tween service components (e.g. authorization manager vs, resource access ma= nager). =A0In that case, the code would not be usable for anything except t= o get an access token (which still requires client auth). =A0A code might h= ave a very short expiration period with a limited number of uses (e.g. ONE)= . I believe that is the case already for all of the uses of the verification code in the spec. IIRC, we settled on something where the authorization code MUST have a short-lifetime, and SHOULD be single-use. Exchanging the authorization code for the refresh token MUST require client auth. The user-agent profile usage of the authorization code should not be any different than the rest of the spec. > The frames timing issue is interesting, but doesn't it suggest a profile = where the whole code step is bypassed (e.g. by receiving code and token)? The user-agent profile callback URL should end up looking like this: /callback#code=3D&token=3D The token component is there so immediately return a usable access token to the relying party/client server. The code component is there so the server-side components of the RP can obtain a refresh token and additional access tokens. > In general I perceive a code as being relatively simple (e.g. like an art= ifact), short lived, and having almost no rights (except to obtain a an acc= ess/refresh token). It is very, very similar to the SAML artifact. I think the only major difference is that the SAML specs require a pre-configured return-to URL for artifacts. The OAuth2 spec allows for more dynamic return-to URL settings by having the RP server present the actual callback URL when it presents the artifact, and having the IdP check that the callback URL matches the artifact. From eran@hueniverse.com Mon Jan 10 15:40:44 2011 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 B36583A67B2 for ; Mon, 10 Jan 2011 15:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 VI--qK1Mps5A for ; Mon, 10 Jan 2011 15:40:43 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A6E853A67AE for ; Mon, 10 Jan 2011 15:40:43 -0800 (PST) Received: (qmail 17685 invoked from network); 10 Jan 2011 23:42:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 10 Jan 2011 23:42:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Mon, 10 Jan 2011 16:42:57 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Mon, 10 Jan 2011 16:42:53 -0700 Thread-Topic: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token Thread-Index: AcuxHaZEuPMPrc/gRtS6JOYEAa2/VwAAa+yA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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: Mon, 10 Jan 2011 23:40:44 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Monday, January 10, 2011 3:25 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=3Dcode_and_token >=20 > On Mon, Jan 10, 2011 at 3:06 PM, Eran Hammer-Lahav > wrote: > > What about the difference between the two access tokens? The one > issued directly and the one via the code? Are those the same? Same scope? > Same duration? >=20 > Same. >=20 > > I think this needs to be presented as a separate profile from the user-= agent > one because it will make it easier to better describe the security > consideration of each. >=20 > That seems wrong, AFAICT everyone interested in implementing the user- > agent profile supported the mode where a verification code is returned. Supported as in "+1" or running code? These are two very different client profiles. In one, the client is complet= ely authenticated, residing solely in the user-agent. The other is a mix au= thenticated and unauthenticated, where parts of the client can keep a secre= ts but others can't. Being able to keep a secret is the primary differentiator when picking whic= h profile to use. I agree that the hybrid one is an optimization of the web= -server profile (removing the need to wait for the server to send a token b= ack to the user-agent after exchanging the code). But that only means the c= ode_and_token really belongs with the web-server profile than with the user= -agent. Moving to the profiles specification organization means that we need to pre= sent each distinct profile separately, and the code_and_token is clearly a = distinct profile. With your clarifications, I feel comfortable leaving it in, but not as a ha= ck of either one of the other two profiles. EHL From James.H.Manger@team.telstra.com Mon Jan 10 21:42:44 2011 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 6BD6F28C260 for ; Mon, 10 Jan 2011 21:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 xi4nOLbkf-XU for ; Mon, 10 Jan 2011 21:42:43 -0800 (PST) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by core3.amsl.com (Postfix) with ESMTP id 6B1F328C20D for ; Mon, 10 Jan 2011 21:42:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,305,1291554000"; d="scan'208";a="21373580" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 11 Jan 2011 16:44:51 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6222"; a="16740521" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcdvi.tcif.telstra.com.au with ESMTP; 11 Jan 2011 16:44:51 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Tue, 11 Jan 2011 16:44:51 +1100 From: "Manger, James H" To: OAuth WG Date: Tue, 11 Jan 2011 16:44:49 +1100 Thread-Topic: [OAUTH-WG] OAuth MAC token type draft Thread-Index: AcuxCvKIPAG8RHKbReG0rfWAAgFAUAAA/ykgABBn+cA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1127B45344D@WSMSG3153V.srv.dir.telstra.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2B7523.5030908@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A5AB74E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB74E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 11 Jan 2011 05:42:44 -0000 >> - Authentication schemes >> You propose to use the authentication scheme name "OAuth2" for the >> WWW-Authenticate header but another scheme name "MAC" for the >> authorization header. I've never seen such an asymmetric approach before= . >> Don't you think people get confused about that? > This was proposed by James Manger and discussed earlier on the list. I'll= let James explain it. The MAC draft doesn't bother to define a "WWW-Authenticate: MAC ..." respon= se header because Eran is only interested in using MAC in conjunction with = OAuth2. The server can say (in response to an unauthenticated request): "you can us= e OAuth flows to be delegated access to this server". It says this with a "= WWW-Authenticate: OAuth2" response. This statement is not specific to MAC. I think the MAC scheme should define its own "WWW-Authenticate: MAC ..." re= sponse header. It might not be used by systems using OAuth2, but it makes M= AC a more complete standalone HTTP authentication mechanism. >> Moreover, the bearer draft >> also uses the name "OAuth2" in the authorization header. Why this >> difference? Why don't you just add some parameters to the "OAuth2" >> scheme? The bearer draft should change to use its own scheme name (eg "BEARER") in = Authorization request headers. -- James Manger From eran@hueniverse.com Mon Jan 10 21:58:12 2011 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 E89E13A698D for ; Mon, 10 Jan 2011 21:58:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 5osL7lDBViwX for ; Mon, 10 Jan 2011 21:58:12 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EE9E53A699C for ; Mon, 10 Jan 2011 21:58:11 -0800 (PST) Received: (qmail 15690 invoked from network); 11 Jan 2011 06:00:27 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jan 2011 06:00:27 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Mon, 10 Jan 2011 23:00:26 -0700 From: Eran Hammer-Lahav To: "Manger, James H" , OAuth WG Date: Mon, 10 Jan 2011 23:00:22 -0700 Thread-Topic: [OAUTH-WG] OAuth MAC token type draft Thread-Index: AcuxCvKIPAG8RHKbReG0rfWAAgFAUAAA/ykgABBn+cAAAQfOQA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7578@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2B7523.5030908@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A5AB74E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127B45344D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127B45344D@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 11 Jan 2011 05:58:13 -0000 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Monday, January 10, 2011 9:45 PM > To: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft >=20 > >> - Authentication schemes > >> You propose to use the authentication scheme name "OAuth2" for the > >> WWW-Authenticate header but another scheme name "MAC" for the > >> authorization header. I've never seen such an asymmetric approach > before. > >> Don't you think people get confused about that? >=20 > > This was proposed by James Manger and discussed earlier on the list. I'= ll let > James explain it. >=20 > The MAC draft doesn't bother to define a "WWW-Authenticate: MAC ..." > response header because Eran is only interested in using MAC in conjuncti= on > with OAuth2. > The server can say (in response to an unauthenticated request): "you can > use OAuth flows to be delegated access to this server". It says this with= a > "WWW-Authenticate: OAuth2" response. This statement is not specific to > MAC. >=20 > I think the MAC scheme should define its own "WWW-Authenticate: MAC > ..." response header. It might not be used by systems using OAuth2, but i= t > makes MAC a more complete standalone HTTP authentication mechanism. I will consider adding it, but need to find a way that doesn't bring up the= 'how to get a token' part if you are not using OAuth. EHL >=20 > >> Moreover, the bearer draft > >> also uses the name "OAuth2" in the authorization header. Why this > >> difference? Why don't you just add some parameters to the "OAuth2" > >> scheme? >=20 > The bearer draft should change to use its own scheme name (eg "BEARER") > in Authorization request headers. >=20 > -- > James Manger >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From James.H.Manger@team.telstra.com Mon Jan 10 22:02:21 2011 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 4A5B73A6992 for ; Mon, 10 Jan 2011 22:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.879 X-Spam-Level: X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 5tQ9sTkSpTl4 for ; Mon, 10 Jan 2011 22:02:18 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by core3.amsl.com (Postfix) with ESMTP id F3C0E3A698D for ; Mon, 10 Jan 2011 22:02:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.60,305,1291554000"; d="scan'208";a="23619993" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 11 Jan 2011 17:04:31 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,6222"; a="16742406" Received: from wsmsg3702.srv.dir.telstra.com ([172.49.40.170]) by ipcdvi.tcif.telstra.com.au with ESMTP; 11 Jan 2011 17:04:31 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3702.srv.dir.telstra.com ([172.49.40.170]) with mapi; Tue, 11 Jan 2011 17:04:31 +1100 From: "Manger, James H" To: OAuth WG Date: Tue, 11 Jan 2011 17:04:30 +1100 Thread-Topic: comments on draft-hammer-oauth-v2-mac-token-00 Thread-Index: AcuxSHVnmSRFc5caQL+nfm1VQbrgkQACjnbA Message-ID: <255B9BB34FB7D647A506DC292726F6E1127B45349E@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OAUTH-WG] MAC: comments on draft-hammer-oauth-v2-mac-token-00 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, 11 Jan 2011 06:02:22 -0000 Comments on draft-hammer-oauth-v2-mac-token-00 1. The connection of this MAC scheme to OAuth is secondary. The primary fun= ction of the MAC scheme is to secure the authenticity of parts of an HTTP r= equest using a shared secret. Section 2 "Issuing MAC-Type Access Tokens" wo= uld be better at the end, ideally as an Annex, along with most of the OAuth= talk from the introduction (and title). 2. Include a \n after the final query string parameter. It makes the format simply lines of text, instead of making the last line s= pecial (and only special if there are query params). It is awkward to manua= lly edit sample files, debug files etc without a final newline character. A= dding a final \n would just make it more consistent. 3. The Authorization header example in 1.1 uses single quotes around values= . It should use double quotes. The ABNF in 3.1 for timestamp, for instance,= explicitly uses <">. 4. The quoted-string production only supports a subset of ASCII. Better add= a sentence stating that the 'token' is assumed to only use this subset so = no escaping is defined. May be worth adding that only double-quote and back= slash need escaping in quoted-string, but neither of those are allowed in a= ny of this specs parameters so no escaping in quoted-string values shall oc= cur. 5. Don't list the new line characters as separate numbered items in section= 3.2.1 "Normalized Request String". Better to say it is a line-based format= . Each line ends with a single new line character (U+000A). Then list the 7= lines (as points 1 to 7), followed by point 8 saying there is 1 extra line= for each query string parameter. 6. I18N. Is the Normalised Request String UTF-8, or does it happen to be ju= st ASCII? Host, path, and query strings can contain non-ASCII characters --= but I guess that the ASCII-only escaping used to create an HTTP Host heade= r and URI are assumed to have occurred before this spec uses these values. = Would be worth an explicit statement, and definitely an example. 7. I suggest swapping steps 2 (sort) & 3 (combine escaped name and value) i= n section 3.2.1.1. "Parameters Normalization". The current 2-layer sort is not ideal (sort on %-escaped name, then on %-es= caped value if the names are equal). It needs a special comparator function= etc, instead of using a programming language's standard sort-a-list-of-str= ings function. It is tempting to concatenate %-escaped name=3Dvalue pairs a= nd sort those -- but it doesn't always give the same result. Eg a1=3DX and = a11=3DY should sort in that order according to the spec, but "1" < "=3D" in= an ASCII string comparison of the pairs. A programmer probably has a map/dictionary/assoc-array of unescaped names t= o values. The normalisation rules require a separate map of escaped names t= o escaped values plus a custom comparator that considers names and values. A nicer alternative would be to construct escaped name=3Dvalue pairs then s= ort that list (not map). It would be worth adding another parameter to the example (eg a22=3DA) to i= llustrate this (regardless of whether or not the steps are swapped). 8. HMAC operates on bytes, not strings. The 'text' and 'key' HMAC inputs (i= n 3.2.2 and 3.2.3) should be specified as the UTF-8-encoding of the Normali= zed Request String and access token shared secret respectively. Might be ab= le to say ASCII-encoding, but only if we are sure that an OAuth token respo= nse (which might be a UTF-8 JSON blob) can never return non-ASCII chars in = a 'secret' field. 9. The 'secret' parameter is registered twice (7.1 & 7.2). I guess one of t= hese should be registering the 'algorithm' parameter instead. 10. I would like a "WWW-Authenticate: MAC algorithm=3D..." response header = defined. It would provide a nice illustration of how a complete HTTP auth s= cheme is mapped to OAuth2. That is, how the scheme name "MAC" and parameter= s from the "WWW-Authenticate: MAC ..." response header can be mapped to fie= lds in an OAuth2 token response (where they are accompanied by an actual se= cret key). -- James Manger From pt@fb.com Mon Jan 10 21:25:19 2011 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 129C628C265 for ; Mon, 10 Jan 2011 21:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Owvput8yau2 for ; Mon, 10 Jan 2011 21:25:17 -0800 (PST) Received: from mx-out.facebook.com (outmail007.snc4.facebook.com [66.220.144.139]) by core3.amsl.com (Postfix) with ESMTP id 5F33D28C20D for ; Mon, 10 Jan 2011 21:25:17 -0800 (PST) Received: from [192.168.18.198] ([192.168.18.198:34292] helo=mail.thefacebook.com) by mta034.snc4.facebook.com (envelope-from ) (ecelerity 2.2.2.45 r(34222M)) with ESMTP id 05/57-12592-E3AEB2D4; Mon, 10 Jan 2011 21:27:26 -0800 Received: from SC-MBX04.TheFacebook.com ([169.254.3.253]) by sc-hub03.TheFacebook.com ([192.168.18.198]) with mapi id 14.01.0218.012; Mon, 10 Jan 2011 21:26:26 -0800 From: Paul Tarjan To: Dick Hardt , Jeff Lindsay Thread-Topic: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01 Thread-Index: AQHLrhsWBXnUFp6slESZqvDw68j92pPGXySAgATPUoCAAAQbgIAAEWGA Date: Tue, 11 Jan 2011 05:26:22 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 x-originating-ip: [192.168.18.252] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Jan 2011 22:27:09 -0800 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Feedback on JSON Web Token (JWT) draft -01 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, 11 Jan 2011 05:26:26 -0000 I wrote code in the 4 biggest web languages for our signed_request. I'm sure it is a very small change to support JWTs. https://github.com/ptarjan/signed-request On 1/10/11 12:24 PM, "Dick Hardt" wrote: >Hi Jeff >FWIW: 1.5 yrs ago when I was at Microsoft working on OAuth WRAP, I >hacked up some Perl code to generate and crack JWTs using HMAC as the >signing mechanism. It was only about 10-15 lines of code. > >From my experience in building XML-DSIG libraries for >Perl/Python/PHP/Ruby -- normalization and canonicalization were the pain >points. From an implementation point of view, key management is a pain >point. > >JWT solves the serialization / normalization / canonicalization problem. >Having one standard way to assemble and disassemble a token using >standard serialization is a HUGE plus. > >-- Dick > >On 2011-01-10, at 12:09 PM, Jeff Lindsay wrote: > > >Dick, thanks for the response. >I think I'm behind everything you've said. Perhaps the crux is in library >vs user/developer implementation. I'm interested in less steps not for >computational overhead, but for mental overhead and usability. I would >love to have (and even contribute) standard libraries in various >languages (we'll have to anyway if we do adopt this), but for now because >we're an API (like Facebook) and our docs are about using our API. They >assume all you need are the standard libraries in most programming >environments.=20 > >Right now, that means users implementing JWTs by hand. While we have >libraries for our APIs, we have to design the API so that you don't >*have* to use these libraries... otherwise, we might as well be a SOAP >web service.=20 > >So I'm wondering what people's idea are on how to start >using/implementing this now without standard libraries, assuming we don't >want to make the process any easier. My hypothesis is the response from >you all will be, "just have the JWT process in your docs, it's easy >enough. We're not worried about this odd phase of early adoption with no >standard library." > >-jeff > >On Fri, Jan 7, 2011 at 10:42 AM, Dick Hardt wrote: > >Hi Jeff >Thanks for the feedback. A healthy debate is how we optimize a spec! > >Will a slightly shorter token be significant for you? Is the rest of the >message so short that a smaller token will have a significant impact? > >The hope is that if we standardize JWT, that libraries will be developed >so that the average developer does not need to deal with the details. > >We are having to balance between a generalized solution and a simple, >specific solution. > >Too specific and the spec does not solve a broad enough set of people's >needs, libraries don't get developed, or if they do, the code coverage is >nominal and they are not well maintained. This leads to more security >risks and higher barrier to deployment. > >Too generic and the complexity in the library adds more security risks, >less likely someone will implement a library and deploy. > >The header makes it easy for a generic library to quickly see what the >rest of the token is, enables support for encrypted payloads (can't do >that if the crypto info is in the payload), and provides a simple path >for extensions / expansion. > >While I can appreciate doing less encodings operations, the encoding is >already being used, so this is a slight additional computational >overhead. Your suggestion for checking the number of periods may actually >add back the computational overhead, and a separate code path to be >tested leading to less secure code. Happy to elaborate more if that was >not clear and compelling! > >-- Dick > >On 2011-01-06, at 7:29 PM, Jeff Lindsay wrote: > > >Hi everyone! >I'm really excited about this spec (and OAuth2), as are others here at >Twilio. I've been watching it since Paul implemented an early version at >Facebook. We also implemented it in an early iteration of a product we're >working on, but now we're coming back to it as a means of authentication >that would be key to the entire Twilio API... and since our API *is* our >product, we're very touchy about the details. > >I've only been glancing at its progress since the early drafts as various >versions were integrated and issues sorted out. I was afraid that it was >going to have gotten a lot more complicated, but looking at this I'm >pretty happy to see most of the additions are optional. > >Like Paul, I'm not a fan of the short names. However, I've sort of >accepted it, especially since as reserved keys they are less likely to >conflict with keys we want to put in. > >The big problem we have, though, is that the header is required. We're >debating going with JWT or our own method that is loosely based on JWT, >but doesn't use JSON and results in smaller tokens and a simpler process >(for example, you only do one base64url encoding of the final string). We >think we'd gain better room for additions to our payload, and better >readability (therefore learnability/usability) by using JSON, that it >might be worth the tradeoff in token size and several encoding steps. At >that point, we'd basically be JWT except for the fact we really don't >need the header. > >Facebook's implementation and one of the original proposals let the >algorithm key live in the payload. Since this is the only thing required >in the header, allowing it as an optional key in the payload would allow >the entire header to be optional. This would really help us out since we >need a process that is as simple as humanly possible. > >If you need to detect if a JWT has a header, you can just check for the >number of periods in the JWT. But I really think the header should be >optional if you specify the alg in the payload. There may have been some >issues reserving the key "algorithm", but I think if we go with short >names, "alg" is much less likely to cause conflicts. > >-- >Jeff Lindsay > >On Tue, Jan 4, 2011 at 6:31 PM, Mike Jones >wrote: > >Draft -01 of the JSON Web Token (JWT) specification > is now >available. This version incorporates the consensus decisions reached at >the Internet Identity Workshop. > The remaining open issues and to-do items are documented in >Section 12=20 >. >As a reminder, the suggested pronunciation of JWT is the same as the >English word "jot". > >=20 > >The draft is available at these locations: > -=20 >http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.txt > > -=20 >http://www.ietf.org/internet-drafts/draft-jones-json-web-token-01.xml > > -=20 >http://self-issued.info/docs/draft-jones-json-web-token-01.html > > -=20 >http://self-issued.info/docs/draft-jones-json-web-token-01.txt > > -=20 >http://self-issued.info/docs/draft-jones-json-web-token-01.xml > > -=20 >http://self-issued.info/docs/draft-jones-json-web-token.html > (will >point to new versions as they are posted) > -=20 >http://self-issued.info/docs/draft-jones-json-web-token.txt > (will point >to new versions as they are posted) > -=20 >http://self-issued.info/docs/draft-jones-json-web-token.xml > (will point >to new versions as they are posted) > -=20 >http://svn.openid.net/repos/specifications/json_web_token/1.0/ > >(Subversion repository, with html, txt, and html versions available) >=20 > >The decisions reached at IIW are documented here: > - JSON Token Spec Results at IIW: >http://self-issued.info/?p=3D361 > - JSON Token Encryption Spec Results at IIW: >http://self-issued.info/?p=3D378 > - JSON Token Naming Spec Results at IIW: >http://self-issued.info/?p=3D386 > - JSON Public Key Spec Results at IIW: http://self-issued.info/?p=3D390 >=20 > >This announcement is also posted here: > - http://self-issued.info/?p=3D446 >=20 > >Thanks to all who provided the input that led to this draft! Feedback is >highly welcome. >=20 > > -- Mike > > > > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > > > > > > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > > > > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Jan 11 11:12:43 2011 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 695523A6A8B for ; Tue, 11 Jan 2011 11:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S12A4s5a85gD for ; Tue, 11 Jan 2011 11:12:43 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id A2E883A6A88 for ; Tue, 11 Jan 2011 11:12:42 -0800 (PST) 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; Tue, 11 Jan 2011 11:14:59 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Tue, 11 Jan 2011 11:14:05 -0800 From: Mike Jones To: Eran Hammer-Lahav Thread-Topic: Editorial comments on draft 11 Thread-Index: Acuxw7NjDc0M6iYMRkqbKKf0f0QoxA== Date: Tue, 11 Jan 2011 19:14:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246DF492@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B1680429673943246DF492TK5EX14MBXC202r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Editorial comments on draft 11 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, 11 Jan 2011 19:12:43 -0000 --_004_4E1F6AAD24975D4BA5B1680429673943246DF492TK5EX14MBXC202r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246DF492TK5EX14MBXC202r_" --_000_4E1F6AAD24975D4BA5B1680429673943246DF492TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The attached document has a number of editorial comments on draft 11. Prop= osed are shown as tracked changes and review comments. Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943246DF492TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The attached document has a number of editorial comm= ents on draft 11.  Proposed are shown as tracked changes and review co= mments.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thanks,

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943246DF492TK5EX14MBXC202r_-- --_004_4E1F6AAD24975D4BA5B1680429673943246DF492TK5EX14MBXC202r_ Content-Type: application/msword; name="OAuth2 Draft 11 editorial comments.doc" Content-Description: OAuth2 Draft 11 editorial comments.doc Content-Disposition: attachment; filename="OAuth2 Draft 11 editorial comments.doc"; size=308224; creation-date="Tue, 11 Jan 2011 18:58:10 GMT"; modification-date="Tue, 11 Jan 2011 19:12:03 GMT" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAFAAAAUwIAAAAAAAAA EAAAVgIAAAEAAAD+////AAAAAE4CAABPAgAAUAIAAFECAABSAgAA//////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAZ8AJBAAA+BK/AAAAAAAAEAAAAAAACAAAXFUBAA4AYmpiahBWEFYAAAAAAAAAAAAAAAAAAAAA AAAJBBYALgQDAHI8AQByPAEA+EcBAAAAAAAZAAAAAAAAAEoFAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAALcAAAAAAOQWAAAAAAAA5BYAAD4k AAAAAAAAPiQAAAAAAABMJAAAzgIAAJQoAABcAAAA8CgAABQAAAAAAAAAAAAAAP////8AAAAABCkA AAAAAAAEKQAAAAAAAAQpAAA4AAAAPCkAAAQDAABALAAAvAMAAAQpAAAAAAAAwdoAAPQCAAD8LwAA 9AwAAPA8AAAAAAAA8DwAAAAAAADwPAAAAAAAAPA8AAAAAAAAOD4AALQNAADsSwAANAQAACBQAAAc AgAAJtoAAAIAAAAo2gAAAAAAACjaAAAAAAAAKNoAAAAAAAAo2gAAAAAAACjaAAAAAAAAKNoAACQA AAC13QAAsgIAAGfgAAAqAAAATNoAABUAAAAAAAAAAAAAAAAAAAAAAAAAPiQAAA4AAAA8UgAAAgEA AAAAAAAAAAAAAAAAAAAAAAA4PgAAAAAAADg+AAAAAAAAPlMAAKwAAADqUwAAWAAAAEzaAAAAAAAA AAAAAAAAAAA+JAAAAAAAAD4kAAAAAAAA8DwAAAAAAAAAAAAAAAAAAPA8AABIAQAAYdoAACQAAAD+ bQAAAAAAAP5tAAAAAAAA/m0AAAAAAABCVAAAIAgAAD4kAAAAAAAA8DwAAAAAAAA+JAAAAAAAAPA8 AAAAAAAAJtoAAAAAAAAAAAAAAAAAAP5tAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAPFIAAAAAAAAm2gAAAAAAAAAAAAAAAAAA/m0AAAAAAAD+bQAA 8gMAAMzLAADUAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPM8AAAAAAADwPAAAAAAAAP////8AAAAAkNI8bsOx ywEAAAAAAAAAAP////8AAAAAYlwAALwOAACgzgAATgAAAAAAAAAAAAAAEtoAABQAAACF2gAAPAAA AMHaAAAAAAAA7s4AAE4AAACR4AAAAAAAAB5rAADgAgAAkeAAAJwAAAA8zwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8 zwAAhgoAAJHgAAAAAAAAAAAAAAAAAAAaJwAAegEAAMLZAABQAAAAPFIAAAAAAAA8UgAAAAAAAP5t AAAAAAAAPFIAAAAAAAA8UgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPFIA AAAAAAA8UgAAAAAAADxSAAAAAAAATNoAAAAAAABM2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA/m0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADxSAAAA AAAAPFIAAAAAAAA8UgAAAAAAAMHaAAAAAAAAPFIAAAAAAAA8UgAAAAAAADxSAAAAAAAAPFIAAAAA AAAAAAAAAAAAAP////8AAAAA/////wAAAAD/////AAAAAAAAAAAAAAAA/////wAAAAD/////AAAA AP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAP////8AAAAA /////wAAAAD/////AAAAAP////8AAAAA/////wAAAAD/////AAAAAJHgAAAAAAAAPFIAAAAAAAA8 UgAAAAAAADxSAAAAAAAAPFIAAAAAAAA8UgAAAAAAADxSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8UgAAAAAAADxSAAAAAAAAPFIA AAAAAADkFgAAIAwAAAQjAAA6AQAABQASAQAACQQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABMgSFlQ RVJMSU5LICIiIFxsICJ0b2MiIBSgVE9DoBUHB05ldHdvcmsgV29ya2luZyBHcm91cA1FLiBIYW1t ZXItTGFoYXYsIEVkLg0NSW50ZXJuZXQtRHJhZnQNWWFob28hDQ1PYnNvbGV0ZXM6IBMgSFlQRVJM SU5LICJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODQ5IiAUNTg0ORUgKGlmoGFwcHJv dmVkKQ1ELiBSZWNvcmRvbg0NSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sNRmFjZWJv b2sNDUV4cGlyZXM6IEp1bmUgNCwgMjAxMQ1ELiBIYXJkdA0NoA1NaWNyb3NvZnQNDaANRGVjZW1i ZXIgMSwgMjAxMA0NBwcLVGhlIE9BdXRoIDIuMCBQcm90b2NvbCBGcmFtZXdvcmsLZHJhZnQtaWV0 Zi1vYXV0aC12Mi0xMQ1BYnN0cmFjdA1UaGlzIHNwZWNpZmljYXRpb24gZGVzY3JpYmVzIHRoZSBP QXV0aCAyLjAgcHJvdG9jb2wgZnJhbWV3b3JrLiANU3RhdHVzIG9mIHRoaXMgTWVtbw1UaGlzIElu dGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIHBy b3Zpc2lvbnMgb2YgQkNQoDc4IGFuZCBCQ1CgNzkuDUludGVybmV0LURyYWZ0cyBhcmUgd29ya2lu ZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYp LiBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1 bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURy YWZ0cyBpcyBhdCBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRzL2N1cnJlbnQvLg1J bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3Ro ZXIgdGhhbiBhcyCTd29yayBpbiBwcm9ncmVzcy6UDVRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBl eHBpcmUgb24gSnVuZSA0LCAyMDExLg1Db3B5cmlnaHQgTm90aWNlDUNvcHlyaWdodCAoYykgMjAx MCBJRVRGIFRydXN0IGFuZCB0aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZSBkb2N1bWVudCBh dXRob3JzLiBBbGwgcmlnaHRzIHJlc2VydmVkLg1UaGlzIGRvY3VtZW50IGlzIHN1YmplY3QgdG8g QkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2FsIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8g SUVURiBEb2N1bWVudHMgKGh0dHA6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4g ZWZmZWN0IG9uIHRoZSBkYXRlIG9mIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuIFBsZWFz ZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3Vy IHJpZ2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdCB0byB0aGlzIGRvY3VtZW50LiBD b2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBtdXN0IGluY2x1ZGUg U2ltcGxpZmllZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBv ZiB0aGUgVHJ1c3QgTGVnYWwgUHJvdmlzaW9ucyBhbmQgYXJlIHByb3ZpZGVkIHdpdGhvdXQgd2Fy cmFudHkgYXMgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLg0NAQ1UYWJs ZSBvZiBDb250ZW50cw0TIEhZUEVSTElOSyBcbCAiYW5jaG9yMSIgFDEuFaAgSW50cm9kdWN0aW9u C6CgoKATIEhZUEVSTElOSyBcbCAiYW5jaG9yMiIgFDEuMS4VoCBOb3RhdGlvbmFsIENvbnZlbnRp b25zC6CgoKATIEhZUEVSTElOSyBcbCAiYW5jaG9yMyIgFDEuMi4VoCBUZXJtaW5vbG9neQugoKCg EyBIWVBFUkxJTksgXGwgImFuY2hvcjQiIBQxLjMuFaAgT3ZlcnZpZXcLoKCgoBMgSFlQRVJMSU5L IFxsICJhbmNob3I1IiAUMS40LhWgIEFjY2VzcyBHcmFudHMLoKCgoKCgoKATIEhZUEVSTElOSyBc bCAiYW5jaG9yNiIgFDEuNC4xLhWgIEF1dGhvcml6YXRpb24gQ29kZQugoKCgoKCgoBMgSFlQRVJM SU5LIFxsICJhbmNob3I3IiAUMS40LjIuFaAgUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVu dGlhbHMLoKCgoKCgoKATIEhZUEVSTElOSyBcbCAiYW5jaG9yOCIgFDEuNC4zLhWgIENsaWVudCBD cmVkZW50aWFscwugoKCgoKCgoBMgSFlQRVJMSU5LIFxsICJhbmNob3I5IiAUMS40LjQuFaAgUmVm cmVzaCBUb2tlbgugoKCgoKCgoBMgSFlQRVJMSU5LIFxsICJhbmNob3IxMCIgFDEuNC41LhWgIEFz c2VydGlvbgsTIEhZUEVSTElOSyBcbCAiYW5jaG9yMTEiIBQyLhWgIENsaWVudCBQcm9maWxlcwug oKCgEyBIWVBFUkxJTksgXGwgImFuY2hvcjEyIiAUMi4xLhWgIFdlYiBTZXJ2ZXILoKCgoBMgSFlQ RVJMSU5LIFxsICJ1c2VyLWFnZW50IiAUMi4yLhWgIFVzZXItQWdlbnQLoKCgoBMgSFlQRVJMSU5L IFxsICJhbmNob3IxMyIgFDIuMy4VoCBOYXRpdmUgQXBwbGljYXRpb24LoKCgoBMgSFlQRVJMSU5L IFxsICJhbmNob3IxNCIgFDIuNC4VoCBBdXRvbm9tb3VzCxMgSFlQRVJMSU5LIFxsICJjbGllbnQt YXV0aGVudGljYXRpb24iIBQzLhWgIENsaWVudCBDcmVkZW50aWFscwugoKCgEyBIWVBFUkxJTksg XGwgImFuY2hvcjE1IiAUMy4xLhWgIENsaWVudCBQYXNzd29yZCBDcmVkZW50aWFscwugoKCgEyBI WVBFUkxJTksgXGwgImFuY2hvcjE2IiAUMy4yLhWgIENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlh bHMLEyBIWVBFUkxJTksgXGwgInVzZXItYXV0aG9yaXphdGlvbiIgFDQuFaAgT2J0YWluaW5nIEVu ZC1Vc2VyIEF1dGhvcml6YXRpb24LoKCgoBMgSFlQRVJMSU5LIFxsICJhbmNob3IxNyIgFDQuMS4V oCBBdXRob3JpemF0aW9uIFJlcXVlc3QLoKCgoBMgSFlQRVJMSU5LIFxsICJhbmNob3IxOCIgFDQu Mi4VoCBBdXRob3JpemF0aW9uIFJlc3BvbnNlC6CgoKATIEhZUEVSTElOSyBcbCAiYXV0aC1lcnJv ciIgFDQuMy4VoCBFcnJvciBSZXNwb25zZQugoKCgoKCgoBMgSFlQRVJMSU5LIFxsICJhdXRoLWVy cm9yLWNvZGVzIiAUNC4zLjEuFaAgRXJyb3IgQ29kZXMLEyBIWVBFUkxJTksgXGwgIm9idGFpbmlu Zy10b2tlbiIgFDUuFaAgT2J0YWluaW5nIGFuIEFjY2VzcyBUb2tlbgugoKCgEyBIWVBFUkxJTksg XGwgImFjY2Vzcy1ncmFudC10eXBlcyIgFDUuMS4VoCBBY2Nlc3MgR3JhbnQgVHlwZXMLoKCgoKCg oKATIEhZUEVSTElOSyBcbCAiY29kZS1ncmFudC10eXBlIiAUNS4xLjEuFaAgQXV0aG9yaXphdGlv biBDb2RlC6CgoKCgoKCgEyBIWVBFUkxJTksgXGwgImFuY2hvcjE5IiAUNS4xLjIuFaAgUmVzb3Vy Y2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHMLoKCgoKCgoKATIEhZUEVSTElOSyBcbCAiYW5j aG9yMjAiIBQ1LjEuMy4VoCBDbGllbnQgQ3JlZGVudGlhbHMLoKCgoKCgoKATIEhZUEVSTElOSyBc bCAidG9rZW4tcmVmcmVzaCIgFDUuMS40LhWgIFJlZnJlc2ggVG9rZW4LoKCgoKCgoKATIEhZUEVS TElOSyBcbCAiYW5jaG9yMjEiIBQ1LjEuNS4VoCBBc3NlcnRpb24LoKCgoBMgSFlQRVJMSU5LIFxs ICJhY2Nlc3MtdG9rZW4tcmVzcG9uc2UiIBQ1LjIuFaAgQWNjZXNzIFRva2VuIFJlc3BvbnNlC6Cg oKATIEhZUEVSTElOSyBcbCAidG9rZW4tZXJyb3IiIBQ1LjMuFaAgRXJyb3IgUmVzcG9uc2ULoKCg oKCgoKATIEhZUEVSTElOSyBcbCAidG9rZW4tZXJyb3ItY29kZXMiIBQ1LjMuMS4VoCBFcnJvciBD b2RlcwsTIEhZUEVSTElOSyBcbCAiYWNjZXNzLXJlc291cmNlIiAUNi4VoCBBY2Nlc3NpbmcgYSBQ cm90ZWN0ZWQgUmVzb3VyY2ULoKCgoBMgSFlQRVJMSU5LIFxsICJ0b2tlbi10eXBlcyIgFDYuMS4V oCBBY2Nlc3MgVG9rZW4gVHlwZXMLoKCgoBMgSFlQRVJMSU5LIFxsICJhdXRobi1oZWFkZXIiIBQ2 LjIuFaAgVGhlIFdXVy1BdXRoZW50aWNhdGUgUmVzcG9uc2UgSGVhZGVyIEZpZWxkC6CgoKCgoKCg EyBIWVBFUkxJTksgXGwgInJlc291cmNlLWVycm9yLWNvZGVzIiAUNi4yLjEuFaAgRXJyb3IgQ29k ZXMLEyBIWVBFUkxJTksgXGwgImFuY2hvcjIyIiAUNy4VoCBFeHRlbnNpYmlsaXR5C6CgoKATIEhZ UEVSTElOSyBcbCAiYW5jaG9yMjMiIBQ3LjEuFaAgRGVmaW5pbmcgTmV3IENsaWVudCBDcmVkZW50 aWFscyBUeXBlcwugoKCgEyBIWVBFUkxJTksgXGwgImFuY2hvcjI0IiAUNy4yLhWgIERlZmluaW5n IE5ldyBFbmRwb2ludCBQYXJhbWV0ZXJzC6CgoKATIEhZUEVSTElOSyBcbCAiYW5jaG9yMjUiIBQ3 LjMuFaAgRGVmaW5pbmcgTmV3IEhlYWRlciBGaWVsZCBQYXJhbWV0ZXJzC6CgoKATIEhZUEVSTElO SyBcbCAiYW5jaG9yMjYiIBQ3LjQuFaAgRGVmaW5pbmcgTmV3IEFjY2VzcyBHcmFudCBUeXBlcwsT IEhZUEVSTElOSyBcbCAiYW5jaG9yMjciIBQ4LhWgIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCxMg SFlQRVJMSU5LIFxsICJhbmNob3IyOCIgFDkuFaAgSUFOQSBDb25zaWRlcmF0aW9ucwugoKCgEyBI WVBFUkxJTksgXGwgInBhcmFtZXRlcnMtcmVnaXN0cnkiIBQ5LjEuFaAgVGhlIE9BdXRoIFBhcmFt ZXRlcnMgUmVnaXN0cnkLoKCgoKCgoKATIEhZUEVSTElOSyBcbCAiYW5jaG9yMjkiIBQ5LjEuMS4V oCBSZWdpc3RyYXRpb24gVGVtcGxhdGULoKCgoKCgoKATIEhZUEVSTElOSyBcbCAiYW5jaG9yMzAi IBQ5LjEuMi4VoCBFeGFtcGxlCxMgSFlQRVJMSU5LIFxsICJhbmNob3IzMSIgFEFwcGVuZGl4oEEu FaAgRXhhbXBsZXMLEyBIWVBFUkxJTksgXGwgImFuY2hvcjMyIiAUQXBwZW5kaXigQi4VoCBDb250 cmlidXRvcnMLEyBIWVBFUkxJTksgXGwgImFuY2hvcjMzIiAUQXBwZW5kaXigQy4VoCBBY2tub3ds ZWRnZW1lbnRzCxMgSFlQRVJMSU5LIFxsICJhbmNob3IzNCIgFEFwcGVuZGl4oEQuFaAgRG9jdW1l bnQgSGlzdG9yeQsTIEhZUEVSTElOSyBcbCAicmZjLnJlZmVyZW5jZXMxIiAUMTAuFaAgUmVmZXJl bmNlcwugoKCgEyBIWVBFUkxJTksgXGwgInJmYy5yZWZlcmVuY2VzMSIgFDEwLjEuFaAgTm9ybWF0 aXZlIFJlZmVyZW5jZXMLoKCgoBMgSFlQRVJMSU5LIFxsICJyZmMucmVmZXJlbmNlczIiIBQxMC4y LhWgIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMLEyBIWVBFUkxJTksgXGwgInJmYy5hdXRob3JzIiAU pxWgIEF1dGhvcnMnIEFkZHJlc3Nlcw0LDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcH MS6gIEludHJvZHVjdGlvbg1XaXRoIHRoZSBpbmNyZWFzaW5nIHVzZSBvZiBkaXN0cmlidXRlZCB3 ZWIgc2VydmljZXMgYW5kIGNsb3VkIGNvbXB1dGluZywgdGhpcmQtcGFydHkgYXBwbGljYXRpb25z IHJlcXVpcmUgYWNjZXNzIHRvIHNlcnZlci1ob3N0ZWQgcmVzb3VyY2VzLiBUaGVzZSByZXNvdXJj ZXMgYXJlIHVzdWFsbHkgcHJvdGVjdGVkIGFuZCByZXF1aXJlIGF1dGhlbnRpY2F0aW9uIHVzaW5n IHRoZSByZXNvdXJjZSBvd25lcidzIGNyZWRlbnRpYWxzICh0eXBpY2FsbHkgYSB1c2VybmFtZSBh bmQgcGFzc3dvcmQpLiANSW4gdGhlIHRyYWRpdGlvbmFsIGNsaWVudC1zZXJ2ZXIgYXV0aGVudGlj YXRpb24gbW9kZWwsIHRoZSBjbGllbnQgYWNjZXNzZXMgYSBwcm90ZWN0ZWQgcmVzb3VyY2Ugb24g dGhlIHNlcnZlciBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBzZXJ2ZXIgdXNpbmcgdGhlIHJl c291cmNlIG93bmVyJ3MgY3JlZGVudGlhbHMuIEluIG9yZGVyIHRvIHByb3ZpZGUgdGhpcmQtcGFy dHkgYXBwbGljYXRpb25zIGFjY2VzcyB0byBwcm90ZWN0ZWQgcmVzb3VyY2VzLCB0aGUgcmVzb3Vy Y2Ugb3duZXIgc2hhcmVzIGl0cyBjcmVkZW50aWFscyB3aXRoIHRoZSB0aGlyZC1wYXJ0eS4gVGhp cyBjcmVhdGVzIHNldmVyYWwgcHJvYmxlbXMgYW5kIGxpbWl0YXRpb25zOiANVGhpcmQtcGFydHkg YXBwbGljYXRpb25zIGFyZSByZXF1aXJlZCB0byBzdG9yZSB0aGUgcmVzb3VyY2Utb3duZXIncyBj cmVkZW50aWFscyBmb3IgZnV0dXJlIHVzZSwgdHlwaWNhbGx5IGEgcGFzc3dvcmQgaW4gY2xlYXIt dGV4dC4gDVNlcnZlcnMgYXJlIHJlcXVpcmVkIHRvIHN1cHBvcnQgcGFzc3dvcmQgYXV0aGVudGlj YXRpb24sIGRlc3BpdGUgdGhlIHNlY3VyaXR5IHdlYWtuZXNzZXMgY3JlYXRlZCBieSBwYXNzd29y ZHMuIA1UaGlyZC1wYXJ0eSBhcHBsaWNhdGlvbnMgZ2FpbiBvdmVybHkgYnJvYWQgYWNjZXNzIHRv IHRoZSByZXNvdXJjZS1vd25lcidzIHByb3RlY3RlZCByZXNvdXJjZXMsIGxlYXZpbmcgcmVzb3Vy Y2Ugb3duZXJzIHdpdGhvdXQgYW55IGFiaWxpdHkgdG8gcmVzdHJpY3QgYWNjZXNzIHRvIGEgbGlt aXRlZCBzdWJzZXQgb2YgcmVzb3VyY2VzLCB0byBsaW1pdCBhY2Nlc3MgZHVyYXRpb24sIG9yIHRv IGxpbWl0IGFjY2VzcyB0byB0aGUgbWV0aG9kcyBzdXBwb3J0ZWQgYnkgdGhlc2UgcmVzb3VyY2Vz LiANUmVzb3VyY2Ugb3duZXJzIGNhbm5vdCByZXZva2UgYWNjZXNzIHRvIGFuIGluZGl2aWR1YWwg dGhpcmQtcGFydHkgd2l0aG91dCByZXZva2luZyBhY2Nlc3MgdG8gYWxsIHRoaXJkLXBhcnRpZXMs IGFuZCBtdXN0IGRvIHNvIGJ5IGNoYW5naW5nIHRoZWlyIHBhc3N3b3JkLiANT0F1dGggYWRkcmVz c2VzIHRoZXNlIGlzc3VlcyBieSBzZXBhcmF0aW5nIHRoZSByb2xlIG9mIHRoZSBjbGllbnQgZnJv bSB0aGF0IG9mIHRoZSByZXNvdXJjZSBvd25lci4gSW4gT0F1dGgsIHRoZSBjbGllbnQgKHdoaWNo IGlzIHVzdWFsbHkgbm90IHRoZSByZXNvdXJjZSBvd25lciwgYnV0IGlzIGFjdGluZyBvbiB0aGUg cmVzb3VyY2Ugb3duZXIncyBiZWhhbGYpIHJlcXVlc3RzIGFjY2VzcyB0byByZXNvdXJjZXMgY29u dHJvbGxlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIgYW5kIGhvc3RlZCBieSB0aGUgcmVzb3VyY2Ug c2VydmVyLCBhbmQgaXMgaXNzdWVkIGEgZGlmZmVyZW50IHNldCBvZiBjcmVkZW50aWFscyB0aGFu IHRob3NlIG9mIHRoZSByZXNvdXJjZSBvd25lci4gDUluc3RlYWQgb2YgdXNpbmcgdGhlIHJlc291 cmNlIG93bmVyJ3MgY3JlZGVudGlhbHMgdG8gYWNjZXNzIHByb3RlY3RlZCByZXNvdXJjZXMsIHRo ZSBjbGllbnQgb2J0YWlucyBhbiBhY2Nlc3MgdG9rZW4gLSBhIHN0cmluZyB3aGljaCBkZW5vdGVz IGEgc3BlY2lmaWMgc2NvcGUFLCBkdXJhdGlvbiwgYW5kIG90aGVyIGF0dHJpYnV0ZXMuIEFjY2Vz cyB0b2tlbnMgYXJlIGlzc3VlZCB0byB0aGlyZC1wYXJ0eSAFY2xpZW50cyBieSBhbiBhdXRob3Jp emF0aW9uIHNlcnZlciB3aXRoIHRoZSBhcHByb3ZhbCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuIFRo ZSBjbGllbnQgdXNlcyB0aGUgYWNjZXNzIHRva2VuIHRvIGFjY2VzcyB0aGUgcHJvdGVjdGVkIHJl c291cmNlcyBob3N0ZWQgYnkgdGhlIHJlc291cmNlIHNlcnZlci4gDUZvciBleGFtcGxlLCBhIHdl YiB1c2VyIChyZXNvdXJjZSBvd25lcikgY2FuIGdyYW50IGEgcHJpbnRpbmcgc2VydmljZSAoY2xp ZW50KSBhY2Nlc3MgdG8gaGVyIHByb3RlY3RlZCBwaG90b3Mgc3RvcmVkIGF0IGEgcGhvdG8gc2hh cmluZyBzZXJ2aWNlIChyZXNvdXJjZSBzZXJ2ZXIpLCB3aXRob3V0IHNoYXJpbmcgaGVyIHVzZXJu YW1lIGFuZCBwYXNzd29yZCB3aXRoIHRoZSBwcmludGluZyBzZXJ2aWNlLiBJbnN0ZWFkLCBzaGUg YXV0aGVudGljYXRlcyBkaXJlY3RseSB3aXRoIGFuIGF1dGhlbnRpY2F0aW9uIHNlcnZpY2UgdHJ1 c3RlZCBieSB0aGUgcGhvdG8gc2hhcmluZyBzZXJ2aWNlIChhdXRob3JpemF0aW9uIHNlcnZlcikg d2hpY2ggaXNzdWVzIHRoZSBwcmludGluZyBzZXJ2aWNlIGRlbGVnYXRpb24tc3BlY2lmaWMgY3Jl ZGVudGlhbHMgKHRva2VuKS4gDUFjY2VzcyB0b2tlbnMgY2FuIGhhdmUgZGlmZmVyZW50IGZvcm1h dHMsIHN0cnVjdHVyZXMsIGFuZCBtZXRob2RzIG9mIHV0aWxpemF0aW9uIChlLmcuIGNyeXB0b2dy YXBoaWMgcHJvcGVydGllcyksIGJhc2VkIG9uIHRoZSByZXNvdXJjZSBzZXJ2ZXIgc2VjdXJpdHkg cmVxdWlyZW1lbnRzBS4gQWNjZXNzIHRva2VuIGF0dHJpYnV0ZXMgYW5kIHRoZSBtZXRob2RzIHVz ZWQgdG8gYWNjZXNzIHByb3RlY3RlZCByZXNvdXJjZXMgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2Yg dGhpcyBzcGVjaWZpY2F0aW9uIGFuZCBhcmUgZGVmaW5lZCBieSBjb21wYW5pb24gc3BlY2lmaWNh dGlvbnMuIFRoZSBpbnRlcmFjdGlvbiBiZXR3ZWVuIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBh bmQgcmVzb3VyY2Ugc2VydmVyIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0 aW9uLiANDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHMS4xLqAgTm90YXRpb25hbCBD b252ZW50aW9ucw1UaGUga2V5IHdvcmRzICdNVVNUJywgJ01VU1QgTk9UJywgJ1JFUVVJUkVEJywg J1NIQUxMJywgJ1NIQUxMIE5PVCcsICdTSE9VTEQnLCAnU0hPVUxEIE5PVCcsICdSRUNPTU1FTkRF RCcsICdNQVknLCBhbmQgJ09QVElPTkFMJyBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRl cnByZXRlZCBhcyBkZXNjcmliZWQgaW4gLiANVGhpcyBkb2N1bWVudCB1c2VzIHRoZSBBdWdtZW50 ZWQgQmFja3VzLU5hdXIgRm9ybSAoQUJORikgbm90YXRpb24gb2YgLiBBZGRpdGlvbmFsbHksIHRo ZSBmb2xsb3dpbmcgcnVsZXMgYXJlIGluY2x1ZGVkIGZyb20gOiBVUkktcmVmZXJlbmNlOyBhbmQg ZnJvbSA6IE9XUywgUldTLCBhbmQgcXVvdGVkLXN0cmluZy4gDVVubGVzcyBvdGhlcndpc2Ugbm90 ZWQsIGFsbCB0aGUgcHJvdG9jb2wgcGFyYW1ldGVyIG5hbWVzIGFuZCB2YWx1ZXMgYXJlIGNhc2Ug c2Vuc2l0aXZlLiANDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHMS4yLqAgVGVybWlu b2xvZ3kNcHJvdGVjdGVkIHJlc291cmNlDUFuIGFjY2Vzcy1yZXN0cmljdGVkIHJlc291cmNlIHdo aWNoIGNhbiBiZSBvYnRhaW5lZCB1c2luZyBhbiBPQXV0aC1hdXRoZW50aWNhdGVkIHJlcXVlc3Qu IA1yZXNvdXJjZSBzZXJ2ZXINQSBzZXJ2ZXIgY2FwYWJsZSBvZiBhY2NlcHRpbmcgYW5kIHJlc3Bv bmRpbmcgdG8gcHJvdGVjdGVkIHJlc291cmNlIHJlcXVlc3RzLiANY2xpZW50DUFuIGFwcGxpY2F0 aW9uIG9idGFpbmluZyBhdXRob3JpemF0aW9uIGFuZCBtYWtpbmcgcHJvdGVjdGVkIHJlc291cmNl IHJlcXVlc3RzLiANcmVzb3VyY2Ugb3duZXINQW4gZW50aXR5IGNhcGFibGUgb2YgZ3JhbnRpbmcg YWNjZXNzIHRvIGEgcHJvdGVjdGVkIHJlc291cmNlLiANZW5kLXVzZXINQSBodW1hbiByZXNvdXJj ZSBvd25lci4gDXRva2VuDUEgc3RyaW5nIHJlcHJlc2VudGluZyBhbiBhY2Nlc3MgYXV0aG9yaXph dGlvbiBpc3N1ZWQgdG8gdGhlIGNsaWVudC4gVGhlIHN0cmluZyBpcyB1c3VhbGx5IG9wYXF1ZSB0 byB0aGUgY2xpZW50LiBUb2tlbnMgcmVwcmVzZW50IHNwZWNpZmljIHNjb3BlcyBhbmQgZHVyYXRp b25zIG9mIGFjY2VzcywgZ3JhbnRlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIsIGFuZCBlbmZvcmNl ZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVyIGFuZCBhdXRob3JpemF0aW9uIHNlcnZlcnMuIFRoZSB0 b2tlbiBtYXkgZGVub3RlIGFuIGlkZW50aWZpZXIgdXNlZCB0byByZXRyaWV2ZSB0aGUgYXV0aG9y aXphdGlvbiBpbmZvcm1hdGlvbiwgb3Igc2VsZi1jb250YWluIHRoZSBhdXRob3JpemF0aW9uIGlu Zm9ybWF0aW9uIGluIGEgdmVyaWZpYWJsZSBtYW5uZXIgKGkuZS4gYSB0b2tlbiBzdHJpbmcgY29u c2lzdGluZyBvZiBzb21lIGRhdGEgYW5kIGEgc2lnbmF0dXJlKS4gVG9rZW5zIG1heSBiZSBwdXJl IGNhcGFiaWxpdGllcy4gU3BlY2lmaWMgYWRkaXRpb25hbCBhdXRoZW50aWNhdGlvbiBjcmVkZW50 aWFscyBtYXkgYmUgcmVxdWlyZWQgaW4gb3JkZXIgZm9yIGEgY2xpZW50IHRvIHVzZSBhIHRva2Vu LiANYWNjZXNzIHRva2VuDUEgdG9rZW4gdXNlZCBieSB0aGUgY2xpZW50IHRvIG1ha2UgYXV0aGVu dGljYXRlZCByZXF1ZXN0cyBvbiBiZWhhbGYgb2YgdGhlIHJlc291cmNlIG93bmVyLiANcmVmcmVz aCB0b2tlbg1BIHRva2VuIHVzZWQgYnkgdGhlIGNsaWVudCB0byBvYnRhaW4gYSBuZXcgYWNjZXNz IHRva2VuIHdpdGhvdXQgaGF2aW5nIHRvIGludm9sdmUgdGhlIHJlc291cmNlIG93bmVyLiANYXV0 aG9yaXphdGlvbiBjb2RlDUEgc2hvcnQtbGl2ZWQgdG9rZW4gcmVwcmVzZW50aW5nIHRoZSBhdXRo b3JpemF0aW9uIHByb3ZpZGVkIGJ5IHRoZSBlbmQtdXNlci4gVGhlIGF1dGhvcml6YXRpb24gY29k ZSBpcyB1c2VkIHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4gYW5kIGEgcmVmcmVzaCB0b2tlbi4g DWFjY2VzcyBncmFudA1BIGdlbmVyYWwgdGVybSB1c2VkIHRvIGRlc2NyaWJlIHRoZSBpbnRlcm1l ZGlhdGUgY3JlZGVudGlhbHMgKHN1Y2ggYXMgYW4gZW5kLXVzZXIgcGFzc3dvcmQgb3IgYXV0aG9y aXphdGlvbiBjb2RlKSByZXByZXNlbnRpbmcgdGhlIHJlc291cmNlIG93bmVyIGF1dGhvcml6YXRp b24uIEFjY2VzcyBncmFudHMgYXJlIHVzZWQgYnkgdGhlIGNsaWVudCB0byBvYnRhaW4gYW4gYWNj ZXNzIHRva2VuLiBCeSBleGNoYW5naW5nIGFjY2VzcyBncmFudHMgb2YgZGlmZmVyZW50IHR5cGVz IGZvciBhbiBhY2Nlc3MgdG9rZW4sIHRoZSByZXNvdXJjZSBzZXJ2ZXIgaXMgb25seSByZXF1aXJl ZCB0byBzdXBwb3J0IGEgc2luZ2xlIGF1dGhlbnRpY2F0aW9uIHNjaGVtZS4gDWF1dGhvcml6YXRp b24gc2VydmVyDUEgc2VydmVyIGNhcGFibGUgb2YgaXNzdWluZyB0b2tlbnMgYWZ0ZXIgc3VjY2Vz c2Z1bGx5IGF1dGhlbnRpY2F0aW5nIHRoZSByZXNvdXJjZSBvd25lciBhbmQgb2J0YWluaW5nIGF1 dGhvcml6YXRpb24uIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBtYXkgYmUgdGhlIHNhbWUgc2Vy dmVyIGFzIHRoZSByZXNvdXJjZSBzZXJ2ZXIsIG9yIGEgc2VwYXJhdGUgZW50aXR5LiBBIHNpbmds ZSBhdXRob3JpemF0aW9uIHNlcnZlciBtYXkgaXNzdWUgdG9rZW5zIGZvciBtdWx0aXBsZSByZXNv dXJjZSBzZXJ2ZXJzLiANZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBlbmRwb2ludA1UaGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIncyBIVFRQIGVuZHBvaW50IGNhcGFibGUgb2YgYXV0aGVudGljYXRpbmcg dGhlIGVuZC11c2VyIGFuZCBvYnRhaW5pbmcgYXV0aG9yaXphdGlvbi4gVGhlIGVuZC11c2VyIGF1 dGhvcml6YXRpb24gZW5kcG9pbnQgaXMgZGVzY3JpYmVkIGluIC4gDXRva2VuIGVuZHBvaW50DVRo ZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIEhUVFAgZW5kcG9pbnQgY2FwYWJsZSBvZiBpc3N1aW5n IHRva2VucyBhbmQgcmVmcmVzaGluZyBleHBpcmVkIHRva2Vucy4gVGhlIHRva2VuIGVuZHBvaW50 IGlzIGRlc2NyaWJlZCBpbiAuIA1jbGllbnQgaWRlbnRpZmllcg1BIHVuaXF1ZSBpZGVudGlmaWVy IGlzc3VlZCB0byB0aGUgY2xpZW50IHRvIGlkZW50aWZ5IGl0c2VsZiB0byB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIuIENsaWVudCBpZGVudGlmaWVycyBtYXkgaGF2ZSBhIG1hdGNoaW5nIHNlY3Jl dC4gVGhlIGNsaWVudCBpZGVudGlmaWVyIGlzIGRlc2NyaWJlZCBpbiAuIA0NAQ0TIEhZUEVSTElO SyBcbCAidG9jIiAUoFRPQ6AVBwcxLjMuoCBPdmVydmlldw1PQXV0aCBwcm92aWRlcyBhIG1ldGhv ZCBmb3IgY2xpZW50cyB0byBhY2Nlc3MgYSBwcm90ZWN0ZWQgcmVzb3VyY2Ugb24gYmVoYWxmIG9m IGEgcmVzb3VyY2Ugb3duZXIuIEJlZm9yZSBhIGNsaWVudCBjYW4gYWNjZXNzIGEgcHJvdGVjdGVk IHJlc291cmNlLCBpdCBtdXN0IGZpcnN0IG9idGFpbiBhdXRob3JpemF0aW9uIChhY2Nlc3MgZ3Jh bnQpIAVmcm9tIHRoZSByZXNvdXJjZSBvd25lciwgdGhlbiBleGNoYW5nZSB0aGUgYWNjZXNzIGdy YW50IAVmb3IgYW4gYWNjZXNzIHRva2VuIChyZXByZXNlbnRpbmcgdGhlIGdyYW50J3Mgc2NvcGUs IGR1cmF0aW9uLCBhbmQgb3RoZXIgYXR0cmlidXRlcykuIFRoZSBjbGllbnQgYWNjZXNzZXMgdGhl IHByb3RlY3RlZCByZXNvdXJjZSBieSBwcmVzZW50aW5nIHRoZSBhY2Nlc3MgdG9rZW4gdG8gdGhl IHJlc291cmNlIHNlcnZlci4gDVRoZSBhY2Nlc3MgdG9rZW4gcHJvdmlkZXMgYW4gYWJzdHJhY3Rp b24gbGF5ZXIsIHJlcGxhY2luZyBkaWZmZXJlbnQgYXV0aG9yaXphdGlvbiBjb25zdHJ1Y3RzIChl LmcuIHVzZXJuYW1lIGFuZCBwYXNzd29yZCwgYXNzZXJ0aW9uKSBmb3IgYSBzaW5nbGUgdG9rZW4g dW5kZXJzdG9vZCBieSB0aGUgcmVzb3VyY2Ugc2VydmVyLiBUaGlzIGFic3RyYWN0aW9uIGVuYWJs ZXMgaXNzdWluZyBhY2Nlc3MgdG9rZW5zIHZhbGlkIGZvciBhIHNob3J0IHRpbWUgcGVyaW9kLCBh cyB3ZWxsIGFzIHJlbW92aW5nIHRoZSByZXNvdXJjZSBzZXJ2ZXIncyBuZWVkIHRvIHVuZGVyc3Rh bmQgYSB3aWRlIHJhbmdlIG9mIGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMuIA0NAQ0NDSAgKy0tLS0t LS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tKw0gIHwg ICAgICAgIHwtLShBKS0gQXV0aG9yaXphdGlvbiBSZXF1ZXN0IC0+fCAgIFJlc291cmNlICAgIHwN ICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIE93bmVyICAg ICB8DSAgfCAgICAgICAgfDwtKEIpLS0tLS0gQWNjZXNzIEdyYW50IC0tLS0tLS18ICAgICAgICAg ICAgICAgfA0gIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLSsNICB8ICAgICAgICB8DSAgfCAgICAgICAgfCAgICAgICAgICAgQWNjZXNzIEdy YW50ICYgICAgICArLS0tLS0tLS0tLS0tLS0tKw0gIHwgICAgICAgIHwtLShDKS0tLSBDbGllbnQg Q3JlZGVudGlhbHMgLS0+fCBBdXRob3JpemF0aW9uIHwNICB8IENsaWVudCB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICAgIFNlcnZlciAgICB8DSAgfCAgICAgICAgfDwtKEQpLS0t LS0gQWNjZXNzIFRva2VuIC0tLS0tLS18ICAgICAgICAgICAgICAgfA0gIHwgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNICB8ICAgICAgICB8 DSAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LS0tKw0gIHwgICAgICAgIHwtLShFKS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0+fCAgICBSZXNv dXJjZSAgIHwNICB8ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg IFNlcnZlciAgICB8DSAgfCAgICAgICAgfDwtKEYpLS0tIFByb3RlY3RlZCBSZXNvdXJjZSAtLS18 ICAgICAgICAgICAgICAgfA0gICstLS0tLS0tLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0tLSsNDaBGaWd1cmWgMTogQWJzdHJhY3QgUHJvdG9jb2wgRmxvd6AH BwENVGhlIGFic3RyYWN0IGZsb3cgaWxsdXN0cmF0ZWQgaW4gIGRlc2NyaWJlcyB0aGUgb3ZlcmFs bCBwcm90b2NvbCBhcmNoaXRlY3R1cmUgYW5kIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgc3RlcHM6 IA0oQSkNVGhlIGNsaWVudCByZXF1ZXN0cyBhdXRob3JpemF0aW9uIGZyb20gdGhlIHJlc291cmNl IG93bmVyLiBUaGUgYXV0aG9yaXphdGlvbiByZXF1ZXN0IGNhbiBiZSBtYWRlIGRpcmVjdGx5IHRv IHRoZSByZXNvdXJjZSBvd25lciwgb3IgcHJlZmVyYWJseSBpbmRpcmVjdGx5IHZpYSBhbiBpbnRl cm1lZGlhcnkgc3VjaCBhcyBhbiBhdXRob3JpemF0aW9uIHNlcnZlci4gDShCKQ1UaGUgY2xpZW50 IHJlY2VpdmVzIGFuIGFjY2VzcyBncmFudCAFd2hpY2ggcmVwcmVzZW50cyB0aGUgYXV0aG9yaXph dGlvbiBwcm92aWRlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIuIA0oQykNVGhlIGNsaWVudCByZXF1 ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gYnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgdXNpbmcgaXRzIGNsaWVudCBjcmVkZW50aWFscywgYW5kIHByZXNlbnRpbmcg dGhlIGFjY2VzcyBncmFudAUuIA0oRCkNVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHZhbGlkYXRl cyB0aGUgY2xpZW50IGNyZWRlbnRpYWxzIGFuZCB0aGUgYWNjZXNzIGdyYW50BSwgYW5kIGlmIHZh bGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9rZW4uIA0oRSkNVGhlIGNsaWVudCBtYWtlcyBhIHByb3Rl Y3RlZCByZXNvdXJjZSByZXF1ZXN0IHRvIHRoZSByZXNvdXJjZSBzZXJ2ZXIgYnkgcHJlc2VudGlu ZyB0aGUgYWNjZXNzIHRva2VuLiANKEYpDVRoZSByZXNvdXJjZSBzZXJ2ZXIgdmFsaWRhdGVzIHRo ZSBhY2Nlc3MgdG9rZW4sIGFuZCBpZiB2YWxpZCwgc2VydmVzIHRoZSByZXF1ZXN0LiANDQENEyBI WVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHMS40LqAgQWNjZXNzIEdyYW50cw1UaGUgYWNjZXNz IGdyYW50IHJlcHJlc2VudHMgdGhlIGF1dGhvcml6YXRpb24gcHJvdmlkZWQgYnkgdGhlIHJlc291 cmNlIG93bmVyLiBUaGUgYWNjZXNzIGdyYW50IHR5cGUgZGVwZW5kcyBvbiB0aGUgbWV0aG9kIHVz ZWQgYnkgdGhlIGNsaWVudCBhbmQgc3VwcG9ydGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciB0byBvYnRhaW4gaXQuIA0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAUoFRPQ6AVBwcxLjQuMS6g IEF1dGhvcml6YXRpb24gQ29kZQ1UaGUgYXV0aG9yaXphdGlvbiBjb2RlIGlzIGFuIGFjY2VzcyBn cmFudCBvYnRhaW5lZCBieSBkaXJlY3RpbmcgdGhlIGVuZC11c2VyIHRvIGFuIGF1dGhvcml6YXRp b24gc2VydmVyLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYXV0aGVudGljYXRlcyB0aGUgZW5k LXVzZXIsIG9idGFpbnMgYXV0aG9yaXphdGlvbiwgYW5kIGlzc3VlcyB0aGUgYW4gYXV0aG9yaXph dGlvbiBjb2RlIHRvIHRoZSBjbGllbnQuIEJlY2F1c2UgdGhlIGVuZC11c2VyIG9ubHkgYXV0aGVu dGljYXRlcyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlIGVuZC11c2VyJ3MgcGFz c3dvcmQgaXMgbmV2ZXIgc2hhcmVkIHdpdGggdGhlIGNsaWVudC4gDVRoZSBhdXRob3JpemF0aW9u IGNvZGUgYWNjZXNzIGdyYW50IGlzIHN1aXRhYmxlIHdoZW4gdGhlIGNsaWVudCBpcyBpbnRlcmFj dGluZyB3aXRoIGFuIGVuZC11c2VyIHZpYSBhIHVzZXItYWdlbnQuIA0NAQ0NDSAgKy0tLS0tLS0t LS0rDSAgfCAgICAgICAgICB8DSAgfCBFbmQtVXNlciB8DSAgfCAgICAgICAgICB8DSAgKy0tLS0t LS0tLS0rDSAgICAgICBeDSAgICAgICB8DSAgICAgIChCKQ0gICstLS0tfC0tLS0tKyAgICAgICAg Q2xpZW50IElkZW50aWZpZXIgICAgICstLS0tLS0tLS0tLS0tLS0rDSAgfCAgICAgICAgIC0rLS0o QSktLS0gJiBSZWRpcmVjdCBVUkkgLS0tLS0+fCAgICAgICAgICAgICAgIHwNICB8ICBVc2VyLSAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IEF1dGhvcml6YXRpb24gfA0gIHwgIEFn ZW50ICAtfC0tKEIpLS0gVXNlciBhdXRoZW50aWNhdGVzIC0tPnwgICAgIFNlcnZlciAgICB8DSAg fCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg IHwNICB8ICAgICAgICAgLSstLShDKS0tIEF1dGhvcml6YXRpb24gQ29kZSAtLTx8ICAgICAgICAg ICAgICAgfA0gICstfC0tLS18LS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0t LS0tLS0tLS0tLS0rDSAgIChBKSAgKEMpDSAgICB8ICAgIHwNICAgIF4gICAgdg0gICstLS0tLS0t LS0rDSAgfCAgICAgICAgIHwNICB8ICBDbGllbnQgfA0gIHwgICAgICAgICB8DSAgKy0tLS0tLS0t LSsNDaBGaWd1cmWgMjogT2J0YWluaW5nIGFuIEF1dGhvcml6YXRpb24gQ29kZaAHBwENVGhlIGF1 dGhvcml6YXRpb24gY29kZSBmbG93IGlsbHVzdHJhdGVkIGluICBpbmNsdWRlcyB0aGUgZm9sbG93 aW5nIHN0ZXBzOiANKEEpDVRoZSBjbGllbnQgaW5pdGlhdGVzIHRoZSBmbG93IGJ5IGRpcmVjdGlu ZyB0aGUgZW5kLXVzZXIncyB1c2VyLWFnZW50IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidz IGVuZC11c2VyIGF1dGhvcml6YXRpb24gZW5kcG9pbnQuIFRoZSBjbGllbnQgaW5jbHVkZXMgaXRz IGNsaWVudCBpZGVudGlmaWVyLCByZXF1ZXN0ZWQgc2NvcGUsIGxvY2FsIHN0YXRlLCBhbmQgYSBy ZWRpcmVjdGlvbiBVUkkgKHRvIHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHNl bmQgdGhlIHVzZXItYWdlbnQgYmFjayBvbmNlIGFjY2VzcyBpcyBncmFudGVkIG9yIGRlbmllZCku IA0oQikNVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGVuZC11c2Vy ICh2aWEgdGhlIHVzZXItYWdlbnQpIGFuZCBlc3RhYmxpc2hlcyB3aGV0aGVyIHRoZSBlbmQtdXNl ciBncmFudHMgb3IgZGVuaWVzIHRoZSBjbGllbnQncyBhY2Nlc3MgcmVxdWVzdC4gDShDKQ1JZiBh Y2Nlc3MgaXMgZ3JhbnRlZCwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGRpcmVjdHMgdGhlIHVz ZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50IHVzaW5nIHRoZSByZWRpcmVjdGlvbiBVUkkgcHJv dmlkZWQuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpbmNsdWRlcyBhbiBhdXRob3JpemF0aW9u IGNvZGUgZm9yIHRoZSBjbGllbnQgdG8gdXNlIHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4uIA1P bmNlIHRoZSBjbGllbnQgb2J0YWlucyBhbiBhdXRob3JpemF0aW9uIGNvZGUsIGl0IHJlcXVlc3Rz IGFuIGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9u IHNlcnZlciAodXNpbmcgaXRzIGNsaWVudCBjcmVkZW50aWFscykgYW5kIHByZXNlbnRpbmcgdGhl IGF1dGhvcml6YXRpb24gY29kZSAoYWNjZXNzIGdyYW50KS4gDUluIGNhc2VzIHdoZXJlIHRoZSBj bGllbnQgaXMgaW5jYXBhYmxlIG9mIG1haW50YWluaW5nIGl0cyBjbGllbnQgY3JlZGVudGlhbHMg c2VjcmV0IChzdWNoIGFzIG5hdGl2ZSBhcHBsaWNhdGlvbnMgb3IgYW4gYXBwbGljYXRpb24gaW1w bGVtZW50ZWQgYXMgYSB1c2VyLWFnZW50IHNjcmlwdCksIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIGRpcmVjdGx5IHRvIHRoZSBjbGllbnQgaW4gc3RlcCAo QyksIGluc3RlYWQgb2YgaXNzdWluZyBhbiBhdXRob3JpemF0aW9uIGNvZGUuIA1PYnRhaW5pbmcg YW4gYXV0aG9yaXphdGlvbiBjb2RlIGlzIGRlc2NyaWJlZCBpbiAuIA0NAQ0TIEhZUEVSTElOSyBc bCAidG9jIiAUoFRPQ6AVBwcxLjQuMi6gIFJlc291cmNlIE93bmVyIFBhc3N3b3JkIENyZWRlbnRp YWxzBQ1UaGUgcmVzb3VyY2Ugb3duZXIgcGFzc3dvcmQgY3JlZGVudGlhbHMgKGUuZy4gYSB1c2Vy bmFtZSBhbmQgcGFzc3dvcmQpIGNhbiBiZSB1c2VkIGRpcmVjdGx5IGFzIGFuIGFjY2VzcyBncmFu dCB0byBvYnRhaW4gYW4gYWNjZXNzIHRva2VuLiBUaGUgY3JlZGVudGlhbHMgc2hvdWxkIG9ubHkg YmUgdXNlZCB3aGVuIHRoZXJlIGlzIGEgaGlnaCBkZWdyZWUgb2YgdHJ1c3QgYmV0d2VlbiB0aGUg cmVzb3VyY2Ugb3duZXIgYW5kIHRoZSBjbGllbnQgKGUuZy4gaXRzIGNvbXB1dGVyIG9wZXJhdGlu ZyBzeXN0ZW0gb3IgYSBoaWdobHkgcHJpdmlsZWdlZCBhcHBsaWNhdGlvbiksIGFuZCB3aGVuIG90 aGVyIGFjY2VzcyBncmFudCB0eXBlcyBhcmUgbm90IGF2YWlsYWJsZSAoc3VjaCBhcyBhbiBhdXRo b3JpemF0aW9uIGNvZGUpLiANRXZlbiB0aG91Z2ggdGhpcyBncmFudCB0eXBlIHJlcXVpcmVzIGRp cmVjdCBjbGllbnQgYWNjZXNzIHRvIHRoZSByZXNvdXJjZSBvd25lcidzIGNyZWRlbnRpYWxzLCB0 aGUgcmVzb3VyY2Ugb3duZXIncyBjcmVkZW50aWFscyBhcmUgdXNlZCBmb3IgYSBzaW5nbGUgcmVx dWVzdCBhbmQgYXJlIGV4Y2hhbmdlZCBmb3IgYW4gYWNjZXNzIHRva2VuLiBVbmxpa2UgdGhlIEhU VFAgQmFzaWMgYXV0aGVudGljYXRpb24gc2NoZW1lIGRlZmluZWQgaW4gLCB0aGlzIGdyYW50IHR5 cGUgZWxpbWluYXRlcyB0aGUgbmVlZCBmb3IgdGhlIGNsaWVudCB0byBzdG9yZSB0aGUgcmVzb3Vy Y2Utb3duZXIncyBjcmVkZW50aWFscyBmb3IgZnV0dXJlIHVzZS4gDUluICwgdGhlIGNsaWVudCBy ZXF1ZXN0cyBhdXRob3JpemF0aW9uIGZyb20gdGhlIHJlc291cmNlIG93bmVyIGRpcmVjdGx5LiBX aGVuIHRoZSByZXNvdXJjZSBvd25lciBpcyBhbiBlbmQtdXNlciwgdGhlIGNsaWVudCB0eXBpY2Fs bHkgcHJvbXB0cyB0aGUgZW5kLXVzZXIgZm9yIHRoZSB1c2VybmFtZSBhbmQgcGFzc3dvcmQuIA0N AQ0NDSAgKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LSsNICB8ICAgICAgICB8LS0oQSktIEF1dGhvcml6YXRpb24gUmVxdWVzdCAtPnwgUmVzb3VyY2Ug fA0gIHwgQ2xpZW50IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIE93bmVyICB8 DSAgfCAgICAgICAgfDwtKEIpLS0gVXNlcm5hbWUgJiBQYXNzd29yZCAtLS18ICAgICAgICAgIHwN ICArLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tKw0N oEZpZ3VyZaAzOiBPYnRhaW5pbmcgUmVzb3VyY2UgT3duZXIgUGFzc3dvcmQgQ3JlZGVudGlhbHOg BwcBDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzEuNC4zLqAgQ2xpZW50IENyZWRl bnRpYWxzDVRoZSBjbGllbnQgY3JlZGVudGlhbHMgY2FuIGJlIHVzZWQgYXMgYW4gYWNjZXNzIGdy YW50IHdoZW4gdGhlIGF1dGhvcml6YXRpb24gc2NvcGUgaXMgbGltaXRlZCB0byB0aGUgcHJvdGVj dGVkIHJlc291cmNlcyB1bmRlciB0aGUgY29udHJvbCBvZiB0aGUgY2xpZW50LCBvciBvdGhlciBw cm90ZWN0ZWQgcmVzb3VyY2VzIHByZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIuIENsaWVudCBjcmVkZW50aWFscyBhcmUgdXNlZCBhcyBhbiBhY2Nlc3MgZ3Jh bnQgdHlwaWNhbGx5IHdoZW4gdGhlIGNsaWVudCBpcyBhY3Rpbmcgb24gaXRzIG93biBiZWhhbGYg KHRoZSBjbGllbnQgaXMgYWxzbyB0aGUgcmVzb3VyY2Ugb3duZXIpLiANDQENEyBIWVBFUkxJTksg XGwgInRvYyIgFKBUT0OgFQcHMS40LjQuoCBSZWZyZXNoIFRva2VuDUFjY2VzcyB0b2tlbnMgdXN1 YWxseSBoYXZlIGEgc2hvcnRlciBsaWZldGltZSB0aGFuIGF1dGhvcml6ZWQgYnkgdGhlIHJlc291 cmNlIG93bmVyLiBXaGVuIGlzc3VpbmcgYW4gYWNjZXNzIHRva2VuLCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgY2FuBSBpbmNsdWRlIGEgcmVmcmVzaCB0b2tlbiB3aGljaCBpcyB1c2VkIGJ5IHRo ZSBjbGllbnQgdG8gb2J0YWluIGEgbmV3IGFjY2VzcyB0b2tlbiB3aGVuIHRoZSBjdXJyZW50IGFj Y2VzcyB0b2tlbiBleHBpcmVzLiBXaGVuIHJlcXVlc3RpbmcgYSBuZXcgYWNjZXNzIHRva2VuLCB0 aGUgcmVmcmVzaCB0b2tlbiBhY3RzIGFzIGFuIGFjY2VzcyBncmFudC4gVXNpbmcgYSByZWZyZXNo IHRva2VuIHJlbW92ZXMgdGhlIG5lZWQgdG8gaW50ZXJhY3Qgd2l0aCB0aGUgcmVzb3VyY2Ugb3du ZXIgYWdhaW4sIG9yIHRvIHN0b3JlIHRoZSBvcmlnaW5hbCBhY2Nlc3MgZ3JhbnQgdXNlZCB0byBv YnRhaW4gdGhlIGFjY2VzcyB0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbi4gDQ0BDQ0NICArLS0tLS0t LS0rICAgICAgICAgIEFjY2VzcyBHcmFudCAmICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNICB8ICAg ICAgICB8LS0oQSktLSBDbGllbnQgQ3JlZGVudGlhbHMgLS0+fCBBdXRob3JpemF0aW9uIHwNICB8 ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgU2VydmVyICAgIHwN ICB8ICAgICAgICB8PC0oQiktLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS0tfCAgICAgICAgICAgICAg IHwNICB8ICAgICAgICB8ICAgICAgICAgJiBSZWZyZXNoIFRva2VuICAgICAgKy0tLS0tLS0tLS0t LS0tLSsNICB8ICAgICAgICB8DSAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICstLS0tLS0tLS0tLS0tLS0rDSAgfCAgICAgICAgfC0tKEMpLS0tLS0gQWNjZXNzIFRva2Vu IC0tLS0tPnwgICAgICAgICAgICAgICB8DSAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICAgICAgICB8DSAgfCAgICAgICAgfDwtKEQpLS0gUHJvdGVjdGVk IFJlc291cmNlIC0tLXwgICAgUmVzb3VyY2UgICB8DSAgfCBDbGllbnQgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgICAgIFNlcnZlciAgICB8DSAgfCAgICAgICAgfC0tKEUpLS0tLS0g QWNjZXNzIFRva2VuIC0tLS0tPnwgICAgICAgICAgICAgICB8DSAgfCAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8DSAgfCAgICAgICAgfDwtKEYp LS0gSW52YWxpZCBUb2tlbiBFcnJvciAtLXwgICAgICAgICAgICAgICB8DSAgfCAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDSAgfCAgICAgICAg fA0gIHwgICAgICAgIHwgICAgICAgICAgUmVmcmVzaCBUb2tlbiAmICAgICArLS0tLS0tLS0tLS0t LS0tKw0gIHwgICAgICAgIHwtLShHKS0tIENsaWVudCBDcmVkZW50aWFscyAtLT58IEF1dGhvcml6 YXRpb24gfA0gIHwgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBT ZXJ2ZXIgICAgfA0gIHwgICAgICAgIHw8LShIKS0tLS0tIEFjY2VzcyBUb2tlbiAtLS0tLS18ICAg ICAgICAgICAgICAgfA0gICstLS0tLS0tLSsgICAgICYgT3B0aW9uYWwgUmVmcmVzaCBUb2tlbiAr LS0tLS0tLS0tLS0tLS0tKw0NoEZpZ3VyZaA0OiBSZWZyZXNoaW5nIGFuIEFjY2VzcyBUb2tlbqAH BwENVGhlIHJlZnJlc2ggdG9rZW4gZmxvdyBpbGx1c3RyYXRlZCBpbiAgaW5jbHVkZXMgdGhlIGZv bGxvd2luZyBzdGVwczogDShBKQ1UaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0b2tlbiBi eSBhdXRoZW50aWNhdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB1c2luZyBpdHMg Y2xpZW50IGNyZWRlbnRpYWxzLCBhbmQgcHJlc2VudGluZyBhbiBhY2Nlc3MgZ3JhbnQuIA0oQikN VGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHZhbGlkYXRlcyB0aGUgY2xpZW50IGNyZWRlbnRpYWxz IGFuZCB0aGUgYWNjZXNzIGdyYW50BSwgYW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9r ZW4gYW5kIGEgcmVmcmVzaCB0b2tlbgUuIA0oQykNVGhlIGNsaWVudCBtYWtlcyBhIHByb3RlY3Rl ZCByZXNvdXJjZSByZXF1ZXN0cyB0byB0aGUgcmVzb3VyY2Ugc2VydmVyIGJ5IHByZXNlbnRpbmcg dGhlIGFjY2VzcyB0b2tlbi4gDShEKQ1UaGUgcmVzb3VyY2Ugc2VydmVyIHZhbGlkYXRlcyB0aGUg YWNjZXNzIHRva2VuLCBhbmQgaWYgdmFsaWQsIHNlcnZlcyB0aGUgcmVxdWVzdC4gDShFKQ1TdGVw cyAoQykgYW5kIChEKSByZXBlYXQgdW50aWwgdGhlIGFjY2VzcyB0b2tlbiBleHBpcmVzLiBJZiB0 aGUgY2xpZW50IGRvZXMgbm90IGtub3cgdGhlIGFjY2VzcyB0b2tlbiBleHBpcmVkLCBpdCBtYWtl cyBhbm90aGVyIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0LiBPdGhlcndpc2UsIGl0IHNraXBz IHRvIHN0ZXAgKEcpLiANKEYpDVNpbmNlIHRoZSBhY2Nlc3MgdG9rZW4gaXMgaW52YWxpZCAoZXhw aXJlZCksIHRoZSByZXNvdXJjZSBzZXJ2ZXIgcmV0dXJucyBhbiBpbnZhbGlkIHRva2VuIGVycm9y LiANKEcpDVRoZSBjbGllbnQgcmVxdWVzdHMgYSBuZXcgYWNjZXNzIHRva2VuIGJ5IGF1dGhlbnRp Y2F0aW5nIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHVzaW5nIGl0cyBjbGllbnQgY3Jl ZGVudGlhbHMsIGFuZCBwcmVzZW50aW5nIHRoZSByZWZyZXNoIHRva2VuIChhcyB0aGUgYWNjZXNz IGdyYW50KS4gDShIKQ1UaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdmFsaWRhdGVzIHRoZSBjbGll bnQgY3JlZGVudGlhbHMgYW5kIHRoZSByZWZyZXNoIHRva2VuLCBhbmQgaWYgdmFsaWQgaXNzdWVz IGEgbmV3IGFjY2VzcyB0b2tlbiAoYW5kIG9wdGlvbmFsbHksIGEgbmV3IHJlZnJlc2ggdG9rZW4p LiANDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHMS40LjUuoCBBc3NlcnRpb24NQXNz ZXJ0aW9ucyBwcm92aWRlIGEgYnJpZGdlIGJldHdlZW4gT0F1dGggYW5kIG90aGVyIHRydXN0IGZy YW1ld29ya3MuIFRoZXkgZW5hYmxlIHRoZSBjbGllbnQgdG8gdXRpbGl6ZSBleGlzdGluZyB0cnVz dCByZWxhdGlvbnNoaXBzIGluIG9yZGVyIHRvIG9idGFpbiBhbiBhY2Nlc3MgdG9rZW4uIFRoZSBh Y2Nlc3MgZ3JhbnQgcmVwcmVzZW50ZWQgYnkgYW4gYXNzZXJ0aW9uIGRlcGVuZHMgb24gdGhlIGFz c2VydGlvbiB0eXBlLCBpdHMgY29udGVudCwgYW5kIGhvdyBpdCB3YXMgaXNzdWVkLCB3aGljaCBh cmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uIA1Bc3NlcnRpb25zIGFy ZSB1c2VkIGFzIHBhcnQgb2YgdGhlIHByb3RvY29sIGV4dGVuc2liaWxpdHkgbW9kZWwsIHByb3Zp ZGluZyBhIHdheSBmb3IgYXV0aG9yaXphdGlvbiBzZXJ2ZXJzIHRvIHN1cHBvcnQgYWRkaXRpb25h bCBhY2Nlc3MgZ3JhbnQgdHlwZXMuIA0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAUoFRPQ6AVBwcy LqAgQ2xpZW50IFByb2ZpbGVzDVtbIGFkZCBpbnRybyBhbmQgZmluZCBuZXcgbmFtZXMgZm9yIHRo ZSBwcm9maWxlcy4gdGhpcyBzZWN0aW9uIHdpbGwgaGF2ZSBub3JtYXRpdmUgbGFuZ3VhZ2UgaW4g ZnV0dXJlIGRyYWZ0cywgc2ltaWxhciB0byAtMDUgYW5kIGVhcmxpZXIuIF1dIA0NAQ0TIEhZUEVS TElOSyBcbCAidG9jIiAUoFRPQ6AVBwcyLjEuoCBXZWIgU2VydmVyDVRoZSB3ZWIgc2VydmVyIHBy b2ZpbGUgaXMgc3VpdGFibGUgZm9yIGNsaWVudHMgY2FwYWJsZSBvZiBpbnRlcmFjdGluZyB3aXRo IHRoZSBlbmQtdXNlcidzIHVzZXItYWdlbnQgBSh0eXBpY2FsbHkgYSB3ZWIgYnJvd3NlcikgYW5k IGNhcGFibGUgb2YgcmVjZWl2aW5nIGluY29taW5nIHJlcXVlc3RzICh2aWEgcmVkaXJlY3Rpb24p IGZyb20gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIChjYXBhYmxlIG9mIGFjdGluZyBhcyBhbiBI VFRQIHNlcnZlcikuIA0NAQ0NDSAgKy0tLS0tLS0tLS0rICAgICAgICAgIENsaWVudCBJZGVudGlm aWVyICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNICB8ICAgICAgICAgLSstLS0tKEEpLS0tICYgUmVk aXJlY3QgVVJJIC0tLS0tLT58ICAgICAgICAgICAgICAgfA0gIHwgRW5kLXVzZXIgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgQXV0aG9yaXphdGlvbiB8DSAgfCAgICBhdCAgICB8 PC0tLShCKS0tIFVzZXIgYXV0aGVudGljYXRlcyAtLS0+fCAgICAgU2VydmVyICAgIHwNICB8IEJy b3dzZXIgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fA0gIHwgICAgICAgICAtKy0tLS0oQyktLSBBdXRob3JpemF0aW9uIENvZGUgLS0tPHwgICAgICAg ICAgICAgICB8DSAgKy18LS0tLXwtLS0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0tLS0tLS0tLS0tLS0tLSsNICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgXiAgICAgIHYNICAgKEEpICAoQykgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgIHwNICAgIHwgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICAgIHwNICAgIF4gICAgdiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwNICArLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIHwNICB8ICAgICAgICAgfD4tLS0oRCktLSBD bGllbnQgQ3JlZGVudGlhbHMsIC0tLS0tLS0tJyAgICAgIHwNICB8ICBTZXJ2ZXIgfCAgICAgICAg ICBBdXRob3JpemF0aW9uIENvZGUsICAgICAgICAgICAgICAgIHwNICB8ICAtQmFzZWQgfCAgICAg ICAgICAgICYgUmVkaXJlY3QgVVJJICAgICAgICAgICAgICAgICAgIHwNICB8ICBDbGllbnQgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNICB8ICAgICAgICAg fDwtLS0oRSktLS0tLSBBY2Nlc3MgVG9rZW4gLS0tLS0tLS0tLS0tLS0tLS0tLScNICArLS0tLS0t LS0tKyAgICAgICAody8gT3B0aW9uYWwgUmVmcmVzaCBUb2tlbikNDaBGaWd1cmWgNTogV2ViIFNl cnZlciBGbG93oAcHAQ1UaGUgd2ViIHNlcnZlciBmbG93IGlsbHVzdHJhdGVkIGluICBpbmNsdWRl cyB0aGUgZm9sbG93aW5nIHN0ZXBzOiANKEEpDVRoZSB3ZWIgY2xpZW50IGluaXRpYXRlcyB0aGUg ZmxvdyBieSByZWRpcmVjdGluZyB0aGUgZW5kLXVzZXIncyB1c2VyLWFnZW50IHRvIHRoZSBlbmQt dXNlciBhdXRob3JpemF0aW9uIGVuZHBvaW50IGFzIGRlc2NyaWJlZCBpbiAuIFRoZSBjbGllbnQg aW5jbHVkZXMgaXRzIGNsaWVudCBpZGVudGlmaWVyLCByZXF1ZXN0ZWQgc2NvcGUsIGxvY2FsIHN0 YXRlLCBhbmQgYSByZWRpcmVjdCBVUkkgdG8gd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gc2VydmVy IHdpbGwgc2VuZCB0aGUgZW5kLXVzZXIgYmFjayBvbmNlIGFjY2VzcyBpcyBncmFudGVkIChvciBk ZW5pZWQpLiANKEIpDVRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBl bmQtdXNlciAodmlhIHRoZSB1c2VyLWFnZW50KSBhbmQgZXN0YWJsaXNoZXMgd2hldGhlciB0aGUg ZW5kLXVzZXIgZ3JhbnRzIG9yIGRlbmllcyB0aGUgY2xpZW50J3MgYWNjZXNzIHJlcXVlc3QuIA0o QykNQXNzdW1pbmcgdGhlIGVuZC11c2VyIGdyYW50ZWQgYWNjZXNzLCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudCB0byB0 aGUgcmVkaXJlY3Rpb24gVVJJIHByb3ZpZGVkIGVhcmxpZXIuIFRoZSBhdXRob3JpemF0aW9uIGlu Y2x1ZGVzIGFuIGF1dGhvcml6YXRpb24gY29kZSBmb3IgdGhlIGNsaWVudCB0byB1c2UgdG8gb2J0 YWluIGFuIGFjY2VzcyB0b2tlbi4gDShEKQ1UaGUgY2xpZW50IHJlcXVlc3RzIGFuIGFjY2VzcyB0 b2tlbiBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBieSBhdXRoZW50aWNhdGluZyBhbmQg aW5jbHVkaW5nIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgcmVjZWl2ZWQgaW4gdGhlIHByZXZpb3Vz IHN0ZXAgYXMgZGVzY3JpYmVkIGluIC4gDShFKQ1UaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdmFs aWRhdGVzIHRoZSBjbGllbnQgY3JlZGVudGlhbHMgYW5kIHRoZSBhdXRob3JpemF0aW9uIGNvZGUg YW5kIHJlc3BvbmRzIGJhY2sgd2l0aCB0aGUgYWNjZXNzIHRva2VuLiANDQENEyBIWVBFUkxJTksg XGwgInRvYyIgFKBUT0OgFQcHMi4yLqAgVXNlci1BZ2VudA1UaGUgdXNlci1hZ2VudCBwcm9maWxl IGlzIHN1aXRhYmxlIGZvciBjbGllbnQgYXBwbGljYXRpb25zIHJlc2lkaW5nIGluIGEgdXNlci1h Z2VudAUsIHR5cGljYWxseSBpbXBsZW1lbnRlZCBpbiBhIGJyb3dzZXIgdXNpbmcgYSBzY3JpcHRp bmcgbGFuZ3VhZ2Ugc3VjaCBhcyBKYXZhU2NyaXB0LiBUaGVzZSBjbGllbnRzIGNhbm5vdCBrZWVw IGNsaWVudCBzZWNyZXRzIGNvbmZpZGVudGlhbCBhbmQgdGhlIGF1dGhlbnRpY2F0aW9uIG9mIHRo ZSBjbGllbnQgaXMgYmFzZWQgb24gdGhlIHVzZXItYWdlbnQncyBzYW1lLW9yaWdpbiBwb2xpY3ku IA1Vbmxpa2Ugb3RoZXIgcHJvZmlsZXMgaW4gd2hpY2ggdGhlIGNsaWVudCBtYWtlcyBzZXBhcmF0 ZSByZXF1ZXN0cyBmb3IgZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBhbmQgYWNjZXNzIHRva2VuLCB0 aGUgY2xpZW50IHJlY2VpdmVzIHRoZSBhY2Nlc3MgdG9rZW4gYXMgYSByZXN1bHQgb2YgdGhlIGVu ZC11c2VyIGF1dGhvcml6YXRpb24gcmVxdWVzdCBpbiB0aGUgZm9ybSBvZiBhbiBIVFRQIHJlZGly ZWN0aW9uLiBUaGUgY2xpZW50IHJlcXVlc3RzIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB0byBy ZWRpcmVjdCB0aGUgdXNlci1hZ2VudCB0byBhbm90aGVyIHdlYiBzZXJ2ZXIgb3IgbG9jYWwgcmVz b3VyY2UgYWNjZXNzaWJsZSB0byB0aGUgdXNlci1hZ2VudCB3aGljaCBpcyBjYXBhYmxlIG9mIGV4 dHJhY3RpbmcgdGhlIGFjY2VzcyB0b2tlbiBmcm9tIHRoZSByZXNwb25zZSBhbmQgcGFzc2luZyBp dCB0byB0aGUgY2xpZW50LiANVGhpcyB1c2VyLWFnZW50IHByb2ZpbGUgZG9lcyBub3QgdXRpbGl6 ZSB0aGUgY2xpZW50IHNlY3JldCBzaW5jZSB0aGUgY2xpZW50IGV4ZWN1dGFibGVzIHJlc2lkZSBv biB0aGUgZW5kLXVzZXIncyBjb21wdXRlciBvciBkZXZpY2Ugd2hpY2ggbWFrZXMgdGhlIGNsaWVu dCBzZWNyZXQgYWNjZXNzaWJsZSBhbmQgZXhwbG9pdGFibGUuIEJlY2F1c2UgdGhlIGFjY2VzcyB0 b2tlbiBpcyBlbmNvZGVkIGludG8gdGhlIHJlZGlyZWN0aW9uIFVSSSwgaXQgbWF5IGJlIGV4cG9z ZWQgdG8gdGhlIGVuZC11c2VyIGFuZCBvdGhlciBhcHBsaWNhdGlvbnMgcmVzaWRpbmcgb24gdGhl IGNvbXB1dGVyIG9yIGRldmljZS4gDQ0BDQ0NICAgICAgICAgKy0tLS0tLS0tLS0rICAgICAgICAg IENsaWVudCBJZGVudGlmaWVyICAgICArLS0tLS0tLS0tLS0tLS0tLSsNICAgICAgICAgfCAgICAg ICAgICB8Pi0tLShBKS0tICYgUmVkaXJlY3Rpb24gVVJJIC0tLT58ICAgICAgICAgICAgICAgIHwN ICAgICAgICAgfCAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgIHwNICBFbmQgPC0tKyAgLSAgLSAgLSArLS0tLShCKS0tIFVzZXIgYXV0aGVu dGljYXRlcyAtLT58ICBBdXRob3JpemF0aW9uIHwNICBVc2VyICAgfCAgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICBTZXJ2ZXIgICAgIHwNICAgICAgICAgfCAg ICAgICAgICB8PC0tLShDKS0tLSBSZWRpcmVjdCBVUkkgLS0tLS0tLTx8ICAgICAgICAgICAgICAg IHwNICAgICAgICAgfCAgQ2xpZW50ICB8ICAgICAgICAgd2l0aCBBY2Nlc3MgVG9rZW4gICAgICB8 ICAgICAgICAgICAgICAgIHwNICAgICAgICAgfCAgICBpbiAgICB8ICAgICAgICAgICAgaW4gRnJh Z21lbnQgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLSsNICAgICAgICAgfCAgQnJvd3NlciB8DSAg ICAgICAgIHwgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tLS0tLS0rDSAgICAgICAgIHwgICAgICAgICAgfD4tLS0oRCktLS0gUmVkaXJlY3QgVVJJ IC0tLS0tLS0+fCAgICAgICAgICAgICAgICB8DSAgICAgICAgIHwgICAgICAgICAgfCAgICAgICAg IHdpdGhvdXQgRnJhZ21lbnQgICAgICAgfCAgIFdlYiBTZXJ2ZXIgICB8DSAgICAgICAgIHwgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHdpdGggQ2xpZW50ICB8 DSAgICAgICAgIHwgICAgKEYpICAgfDwtLS0oRSktLS0gV2ViIFBhZ2Ugd2l0aCAtLS0tLS08fCAg ICBSZXNvdXJjZSAgICB8DSAgICAgICAgIHwgIEFjY2VzcyAgfCAgICAgICAgICAgICAgU2NyaXB0 ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICB8DSAgICAgICAgIHwgICBUb2tlbiAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0rDSAgICAgICAgICst LS0tLS0tLS0tKw0NoEZpZ3VyZaA2OiBVc2VyLUFnZW50IEZsb3egBwcBDVRoZSB1c2VyLWFnZW50 IGZsb3cgaWxsdXN0cmF0ZWQgaW4gIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgc3RlcHM6IA0oQSkN VGhlIGNsaWVudCBzZW5kcyB0aGUgdXNlci1hZ2VudCB0byB0aGUgZW5kLXVzZXIgYXV0aG9yaXph dGlvbiBlbmRwb2ludCBhcyBkZXNjcmliZWQgaW4gLiBUaGUgY2xpZW50IGluY2x1ZGVzIGl0cyBj bGllbnQgaWRlbnRpZmllciwgcmVxdWVzdGVkIHNjb3BlLCBsb2NhbCBzdGF0ZSwgYW5kIGEgcmVk aXJlY3QgVVJJIHRvIHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciB3aWxsIHNlbmQgdGhl IGVuZC11c2VyIGJhY2sgb25jZSBhdXRob3JpemF0aW9uIGlzIGdyYW50ZWQgKG9yIGRlbmllZCku IA0oQikNVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhlbnRpY2F0ZXMgdGhlIGVuZC11c2Vy ICh2aWEgdGhlIHVzZXItYWdlbnQpIGFuZCBlc3RhYmxpc2hlcyB3aGV0aGVyIHRoZSBlbmQtdXNl ciBncmFudHMgb3IgZGVuaWVzIHRoZSBjbGllbnQncyBhY2Nlc3MgcmVxdWVzdC4gDShDKQ1JZiB0 aGUgZW5kLXVzZXIgZ3JhbnRlZCBhY2Nlc3MsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciByZWRp cmVjdHMgdGhlIHVzZXItYWdlbnQgdG8gdGhlIHJlZGlyZWN0aW9uIFVSSSBwcm92aWRlZCBlYXJs aWVyLiBUaGUgcmVkaXJlY3Rpb24gVVJJIGluY2x1ZGVzIHRoZSBhY2Nlc3MgdG9rZW4gaW4gdGhl IFVSSSBmcmFnbWVudC4gDShEKQ1UaGUgdXNlci1hZ2VudCBmb2xsb3dzIHRoZSByZWRpcmVjdGlv biBpbnN0cnVjdGlvbnMgYnkgbWFraW5nIGEgcmVxdWVzdCB0byB0aGUgd2ViIHNlcnZlciB3aGlj aCBkb2VzIG5vdCBpbmNsdWRlIHRoZSBmcmFnbWVudC4gVGhlIHVzZXItYWdlbnQgcmV0YWlucyB0 aGUgZnJhZ21lbnQgaW5mb3JtYXRpb24gbG9jYWxseS4gDShFKQ1UaGUgd2ViIHNlcnZlciByZXR1 cm5zIGEgd2ViIHBhZ2UgKHR5cGljYWxseSBhbiBIVE1MIHBhZ2Ugd2l0aCBhbiBlbWJlZGRlZCBz Y3JpcHQpIGNhcGFibGUgb2YgYWNjZXNzaW5nIHRoZSBmdWxsIHJlZGlyZWN0aW9uIFVSSSBpbmNs dWRpbmcgdGhlIGZyYWdtZW50IHJldGFpbmVkIGJ5IHRoZSB1c2VyLWFnZW50LCBhbmQgZXh0cmFj dGluZyB0aGUgYWNjZXNzIHRva2VuIChhbmQgb3RoZXIgcGFyYW1ldGVycykgY29udGFpbmVkIGlu IHRoZSBmcmFnbWVudC4gDShGKQ1UaGUgdXNlci1hZ2VudCBleGVjdXRlcyB0aGUgc2NyaXB0IHBy b3ZpZGVkIGJ5IHRoZSB3ZWIgc2VydmVyIGxvY2FsbHksIHdoaWNoIGV4dHJhY3RzIHRoZSBhY2Nl c3MgdG9rZW4gYW5kIHBhc3NlcyBpdCB0byB0aGUgY2xpZW50LiANDQENEyBIWVBFUkxJTksgXGwg InRvYyIgFKBUT0OgFQcHMi4zLqAgTmF0aXZlIEFwcGxpY2F0aW9uDU5hdGl2ZSBhcHBsaWNhdGlv bnMgYXJlIGNsaWVudHMgcnVubmluZyBhcyBuYXRpdmUgY29kZSAFb24gdGhlIGVuZC11c2VyJ3Mg Y29tcHV0ZXIgb3IgZGV2aWNlIChpLmUuIGV4ZWN1dGluZyBvdXRzaWRlIGEgdXNlci1hZ2VudCBv ciBhcyBhIGRlc2t0b3AgcHJvZ3JhbSkuIFRoZXNlIGNsaWVudHMgYXJlIG9mdGVuIGNhcGFibGUg b2YgaW50ZXJhY3Rpbmcgd2l0aCAob3IgZW1iZWRkaW5nKSB0aGUgZW5kLXVzZXIncyB1c2VyLWFn ZW50IGJ1dCBhcmUgbGltaXRlZCBpbiBob3cgc3VjaCBpbnRlcmFjdGlvbiBhZmZlY3RzIHRoZWly IGVuZC11c2VyIGV4cGVyaWVuY2UuIEluIG1hbnkgY2FzZXMsIG5hdGl2ZSBhcHBsaWNhdGlvbnMg YXJlIGluY2FwYWJsZSBvZiByZWNlaXZpbmcgZGlyZWN0IGNhbGxiYWNrIHJlcXVlc3RzIGZyb20g dGhlIHNlcnZlciAoZS5nLiBmaXJld2FsbCwgb3BlcmF0aW5nIHN5c3RlbSByZXN0cmljdGlvbnMp LiANTmF0aXZlIGFwcGxpY2F0aW9uIGNsaWVudHMgY2FuIAViZSBpbXBsZW1lbnRlZCBpbiBkaWZm ZXJlbnQgd2F5cyBiYXNlZCBvbiB0aGVpciByZXF1aXJlbWVudHMgYW5kIGRlc2lyZWQgZW5kLXVz ZXIgZXhwZXJpZW5jZS4gTmF0aXZlIGFwcGxpY2F0aW9uIGNsaWVudHMgY2FuBTogDVV0aWxpemUg dGhlIGVuZC11c2VyIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgYXMgZGVzY3JpYmVkIGluICBieSBs YXVuY2hpbmcgYW4gZXh0ZXJuYWwgdXNlci1hZ2VudC4gVGhlIGNsaWVudCBjYW4gY2FwdHVyZSB0 aGUgcmVzcG9uc2UgYnkgcHJvdmlkaW5nIGEgcmVkaXJlY3Rpb24gVVJJIHdpdGggYSBjdXN0b20g VVJJIHNjaGVtZSAocmVnaXN0ZXJlZCB3aXRoIHRoZSBvcGVyYXRpbmcgc3lzdGVtIHRvIGludm9r ZSB0aGUgY2xpZW50IGFwcGxpY2F0aW9uKSwgb3IgYnkgcHJvdmlkaW5nIGEgcmVkaXJlY3Rpb24g VVJJIHBvaW50aW5nIHRvIGEgc2VydmVyLWhvc3RlZCByZXNvdXJjZSB1bmRlciB0aGUgY2xpZW50 J3MgY29udHJvbCB3aGljaCBtYWtlcyB0aGUgcmVzcG9uc2UgYXZhaWxhYmxlIHRvIHRoZSBjbGll bnQgKGUuZy4gdXNpbmcgdGhlIHdpbmRvdyB0aXRsZSBvciBvdGhlciBsb2NhdGlvbnMgYWNjZXNz aWJsZSBmcm9tIG91dHNpZGUgdGhlIHVzZXItYWdlbnQpLiANVXRpbGl6ZSB0aGUgZW5kLXVzZXIg YXV0aG9yaXphdGlvbiBlbmRwb2ludCBhcyBkZXNjcmliZWQgaW4gIGJ5IHVzaW5nIGFuIGVtYmVk ZGVkIHVzZXItYWdlbnQuIFRoZSBjbGllbnQgb2J0YWlucyB0aGUgcmVzcG9uc2UgYnkgZGlyZWN0 bHkgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBlbWJlZGRlZCB1c2VyLWFnZW50LiANUHJvbXB0IGVu ZC11c2VycyBmb3IgdGhlaXIgcGFzc3dvcmQgYW5kIHVzZSB0aGVtIGRpcmVjdGx5IHRvIG9idGFp biBhbiBhY2Nlc3MgdG9rZW4uIFRoaXMgaXMgZ2VuZXJhbGx5IGRpc2NvdXJhZ2VkLCBhcyBpdCBo YW5kcyB0aGUgZW5kLXVzZXIncyBwYXNzd29yZCBkaXJlY3RseSB0byB0aGUgdGhpcmQtcGFydHkg Y2xpZW50IHdoaWNoIGluIHR1cm4gaGFzIHRvIHN0b3JlIGl0IGluIGNsZWFyLXRleHQuIEl0IGFs c28gcmVxdWlyZXMgdGhlIHNlcnZlciB0byBzdXBwb3J0IHBhc3N3b3JkLWJhc2VkIGF1dGhlbnRp Y2F0aW9uLiANV2hlbiBjaG9vc2luZyBiZXR3ZWVuIGxhdW5jaGluZyBhbiBleHRlcm5hbCBicm93 c2VyIGFuZCBhbiBlbWJlZGRlZCB1c2VyLWFnZW50LCBkZXZlbG9wZXJzIHNob3VsZCBjb25zaWRl ciB0aGUgZm9sbG93aW5nOiANRXh0ZXJuYWwgdXNlci1hZ2VudHMgbWF5IGltcHJvdmUgY29tcGxl dGlvbiByYXRlIGFzIHRoZSBlbmQtdXNlciBtYXkgYWxyZWFkeSBiZSBsb2dnZWQtaW4gYW5kIG5v dCBoYXZlIHRvIHJlLWF1dGhlbnRpY2F0ZS4gDUVtYmVkZGVkIHVzZXItYWdlbnRzIG9mdGVuIG9m ZmVyIGEgYmV0dGVyIGVuZC11c2VyIGZsb3csIGFzIHRoZXkgcmVtb3ZlIHRoZSBuZWVkIHRvIHN3 aXRjaCBjb250ZXh0IGFuZCBvcGVuIG5ldyB3aW5kb3dzLiANRW1iZWRkZWQgdXNlci1hZ2VudHMg cG9zZSBhIHNlY3VyaXR5IGNoYWxsZW5nZSBiZWNhdXNlIHVzZXJzIGFyZSBhdXRoZW50aWNhdGlu ZyBpbiBhbiB1bmlkZW50aWZpZWQgd2luZG93IHdpdGhvdXQgYWNjZXNzIHRvIHRoZSB2aXN1YWwg cHJvdGVjdGlvbnMgb2ZmZXJlZCBieSBtYW55IHVzZXItYWdlbnRzLiANDQENEyBIWVBFUkxJTksg XGwgInRvYyIgFKBUT0OgFQcHMi40LqAgQXV0b25vbW91cw1BdXRvbm9tb3VzIGNsaWVudHMgdXRp bGl6ZSBhbiBleGlzdGluZyB0cnVzdCByZWxhdGlvbnNoaXAgb3IgZnJhbWV3b3JrIHRvIGVzdGFi bGlzaCBhdXRob3JpemF0aW9uLiBBdXRvbm9tb3VzIGNsaWVudHMgY2FuBSBiZSBpbXBsZW1lbnRl ZCBpbiBkaWZmZXJlbnQgd2F5cyBiYXNlZCBvbiB0aGVpciByZXF1aXJlbWVudHMgYW5kIHRoZSBl eGlzdGluZyB0cnVzdCBmcmFtZXdvcmsFIHRoZXkgcmVseSB1cG9uLiBBdXRvbm9tb3VzIGNsaWVu dHMgY2FuOiANT2J0YWluIGFuIGFjY2VzcyB0b2tlbiBieSBhdXRoZW50aWNhdGluZyB3aXRoIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciB1c2luZyB0aGVpciBjbGllbnQgY3JlZGVudGlhbHMuIFRo ZSBzY29wZSBvZiB0aGUgYWNjZXNzIHRva2VuIGlzIGxpbWl0ZWQgdG8gdGhlIHByb3RlY3RlZCBy ZXNvdXJjZXMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIGNsaWVudCwgb3IgdGhhdCBvZiBhbm90 aGVyIHJlc291cmNlIG93bmVyIHByZXZpb3VzbHkgYXJyYW5nZWQgd2l0aCB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIuIA1Vc2UgYW4gZXhpc3RpbmcgYWNjZXNzIGdyYW50IGV4cHJlc3NlZCBhcyBh biBhc3NlcnRpb24gdXNpbmcgYW4gYXNzZXJ0aW9uIGZvcm1hdCBzdXBwb3J0ZWQgYnkgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyLiBVc2luZyBhc3NlcnRpb25zIHJlcXVpcmVzIHRoZSBjbGllbnQg dG8gb2J0YWluIGFuIGFzc2VydGlvbiAoc3VjaCBhcyBhICBbT0FTSVMuc2FtbB5jb3JlHjIuMB5v c10gYXNzZXJ0aW9uKSBmcm9tIGFuIGFzc2VydGlvbiBpc3N1ZXIgb3IgdG8gc2VsZi1pc3N1ZSBh biBhc3NlcnRpb24uIFRoZSBhc3NlcnRpb24gZm9ybWF0LCB0aGUgcHJvY2VzcyBieSB3aGljaCB0 aGUgYXNzZXJ0aW9uIGlzIG9idGFpbmVkLCBhbmQgdGhlIG1ldGhvZCBvZiB2YWxpZGF0aW5nIHRo ZSBhc3NlcnRpb24gYXJlIGRlZmluZWQgYnkgdGhlIGFzc2VydGlvbiBpc3N1ZXIgYW5kIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciwgYW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4gDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzMuoCBDbGllbnQg Q3JlZGVudGlhbHMNV2hlbiBpbnRlcmFjdGluZyB3aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ciwgdGhlIGNsaWVudCBpZGVudGlmaWVzIGl0c2VsZiB1c2luZyBhIHNldCBvZiBjbGllbnQgY3Jl ZGVudGlhbHMgd2hpY2ggaW5jbHVkZSBhIGNsaWVudCBpZGVudGlmaWVyIGFuZCBvdGhlciBwcm9w ZXJ0aWVzIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24uIFRoZSBtZWFucyB0aHJvdWdoIHdoaWNo IHRoZSBjbGllbnQgb2J0YWlucyBpdHMgY3JlZGVudGlhbHMgYXJlIGJleW9uZCB0aGUgc2NvcGUg b2YgdGhpcyBzcGVjaWZpY2F0aW9uLCBidXQgdHlwaWNhbGx5IGludm9sdmUgcmVnaXN0cmF0aW9u IHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiANRHVlIHRvIHRoZSBuYXR1cmUgb2Ygc29t ZSBjbGllbnRzLCBhdXRob3JpemF0aW9uIHNlcnZlcnMgU0hPVUxEIE5PVCBtYWtlIGFzc3VtcHRp b25zIGFib3V0IHRoZSBjb25maWRlbnRpYWxpdHkgb2YgY2xpZW50IHNlY3JldHMgd2l0aG91dCBl c3RhYmxpc2hpbmcgdHJ1c3Qgd2l0aCB0aGUgY2xpZW50LiBBdXRob3JpemF0aW9uIHNlcnZlcnMg U0hPVUxEIE5PVCBpc3N1ZSBjbGllbnQgc2VjcmV0cyB0byBjbGllbnRzIGluY2FwYWJsZSBvZiBr ZWVwaW5nIHRoZWlyIHNlY3JldHMgY29uZmlkZW50aWFsLiANVGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyIE1BWSBhdXRoZW50aWNhdGUgdGhlIGNsaWVudCB1c2luZyBhbnkgYXBwcm9wcmlhdGUgc2V0 IG9mIGNyZWRlbnRpYWxzIGFuZCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzLiBUaGUgY2xpZW50IE1V U1QgTk9UIGluY2x1ZGUgbW9yZSB0aGFuIG9uZSBzZXQgb2YgY3JlZGVudGlhbHMgb3IgYXV0aGVu dGljYXRpb24gbWVjaGFuaXNtIHdpdGggZWFjaCByZXF1ZXN0LiANDQENEyBIWVBFUkxJTksgXGwg InRvYyIgFKBUT0OgFQcHMy4xLqAgQ2xpZW50IFBhc3N3b3JkIENyZWRlbnRpYWxzDVRoZSBjbGll bnQgcGFzc3dvcmQgY3JlZGVudGlhbHMgdXNlIGEgc2hhcmVkIHN5bW1ldHJpYyBzZWNyZXQgdG8g YXV0aGVudGljYXRlIHRoZSBjbGllbnQuIFRoZSBjbGllbnQgaWRlbnRpZmllciBhbmQgcGFzc3dv cmQgYXJlIGluY2x1ZGVkIGluIHRoZSByZXF1ZXN0IHVzaW5nIHRoZSBIVFRQIEJhc2ljIGF1dGhl bnRpY2F0aW9uIHNjaGVtZSBhcyBkZWZpbmVkIGluICBieSBpbmNsdWRpbmcgdGhlIGNsaWVudCBp ZGVudGlmaWVyIGFzIHRoZSB1c2VybmFtZSBhbmQgY2xpZW50IHBhc3N3b3JkIGFzIHRoZSBwYXNz d29yZC4gDUZvciBleGFtcGxlIChsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMg b25seSk6IA0NDSAgUE9TVCAvdG9rZW4gSFRUUC8xLjENICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5j b20NICBBdXRob3JpemF0aW9uOiBCYXNpYyBjelpDYUdSU2EzRjBNenBuV0RGbVFtRjBNMkpXDSAg Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQNDSAgZ3JhbnRf dHlwZT1hdXRob3JpemF0aW9uX2NvZGUmY29kZT1pMVdzUm4xdUIxJg0gIHJlZGlyZWN0X3VyaT1o dHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYg0NQWx0ZXJuYXRpdmVseSwg dGhlIGNsaWVudCBNQVkgaW5jbHVkZSB0aGUgcGFzc3dvcmQgaW4gdGhlIHJlcXVlc3QgYm9keSB1 c2luZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMFOiANY2xpZW50X2lkDVJFUVVJUkVELiBUaGUg Y2xpZW50IGlkZW50aWZpZXIuIA1jbGllbnRfc2VjcmV0DVJFUVVJUkVELiBUaGUgY2xpZW50IHBh c3N3b3JkLiANRm9yIGV4YW1wbGUgKGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3Nl cyBvbmx5KTogDQ0NICBQT1NUIC90b2tlbiBIVFRQLzEuMQ0gIEhvc3Q6IHNlcnZlci5leGFtcGxl LmNvbQ0gIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkDQ0g IGdyYW50X3R5cGU9YXV0aG9yaXphdGlvbl9jb2RlJmNsaWVudF9pZD1zNkJoZFJrcXQzJg0gIGNs aWVudF9zZWNyZXQ9Z1gxZkJhdDNiViZjb2RlPWkxV3NSbjF1QjEmDSAgcmVkaXJlY3RfdXJpPWh0 dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiDQ1UaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgTVVTVCBhY2NlcHQgdGhlIGNsaWVudCBjcmVkZW50aWFscyB1c2luZyBib3RoIHRo ZSByZXF1ZXN0IHBhcmFtZXRlciwgYW5kIHRoZSBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIHNj aGVtZS4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1BWSBzdXBwb3J0IGFkZGl0aW9uYWwgYXV0 aGVudGljYXRpb24gc2NoZW1lcyBzdWl0YWJsZSBmb3IgdGhlIHRyYW5zbWlzc2lvbiBvZiBwYXNz d29yZCBjcmVkZW50aWFscy4gDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzMuMi6g IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMNVGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVu dGlhbHMgYXJlIHVzZWQgaW4gY2FzZXMgd2hlcmUgYSBwYXNzd29yZCAoY2xlYXItdGV4dCBzaGFy ZWQgc3ltbWV0cmljIHNlY3JldCkgaXMgdW5zdWl0YWJsZSBvciBkb2VzIG5vdCBwcm92aWRlIHN1 ZmZpY2llbnQgc2VjdXJpdHkgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gSW4gc3VjaCBjYXNl cyBpdCBpcyBjb21tb24gdG8gdXNlIG90aGVyIG1lY2hhbmlzbXMgc3VjaCBhcyBITUFDIG9yIGRp Z2l0YWwgc2lnbmF0dXJlcyB0aGF0IGRvIG5vdCByZXF1aXJlIHNlbmRpbmcgY2xlYXItdGV4dCBz ZWNyZXRzLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBwcm92aWRlIGFuIGV4dGVu c2libGUgbWVjaGFuaXNtIHRvIHVzZSBhbiBhc3NlcnRpb24gZm9ybWF0IHN1cHBvcnRlZCBieSB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0aW9uIHRoZSBjbGllbnQuIA1V c2luZyBhc3NlcnRpb25zIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFzc2VydGlv biAoc3VjaCBhcyBhICBbT0FTSVMuc2FtbB5jb3JlHjIuMB5vc10gYXNzZXJ0aW9uKSBmcm9tIGFu IGFzc2VydGlvbiBpc3N1ZXIgb3IgdG8gc2VsZi1pc3N1ZSBhbiBhc3NlcnRpb24uIFRoZSBhc3Nl cnRpb24gZm9ybWF0LCB0aGUgcHJvY2VzcyBieSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlzIG9idGFp bmVkLCBhbmQgdGhlIG1ldGhvZCBvZiB2YWxpZGF0aW5nIHRoZSBhc3NlcnRpb24gYXJlIGRlZmlu ZWQgYnkgdGhlIGFzc2VydGlvbiBpc3N1ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwg YW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gDVdoZW4gdXNp bmcgYSBjbGllbnQgYXNzZXJ0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcg cGFyYW1ldGVyczogDWNsaWVudF9hc3NlcnRpb25fdHlwZQ1SRVFVSVJFRC4gVGhlIGZvcm1hdCBv ZiB0aGUgYXNzZXJ0aW9uIGFzIGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBU aGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0ZSBVUkkuIA1jbGllbnRfYXNzZXJ0aW9uDVJFUVVJ UkVELiBUaGUgY2xpZW50IGFzc2VydGlvbi4gDUZvciBleGFtcGxlLCB0aGUgY2xpZW50IHNlbmRz IHRoZSBmb2xsb3dpbmcgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXNpbmcgYSBTQU1MIDIuMCBhc3Nl cnRpb24gdG8gYXV0aGVudGljYXRlIGl0c2VsZiAobGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5 IHB1cnBvc2VzIG9ubHkpOiANDQ0gIFBPU1QgL3Rva2VuIEhUVFAvMS4xDSAgSG9zdDogc2VydmVy LmV4YW1wbGUuY29tDSAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVu Y29kZWQNDSAgZ3JhbnRfdHlwZT1hdXRob3JpemF0aW9uX2NvZGUmY29kZT1pMVdzUm4xdUIxJg0g IGNsaWVudF9hc3NlcnRpb249UEhOaGJXeHdPbFsuLi5vbWl0dGVkIGZvciBicmV2aXR5Li4uXVpU NCUzRCYNICBjbGllbnRfYXNzZXJ0aW9uX3R5cGU9DSAgdXJuJTNBb2FzaXMlM0FuYW1lcyVzQXRj JTNBU0FNTCUzQTIuMCUzQWFzc2VydGlvbiYNICByZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZj bGllbnQlMkVleGFtcGxlJTJFY29tJTJGY2INDVdoZW4gb2J0YWluaW5nIGFuIGFjY2VzcyB0b2tl biB1c2luZyBhIGNsaWVudCBhc3NlcnRpb24gdG9nZXRoZXIgd2l0aCBhbiBhdXRob3JpemF0aW9u IGNvZGUgKGFzIGRlc2NyaWJlZCBpbiApLCBhIG1lY2hhbmlzbSBpcyBuZWVkZWQgdG8gbWFwIGJl dHdlZW4gdGhlIHZhbHVlIG9mIGNsaWVudF9pZCBwYXJhbWV0ZXIgdXNlZCB0byBvYnRhaW4gdGhl IGF1dGhvcml6YXRpb24gY29kZSwgYW5kIHRoZSBjbGllbnQgYXNzZXJ0aW9uLiBTdWNoIG1lY2hh bmlzbSBpcyBiZXlvbmQgdGhlIG91dCBvZiBzY29wZSBmb3IgdGhpcyBzcGVjaWZpY2F0aW9uLCBi dXQgTVVTVCBiZSBzcGVjaWZpZWQgZm9yIGFueSBjbGllbnQgYXNzZXJ0aW9uIHR5cGUgdXNlZCBp biBjb21iaW5hdGlvbiB3aXRoIGFuIGF1dGhvcml6YXRpb24gY29kZS4gDVRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciBNVVNUIHJlamVjdCBhY2Nlc3MgdG9rZW4gcmVxdWVzdHMgdXNpbmcgY2xpZW50 IGFzc2VydGlvbiBjcmVkZW50aWFscyB0aGF0IGRvIG5vdCBjb250YWluIEhNQUMgb3Igc2lnbmVk IHZhbHVlcyB0aGF0OiANU3RhdGUgdGhlIGFzc2VydGlvbiB3YXMgc3BlY2lmaWNhbGx5IGlzc3Vl ZCB0byBiZSBjb25zdW1lZCBieSB0aGUgcmVjZWl2aW5nIGVuZHBvaW50ICh0eXBpY2FsbHkgdmlh IGFuIGF1ZGllbmNlIG9yIHJlY2lwaWVudCB2YWx1ZSBjb250YWluaW5nIHRoZSByZWNlaXZpbmcg ZW5kcG9pbnSScyBpZGVudGlmaWVyKS4gDUlkZW50aWZ5IHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQg dGhlIGFzc2VydGlvbiAodHlwaWNhbGx5IHZpYSBhbiBpc3N1ZXIgdmFsdWUpLiANSWRlbnRpZnkg d2hlbiB0aGUgYXNzZXJ0aW9uIGV4cGlyZXMgYXMgYW4gYWJzb2x1dGUgdGltZSAodHlwaWNhbGx5 IHZpYSBhbiBleHBpcmF0aW9uIHZhbHVlIGNvbnRhaW5pbmcgYSBVVEMgZGF0ZS90aW1lIHZhbHVl KS4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgcmVqZWN0IGV4cGlyZWQgYXNzZXJ0aW9u cy4gDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzQuoCBPYnRhaW5pbmcgRW5kLVVz ZXIgQXV0aG9yaXphdGlvbg1CZWZvcmUgdGhlIGNsaWVudCBjYW4gYWNjZXNzIGEgcHJvdGVjdCBy ZXNvdXJjZSwgaXQgTVVTVCBmaXJzdCBvYnRhaW4gYXV0aG9yaXphdGlvbiBmcm9tIHRoZSBlbmQt dXNlci4gVG8gb2J0YWluIGFuIGVuZC11c2VyIGF1dGhvcml6YXRpb24sIHRoZSBjbGllbnQgc2Vu ZHMgdGhlIGVuZC11c2VyIHRvIHRoZSBlbmQtdXNlciBhdXRob3JpemF0aW9uIGVuZHBvaW50LiBP bmNlIG9idGFpbmVkLCB0aGUgZW5kLXVzZXIgYWNjZXNzIGdyYW50IGlzIGV4cHJlc3NlZCBhcyBh biBhdXRob3JpemF0aW9uIGNvZGUgd2hpY2ggdGhlIGNsaWVudCB1c2VzIHRvIG9idGFpbiBhbiBh Y2Nlc3MgdG9rZW4uIA1BdCB0aGUgZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgdGhl IGVuZC11c2VyIGZpcnN0IGF1dGhlbnRpY2F0ZXMgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIsIGFuZCB0aGVuIGdyYW50cyBvciBkZW5pZXMgdGhlIGFjY2VzcyByZXF1ZXN0LiBUaGUgd2F5 IGluIHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhdXRoZW50aWNhdGVzIHRoZSBlbmQt dXNlciAoZS5nLiB1c2VybmFtZSBhbmQgcGFzc3dvcmQgbG9naW4sIE9wZW5JRCwgc2Vzc2lvbiBj b29raWVzKSBhbmQgaW4gd2hpY2ggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG9idGFpbnMgdGhl IGVuZC11c2VyJ3MgYXV0aG9yaXphdGlvbiwgaW5jbHVkaW5nIHdoZXRoZXIgaXQgdXNlcyBhIHNl Y3VyZSBjaGFubmVsIHN1Y2ggYXMgVExTLCBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4gSG93ZXZlciwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIE1VU1QgZmlyc3Qg dmVyaWZ5IHRoZSBpZGVudGl0eSBvZiB0aGUgZW5kLXVzZXIuIA1UaGUgbG9jYXRpb24gb2YgdGhl IGVuZC11c2VyIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgY2FuIGJlIGZvdW5kIGluIHRoZSBzZXJ2 aWNlIGRvY3VtZW50YXRpb24uIFRoZSBlbmQtdXNlciBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVS SSBNQVkgaW5jbHVkZSBhIHF1ZXJ5IGNvbXBvbmVudCBhcyBkZWZpbmVkIGJ5ICBzZWN0aW9uIDMs IHdoaWNoIG11c3QgYmUgcmV0YWluZWQgd2hlbiBhZGRpbmcgYWRkaXRpb25hbCBxdWVyeSBwYXJh bWV0ZXJzLiANU2luY2UgcmVxdWVzdHMgdG8gdGhlIGVuZC11c2VyIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgcmVzdWx0IGluIHVzZXIgYXV0aGVudGljYXRpb24gYW5kIHRoZSB0cmFuc21pc3Npb24g b2Ygc2Vuc2l0aXZlIGluZm9ybWF0aW9uLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxE IHJlcXVpcmUgdGhlIHVzZSBvZiBhIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBtZWNoYW5pc20g c3VjaCBhcyBUTFMgd2hlbiBzZW5kaW5nIHJlcXVlc3RzIHRvIHRoZSBlbmQtdXNlciBhdXRob3Jp emF0aW9uIGVuZHBvaW50LiANDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHNC4xLqAg QXV0aG9yaXphdGlvbiBSZXF1ZXN0DUluIG9yZGVyIHRvIGRpcmVjdCB0aGUgZW5kLXVzZXIncyB1 c2VyLWFnZW50IHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgdGhlIGNsaWVudCBjb25zdHJ1 Y3RzIHRoZSByZXF1ZXN0IFVSSSBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHRv IHRoZSBlbmQtdXNlciBhdXRob3JpemF0aW9uIGVuZHBvaW50IFVSSSBxdWVyeSBjb21wb25lbnQg dXNpbmcgdGhlIGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCBmb3JtYXQgYXMgZGVm aW5lZCBieSA6IA1yZXNwb25zZV90eXBlDVJFUVVJUkVELiBUaGUgcmVxdWVzdGVkIHJlc3BvbnNl OiBhbiBhY2Nlc3MgdG9rZW4sIGFuIGF1dGhvcml6YXRpb24gY29kZSwgb3IgYm90aC4gVGhlIHBh cmFtZXRlciB2YWx1ZSBNVVNUIGJlIHNldCB0byB0b2tlbiBmb3IgcmVxdWVzdGluZyBhbiBhY2Nl c3MgdG9rZW4sIGNvZGUgZm9yIHJlcXVlc3RpbmcgYW4gYXV0aG9yaXphdGlvbiBjb2RlLCBvciBj b2RlX2FuZF90b2tlbiB0byByZXF1ZXN0IGJvdGguIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBN QVkgZGVjbGluZSB0byBwcm92aWRlIG9uZSBvciBtb3JlIG9mIHRoZXNlIHJlc3BvbnNlIHR5cGVz LiANY2xpZW50X2lkDVJFUVVJUkVELiBUaGUgY2xpZW50IGlkZW50aWZpZXIgYXMgZGVzY3JpYmVk IGluIC4gDXJlZGlyZWN0X3VyaQ1SRVFVSVJFRCwgdW5sZXNzIGEgcmVkaXJlY3Rpb24gVVJJIGhh cyBiZWVuIGVzdGFibGlzaGVkIGJldHdlZW4gdGhlIGNsaWVudCBhbmQgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgdmlhIG90aGVyIG1lYW5zLiBBbiBhYnNvbHV0ZSBVUkkgdG8gd2hpY2ggdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIHdpbGwgcmVkaXJlY3QgdGhlIHVzZXItYWdlbnQgdG8gd2hlbiB0aGUg ZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBzdGVwIGlzIGNvbXBsZXRlZC4gVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIFNIT1VMRCByZXF1aXJlIHRoZSBjbGllbnQgdG8gcHJlLXJlZ2lzdGVyIHRoZWly IHJlZGlyZWN0aW9uIFVSSS4gDXNjb3BlDU9QVElPTkFMLiBUaGUgc2NvcGUgb2YgdGhlIGFjY2Vz cyByZXF1ZXN0IGV4cHJlc3NlZCBhcyBhIGxpc3Qgb2Ygc3BhY2UtZGVsaW1pdGVkIHN0cmluZ3Mu IFRoZSB2YWx1ZSBvZiB0aGUgc2NvcGUgcGFyYW1ldGVyIGlzIGRlZmluZWQgYnkgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyLiBJZiB0aGUgdmFsdWUgY29udGFpbnMgbXVsdGlwbGUgc3BhY2UtZGVs aW1pdGVkIHN0cmluZ3MsIHRoZWlyIG9yZGVyIGRvZXMgbm90IG1hdHRlciwgYW5kIGVhY2ggc3Ry aW5nIGFkZHMgYW4gYWRkaXRpb25hbCBhY2Nlc3MgcmFuZ2UgdG8gdGhlIHJlcXVlc3RlZCBzY29w ZS4gDXN0YXRlDU9QVElPTkFMLiBBbiBvcGFxdWUgdmFsdWUgdXNlZCBieSB0aGUgY2xpZW50IHRv IG1haW50YWluIHN0YXRlIGJldHdlZW4gdGhlIHJlcXVlc3QgYW5kIGNhbGxiYWNrLiBUaGUgYXV0 aG9yaXphdGlvbiBzZXJ2ZXIgaW5jbHVkZXMgdGhpcyB2YWx1ZSB3aGVuIHJlZGlyZWN0aW5nIHRo ZSB1c2VyLWFnZW50IGJhY2sgdG8gdGhlIGNsaWVudC4gDVRoZSBjbGllbnQgZGlyZWN0cyB0aGUg ZW5kLXVzZXIgdG8gdGhlIGNvbnN0cnVjdGVkIFVSSSB1c2luZyBhbiBIVFRQIHJlZGlyZWN0aW9u IHJlc3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRoZSBlbmQt dXNlcidzIHVzZXItYWdlbnQuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHN1cHBvcnQg dGhlIHVzZSBvZiB0aGUgSFRUUCBHRVQgbWV0aG9kIGZvciB0aGUgZW5kLXVzZXIgYXV0aG9yaXph dGlvbiBlbmRwb2ludCwgYW5kIE1BWSBzdXBwb3J0IHRoZSB1c2Ugb2YgdGhlIFBPU1QgbWV0aG9k IGFzIHdlbGwuIA1Gb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBkaXJlY3RzIHRoZSBlbmQtdXNlcidz IHVzZXItYWdlbnQgdG8gbWFrZSB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2luZyB0cmFu c3BvcnQtbGF5ZXIgc2VjdXJpdHkgKGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3Nl cyBvbmx5KTogDQ0NICBHRVQgL2F1dGhvcml6ZT9yZXNwb25zZV90eXBlPWNvZGUmY2xpZW50X2lk PXM2QmhkUmtxdDMmDSAgICAgIHJlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4 YW1wbGUlMkVjb20lMkZjYiBIVFRQLzEuMQ0gIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQ0NSWYg dGhlIGNsaWVudCBoYXMgcHJldmlvdXNseSByZWdpc3RlcmVkIGEgcmVkaXJlY3Rpb24gVVJJIHdp dGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVT VCB2ZXJpZnkgdGhhdCB0aGUgcmVkaXJlY3Rpb24gVVJJIHJlY2VpdmVkIG1hdGNoZXMgdGhlIHJl Z2lzdGVyZWQgVVJJIGFzc29jaWF0ZWQgd2l0aCB0aGUgY2xpZW50IGlkZW50aWZpZXIuIFRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgTk9UIHJlZGlyZWN0IHRoZSB1c2VyLWFnZW50IHRv IHVucmVnaXN0ZXJlZCBvciB1bnRydXN0ZWQgVVJJcyB0byBwcmV2ZW50IHRoZSBlbmRwb2ludCBm cm9tIGJlaW5nIHVzZWQgYXMgYW4gb3BlbiByZWRpcmVjdG9yLiBJZiBubyB2YWxpZCByZWRpcmVj dGlvbiBVUkkgaXMgYXZhaWxhYmxlLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGlu Zm9ybSB0aGUgZW5kLXVzZXIgb2YgdGhlIGVycm9yIG9jY3VyZWQuIFtbIHByb3ZpZGUgZ3VpZGFu Y2Ugb24gaG93IHRvIHBlcmZvcm0gbWF0Y2hpbmcgXV0gDVBhcmFtZXRlcnMgc2VudCB3aXRob3V0 IGEgdmFsdWUgTVVTVCBiZSB0cmVhdGVkIGFzIGlmIHRoZXkgd2VyZSBvbWl0dGVkIGZyb20gdGhl IHJlcXVlc3QuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaWdub3JlIHVucmVjb2du aXplZCByZXF1ZXN0IHBhcmFtZXRlcnMuIA1UaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgdmFsaWRh dGVzIHRoZSByZXF1ZXN0IHRvIGVuc3VyZSBhbGwgcmVxdWlyZWQgcGFyYW1ldGVycyBhcmUgcHJl c2VudCBhbmQgdmFsaWQuIElmIHRoZSByZXF1ZXN0IGlzIGludmFsaWQsIHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlciByZWRpcmVjdHMgdGhlIHVzZXItYWdlbnQgYmFjayB0byB0aGUgY2xpZW50IHVz aW5nIHRoZSByZWRpcmVjdGlvbiBVUkkgcHJvdmlkZWQgd2l0aCB0aGUgYXBwcm9wcmlhdGUgZXJy b3IgY29kZSBhcyBkZXNjcmliZWQgaW4gLiANVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGF1dGhl bnRpY2F0ZXMgdGhlIGVuZC11c2VyIGFuZCBvYnRhaW5zIGFuIGF1dGhvcml6YXRpb24gZGVjaXNp b24gKGJ5IGFza2luZyB0aGUgZW5kLXVzZXIgb3IgYnkgZXN0YWJsaXNoaW5nIGFwcHJvdmFsIHZp YSBvdGhlciBtZWFucykuIFdoZW4gYSBkZWNpc2lvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGRpcmVjdHMgdGhlIGVuZC11c2VyJ3MgdXNlci1hZ2VudCB0 byB0aGUgcHJvdmlkZWQgY2xpZW50IHJlZGlyZWN0aW9uIFVSSSB1c2luZyBhbiBIVFRQIHJlZGly ZWN0aW9uIHJlc3BvbnNlLCBvciBieSBvdGhlciBtZWFucyBhdmFpbGFibGUgdG8gaXQgdmlhIHRo ZSBlbmQtdXNlcidzIHVzZXItYWdlbnQuIA0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAUoFRPQ6AV Bwc0LjIuoCBBdXRob3JpemF0aW9uIFJlc3BvbnNlDUlmIHRoZSBlbmQtdXNlciBncmFudHMgdGhl IGFjY2VzcyByZXF1ZXN0LCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNzdWVzIGFuIGFjY2Vz cyB0b2tlbiwgYW4gYXV0aG9yaXphdGlvbiBjb2RlLCBvciBib3RoLCBhbmQgZGVsaXZlcnMgdGhl bSB0byB0aGUgY2xpZW50IGJ5IGFkZGluZyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnMgdG8gdGhl IHJlZGlyZWN0aW9uIFVSSSAoYXMgZGVzY3JpYmVkIGJlbG93KTogDWNvZGUNUkVRVUlSRUQgaWYg dGhlIHJlc3BvbnNlIHR5cGUgaXMgY29kZSBvciBjb2RlX2FuZF90b2tlbiwgb3RoZXJ3aXNlIE1V U1QgTk9UIGJlIGluY2x1ZGVkLiBUaGUgYXV0aG9yaXphdGlvbiBjb2RlIGdlbmVyYXRlZCBieSB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZSBhdXRob3JpemF0aW9uIGNvZGUgU0hPVUxEIGV4 cGlyZSBzaG9ydGx5IGFmdGVyIGl0IGlzIGlzc3VlZCB0byBtaW5pbWl6ZSB0aGUgcmlzayBvZiBs ZWFrcy4gVGhlIGNsaWVudCBNVVNUIE5PVCByZXVzZSB0aGUgYXV0aG9yaXphdGlvbiBjb2RlLiBJ ZiBhbiBhdXRob3JpemF0aW9uIGNvZGUgaXMgdXNlZCBtb3JlIHRoYW4gb25jZSwgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIE1BWSByZXZva2UgYWxsIHRva2VucyBwcmV2aW91c2x5IGlzc3VlZCBi YXNlZCBvbiB0aGF0IGF1dGhvcml6YXRpb24gY29kZS4gVGhlIGF1dGhvcml6YXRpb24gY29kZSBp cyBib3VuZCB0byB0aGUgY2xpZW50IGlkZW50aWZpZXIgYW5kIHJlZGlyZWN0aW9uIFVSSS4gDWFj Y2Vzc190b2tlbg1SRVFVSVJFRCBpZiB0aGUgcmVzcG9uc2UgdHlwZSBpcyB0b2tlbiBvciBjb2Rl X2FuZF90b2tlbiwgb3RoZXJ3aXNlIE1VU1QgTk9UIGJlIGluY2x1ZGVkLiBUaGUgYWNjZXNzIHRv a2VuIGlzc3VlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIA10b2tlbl90eXBlDVJFUVVJ UkVEIGlmIHRoZSByZXNwb25zZSBpbmNsdWRlcyBhbiBhY2Nlc3MgdG9rZW4uIFRoZSB0eXBlIG9m IHRoZSB0b2tlbiBpc3N1ZWQuIFRoZSB0b2tlbiB0eXBlIGluZm9ybXMgdGhlIGNsaWVudCBob3cg dGhlIGFjY2VzcyB0b2tlbiBpcyB0byBiZSB1c2VkIHdoZW4gYWNjZXNzaW5nIGEgcHJvdGVjdGVk IHJlc291cmNlIGFzIGRlc2NyaWJlZCBpbiAuIA1leHBpcmVzX2luDU9QVElPTkFMLiBUaGUgZHVy YXRpb24gaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNzIHRva2VuIGxpZmV0aW1lIGlmIGFuIGFjY2Vz cyB0b2tlbiBpcyBpbmNsdWRlZC4gRm9yIGV4YW1wbGUsIHRoZSB2YWx1ZSAzNjAwIGRlbm90ZXMg dGhhdCB0aGUgYWNjZXNzIHRva2VuIHdpbGwgZXhwaXJlIGluIG9uZSBob3VyIGZyb20gdGhlIHRp bWUgdGhlIHJlc3BvbnNlIHdhcyBnZW5lcmF0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy LiANc2NvcGUNT1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHRva2VuIGFzIGEgbGlz dCBvZiBzcGFjZS1kZWxpbWl0ZWQgc3RyaW5ncyBpZiBhbiBhY2Nlc3MgdG9rZW4gaXMgaW5jbHVk ZWQuIFRoZSB2YWx1ZSBvZiB0aGUgc2NvcGUgcGFyYW1ldGVyIGlzIGRlZmluZWQgYnkgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyLiBJZiB0aGUgdmFsdWUgY29udGFpbnMgbXVsdGlwbGUgc3BhY2Ut ZGVsaW1pdGVkIHN0cmluZ3MsIHRoZWlyIG9yZGVyIGRvZXMgbm90IG1hdHRlciwgYW5kIGVhY2gg c3RyaW5nIGFkZHMgYW4gYWRkaXRpb25hbCBhY2Nlc3MgcmFuZ2UgdG8gdGhlIHJlcXVlc3RlZCBz Y29wZS4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBpbmNsdWRlIHRoZSBwYXJhbWV0 ZXIgaWYgdGhlIHJlcXVlc3RlZCBzY29wZSBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgb25lIHJlcXVl c3RlZCBieSB0aGUgY2xpZW50LiANc3RhdGUNUkVRVUlSRUQgaWYgdGhlIHN0YXRlIHBhcmFtZXRl ciB3YXMgcHJlc2VudCBpbiB0aGUgY2xpZW50IGF1dGhvcml6YXRpb24gcmVxdWVzdC4gU2V0IHRv IHRoZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuIA1UaGUgbWV0aG9kIGlu IHdoaWNoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBhZGRzIHRoZSBwYXJhbWV0ZXIgdG8gdGhl IHJlZGlyZWN0aW9uIFVSSSBpcyBkZXRlcm1pbmVkIGJ5IHRoZSByZXNwb25zZSB0eXBlIHJlcXVl c3RlZCBieSB0aGUgY2xpZW50IGluIHRoZSBhdXRob3JpemF0aW9uIHJlcXVlc3QgdXNpbmcgdGhl IHJlc3BvbnNlX3R5cGUgcGFyYW1ldGVyLiANSWYgdGhlIHJlc3BvbnNlIHR5cGUgaXMgY29kZSwg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGFkZHMgdGhlIHBhcmFtZXRlcnMgdG8gdGhlIHJlZGly ZWN0aW9uIFVSSSBxdWVyeSBjb21wb25lbnQgdXNpbmcgdGhlIGFwcGxpY2F0aW9uL3gtd3d3LWZv cm0tdXJsZW5jb2RlZCBmb3JtYXQgYXMgZGVmaW5lZCBieSAuIA1Gb3IgZXhhbXBsZSwgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUgZW5kLXVzZXIncyB1c2VyLWFnZW50IGJ5 IHNlbmRpbmcgdGhlIGZvbGxvd2luZyBIVFRQIHJlc3BvbnNlOiANDQ0gIEhUVFAvMS4xIDMwMiBG b3VuZA0gIExvY2F0aW9uOiBodHRwczovL2NsaWVudC5leGFtcGxlLmNvbS9jYj9jb2RlPWkxV3NS bjF1QjENDUlmIHRoZSByZXNwb25zZSB0eXBlIGlzIHRva2VuIG9yIGNvZGVfYW5kX3Rva2VuLCB0 aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYWRkcyB0aGUgcGFyYW1ldGVycyB0byB0aGUgcmVkaXJl Y3Rpb24gVVJJIGZyYWdtZW50IGNvbXBvbmVudCB1c2luZyB0aGUgYXBwbGljYXRpb24veC13d3ct Zm9ybS11cmxlbmNvZGVkIGZvcm1hdCBhcyBkZWZpbmVkIGJ5IC4gDUZvciBleGFtcGxlLCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgcmVkaXJlY3RzIHRoZSBlbmQtdXNlcidzIHVzZXItYWdlbnQg Ynkgc2VuZGluZyB0aGUgZm9sbG93aW5nIEhUVFAgcmVzcG9uc2UgKFVSSSBsaW5lIGJyZWFrcyBh cmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6IA0NDSAgSFRUUC8xLjEgMzAyIEZvdW5kDSAg TG9jYXRpb246IGh0dHA6Ly9leGFtcGxlLmNvbS9yZCNhY2Nlc3NfdG9rZW49RkpRYndxOSYNICAg ICAgICAgICAgdG9rZW5fdHlwZT1leGFtcGxlJmV4cGlyZXNfaW49MzYwMA0NQ2xpZW50cyBTSE9V TEQgaWdub3JlIHVucmVjb2duaXplZCByZXNwb25zZSBwYXJhbWV0ZXJzLiBUaGUgc2l6ZXMgb2Yg dG9rZW5zIGFuZCBvdGhlciB2YWx1ZXMgcmVjZWl2ZWQgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIsIGFyZSBsZWZ0IHVuZGVmaW5lZCBieSB0aGlzIHNwZWNpZmljYXRpb24uIENsaWVudHMg c2hvdWxkIGF2b2lkIG1ha2luZyBhc3N1bXB0aW9ucyBhYm91dCB2YWx1ZSBzaXplcy4gU2VydmVy cyBzaG91bGQgZG9jdW1lbnQgdGhlIGV4cGVjdGVkIHNpemUgb2YgYW55IHZhbHVlIHRoZXkgaXNz dWUuIA0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAUoFRPQ6AVBwc0LjMuoCBFcnJvciBSZXNwb25z ZQ1JZiB0aGUgZW5kLXVzZXIgZGVuaWVzIHRoZSBhY2Nlc3MgcmVxdWVzdCBvciBpZiB0aGUgcmVx dWVzdCBmYWlscyBmb3IgcmVhc29ucyBvdGhlciB0aGFuIGEgbWlzc2luZyBvciBpbnZhbGlkIHJl ZGlyZWN0aW9uIFVSSSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGluZm9ybXMgdGhlIGNsaWVu dCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIHRvIHRoZSByZWRpcmVjdGlvbiBV UkkgcXVlcnkgY29tcG9uZW50IHVzaW5nIHRoZSBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVu Y29kZWQgZm9ybWF0IGFzIGRlZmluZWQgYnkgOiANZXJyb3INUkVRVUlSRUQuIEEgc2luZ2xlIGVy cm9yIGNvZGUgYXMgZGVzY3JpYmVkIGluIC4gDWVycm9yX2Rlc2NyaXB0aW9uDU9QVElPTkFMLiBB IGh1bWFuLXJlYWRhYmxlIHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHVz ZWQgdG8gYXNzaXN0IGluIHRoZSB1bmRlcnN0YW5kaW5nIGFuZCByZXNvbHV0aW9uIG9mIHRoZSBl cnJvciBvY2N1cnJlZC4gDWVycm9yX3VyaQ1PUFRJT05BTC4gQSBVUkkgaWRlbnRpZnlpbmcgYSBo dW1hbi1yZWFkYWJsZSB3ZWIgcGFnZSB3aXRoIGluZm9ybWF0aW9uIGFib3V0IHRoZSBlcnJvciwg dXNlZCB0byBwcm92aWRlIHRoZSBlbmQtdXNlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g YWJvdXQgdGhlIGVycm9yLiANc3RhdGUNUkVRVUlSRUQgaWYgdGhlIHN0YXRlIHBhcmFtZXRlciB3 YXMgcHJlc2VudCBpbiB0aGUgY2xpZW50IGF1dGhvcml6YXRpb24gcmVxdWVzdC4gU2V0IHRvIHRo ZSBleGFjdCB2YWx1ZSByZWNlaXZlZCBmcm9tIHRoZSBjbGllbnQuIA1Gb3IgZXhhbXBsZSwgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIHJlZGlyZWN0cyB0aGUgZW5kLXVzZXIncyB1c2VyLWFnZW50 IGJ5IHNlbmRpbmcgdGhlIGZvbGxvd2luZyBIVFRQIHJlc3BvbnNlOiANDQ0gIEhUVFAvMS4xIDMw MiBGb3VuZA0gIExvY2F0aW9uOiBodHRwczovL2NsaWVudC5leGFtcGxlLmNvbS9jYj9lcnJvcj1h Y2Nlc3NfZGVuaWVkDQ1JZiB0aGUgcmVxdWVzdCBmYWlscyBkdWUgdG8gYSBtaXNzaW5nIG9yIGlu dmFsaWQgcmVkaXJlY3Rpb24gVVJJLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIGlu Zm9ybSB0aGUgZW5kLXVzZXIgb2YgdGhlIGVycm9yLCBhbmQgTVVTVCBOT1QgcmVkaXJlY3QgdGhl IGVuZC11c2VyJ3MgdXNlci1hZ2VudCB0byB0aGUgaW52YWxpZCByZWRpcmVjdGlvbiBVUkkuIA0N AQ0TIEhZUEVSTElOSyBcbCAidG9jIiAUoFRPQ6AVBwc0LjMuMS6gIEVycm9yIENvZGVzDVRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBpbmNsdWRlcyBvbmUgb2YgdGhlIGZvbGxvd2luZyBlcnJvciBj b2RlcyB3aXRoIHRoZSBlcnJvciByZXNwb25zZTogDWludmFsaWRfcmVxdWVzdA1UaGUgcmVxdWVz dCBpcyBtaXNzaW5nIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBpbmNsdWRlcyBhbiB1bnN1cHBvcnRl ZCBwYXJhbWV0ZXIgb3IgcGFyYW1ldGVyIHZhbHVlLCBvciBpcyBvdGhlcndpc2UgbWFsZm9ybWVk LiANaW52YWxpZF9jbGllbnQNVGhlIGNsaWVudCBpZGVudGlmaWVyIHByb3ZpZGVkIGlzIGludmFs aWQuIA11bmF1dGhvcml6ZWRfY2xpZW50DVRoZSBjbGllbnQgaXMgbm90IGF1dGhvcml6ZWQgdG8g dXNlIHRoZSByZXF1ZXN0ZWQgcmVzcG9uc2UgdHlwZS4gDXJlZGlyZWN0X3VyaV9taXNtYXRjaA1U aGUgcmVkaXJlY3Rpb24gVVJJIHByb3ZpZGVkIGRvZXMgbm90IG1hdGNoIGEgcHJlLXJlZ2lzdGVy ZWQgdmFsdWUuIA1hY2Nlc3NfZGVuaWVkDVRoZSBlbmQtdXNlciBvciBhdXRob3JpemF0aW9uIHNl cnZlciBkZW5pZWQgdGhlIHJlcXVlc3QuIA11bnN1cHBvcnRlZF9yZXNwb25zZV90eXBlDVRoZSBy ZXF1ZXN0ZWQgcmVzcG9uc2UgdHlwZSBpcyBub3Qgc3VwcG9ydGVkIGJ5IHRoZSBhdXRob3JpemF0 aW9uIHNlcnZlci4gDWludmFsaWRfc2NvcGUNVGhlIHJlcXVlc3RlZCBzY29wZSBpcyBpbnZhbGlk LCB1bmtub3duLCBvciBtYWxmb3JtZWQuIA1bWyBBZGQgbWVjaGFuaXNtIGZvciBleHRlbmRpbmcg ZXJyb3IgY29kZXMgXV0gDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzUuoCBPYnRh aW5pbmcgYW4gQWNjZXNzIFRva2VuDVRoZSBjbGllbnQgb2J0YWlucyBhbiBhY2Nlc3MgdG9rZW4g YnkgYXV0aGVudGljYXRpbmcgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgYW5kIHByZXNl bnRpbmcgaXRzIGFjY2VzcyBncmFudCAoaW4gdGhlIGZvcm0gb2YgYW4gYXV0aG9yaXphdGlvbiBj b2RlLCByZXNvdXJjZSBvd25lciBjcmVkZW50aWFscywgYW4gYXNzZXJ0aW9uLCBvciBhIHJlZnJl c2ggdG9rZW4pLiANU2luY2UgcmVxdWVzdHMgdG8gdGhlIHRva2VuIGVuZHBvaW50IHJlc3VsdCBp biB0aGUgdHJhbnNtaXNzaW9uIG9mIGNsZWFyLXRleHQgY3JlZGVudGlhbHMgaW4gdGhlIEhUVFAg cmVxdWVzdCBhbmQgcmVzcG9uc2UsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUIHJlcXVp cmUgdGhlIHVzZSBvZiBhIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSBtZWNoYW5pc20gd2hlbiBz ZW5kaW5nIHJlcXVlc3RzIHRvIHRoZSB0b2tlbiBlbmRwb2ludHMuIFNlcnZlcnMgTVVTVCBzdXBw b3J0IFRMUyAxLjIgYXMgZGVmaW5lZCBpbiAsIGFuZCBNQVkgc3VwcG9ydCBhZGRpdGlvbmFsIHRy YW5zcG9ydC1sYXllciBzZWN1cml0eSBtZWNoYW5pc21zLiANVGhlIGNsaWVudCByZXF1ZXN0cyBh biBhY2Nlc3MgdG9rZW4gYnkgbWFraW5nIGFuIEhUVFAgUE9TVCByZXF1ZXN0IHRvIHRoZSB0b2tl biBlbmRwb2ludC4gVGhlIGxvY2F0aW9uIG9mIHRoZSB0b2tlbiBlbmRwb2ludCBjYW4gYmUgZm91 bmQgaW4gdGhlIHNlcnZpY2UgZG9jdW1lbnRhdGlvbi4gVGhlIHRva2VuIGVuZHBvaW50IFVSSSBN QVkgaW5jbHVkZSBhIHF1ZXJ5IGNvbXBvbmVudC4gDVRoZSBjbGllbnQgYXV0aGVudGljYXRlcyB3 aXRoIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBieSBhZGRpbmcgaXRzIGNsaWVudCBjcmVkZW50 aWFscyB0byB0aGUgcmVxdWVzdCBhcyBkZXNjcmliZWQgaW4gLiBUaGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIgTUFZIGFsbG93IHVuYXV0aGVudGljYXRlZCBhY2Nlc3MgdG9rZW4gcmVxdWVzdHMgd2hl biB0aGUgY2xpZW50IGlkZW50aXR5IGRvZXMgbm90IG1hdHRlciAoZS5nLiBhbm9ueW1vdXMgY2xp ZW50KSBvciB3aGVuIHRoZSBjbGllbnQgaWRlbnRpdHkgaXMgZXN0YWJsaXNoZWQgdmlhIG90aGVy IG1lYW5zIChlLmcuIHVzaW5nIGFuIGFzc2VydGlvbiBhY2Nlc3MgZ3JhbnQpLiANVGhlIGNsaWVu dCBjb25zdHJ1Y3RzIHRoZSByZXF1ZXN0IGJ5IGluY2x1ZGluZyB0aGUgZm9sbG93aW5nIHBhcmFt ZXRlcnMgdXNpbmcgdGhlIGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCBmb3JtYXQg aW4gdGhlIEhUVFAgcmVxdWVzdCBlbnRpdHktYm9keTogDWdyYW50X3R5cGUNUkVRVUlSRUQuIFRo ZSBhY2Nlc3MgZ3JhbnQgdHlwZSBpbmNsdWRlZCBpbiB0aGUgcmVxdWVzdC4gVmFsdWUgTVVTVCBi ZSBvbmUgb2YgYXV0aG9yaXphdGlvbl9jb2RlLCBwYXNzd29yZCwgcmVmcmVzaF90b2tlbiwgY2xp ZW50X2NyZWRlbnRpYWxzLCBvciBhbiBhYnNvbHV0ZSBVUkkgaWRlbnRpZnlpbmcgYW4gYXNzZXJ0 aW9uIGZvcm1hdCBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiANc2NvcGUN T1BUSU9OQUwuIFRoZSBzY29wZSBvZiB0aGUgYWNjZXNzIHJlcXVlc3QgZXhwcmVzc2VkIGFzIGEg bGlzdCBvZiBzcGFjZS1kZWxpbWl0ZWQgc3RyaW5ncy4gVGhlIHZhbHVlIG9mIHRoZSBzY29wZSBw YXJhbWV0ZXIgaXMgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIElmIHRoZSB2 YWx1ZSBjb250YWlucyBtdWx0aXBsZSBzcGFjZS1kZWxpbWl0ZWQgc3RyaW5ncywgdGhlaXIgb3Jk ZXIgZG9lcyBub3QgbWF0dGVyLCBhbmQgZWFjaCBzdHJpbmcgYWRkcyBhbiBhZGRpdGlvbmFsIGFj Y2VzcyByYW5nZSB0byB0aGUgcmVxdWVzdGVkIHNjb3BlLiBJZiB0aGUgYWNjZXNzIGdyYW50IGJl aW5nIHVzZWQgYWxyZWFkeSByZXByZXNlbnRzIGFuIGFwcHJvdmVkIHNjb3BlIChlLmcuIGF1dGhv cml6YXRpb24gY29kZSwgYXNzZXJ0aW9uKSwgdGhlIHJlcXVlc3RlZCBzY29wZSBNVVNUIGJlIGVx dWFsIG9yIGxlc3NlciB0aGFuIHRoZSBzY29wZSBwcmV2aW91c2x5IGdyYW50ZWQsIGFuZCBpZiBv bWl0dGVkIGlzIHRyZWF0ZWQgYXMgZXF1YWwgdG8gdGhlIHByZXZpb3VzbHkgYXBwcm92ZWQgc2Nv cGUuIA1JbiBhZGRpdGlvbiwgdGhlIGNsaWVudCBNVVNUIGluY2x1ZGUgdGhlIGFwcHJvcHJpYXRl IHBhcmFtZXRlcnMgbGlzdGVkIGZvciB0aGUgc2VsZWN0ZWQgYWNjZXNzIGdyYW50IHR5cGUgYXMg ZGVzY3JpYmVkIGluIC4gDVBhcmFtZXRlcnMgc2VudCB3aXRob3V0IGEgdmFsdWUgTVVTVCBiZSB0 cmVhdGVkIGFzIGlmIHRoZXkgd2VyZSBvbWl0dGVkIGZyb20gdGhlIHJlcXVlc3QuIFRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBTSE9VTEQgaWdub3JlIHVucmVjb2duaXplZCByZXF1ZXN0IHBhcmFt ZXRlcnMuIA0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAUoFRPQ6AVBwc1LjEuoCBBY2Nlc3MgR3Jh bnQgVHlwZXMNVGhlIGNsaWVudCByZXF1ZXN0cyBhbiBhY2Nlc3MgdG9rZW4gdXNpbmcgYW4gYXV0 aG9yaXphdGlvbiBjb2RlLCByZXNvdXJjZSBvd25lciBwYXNzd29yZCBjcmVkZW50aWFscywgY2xp ZW50IGNyZWRlbnRpYWxzLCByZWZyZXNoIHRva2VuLCBvciBhc3NlcnRpb24uIA0NAQ0TIEhZUEVS TElOSyBcbCAidG9jIiAUoFRPQ6AVBwc1LjEuMS6gIEF1dGhvcml6YXRpb24gQ29kZQ1UaGUgY2xp ZW50IGluY2x1ZGVzIHRoZSBhdXRob3JpemF0aW9uIGNvZGUgdXNpbmcgdGhlIGF1dGhvcml6YXRp b25fY29kZSBhY2Nlc3MgZ3JhbnQgdHlwZSBhbmQgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOiAN Y29kZQ1SRVFVSVJFRC4gVGhlIGF1dGhvcml6YXRpb24gY29kZSByZWNlaXZlZCBmcm9tIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlci4gDXJlZGlyZWN0X3VyaQ1SRVFVSVJFRC4gVGhlIHJlZGlyZWN0 aW9uIFVSSSB1c2VkIGluIHRoZSBpbml0aWFsIHJlcXVlc3QuIA1Gb3IgZXhhbXBsZSwgdGhlIGNs aWVudCBtYWtlcyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCBieSBpbmNsdWRpbmcgaXRzIGNs aWVudCBjcmVkZW50aWFscyB2aWEgdGhlIGNsaWVudF9zZWNyZXQgcGFyYW1ldGVyIGRlc2NyaWJl ZCBpbiAgYW5kIHVzaW5nIHRyYW5zcG9ydC1sYXllciBzZWN1cml0eSAobGluZSBicmVha3MgYXJl IGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOiANDQ0gIFBPU1QgL3Rva2VuIEhUVFAvMS4xDSAg SG9zdDogc2VydmVyLmV4YW1wbGUuY29tDSAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3 dy1mb3JtLXVybGVuY29kZWQNDSAgZ3JhbnRfdHlwZT1hdXRob3JpemF0aW9uX2NvZGUmY2xpZW50 X2lkPXM2QmhkUmtxdDMmDSAgY2xpZW50X3NlY3JldD1nWDFmQmF0M2JWJmNvZGU9aTFXc1JuMXVC MSYNICByZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZjbGllbnQlMkVleGFtcGxlJTJFY29tJTJG Y2INDVRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNVVNUOiANVmFsaWRhdGUgdGhlIGNsaWVudCBj cmVkZW50aWFscyAoaWYgcHJlc2VudCkgYW5kIGVuc3VyZSB0aGV5IG1hdGNoIHRoZSBhdXRob3Jp emF0aW9uIGNvZGUuIA1WZXJpZnkgdGhhdCB0aGUgYXV0aG9yaXphdGlvbiBjb2RlIGFuZCByZWRp cmVjdGlvbiBVUkkgYXJlIGFsbCB2YWxpZCBhbmQgbWF0Y2ggaXRzIHN0b3JlZCBhc3NvY2lhdGlv bi4gDUlmIHRoZSByZXF1ZXN0IGlzIHZhbGlkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgaXNz dWVzIGEgc3VjY2Vzc2Z1bCByZXNwb25zZSBhcyBkZXNjcmliZWQgaW4gLiANDQENEyBIWVBFUkxJ TksgXGwgInRvYyIgFKBUT0OgFQcHNS4xLjIuoCBSZXNvdXJjZSBPd25lciBQYXNzd29yZCBDcmVk ZW50aWFscw1UaGUgY2xpZW50IGluY2x1ZGVzIHRoZSByZXNvdXJjZSBvd25lciBjcmVkZW50aWFs cyB1c2luZyB0aGUgcGFzc3dvcmQgYWNjZXNzIGdyYW50IHR5cGUgYW5kIHRoZSBmb2xsb3dpbmcg cGFyYW1ldGVyczogW1sgYWRkIGludGVybmF0aW9uYWxpemF0aW9uIGNvbnNpZGVyYXRpb24gZm9y IHVzZXJuYW1lIGFuZCBwYXNzd29yZCBdXSANdXNlcm5hbWUNUkVRVUlSRUQuIFRoZSByZXNvdXJj ZSBvd25lcidzIHVzZXJuYW1lLiANcGFzc3dvcmQNUkVRVUlSRUQuIFRoZSByZXNvdXJjZSBvd25l cidzIHBhc3N3b3JkLiANRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgbWFrZXMgdGhlIGZvbGxvd2lu ZyBIVFRQIHJlcXVlc3QgYnkgaW5jbHVkaW5nIGl0cyBjbGllbnQgY3JlZGVudGlhbHMgdmlhIHRo ZSBjbGllbnRfc2VjcmV0IHBhcmFtZXRlciBkZXNjcmliZWQgaW4gIGFuZCB1c2luZyB0cmFuc3Bv cnQtbGF5ZXIgc2VjdXJpdHkgKGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBv bmx5KTogDQ0NICBQT1NUIC90b2tlbiBIVFRQLzEuMQ0gIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNv bQ0gIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkDQ0gIGdy YW50X3R5cGU9cGFzc3dvcmQmY2xpZW50X2lkPXM2QmhkUmtxdDMmDSAgY2xpZW50X3NlY3JldD00 N0hEdThzJnVzZXJuYW1lPWpvaG5kb2UmcGFzc3dvcmQ9QTNkZGozdw0NVGhlIGF1dGhvcml6YXRp b24gc2VydmVyIE1VU1QgdmFsaWRhdGUgdGhlIGNsaWVudCBjcmVkZW50aWFscyAoaWYgcHJlc2Vu dCkgYW5kIGVuZC11c2VyIGNyZWRlbnRpYWxzIGFuZCBpZiB2YWxpZCBpc3N1ZSBhbiBhY2Nlc3Mg dG9rZW4gcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIC4gDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2Mi IBSgVE9DoBUHBzUuMS4zLqAgQ2xpZW50IENyZWRlbnRpYWxzDVRoZSBjbGllbnQgY2FuIHJlcXVl c3QgYW4gYWNjZXNzIHRva2VuIHVzaW5nIG9ubHkgaXRzIGNsaWVudCBjcmVkZW50aWFscyB1c2lu ZyB0aGUgY2xpZW50X2NyZWRlbnRpYWxzIGFjY2VzcyBncmFudCB0eXBlLiBXaGVuIG9taXR0aW5n IGFuIGV4cGxpY2l0IGFjY2VzcyBncmFudCwgdGhlIGNsaWVudCBpcyByZXF1ZXN0aW5nIGFjY2Vz cyB0byB0aGUgcHJvdGVjdGVkIHJlc291cmNlcyB1bmRlciBpdHMgY29udHJvbCwgb3IgdGhvc2Ug b2YgYW5vdGhlciByZXNvdXJjZSBvd25lciB3aGljaCBoYXMgYmVlbiBwcmV2aW91c2x5IGFycmFu Z2VkIHdpdGggdGhlIGF1dGhvcml6YXRpb24gc2VydmVyICh0aGUgbWV0aG9kIG9mIHdoaWNoIGlz IGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uKS4gDQ0BDRMgSFlQRVJMSU5L IFxsICJ0b2MiIBSgVE9DoBUHBzUuMS40LqAgUmVmcmVzaCBUb2tlbg1UaGUgY2xpZW50IGluY2x1 ZGVzIHRoZSByZWZyZXNoIHRva2VuIHVzaW5nIHRoZSByZWZyZXNoX3Rva2VuIGFjY2VzcyBncmFu dCB0eXBlIGFuZCB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcjogDXJlZnJlc2hfdG9rZW4NUkVRVUlS RUQuIFRoZSByZWZyZXNoIHRva2VuIGFzc29jaWF0ZWQgd2l0aCB0aGUgYWNjZXNzIHRva2VuIHRv IGJlIHJlZnJlc2hlZC4gDUZvciBleGFtcGxlLCB0aGUgY2xpZW50IG1ha2VzIHRoZSBmb2xsb3dp bmcgSFRUUCByZXF1ZXN0IGJ5IGluY2x1ZGluZyBpdHMgY2xpZW50IGNyZWRlbnRpYWxzIHZpYSB0 aGUgY2xpZW50X3NlY3JldCBwYXJhbWV0ZXIgZGVzY3JpYmVkIGluICBhbmQgdXNpbmcgdHJhbnNw b3J0LWxheWVyIHNlY3VyaXR5IChsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMg b25seSk6IA0NDSAgUE9TVCAvdG9rZW4gSFRUUC8xLjENICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5j b20NICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZA0NICBn cmFudF90eXBlPXJlZnJlc2hfdG9rZW4mY2xpZW50X2lkPXM2QmhkUmtxdDMmDSAgY2xpZW50X3Nl Y3JldD04ZVNFSXBucW1NJnJlZnJlc2hfdG9rZW49bjRFOU8xMTlkDQ1UaGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgTVVTVCB2ZXJpZnkgdGhlIGNsaWVudCBjcmVkZW50aWFscyAoaWYgcHJlc2VudCks IHRoZSB2YWxpZGl0eSBvZiB0aGUgcmVmcmVzaCB0b2tlbiwgYW5kIHRoYXQgdGhlIHJlc291cmNl IG93bmVyJ3MgYXV0aG9yaXphdGlvbiBpcyBzdGlsbCB2YWxpZC4gSWYgdGhlIHJlcXVlc3QgaXMg dmFsaWQsIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBpc3N1ZXMgYW4gYWNjZXNzIHRva2VuIHJl c3BvbnNlIGFzIGRlc2NyaWJlZCBpbiAuIFRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBNQVkgaXNz dWUgYSBuZXcgcmVmcmVzaCB0b2tlbiwgaW4gd2hpY2ggY2FzZSwgdGhlIGNsaWVudCBNVVNUIGRp c2NhcmQgdGhlIG9sZCByZWZyZXNoIHRva2VuIGFuZCByZXBsYWNlIGl0IHdpdGggdGhlIG5ldyBy ZWZyZXNoIHRva2VuLiANDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHNS4xLjUuoCBB c3NlcnRpb24NVGhlIGNsaWVudCBpbmNsdWRlcyBhbiBhc3NlcnRpb24gYnkgc3BlY2lmeWluZyB0 aGUgYXNzZXJ0aW9uIGZvcm1hdCB1c2luZyBhbiBhYnNvbHV0ZSBVUkkgKGFzIGRlZmluZWQgYnkg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyKSBhcyB0aGUgdmFsdWUgb2YgdGhlIGdyYW50X3R5cGUg cGFyYW1ldGVyIGFuZCBieSBhZGRpbmcgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXI6IA1hc3NlcnRp b24NUkVRVUlSRUQuIFRoZSBhc3NlcnRpb24uIA1Gb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBtYWtl cyB0aGUgZm9sbG93aW5nIEhUVFAgcmVxdWVzdCB1c2luZyB0cmFuc3BvcnQtbGF5ZXIgc2VjdXJp dHksIGFuZCBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgYWNoaWV2ZWQgdmlhIHRoZSBhc3NlcnRp b24gKGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KTogDQ0NICBQT1NU IC90b2tlbiBIVFRQLzEuMQ0gIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQ0gIENvbnRlbnQtVHlw ZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkDQ0gIGdyYW50X3R5cGU9dXJuJTNB b2FzaXMlM0FuYW1lcyUzQXRjJTNBU0FNTCUzQTIuMCUzQWFzc2VydGlvbiYNICBhc3NlcnRpb249 UEhOaGJXeHdPbFsuLi5vbWl0dGVkIGZvciBicmV2aXR5Li4uXVpUNCUzRA0NVGhlIGF1dGhvcml6 YXRpb24gc2VydmVyIE1VU1QgdmFsaWRhdGUgdGhlIGNsaWVudCBjcmVkZW50aWFscyAoaWYgcHJl c2VudCkgYW5kIHRoZSBhc3NlcnRpb24gYW5kIGlmIHZhbGlkIGlzc3VlcyBhbiBhY2Nlc3MgdG9r ZW4gcmVzcG9uc2UgYXMgZGVzY3JpYmVkIGluIC4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNI T1VMRCBOT1QgaXNzdWUgYSByZWZyZXNoIHRva2VuIChpbnN0ZWFkLCBpdCBzaG91bGQgcmVxdWly ZSB0aGUgY2xpZW50IHRvIHVzZSB0aGUgc2FtZSBvciBuZXcgYXNzZXJ0aW9uKS4gDUF1dGhvcml6 YXRpb24gc2VydmVycyBTSE9VTEQgaXNzdWUgYWNjZXNzIHRva2VucyB3aXRoIGEgbGltaXRlZCBs aWZldGltZSBhbmQgcmVxdWlyZSBjbGllbnRzIHRvIHJlZnJlc2ggdGhlbSBieSByZXF1ZXN0aW5n IGEgbmV3IGFjY2VzcyB0b2tlbiB1c2luZyB0aGUgc2FtZSBhc3NlcnRpb24gaWYgaXQgaXMgc3Rp bGwgdmFsaWQuIE90aGVyd2lzZSB0aGUgY2xpZW50IE1VU1Qgb2J0YWluIGEgbmV3IHZhbGlkIGFz c2VydGlvbi4gDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzUuMi6gIEFjY2VzcyBU b2tlbiBSZXNwb25zZQ1BZnRlciByZWNlaXZpbmcgYW5kIHZlcmlmeWluZyBhIHZhbGlkIGFuZCBh dXRob3JpemVkIGFjY2VzcyB0b2tlbiByZXF1ZXN0IGZyb20gdGhlIGNsaWVudCwgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyIGlzc3VlcyB0aGUgYWNjZXNzIHRva2VuIGFuZCBvcHRpb25hbCByZWZy ZXNoIHRva2VuLCBhbmQgY29uc3RydWN0cyB0aGUgcmVzcG9uc2UgYnkgYWRkaW5nIHRoZSBmb2xs b3dpbmcgcGFyYW1ldGVycyB0byB0aGUgZW50aXR5IGJvZHkgb2YgdGhlIEhUVFAgcmVzcG9uc2Ug d2l0aCBhIDIwMCAoT0spIHN0YXR1cyBjb2RlOiANVGhlIHRva2VuIHJlc3BvbnNlIGNvbnRhaW5z IHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVyczogDWFjY2Vzc190b2tlbg1SRVFVSVJFRC4gVGhlIGFj Y2VzcyB0b2tlbiBpc3N1ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiANdG9rZW5fdHlw ZQ1SRVFVSVJFRC4gVGhlIHR5cGUgb2YgdGhlIHRva2VuIGlzc3VlZC4gVGhlIHRva2VuIHR5cGUg aW5mb3JtcyB0aGUgY2xpZW50IGhvdyB0aGUgYWNjZXNzIHRva2VuIGlzIHRvIGJlIHVzZWQgd2hl biBhY2Nlc3NpbmcgYSBwcm90ZWN0ZWQgcmVzb3VyY2UgYXMgZGVzY3JpYmVkIGluIC4gDWV4cGly ZXNfaW4NT1BUSU9OQUwuIFRoZSBkdXJhdGlvbiBpbiBzZWNvbmRzIG9mIHRoZSBhY2Nlc3MgdG9r ZW4gbGlmZXRpbWUuIEZvciBleGFtcGxlLCB0aGUgdmFsdWUgMzYwMCBkZW5vdGVzIHRoYXQgdGhl IGFjY2VzcyB0b2tlbiB3aWxsIGV4cGlyZSBpbiBvbmUgaG91ciBmcm9tIHRoZSB0aW1lIHRoZSBy ZXNwb25zZSB3YXMgZ2VuZXJhdGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gDXJlZnJl c2hfdG9rZW4NT1BUSU9OQUwuIFRoZSByZWZyZXNoIHRva2VuIHVzZWQgdG8gb2J0YWluIG5ldyBh Y2Nlc3MgdG9rZW5zIHVzaW5nIHRoZSBzYW1lIGVuZC11c2VyIGFjY2VzcyBncmFudCBhcyBkZXNj cmliZWQgaW4gLiBUaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgU0hPVUxEIE5PVCBpc3N1ZSBhIHJl ZnJlc2ggdG9rZW4gd2hlbiB0aGUgYWNjZXNzIGdyYW50IHR5cGUgaXMgYW4gYXNzZXJ0aW9uIG9y IGEgc2V0IG9mIGNsaWVudCBjcmVkZW50aWFscy4gDXNjb3BlDU9QVElPTkFMLiBUaGUgc2NvcGUg b2YgdGhlIGFjY2VzcyB0b2tlbiBhcyBhIGxpc3Qgb2Ygc3BhY2UtZGVsaW1pdGVkIHN0cmluZ3Mu IFRoZSB2YWx1ZSBvZiB0aGUgc2NvcGUgcGFyYW1ldGVyIGlzIGRlZmluZWQgYnkgdGhlIGF1dGhv cml6YXRpb24gc2VydmVyLiBJZiB0aGUgdmFsdWUgY29udGFpbnMgbXVsdGlwbGUgc3BhY2UtZGVs aW1pdGVkIHN0cmluZ3MsIHRoZWlyIG9yZGVyIGRvZXMgbm90IG1hdHRlciwgYW5kIGVhY2ggc3Ry aW5nIGFkZHMgYW4gYWRkaXRpb25hbCBhY2Nlc3MgcmFuZ2UgdG8gdGhlIHJlcXVlc3RlZCBzY29w ZS4gVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNIT1VMRCBpbmNsdWRlIHRoZSBwYXJhbWV0ZXIg aWYgdGhlIHJlcXVlc3RlZCBzY29wZSBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgb25lIHJlcXVlc3Rl ZCBieSB0aGUgY2xpZW50LiANVGhlIHBhcmFtZXRlcnMgYXJlIGluY2x1ZGluZyBpbiB0aGUgZW50 aXR5IGJvZHkgb2YgdGhlIEhUVFAgcmVzcG9uc2UgdXNpbmcgdGhlIGFwcGxpY2F0aW9uL2pzb24g bWVkaWEgdHlwZSBhcyBkZWZpbmVkIGJ5IC4gVGhlIHBhcmFtZXRlcnMgYXJlIHNlcmlhbGl6ZWQg aW50byBhIEpTT04gc3RydWN0dXJlIGJ5IGFkZGluZyBlYWNoIHBhcmFtZXRlciBhdCB0aGUgaGln aGVzdCBzdHJ1Y3R1cmUgbGV2ZWwuIFBhcmFtZXRlciBuYW1lcyBhbmQgc3RyaW5nIHZhbHVlcyBh cmUgaW5jbHVkZWQgYXMgSlNPTiBzdHJpbmdzLiBOdW1lcmljYWwgdmFsdWVzIGFyZSBpbmNsdWRl ZCBhcyBKU09OIG51bWJlcnMuIA1UaGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgTVVTVCBpbmNsdWRl IHRoZSBIVFRQIENhY2hlLUNvbnRyb2wgcmVzcG9uc2UgaGVhZGVyIGZpZWxkIHdpdGggYSB2YWx1 ZSBvZiBuby1zdG9yZSBpbiBhbnkgcmVzcG9uc2UgY29udGFpbmluZyB0b2tlbnMsIHNlY3JldHMs IG9yIG90aGVyIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbi4gDUZvciBleGFtcGxlOiANDQ0gIEhUVFAv MS4xIDIwMCBPSw0gIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vanNvbg0gIENhY2hlLUNvbnRy b2w6IG5vLXN0b3JlDQ0gIHsNICAgICJhY2Nlc3NfdG9rZW4iOiJTbEFWMzJoa0tHIiwNICAgICJ0 b2tlbl90eXBlIjoiZXhhbXBsZSIsDSAgICAiZXhwaXJlc19pbiI6MzYwMCwNICAgICJyZWZyZXNo X3Rva2VuIjoiOHhMT3hCdFpwOCINICB9DQ1DbGllbnRzIFNIT1VMRCBpZ25vcmUgdW5yZWNvZ25p emVkIHJlc3BvbnNlIHBhcmFtZXRlcnMuIFRoZSBzaXplcyBvZiB0b2tlbnMgYW5kIG90aGVyIHZh bHVlcyByZWNlaXZlZCBmcm9tIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYXJlIGxlZnQgdW5k ZWZpbmVkIGJ5IHRoaXMgc3BlY2lmaWNhdGlvbi4gQ2xpZW50cyBzaG91bGQgYXZvaWQgbWFraW5n IGFzc3VtcHRpb25zIGFib3V0IHZhbHVlIHNpemVzLiBTZXJ2ZXJzIHNob3VsZCBkb2N1bWVudCB0 aGUgZXhwZWN0ZWQgc2l6ZSBvZiBhbnkgdmFsdWUgdGhleSBpc3N1ZS4gDQ0BDRMgSFlQRVJMSU5L IFxsICJ0b2MiIBSgVE9DoBUHBzUuMy6gIEVycm9yIFJlc3BvbnNlDUlmIHRoZSB0b2tlbiByZXF1 ZXN0IGlzIGludmFsaWQgb3IgdW5hdXRob3JpemVkLCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIg Y29uc3RydWN0cyB0aGUgcmVzcG9uc2UgYnkgYWRkaW5nIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVy IHRvIHRoZSBlbnRpdHkgYm9keSBvZiB0aGUgSFRUUCByZXNwb25zZSB1c2luZyB0aGUgYXBwbGlj YXRpb24vanNvbiBtZWRpYSB0eXBlOiANZXJyb3INUkVRVUlSRUQuIEEgc2luZ2xlIGVycm9yIGNv ZGUgYXMgZGVzY3JpYmVkIGluIC4gDWVycm9yX2Rlc2NyaXB0aW9uDU9QVElPTkFMLiBBIGh1bWFu LXJlYWRhYmxlIHRleHQgcHJvdmlkaW5nIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24sIHVzZWQgdG8g YXNzaXN0IGluIHRoZSB1bmRlcnN0YW5kaW5nIGFuZCByZXNvbHV0aW9uIG9mIHRoZSBlcnJvciBv Y2N1cnJlZC4gDWVycm9yX3VyaQ1PUFRJT05BTC4gQSBVUkkgaWRlbnRpZnlpbmcgYSBodW1hbi1y ZWFkYWJsZSB3ZWIgcGFnZSB3aXRoIGluZm9ybWF0aW9uIGFib3V0IHRoZSBlcnJvciwgdXNlZCB0 byBwcm92aWRlIHRoZSBlbmQtdXNlciB3aXRoIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gYWJvdXQg dGhlIGVycm9yLiANRm9yIGV4YW1wbGU6IA0NDSAgSFRUUC8xLjEgNDAwIEJhZCBSZXF1ZXN0DSAg Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9qc29uDSAgQ2FjaGUtQ29udHJvbDogbm8tc3RvcmUN DSAgew0gICAgImVycm9yIjoiaW52YWxpZF9yZXF1ZXN0Ig0gIH0NDUlmIHRoZSBjbGllbnQgcHJv dmlkZWQgaW52YWxpZCBjcmVkZW50aWFscyB1c2luZyBhbiBIVFRQIGF1dGhlbnRpY2F0aW9uIHNj aGVtZSB2aWEgdGhlIEF1dGhvcml6YXRpb24gcmVxdWVzdCBoZWFkZXIgZmllbGQsIHRoZSBhdXRo b3JpemF0aW9uIHNlcnZlciBNVVNUIHJlc3BvbmQgd2l0aCB0aGUgSFRUUCA0MDEgKFVuYXV0aG9y aXplZCkgc3RhdHVzIGNvZGUuIE90aGVyd2lzZSwgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIFNI QUxMIHJlc3BvbmQgd2l0aCB0aGUgSFRUUCA0MDAgKEJhZCBSZXF1ZXN0KSBzdGF0dXMgY29kZS4g DQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzUuMy4xLqAgRXJyb3IgQ29kZXMNVGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGluY2x1ZGVzIG9uZSBvZiB0aGUgZm9sbG93aW5nIGVycm9y IGNvZGVzIHdpdGggdGhlIGVycm9yIHJlc3BvbnNlOiANaW52YWxpZF9yZXF1ZXN0DVRoZSByZXF1 ZXN0IGlzIG1pc3NpbmcgYSByZXF1aXJlZCBwYXJhbWV0ZXIsIGluY2x1ZGVzIGFuIHVuc3VwcG9y dGVkIHBhcmFtZXRlciBvciBwYXJhbWV0ZXIgdmFsdWUsIHJlcGVhdHMgYSBwYXJhbWV0ZXIsIGlu Y2x1ZGVzIG11bHRpcGxlIGNyZWRlbnRpYWxzLCB1dGlsaXplcyBtb3JlIHRoYW4gb25lIG1lY2hh bmlzbSBmb3IgYXV0aGVudGljYXRpbmcgdGhlIGNsaWVudCwgb3IgaXMgb3RoZXJ3aXNlIG1hbGZv cm1lZC4gDWludmFsaWRfY2xpZW50DVRoZSBjbGllbnQgaWRlbnRpZmllciBwcm92aWRlZCBpcyBp bnZhbGlkLCB0aGUgY2xpZW50IGZhaWxlZCB0byBhdXRoZW50aWNhdGUsIHRoZSBjbGllbnQgZGlk IG5vdCBpbmNsdWRlIGl0cyBjcmVkZW50aWFscywgcHJvdmlkZWQgbXVsdGlwbGUgY2xpZW50IGNy ZWRlbnRpYWxzLCBvciB1c2VkIHVuc3VwcG9ydGVkIGNyZWRlbnRpYWxzIHR5cGUuIA11bmF1dGhv cml6ZWRfY2xpZW50DVRoZSBhdXRoZW50aWNhdGVkIGNsaWVudCBpcyBub3QgYXV0aG9yaXplZCB0 byB1c2UgdGhlIGFjY2VzcyBncmFudCB0eXBlIHByb3ZpZGVkLiANaW52YWxpZF9ncmFudA1UaGUg cHJvdmlkZWQgYWNjZXNzIGdyYW50IGlzIGludmFsaWQsIGV4cGlyZWQsIG9yIHJldm9rZWQgKGUu Zy4gaW52YWxpZCBhc3NlcnRpb24sIGV4cGlyZWQgYXV0aG9yaXphdGlvbiB0b2tlbiwgYmFkIGVu ZC11c2VyIHBhc3N3b3JkIGNyZWRlbnRpYWxzLCBvciBtaXNtYXRjaGluZyBhdXRob3JpemF0aW9u IGNvZGUgYW5kIHJlZGlyZWN0aW9uIFVSSSkuIA11bnN1cHBvcnRlZF9ncmFudF90eXBlDVRoZSBh Y2Nlc3MgZ3JhbnQgaW5jbHVkZWQgLSBpdHMgdHlwZSBvciBhbm90aGVyIGF0dHJpYnV0ZSAtIGlz IG5vdCBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiANaW52YWxpZF9zY29w ZQ1UaGUgcmVxdWVzdGVkIHNjb3BlIGlzIGludmFsaWQsIHVua25vd24sIG1hbGZvcm1lZCwgb3Ig ZXhjZWVkcyB0aGUgcHJldmlvdXNseSBncmFudGVkIHNjb3BlLiANW1sgQWRkIG1lY2hhbmlzbSBm b3IgZXh0ZW5kaW5nIGVycm9yIGNvZGVzIF1dIA0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAUoFRP Q6AVBwc2LqAgQWNjZXNzaW5nIGEgUHJvdGVjdGVkIFJlc291cmNlDUNsaWVudHMgYWNjZXNzIHBy b3RlY3RlZCByZXNvdXJjZXMgYnkgcHJlc2VudGluZyBhbiBhY2Nlc3MgdG9rZW4gdG8gdGhlIHJl c291cmNlIHNlcnZlci4gVGhlIHJlc291cmNlIHNlcnZlciBNVVNUIHZhbGlkYXRlIHRoZSBhY2Nl c3MgdG9rZW4gYW5kIGVuc3VyZSBpdCBoYXMgbm90IGV4cGlyZWQgYW5kIHRoYXQgaXRzIHNjb3Bl IGNvdmVycyB0aGUgcmVxdWVzdGVkIHJlc291cmNlLiBUaGUgbWV0aG9kcyB1c2VkIGJ5IHRoZSBy ZXNvdXJjZSBzZXJ2ZXIgdG8gdmFsaWRhdGUgdGhlIGFjY2VzcyB0b2tlbiBhcmUgYmV5b25kIHRo ZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24sIGJ1dCBnZW5lcmFsbHkgaW52b2x2ZSBhbiBp bnRlcmFjdGlvbiBvciBjb29yZGluYXRpb24gYmV0d2VlbiB0aGUgcmVzb3VyY2Ugc2VydmVyIGFu ZCBhdXRob3JpemF0aW9uIHNlcnZlci4gDVRoZSBtZXRob2QgaW4gd2hpY2ggdGhlIGNsaWVudCB1 dGlsaXplZCB0aGUgYWNjZXNzIHRva2VuIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSByZXNvdXJj ZSBzZXJ2ZXIgZGVwZW5kcyBvbiB0aGUgdHlwZSBvZiBhY2Nlc3MgdG9rZW4gaXNzdWVkIGJ5IHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4gDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUH BzYuMS6gIEFjY2VzcyBUb2tlbiBUeXBlcw1bWyBhZGQgdG9rZW4gdHlwZSBleHBsYW5hdGlvbiwg bWF5YmUgd2l0aCBsaW5rcyB0byBvdGhlciB0b2tlbiBzcGVjcyBdXSANDQENEyBIWVBFUkxJTksg XGwgInRvYyIgFKBUT0OgFQcHNi4yLqAgVGhlIFdXVy1BdXRoZW50aWNhdGUgUmVzcG9uc2UgSGVh ZGVyIEZpZWxkDUlmIHRoZSBwcm90ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdCBkb2VzIG5vdCBpbmNs dWRlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzLCBjb250YWlucyBhbiBpbnZhbGlkIGFjY2Vz cyB0b2tlbiwgb3IgaXMgbWFsZm9ybWVkLCB0aGUgcmVzb3VyY2Ugc2VydmVyIE1VU1QgaW5jbHVk ZSB0aGUgSFRUUCBXV1ctQXV0aGVudGljYXRlIHJlc3BvbnNlIGhlYWRlciBmaWVsZC4gVGhlIFdX Vy1BdXRoZW50aWNhdGUgaGVhZGVyIGZpZWxkIHVzZXMgdGhlIGZyYW1ld29yayBkZWZpbmVkIGJ5 ICBhcyBmb2xsb3dzOiANDQ0gIGNoYWxsZW5nZSAgICAgICA9ICJPQXV0aDIiIFsgUldTIDEjcGFy YW0gXQ0NICBwYXJhbSAgICAgICAgICAgPSBzY29wZSAvDSAgICAgICAgICAgICAgICAgICAgZXJy b3IgLyBlcnJvci1kZXNjIC8gZXJyb3ItdXJpIC8NICAgICAgICAgICAgICAgICAgICAoIHRva2Vu ICI9IiAoIHRva2VuIC8gcXVvdGVkLXN0cmluZyApICkNDSAgc2NvcGUgICAgICAgICAgID0gInNj b3BlIiAiPSIgPCI+IHNjb3BlLXYgKiggU1Agc2NvcGUtdiApIDwiPg0gIHNjb3BlLXYgICAgICAg ICA9IDEqcXVvdGVkLWNoYXINDSAgcXVvdGVkLWNoYXIgICAgID0gQUxQSEEgLyBESUdJVCAvDSAg ICAgICAgICAgICAgICAgICAgIiEiIC8gIiMiIC8gIiQiIC8gIiUiIC8gIiYiIC8gIiciIC8gIigi IC8gIikiIC8NICAgICAgICAgICAgICAgICAgICAiKiIgLyAiKyIgLyAiLSIgLyAiLiIgLyAiLyIg LyAiOiIgLyAiPCIgLyAiPSIgLw0gICAgICAgICAgICAgICAgICAgICI+IiAvICI/IiAvICJAIiAv ICJbIiAvICJdIiAvICJeIiAvICJfIiAvICJgIiAvDSAgICAgICAgICAgICAgICAgICAgInsiIC8g InwiIC8gIn0iIC8gIn4iIC8gIlwiIC8gIiwiIC8gIjsiDQ0gIGVycm9yICAgICAgICAgICA9ICJl cnJvciIgIj0iIHF1b3RlZC1zdHJpbmcNICBlcnJvci1kZXNjICAgICAgPSAiZXJyb3JfZGVzY3Jp cHRpb24iICI9IiBxdW90ZWQtc3RyaW5nDSAgZXJyb3ItdXJpICAgICAgID0gImVycm9yX3VyaSIg PSA8Ij4gVVJJLXJlZmVyZW5jZSA8Ij4NDVRoZSBzY29wZSBhdHRyaWJ1dGUgaXMgYSBzcGFjZS1k ZWxpbWl0ZWQgbGlzdCBvZiBzY29wZSB2YWx1ZXMgaW5kaWNhdGluZyB0aGUgcmVxdWlyZWQgc2Nv cGUgb2YgdGhlIGFjY2VzcyB0b2tlbiBmb3IgYWNjZXNzaW5nIHRoZSByZXF1ZXN0ZWQgcmVzb3Vy Y2UuIFRoZSBzY29wZSBhdHRyaWJ1dGUgTVVTVCBOT1QgYXBwZWFyIG1vcmUgdGhhbiBvbmNlLiAN SWYgdGhlIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0IGluY2x1ZGVkIGFuIGFjY2VzcyB0b2tl biBhbmQgZmFpbGVkIGF1dGhlbnRpY2F0aW9uLCB0aGUgcmVzb3VyY2Ugc2VydmVyIFNIT1VMRCBp bmNsdWRlIHRoZSBlcnJvciBhdHRyaWJ1dGUgdG8gcHJvdmlkZSB0aGUgY2xpZW50IHdpdGggdGhl IHJlYXNvbiB3aHkgdGhlIGFjY2VzcyByZXF1ZXN0IHdhcyBkZWNsaW5lZC4gVGhlIHBhcmFtZXRl ciB2YWx1ZSBpcyBkZXNjcmliZWQgaW4gLiBJbiBhZGRpdGlvbiwgdGhlIHJlc291cmNlIHNlcnZl ciBNQVkgaW5jbHVkZSB0aGUgZXJyb3JfZGVzY3JpcHRpb24gYXR0cmlidXRlIHRvIHByb3ZpZGUg YSBodW1hbi1yZWFkYWJsZSBleHBsYW5hdGlvbiwgYW5kIHRoZSBlcnJvci11cmkgYXR0cmlidXRl IHdpdGggYW4gYWJzb2x1dGUgVVJJIGlkZW50aWZ5aW5nIGEgaHVtYW4tcmVhZGFibGUgd2ViIHBh Z2UgZXhwbGFpbmluZyB0aGUgZXJyb3IuIFRoZSBlcnJvciwgZXJyb3JfZGVzY3JpcHRpb24sIGFu ZCBlcnJvcl91cmkgYXR0cmlidXRlIE1VU1QgTk9UIGFwcGVhciBtb3JlIHRoYW4gb25jZS4gDUZv ciBleGFtcGxlLCBpbiByZXNwb25zZSB0byBhIHByb3RlY3RlZCByZXNvdXJjZSByZXF1ZXN0IHdp dGhvdXQgYXV0aGVudGljYXRpb246IA0NDSAgSFRUUC8xLjEgNDAxIFVuYXV0aG9yaXplZA0gIFdX Vy1BdXRoZW50aWNhdGU6IE9BdXRoMg0NQW5kIGluIHJlc3BvbnNlIHRvIGEgcHJvdGVjdGVkIHJl c291cmNlIHJlcXVlc3Qgd2l0aCBhbiBhdXRoZW50aWNhdGlvbiBhdHRlbXB0IHVzaW5nIGFuIGV4 cGlyZWQgYWNjZXNzIHRva2VuOiANDQ0gIEhUVFAvMS4xIDQwMSBVbmF1dGhvcml6ZWQNICBXV1ct QXV0aGVudGljYXRlOiBPQXV0aDINICAgICAgICAgICAgICAgICAgICBlcnJvcj0iaW52YWxpZF90 b2tlbiIsDSAgICAgICAgICAgICAgICAgICAgZXJyb3JfZGVzY3JpcHRpb249IlRoZSBhY2Nlc3Mg dG9rZW4gZXhwaXJlZCINDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzYuMi4xLqAg RXJyb3IgQ29kZXMNV2hlbiBhIHJlcXVlc3QgZmFpbHMsIHRoZSByZXNvdXJjZSBzZXJ2ZXIgcmVz cG9uZHMgdXNpbmcgdGhlIGFwcHJvcHJpYXRlIEhUVFAgc3RhdHVzIGNvZGUgKHR5cGljYWxseSwg NDAwLCA0MDEsIG9yIDQwMyksIGFuZCBpbmNsdWRlcyBvbmUgb2YgdGhlIGZvbGxvd2luZyBlcnJv ciBjb2RlcyBpbiB0aGUgcmVzcG9uc2U6IA1pbnZhbGlkX3JlcXVlc3QNVGhlIHJlcXVlc3QgaXMg bWlzc2luZyBhIHJlcXVpcmVkIHBhcmFtZXRlciwgaW5jbHVkZXMgYW4gdW5zdXBwb3J0ZWQgcGFy YW1ldGVyIG9yIHBhcmFtZXRlciB2YWx1ZSwgcmVwZWF0cyB0aGUgc2FtZSBwYXJhbWV0ZXIsIHVz ZXMgbW9yZSB0aGFuIG9uZSBtZXRob2QgZm9yIGluY2x1ZGluZyBhbiBhY2Nlc3MgdG9rZW4sIG9y IGlzIG90aGVyd2lzZSBtYWxmb3JtZWQuIFRoZSByZXNvdXJjZSBzZXJ2ZXIgU0hPVUxEIHJlc3Bv bmQgd2l0aCB0aGUgSFRUUCA0MDAgKEJhZCBSZXF1ZXN0KSBzdGF0dXMgY29kZS4gDWludmFsaWRf dG9rZW4NVGhlIGFjY2VzcyB0b2tlbiBwcm92aWRlZCBpcyBleHBpcmVkLCByZXZva2VkLCBtYWxm b3JtZWQsIG9yIGludmFsaWQgZm9yIG90aGVyIHJlYXNvbnMuIFRoZSByZXNvdXJjZSBTSE9VTEQg cmVzcG9uZCB3aXRoIHRoZSBIVFRQIDQwMSAoVW5hdXRob3JpemVkKSBzdGF0dXMgY29kZS4gVGhl IGNsaWVudCBNQVkgcmVxdWVzdCBhIG5ldyBhY2Nlc3MgdG9rZW4gYW5kIHJldHJ5IHRoZSBwcm90 ZWN0ZWQgcmVzb3VyY2UgcmVxdWVzdC4gDWluc3VmZmljaWVudF9zY29wZQ1UaGUgcmVxdWVzdCBy ZXF1aXJlcyBoaWdoZXIgcHJpdmlsZWdlcyB0aGFuIHByb3ZpZGVkIGJ5IHRoZSBhY2Nlc3MgdG9r ZW4uIFRoZSByZXNvdXJjZSBzZXJ2ZXIgU0hPVUxEIHJlc3BvbmQgd2l0aCB0aGUgSFRUUCA0MDMg KEZvcmJpZGRlbikgc3RhdHVzIGNvZGUgYW5kIE1BWSBpbmNsdWRlIHRoZSBzY29wZSBhdHRyaWJ1 dGUgd2l0aCB0aGUgc2NvcGUgbmVjZXNzYXJ5IHRvIGFjY2VzcyB0aGUgcHJvdGVjdGVkIHJlc291 cmNlLiANW1sgQWRkIG1lY2hhbmlzbSBmb3IgZXh0ZW5kaW5nIGVycm9yIGNvZGVzIF1dIA1JZiB0 aGUgcmVxdWVzdCBsYWNrcyBhbnkgYXV0aGVudGljYXRpb24gaW5mb3JtYXRpb24gKGkuZS4gdGhl IGNsaWVudCB3YXMgdW5hd2FyZSBhdXRoZW50aWNhdGlvbiBpcyBuZWNlc3Nhcnkgb3IgYXR0ZW1w dGVkIHVzaW5nIGFuIHVuc3VwcG9ydGVkIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCksIHRoZSByZXNv dXJjZSBzZXJ2ZXIgU0hPVUxEIG5vdCBpbmNsdWRlIGFuIGVycm9yIGNvZGUgb3Igb3RoZXIgZXJy b3IgaW5mb3JtYXRpb24uIA1Gb3IgZXhhbXBsZTogDQ0NICBIVFRQLzEuMSA0MDEgVW5hdXRob3Jp emVkDSAgV1dXLUF1dGhlbnRpY2F0ZTogT0F1dGgyDQ0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAU oFRPQ6AVBwc3LqAgRXh0ZW5zaWJpbGl0eQ0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAUoFRPQ6AV Bwc3LjEuoCBEZWZpbmluZyBOZXcgQ2xpZW50IENyZWRlbnRpYWxzIFR5cGVzDVtbIFRCRCBdXSAN DQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHNy4yLqAgRGVmaW5pbmcgTmV3IEVuZHBv aW50IFBhcmFtZXRlcnMNQXBwbGljYXRpb25zIHRoYXQgd2lzaCB0byBkZWZpbmUgbmV3IHJlcXVl c3Qgb3IgcmVzcG9uc2UgcGFyYW1ldGVycyBmb3IgdXNlIHdpdGggdGhlIGVuZC11c2VyIGF1dGhv cml6YXRpb24gZW5kcG9pbnQgb3IgdGhlIHRva2VuIGVuZHBvaW50IFNIQUxMIGRvIHNvIGluIG9u ZSBvZiB0d28gd2F5czogcmVnaXN0ZXIgdGhlbSBpbiB0aGUgcGFyYW1ldGVycyByZWdpc3RyeSAo Zm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluICksIG9yIHVzZSB0aGUgeF8gcGFyYW1ldGVyIG5h bWUgcHJlZml4LiANUGFyYW1ldGVycyB1dGlsaXppbmcgdGhlIHhfIHBhcmFtZXRlciBuYW1lIHBy ZWZpeCBNVVNUIGJlIGxpbWl0ZWQgdG8gdmVuZG9yLXNwZWNpZmljIGV4dGVuc2lvbnMgdGhhdCBh cmUgbm90IGNvbW1vbmx5IGFwcGxpY2FibGUsIGFuZCBhcmUgc3BlY2lmaWMgdG8gdGhlIGltcGxl bWVudGF0aW9uIGRldGFpbHMgb2YgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIHdoZXJlIHRoZXkg YXJlIHVzZWQuIEFsbCBvdGhlciBuZXcgcGFyYW1ldGVycyBNVVNUIGJlIHJlZ2lzdGVyZWQsIGFu ZCBNVVNUIE5PVCB1c2UgdGhlIHhfIHBhcmFtZXRlciBuYW1lIHByZWZpeC4gDVBhcmFtZXRlciBu YW1lcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHBhcmFtLW5hbWUgQUJORiwgYW5kIHBhcmFtZXRlciB2 YWx1ZXMgc3ludGF4IE1VU1QgYmUgd2VsbC1kZWZpbmVkIChlLmcuLCB1c2luZyBBQk5GLCBvciBh IHJlZmVyZW5jZSB0byB0aGUgc3ludGF4IG9mIGFuIGV4aXN0aW5nIHBhcmFtZXRlcikuIA0NDSAg cGFyYW0tbmFtZSAgPSAxKm5hbWUtY2hhcg0gIG5hbWUtY2hhciAgID0gIi0iIC8gIi4iIC8gIl8i IC8gRElHSVQgLyBBTFBIQQ0NDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHNy4zLqAg RGVmaW5pbmcgTmV3IEhlYWRlciBGaWVsZCBQYXJhbWV0ZXJzDUFwcGxpY2F0aW9ucyB0aGF0IHdp c2ggdG8gZGVmaW5lIG5ldyBwYXJhbWV0ZXJzIGZvciB1c2UgaW4gdGhlIE9BdXRoIFdXVy1BdXRo ZW50aWNhdGUgaGVhZGVyIGZpZWxkIE1VU1QgcmVnaXN0ZXIgdGhlbSBpbiB0aGUgcGFyYW1ldGVy cyByZWdpc3RyeSwgZm9sbG93aW5nIHRoZSBwcm9jZWR1cmVzIGluIC4gDVBhcmFtZXRlciBuYW1l cyBNVVNUIGNvbmZvcm0gdG8gdGhlIHBhcmFtLW5hbWUgQUJORiBhbmQgTVVTVCBOT1QgYmVnaW4g d2l0aCB4Xy4gUGFyYW1ldGVyIHZhbHVlcyBNVVNUIGNvbmZvcm0gdG8gdGhlIHBhcmFtLXZhbHVl IEFCTkYgYW5kIHRoZWlyIHN5bnRheCBNVVNUIGJlIHdlbGwtZGVmaW5lZCAoZS5nLiwgdXNpbmcg QUJORiwgb3IgYSByZWZlcmVuY2UgdG8gdGhlIHN5bnRheCBvZiBhbiBleGlzdGluZyBwYXJhbWV0 ZXIpLiANDQ0gIHBhcmFtLXZhbHVlICA9IHF1b3RlZC12YWx1ZSB8IHF1b3RlZC1zdHJpbmcNDQ0B DRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzcuNC6gIERlZmluaW5nIE5ldyBBY2Nlc3Mg R3JhbnQgVHlwZXMNVGhlIGFzc2VydGlvbiBhY2Nlc3MgZ3JhbnQgdHlwZSBhbGxvd3MgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIHRvIGFjY2VwdCBhZGRpdGlvbmFsIGFjY2VzcyBncmFudHMgbm90 IHNwZWNpZmllZC4gQXBwbGljYXRpb25zIHRoYXQgd2lzaCB0byBkZWZpbmUgYWRkaXRpb25hbCBh Y2Nlc3MgZ3JhbnQgdHlwZXMgY2FuIGRvIHNvIGJ5IHV0aWxpemluZyBhIG5ldyBvciBleGlzdGlu ZyBhc3NlcnRpb24gdHlwZSBhbmQgZm9ybWF0LiANDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBU T0OgFQcHOC6gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDVtbIFRCRCBdXSANDQENEyBIWVBFUkxJ TksgXGwgInRvYyIgFKBUT0OgFQcHOS6gIElBTkEgQ29uc2lkZXJhdGlvbnMNDQENEyBIWVBFUkxJ TksgXGwgInRvYyIgFKBUT0OgFQcHOS4xLqAgVGhlIE9BdXRoIFBhcmFtZXRlcnMgUmVnaXN0cnkN VGhpcyBkb2N1bWVudCBlc3RhYmxpc2hlcyB0aGUgT0F1dGggcGFyYW1ldGVycyByZWdpc3RyeS4g DUFkZGl0aW9uYWwgcGFyYW1ldGVycyB0byBiZSB1c2UgaW4gdGhlIGVuZC11c2VyIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQgcmVxdWVzdCwgdGhlIGVuZC11c2VyIGF1dGhvcml6YXRpb24gZW5kcG9p bnQgcmVzcG9uc2UsIHRoZSB0b2tlbiBlbmRwb2ludCByZXF1ZXN0LCB0aGUgdG9rZW4gZW5kcG9p bnQgcmVzcG9uc2UsIG9yIHRoZSBXV1ctQXV0aGVudGljYXRlIGhlYWRlciBmaWVsZCwgYXJlIHJl Z2lzdGVyZWQgb24gdGhlIGFkdmljZSBvZiBvbmUgb3IgbW9yZSBEZXNpZ25hdGVkIEV4cGVydHMg KGFwcG9pbnRlZCBieSB0aGUgSUVTRyBvciB0aGVpciBkZWxlZ2F0ZSksIHdpdGggYSBTcGVjaWZp Y2F0aW9uIFJlcXVpcmVkICh1c2luZyB0ZXJtaW5vbG9neSBmcm9tICkuIEhvd2V2ZXIsIHRvIGFs bG93IGZvciB0aGUgYWxsb2NhdGlvbiBvZiB2YWx1ZXMgcHJpb3IgdG8gcHVibGljYXRpb24sIHRo ZSBEZXNpZ25hdGVkIEV4cGVydChzKSBtYXkgYXBwcm92ZSByZWdpc3RyYXRpb24gb25jZSB0aGV5 IGFyZSBzYXRpc2ZpZWQgdGhhdCBzdWNoIGEgc3BlY2lmaWNhdGlvbiB3aWxsIGJlIHB1Ymxpc2hl ZC4gDVJlZ2lzdHJhdGlvbiByZXF1ZXN0cyBzaG91bGQgYmUgc2VudCB0byB0aGUgW1RCRF1AaWV0 Zi5vcmcgbWFpbGluZyBsaXN0IGZvciByZXZpZXcgYW5kIGNvbW1lbnQsIHdpdGggYW4gYXBwcm9w cmlhdGUgc3ViamVjdCAoZS5nLiwgIlJlcXVlc3QgZm9yIHBhcmFtZXRlcjogZXhhbXBsZSIpLiBb WyBOb3RlIHRvIFJGQy1FRElUT1I6IFRoZSBuYW1lIG9mIHRoZSBtYWlsaW5nIGxpc3Qgc2hvdWxk IGJlIGRldGVybWluZWQgaW4gY29uc3VsdGF0aW9uIHdpdGggdGhlIElFU0cgYW5kIElBTkEuIFN1 Z2dlc3RlZCBuYW1lOiBvYXV0aC1leHQtcmV2aWV3LiBdXSANQmVmb3JlIGEgcGVyaW9kIG9mIDE0 IGRheXMgaGFzIHBhc3NlZCwgdGhlIERlc2lnbmF0ZWQgRXhwZXJ0KHMpIHdpbGwgZWl0aGVyIGFw cHJvdmUgb3IgZGVueSB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QsIGNvbW11bmljYXRpbmcgdGhp cyBkZWNpc2lvbiBib3RoIHRvIHRoZSByZXZpZXcgbGlzdCBhbmQgdG8gSUFOQS4gRGVuaWFscyBz aG91bGQgaW5jbHVkZSBhbiBleHBsYW5hdGlvbiBhbmQsIGlmIGFwcGxpY2FibGUsIHN1Z2dlc3Rp b25zIGFzIHRvIGhvdyB0byBtYWtlIHRoZSByZXF1ZXN0IHN1Y2Nlc3NmdWwuIFJlZ2lzdHJhdGlv biByZXF1ZXN0cyB0aGF0IGFyZSB1bmRldGVybWluZWQgZm9yIGEgcGVyaW9kIGxvbmdlciB0aGFu IDIxIGRheXMgY2FuIGJlIGJyb3VnaHQgdG8gdGhlIElFU0cncyBhdHRlbnRpb24gKHVzaW5nIHRo ZSBpZXNnQGllc2cub3JnIG1haWxpbmcgbGlzdCkgZm9yIHJlc29sdXRpb24uIA0NAQ0TIEhZUEVS TElOSyBcbCAidG9jIiAUoFRPQ6AVBwc5LjEuMS6gIFJlZ2lzdHJhdGlvbiBUZW1wbGF0ZQ1QYXJh bWV0ZXIgbmFtZToNVGhlIG5hbWUgcmVxdWVzdGVkIChlLmcuLCAiZXhhbXBsZSIpLiANUGFyYW1l dGVyIHVzYWdlIGxvY2F0aW9uOg1UaGUgbG9jYXRpb24ocykgd2hlcmUgcGFyYW1ldGVyIGNhbiBi ZSB1c2VkLiBUaGUgcG9zc2libGUgbG9jYXRpb25zIGFyZTogdGhlIGVuZC11c2VyIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQgcmVxdWVzdCwgdGhlIGVuZC11c2VyIGF1dGhvcml6YXRpb24gZW5kcG9p bnQgcmVzcG9uc2UsIHRoZSB0b2tlbiBlbmRwb2ludCByZXF1ZXN0LCB0aGUgdG9rZW4gZW5kcG9p bnQgcmVzcG9uc2UsIHRoZSBvciB0aGUgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIgZmllbGQuIA1D aGFuZ2UgY29udHJvbGxlcjoNRm9yIHN0YW5kYXJkcy10cmFjayBSRkNzLCBzdGF0ZSAiSUVURiIu IEZvciBvdGhlcnMsIGdpdmUgdGhlIG5hbWUgb2YgdGhlIHJlc3BvbnNpYmxlIHBhcnR5LiBPdGhl ciBkZXRhaWxzIChlLmcuLCBwb3N0YWwgYWRkcmVzcywgZS1tYWlsIGFkZHJlc3MsIGhvbWUgcGFn ZSBVUkkpIG1heSBhbHNvIGJlIGluY2x1ZGVkLiANU3BlY2lmaWNhdGlvbiBkb2N1bWVudChzKToN UmVmZXJlbmNlIHRvIGRvY3VtZW50IHRoYXQgc3BlY2lmaWVzIHRoZSBwYXJhbWV0ZXIsIHByZWZl cmFibHkgaW5jbHVkaW5nIGEgVVJJIHRoYXQgY2FuIGJlIHVzZWQgdG8gcmV0cmlldmUgYSBjb3B5 IG9mIHRoZSBkb2N1bWVudC4gQW4gaW5kaWNhdGlvbiBvZiB0aGUgcmVsZXZhbnQgc2VjdGlvbnMg bWF5IGFsc28gYmUgaW5jbHVkZWQsIGJ1dCBpcyBub3QgcmVxdWlyZWQuIA1SZWxhdGVkIGluZm9y bWF0aW9uOg1PcHRpb25hbGx5LCBjaXRhdGlvbnMgdG8gYWRkaXRpb25hbCBkb2N1bWVudHMgY29u dGFpbmluZyBmdXJ0aGVyIHJlbGV2YW50IGluZm9ybWF0aW9uLiANDQENEyBIWVBFUkxJTksgXGwg InRvYyIgFKBUT0OgFQcHOS4xLjIuoCBFeGFtcGxlDVRoZSBmb2xsb3dpbmcgaXMgdGhlIHBhcmFt ZXRlciByZWdpc3RyYXRpb24gcmVxdWVzdCBmb3IgdGhlIHNjb3BlIHBhcmFtZXRlciBhcyBkZWZp bmVkIGluIHRoaXMgc3BlY2lmaWNhdGlvbjogDVBhcmFtZXRlciBuYW1lOg1zY29wZSANUGFyYW1l dGVyIHVzYWdlIGxvY2F0aW9uOg1UaGUgZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBy ZXF1ZXN0LCB0aGUgZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXNwb25zZSwgdGhl IHRva2VuIGVuZHBvaW50IHJlcXVlc3QsIHRoZSB0b2tlbiBlbmRwb2ludCByZXNwb25zZSwgYW5k IHRoZSBXV1ctQXV0aGVudGljYXRlIGhlYWRlciBmaWVsZC4gDUNoYW5nZSBjb250cm9sbGVyOg1J RVRGIA1TcGVjaWZpY2F0aW9uIGRvY3VtZW50KHMpOg1bWyB0aGlzIGRvY3VtZW50IF1dIA1SZWxh dGVkIGluZm9ybWF0aW9uOg1Ob25lIA0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAUoFRPQ6AVBwdB cHBlbmRpeCBBLqAgRXhhbXBsZXMNW1sgVEJEIF1dIA0NAQ0TIEhZUEVSTElOSyBcbCAidG9jIiAU oFRPQ6AVBwdBcHBlbmRpeCBCLqAgQ29udHJpYnV0b3JzDVRoZSBmb2xsb3dpbmcgcGVvcGxlIGNv bnRyaWJ1dGVkIHRvIHByZWxpbWluYXJ5IHZlcnNpb25zIG9mIHRoaXMgZG9jdW1lbnQ6IEJsYWlu ZSBDb29rIChCVCksIEJyaWFuIEVhdG9uIChHb29nbGUpLCBZYXJvbiBHb2xhbmQgKE1pY3Jvc29m dCksIEJyZW50IEdvbGRtYW4gKEZhY2Vib29rKSwgUmFmZmkgS3Jpa29yaWFuIChUd2l0dGVyKSwg THVrZSBTaGVwYXJkIChGYWNlYm9vayksIGFuZCBBbGxlbiBUb20gKFlhaG9vISkuIFRoZSBjb250 ZW50IGFuZCBjb25jZXB0cyB3aXRoaW4gYXJlIGEgcHJvZHVjdCBvZiB0aGUgT0F1dGggY29tbXVu aXR5LCBXUkFQIGNvbW11bml0eSwgYW5kIHRoZSBPQXV0aCBXb3JraW5nIEdyb3VwLiANVGhlIE9B dXRoIFdvcmtpbmcgR3JvdXAgaGFzIGRvemVucyBvZiB2ZXJ5IGFjdGl2ZSBjb250cmlidXRvcnMg d2hvIHByb3Bvc2VkIGlkZWFzIGFuZCB3b3JkaW5nIGZvciB0aGlzIGRvY3VtZW50LCBpbmNsdWRp bmc6IFtbIElmIHlvdXIgbmFtZSBpcyBtaXNzaW5nIG9yIHlvdSB0aGluayBzb21lb25lIHNob3Vs ZCBiZSBhZGRlZCBoZXJlLCBwbGVhc2Ugc2VuZCBFcmFuIGEgbm90ZSAtIGRvbid0IGJlIHNoeSBd XSANTWljaGFlbCBBZGFtcywgQW5kcmV3IEFybm90dCwgRGlyayBCYWxmYW56LCBCcmlhbiBDYW1w YmVsbCwgTGVhaCBDdWx2ZXIsIEJpbGwgZGUgaNNyYSwgQnJpYW4gRWxsaW4sIElnb3IgRmF5bmJl cmcsIEdlb3JnZSBGbGV0Y2hlciwgVGltIEZyZWVtYW4sIEV2YW4gR2lsYmVydCwgS3Jpc3RvZmZl ciBHcm9ub3dza2ksIEp1c3RpbiBIYXJ0LCBNaWtlIE1pY2hhZWwgQi4gSm9uZXMFLCBKb2huIEtl bXAsIENoYXNlbiBMZSBIYXJhLCBUb3JzdGVuIExvZGRlcnN0ZWR0LCBBbGFzdGFpciBNYWlyLCBF dmUgTWFsZXIsIEphbWVzIE1hbmdlciwgTGF1cmVuY2UgTWlhbywgQ2h1Y2sgTW9ydGltb3JlLCBB bnRob255IE5hZGFsaW4sIEp1c3RpbiBSaWNoZXIsIFBldGVyIFNhaW50LUFuZHJlLCBOYXQgU2Fr aW11cmEsIFJvYiBTYXlyZSwgTWFyaXVzIFNjdXJ0ZXNjdSwgTmFpdGlrIFNoYWgsIEp1c3RpbiBT bWl0aCwgSmVyZW15IFN1cmllbCwgQ2hyaXN0aWFuIFN0/GJuZXIsIFBhdWwgVGFyamFuLCBGcmFu a2xpbiBUc2UsIGFuZCBOaWNrIFdhbGtlci4gDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9D oBUHB0FwcGVuZGl4IEMuoCBBY2tub3dsZWRnZW1lbnRzDVtbIEFkZCBPQXV0aCAxLjBhIGF1dGhv cnMgKyBXRyBjb250cmlidXRvcnMgXV0gDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUH B0FwcGVuZGl4IEQuoCBEb2N1bWVudCBIaXN0b3J5DVtbIHRvIGJlIHJlbW92ZWQgYnkgUkZDIGVk aXRvciBiZWZvcmUgcHVibGljYXRpb24gYXMgYW4gUkZDIF1dIA0tMTEgDU1hbnkgZWRpdG9yaWFs IGNoYW5nZXMuIEZpeGVkIHVzZXIgYXV0aG9yaXphdGlvbiBzZWN0aW9uIHN0cnVjdHVyZS4gUmVt b3ZlZCB1bnVzZWQgbm9ybWF0aXZlIHJlZmVyZW5jZXMuIEFkanVzdGVkIGxhbmd1YWdlIHJlZ2Fy ZGluZyBzaW5nbGUgdXNlIG9mIGF1dGhvcml6YXRpb24gY29kZXMuIA1GaXhlZCBoZWFkZXIgQUJO Ri4gDUNoYW5nZSBhY2Nlc3MgdG9rZW4gZGVzY3JpcHRpb24gZnJvbSBzaGFyZWQgc3ltbWV0cmlj IHNlY3JldCB0byBwYXNzd29yZC4gDU1vdmVkIGFjY2VzcyBncmFudCAnbm9uZScgdG8gYSBzZXBh cmF0ZSBzZWN0aW9uLCByZW5hbWVkIHRvICdjbGllbnRfY3JlZGVudGlhbHMnLiANRGVtb3RlZCB0 aGUgSFRUUCBzdGF0dXMgY29kZSByZXF1aXJlbWVudCBmcm9tIE1VU1QgdG8gU0hPVUxEIGluIHBy b3RlY3RlZCByZXNvdXJjZSByZXNwb25zZSBlcnJvci4gDVJlbW92ZWQgJ2V4cGlyZWRfdG9rZW4n IGVycm9yIGNvZGUuIA1Nb3ZlZCBhbGwgdGhlICdjb2RlX2FuZF90b2tlbicgcGFyYW1ldGVyIHRv IHRoZSBmcmFnbWVudCAoZnJvbSBjb2RlIGJlaW5nIGluIHRoZSBxdWVyeSkuIA1SZW1vdmVkICdh c3NlcnRpb25fdHlwZScgcGFyYW1ldGVyIChtb3ZlZCB0byAnZ3JhbnRfdHlwZScpLiANQWRkZWQg bm90ZSBhYm91dCByZWRpcmVjdGluZyB0byBpbnZhbGlkIHJlZGlyZWN0aW9uIFVSSXMgKG9wZW4g cmVkaXJlY3RvcnMpLiANUmVtb3ZlZCBiZWFyZXIgdG9rZW4gc2VjdGlvbiwgYWRkZWQgbmV3IHJl cXVpcmVkICd0b2tlbl90eXBlJyBwYXJhbWV0ZXIgd2l0aCBleHRlbnNpYmlsaXR5LiANJ2Vycm9y LXVyaScgcGFyYW1ldGVyIHZhbHVlIGNoYW5nZWQgdG8gYWJzb2x1dGUgVVJJLiANT0F1dGggMi4w IEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lIG5hbWUgY2hhbmdlZCB0byAnT0F1dGgyJy4gDURy b3BwZWQgdGhlICdXV1ctQXV0aGVudGljYXRlJyBoZWFkZXIgZmllbGQgJ3JlYWxtJyBwYXJhbWV0 ZXIuIA1SZW1vdmVkIGRlZmluaXRpb24gb2YgYWNjZXNzIHRva2VuIGNoYXJhY3RlcnMuIA1BZGRl ZCBpbnN0cnVjdGlvbnMgZm9yIGRlYWxpbmcgd2l0aCBlcnJvciBhbmQgYW4gaW52YWxpZCByZWRp cmVjdGlvbiBVUkkuIA0tMTAgDUZpeGVkIHR5cG9zLiBNYW55IGVkaXRvcmlhbCBjaGFuZ2VzLiBS ZXdyb3RlIGludHJvZHVjdGlvbi4gcmVtb3ZlZCB0ZXJtaW5vbG9neSBncm91cGluZy4gDUFsbG93 ZWQgUE9TVCBmb3IgZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBlbmRwb2ludC4gDUZpeGVkIHRva2Vu IGVuZHBvaW50IHRvIG5vdCByZXF1aXJlIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gDU1hZGUgVVJJ IHF1ZXJ5IGFuZCBQT1NUIGJvZHkgJ29hdXRoX3Rva2VuJyBwYXJhbWV0ZXIgb3B0aW9uYWwuIA1N b3ZlZCBhbGwgcGFyYW1ldGVyIG5hbWVzIGFuZCB2YWx1ZXMgdG8gdXNlIHVuZGVyc2NvcmVzLiAN Q2hhbmdlZCAnYmFzaWNfY3JlZGVudGlhbHMnIHRvICdwYXNzd29yZCcsICdpbnZhbGlkX2NsaWVu dF9jcmVkZW50aWFscycgYW5kICdpbnZhbGlkX2NsaWVudF9pZCcgdG8gJ2ludmFsaWRfY2xpZW50 Jy4gDUFkZGVkIG5vdGUgdGhhdCBhY2Nlc3MgdG9rZW4gcmVxdWVzdHMgd2l0aG91dCBhbiBhY2Nl c3MgZ3JhbnQgc2hvdWxkIG5vdCBpbmNsdWRlIGEgcmVmcmVzaCB0b2tlbi4gDUNoYW5nZWQgc2No ZW1lIG5hbWUgZnJvbSAnVG9rZW4nIHRvICdPQXV0aCcsIHNpbXBsaWZpZWQgcmVxdWVzdCBmb3Jt YXQgdG8gc2ltcGxlIHN0cmluZyBmb3IgdG9rZW4gaW5zdGVhZCBvZiBrZXk9dmFsdWUgcGFpciAo c3RpbGwgc3VwcG9ydGVkIGZvciBleHRlbnNpb25zKS4gDURlZmluZWQgcGVybWl0dGVkIGFjY2Vz cyB0b2tlbiBzdHJpbmcgY2hhcmFjdGVycyAoc3VpdGFibGUgZm9yIGluY2x1c2lvbiBpbiBhbiBI VFRQIGhlYWRlcikuIA1BZGRlZCBhIG5vdGUgYWJvdXQgY29uZmxpY3RzIHdpdGggcHJldmlvdXMg dmVyc2lvbnMuIA1Nb3ZlZCAnY2xpZW50X2lkJyBkZWZpbml0aW9uIGZyb20gY2xpZW50IGF1dGhl bnRpY2F0aW9uIHRvIGFjY2VzcyB0b2tlbiBlbmRwb2ludC4gDUFkZGVkIGRlZmluaXRpb24gZm9y ICdhY2Nlc3MgZ3JhbnQnLiANLTA5IA1GaXhlZCB0eXBvcywgZWRpdG9yaWFsIGNoYW5nZXMuIA1B ZGRlZCB0b2tlbiBleHBpcmF0aW9uIGV4YW1wbGUuIA1BZGRlZCBzY29wZSBwYXJhbWV0ZXIgdG8g ZW5kLXVzZXIgYXV0aG9yaXphdGlvbiBlbmRwb2ludCByZXNwb25zZS4gDUFkZGVkIG5vdGUgYWJv dXQgcGFyYW1ldGVycyB3aXRoIGVtcHR5IHZhbHVlcyAoc2FtZSBhcyBvbWl0dGVkKS4gDUNoYW5n ZWQgcGFyYW1ldGVyIHZhbHVlcyB0byB1c2UgJy0nIGluc3RlYWQgb2YgJ18nLiBQYXJhbWV0ZXIg bmFtZXMgc3RpbGwgdXNlICdfJy4gDUNoYW5nZWQgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBjbGll bnQgdHlwZSB0byByZXNwb25zZSB0eXBlIHdpdGggdmFsdWVzOiBjb2RlLCB0b2tlbiwgYW5kIGJv dGguIA1Db21wbGV0ZSBjbGVhbnVwIG9mIGVycm9yIGNvZGVzLiBBZGRlZCBzdXBwb3J0IGZvciBl cnJvciBkZXNjcmlwdGlvbiBhbmQgVVJJLiANQWRkIGluaXRpYWwgZXh0ZW5zaWJpbGl0eSBzdXBw b3J0LiANLTA4IA1SZW5hbWVkIHZlcmlmaWNhdGlvbiBjb2RlIHRvIGF1dGhvcml6YXRpb24gY29k ZS4gDVJldmlzZWQgdGVybWlub2xvZ3ksIHN0cnVjdHVyZWQgc2VjdGlvbiwgYWRkZWQgbmV3IHRl cm1zLiANQ2hhbmdlZCBmbG93cyB0byBwcm9maWxlcyBhbmQgbW92ZWQgdG8gaW50cm9kdWN0aW9u LiANQWRkZWQgc3VwcG9ydCBmb3IgYWNjZXNzIHRva2VuIHJlc2NvcGluZy4gDUNsZWFuZWQgdXAg Y2xpZW50IGNyZWRlbnRpYWxzIHNlY3Rpb24uIA1OZXcgaW50cm9kdWN0aW9uIG92ZXJ2aWV3LiAN QWRkZWQgZXJyb3IgY29kZSBmb3IgaW52YWxpZCB1c2VybmFtZSBhbmQgcGFzc3dvcmQsIGFuZCBy ZW5hbWVkIGVycm9yIGNvZGUgdG8gYmUgbW9yZSBjb25zaXN0ZW50LiANQWRkZWQgYWNjZXNzIGdy YW50IHR5cGUgcGFyYW1ldGVyIHRvIHRva2VuIGVuZHBvaW50LiANLTA3IA1NYWpvciByZXdyaXRl IG9mIGVudGlyZSBkb2N1bWVudCBzdHJ1Y3R1cmUuIA1SZW1vdmVkIGRldmljZSBwcm9maWxlLiAN QWRkZWQgdmVyaWZpY2F0aW9uIGNvZGUgc3VwcG9ydCB0byB1c2VyLWFnZW50IGZsb3cuIA1SZW1v dmVkIG11bHRpcGxlIGZvcm1hdHMgc3VwcG9ydCwgbGVhdmluZyBKU09OIGFzIHRoZSBvbmx5IGZv cm1hdC4gDUNoYW5nZWQgYXNzZXJ0aW9uIGFzc2VydGlvbl9mb3JtYXQgcGFyYW1ldGVyIHRvIGFz c2VydGlvbl90eXBlLiANUmVtb3ZlZCB0eXBlIHBhcmFtZXRlciBmcm9tIHRva2VuIGVuZHBvaW50 LiANLTA2IA1FZGl0b3JpYWwgY2hhbmdlcywgY29ycmVjdGlvbnMsIGNsYXJpZmljYXRpb25zLCBl dGMuIA1SZW1vdmVkIGNvbmZvcm1hbmNlIHNlY3Rpb24uIA1Nb3ZlZCBhdXRob3JzIHNlY3Rpb24g dG8gY29udHJpYnV0b3JzIGFwcGVuZGl4LiANQWRkZWQgc2VjdGlvbiBvbiBuYXRpdmUgYXBwbGlj YXRpb25zLiANQ2hhbmdlZCBlcnJvciByZXNwb25zZSB0byB1c2UgdGhlIHJlcXVlc3RlZCBmb3Jt YXQuIEFkZGVkIHN1cHBvcnQgZm9yIEhUVFAgQWNjZXB0IGhlYWRlci4gDUZsaXBwZWQgdGhlIG9y ZGVyIG9mIHRoZSB3ZWIgc2VydmVyIGFuZCB1c2VyLWFnZW50IGZsb3dzLiANUmVuYW1lZCBhc3Nl cnRpb24gZmxvdyBmb3JtYXQgcGFyYW1ldGVyIG5hbWUgdG8gYXNzZXJ0aW9uX2Zvcm1hdCB0byBy ZXNvbHZlIGNvbmZsaWN0LiANUmVtb3ZlZCB0aGUgdGVybSBpZGVudGlmaWVyIGZyb20gdG9rZW4g ZGVmaW5pdGlvbnMuIEFkZGVkIGEgY3J5cHRvZ3JhcGhpYyB0b2tlbiBkZWZpbml0aW9uLiANQWRk ZWQgZmlndXJlIHRpdGxlcy4gDUFkZGVkIHNlcnZlciByZXNwb25zZSA0MDEgd2hlbiBjbGllbnQg dHJpZWQgdG8gYXV0aGVudGljYXRlIHVzaW5nIG11bHRpcGxlIGNyZWRlbnRpYWxzLiANQ2xhcmlm aWVkIHN1cHBvcnQgZm9yIFRMUyBhbHRlcm5hdGl2ZXMsIGFuZCBhZGRlZCByZXF1aXJlbWVudCBm b3IgVExTIDEuMiBzdXBwb3J0IGZvciB0b2tlbiBlbmRwb2ludC4gDVJlbW92ZWQgYWxsIHNpZ25h dHVyZSBhbmQgY3J5cHRvZ3JhcGh5LiANUmVtb3ZlZCBhbGwgZGlzY292ZXJ5LiANVXBkYXRlZCBI VE1MNCByZWZlcmVuY2UuIA0tMDUgDUNvcnJlY3RlZCBkZXZpY2UgZXhhbXBsZS4gDUFkZGVkIGNs aWVudCBjcmVkZW50aWFscyBwYXJhbWV0ZXJzIHRvIHRoZSBhc3NlcnRpb24gZmxvdyBhcyBPUFRJ T05BTC4gDUFkZGVkIHRoZSBhYmlsaXR5IHRvIHNlbmQgY2xpZW50IGNyZWRlbnRpYWxzIHVzaW5n IGFuIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lLiANSW5pdGlhbCB0ZXh0IGZvciB0aGUgV1dX LUF1dGhlbnRpY2F0ZSBoZWFkZXIgKGFsc28gYWRkZWQgc2NvcGUgc3VwcG9ydCkuIA1DaGFuZ2Ug YXV0aG9yaXphdGlvbiBlbmRwb2ludCB0byBlbmQtdXNlciBlbmRwb2ludC4gDUluIHRoZSBkZXZp Y2UgZmxvdywgY2hhbmdlIHRoZSB1c2VyX3VyaSBwYXJhbWV0ZXIgdG8gdmVyaWZpY2F0aW9uX3Vy aSB0byBhdm9pZCBjb25mdXNpb24gd2l0aCB0aGUgZW5kLXVzZXIgZW5kcG9pbnQuIA1BZGQgZm9y bWF0IHJlcXVlc3QgcGFyYW1ldGVyIGFuZCBzdXBwb3J0IGZvciBYTUwgYW5kIGZvcm0tZW5jb2Rl ZCByZXNwb25zZXMuIA0tMDQgDUNoYW5nZWQgYWxsIHRva2VuIGVuZHBvaW50cyB0byB1c2UgUE9T VCANQ2xhcmlmaWVkIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlcidzIGFiaWxpdHkgdG8gaXNzdWUg YSBuZXcgcmVmcmVzaCB0b2tlbiB3aGVuIHJlZnJlc2hpbmcgYSB0b2tlbi4gDUNoYW5nZWQgdGhl IGZsb3cgY2F0ZWdvcmllcyB0byBjbGFyaWZ5IHRoZSBhdXRvbm9tb3VzIGdyb3VwLiANQ2hhbmdl ZCBjbGllbnQgY3JlZGVudGlhbHMgbGFuZ3VhZ2Ugbm90IHRvIGFsd2F5cyBiZSBzZXJ2ZXItaXNz dWVkLiANQWRkZWQgYSBzY29wZSByZXNwb25zZSBwYXJhbWV0ZXIuIA1GaXhlZCB0eXBvcy4gDUZp eGVkIGJyb2tlbiBkb2N1bWVudCBzdHJ1Y3R1cmUuIA0tMDMgDUZpeGVkIHR5cG8gaW4gSlNPTiBl cnJvciBleGFtcGxlcy4gDUZpeGVkIGdlbmVyYWwgdHlwb3MuIA1Nb3ZlZCBhbGwgZmxvd3Mgc2Vj dGlvbnMgdXAgb25lIGxldmVsLiANLTAyIA1SZW1vdmVkIHJlc3RyaWN0aW9uIG9uIHJlZGlyZWN0 X3VyaSBpbmNsdWRpbmcgYSBxdWVyeS4gDUFkZGVkIHNjb3BlIHBhcmFtZXRlci4gDUluaXRpYWwg cHJvcG9zYWwgZm9yIGEgSlNPTi1iYXNlZCB0b2tlbiByZXNwb25zZSBmb3JtYXQuIA0tMDEgDUVk aXRvcmlhbCBjaGFuZ2VzIGJhc2VkIG9uIGZlZWRiYWNrIGZyb20gQnJpYW4gRWF0b24sIEJpbGwg S2VlbmFuLCBhbmQgQ2h1Y2sgTW9ydGltb3JlLiANQ2hhbmdlZCBkZXZpY2UgZmxvdyB0eXBlIHBh cmFtZXRlciB2YWx1ZXMgYW5kIHN3aXRjaCB0byB1c2Ugb25seSB0aGUgdG9rZW4gZW5kcG9pbnQu IA0tMDAgDUluaXRpYWwgZHJhZnQgYmFzZWQgb24gYSBjb21iaW5hdGlvbiBvZiBXUkFQIGFuZCBP QXV0aCAxLjBhLiANDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHMTAuoCBSZWZlcmVu Y2VzDQ0BDRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzEwLjEuoE5vcm1hdGl2ZSBSZWZl cmVuY2VzDVtJLUQuaWV0Zi1odHRwYmlzLXAxLW1lc3NhZ2luZ10HRmllbGRpbmcsIFIuLCBHZXR0 eXMsIEouLCBNb2d1bCwgSi4sIE5pZWxzZW4sIEguLCBNYXNpbnRlciwgTC4sIExlYWNoLCBQLiwg QmVybmVycy1MZWUsIFQuLCBhbmQgSi4gUmVzY2hrZSwgkxMgSFlQRVJMSU5LICJodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWh0dHBiaXMtcDEtbWVzc2FnaW5n LTA5LnR4dCIgFEhUVFAvMS4xLCBwYXJ0IDE6IFVSSXMsIENvbm5lY3Rpb25zLCBhbmQgTWVzc2Fn ZSBQYXJzaW5nFSyUIGRyYWZ0LWlldGYtaHR0cGJpcy1wMS1tZXNzYWdpbmctMDkgKHdvcmsgaW4g cHJvZ3Jlc3MpLCBNYXJjaKAyMDEwICgTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1odHRwYmlzLXAxLW1lc3NhZ2luZy0wOS50eHQiIBRU WFQVKS4HB1tSRkMyMDQ1XQcTIEhZUEVSTElOSyAibWFpbHRvOm5lZEBpbm5vc29mdC5jb20iIBRG cmVlZCwgTi4VIGFuZCATIEhZUEVSTElOSyAibWFpbHRvOm5zYkBuc2IuZnYuY29tIiAUTi4gQm9y ZW5zdGVpbhUsIJMTIEhZUEVSTElOSyAiaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjA0 NSIgFE11bHRpcHVycG9zZSBJbnRlcm5ldCBNYWlsIEV4dGVuc2lvbnMgKE1JTUUpIFBhcnQgT25l OiBGb3JtYXQgb2YgSW50ZXJuZXQgTWVzc2FnZSBCb2RpZXMVLJQgUkZDoDIwNDUsIE5vdmVtYmVy oDE5OTYgKBMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyMDQ1 LnR4dCIgFFRYVBUpLgcHW1JGQzIxMTldBxMgSFlQRVJMSU5LICJtYWlsdG86c29iQGhhcnZhcmQu ZWR1IiAUQnJhZG5lciwgUy4VLCCTEyBIWVBFUkxJTksgImh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzIxMTkiIBRLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlIFJlcXVp cmVtZW50IExldmVscxUslCBCQ1CgMTQsIFJGQ6AyMTE5LCBNYXJjaKAxOTk3ICgTIEhZUEVSTElO SyAiaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjMjExOS50eHQiIBRUWFQVLCATIEhZ UEVSTElOSyAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGljL3JmYy9odG1sL3JmYzIxMTku aHRtbCIgFEhUTUwVLCATIEhZUEVSTElOSyAiaHR0cDovL3htbC5yZXNvdXJjZS5vcmcvcHVibGlj L3JmYy94bWwvcmZjMjExOS54bWwiIBRYTUwVKS4HB1tSRkMyNjE2XQcTIEhZUEVSTElOSyAibWFp bHRvOmZpZWxkaW5nQGljcy51Y2kuZWR1IiAURmllbGRpbmcsIFIuFSwgEyBIWVBFUkxJTksgIm1h aWx0bzpqZ0B3My5vcmciIBRHZXR0eXMsIEouFSwgEyBIWVBFUkxJTksgIm1haWx0bzptb2d1bEB3 cmwuZGVjLmNvbSIgFE1vZ3VsLCBKLhUsIBMgSFlQRVJMSU5LICJtYWlsdG86ZnJ5c3R5a0B3My5v cmciIBRGcnlzdHlrLCBILhUsIBMgSFlQRVJMSU5LICJtYWlsdG86bWFzaW50ZXJAcGFyYy54ZXJv eC5jb20iIBRNYXNpbnRlciwgTC4VLCATIEhZUEVSTElOSyAibWFpbHRvOnBhdWxsZUBtaWNyb3Nv ZnQuY29tIiAUTGVhY2gsIFAuFSwgYW5kIBMgSFlQRVJMSU5LICJtYWlsdG86dGltYmxAdzMub3Jn IiAUVC4gQmVybmVycy1MZWUVLCCTEyBIWVBFUkxJTksgImh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzI2MTYiIBRIeXBlcnRleHQgVHJhbnNmZXIgUHJvdG9jb2wgLS0gSFRUUC8xLjEVLJQg UkZDoDI2MTYsIEp1bmWgMTk5OSAoEyBIWVBFUkxJTksgImh0dHA6Ly93d3cucmZjLWVkaXRvci5v cmcvcmZjL3JmYzI2MTYudHh0IiAUVFhUFSwgEyBIWVBFUkxJTksgImh0dHA6Ly93d3cucmZjLWVk aXRvci5vcmcvcmZjL3JmYzI2MTYucHMiIBRQUxUsIBMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL3JmYy9yZmMyNjE2LnBkZiIgFFBERhUsIBMgSFlQRVJMSU5LICJodHRwOi8v eG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZjMjYxNi5odG1sIiAUSFRNTBUsIBMg SFlQRVJMSU5LICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL3htbC9yZmMyNjE2 LnhtbCIgFFhNTBUpLgcHW1JGQzI2MTddBxMgSFlQRVJMSU5LICJtYWlsdG86am9obkBtYXRoLm53 dS5lZHUiIBRGcmFua3MsIEouFSwgEyBIWVBFUkxJTksgIm1haWx0bzpwYmFrZXJAdmVyaXNpZ24u Y29tIiAUSGFsbGFtLUJha2VyLCBQLhUsIBMgSFlQRVJMSU5LICJtYWlsdG86amVmZkBBYmlTb3Vy Y2UuY29tIiAUSG9zdGV0bGVyLCBKLhUsIBMgSFlQRVJMSU5LICJtYWlsdG86bGF3cmVuY2VAYWdy YW5hdC5jb20iIBRMYXdyZW5jZSwgUy4VLCATIEhZUEVSTElOSyAibWFpbHRvOnBhdWxsZUBtaWNy b3NvZnQuY29tIiAUTGVhY2gsIFAuFSwgTHVvdG9uZW4sIEEuLCBhbmQgEyBIWVBFUkxJTksgIm1h aWx0bzpzdGV3YXJ0QE9wZW5NYXJrZXQuY29tIiAUTC4gU3Rld2FydBUsIJMTIEhZUEVSTElOSyAi aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjYxNyIgFEhUVFAgQXV0aGVudGljYXRpb246 IEJhc2ljIGFuZCBEaWdlc3QgQWNjZXNzIEF1dGhlbnRpY2F0aW9uFSyUIFJGQ6AyNjE3LCBKdW5l oDE5OTkgKBMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyNjE3 LnR4dCIgFFRYVBUsIBMgSFlQRVJMSU5LICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMv cmZjL2h0bWwvcmZjMjYxNy5odG1sIiAUSFRNTBUsIBMgSFlQRVJMSU5LICJodHRwOi8veG1sLnJl c291cmNlLm9yZy9wdWJsaWMvcmZjL3htbC9yZmMyNjE3LnhtbCIgFFhNTBUpLgcHW1JGQzI4MThd B1Jlc2NvcmxhLCBFLiwgkxMgSFlQRVJMSU5LICJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmMyODE4IiAUSFRUUCBPdmVyIFRMUxUslCBSRkOgMjgxOCwgTWF5oDIwMDAgKBMgSFlQRVJMSU5L ICJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMyODE4LnR4dCIgFFRYVBUpLgcHW1JG QzI4MjhdB1NoaXJleSwgUi4sIJMTIEhZUEVSTElOSyAiaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjMjgyOCIgFEludGVybmV0IFNlY3VyaXR5IEdsb3NzYXJ5FSyUIFJGQ6AyODI4LCBNYXmg MjAwMCAoEyBIWVBFUkxJTksgImh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjL3JmYzI4Mjgu dHh0IiAUVFhUFSkuBwdbUkZDMzAyM10HTXVyYXRhLCBNLiwgU3QuIExhdXJlbnQsIFMuLCBhbmQg RC4gS29obiwgkxMgSFlQRVJMSU5LICJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzMDIz IiAUWE1MIE1lZGlhIFR5cGVzFSyUIFJGQ6AzMDIzLCBKYW51YXJ5oDIwMDEgKBMgSFlQRVJMSU5L ICJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzMDIzLnR4dCIgFFRYVBUpLgcHW1JG QzM0NDddB0pvbnNzb24sIEouIGFuZCBCLiBLYWxpc2tpLCCTEyBIWVBFUkxJTksgImh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzM0NDciIBRQdWJsaWMtS2V5IENyeXB0b2dyYXBoeSBTdGFu ZGFyZHMgKFBLQ1MpICMxOiBSU0EgQ3J5cHRvZ3JhcGh5IFNwZWNpZmljYXRpb25zIFZlcnNpb24g Mi4xFSyUIFJGQ6AzNDQ3LCBGZWJydWFyeaAyMDAzICgTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5y ZmMtZWRpdG9yLm9yZy9yZmMvcmZjMzQ0Ny50eHQiIBRUWFQVKS4HB1tSRkMzNjI5XQdZZXJnZWF1 LCBGLiwgkxMgSFlQRVJMSU5LICJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNjI5IiAU VVRGLTgsIGEgdHJhbnNmb3JtYXRpb24gZm9ybWF0IG9mIElTTyAxMDY0NhUslCBTVESgNjMsIFJG Q6AzNjI5LCBOb3ZlbWJlcqAyMDAzICgTIEhZUEVSTElOSyAiaHR0cDovL3d3dy5yZmMtZWRpdG9y Lm9yZy9yZmMvcmZjMzYyOS50eHQiIBRUWFQVKS4HB1tSRkMzOTg2XQcTIEhZUEVSTElOSyAibWFp bHRvOnRpbWJsQHczLm9yZyIgFEJlcm5lcnMtTGVlLCBULhUsIBMgSFlQRVJMSU5LICJtYWlsdG86 ZmllbGRpbmdAZ2Jpdi5jb20iIBRGaWVsZGluZywgUi4VLCBhbmQgEyBIWVBFUkxJTksgIm1haWx0 bzpMTU1AYWNtLm9yZyIgFEwuIE1hc2ludGVyFSwgkxMgSFlQRVJMSU5LICJodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmMzOTg2IiAUVW5pZm9ybSBSZXNvdXJjZSBJZGVudGlmaWVyIChVUkkp OiBHZW5lcmljIFN5bnRheBUslCBTVESgNjYsIFJGQ6AzOTg2LCBKYW51YXJ5oDIwMDUgKBMgSFlQ RVJMSU5LICJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmMzOTg2LnR4dCIgFFRYVBUs IBMgSFlQRVJMSU5LICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9wdWJsaWMvcmZjL2h0bWwvcmZj Mzk4Ni5odG1sIiAUSFRNTBUsIBMgSFlQRVJMSU5LICJodHRwOi8veG1sLnJlc291cmNlLm9yZy9w dWJsaWMvcmZjL3htbC9yZmMzOTg2LnhtbCIgFFhNTBUpLgcHW1JGQzQ2MjddB0Nyb2NrZm9yZCwg RC4sIJMTIEhZUEVSTElOSyAiaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDYyNyIgFFRo ZSBhcHBsaWNhdGlvbi9qc29uIE1lZGlhIFR5cGUgZm9yIEphdmFTY3JpcHQgT2JqZWN0IE5vdGF0 aW9uIChKU09OKRUslCBSRkOgNDYyNywgSnVseaAyMDA2ICgTIEhZUEVSTElOSyAiaHR0cDovL3d3 dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNDYyNy50eHQiIBRUWFQVKS4HB1tSRkM1MjI2XQdOYXJ0 ZW4sIFQuIGFuZCBILiBBbHZlc3RyYW5kLCCTEyBIWVBFUkxJTksgImh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzUyMjYiIBRHdWlkZWxpbmVzIGZvciBXcml0aW5nIGFuIElBTkEgQ29uc2lk ZXJhdGlvbnMgU2VjdGlvbiBpbiBSRkNzFSyUIEJDUKAyNiwgUkZDoDUyMjYsIE1heaAyMDA4ICgT IEhZUEVSTElOSyAiaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjNTIyNi50eHQiIBRU WFQVKS4HB1tSRkM1MjQ2XQdEaWVya3MsIFQuIGFuZCBFLiBSZXNjb3JsYSwgkxMgSFlQRVJMSU5L ICJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1MjQ2IiAUVGhlIFRyYW5zcG9ydCBMYXll ciBTZWN1cml0eSAoVExTKSBQcm90b2NvbCBWZXJzaW9uIDEuMhUslCBSRkOgNTI0NiwgQXVndXN0 oDIwMDggKBMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM1MjQ2 LnR4dCIgFFRYVBUpLgcHW1JGQzU4NDldB0hhbW1lci1MYWhhdiwgRS4sIJMTIEhZUEVSTElOSyAi aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg0OSIgFFRoZSBPQXV0aCAxLjAgUHJvdG9j b2wVLJQgUkZDoDU4NDksIEFwcmlsoDIwMTAgKBMgSFlQRVJMSU5LICJodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL3JmYy9yZmM1ODQ5LnR4dCIgFFRYVBUpLgcHW1czQy5SRUMtaHRtbDQwMS0xOTk5 MTIyNF0HUmFnZ2V0dCwgRC4sIEhvcnMsIEEuLCBhbmQgSS4gSmFjb2JzLCCTEyBIWVBFUkxJTksg Imh0dHA6Ly93d3cudzMub3JnL1RSLzE5OTkvUkVDLWh0bWw0MDEtMTk5OTEyMjQiIBRIVE1MIDQu MDEgU3BlY2lmaWNhdGlvbhUslCBXb3JsZCBXaWRlIFdlYiBDb25zb3J0aXVtIFJlY29tbWVuZGF0 aW9uoFJFQy1odG1sNDAxLTE5OTkxMjI0LCBEZWNlbWJlcqAxOTk5ICgTIEhZUEVSTElOSyAiaHR0 cDovL3d3dy53My5vcmcvVFIvMTk5OS9SRUMtaHRtbDQwMS0xOTk5MTIyNCIgFEhUTUwVKS4HBw0B DRMgSFlQRVJMSU5LIFxsICJ0b2MiIBSgVE9DoBUHBzEwLjIuoEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMNW09BU0lTLnNhbWwtY29yZS0yLjAtb3NdBxMgSFlQRVJMSU5LICJtYWlsdG86Y2FudG9yLjJA b3N1LmVkdSIgFENhbnRvciwgUy4VLCATIEhZUEVSTElOSyAibWFpbHRvOkpvaG4uS2VtcEBub2tp YS5jb20iIBRLZW1wLCBKLhUsIBMgSFlQRVJMSU5LICJtYWlsdG86cnBoaWxwb3R0QHJzYXNlY3Vy aXR5LmNvbSIgFFBoaWxwb3R0LCBSLhUsIGFuZCATIEhZUEVSTElOSyAibWFpbHRvOmV2ZS5tYWxl ckBzdW4uY29tIiAURS4gTWFsZXIVLCCTEyBIWVBFUkxJTksgImh0dHA6Ly9kb2NzLm9hc2lzLW9w ZW4ub3JnL3NlY3VyaXR5L3NhbWwvdjIuMC9zYW1sLWNvcmUtMi4wLW9zLnBkZiIgFEFzc2VydGlv bnMgYW5kIFByb3RvY29sIGZvciB0aGUgT0FTSVMgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBM YW5ndWFnZSAoU0FNTCkgVjIuMBUslCBPQVNJUyBTdGFuZGFyZKBzYW1sLWNvcmUtMi4wLW9zLCBN YXJjaKAyMDA1LgcHDQENEyBIWVBFUkxJTksgXGwgInRvYyIgFKBUT0OgFQcHQXV0aG9ycycgQWRk cmVzc2VzDaAHRXJhbiBIYW1tZXItTGFoYXYgKGVkaXRvcikHB6AHWWFob28hBwdFbWFpbDqgBxMg SFlQRVJMSU5LICJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSIgFGVyYW5AaHVlbml2ZXJzZS5j b20VBwdVUkk6oAcTIEhZUEVSTElOSyAiaHR0cDovL2h1ZW5pdmVyc2UuY29tIiAUaHR0cDovL2h1 ZW5pdmVyc2UuY29tFQcHoAegBwegB0RhdmlkIFJlY29yZG9uBwegB0ZhY2Vib29rBwdFbWFpbDqg BxMgSFlQRVJMSU5LICJtYWlsdG86ZGF2aWRyZWNvcmRvbkBmYWNlYm9vay5jb20iIBRkYXZpZHJl Y29yZG9uQGZhY2Vib29rLmNvbRUHB1VSSTqgBxMgSFlQRVJMSU5LICJodHRwOi8vd3d3LmRhdmlk cmVjb3Jkb24uY29tLyIgFGh0dHA6Ly93d3cuZGF2aWRyZWNvcmRvbi5jb20vFQcHoAegBwegB0Rp Y2sgSGFyZHQHB6AHTWljcm9zb2Z0BwdFbWFpbDqgBxMgSFlQRVJMSU5LICJtYWlsdG86ZGljay5o YXJkdEBnbWFpbC5jb20iIBRkaWNrLmhhcmR0QGdtYWlsLmNvbRUHB1VSSTqgBxMgSFlQRVJMSU5L ICJodHRwOi8vZGlja2hhcmR0Lm9yZy8iIBRodHRwOi8vZGlja2hhcmR0Lm9yZy8VBwcNAw0NBA0N Aw0NBA0NDQ0NDQ0NDQ0NDQ0NDQVPcHRpb25hbGx5IGRlbm90ZXMgYSBzcGVjaWZpYyBzY29wZQ0F SSBkb26SdCBiZWxpdmUgdGhhdCBpdCBtdXN0IGJlIGEgM3JkIHBhcnR5IGNsaWVudCBhcyB0aGUg Y2xpZW50IGNvdWxmIGJlIHRoZSBvbmUgdGhhdCByZXF1ZXN0IHRoZSBhY2Nlc3MgdG9rZW4NBVNo b3VsZCBub3QgaGVyZSB0aGF0IGluIHRoaXMgc3BlY2lmaWNhdGlvbiB3ZSBkb26SdCBwcmVzY3Jp YmUgYSBwYXJ0aWN1bGFyIGFjY2VzcyB0b2tlbiBmb3JtYXQgYW5kIGVuY29kaW5nDQVTaG91bGQg YmUgk2F1dGhvcml6YXRpb24gKGFjZXNzIGdyYW50KSBjb2RllA0FVGhpcyBzaG91bGQgYmUgk2F1 dGhvcml6YXRpb24gY29kZZQNBVRoaXMgbWF5IGFsc28gYmUgYSAgk2F1dGhvcml6YXRpb24gY29k ZZQNDQVUaGlzIG1heSBhbHNvIGJlIGEgIJNhdXRob3JpemF0aW9uIGNvZGWUDQ0FVGhpcyBtYXkg YWxzbyBiZSBhICCTYXV0aG9yaXphdGlvbiBjb2RllA0NBVRoaXMgc2VlbXMgYW4gb2RkIHNlY3Rp b24gYXMgdGhlcmUgaXMgbm8gc3RhbmRhcmQgZm9ybWF0IG9yIGVuY29kaW5nIGRlc2NyaWJlZCBm b3IgdXNlcm5hbWUvcGFzc3dvcmQgYW5kIHRoaXMgc2VlbXMgdG8gYmUgbW9yZSBhYm91dCBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgbWF5IGJlIGJlc3QgbW92ZWQgdGhlcmUNBVRoaXMgc2hv dWxkIGJlIHNvbWV0aGluZyB0aGF0IDI5MTE1IHN1cHBvcnRzIGFzIE1VU1QsIFNIQUwsIE1heSwg ZXRjIGJ1dCBub3QgY2FuDQVUaGUgYWNjZXNzIGdyYW50IGNhbiBiZSB0aGUgY3JlZGVudGlhbHMg KHVzZXIgbmFtZS9wYXNzd29yZCkgc28gc3VnZ2VzdCB0aGF0IHRoaXMgYmUgk2NsaWVudCBjcmVk ZW50aWFscyBhbmQvb3IgYWNjZXNzIGdyYW50lA0FVGhpcyBpcyBvcGlvbmFsDQVUaGlzIHRlcm0g aGFzIG5vdCBiZWVuIGRlZmluZWQgYW5kIGl0cyBjb25mdXNpbmcsIGFsc28gbm90IHN1cmUgdGhh dCB0aGlzIGhhcyB0byBiZSB0aGUgZW5kLXVzZXKScyBpdCBqdXN0IG5lZWRzIHRvIGJlIGEgdXNl ciBhZ2VudCBhY3Rpbmcgb24gYmVoYWxmIG9mIHRoZSBlbmQtdXNlcg0FTmVkIHRoaXMgZGVmaW5l ZA0FVGhpcyBkb2VzIG5vdCBoYXZlIHRvIGJlIG5hdGl2ZSBjb2RlIGJ1dCBqdXN0IGhhcyB0byBi ZSB3aXRoaW5nIHRoZSBwcm9jZXNzIGJvdW5kcnkgb2YgdGhlIGVuZCB1c2VyIGRldmljZQ0FTUFZ DQVNQVkNBU1BWQ0FRGVsZXRlIGFzIHRoaXMgdGhpcyBlbHVkZXMgdG8gT0lYIHR5cGVzIG9mIGZy YW1ld29ya3MNBVRoaXMgd291bGQgc2VlbSB0byBjb25mbGljdCB3aXRoIEpXVCBhbmQgd2hhdCBp cyBwbGFjZWQgaW4gdGhlIGJvZHkNBZNNaWtlIEpvbmVzlCBpcyB3YXkgdG9vIGNvbW1vbiBhIG5h bWUhDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CAAAAQgAABgIAAAZCAAAGggAAB0IAAAeCAAAHwgAACAIAAAhCAAANggAADcIAABLCAAATAgAAE0I AABbCAAAXAgAAGIIAABjCAAAZAgAAG8IAABwCAAAoAgAAKEIAAClCAAApggAALQIAAC1CAAA7N3s ybbJ7KegjnyOfKCOfI58oI5xanFaRo58ACcDagAAAAAWaBo38gAwSg8AQ0oUAE9KAgBRSgIAVQgB XkoCAGFKFAAeFmhFRmsAMEoPAENKFABPSgIAUUoCAF5KAgBhShQAAAwVaHZMdwAWaBo38gAAFQNq AAAAABVodkx3ABZoGjfyAFUIASMWaNpY9wBCKghDShQAT0oCAFFKAgBeSgIAYUoUAHBo////ACMW aEVGawBCKghDShQAT0oCAFFKAgBeSgIAYUoUAHBo////AAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo 2lj3AEIqCE9KAwBRSgMAcGj///8AJBVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAHBo//// AAAnFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAbygBcGj///8AHRVodkx3ABZoRUZrAEIq CE9KAwBRSgMAcGj///8AJgNqAAAAABVodkx3ABZoRUZrAEIqCE9KAwBRSgMAVQgBcGj///8AGwAI AAAgCAAAIQgAADcIAABMCAAA4AAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAA cQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAA E6QAABSkAAAWJAFJZgIAAABbJABcJABLJAFgAABrZAAAAAAWJAEXJAFJZgEAAABlZEtM1jcHlOEA CNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLW CgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/x6ULQAz 1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAAAAAfAAADJAESZOEA AAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAWdkb2geAAAETAgA AE0IAABcCAAAYwgAAIwAAAAAAAAAAAAAAAB9AAAAAAAAAAAAAAAAfQAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAOAAATpAAAFKQAABYkAUlmAgAAAFskAFwkAEskAXMAAGtkmAAA ABYkAUlmAgAAAEskAUwkAQKWHgAI1jAAAgAAEQwiGABEcgYAAAAAAAAAAAAAAAAAAAAAAERyBgAA AAAAAAAAAAAAAAAAAAAJ1gTgAeABCnQAAKAEEtYUAAAA/2ZmZgAAAAAAAP9mZmYAAAAU9gKIExU2 ARf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP8z1gYAAQ8D BwA01gYAAQ8DHgBC1gMAAgFh9gMAAHDWFAAAAP9mZmYAAAAAAAD/ZmZmAAAAeXRvaB4AAANjCAAA ZAgAALUIAADBCAAAjAAAAAAAAAAAAAAAAH0AAAAAAAAAAAAAAAB9AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA4AABOkAAAUpAAAFiQBSWYCAAAAWyQAXCQASyQBcwAAa2QqAQAA FiQBSWYCAAAASyQBTCQBApYeAAjWMAACAAARDCIYAERyBgAAAAAAAAAAAAAAAAAAAAAARHIGAAAA AAAAAAAAAAAAAAAAAAnWBOAB4AEKdAAAoAQS1hQAAAD/ZmZmAAAAAAAA/2ZmZgAAABT2AogTFTYB F/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zPWBgABDwMH ADTWBgABDwMeAELWAwACAWH2AwAAcNYUAAAA/2ZmZgAAAAAAAP9mZmYAAAB5dG9oHgAAA7UIAADA CAAAwQgAAMIIAADiCAAA4wgAAOsIAADsCAAA7QgAAAIJAAADCQAACwkAAAwJAAANCQAADgkAAA8J AAAYCQAAGQkAABoJAAAbCQAAHAkAACwJAAAtCQAALgkAAC8JAAAwCQAAaAkAAGkJAABxCQAAcgkA AKUJAACvCQAAsQkAALIJAADFCQAAxgkAACQKAAAlCgAAIQsAACILAAAlDAAAJgwAAEkMAABPDAAA VgwAAFcMAABnDAAAaAwAAM4MAADPDAAA5A4AAO3b1O3b7dvU7dvt29Tt2+3b1O3b7dvUxdS9tb21 opKif721on+if6J/opKif721on+iJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNI CQAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAWaEVGawBCKgFPSgMAUUoD AG1ICQBwaAAAAABzSAkADhZo2lj3AG1ICQBzSAkAAA4WaEVGawBtSAkAc0gJAAAdFWh2THcAFmja WPcAQioBT0oDAFFKAwBwaAAAAAAMFWh2THcAFmjaWPcAACMWaNpY9wBCKghDShQAT0oCAFFKAgBe SgIAYUoUAHBo////ACMWaEVGawBCKghDShQAT0oCAFFKAgBeSgIAYUoUAHBo////AAAywQgAAMII AADjCAAA7AgAAIwAAAAAAAAAAAAAAAB9AAAAAAAAAAAAAAAAfQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAOAAATpAAAFKQAABYkAUlmAgAAAFskAFwkAEskAXMAAGtkvAEAABYk AUlmAgAAAEskAUwkAQKWHgAI1jAAAgAAEQwiGABEcgYAAAAAAAAAAAAAAAAAAAAAAERyBgAAAAAA AAAAAAAAAAAAAAAJ1gTgAeABCnQAAKAEEtYUAAAA/2ZmZgAAAAAAAP9mZmYAAAAU9gKIExU2ARf2 AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP8z1gYAAQ8DBwA0 1gYAAQ8DHgBC1gMAAgFh9gMAAHDWFAAAAP9mZmYAAAAAAAD/ZmZmAAAAeXRvaB4AAAPsCAAA7QgA AAMJAAAMCQAAjAAAAAAAAAAAAAAAAH0AAAAAAAAAAAAAAAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA4AABOkAAAUpAAAFiQBSWYCAAAAWyQAXCQASyQBcwAAa2ROAgAAFiQB SWYCAAAASyQBTCQBApYeAAjWMAACAAARDCIYAERyBgAAAAAAAAAAAAAAAAAAAAAARHIGAAAAAAAA AAAAAAAAAAAAAAnWBOAB4AEKdAAAoAQS1hQAAAD/ZmZmAAAAAAAA/2ZmZgAAABT2AogTFTYBF/YD AAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zPWBgABDwMHADTW BgABDwMeAELWAwACAWH2AwAAcNYUAAAA/2ZmZgAAAAAAAP9mZmYAAAB5dG9oHgAAAwwJAAANCQAA DwkAABkJAACPAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAE6QAABSkAAAWJAFJZgIAAABbJABcJABLJAFwAABrZOAC AAAWJAFJZgIAAABLJAFMJAEClh4ACNYwAAIAABEMIhgARHIGAAAAAAAAAAAAAAAAAAAAAABEcgYA AAAAAAAAAAAAAAAAAAAACdYE4AHgAQp0AACgBBLWFAAAAP9mZmYAAAAAAAD/ZmZmAAAAFPYCiBMV NgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEP AwcANNYGAAEPAx4AQtYDAAIBYfYDAABw1hQAAAD/ZmZmAAAAAAAA/2ZmZgAAAAADGQkAABoJAAAc CQAALQkAAIwAAAAAAAAAAAAAAAB9AAAAAAAAAAAAAAAAfQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAOAAATpAAAFKQAABYkAUlmAgAAAFskAFwkAEskAXMAAGtkbAMAABYkAUlm AgAAAEskAUwkAQKWHgAI1jAAAgAAEQwiGABEcgYAAAAAAAAAAAAAAAAAAAAAAERyBgAAAAAAAAAA AAAAAAAAAAAJ1gTgAeABCnQAAKAEEtYUAAAA/2ZmZgAAAAAAAP9mZmYAAAAU9gKIExU2ARf2AwAA GtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP8z1gYAAQ8DBwA01gYA AQ8DHgBC1gMAAgFh9gMAAHDWFAAAAP9mZmYAAAAAAAD/ZmZmAAAAeXRvaB4AAAMtCQAALgkAAC8J AAAwCQAAaQkAAHIJAACPAAAAAAAAAAAAAAAAggAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA4AAAA AAAAAAAAAAAAMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAMAZWRLTNY3AAQBAGVkS0zWN0UA AGtkigQAABYkARckAUlmAQAAAGVkS0zWNwjWGgABAAAiGIBCAAAAAAAAAAAAAAAAAAAAAAAACnQA AKAEFPYC5AwVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8z1gYAAQ8DAAA01gYA AQ8DAABC1gMAAQFh9gMAAGl0S0zWNw0AABOkAAAUpAAAFiQBSWYBAAAAWyQAXCQAcAAAa2T+AwAA FiQBSWYCAAAASyQBTCQBApYeAAjWMAACAAARDCIYAERyBgAAAAAAAAAAAAAAAAAAAAAARHIGAAAA AAAAAAAAAAAAAAAAAAnWBOAB4AEKdAAAoAQS1hQAAAD/ZmZmAAAAAAAA/2ZmZgAAABT2AogTFTYB F/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zPWBgABDwMH ADTWBgABDwMeAELWAwACAWH2AwAAcNYUAAAA/2ZmZgAAAAAAAP9mZmYAAAAABXIJAACyCQAAxgkA ACUKAAAiCwAAJgwAAFcMAABoDAAAzwwAAOUOAADmDgAA6A4AAPoOAAAmHAAAKBwAACocAABHHAAA +gAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOkA AAAAAAAAAAAAAADpAAAAAAAAAAAAAAAAxQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfAAADJAESZOEAAAATpAAA FKQAABYkARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAWdkb2geAAAEIABlZEtM1jcA CwAAE6QAABSkAABbJABcJABlZEtM1jcABAMAZWRLTNY3AAQeAGVkS0zWNwAQ5A4AAOYOAADnDgAA 6A4AAPkOAAD6DgAA+w4AABMPAAAUDwAAFg8AABcPAAAqDwAAKw8AAEMPAABEDwAASA8AAEkPAABm DwAAZw8AAH8PAACADwAAhA8AAIUPAACXDwAAmA8AALAPAACxDwAAtQ8AALYPAADFDwAAxg8AAN4P AADfDwAA4w8AAOQPAADmDwAA8w8AAPwPAAD9DwAAFRAAABYQAAAcEAAAHRAAAB8QAAA6EAAA7Nfs z8e/u7+plYK/u7+plYK/u7+plYK/u7+plYK/u7+plYJygr+7v6mVgnIAAAAAHxZoRUZrAEIqAU9K AwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJ ACYDagAAAAAWaBo38gAwSg8ANQiBT0oDAFFKAwBVCAFtSAkAc0gJAAAjFWhvaB4AFmhFRmsAMEoP ADUIgU9KAwBRSgMAbUgJAHNICQAGFmgaN/IAAA8DagAAAAAWaBo38gBVCAEOFmjaWPcAbUgJAHNI CQAADhZoRUZrAG1ICQBzSAkAACgDaugEAAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABz SAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAACw6EAAAOxAAAFMQAABU EAAAWhAAAFsQAACJEAAAihAAAKIQAACjEAAAqRAAAKoQAADHEAAAyBAAAOAQAADhEAAA5xAAAOgQ AAAAEQAAAREAABoRAAAbEQAAIREAACIRAAAuEQAALxEAAEgRAABJEQAASxEAAEwRAABiEQAAYxEA AHwRAAB9EQAAgREAAIIRAACEEQAAkxEAAJQRAACvEQAAsBEAALERAAC0EQAAtREAAMYRAADHEQAA 4BEAAOERAADlEQAA5hEAAP8RAAAAEgAAGRIAAPfz9+LNvffz9+LNvffz9+LNvffz9+LNvffz9+LN vffz9+LNvar38/fimISq9/P34s2q9/MmA2oAAAAAFmgaN/IAMEoPADUIgU9KAwBRSgMAVQgBbUgJ AHNICQAAIxVob2geABZoRUZrADBKDwA1CIFPSgMAUUoDAG1ICQBzSAkAJRVob2geABZoRUZrAEIq AU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACkD agAAAAAWaBo38gAwSg8ANQiBT0oDAFFKAwBVCAFcCIFtSAkAc0gJACAWaEVGawAwSg8ANQiBT0oD AFFKAwBcCIFtSAkAc0gJAAAGFmgaN/IAAA8DagAAAAAWaBo38gBVCAEANBkSAAAaEgAAHhIAAB8S AAAsEgAALRIAAFMSAABUEgAAVRIAAFYSAABXEgAAYBIAAHASAABxEgAAihIAAIsSAACPEgAAkBIA ALISAACzEgAAzBIAAM0SAADREgAA0hIAAOQSAADxEgAA8hIAABUTAAAWEwAAFxMAABgTAAAZEwAA QBMAAEETAABaEwAAWxMAAF8TAABgEwAAfBMAAH0TAACWEwAAlxMAAJsTAACcEwAAuRMAALoTAADV EwAA1hMAANgTAADaEwAA2xMAAPQTAAD1EwAA9+bRvve69+aolL6E97r35tGE97r35tGEvve69+ao lL73uvfm0YT3uvfm0b73uvfmqJS+9x8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJgNq AAAAABZoGjfyADBKDwA1CIFPSgMAUUoDAFUIAW1ICQBzSAkAACMVaG9oHgAWaEVGawAwSg8ANQiB T0oDAFFKAwBtSAkAc0gJAAYWaBo38gAAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAA AHNICQApA2oAAAAAFmgaN/IAMEoPADUIgU9KAwBRSgMAVQgBXAiBbUgJAHNICQAgFmhFRmsAMEoP ADUIgU9KAwBRSgMAXAiBbUgJAHNICQAADwNqAAAAABZoGjfyAFUIAQA09RMAABYUAAAXFAAAGRQA AB0UAAAeFAAALBQAAC0UAABNFAAAThQAAE8UAABQFAAAURQAAHEUAAByFAAAlRQAAJYUAACXFAAA mhQAAJsUAAC4FAAAuRQAANkUAADaFAAA4BQAAOEUAAD+FAAA/xQAABgVAAAZFQAAHxUAACAVAABO FQAATxUAAGgVAABpFQAAbxUAAHAVAAByFQAAhRUAAI0VAACOFQAArBUAAK0VAACuFQAAsxUAALQV AADIFQAAzBUAAM0VAADmFQAA5xUAAO0VAAD89OPRvar0/PTj0b2q9Pz049G9qvT89OOVqvT89OOV qvT89OOVqoWq9Pz049G9qoX0/PTjAAAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACkD agAAAAAWaBo38gAwSg8ANQiBT0oDAFFKAwBVCAFcCIFtSAkAc0gJACUVaG9oHgAWaEVGawBCKgFP SgMAUUoDAG1ICQBwaAAAAABzSAkAJgNqAAAAABZoGjfyADBKDwA1CIFPSgMAUUoDAFUIAW1ICQBz SAkAACMVaG9oHgAWaEVGawAwSg8ANQiBT0oDAFFKAwBtSAkAc0gJACAWaEVGawAwSg8ANQiBT0oD AFFKAwBcCIFtSAkAc0gJAAAPA2oAAAAAFmgaN/IAVQgBBhZoGjfyADTtFQAA7hUAAP4VAAD/FQAA JRYAACYWAAAqFgAAKxYAAEcWAABIFgAAZBYAAGUWAABmFgAAaRYAAGoWAACDFgAAhBYAAKYWAACn FgAAqBYAAK0WAACuFgAAvBYAAL0WAADdFgAA3hYAAN8WAADgFgAA4RYAAAYXAAAHFwAAIxcAACQX AAAoFwAAKRcAAEIXAABDFwAAYBcAAGEXAABlFwAAZhcAAJsXAACcFwAAwRcAAMIXAADDFwAAyBcA AMkXAADXFwAA2BcAAPEXAADyFwAA9BcAAOra0s7Sveqq0s7SvZiEqtLO0r2YhKrSztK9mISq0s7S vera0s7Sveqq0s7SvZiEqtLO0r0mA2oAAAAAFmgaN/IAMEoPADUIgU9KAwBRSgMAVQgBbUgJAHNI CQAAIxVob2geABZoRUZrADBKDwA1CIFPSgMAUUoDAG1ICQBzSAkAJRVob2geABZoRUZrAEIqAU9K AwBRSgMAbUgJAHBoAAAAAHNICQAgFmhFRmsAMEoPADUIgU9KAwBRSgMAXAiBbUgJAHNICQAABhZo GjfyAAAPA2oAAAAAFmgaN/IAVQgBHxZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQApA2oA AAAAFmgaN/IAMEoPADUIgU9KAwBRSgMAVQgBXAiBbUgJAHNICQAANPQXAAD1FwAACRgAAAoYAAAj GAAAJBgAACgYAAApGAAAVRgAAFYYAABvGAAAcBgAAHQYAAB1GAAAnBgAAJ0YAAC2GAAAtxgAALsY AAC8GAAA5xgAAOgYAAABGQAAAhkAAAYZAAAHGQAAKRkAACoZAABDGQAARBkAAEYZAABHGQAAYRkA AGIZAAB7GQAAfBkAAH4ZAAB/GQAAmRkAAJoZAAC+GQAAvxkAAMAZAADDGQAAxBkAAOwZAADtGQAA BhoAAAcaAAANGgAADhoAAC4aAAAvGgAASBoAAEkaAABPGgAAUBoAAFoaAABbGgAA6tfPy8+66tfP y8+66tfPy8+66tfPy8+66tfPy8+66tfPy8+66tfPy8+6qJTXz8vPuurXz8vPuurXzwAAJgNqAAAA ABZoGjfyADBKDwA1CIFPSgMAUUoDAFUIAW1ICQBzSAkAACMVaG9oHgAWaEVGawAwSg8ANQiBT0oD AFFKAwBtSAkAc0gJACAWaEVGawAwSg8ANQiBT0oDAFFKAwBcCIFtSAkAc0gJAAAGFmgaN/IAAA8D agAAAAAWaBo38gBVCAElFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACkDagAA AAAWaBo38gAwSg8ANQiBT0oDAFFKAwBVCAFcCIFtSAkAc0gJAAA6WxoAAHQaAAB1GgAAgBoAAIEa AACMGgAAjRoAAKYaAACnGgAAshoAALMaAADCGgAAwxoAANwaAADdGgAA6BoAAOkaAAD8GgAA/RoA ABYbAAAXGwAAIhsAACMbAAA2GwAANxsAAFcbAABYGwAAWhsAAFsbAABcGwAAbRsAAG4bAACOGwAA jxsAAJEbAACUGwAAlRsAALAbAACxGwAA0RsAANIbAADUGwAA1xsAANgbAADxGwAA8hsAAA4cAAAP HAAAEBwAABEcAAAlHAAAJhwAAPz048679Pz048679Pz048679Pz048679Pz046mVu/T89OOplbv0 /PTjqZW79Pz0qZW7ggAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACYDagAA AAAWaBo38gAwSg8ANQiBT0oDAFFKAwBVCAFtSAkAc0gJAAAjFWhvaB4AFmhFRmsAMEoPADUIgU9K AwBRSgMAbUgJAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACkDagAA AAAWaBo38gAwSg8ANQiBT0oDAFFKAwBVCAFcCIFtSAkAc0gJACAWaEVGawAwSg8ANQiBT0oDAFFK AwBcCIFtSAkAc0gJAAAPA2oAAAAAFmgaN/IAVQgBBhZoGjfyADMmHAAAJxwAACgcAAApHAAAKhwA ACscAAA/HAAAQBwAAEEcAABEHAAARRwAAEYcAABHHAAASBwAAFgcAABZHAAAcx0AAHQdAADnHgAA 6B4AAGwfAABtHwAA3B8AAN0fAAD3IAAA+CAAAJMhAACUIQAAmiEAAOzZxNm5srmei550ZV5WTuzZ 7Nns2ezZ7Nns2ewAAAAAAAAAAAAAAAAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwV aHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZo GjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQAT0oE AFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////AAwVaHZM dwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDaoQFAAAWaBo38gBCKgFPSgMAUUoDAFUI AW1ICQBwaAAAAABzSAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVo b2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAAHEccAABIHAAAWRwAAHQdAADoHgAA bR8AAN0fAAD4IAAAlCEAABUjAACtJAAAYCYAABsoAAAcKAAAnwAAAAAAAAAAAAAAAJoAAAAAAAAA AAAAAACVAAAAAAAAAAAAAAAAlQAAAAAAAAAAAAAAAIIAAAAAAAAAAAAAAACCAAAAAAAAAAAAAAAA ggAAAAAAAAAAAAAAAIIAAAAAAAAAAAAAAACVAAAAAAAAAAAAAAAAlQAAAAAAAAAAAAAAAJUAAAAA AAAAAAAAAACVAAAAAAAAAAAAAAAAdgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkAAAUpAAA WyQAXCQAZWRLTNY3EwAACiYAC0YBAA6EwAMPhJAGXYTAA16EkAZlZEtM1jdnZG9oHgAABB4AZWRL TNY3AAQDAGVkS0zWN2AAAGtkIAYAABYkARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIB AAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2 A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgAB DwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAAANmiEAAKMhAAAUIwAAFSMAAGYjAAB4 IwAAiSMAAIsjAACyIwAAsyMAANMjAADbIwAA/SMAAP4jAACsJAAArSQAAF8mAABgJgAABCcAAAUn AACqJwAAGigAABwoAAAdKAAAHigAAB8oAAAzKAAANCgAADUoAAA4KAAAOSgAAO/cydzv3O/cv9zv 3L/cr9zJ77/v3MmayY+Ij3RhdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAkFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAcGj///8AACcVaHZMdwAWaEVGawA1CIFC KghDShQAT0oEAFFKBABvKAFwaP///wAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo38gBV CAEoA2q4BgAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAfFmjaWPcAQioBT0oD AFFKAwBtSAkAcGgAAAAAc0gJABMDagAAAAAWaGVHWQAwSkIAVQgBJRVob2geABZo2lj3AEIqAU9K AwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJ AB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAAB4cKAAAHigAADsoAAA8KAAAWSgAABQp AADJKQAAIioAACMqAAAlKgAAQioAAPMAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAdAAAAAAAAAAA AAAAAG8AAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAADz AAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEHgBlZEtM1jcABAMAZWRLTNY3YAAAa2RUBwAAFiQBFyQBSWYB AAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAO lPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA /x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAA AAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABh JAFnZG9oHgAACwAAE6QAABSkAABbJABcJABlZEtM1jcACjkoAAA6KAAAOygAADwoAABYKAAAWSgA ABMpAAAUKQAAlSkAAJ4pAADIKQAAySkAACEqAAAjKgAAJCoAACUqAAAmKgAAOioAADsqAAA8KgAA PyoAAEAqAABBKgAAQioAAEMqAADo2dLKwq+cr4yvnK+cd5xsZWxRPlHo2dIkFWh2THcAFmhFRmsA NQiBQioIQ0oUAE9KBABRSgQAcGj///8AACcVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABv KAFwaP///wAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo38gBVCAEoA2rsBwAAFmgaN/IA QioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAA c0gJACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIq AU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwV aHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZo GjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////AAAYQioAAEMqAABVKgAAaCoAAMMqAADTKgAA ISsAACgrAAB4KwAAhysAAMYrAACfAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAIUAAAAAAAAAAAAA AABuAAAAAAAAAAAAAAAAVwAAAAAAAAAAAAAAAG4AAAAAAAAAAAAAAABXAAAAAAAAAAAAAAAAbgAA AAAAAAAAAAAAAFcAAAAAAAAAAAAAAABuAAAAAAAAAAAAAAAAABYAAA6EsAQPhLAEE6QAABSkAABb JABcJABdhLAEXoSwBGVkEjkRVWdkRUZrAAAWAAAOhLAED4SABxOkAAAUpAAAWyQAXCQAXYSwBF6E gAdlZBI5EVVnZEVGawAAFAAADoSwBA+EsAQUpAAAWyQAXCQAXYSwBF6EsARlZBI5EVVnZEVGawAA BAMAZWRLTNY3YAAAa2SICAAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAA AAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEV NgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAA QtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAAApDKgAAVCoAAFUqAABnKgAAaCoAAMIqAADD KgAA0ioAANMqAAAgKwAAISsAACcrAAAoKwAAdysAAHgrAACGKwAAhysAAMUrAADGKwAAzisAAM8r AADnKwAA6CsAAO0rAADuKwAAUy4AAFQuAABgLgAAYS4AALwuAAC9LgAAyi4AAMsuAAAxLwAAMi8A AEQvAABFLwAAai8AAHcvAADgLwAA4S8AAO0vAADuLwAAYzEAAGQxAAB4MQAAeTEAAEwyAACaMgAA mzIAALoyAAC7MgAAXjMAAF8zAABtMwAAbjMAAPUzAAD2MwAABzQAAAg0AAC4NAAAujQAAPjw3crd yt3K3crdyt3K3crdyt3K3crdyt3K3crdyt3K3crdyt263crdqrqq3crdusrdyt3K3crdyt3K3coA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAA AHNICQAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAWaNpY9wBCKgFPSgMA UUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAO FmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAPcYrAADPKwAA6CsAAO4rAABULgAAYS4AAL0u AADLLgAAMi8AAEUvAADhLwAA7i8AAGQxAAB5MQAAmzIAALsyAABfMwAAbjMAAPYzAAAINAAA6AAA AAAAAAAAAAAAANEAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAOgAAAAAAAAA AAAAAADRAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA 0QAAAAAAAAAAAAAAAMUAAAAAAAAAAAAAAAC1AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAANEAAAAA AAAAAAAAAADoAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADRAAAAAAAAAAAA AAAA6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8AAA+E 0AITpAAAFKQAAFskAFwkAF6E0AJlZBI5EVUACwAAE6QAABSkAABbJABcJABlZBI5EVUAFgAADoSw BA+EgAcTpAAAFKQAAFskAFwkAF2EsARehIAHZWQSORFVZ2RFRmsAABYAAA6EsAQPhLAEE6QAABSk AABbJABcJABdhLAEXoSwBGVkEjkRVWdkRUZrAAATCDQAALk0AAC6NAAAvDQAANk0AADaNAAA6TQA AKE2AAAQOAAAETgAAOoAAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAAL8AAAAA AAAAAAAAAABfAAAAAAAAAAAAAAAAWgAAAAAAAAAAAAAAAFUAAAAAAAAAAAAAAABVAAAAAAAAAAAA AAAA3gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtkvAkA ABYkARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqAB CnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YE AAAA/xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3 cNYKAAAA/5kAAAAAAB8AAAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYB AAAAWyQAXCQAYSQBZ2RvaB4AAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3ABQAAA6EsAQPhIAHE6QA AFskAFwkAF2EsARehIAHZWQSORFVZ2RFRmsAAAm6NAAAuzQAALw0AAC9NAAA0TQAANI0AADTNAAA 1jQAANc0AADYNAAA2TQAANo0AADoNAAA6TQAAJ81AACuNQAArzUAAOc1AADoNQAAoDYAAKE2AADr 2M3GzbKfsoh5cmpiTz81TzVP2AAAEwNqAAAAABZoZUdZADBKQgBVCAEfFmhFRmsAQioBT0oDAFFK AwBtSAkAcGgAAAAAc0gJACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkADhZo 2lj3AG1ICQBzSAkAAA4WaEVGawBtSAkAc0gJAAAMFWh2THcAFmjaWPcAAB0VaHZMdwAWaNpY9wBC KghPSgMAUUoDAHBo////AC0DagAAAAAVaHZMdwAWaBo38gA1CIFCKghDShQAT0oEAFFKBABVCAFw aP///wAkFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAcGj///8AACcVaHZMdwAWaEVGawA1 CIFCKghDShQAT0oEAFFKBABvKAFwaP///wAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo3 8gBVCAElFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACgDaiAJAAAWaBo38gBC KgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAFKE2AAAPOAAAETgAABI4AAATOAAAFTgAAFE4AABS OAAAjjgAAI84AADLOAAAzDgAAAg5AAAJOQAARTkAAEY5AABSOQAAUzkAAI85AACQOQAAzDkAAM05 AAAJOgAACjoAAEY6AABHOgAAgzoAAIQ6AACQOgAAkToAAM06AADOOgAACjsAAAs7AABHOwAASDsA AIQ7AACFOwAAwTsAAMM7AADlOwAA5jsAAOc7AADoOwAA6TsAAO/fyt/CusK6wrrCusK6wrrCusK6 wrrCusK6wrrCusK6wrrCusK6wqeYkXzfAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKANqXAsAABZo GjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAADBVodkx3ABZo2lj3AAAdFWh2THcAFmja WPcAQioBT0oDAFFKAwBwaAAAAAAlFmhFRmsANQiBQioBQ0oPAE9KBQBRSgUAXAiBYUoPAHBoAAAA AA4WaEVGawBtSAkAc0gJAAAOFmjaWPcAbUgJAHNICQAAKANqVAoAABZoGjfyAEIqAU9KAwBRSgMA VQgBbUgJAHBoAAAAAHNICQAAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhFRmsA QioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAAAsETgAABM4AAAUOAAAFTgAAFI4AACPOAAAzDgAAAk5 AABGOQAAUzkAAJA5AADNOQAACjoAAEc6AACEOgAAkToAAM46AAALOwAASDsAAIU7AADCOwAAwzsA APMAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADeAAAA AAAAAAAAAAAA3gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAA3gAAAAAAAAAA AAAAAO4AAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADe AAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAA3gAAAAAA AAAAAAAAAN4AAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAAzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABEaAA6E4AEPhLAEFKTgAV2E4AFe hLAEZWTiYJQEZ2RFRmsAAA8aAA6E4AEPhLAEXYTgAV6EsARlZOJglARnZEVGawAABBoAZWTiYJQE AAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3ABXDOwAA5jsAAOc7AADpOwAAWjwAAF48AAAuPQAAMj0A AO8AAAAAAAAAAAAAAACmAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACAAAAA AAAAAAAAAAAAaQAAAAAAAAAAAAAAAFIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAWAAAOhLAED4SwBBOkAAAUpAAAWyQAXCQAXYSwBF6EsARlZMN5 rV1nZEVGawAAFgAADoSwBA+EgAcTpAAAFKQAAFskAFwkAF2EsARehIAHZWTDea1dZ2RFRmsAABQA AA6EsAQPhLAEFKQAAFskAFwkAF2EsARehLAEZWTDea1dZ2RFRmsAAAQeAGVkS0zWNwALAAATpAAA FKQAAFskAFwkAGVkS0zWN0kAAGtk9goAABYkARckAUlmAQAAAGVkS0zWNwBUAQAI1hoAAeL/rgiA QgAAAAAAAAAAAAAAAAAAAAAAAAp0AACgBBT2AQAAFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAA AP8d1gQAAAD/M9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jeKVAEAEAAAAyQBE6QA ABSkAAAWJAFJZgEAAABbJABcJABhJAEAB+k7AAALPAAAOzwAAFk8AABaPAAAXTwAAF48AACZPAAA nTwAAKs8AAAXPQAAKz0AACw9AAAtPQAALj0AADE9AAAyPQAAPT0AAEU9AABWPQAAVz0AAJo9AACb PQAAnj0AAJ89AACjPQAAJD4AADA+AAAxPgAAMj4AADM+AAA0PgAANz4AADg+AABQPgAAhj4AAIc+ AACuPgAArz4AALI+AACzPgAAGD8AABk/AAAcPwAAHT8AAG8/AABxPwAAcj8AAHM/AAB0PwAA7Nzs yezJ7Nzs3Ozc7Mnsyezc7L/sr+zJ7Nzsv9zsyezJ7Nyl3K/cr9yv7MnsyZDJhQAAAAAAAAAAAAAA AAAAAAAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDav4LAAAWaBo38gBCKgFPSgMAUUoDAFUIAW1I CQBwaAAAAABzSAkAABMDagAAAAAWaJNsuAAwSkIAVQgBHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBo AAAAAHNICQATA2oAAAAAFmhlR1kAMEpCAFUIASUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBw aAAAAABzSAkAHxZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioB T0oDAFFKAwBtSAkAcGgAAAAAc0gJAAAxMj0AAJs9AACfPQAAND4AADg+AACvPgAAsz4AABk/AAAd PwAAcD8AAHE/AABzPwAAkD8AAO8AAAAAAAAAAAAAAADYAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAA ANgAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAAtQAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADYAAAA AAAAAAAAAAAAoAAAAAAAAAAAAAAAAJQAAAAAAAAAAAAAAACUAAAAAAAAAAAAAAAAdQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/ GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACwAAE6QAABSkAABbJABcJABlZEtM 1jcAFAAADoSwBA+EgAcTpAAAWyQAXCQAXYSwBF6EgAdlZMN5rV1nZEVGawAACwAAE6QAABSkAABb JABcJABlZMN5rV0AFgAADoSwBA+EgAcTpAAAFKQAAFskAFwkAF2EsARehIAHZWTDea1dZ2RFRmsA ABYAAA6EsAQPhLAEE6QAABSkAABbJABcJABdhLAEXoSwBGVkw3mtXWdkRUZrAAAPAAAPhNACE6QA ABSkAABbJABcJABehNACZWTDea1dAAx0PwAAiD8AAIk/AACKPwAAjT8AAI4/AACPPwAAkD8AAJE/ AACkPwAApT8AAGpAAABrQAAAbEAAAG1AAABuQAAAb0AAAINAAACEQAAAhUAAAIhAAACJQAAAikAA AItAAACMQAAApkAAAPnu2sfasKGakop6aldCV+757trH2rChmpIAAAAoA2oyDQAAFmgaN/IAQioB T0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgA AAAAc0gJAB8WaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAHxZoRUZrAEIqAU9KAwBRSgMA bUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY 9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIq CENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABwaP// /wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////ABUDagAAAAAVaHZMdwAW aBo38gBVCAEMFWh2THcAFmgaN/IAGZA/AACRPwAApT8AAGtAAABsQAAAbkAAAItAAACfAAAAAAAA AAAAAAAAmgAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACJAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAA AGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABbJABc JABhJAFnZG9oHgAACwAAE6QAABSkAABbJABcJABlZEtM1jcABB4AZWRLTNY3AAQDAGVkS0zWN2AA AGtkmgwAABYkARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAA AAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQA AAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAA aXRLTNY3cNYKAAAA/5kAAAAAAAAGi0AAAIxAAACnQAAAEUIAAIRCAACFQgAAh0IAAIhCAACJQgAA mEIAAKdCAAC2QgAAxUIAANRCAACfAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAJUAAAAAAAAAAAAA AACFAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAHkAAAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAdAAA AAAAAAAAAAAAAHQAAAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAHQAAAAAAAAA AAAAAAB0AAAAAAAAAAAAAAAAAAAAAAAAAAAEGgBlZDQwoyQACwAAE6QAABSkAABbJABcJABlZEtM 1jcADx4ADoTAAw+EwANdhMADXoTAA2VkihOSSmdkb2geAAAEHgBlZEtM1jcABAMAZWRLTNY3YAAA a2TODQAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAA CdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAA AP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABp dEtM1jdw1goAAAD/mQAAAAAAAA2mQAAAp0AAAGtBAACBQQAAl0EAAKVBAAAQQgAAEUIAAHVCAACD QgAAhEIAAIVCAACGQgAAh0IAAIlCAACXQgAAmEIAAKZCAACnQgAAtUIAALZCAADEQgAAxUIAANNC AADUQgAA3EIAAN1CAADlQgAA5kIAAO9CAADwQgAALUMAAC5DAABrQwAAbEMAAKlDAACqQwAA50MA AOhDAAAlRAAAJkQAAGNEAABkRAAAoUQAAKJEAACtRAAArkQAALhEAAC5RAAAw0QAAMREAADRRAAA 0kQAAN9EAADgRAAA7UQAAO5EAAD7RAAA/EQAAPjo1ejV6MXo1bLFncX4lfiV+JX4lfiV+JX4lfiV +JX4lfiV+JX4lfiV+JX4lfiV+JX4lfiV+JX4lfgAAAAADhZoRUZrAG1ICQBzSAkAACgDamYOAAAW aBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoD AG1ICQBwaAAAAABzSAkAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhF RmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABz SAkADhZo2lj3AG1ICQBzSAkAOtRCAADdQgAA5kIAAPBCAAAuQwAAbEMAAKpDAADoQwAAJkQAAGRE AACiRAAArkQAALlEAADERAAA0kQAAOBEAADuRAAA/EQAAApFAAALRQAAN0UAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAADqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAMkAROkAAAUpAAAFiQBSWYBAAAAWyQA XCQAYSQBAAQaAGVkNDCjJAAU/EQAAAlFAAALRQAANkUAADdFAAA4RQAAOUUAADpFAACERQAAhUUA AIhFAACJRQAA0EYAANFGAADURgAA1UYAAHFHAAByRwAAdUcAAHZHAABcSAAAXUgAAC1JAAAuSQAA VEoAAFVKAACHSgAAiUoAAIpKAACLSgAAjEoAAKBKAAChSgAA+PDd0cq1pZWllaWVpZWllaWVpZWl laWVpZWlgG1iW2IAAAAAAAAAAAAAAAAAAAAAAAAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAW aBo38gBVCAElFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACgDahAQAAAWaBo3 8gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAAB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAA AABzSAkAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAoA2puDwAAFmgaN/IAQioBT0oD AFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAMFWh2THcAFmjaWPcAABcWaNpY9wBCKgFPSgMAUUoDAHBo AAAAACUWaEVGawA1CIFCKgFDSg8AT0oFAFFKBQBcCIFhSg8AcGgAAAAADhZo2lj3AG1ICQBzSAkA AA4WaEVGawBtSAkAc0gJACA3RQAAOEUAADpFAACFRQAAiUUAANFGAADVRgAAckcAAHZHAABdSAAA LkkAAFVKAACISgAAiUoAAItKAAC2AAAAAAAAAAAAAAAAqgAAAAAAAAAAAAAAAKUAAAAAAAAAAAAA AACZAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAAJkAAAAAAAAAAAAAAACJAAAAAAAAAAAAAAAAmQAA AAAAAAAAAAAAAIkAAAAAAAAAAAAAAAClAAAAAAAAAAAAAAAApQAAAAAAAAAAAAAAAKUAAAAAAAAA AAAAAACqAAAAAAAAAAAAAAAAqgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA8AAA+E0AITpAAAFKQAAFskAFwkAF6E0AJlZEculwEACwAAE6QAABSkAABbJABcJABl ZEculwEABB4AZWRLTNY3AAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3SQAAa2QIDwAAFiQBFyQBSWYB AAAAZWRLTNY3AFQBAAjWGgAB4v9FC4BCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYBAAAVNgEX 9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8z1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh 9gMAAGl0S0zWN4pUAQAADqFKAACiSgAApUoAAKZKAACnSgAAqEoAAKlKAACxSgAAukoAANRKAADV SgAA1koAAONKAAD+SgAA/0oAAAFLAAADSwAAHEsAAG9LAAAZTAAAcUwAAHJMAAA9TQAAcE0AAH9N AADdTQAA69jrwbKro5ijgHhoVWhVaFVoVWhFaFVoVQAAAAAAAAAAAB8WaNpY9wBCKgFPSgMAUUoD AG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhF RmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAA4WaNpY9wBtSAkAc0gJAAAuA2oAAAAAFmgtLfgA MEpCADUIgUIqAE9KAABRSgAAVQgBXAiBXkoAAHBoAAAA/wAUFWhvaB4AFmhFRmsAbUgJAHNICQAA DhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj/ //8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAW aEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQA UUoEAG8oAXBo////AAAZi0oAAKhKAACpSgAA1koAAHJMAADeTQAAmU4AAJpOAACcTgAAnU4AAOAA AAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAewAAAAAAAAAAAAAAAHYAAAAAAAAAAAAAAABmAAAAAAAA AAAAAAAAdgAAAAAAAAAAAAAAAFoAAAAAAAAAAAAAAABaAAAAAAAAAAAAAAAAVQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABBoAZWT2FU1OAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3AA8eAA6EwAMP hMADXYTAA16EwANlZIoTkkpnZG9oHgAABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtkrBAAABYkARck AUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAE DTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzW BAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA /5kAAAAAAB8AAAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQA XCQAYSQBZ2RvaB4AAAndTQAA3k0AAJhOAACaTgAAm04AAJxOAACeTgAA1U4AANZOAAANTwAADk8A AEVPAABGTwAAfU8AAH5PAAC1TwAAt08AAPBPAADxTwAA8k8AAPNPAAD1TwAA9k8AAPdPAAD4TwAA DFAAAA1QAADs3My3zK+nr6evp6+nr6evlIiBbMxXzExFTAAAAAAMFWh2THcAFmgaN/IAABUDagAA AAAVaHZMdwAWaBo38gBVCAEoA2ruEgAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJ AAAoA2pMEgAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAMFWh2THcAFmjaWPcA ABcWaNpY9wBCKgFPSgMAUUoDAHBoAAAAACUWaEVGawA1CIFCKgFDSg8AT0oFAFFKBQBcCIFhSg8A cGgAAAAADhZoRUZrAG1ICQBzSAkAAA4WaNpY9wBtSAkAc0gJAAAoA2pEEQAAFmgaN/IAQioBT0oD AFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAfFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAB8W aEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJ AHBoAAAAAHNICQAAGp1OAACeTgAA1k4AAA5PAABGTwAAfk8AALZPAAC3TwAA8U8AAPJPAAD0TwAA 9U8AAPdPAAAUUAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAA AAChAAAAAAAAAAAAAAAAlQAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACVAAAAAAAAAAAAAAAAeQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/GYT4 /xsmICMkAi+ELQBJZgEAAABbJABcJABhJAEACwAAE6QAABSkAABbJABcJABlZEtM1jdJAABrZOYR AAAWJAEXJAFJZgEAAABlZEtM1jcAVAEACNYaAAHi/1IPgEIAAAAAAAAAAAAAAAAAAAAAAAAKdAAA oAQU9gEAABU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/zPWBgABDwMPADTWBgAB DwMAAELWAwABAWH2AwAAaXRLTNY3ilQBABAAAAMkAROkAAAUpAAAFiQBSWYBAAAAWyQAXCQAYSQB AAQaAGVk9hVNTgANDVAAABJQAAATUAAAFFAAABVQAAAvUAAAMFAAAFdRAAClUQAAp1EAAKhRAACq UQAAq1EAAKxRAACtUQAAwVEAAMJRAADDUQAA6tDEvbWtnYqdindid1dQVzwAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo//// AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDahwUAAAWaBo38gBCKgFPSgMA UUoDAFUIAW1ICQBwaAAAAABzSAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABz SAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhFRmsAQioBT0oDAFFK AwBtSAkAcGgAAAAAc0gJAA4WaNpY9wBtSAkAc0gJAAAOFmhFRmsAbUgJAHNICQAADBVodkx3ABZo 2lj3AAAXFmjaWPcAQioIT0oDAFFKAwBwaP///wAyA2oAAAAAFmgaN/IANQiBQioIQ0oUAE9KBABR SgQAVQgBXAiBXkoEAGFKFABwaP///wAAKRZoRUZrADUIgUIqCENKFABPSgQAUUoEAFwIgV5KBABh ShQAcGj///8AABEUUAAAFVAAADBQAACpUQAAqlEAAKxRAADJUQAAnwAAAAAAAAAAAAAAAJoAAAAA AAAAAAAAAACVAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAAIkAAAAAAAAAAAAAAABqAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8AAAMk ARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBZ2RvaB4A AAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3AAQeAGVkS0zWNwAEAwBlZEtM1jdgAABrZIQTAAAWJAEX JAFJZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACg BA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c 1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAA AP+ZAAAAAAAABsNRAADGUQAAx1EAAMhRAADJUQAAylEAAN9RAADgUQAAb1IAAHBSAADjUwAA5VMA AOZTAADnUwAA6VMAACRUAAAlVAAAYFQAAGFUAACcVAAAnVQAANhUAADZVAAAFFUAABVVAAAhVQAA IlUAAF1VAABeVQAAmVUAAJpVAADVVQAA1lUAABFWAAASVgAATVYAAE5WAADt2cKzrKScjIKMcl1y nKScpJyknKScpJyknKScpJyknKScpJwAACgDakoVAAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBw aAAAAABzSAkAAB8WaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAEwNqAAAAABZodEUuADBK QgBVCAEfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAA4WaNpY9wBtSAkAc0gJAAAOFmhF RmsAbUgJAHNICQAADBVodkx3ABZo2lj3AAAdFWh2THcAFmjaWPcAQioIT0oDAFFKAwBwaP///wAt A2oAAAAAFWh2THcAFmgaN/IANQiBQioIQ0oUAE9KBABRSgQAVQgBcGj///8AJxVodkx3ABZoRUZr ADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFK BABwaP///wAkyVEAAMpRAADgUQAA5FMAAOVTAADnUwAA6FMAAOlTAAAlVAAAYVQAAJ1UAADZVAAA FVUAACJVAACfAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACJAAAAAAAAAAAA AAAAiQAAAAAAAAAAAAAAAIQAAAAAAAAAAAAAAACEAAAAAAAAAAAAAAAAhAAAAAAAAAAAAAAAAHQA AAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAHQAAAAAAAAAAAAAAAB0AAAAAAAA AAAAAAAAAAAAAAAAAAAPGgAOhOABD4SwBF2E4AFehLAEZWT2AARIZ2RFRmsAAAQaAGVk9gAESAAL AAATpAAAFKQAAFskAFwkAGVkS0zWNwAEHgBlZEtM1jcABAMAZWRLTNY3YAAAa2SyFAAAFiQBFyQB SWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQN NiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYE AAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/ mQAAAAAAAA0iVQAAXlUAAJpVAADWVQAAElYAAE5WAACKVgAAxlYAAAJXAAA+VwAAS1cAAIdXAADD VwAA/1cAADtYAAB3WAAAeFgAAJ9YAADvAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAO8AAAAA AAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAA AAAA2gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAyQBE6QAABSk AAAWJAFJZgEAAABbJABcJABhJAEABBoAZWT2AARIAA8aAA6E4AEPhLAEXYTgAV6EsARlZPYABEhn ZEVGawAAEU5WAACJVgAAilYAAMVWAADGVgAAAVcAAAJXAAA9VwAAPlcAAEpXAABLVwAAhlcAAIdX AADCVwAAw1cAAP5XAAD/VwAAOlgAADtYAAB2WAAAeFgAAJ5YAACfWAAAoFgAAKFYAACiWAAA51gA AOhYAADrWAAA7FgAAH5ZAAB/WQAAglkAAINZAADRWQAA0lkAAAtaAAAMWgAADloAAA9aAAASWgAA E1oAAHlaAAB6WgAAfVoAAH5aAADQWgAA0VoAANRaAADVWgAAklsAAJNbAACWWwAAl1sAAPhbAAD4 8Pjw+PD48Pjw+PD48Pjw+PD48N3RyrWllaWVpZWllaWVi5WLlaWVpZWllaWVpZWllaWVpZUAAAAA EwNqAAAAABZodEUuADBKQgBVCAEfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAB8WaNpY 9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAKANqUhYAABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJ AHBoAAAAAHNICQAADBVodkx3ABZo2lj3AAAXFmjaWPcAQioBT0oDAFFKAwBwaAAAAAAlFmhFRmsA NQiBQioBQ0oPAE9KBQBRSgUAXAiBYUoPAHBoAAAAAA4WaNpY9wBtSAkAc0gJAAAOFmhFRmsAbUgJ AHNICQA2n1gAAKBYAACiWAAA6FgAAOxYAAB/WQAAg1kAAA9aAAATWgAAeloAAH5aAADRWgAA1VoA AJNbAACXWwAA+VsAALYAAAAAAAAAAAAAAACqAAAAAAAAAAAAAAAApQAAAAAAAAAAAAAAAJkAAAAA AAAAAAAAAACJAAAAAAAAAAAAAAAAmQAAAAAAAAAAAAAAAIkAAAAAAAAAAAAAAACZAAAAAAAAAAAA AAAAiQAAAAAAAAAAAAAAAJkAAAAAAAAAAAAAAACJAAAAAAAAAAAAAAAAmQAAAAAAAAAAAAAAAIkA AAAAAAAAAAAAAACZAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAAAP hNACE6QAABSkAABbJABcJABehNACZWSBIgVBAAsAABOkAAAUpAAAWyQAXCQAZWSBIgVBAAQeAGVk S0zWNwALAAATpAAAFKQAAFskAFwkAGVkS0zWN0kAAGtk7BUAABYkARckAUlmAQAAAGVkS0zWNwBU AQAI1hoAAeL/5gmAQgAAAAAAAAAAAAAAAAAAAAAAAAp0AACgBBT2AQAAFTYBF/YDAAAa1gQAAAD/ G9YEAAAA/xzWBAAAAP8d1gQAAAD/M9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jeK VAEAAA/4WwAA+VsAAPxbAAD9WwAAqlwAAKtcAACuXAAAr1wAAE1dAABOXQAAUF0AAFFdAABSXQAA U10AAGddAABoXQAAaV0AAGxdAABtXQAAbl0AAG9dAABwXQAA79/v3+/f79/MuaS5mZKZfmt+VEU+ AAAAAAAAAAAAAAAAAAAADBVodkx3ABZo2lj3AAAdFWh2THcAFmjaWPcAQioIT0oDAFFKAwBwaP// /wAtA2oAAAAAFWh2THcAFmgaN/IANQiBQioIQ0oUAE9KBABRSgQAVQgBcGj///8AJBVodkx3ABZo RUZrADUIgUIqCENKFABPSgQAUUoEAHBo////AAAnFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABR SgQAbygBcGj///8ADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBKANq9BYAABZo GjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAJRVob2geABZo2lj3AEIqAU9KAwBRSgMA bUgJAHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAB8WaEVG awBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNI CQAAFflbAAD9WwAAq1wAAK9cAABPXQAAUF0AAFJdAABvXQAA8wAAAAAAAAAAAAAAAOMAAAAAAAAA AAAAAADzAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAA owAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAyQBEmThAAAA E6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACwAAE6QA ABSkAABbJABcJABlZEtM1jcAFAAADoSwBA+EgAcTpAAAWyQAXCQAXYSwBF6EgAdlZIEiBUFnZG9o HgAADwAAD4TQAhOkAAAUpAAAWyQAXCQAXoTQAmVkgSIFQQALAAATpAAAFKQAAFskAFwkAGVkgSIF QQAHb10AAHBdAACCXQAAzl4AAGRfAABlXwAAZ18AAIRfAACfAAAAAAAAAAAAAAAAmgAAAAAAAAAA AAAAAIoAAAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAHkAAAAAAAAAAAAAAABa AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEA AABbJABcJABhJAFnZG9oHgAACwAAE6QAABSkAABbJABcJABlZEtM1jcABB4AZWRLTNY3AA8eAA6E wAMPhMADXYTAA16EwANlZIoTkkpnZG9oHgAABAMAZWRLTNY3YAAAa2SKFwAAFiQBFyQBSWYBAAAA ZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/ D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3W BAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAA AAdwXQAAgV0AAIJdAAAqXgAAzV4AAM5eAABjXwAAZF8AAGVfAABmXwAAZ18AAGhfAAB8XwAAfV8A AH5fAACBXwAAgl8AAINfAACEXwAA+PDgzbrgqrqVuoqDim9cb0U2AAAAAAAAAAAAAAAAAAAdFWh2 THcAFmjaWPcAQioIT0oDAFFKAwBwaP///wAtA2oAAAAAFWh2THcAFmgaN/IANQiBQioIQ0oUAE9K BABRSgQAVQgBcGj///8AJBVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAHBo////AAAnFWh2 THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAbygBcGj///8ADBVodkx3ABZoGjfyAAAVA2oAAAAA FWh2THcAFmgaN/IAVQgBKANqIhgAABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAA HxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBt SAkAcGgAAAAAc0gJACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAHxZoRUZr AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkA EoRfAACFXwAAmV8AACdgAAAoYAAAKmAAAEdgAACfAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAJUA AAAAAAAAAAAAAACJAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAyQBEmThAAAAE6QA ABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACwAAE6QAABSk AABbJABcJABlZEtM1jcABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtkuBgAABYkARckAUlmAQAAAGVk S0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U +P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQA AAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAAAG hF8AAIVfAACYXwAAmV8AACZgAAAnYAAAKGAAAClgAAAqYAAAK2AAAD9gAABAYAAAQWAAAERgAABF YAAARmAAAEdgAABIYAAAWGAAAFlgAAD58enZybahtpaPlntoe1FC+fHpAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVo dkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghD ShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo//// AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDalAZAAAWaBo38gBCKgFPSgMA UUoDAFUIAW1ICQBwaAAAAABzSAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABz SAkAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhFRmsAQioBT0oDAFFKAwBtSAkA cGgAAAAAc0gJAA4WaNpY9wBtSAkAc0gJAAAOFmhFRmsAbUgJAHNICQAADBVodkx3ABZo2lj3ABNH YAAASGAAAFlgAABcYQAAXWEAAF9hAABgYQAAYWEAAKJhAADjYQAAJGIAAGViAACmYgAA52IAAChj AACfAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACJAAAAAAAAAAAAAAAAiQAA AAAAAAAAAAAAAHkAAAAAAAAAAAAAAAB5AAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAHkAAAAAAAAA AAAAAAB5AAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAHkAAAAAAAAAAAAAAAB5AAAAAAAAAAAAAAAA eQAAAAAAAAAAAAAAAAAPGgAOhOABD4SwBF2E4AFehLAEZWR2NddHZ2RFRmsAAAsAABOkAAAUpAAA WyQAXCQAZWRLTNY3AAQeAGVkS0zWNwAEAwBlZEtM1jdgAABrZOYZAAAWJAEXJAFJZgEAAABlZEtM 1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/ EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA /x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAAAAAADllg AAC+YAAAv2AAAARhAAAWYQAAW2EAAF1hAABeYQAAX2EAAGFhAAChYQAAomEAAOJhAADjYQAAI2IA ACRiAABkYgAAZWIAAKViAACmYgAA5mIAAOdiAAAnYwAAKGMAAGNjAABkYwAAn2MAAKBjAADbYwAA 3GMAABdkAAAYZAAAU2QAAFRkAACPZAAAkGQAAMtkAADMZAAAB2UAAAhlAABDZQAARGUAAH9lAACA ZQAAr2UAALFlAADMZQAA7OLs0uy/qpqSipKKkoqSipKKkoqSipKKkoqSipKKkoqSipKKkoqSipKK koqSdwAAAAAlFmhFRmsANQiBQioBQ0oPAE9KBQBRSgUAXAiBYUoPAHBoAAAAAA4WaEVGawBtSAkA c0gJAAAOFmjaWPcAbUgJAHNICQAAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAoA2p+ GgAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oD AFFKAwBtSAkAcGgAAAAAc0gJAB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAEwNqAAAA ABZodEUuADBKQgBVCAElFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAAAuKGMA AGRjAACgYwAA3GMAABhkAABUZAAAkGQAAMxkAAAIZQAARGUAAIBlAACwZQAAsWUAAM1lAADOZQAA 7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAA AAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAA AAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAIQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASQAAa2QgGwAAFiQBFyQBSWYBAAAAZWRL TNY3AFQBAAjWGgAB4v83B4BCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYBAAAVNgEX9gMAABrW BAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8z1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0 S0zWN4pUAQAQAAADJAETpAAAFKQAABYkAUlmAQAAAFskAFwkAGEkAQARGgAOhOABD4SwBBSk4AFd hOABXoSwBGVkdjXXR2dkRUZrAAAPGgAOhOABD4SwBF2E4AFehLAEZWR2NddHZ2RFRmsAAA7MZQAA zWUAAM5lAADPZQAA0GUAABJmAAATZgAAFmYAABdmAABZZwAAWmcAAF1nAABeZwAA+mcAAPtnAAD+ ZwAA/2cAAPVoAAD2aAAA+WgAAPpoAACjaQAApGkAAKdpAACoaQAAJmoAAChqAAApagAAKmoAACtq AAA/agAAQGoAAEFqAADw6dTEsZ6xnrGesZ6xnrGesZ6xnrGesZ6xnomefnd+YwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAbygB cGj///8ADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBKANqKBwAABZoGjfyAEIq AU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBo AAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAB8WaNpY9wBCKgFP SgMAUUoDAG1ICQBwaAAAAABzSAkAKANqhhsAABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAA AHNICQAADBVodkx3ABZo2lj3AAAdFWh2THcAFmjaWPcAQioBT0oDAFFKAwBwaAAAAAAAIM5lAADQ ZQAAE2YAABdmAABaZwAAXmcAAPtnAAD/ZwAA9mgAAPpoAACkaQAAqGkAACdqAAAoagAAKmoAAPMA AAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAACrAAAAAAAA AAAAAAAAwgAAAAAAAAAAAAAAAKsAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAAqwAAAAAAAAAAAAAA AMIAAAAAAAAAAAAAAACrAAAAAAAAAAAAAAAAlgAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAUAAAOhLAED4SABxOkAABbJABcJABdhLAEXoSAB2Vk2yZlR2dkRUZrAAAWAAAO hLAED4SwBBOkAAAUpAAAWyQAXCQAXYSwBF6EsARlZNsmZUdnZEVGawAAFgAADoSwBA+EgAcTpAAA FKQAAFskAFwkAF2EsARehIAHZWTbJmVHZ2RFRmsAABQAAA6EsAQPhLAEFKQAAFskAFwkAF2EsARe hLAEZWTbJmVHZ2RFRmsAAAQeAGVkS0zWNwALAAATpAAAFKQAAFskAFwkAGVkS0zWNwAOQWoAAERq AABFagAARmoAAEdqAABIagAAWGoAAFlqAACsagAArWoAAI1rAACOawAAZW0AAGZtAAC/bgAAwW4A AMJuAADDbgAAxW4AAAxvAAANbwAAVG8AAFVvAACcbwAAnW8AAORvAADlbwAALHAAAO3ZwrOspJyJ f4lsiWyJbFdHnKScpJyknKScpAAAAB8WaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAKANq XB0AABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAJRVob2geABZo2lj3AEIqAU9K AwBRSgMAbUgJAHBoAAAAAHNICQATA2oAAAAAFmh0RS4AMEpCAFUIASUVaG9oHgAWaEVGawBCKgFP SgMAUUoDAG1ICQBwaAAAAABzSAkADhZo2lj3AG1ICQBzSAkAAA4WaEVGawBtSAkAc0gJAAAMFWh2 THcAFmjaWPcAAB0VaHZMdwAWaNpY9wBCKghPSgMAUUoDAHBo////AC0DagAAAAAVaHZMdwAWaBo3 8gA1CIFCKghDShQAT0oEAFFKBABVCAFwaP///wAnFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABR SgQAbygBcGj///8AJBVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAHBo////ABsqagAAR2oA AEhqAABZagAAjmsAAGZtAADAbgAAwW4AAMNuAADEbgAAxW4AAOAAAAAAAAAAAAAAAACAAAAAAAAA AAAAAAAAewAAAAAAAAAAAAAAAHYAAAAAAAAAAAAAAAB2AAAAAAAAAAAAAAAAdgAAAAAAAAAAAAAA AGoAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAWgAAAAAAAAAAAAAAAFoAAAAAAAAAAAAAAAAAAAAA AAAADxoADoTgAQ+EsARdhOABXoSwBGVknTyJO2dkRUZrAAALAAATpAAAFKQAAFskAFwkAGVkS0zW NwAEHgBlZEtM1jcABAMAZWRLTNY3YAAAa2TEHAAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB 4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/ mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEP Aw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAHwAAAyQBEmThAAAAE6QA ABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACsVuAAANbwAA VW8AAJ1vAADlbwAALXAAAHVwAAC9cAAABXEAABtxAABjcQAAq3EAAPNxAAA7cgAAg3IAAMtyAAAT cwAAKXMAACpzAABGcwAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAA AAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAA AAAAAAAAAADdAAAAAAAAAAAAAAAAzQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAEAAAAyQBE6QAABSkAAAWJAFJZgEAAABbJABcJABhJAEAERoADoTgAQ+EsAQUpOABXYTgAV6E sARlZJ08iTtnZEVGawAADxoADoTgAQ+EsARdhOABXoSwBGVknTyJO2dkRUZrAAATLHAAAC1wAAB0 cAAAdXAAALxwAAC9cAAABHEAAAVxAAAacQAAG3EAAGJxAABjcQAAqnEAAKtxAADycQAA83EAADpy AAA7cgAAgnIAAINyAADKcgAAy3IAABJzAAATcwAAKHMAACpzAABFcwAARnMAAEdzAABIcwAASXMA AItzAACMcwAAj3MAAJBzAACudAAAr3QAALJ0AACzdAAAT3UAAFB1AABTdQAAVHUAABJ2AAATdgAA FnYAABd2AADPdgAA0HYAAPjw+PD48Pjw+PD48Pjw+PD48Pjw+PD48Pjdzseyoo98j3yPfI98j3yP fI98j3yPfAAAAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAW aEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAA AHNICQAoA2pkHgAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAMFWh2THcAFmja WPcAAB0VaHZMdwAWaNpY9wBCKgFPSgMAUUoDAHBoAAAAACUWaEVGawA1CIFCKgFDSg8AT0oFAFFK BQBcCIFhSg8AcGgAAAAADhZoRUZrAG1ICQBzSAkAAA4WaNpY9wBtSAkAc0gJADBGcwAAR3MAAElz AACMcwAAkHMAAK90AACzdAAAUHUAAFR1AAATdgAAF3YAANB2AAC2AAAAAAAAAAAAAAAAqgAAAAAA AAAAAAAAAKUAAAAAAAAAAAAAAACQAAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAGIAAAAAAAAAAAAA AAB5AAAAAAAAAAAAAAAAYgAAAAAAAAAAAAAAAHkAAAAAAAAAAAAAAABiAAAAAAAAAAAAAAAAeQAA AAAAAAAAAAAAAAAAAAAAABYAAA6EsAQPhLAEE6QAABSkAABbJABcJABdhLAEXoSwBGVk3jaNEGdk RUZrAAAWAAAOhLAED4SABxOkAAAUpAAAWyQAXCQAXYSwBF6EgAdlZN42jRBnZEVGawAAFAAADoSw BA+EsAQUpAAAWyQAXCQAXYSwBF6EsARlZN42jRBnZEVGawAABB4AZWRLTNY3AAsAABOkAAAUpAAA WyQAXCQAZWRLTNY3SQAAa2T+HQAAFiQBFyQBSWYBAAAAZWRLTNY3AFQBAAjWGgAB4v8aB4BCAAAA AAAAAAAAAAAAAAAAAAAACnQAAKAEFPYBAAAVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3W BAAAAP8z1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN4pUAQAAC9B2AADTdgAA1HYA ANp3AADbdwAA3ncAAN93AABjeAAAZXgAAGZ4AABneAAAaHgAAHx4AAB9eAAAfngAAIF4AACCeAAA g3gAAIR4AACFeAAAnXgAAJ54AACleAAAsXgAANV4AADs2ezZ7Nns2cTZubK5nouedGVeVk7sPuwf FmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAA4WaNpY9wBtSAkAc0gJAAAOFmhFRmsAbUgJ AHNICQAADBVodkx3ABZo2lj3AAAdFWh2THcAFmjaWPcAQioIT0oDAFFKAwBwaP///wAtA2oAAAAA FWh2THcAFmgaN/IANQiBQioIQ0oUAE9KBABRSgQAVQgBcGj///8AJBVodkx3ABZoRUZrADUIgUIq CENKFABPSgQAUUoEAHBo////AAAnFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAbygBcGj/ //8ADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBKANqBh8AABZoGjfyAEIqAU9K AwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAA AHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAAAY0HYAANR2AADbdwAA 33cAAGR4AABleAAAZ3gAAIR4AADoAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAAAOgAAAAAAAAAAAAA AAC8AAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAALAAAAAAAAAAAAAAAACRAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfAAADJAES ZOEAAAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAWdkb2geAAAL AAATpAAAFKQAAFskAFwkAGVkS0zWNwAUAAAOhLAED4SABxOkAABbJABcJABdhLAEXoSAB2Vk3jaN EGdkRUZrAAAWAAAOhLAED4SABxOkAAAUpAAAWyQAXCQAXYSwBF6EgAdlZN42jRBnZEVGawAAFgAA DoSwBA+EsAQTpAAAFKQAAFskAFwkAF2EsARehLAEZWTeNo0QZ2RFRmsAAAeEeAAAhXgAAJ54AAB6 egAAGnsAAA59AADFfQAA9H4AAG9/AADrfwAAZYAAABaBAACfAAAAAAAAAAAAAAAAmgAAAAAAAAAA AAAAAJUAAAAAAAAAAAAAAACVAAAAAAAAAAAAAAAAggAAAAAAAAAAAAAAAIIAAAAAAAAAAAAAAACC AAAAAAAAAAAAAAAAlQAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAbwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAATAAAKJgALRgMADoTAAw+EkAZd hMADXoSQBmVkS0zWN2dkb2geABMAAAomAAtGAgAOhMADD4SQBl2EwANehJAGZWRLTNY3Z2RvaB4A AAQeAGVkS0zWNwAEAwBlZEtM1jdgAABrZKIfAAAWJAEXJAFJZgEAAABlZEtM1jcHlOEACNYaAAHi /zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+Z AAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8D DwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAAAAAAC9V4AADWeAAAeXoAAHp6 AACZegAAmnoAABZ7AAAXewAAGXsAABp7AAANfQAADn0AAMR9AADFfQAA834AAPR+AABufwAAb38A AOp/AADrfwAAZIAAAGWAAAAVgQAAF4EAABiBAAAZgQAAGoEAAC6BAAAvgQAAMIEAADOBAAA0gQAA NYEAADaBAAD14s/i9eL14s/iz+LP4s/iz+LP4s/iz7rPr6ivlIGUalsAAAAAAAAAAAAAAAAAHRVo dkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABP SgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVo dkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////AAwVaHZMdwAWaBo38gAAFQNqAAAA ABVodkx3ABZoGjfyAFUIASgDajogAAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkA ACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9K AwBRSgMAbUgJAHBoAAAAAHNICQATA2oAAAAAFmjkfO0AMEpCAFUIAQAhFoEAABeBAAAZgQAANoEA ADeBAABIgQAAS4IAAG2DAABthQAAboUAAHCFAADzAAAAAAAAAAAAAAAA8wAAAAAAAAAAAAAAANQA AAAAAAAAAAAAAAB0AAAAAAAAAAAAAAAAbwAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAABXAAAAAAAA AAAAAAAAVwAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADzAAAAAAAAAAAAAAAAEwAACiYAC0YEAA6E wAMPhJAGXYTAA16EkAZlZEtM1jdnZG9oHgAABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtk1iAAABYk ARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQA AKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA /xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYK AAAA/5kAAAAAAB8AAAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAA WyQAXCQAYSQBZ2RvaB4AAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3AAo2gQAAN4EAAEeBAABIgQAA wYEAAMKBAAAgggAAIYIAAEqCAABLggAAbIMAAG2DAAAUhAAAFoQAAGyFAABuhQAAb4UAAHCFAABx hQAAhYUAAIaFAACHhQAAioUAAIuFAACMhQAA+fHp1szWzNa51rnWqda5lLmJgoluW25EAAAAAAAA AAAAAAAALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZM dwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABP SgQAUUoEAG8oAXBo////AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDam4h AAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAAB8WaEVGawBCKgFPSgMAUUoDAG1I CQBwaAAAAABzSAkAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQATA2oAAAAA FmjkfO0AMEpCAFUIASUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkADhZo2lj3 AG1ICQBzSAkAAA4WaEVGawBtSAkAc0gJAAAMFWh2THcAFmjaWPcAGHCFAACNhQAAjoUAAKWFAAAQ hwAAMIgAABeJAAAYiQAAGokAAOAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAewAAAAAAAAAAAAAA AHYAAAAAAAAAAAAAAAB2AAAAAAAAAAAAAAAAdgAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAABqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3AAQeAGVkS0zW NwAEAwBlZEtM1jdgAABrZAoiAAAWJAEXJAFJZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAA AAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPC ARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8D AABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAAAAAfAAADJAESZOEAAAATpAAAFKQAABYkARiE +P8ZhPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAWdkb2geAAAIjIUAAI2FAACOhQAApIUAAKWF AAAThgAASoYAAFaGAABmhgAA0YYAANqGAAAPhwAAEIcAAC+IAAAwiAAAoYgAAKmIAAC+iAAAxYgA ABaJAAAXiQAAGIkAABmJAAAaiQAAG4kAAC+JAAAwiQAANYkAAPDp4dnGtsa2xrbGo8ajxrbGtsaj k36Tc2xzVwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKRZoRUZrADUIgUIqCENK FABPSgQAUUoEAFwIgV5KBABhShQAcGj///8ADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmga N/IAVQgBKANqoiIAABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAHxZo2lj3AEIq AU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAA c0gJAB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBR SgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAW aNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8AABs1iQAANokAADeJAAA4iQAAWYkA AFqJAACFigAAhooAAL+KAADAigAAwooAANiKAADZigAA84oAAPSKAAAniwAAKIsAAFmLAABbiwAA i4sAAIyLAADEiwAAxosAACGMAAArjAAALIwAAC6MAAAvjAAAOIwAADmMAABZjAAAWowAAFuMAABo jAAAaYwAAIiMAACJjAAAwowAAMOMAADFjAAA24wAANyMAAD2jAAA94wAACiNAAAqjQAA5trTy8Ow nbCdw8vDy8PLw8vDy8PLw7CNg41zsHONsJ2wnbCdsJ3Dy8PLw8vDAB8WaNpY9wBCKgFPSgMAUUoD AG1ICQBwaAAAAABzSAkAEwNqAAAAABZo5HztADBKQgBVCAEfFmhFRmsAQioBT0oDAFFKAwBtSAkA cGgAAAAAc0gJACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZo RUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBz SAkAAAwVaHZMdwAWaNpY9wAAFxZo2lj3AEIqCE9KAwBRSgMAcGj///8AMgNqAAAAABZoGjfyADUI gUIqCENKFABPSgQAUUoEAFUIAVwIgV5KBABhShQAcGj///8ALRqJAAA3iQAAOIkAAFqJAACGigAA wIoAAMGKAADCigAA2YoAAPSKAAAoiwAAWosAAFuLAADjAAAAAAAAAAAAAAAAgwAAAAAAAAAAAAAA AH4AAAAAAAAAAAAAAAB5AAAAAAAAAAAAAAAAeQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAA AAAAAAAAAAAAaQAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAaQAAAAAAAAAA AAAAAGkAAAAAAAAAAAAAAAAAAAAPGgAOhOABD4SwBF2E4AFehLAEZWTGa81kZ2RFRmsAAAQeAGVk S0zWNwAEAwBlZEtM1jdgAABrZD4jAAAWJAEXJAFJZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbC AQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU 9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYA AQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAAAAAcAAADJAESZOEAAAATpAAAFKQAABYk ARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAQAMW4sAAIyLAADFiwAAxosAAC+MAAA5 jAAAW4wAAGmMAACJjAAAw4wAAMSMAADFjAAA3IwAAPeMAAApjQAAKo0AAGCNAADvAAAAAAAAAAAA AAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAAMcA AAAAAAAAAAAAAACwAAAAAAAAAAAAAAAAmwAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAACLAAAAAAAA AAAAAAAAiwAAAAAAAAAAAAAAAIsAAAAAAAAAAAAAAACLAAAAAAAAAAAAAAAAiwAAAAAAAAAAAAAA AIsAAAAAAAAAAAAAAACLAAAAAAAAAAAAAAAAAAAADxoADoTgAQ+EsARdhOABXoSwBGVkoyhdbmdk RUZrAAAUAAAOhLAED4SABxOkAABbJABcJABdhLAEXoSAB2VkDGY+Q2dkRUZrAAAWAAAOhLAED4Sw BBOkAAAUpAAAWyQAXCQAXYSwBF6EsARlZAxmPkNnZG9oHgAAFgAADoSwBA+EgAcTpAAAFKQAAFsk AFwkAF2EsARehIAHZWQMZj5DZ2RvaB4AAAsAABOkAAAUpAAAWyQAXCQAZWQMZj5DAAQeAGVkS0zW NwAPGgAOhOABD4SwBF2E4AFehLAEZWTGa81kZ2RFRmsAABAqjQAAX40AAGCNAACLjQAAjI0AAMSN AADGjQAAvo4AAMqOAADMjgAAzo4AAM+OAADQjgAA0Y4AAOWOAADmjgAA544AAOqOAADrjgAA7I4A AO2OAADujgAAEI8AABGPAADykAAA+PD48Pjw3c3duqW6mpOaf2x/VUY/+PDNAAAMFWh2THcAFmja WPcAAB0VaHZMdwAWaNpY9wBCKghPSgMAUUoDAHBo////AC0DagAAAAAVaHZMdwAWaBo38gA1CIFC KghDShQAT0oEAFFKBABVCAFwaP///wAkFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAcGj/ //8AACcVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABvKAFwaP///wAMFWh2THcAFmgaN/IA ABUDagAAAAAVaHZMdwAWaBo38gBVCAEoA2rWIwAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgA AAAAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAB8WaEVGawBCKgFP SgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNI CQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAGGCNAACMjQAAxY0AAMaNAADNjgAAzo4A ANCOAADtjgAA7o4AABGPAADzkAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAA AAAA6gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAAvwAAAAAAAAAAAAAAAF8A AAAAAAAAAAAAAABaAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAAAAAAAAAAAEAwBlZEtM1jdgAABr ZHIkAAAWJAEXJAFJZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ 1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA /xvWBAAAAP8c1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0 S0zWN3DWCgAAAP+ZAAAAAAAfAAADJAESZOEAAAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQCL4Qt AElmAQAAAFskAFwkAGEkAWdkb2geAAALAAATpAAAFKQAAFskAFwkAGVkS0zWNwAEHgBlZEtM1jcA DxoADoTgAQ+EsARdhOABXoSwBGVkoyhdbmdkRUZrAAAK8pAAAPOQAAB6kgAAe5IAAMiSAADJkgAA 0JIAAN6SAADfkgAA7ZIAAFCTAABRkwAAYZMAAGKTAACCkwAAg5MAAPWTAAAjlAAAJJQAACaUAAA8 lAAAPZQAAFeUAABYlAAAiZQAAIuUAAC7lAAAvJQAAPuUAAD8lAAAFJUAABWVAABJlQAASpUAAIKV AACElQAAiZUAACaWAAAvlgAAIZcAACKXAACwlwAAsZcAAGWYAABmmAAAtZgAALaYAABtmQAAb5kA AHCZAABxmQAA79/v3+/fzLnM3+/f79/v38y5samxqbGpsamxqbGpsamxqbHM35/f79/v3+/f79/v iu8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAKANqCiUAABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBo AAAAAHNICQAAEhZoRUZrADBKHQBtSAkAc0gJAAAOFmhFRmsAbUgJAHNICQAADhZo2lj3AG1ICQBz SAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIq AU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAB8W aNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAADLzkAAAe5IAAMmSAADfkgAAUZMAAGKTAACD kwAAJJQAACWUAAAmlAAAPZQAAFiUAACKlAAAi5QAALyUAAD8lAAAFZUAAEqVAACDlQAAhJUAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA5QAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADJAAAAAAAA AAAAAAAA1QAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAuQAAAAAAAAAAAAAA ALQAAAAAAAAAAAAAAAC5AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAA AAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAA AAAAAKQAAAAAAAAAAAAAAAAAAA8aAA6E4AEPhLAEXYTgAV6EsARlZBcuiyRnZG9oHgAABBoAZWQX LoskAA8aAA6E4AEPhLAEXYTgAV6EsARlZBcuiyRnZEVGawAACwAAE6QAABSkAABbJABcJABlZFhk LDMADwAAD4TQAhOkAAAUpAAAWyQAXCQAXoTQAmVkWGQsMwAUAAAOhLAED4SwBBSkAABbJABcJABd hLAEXoSwBGVkWGQsM2dkRUZrAAAEHgBlZEtM1jcAE4SVAAAilwAAsZcAAGaYAAC2mAAAbpkAAG+Z AABxmQAAjpkAAI+ZAAC0mQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA 6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADeAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAAMIAAAAA AAAAAAAAAABiAAAAAAAAAAAAAAAAXQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAwBlZEtM1jdg AABrZKYlAAAWJAEXJAFJZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAA AAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYE AAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMA AGl0S0zWN3DWCgAAAP+ZAAAAAAAcAAADJAESZOEAAAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQC L4QtAElmAQAAAFskAFwkAGEkAQALAAATpAAAFKQAAFskAFwkAGVkS0zWNxAAAAomAAtGBQAOhOAB D4SwBF2E4AFehLAEZWRLTNY3AAQeAGVkS0zWNwAKcZkAAHKZAACGmQAAh5kAAIyZAACNmQAAjpkA AI+ZAACzmQAAtJkAABqaAACGmgAABpsAAAebAAAfnQAAIJ0AAH2dAAB+nQAAH54AACCeAABFnwAA Rp8AAEefAABInwAASZ8AAPTt9Ni+squjm4t4i2V4ZXiLeGV4ZVVAVQAAAAAoA2o+JgAAFmgaN/IA QioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAfFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAA c0gJACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIq AU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAA4W aNpY9wBtSAkAc0gJAAAOFmhFRmsAbUgJAHNICQAADBVodkx3ABZo2lj3AAAXFmjaWPcAQioIT0oD AFFKAwBwaP///wAyA2oAAAAAFmgaN/IANQiBQioIQ0oUAE9KBABRSgQAVQgBXAiBXkoEAGFKFABw aP///wAAKRZoRUZrADUIgUIqCENKFABPSgQAUUoEAFwIgV5KBABhShQAcGj///8ADBVodkx3ABZo GjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBABi0mQAAB5sAACCdAAAgngAARp8AAEefAABJnwAA Zp8AAGefAACDnwAAlaAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAANIAAAAAAAAAAAAAAAByAAAAAAAA AAAAAAAAbQAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEAwBlZEtM1jdgAABrZNomAAAWJAEXJAFJZgEAAABlZEtM1jcH lOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQt ABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/x6U LQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAAAAAcAAADJAES ZOEAAAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAQALAAATpAAA FKQAAFskAFwkAGVkS0zWNwAEHgBlZEtM1jcACkmfAABKnwAAXp8AAF+fAABknwAAZZ8AAGafAABn nwAAgp8AAIOfAABboAAAfKAAAJSgAACVoAAAoqAAAKOgAAAZoQAAHqEAAD+hAABDoQAAbaEAAHuh AADioQAA46EAAOyhAADtoQAAH6IAACCiAAAsogAALaIAAIGjAACCowAAh6MAAIijAADzowAA+KMA AMikAADJpAAAzqQAAM+kAACRpQAAkqUAAGimAAD07fTYvrKro5uIfohriGuIfoh+iH6Ia4hriGuI a4hriGuIfohriGuIa4glFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJABIWaEVG awAwSh0AbUgJAHNICQAAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmja WPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAFxZo2lj3AEIqCE9KAwBR SgMAcGj///8AMgNqAAAAABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAVwIgV5KBABhShQAcGj/ //8AACkWaEVGawA1CIFCKghDShQAT0oEAFFKBABcCIFeSgQAYUoUAHBo////AAwVaHZMdwAWaBo3 8gAAFQNqAAAAABVodkx3ABZoGjfyAFUIAQAqlaAAAKOgAADjoQAA7aEAACCiAAAtogAAgqMAAIij AADJpAAAz6QAAJKlAADRpgAAe6cAAHynAAB9pwAAt6cAAP2nAADqAAAAAAAAAAAAAAAA0wAAAAAA AAAAAAAAALwAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAANMAAAAAAAAAAAAA AAC8AAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAACnAAAAAAAAAAAAAAAAogAA AAAAAAAAAAAAAKIAAAAAAAAAAAAAAACSAAAAAAAAAAAAAAAAkgAAAAAAAAAAAAAAAJIAAAAAAAAA AAAAAACSAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPGgAOhOABD4SwBF2E4AFehLAEZWQl TqtNZ2RFRmsAAAQeAGVkS0zWNwAUAAAOhLAED4SABxOkAABbJABcJABdhLAEXoSAB2VksF0Df2dk RUZrAAAWAAAOhLAED4SwBBOkAAAUpAAAWyQAXCQAXYSwBF6EsARlZLBdA39nZEVGawAAFgAADoSw BA+EgAcTpAAAFKQAAFskAFwkAF2EsARehIAHZWSwXQN/Z2RFRmsAABQAAA6EsAQPhLAEFKQAAFsk AFwkAF2EsARehLAEZWSwXQN/Z2RFRmsAABBopgAAa6YAALumAAC/pgAA0KYAANGmAAB6pwAAe6cA AH2nAAC2pwAAt6cAAPynAAD9pwAAF6gAABmoAAD7qAAADKoAAD6qAAA/qgAA4aoAAOKqAAD/qwAA AKwAAI2tAACPrQAAkK0AAJGtAACSrQAApq0AAKetAACorQAAq60AAKytAAD24/bj0OPQyMDIwMjA yOOw49Dj0OPQ49Cb0JCJkHVidQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJBVodkx3 ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAHBo////AAAnFWh2THcAFmhFRmsANQiBQioIQ0oUAE9K BABRSgQAbygBcGj///8ADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBKANqcicA ABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAHxZoRUZrAEIqAU9KAwBRSgMAbUgJ AHBoAAAAAHNICQAOFmhFRmsAbUgJAHNICQAADhZo2lj3AG1ICQBzSAkAACUVaG9oHgAWaNpY9wBC KgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAA AHNICQASFmhFRmsAMEodAG1ICQBzSAkAIP2nAAAYqAAAGagAAD+qAADiqgAAAKwAAI6tAACPrQAA ka0AAK6tAACvrQAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAA AAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAA AAC/AAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAABrZA4oAAAWJAEX JAFJZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACg BA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c 1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAA AP+ZAAAAAAAfAAADJAESZOEAAAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAAAFsk AFwkAGEkAWdkb2geAAALAAATpAAAFKQAAFskAFwkAGVkS0zWNwAEHgBlZEtM1jcADxoADoTgAQ+E sARdhOABXoSwBGVkJU6rTWdkRUZrAAAKrK0AAK2tAACurQAAr60AAMutAADMrQAAuK4AALmuAAC9 rgAAvq4AAN+uAADjrgAA564AAPWuAACUrwAAs68AALivAAC/rwAAxK8AAM2vAADkrwAA/q8AAP+v AAB5sAAAyLAAAMmwAADVsAAA1rAAAPewAAD8sAAAALEAAA6xAABlsQAAZrEAAHCxAABxsQAAPLIA AD2yAAA+sgAASLIAAEmyAAC/sgAAw7IAAECzAABBswAA6NnSysKvnK+cr5Kvkq+Cr4Kvgq+Cr4Kv nK+cr5Kvkq9ygnKCr5yvnK+Sr5wAAAAAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAf FmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJABIWaEVGawAwSh0AbUgJAHNICQAAJRVob2ge ABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBt SAkAcGgAAAAAc0gJAA4WaNpY9wBtSAkAc0gJAAAOFmhFRmsAbUgJAHNICQAADBVodkx3ABZo2lj3 AAAdFWh2THcAFmjaWPcAQioIT0oDAFFKAwBwaP///wAtA2oAAAAAFWh2THcAFmgaN/IANQiBQioI Q0oUAE9KBABRSgQAVQgBcGj///8AACyvrQAAzK0AALmuAAC+rgAAybAAANawAABmsQAAcbEAAD6y AABJsgAAQbMAAEezAAAbtQAAIbUAAKS1AAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAOAAAAAA AAAAAAAAAADJAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAKIAAAAAAAAAAAAAAACWAAAAAAAAAAAA AAAAyQAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAADJAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAMkA AAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAA DoSwBA+EgAcTpAAAWyQAXCQAXYSwBF6EgAdlZHhvUixnZEVGawAACwAAE6QAABSkAABbJABcJABl ZHhvUiwADwAAD4TQAhOkAAAUpAAAWyQAXCQAXoTQAmVkeG9SLAAWAAAOhLAED4SwBBOkAAAUpAAA WyQAXCQAXYSwBF6EsARlZHhvUixnZEVGawAAFgAADoSwBA+EgAcTpAAAFKQAAFskAFwkAF2EsARe hIAHZWR4b1IsZ2RFRmsAABQAAA6EsAQPhLAEFKQAAFskAFwkAF2EsARehLAEZWR4b1IsZ2RFRmsA AAQeAGVkS0zWNwAEAwBlZEtM1jcADkGzAABGswAAR7MAAMWzAADKswAAGrUAABu1AAAgtQAAIbUA ADG1AAA2tQAAo7UAAKS1AABdtgAAarYAAHa2AAB3tgAAj7YAAJO2AADztgAAFLcAACy3AAAttwAA n7cAAKC3AACitwAAtrcAALe3AADwtwAA8rcAAAq4AAAPuAAAE7gAACG4AACEuAAApbgAAL24AAC+ uAAALrkAAF+5AABguQAAYbkAAGO5AAB3uQAAeLkAAK+5AACwuQAA3rkAAOC5AAANuwAAD7sAABC7 AAARuwAAErsAAOzZ7M/s2ezZ7M/s2ezP7Nnsz+zP7Nns2ce/x7/H7M+vz+zP7Nnsr+zZx7/Hv8e/ x+zZmtmPAAAAAAAAAAAAAAAAAAAAAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBKANqpigAABZoGjfy AEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAHxZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAA AHNICQAOFmhFRmsAbUgJAHNICQAADhZo2lj3AG1ICQBzSAkAABIWaEVGawAwSh0AbUgJAHNICQAA JRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oD AFFKAwBtSAkAcGgAAAAAc0gJAAA1pLUAAHe2AAAttwAAoLcAAKG3AACitwAAt7cAAPG3AADytwAA vrgAAGG5AABiuQAAY7kAAHi5AACwuQAA37kAAOC5AAAOuwAAD7sAABG7AAAuuwAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADq AAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAANoAAAAAAAAAAAAAAADaAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAANoAAAAAAAAAAAAA AADaAAAAAAAAAAAAAAAA2gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADOAAAAAAAAAAAAAAAAzgAA AAAAAAAAAAAAAK8AAAAAAAAAAAAAAAAAAAAAAAAfAAADJAESZOEAAAATpAAAFKQAABYkARiE+P8Z hPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAWdkb2geAAALAAATpAAAFKQAAFskAFwkAGVkS0zW NwAPGgAOhOABD4SwBF2E4AFehLAEZWSmWnEyZ2RFRmsAAA8aAA6E4AEPhLAEXYTgAV6EsARlZK10 +HlnZEVGawAABB4AZWRLTNY3ABQSuwAAJrsAACe7AAAouwAAK7sAACy7AAAtuwAALrsAAC+7AABD uwAARLsAAIC7AACpuwAAsbsAAMG7AABDvAAAZLwAAHy8AAB9vAAAgrwAAIO8AACzvAAAtLwAAMW8 AADGvAAAUr0AAFO9AABcvQAAXb0AAPnu2sfasKGakop3Z3dnd113SndKd0p3SndKd0oAAAAAJRVo b2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQASFmhFRmsAMEodAG1ICQBzSAkAAB8W aEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJ AHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAA HRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENK FABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAA JxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////ABUDagAAAAAVaHZMdwAWaBo3 8gBVCAEMFWh2THcAFmgaN/IAHC67AAAvuwAARLsAAH28AACDvAAAtLwAAMa8AABTvQAAXb0AAAC+ AACfAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAaQAA AAAAAAAAAAAAAFIAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAUgAAAAAAAAAAAAAAAGkAAAAAAAAA AAAAAAAAAAAAAAAAABYAAA6EsAQPhLAEE6QAABSkAABbJABcJABdhLAEXoSwBGVkcUAGJ2dkRUZr AAAWAAAOhLAED4SABxOkAAAUpAAAWyQAXCQAXYSwBF6EgAdlZHFABidnZEVGawAAFAAADoSwBA+E sAQUpAAAWyQAXCQAXYSwBF6EsARlZHFABidnZEVGawAABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtk PCkAABYkARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnW AqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/ G9YEAAAA/xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRL TNY3cNYKAAAA/5kAAAAAAAAJXb0AAP+9AAAAvgAABb4AAAa+AAAWvgAAG74AAIi+AACJvgAA+74A APy+AAD+vgAAEr8AABO/AABQvwAAUr8AACbAAAAnwAAAKMAAACnAAAAqwAAAK8AAAD/AAABAwAAA QcAAAETAAABFwAAA7Nns2ezP7Nns2ce/x7/Hr5/Zitl/eH9kUWQAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAJBVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAHBo////AAAnFWh2THcAFmhF RmsANQiBQioIQ0oUAE9KBABRSgQAbygBcGj///8ADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcA FmgaN/IAVQgBKANq1CkAABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAHxZo2lj3 AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJ AA4WaEVGawBtSAkAc0gJAAAOFmjaWPcAbUgJAHNICQAAEhZoRUZrADBKHQBtSAkAc0gJAAAlFWhv aB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAWaEVGawBCKgFPSgMAUUoD AG1ICQBwaAAAAABzSAkAABoAvgAABr4AAIm+AAD8vgAA/b4AAP6+AAATvwAAUb8AAFK/AAAnwAAA KMAAACrAAABHwAAA6AAAAAAAAAAAAAAAANMAAAAAAAAAAAAAAADOAAAAAAAAAAAAAAAAvgAAAAAA AAAAAAAAAL4AAAAAAAAAAAAAAAC+AAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAAL4AAAAAAAAAAAAA AADOAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACTAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfAAADJAESZOEAAAATpAAAFKQAABYkARiE+P8ZhPj/ GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAWdkb2geAAALAAATpAAAFKQAAFskAFwkAGVkS0zWNwAP GgAOhOABD4SwBF2E4AFehLAEZWSiNItIZ2RFRmsAAAQeAGVkS0zWNwAUAAAOhLAED4SABxOkAABb JABcJABdhLAEXoSAB2VkcUAGJ2dkRUZrAAAWAAAOhLAED4SwBBOkAAAUpAAAWyQAXCQAXYSwBF6E sARlZHFABidnZEVGawAADEXAAABGwAAAR8AAAEjAAABbwAAAXMAAALjAAAC5wAAAyMAAAMnAAABH wQAASMEAAFbBAABXwQAAgsEAAIPBAACWwQAAl8EAANjBAADZwQAA7sEAAO/BAAAzwgAANMIAAEHC AABCwgAAe8IAAHzCAACVwgAAlsIAAODCAADhwgAA7sIAAO/CAAAmwwAAJ8MAAFXDAABXwwAAWMMA AFnDAABawwAAbsMAAG/DAADo2dLKwq+cr5yvnK+cr5yvnK+cr5yvnK+cr5yvnK+cr5yvnK+ch5x8 dXwAAAAAAAAAAAAAAAAAAAAAAAAAAAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUI ASgDaggrAAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAACUVaG9oHgAWaNpY9wBC KgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAA AHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3 ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQA UUoEAFUIAXBo////AAAqR8AAAEjAAABcwAAAucAAAMnAAABIwQAAV8EAAIPBAACXwQAA2cEAAJ8A AAAAAAAAAAAAAACaAAAAAAAAAAAAAAAAlQAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAABpAAAAAAAA AAAAAAAAUgAAAAAAAAAAAAAAAGkAAAAAAAAAAAAAAABSAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAA AAAAAAAAAAAAFgAADoSwBA+EsAQTpAAAFKQAAFskAFwkAF2EsARehLAEZWQ4Wb5bZ2RFRmsAABYA AA6EsAQPhIAHE6QAABSkAABbJABcJABdhLAEXoSAB2VkOFm+W2dkRUZrAAAUAAAOhLAED4SwBBSk AABbJABcJABdhLAEXoSwBGVkOFm+W2dkRUZrAAAEHgBlZEtM1jcABAMAZWRLTNY3YAAAa2RwKgAA FiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEK dAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQA AAD/HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw 1goAAAD/mQAAAAAAAAnZwQAA78EAADTCAABCwgAAfMIAAJbCAADhwgAA78IAACfDAABWwwAAV8MA AFnDAAB2wwAA6AAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAAOgAAAAAAAAAAAAAAADRAAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAAC3 AAAAAAAAAAAAAAAAqwAAAAAAAAAAAAAAAKsAAAAAAAAAAAAAAACMAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABb JABcJABhJAFnZG9oHgAACwAAE6QAABSkAABbJABcJABlZEtM1jcABB4AZWRLTNY3ABQAAA6EsAQP hIAHE6QAAFskAFwkAF2EsARehIAHZWQ4Wb5bZ2RFRmsAABYAAA6EsAQPhIAHE6QAABSkAABbJABc JABdhLAEXoSAB2VkOFm+W2dkRUZrAAAWAAAOhLAED4SwBBOkAAAUpAAAWyQAXCQAXYSwBF6EsARl ZDhZvltnZEVGawAADG/DAABwwwAAc8MAAHTDAAB1wwAAdsMAAHfDAACUwwAAlcMAAG7EAABvxAAA ssQAALjEAADcxQAA3cUAABPGAAAXxgAAg8YAAITGAAC7xgAAvMYAACLIAAAjyAAAdcgAAJbIAAC/ yAAAwMgAAMrIAADLyAAAGckAACvJAAAtyQAANckAADfJAABEyQAARskAAOvY68Gyq6ObiHWIZYh1 iFuIZYh1iHWIW4h1iHWIW4hbiFuIAAAAEhZoRUZrADBKHQBtSAkAc0gJAAAfFmhFRmsAQioBT0oD AFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkA JRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZo RUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8A LQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVG awA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoE AG8oAXBo////AAAjdsMAAHfDAACVwwAAb8QAAN3FAAC8xgAAI8gAAMDIAADLyAAAtckAAJ8AAAAA AAAAAAAAAACaAAAAAAAAAAAAAAAAlQAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACVAAAAAAAAAAAA AAAAlQAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAaQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYAAA6E sAQPhIAHE6QAABSkAABbJABcJABdhLAEXoSAB2VkMxtpLmdkRUZrAAAUAAAOhLAED4SwBBSkAABb JABcJABdhLAEXoSwBGVkMxtpLmdkRUZrAAAEHgBlZEtM1jcABAMAZWRLTNY3YAAAa2SkKwAAFiQB FyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAA oAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/ HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goA AAD/mQAAAAAAAAlGyQAATckAAFjJAACZyQAAnskAALPJAAC0yQAAtckAALrJAAC7yQAAJsoAACvK AACyywAA+MsAAPnLAAD6ywAAdswAAHfMAAAZzQAAG80AABzNAAAdzQAAHs0AADLNAAAzzQAANM0A ADfNAAA4zQAAOc0AAPft3crdyrfKt8rtyt3Kt8q3yreit5eQl3xpfFIAAAAAAAAAAAAAAAAAAAAA AAAAAC0DagAAAAAVaHZMdwAWaBo38gA1CIFCKghDShQAT0oEAFFKBABVCAFwaP///wAkFWh2THcA FmhFRmsANQiBQioIQ0oUAE9KBABRSgQAcGj///8AACcVaHZMdwAWaEVGawA1CIFCKghDShQAT0oE AFFKBABvKAFwaP///wAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo38gBVCAEoA2o8LAAA FmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFK AwBtSAkAcGgAAAAAc0gJACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAHxZo RUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQASFmhFRmsAMEodAG1ICQBzSAkAABAVaG9oHgAW aEVGawAwSh0AHLXJAAC7yQAA+ssAAHfMAAAazQAAG80AAB3NAAA6zQAA6AAAAAAAAAAAAAAAANMA AAAAAAAAAAAAAADOAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAADCAAAAAAAA AAAAAAAAowAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAyQB EmThAAAAE6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAA CwAAE6QAABSkAABbJABcJABlZEtM1jcABB4AZWRLTNY3ABQAAA6EsAQPhIAHE6QAAFskAFwkAF2E sARehIAHZWQzG2kuZ2RFRmsAABYAAA6EsAQPhLAEE6QAABSkAABbJABcJABdhLAEXoSwBGVkMxtp LmdkRUZrAAAHOc0AADrNAAA7zQAAU80AAFTNAAB+zQAAgM0AAJXNAACkzQAAus0AAM7NAADbzQAA 6c0AAOvNAADszQAA7c0AAO7NAADvzQAA8M0AAATOAAAFzgAACs4AAAvOAADw6eHZxrbGtsa2xrbG o5N+k3Nsc1c9AAAAAAAAAAAyA2oAAAAAFmgaN/IANQiBQioIQ0oUAE9KBABRSgQAVQgBXAiBXkoE AGFKFABwaP///wAAKRZoRUZrADUIgUIqCENKFABPSgQAUUoEAFwIgV5KBABhShQAcGj///8ADBVo dkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBKANqcC0AABZoGjfyAEIqAU9KAwBRSgMA VQgBbUgJAHBoAAAAAHNICQAAHxZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4A FmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAA AABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNI CQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMA cGj///8AABY6zQAAO80AAFTNAADszQAA7c0AAO/NAAAMzgAAnwAAAAAAAAAAAAAAAJoAAAAAAAAA AAAAAACVAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAAIkAAAAAAAAAAAAAAABtAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwA AAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBAAsA ABOkAAAUpAAAWyQAXCQAZWRLTNY3AAQeAGVkS0zWNwAEAwBlZEtM1jdgAABrZNgsAAAWJAEXJAFJ ZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02 IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQA AAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+Z AAAAAAAABgvOAAAMzgAADc4AACfOAAAozgAAXc4AAG/OAACgzgAAoc4AAKXOAACmzgAA784AAPDO AAD8zgAA/c4AADjPAAA5zwAAns8AAKvPAAAU0AAAFdAAABfQAAAt0AAALtAAAEjQAABJ0AAAetAA AHzQAACx0AAAstAAAN3QAADe0AAAFtEAABjRAAA30QAAONEAAJPRAACU0QAA+9EAAPzRAABd0gAA X9IAAGDSAABh0gAAYtIAAHbSAAB30gAA8+zk3Mm/yazJrMmsyazJrMm/yazc5Nzk3OTc5Nzk3OTc yazJrMmsyayXrIyFjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADBVodkx3ABZoGjfy AAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBKANqpC4AABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBo AAAAAHNICQAAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQASFmhFRmsAMEod AG1ICQBzSAkAACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkADhZo2lj3AG1I CQBzSAkAAA4WaEVGawBtSAkAc0gJAAAMFWh2THcAFmjaWPcAABcWaNpY9wBCKghPSgMAUUoDAHBo ////AAAuDM4AAA3OAAAozgAAoc4AAKbOAADwzgAA/c4AAJ8AAAAAAAAAAAAAAACaAAAAAAAAAAAA AAAAlQAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAABpAAAAAAAAAAAAAAAAUgAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FgAADoSwBA+EsAQTpAAAFKQAAFskAFwkAF2EsARehLAEZWTTMj9GZ2RFRmsAABYAAA6EsAQPhIAH E6QAABSkAABbJABcJABdhLAEXoSAB2Vk0zI/RmdkRUZrAAAUAAAOhLAED4SwBBSkAABbJABcJABd hLAEXoSwBGVk0zI/RmdkRUZrAAAEHgBlZEtM1jcABAMAZWRLTNY3YAAAa2QMLgAAFiQBFyQBSWYB AAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAO lPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA /x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAA AAAAAAb9zgAAOc8AABXQAAAW0AAAF9AAAC7QAABJ0AAAe9AAAHzQAACy0AAA3tAAABfRAAAY0QAA ONEAAJTRAAD80QAAXtIAAF/SAABh0gAA6gAAAAAAAAAAAAAAAOUAAAAAAAAAAAAAAADVAAAAAAAA AAAAAAAA1QAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAA ANUAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADVAAAA AAAAAAAAAAAA5QAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAA5QAAAAAAAAAA AAAAALYAAAAAAAAAAAAAAAC2AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3EwAACiYA C0YGAA6EwAMPhJAGXYTAA16EkAZlZEtM1jdnZG9oHgAADxoADoTgAQ+EsARdhOABXoSwBGVkxVl1 UGdkRUZrAAAEHgBlZEtM1jcAFAAADoSwBA+EgAcTpAAAWyQAXCQAXYSwBF6EgAdlZNMyP0ZnZEVG awAAEnfSAAB40gAAe9IAAHzSAAB90gAAftIAAH/SAACq0gAAq9IAAOjSAADw0gAAaNMAAGnTAABx 0wAActMAAJvTAACc0wAApNMAAKXTAADO0wAAz9MAADTUAABB1AAAqtQAAKvUAACt1AAAw9QAAMTU AADe1AAA39QAABDVAAAS1QAAPdUAAD7VAAB31QAAedUAABvWAAAd1gAA69jrwbKro5uIfohriGuI a4hriGuIfohrm6Obo5ujm6Obo5uIawAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlFWhvaB4AFmja WPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJABIWaEVGawAwSh0AbUgJAHNICQAAJRVob2geABZo RUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBz SAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVo dkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghD ShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo//// AAAlYdIAAH7SAAB/0gAAq9IAAGnTAABy0wAAnNMAAOAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAA ewAAAAAAAAAAAAAAAHYAAAAAAAAAAAAAAABhAAAAAAAAAAAAAAAASgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAAOhLAED4SABxOkAAAUpAAA WyQAXCQAXYSwBF6EgAdlZFVFyXpnZEVGawAAFAAADoSwBA+EsAQUpAAAWyQAXCQAXYSwBF6EsARl ZFVFyXpnZEVGawAABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtkQC8AABYkARckAUlmAQAAAGVkS0zW NweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8Q lC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/ HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAB8AAAMk ARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBZ2RvaB4A AAac0wAApdMAAM/TAACr1AAArNQAAK3UAADE1AAA39QAABHVAAAS1QAAPtUAAHjVAAB51QAAHNYA AB3WAAAf1gAAPNYAAOgAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAAL4AAAAA AAAAAAAAAAC+AAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAAL4AAAAAAAAAAAAAAAC+AAAAAAAAAAAA AAAAvgAAAAAAAAAAAAAAAL4AAAAAAAAAAAAAAAC+AAAAAAAAAAAAAAAAvgAAAAAAAAAAAAAAAM4A AAAAAAAAAAAAAACyAAAAAAAAAAAAAAAAsgAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAfAAADJAESZOEAAAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAA AFskAFwkAGEkAWdkb2geAAALAAATpAAAFKQAAFskAFwkAGVkS0zWNwAPGgAOhOABD4SwBF2E4AFe hLAEZWTTSqFvZ2RFRmsAAAQeAGVkS0zWNwAUAAAOhLAED4SABxOkAABbJABcJABdhLAEXoSAB2Vk VUXJemdkRUZrAAAWAAAOhLAED4SwBBOkAAAUpAAAWyQAXCQAXYSwBF6EsARlZFVFyXpnZEVGawAA EB3WAAAe1gAAH9YAACDWAAA01gAANdYAADbWAAA51gAAOtYAADvWAAA81gAAPdYAAFfWAABY1gAA q9YAAL3WAADs1wAA7tcAAOvYzcbNsp+yiHlyamJSSFI4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAf FmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJABIWaEVGawAwSh0AbUgJAHNICQAAHxZoRUZr AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkA AAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3 ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQA T0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////AAwV aHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASUVaG9oHgAWaNpY9wBCKgFPSgMAUUoD AG1ICQBwaAAAAABzSAkAKANq2C8AABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAR PNYAAD3WAABY1gAA7dcAAO7XAADw1wAADdgAAJ8AAAAAAAAAAAAAAACaAAAAAAAAAAAAAAAAlQAA AAAAAAAAAAAAAIkAAAAAAAAAAAAAAACJAAAAAAAAAAAAAAAAbQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcAAADJAESZOEA AAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAQALAAATpAAAFKQA AFskAFwkAGVkS0zWNwAEHgBlZEtM1jcABAMAZWRLTNY3YAAAa2R0MAAAFiQBFyQBSWYBAAAAZWRL TNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4 /xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAA AP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAAAbu 1wAA79cAAPDXAADx1wAABdgAAAbYAAAL2AAADNgAAA3YAAAO2AAAI9gAACTYAABU2AAAYdgAAJHY AACS2AAAn9gAAKDYAADu2AAA79gAAFTZAABh2QAAedkAAOvb0MnQtJqOh393ZFpkR2RHZEdkWmQA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBo AAAAAHNICQASFmhFRmsAMEodAG1ICQBzSAkAACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBw aAAAAABzSAkADhZo2lj3AG1ICQBzSAkAAA4WaEVGawBtSAkAc0gJAAAMFWh2THcAFmjaWPcAABcW aNpY9wBCKghPSgMAUUoDAHBo////ADIDagAAAAAWaBo38gA1CIFCKghDShQAT0oEAFFKBABVCAFc CIFeSgQAYUoUAHBo////AAApFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAXAiBXkoEAGFKFABwaP// /wAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo38gBVCAEfFmjaWPcAQioBT0oDAFFKAwBt SAkAcGgAAAAAc0gJACgDagwxAAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAFg3Y AAAO2AAAJNgAAJLYAACg2AAA79gAAMvZAADM2QAAzdkAAOTZAAD/2QAAnwAAAAAAAAAAAAAAAJoA AAAAAAAAAAAAAACVAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAGsAAAAAAAAAAAAAAACVAAAAAAAA AAAAAAAAWwAAAAAAAAAAAAAAAFsAAAAAAAAAAAAAAABbAAAAAAAAAAAAAAAAWwAAAAAAAAAAAAAA AAAAAAAAAAAAAA8aAA6E4AEPhLAEXYTgAV6EsARlZP9fxUlnZEVGawAAFAAADoSwBA+EgAcTpAAA WyQAXCQAXYSwBF6EgAdlZNstsz1nZEVGawAAFAAADoSwBA+EsAQUpAAAWyQAXCQAXYSwBF6EsARl ZNstsz1nZEVGawAABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtkqDEAABYkARckAUlmAQAAAGVkS0zW NweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8Q lC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/ HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAAAKedkA AMrZAADL2QAAzdkAAOPZAADk2QAA/tkAAP/ZAAAw2gAAMtoAAGLaAABj2gAAldoAAJfaAACi2wAA Q9wAAETcAABG3AAAR9wAAEjcAABJ3AAAXdwAAF7cAABf3AAAYtwAAGPcAABk3AAA79/Xz9fP18/X z9fP17zvvKmUqYmCiW5bbkQAAC0DagAAAAAVaHZMdwAWaBo38gA1CIFCKghDShQAT0oEAFFKBABV CAFwaP///wAkFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAcGj///8AACcVaHZMdwAWaEVG awA1CIFCKghDShQAT0oEAFFKBABvKAFwaP///wAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAW aBo38gBVCAEoA2pAMgAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAlFWhvaB4A FmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1I CQBwaAAAAABzSAkADhZoRUZrAG1ICQBzSAkAAA4WaNpY9wBtSAkAc0gJAAAfFmjaWPcAQioBT0oD AFFKAwBtSAkAcGgAAAAAc0gJAB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAABr/2QAA MdoAADLaAABj2gAAltoAAJfaAABF3AAARtwAAEjcAABl3AAA7wAAAAAAAAAAAAAAAO8AAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADfAAAAAAAAAAAAAAAA yAAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAACdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8AAAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8b JiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBZ2RvaB4AAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3ABYA AA6E4AEPhOABE6TgARSkAABbJABcJABdhOABXoTgAWVkS0zWN2dkRUZrAAAPHgAOhMADD4TAA12E wANehMADZWSrA7hMZ2RvaB4AAA8aAA6E4AEPhLAEXYTgAV6EsARlZP9fxUlnZEVGawAACWTcAABl 3AAAZtwAAHfcAAB43AAAjNwAAI7cAACZ3AAAp9wAAKvcAAC03AAAvNwAANPcAAD53AAAAd0AAAjd AAAP3QAAGd0AAErdAABL3QAATN0AAFXdAABW3QAAb90AAHDdAAAu3gAAL94AADHeAABH3gAASN4A AGLeAABj3gAAlN4AAJbeAADV3gAA1t4AAA3fAAAP3wAA7t8AAPjfAAAv4AAAMOAAACXhAAAn4QAA KOEAACnhAADw6eHZxrbGtsanxrbGtsa2nbbGisaKxorGitnh2eHZ4dnh2eHZxrbGisaKdYoAAAAA ACgDanQzAAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAACUVaG9oHgAWaNpY9wBC KgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAEhZoRUZrADBKHQBtSAkAc0gJAAAdFWhvaB4AFmhFRmsA QioBT0oDAFFKAwBwaAAAAAAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAW aEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkADhZo2lj3AG1ICQBzSAkAAA4WaEVGawBtSAkA c0gJAAAMFWh2THcAFmjaWPcAAB0VaHZMdwAWaNpY9wBCKghPSgMAUUoDAHBo////AAAtZdwAAGbc AAB43AAATN0AAFbdAABw3QAAL94AADDeAAAx3gAAnwAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAACK AAAAAAAAAAAAAAAAcwAAAAAAAAAAAAAAAF4AAAAAAAAAAAAAAABZAAAAAAAAAAAAAAAASQAAAAAA AAAAAAAAAEkAAAAAAAAAAAAAAAAAAAAAAAAADxoADoTgAQ+EsARdhOABXoSwBGVkEhEwL2dkRUZr AAAEHgBlZEtM1jcAFAAADoSwBA+EgAcTpAAAWyQAXCQAXYSwBF6EgAdlZIkGSnRnZEVGawAAFgAA DoSwBA+EsAQTpOABFKQAAFskAFwkAF2EsARehLAEZWSJBkp0Z2RFRmsAAA8eAA6EwAMPhMADXYTA A16EwANlZGhA30FnZG9oHgAABAMAZWRLTNY3YAAAa2TcMgAAFiQBFyQBSWYBAAAAZWRLTNY3B5Th AAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS 1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0A M9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAAAgx3gAASN4A AGPeAACV3gAAlt4AANbeAAAO3wAAD98AADDgAAAm4QAAJ+EAACnhAABG4QAA7wAAAAAAAAAAAAAA AO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAA AAAAAAAAAAAA7wAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA3gAAAAAAAAAA AAAAAN4AAAAAAAAAAAAAAAC/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEY hPj/GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACwAAE6QAABSkAABbJABcJABl ZEtM1jcABB4AZWRLTNY3AA8aAA6E4AEPhLAEXYTgAV6EsARlZBIRMC9nZEVGawAADCnhAAAq4QAA PuEAAD/hAABA4QAAQ+EAAEThAABF4QAARuEAAEfhAABi4QAAY+EAAI/iAACQ4gAAxuIAAMfiAADT 4gAA1OIAABPjAAAU4wAAHuMAAB/jAADB4wAAwuMAAMPjAADN4wAAzuMAAPTt9NnG2a+gmZGJdmN2 Y3ZjdlNDU0N2Y3ZjHxZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmjaWPcAQioBT0oD AFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkA JRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZo RUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8A LQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVG awA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoE AG8oAXBo////AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIAQAaRuEAAEfhAABj 4QAAkOIAAMfiAADU4gAAFOMAAB/jAADD4wAAnwAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAACVAAAA AAAAAAAAAAAAlQAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAZAAAAAAAAAAA AAAAAE0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAAOhLAED4SABxOkAAAUpAAAWyQAXCQA XYSwBF6EgAdlZGNKp01nZEVGawAACwAAE6QAABSkAABbJABcJABlZGNKp00ADwAAD4TQAhOkAAAU pAAAWyQAXCQAXoTQAmVkY0qnTQAUAAAOhLAED4SwBBSkAABbJABcJABdhLAEXoSwBGVkY0qnTWdk RUZrAAAEHgBlZEtM1jcABAMAZWRLTNY3YAAAa2QKNAAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjW GgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goA AAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YG AAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAAAjD4wAAzuMAAKfk AAC15AAAr+UAALXlAABq5wAAwugAAHvpAACJ6QAAiukAAIvpAACd6QAAvukAANjpAADZ6QAA3ekA AP7pAAAa6gAA6AAAAAAAAAAAAAAAANEAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA0QAAAAAAAAAA AAAAAOgAAAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAAtwAAAAAAAAAAAAAAALcAAAAAAAAAAAAAAAC3 AAAAAAAAAAAAAAAApwAAAAAAAAAAAAAAAKcAAAAAAAAAAAAAAACnAAAAAAAAAAAAAAAApwAAAAAA AAAAAAAAAKcAAAAAAAAAAAAAAACnAAAAAAAAAAAAAAAApwAAAAAAAAAAAAAAAKcAAAAAAAAAAAAA AACiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBoAZWTnE1pKAA8aAA6E4AEPhLAEXYTgAV6E sARlZOcTWkpnZEVGawAABB4AZWRLTNY3ABQAAA6EsAQPhIAHE6QAAFskAFwkAF2EsARehIAHZWRj SqdNZ2RFRmsAABYAAA6EsAQPhIAHE6QAABSkAABbJABcJABdhLAEXoSAB2VkY0qnTWdkRUZrAAAW AAAOhLAED4SwBBOkAAAUpAAAWyQAXCQAXYSwBF6EsARlZGNKp01nZEVGawAAEs7jAAAl5AAAKeQA AKbkAACn5AAAtOQAALXkAACB5QAAreUAAK7lAACv5QAAtOUAALXlAAAU5gAAGeYAAGnnAABq5wAA uecAAMnnAADB6AAAwugAAPHoAAD+6AAAJekAAC3pAAB66QAAe+kAAIjpAACJ6QAAi+kAAJzpAACd 6QAAvekAAL7pAADX6QAA2ekAANzpAADd6QAA/ekAAP7pAAAZ6gAAGuoAADDqAAAx6gAAUeoAAFLq AABV6gAAV+oAAITrAACG6wAAh+sAAIjrAACJ6wAAnesAAOzi7M/sz+y/7M/sz+zi7M/s4uzP7OLs 4uzP7M+3r7evt6+3r7evt6+3r7evt6+37M+az4+IAAAADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2 THcAFmgaN/IAVQgBKANqojQAABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAADhZo RUZrAG1ICQBzSAkAAA4WaNpY9wBtSAkAc0gJAAAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAA c0gJACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAEhZoRUZrADBKHQBtSAkA c0gJAAAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAAA1GuoAADHqAABS6gAA VuoAAFfqAACF6wAAhusAAIjrAACl6wAApusAALvrAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAA AO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAADeAAAA AAAAAAAAAAAAvwAAAAAAAAAAAAAAAF8AAAAAAAAAAAAAAABaAAAAAAAAAAAAAAAAAAAAAAAAAAQD AGVkS0zWN2AAAGtkPjUAABYkARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAA AAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYB F/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMAAELW AwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAB8AAAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE +P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBZ2RvaB4AAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3 AAQeAGVkS0zWNwAPGgAOhOABD4SwBF2E4AFehLAEZWTnE1pKZ2RFRmsAAAqd6wAAnusAAJ/rAACi 6wAAo+sAAKTrAACl6wAApusAALrrAAC76wAAcewAAIHsAACO7AAAj+wAAJTsAACV7AAAxewAAMbs AADX7AAA2OwAAGTtAABl7QAAbu0AAG/tAAAR7gAAEu4AAB/uAAAg7gAAIu4AADzuAAA97gAAXe4A AF7uAAB37gAAee4AAHzuAAB97gAAmu4AAPTgzeC2p6CYkH1zfWB9YH1gfWB9YH1gfWB9YJCYkJiQ mJCYkJgAAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJABIWaEVGawAwSh0A bUgJAHNICQAAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJ AHNICQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBR SgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQV aHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENK FABPSgQAUUoEAG8oAXBo////ABUDagAAAAAVaHZMdwAWaBo38gBVCAEAJbvrAACP7AAAlewAAMbs AADY7AAAZe0AAG/tAAAS7gAAIO4AACHuAAAi7gAAPe4AAF7uAAB47gAAee4AAH3uAACb7gAA+gAA AAAAAAAAAAAAAOUAAAAAAAAAAAAAAADOAAAAAAAAAAAAAAAAtwAAAAAAAAAAAAAAAM4AAAAAAAAA AAAAAAC3AAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAACSAAAAAAAAAAAAAAAA kgAAAAAAAAAAAAAAAJIAAAAAAAAAAAAAAACSAAAAAAAAAAAAAAAAkgAAAAAAAAAAAAAAAJIAAAAA AAAAAAAAAACSAAAAAAAAAAAAAAAAkgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADxoADoTg AQ+EsARdhOABXoSwBGVkHSRDWWdkRUZrAAAUAAAOhLAED4SABxOkAABbJABcJABdhLAEXoSAB2Vk SB1NCGdkRUZrAAAWAAAOhLAED4SwBBOkAAAUpAAAWyQAXCQAXYSwBF6EsARlZEgdTQhnZEVGawAA FgAADoSwBA+EgAcTpAAAFKQAAFskAFwkAF2EsARehIAHZWRIHU0IZ2RFRmsAABQAAA6EsAQPhLAE FKQAAFskAFwkAF2EsARehLAEZWRIHU0IZ2RFRmsAAAQeAGVkS0zWNwAQmu4AAJvuAACe7gAAoO4A APfuAAAE7wAAzu8AANDvAADR7wAA0u8AANPvAADn7wAA6O8AAOnvAADs7wAA7e8AAO7vAADv7wAA 8O8AAAPwAAAE8AAAYPAAAGHwAABw8AAAcfAAAGPxAABk8QAA+PD43dPdwKvAoJmghXKFW0xF8Pjd wN3A3cAAAAAADBVodkx3ABZo2lj3AAAdFWh2THcAFmjaWPcAQioIT0oDAFFKAwBwaP///wAtA2oA AAAAFWh2THcAFmgaN/IANQiBQioIQ0oUAE9KBABRSgQAVQgBcGj///8AJBVodkx3ABZoRUZrADUI gUIqCENKFABPSgQAUUoEAHBo////AAAnFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAbygB cGj///8ADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBKANq1jUAABZoGjfyAEIq AU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBo AAAAAHNICQASFmhFRmsAMEodAG1ICQBzSAkAACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBw aAAAAABzSAkADhZoRUZrAG1ICQBzSAkAAA4WaNpY9wBtSAkAc0gJABqb7gAAn+4AAKDuAADP7wAA 0O8AANLvAADv7wAA8O8AAATwAABh8AAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADqAAAAAAAA AAAAAAAA3gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAAC/AAAAAAAAAAAAAAAAXwAAAAAAAAAAAAAA AFoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAMAZWRL TNY3YAAAa2RyNgAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAA AAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMA ABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEB YfYDAABpdEtM1jdw1goAAAD/mQAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/GYT4/xsm ICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACwAAE6QAABSkAABbJABcJABlZEtM1jcABB4A ZWRLTNY3AA8aAA6E4AEPhLAEXYTgAV6EsARlZB0kQ1lnZEVGawAACWHwAABx8AAAZPEAAHPxAAA6 8gAATvIAAKHyAACv8gAAe/MAAJLzAAD98wAAC/QAAGn0AACY9AAAmfQAAJv0AADqAAAAAAAAAAAA AAAA0wAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAANMA AAAAAAAAAAAAAAC8AAAAAAAAAAAAAAAA0wAAAAAAAAAAAAAAALwAAAAAAAAAAAAAAADTAAAAAAAA AAAAAAAAvAAAAAAAAAAAAAAAAKcAAAAAAAAAAAAAAACiAAAAAAAAAAAAAAAAlgAAAAAAAAAAAAAA AJYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL AAATpAAAFKQAAFskAFwkAGVkS0zWNwAEHgBlZEtM1jcAFAAADoSwBA+EgAcTpAAAWyQAXCQAXYSw BF6EgAdlZEk4chNnZEVGawAAFgAADoSwBA+EsAQTpAAAFKQAAFskAFwkAF2EsARehLAEZWRJOHIT Z2RFRmsAABYAAA6EsAQPhIAHE6QAABSkAABbJABcJABdhLAEXoSAB2VkSThyE2dkRUZrAAAUAAAO hLAED4SwBBSkAABbJABcJABdhLAEXoSwBGVkSThyE2dkRUZrAAAPZPEAAHLxAABz8QAAOfIAADry AABN8gAATvIAAKDyAACh8gAArvIAAK/yAAB68wAAe/MAAJHzAACS8wAA/PMAAP3zAAAK9AAAC/QA AGj0AABp9AAAl/QAAJn0AACa9AAAm/QAAJz0AACw9AAAsfQAALL0AAC19AAAtvQAALf0AAC49AAA ufQAAOzZ7Nns2ezZ7Nns2ezZ7Nns2ezZ7NnE2bmyuZ6LnnRlXgAAAAAAAAAAAAAAAAAAAAAAAAAM FWh2THcAFmjaWPcAAB0VaHZMdwAWaNpY9wBCKghPSgMAUUoDAHBo////AC0DagAAAAAVaHZMdwAW aBo38gA1CIFCKghDShQAT0oEAFFKBABVCAFwaP///wAkFWh2THcAFmhFRmsANQiBQioIQ0oUAE9K BABRSgQAcGj///8AACcVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABvKAFwaP///wAMFWh2 THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo38gBVCAEoA2oKNwAAFmgaN/IAQioBT0oDAFFKAwBV CAFtSAkAcGgAAAAAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACUV aG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAACGb9AAAuPQAALn0AADc9AAAlfYA AED3AABB9wAAQ/cAAGD3AADgAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB2 AAAAAAAAAAAAAAAAdgAAAAAAAAAAAAAAAGoAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAA4AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpAAAFKQAAFskAFwkAGVkS0zWNwAEHgBlZEtM1jcA BAMAZWRLTNY3YAAAa2SmNwAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAA AAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEV NgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAA QtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/ GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACLn0AADb9AAA3PQAAJT2AACV9gAA P/cAAED3AABB9wAAQvcAAEP3AABE9wAAWPcAAFn3AABa9wAAXfcAAF73AABf9wAAYPcAAGH3AAD4 8N3KuqrKlcqKg4pvXG9FNi8MFWh2THcAFmjaWPcAAB0VaHZMdwAWaNpY9wBCKghPSgMAUUoDAHBo ////AC0DagAAAAAVaHZMdwAWaBo38gA1CIFCKghDShQAT0oEAFFKBABVCAFwaP///wAkFWh2THcA FmhFRmsANQiBQioIQ0oUAE9KBABRSgQAcGj///8AACcVaHZMdwAWaEVGawA1CIFCKghDShQAT0oE AFFKBABvKAFwaP///wAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo38gBVCAEoA2o+OAAA FmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAfFmjaWPcAQioBT0oDAFFKAwBtSAkA cGgAAAAAc0gJAB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZo2lj3AEIq AU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAA c0gJAA4WaNpY9wBtSAkAc0gJAAAOFmhFRmsAbUgJAHNICQASYPcAAGH3AAB69wAAw/cAAMT3AADG 9wAA4/cAAJ8AAAAAAAAAAAAAAACaAAAAAAAAAAAAAAAAlQAAAAAAAAAAAAAAAIkAAAAAAAAAAAAA AACJAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAfAAADJAESZOEAAAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQC L4QtAElmAQAAAFskAFwkAGEkAWdkb2geAAALAAATpAAAFKQAAFskAFwkAGVkS0zWNwAEHgBlZEtM 1jcABAMAZWRLTNY3YAAAa2TaOAAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEA AAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYD wgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEP AwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAAAZh9wAAefcAAHr3AADC9wAAxPcAAMX3 AADG9wAAx/cAANv3AADc9wAA3fcAAOD3AADh9wAA4vcAAOP3AADk9wAAFPgAABX4AAA3+AAAZPgA AIT4AACF+AAAwfgAAPjw4NC70LCpsJWClWtcVfjwQuBC4EIAAAAAAAAAAAAAAAAAAAAAAAAlFWhv aB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo 2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoE AFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZo RUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3 ABZoGjfyAFUIASgDanI5AAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAAB8WaNpY 9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAHxZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNI CQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAFuP3AADk9wAAFfgAADf5AAA4+QAAOfkA AGb5AABn+QAAg/kAALj5AAD0+QAA9fkAADX6AABX+gAAWPoAAJ8AAAAAAAAAAAAAAACaAAAAAAAA AAAAAAAAlQAAAAAAAAAAAAAAAIUAAAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAhQAAAAAAAAAAAAAA AIUAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAhQAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAACAAAAA AAAAAAAAAAAAhQAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABBoAZWTgf+8EAA8aAA6E4AEPhLAEXYTgAV6EsARlZOB/7wRnZEVGawAABB4AZWRLTNY3 AAQDAGVkS0zWN2AAAGtkDjoAABYkARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAA AAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IB FTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMA AELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAAAOwfgAANH4AADt+AAA/fgAADb5AAA3+QAA OfkAAGX5AABn+QAAgvkAAIP5AAC3+QAAuPkAAPP5AAD1+QAANPoAADX6AABW+gAAWPoAAHv6AAB8 +gAAv/oAAMD6AAAD+wAABPsAAEf7AABI+wAAg/sAAIX7AACy+wAAs/sAAOz7AADt+wAAJPwAACX8 AAAm/AAAKvwAAC/8AAC8/AAAwPwAAMX8AADw/AAA8fwAAG79AABz/QAAIP4AADH+AABt/gAAdv4A ANb+AADb/gAA3f4AAO7+AAD0/gAA/f4AACj/AAAp/wAAev8AAHv/AAD24/bj0MjAyMDIwMjAyMDI wMjAyMDIwMjAyMDIwMjAyMDIteP246X2pdCl9qX2pfal9qX2pfallaWVAAAAAB8WaNpY9wBCKgFP SgMAUUoDAG1ICQBwaAAAAABzSAkAHxZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAUFWhv aB4AFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAA4WaNpY9wBtSAkAc0gJAAAlFWhvaB4A FmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1I CQBwaAAAAABzSAkAEhZoRUZrADBKHQBtSAkAc0gJADpY+gAAfPoAAMD6AAAE+wAASPsAAIT7AACF +wAAs/sAAO37AAAl/AAAJvwAAPH8AAAp/wAAe/8AAHz/AAB9/wAAmf8AALT/AAC1/wAAJAABACUA AQAmAAEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAA AAAAAAAAAAAA2gAAAAAAAAAAAAAAANUAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA1QAAAAAAAAAA AAAAAMUAAAAAAAAAAAAAAADFAAAAAAAAAAAAAAAAxQAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAADA AAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAALsAAAAAAAAAAAAAAAC7AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAEGgBlZElQRA8ABBoAZWSXPy9cAA8aAA6E4AEPhLAEXYTgAV6EsARlZJc/L1xnZEVG awAABB4AZWRLTNY3AA8aAA6E4AEPhLAEXYTgAV6EsARlZOB/7wRnZG9oHgAADxoADoTgAQ+EsARd hOABXoSwBGVk4H/vBGdkRUZrAAAEGgBlZOB/7wQAFXv/AAB9/wAAmP8AAJn/AACz/wAAtf8AACMA AQAkAAEAJgABAEEAAQBCAAEAXAABAF0AAQCHAAEAiAABAMgAAQDKAAEAywABAMwAAQDNAAEAzgAB AOIAAQDjAAEA5AABAOcAAQDoAAEA6QABAOoAAQD48Pjw+ODQ+PD48Pjw+PD4vai9nZadgm+CWEkA AAAAAAAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUI gUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABw aP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////AAwVaHZMdwAWaBo3 8gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDaqY6AAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBw aAAAAABzSAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAHxZo2lj3AEIq AU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAA4W aEVGawBtSAkAc0gJAAAOFmjaWPcAbUgJAHNICQAbJgABAEIAAQBdAAEAiAABAMkAAQDKAAEAywAB AM0AAQDqAAEA6wABAP8AAQC4AQEA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAM8A AAAAAAAAAAAAAABvAAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAGUAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAEHgBlZEtM1jcABAMAZWRLTNY3YAAAa2RCOwAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjW GgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goA AAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YG AAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAHwAAAyQBEmThAAAA E6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACwAAE6QA ABSkAABbJABcJABlZEtM1jcABBoAZWRJUEQPAAvqAAEA6wABAP4AAQD/AAEAfAEBAKYBAQCoAQEA twEBALgBAQDHAQEAyAEBAK8CAQC1AgEA6wIBAOwCAQD5AgEA+gIBABcDAQA3AwEAPgMBAFEDAQBf AwEAZgMBAKADAQCrAwEAxgMBAN0DAQDnAwEA7wMBAPADAQDxAwEAAwQBAAQEAQCvBAEAtAQBAPoE AQD7BAEAKQUBACoFAQAiBgEAIwYBADAGAQAxBgEAMwYBAE4GAQBPBgEAaQYBAGsGAQBsBgEAbQYB AG4GAQBvBgEA+fHp2cbZxrPGs8bZxrPGs8bZxtnG2cbZxtnG2cazxrPGqcazxrPGs8az6fHp8emz lLOJAAAAAAAAAAAAAAAAAAAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDato7AAAWaBo38gBCKgFP SgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAABIWaEVGawAwSh0AbUgJAHNICQAAJRVob2geABZo2lj3 AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgA AAAAc0gJAB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkADhZo2lj3AG1ICQBzSAkAAA4W aEVGawBtSAkAc0gJAAAMFWh2THcAFmjaWPcAM7gBAQDIAQEA7AIBAPoCAQDxAwEABAQBAPsEAQAq BQEAIwYBADEGAQAyBgEAMwYBAE8GAQBqBgEAawYBAGwGAQDqAAAAAAAAAAAAAAAA0wAAAAAAAAAA AAAAALwAAAAAAAAAAAAAAADTAAAAAAAAAAAAAAAAvAAAAAAAAAAAAAAAAKcAAAAAAAAAAAAAAACi AAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAKIAAAAAAAAAAAAAAACSAAAAAAAAAAAAAAAAkgAAAAAA AAAAAAAAAJIAAAAAAAAAAAAAAACSAAAAAAAAAAAAAAAAkgAAAAAAAAAAAAAAAIYAAAAAAAAAAAAA AAAAAAAAAAAAAAAACwAAE6QAABSkAABbJABcJABlZEtM1jcADxoADoTgAQ+EsARdhOABXoSwBGVk JxkoTmdkRUZrAAAEHgBlZEtM1jcAFAAADoSwBA+EgAcTpAAAWyQAXCQAXYSwBF6EgAdlZOtCpFln ZEVGawAAFgAADoSwBA+EsAQTpAAAFKQAAFskAFwkAF2EsARehLAEZWTrQqRZZ2RFRmsAABYAAA6E sAQPhIAHE6QAABSkAABbJABcJABdhLAEXoSAB2Vk60KkWWdkRUZrAAAUAAAOhLAED4SwBBSkAABb JABcJABdhLAEXoSwBGVk60KkWWdkRUZrAAAPbAYBAG4GAQCLBgEAjAYBAJ4GAQCfBgEAoQYBAL4G AQDzAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAAHQAAAAAAAAAAAAAAABvAAAAAAAAAAAAAAAA8wAA AAAAAAAAAAAAAPMAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQDAGVkS0zWN2AAAGtkcDwAABYkARckAUlmAQAAAGVkS0zW NweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8Q lC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/ HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAB8AAAMk ARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBZ2RvaB4A AAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3AAdvBgEAgwYBAIQGAQCFBgEAiAYBAIkGAQCKBgEAiwYB AIwGAQCdBgEAngYBAJ8GAQCgBgEAoQYBAKIGAQC2BgEAtwYBALgGAQC7BgEAvAYBAL0GAQC+BgEA vwYBAOoGAQDrBgEA9QYBAPcGAQD57trH2rChmpKKd2J37vnu2sfasKGakopPdwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAKANqCD0A ABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAJRVob2geABZo2lj3AEIqAU9KAwBR SgMAbUgJAHBoAAAAAHNICQAOFmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAW aNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUI gUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABw aP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////ABUDagAAAAAVaHZM dwAWaBo38gBVCAEMFWh2THcAFmgaN/IAGr4GAQC/BgEA6wYBAPYGAQD3BgEA+QYBABYHAQCfAAAA AAAAAAAAAAAAmgAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACJAAAAAAAAAAAAAAAAiQAAAAAAAAAA AAAAAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABb JABcJABhJAFnZG9oHgAACwAAE6QAABSkAABbJABcJABlZEtM1jcABB4AZWRLTNY3AAQDAGVkS0zW N2AAAGtknj0AABYkARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAA AAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa 1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2 AwAAaXRLTNY3cNYKAAAA/5kAAAAAAAAG9wYBAPgGAQD5BgEA+gYBAA4HAQAPBwEAEAcBABMHAQAU BwEAFQcBABYHAQAXBwEAPQcBAD4HAQA9CAEAPwgBAFcIAQBYCAEAcQgBAHMIAQB8CQEAfgkBAJYJ AQCXCQEASAoBAEkKAQBLCgEA69jNxs2yn7KIeXJqYk9FT9hPRU9FT9hP2GIAAAAAEhZoRUZrADBK HQBtSAkAc0gJAAAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAA4WaNpY9wBt SAkAc0gJAAAOFmhFRmsAbUgJAHNICQAADBVodkx3ABZo2lj3AAAdFWh2THcAFmjaWPcAQioIT0oD AFFKAwBwaP///wAtA2oAAAAAFWh2THcAFmgaN/IANQiBQioIQ0oUAE9KBABRSgQAVQgBcGj///8A JBVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAHBo////AAAnFWh2THcAFmhFRmsANQiBQioI Q0oUAE9KBABRSgQAbygBcGj///8ADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgB JRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAoA2o2PgAAFmgaN/IAQioBT0oD AFFKAwBVCAFtSAkAcGgAAAAAc0gJABoWBwEAFwcBAD4HAQBYCAEAlwkBAEkKAQBKCgEASwoBAGcK AQCXCgEAmAoBAJkKAQCbCgEAnwAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAACVAAAAAAAAAAAAAAAA lQAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAhQAAAAAAAAAAAAAAAIUAAAAA AAAAAAAAAACFAAAAAAAAAAAAAAAAhQAAAAAAAAAAAAAAAHkAAAAAAAAAAAAAAAB5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAATpAAAFKQAAFskAFwkAGVk S0zWNwAPGgAOhOABD4SwBF2E4AFehLAEZWQeMUgJZ2RFRmsAAAQeAGVkS0zWNwAEAwBlZEtM1jdg AABrZMw+AAAWJAEXJAFJZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAA AAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYE AAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMA AGl0S0zWN3DWCgAAAP+ZAAAAAAAADEsKAQBmCgEAZwoBAJYKAQCYCgEAmQoBAJoKAQCbCgEAnAoB ALAKAQCxCgEAsgoBALUKAQC2CgEAtwoBALgKAQC5CgEA4woBAOQKAQApCwEAOQsBAEELAQD48Pjw 3cjdvba9oo+ieGli+PBPRU8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWaEVGawAwSh0A bUgJAHNICQAAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAMFWh2THcAFmja WPcAAB0VaHZMdwAWaNpY9wBCKghPSgMAUUoDAHBo////AC0DagAAAAAVaHZMdwAWaBo38gA1CIFC KghDShQAT0oEAFFKBABVCAFwaP///wAkFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAcGj/ //8AACcVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABvKAFwaP///wAMFWh2THcAFmgaN/IA ABUDagAAAAAVaHZMdwAWaBo38gBVCAEoA2pkPwAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgA AAAAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAA4WaNpY9wBtSAkA c0gJAAAOFmhFRmsAbUgJAHNICQAVmwoBALgKAQC5CgEA5AoBAJULAQCNDAEAjgwBAI8MAQC9DAEA vgwBAL8MAQDgAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAHsAAAAAAAAAAAAAAAB2AAAAAAAAAAAA AAAAdgAAAAAAAAAAAAAAAGYAAAAAAAAAAAAAAABmAAAAAAAAAAAAAAAAZgAAAAAAAAAAAAAAAGYA AAAAAAAAAAAAAABaAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3AA8a AA6E4AEPhLAEXYTgAV6EsARlZDwlYWhnZEVGawAABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtkAEAA ABYkARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqAB CnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YE AAAA/xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3 cNYKAAAA/5kAAAAAAB8AAAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYB AAAAWyQAXCQAYSQBZ2RvaB4AAApBCwEARgsBAJQLAQCVCwEA4QsBAOMLAQCMDAEAjQwBAI8MAQC8 DAEAvgwBAL8MAQDADAEAwQwBAMIMAQDWDAEA1wwBANgMAQDbDAEA3AwBAN0MAQDeDAEA79zJ3L/c ybevt8mayY+Ij3RhdEo7AAAAAAAAAAAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNq AAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1 CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8o AXBo////AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDaphAAAAWaBo38gBC KgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAAA4WaEVGawBtSAkAc0gJAAAOFmjaWPcAbUgJAHNI CQAAEhZoRUZrADBKHQBtSAkAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAA c0gJACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAHxZoRUZrAEIqAU9KAwBR SgMAbUgJAHBoAAAAAHNICQAAFb8MAQDBDAEA3gwBAN8MAQAFDQEA+w0BAPwNAQD+DQEAGw4BAPMA AAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAABqAAAAAAAA AAAAAAAA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQeAGVkS0zWNwAEAwBlZEtM1jdgAABrZDRBAAAWJAEXJAFJZgEAAABlZEtM1jcHlOEACNYa AAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAA AP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA/x6ULQAz1gYA AQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAAAAAfAAADJAESZOEAAAAT pAAAFKQAABYkARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAWdkb2geAAALAAATpAAA FKQAAFskAFwkAGVkS0zWNwAI3gwBAN8MAQAEDQEABQ0BACUNAQArDQEA+g0BAPwNAQD9DQEA/g0B AP8NAQATDgEAFA4BABUOAQAYDgEAGQ4BABoOAQAbDgEAHA4BADcOAQA4DgEAQg4BAEQOAQD58enW xtaznrOTjJN4ZXhOP/nx6dazAAAAAAAAAAAAAAAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj/ //8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAW aEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQA UUoEAG8oAXBo////AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDasxBAAAW aBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoD AG1ICQBwaAAAAABzSAkAHxZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhF RmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAA4WaNpY9wBtSAkAc0gJAAAOFmhFRmsAbUgJAHNI CQAADBVodkx3ABZo2lj3ABYbDgEAHA4BADgOAQBDDgEARA4BAEYOAQBjDgEAnwAAAAAAAAAAAAAA AJoAAAAAAAAAAAAAAACVAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAAIkAAAAAAAAAAAAAAABqAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AB8AAAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQB Z2RvaB4AAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3AAQeAGVkS0zWNwAEAwBlZEtM1jdgAABrZGhC AAAWJAEXJAFJZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKg AQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvW BAAAAP8c1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zW N3DWCgAAAP+ZAAAAAAAABkQOAQBFDgEARg4BAEcOAQBbDgEAXA4BAF0OAQBgDgEAYQ4BAGIOAQBj DgEAZA4BAHsOAQB8DgEAfQ4BAH4OAQB/DgEAgA4BAJQOAQCVDgEAlg4BAJkOAQCaDgEAmw4BAJwO AQCdDgEAwA4BAMEOAQDr2M3GzbKfsoh5cmpi2E3YzcbNsp+yiHlyamIAAAAAAAAAAAAAAAAAAAAo A2o0RAAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAOFmjaWPcAbUgJAHNICQAA DhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj/ //8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAW aEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQA UUoEAG8oAXBo////AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASUVaG9oHgAW aNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAKANqAEMAABZoGjfyAEIqAU9KAwBRSgMAVQgB bUgJAHBoAAAAAHNICQAbYw4BAGQOAQB8DgEAfQ4BAH8OAQCcDgEAnwAAAAAAAAAAAAAAAJoAAAAA AAAAAAAAAACOAAAAAAAAAAAAAAAAjgAAAAAAAAAAAAAAAG8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABb JABcJABhJAFnZG9oHgAACwAAE6QAABSkAABbJABcJABlZEtM1jcABAMAZWRLTNY3YAAAa2ScQwAA FiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEK dAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQA AAD/HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw 1goAAAD/mQAAAAAAAAWcDgEAnQ4BAMEOAQD7DgEAOBEBAHUSAQBIFAEASRQBAEsUAQBoFAEAnwAA AAAAAAAAAAAAAJoAAAAAAAAAAAAAAACVAAAAAAAAAAAAAAAAlQAAAAAAAAAAAAAAAJUAAAAAAAAA AAAAAACVAAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAAIkAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8A AAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBZ2Rv aB4AAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3AAQeAGVkS0zWNwAEAwBlZEtM1jdgAABrZNBEAAAW JAEXJAFJZgEAAABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0 AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAA AP8c1gQAAAD/HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DW CgAAAP+ZAAAAAAAACcEOAQD6DgEA+w4BALkPAQDJDwEANxEBADgRAQB0EgEAdRIBAEcUAQBJFAEA ShQBAEsUAQBMFAEAYBQBAGEUAQBiFAEAZRQBAGYUAQBnFAEAaBQBAGkUAQCGFAEAhxQBAJYUAQCX FAEAvRQBAOzZ7M/s2ezZ7Nm62a+or5SBlGpbVExE7NnsAAAOFmjaWPcAbUgJAHNICQAADhZoRUZr AG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIqCE9KAwBRSgMAcGj///8ALQNq AAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo////ACQVaHZMdwAWaEVGawA1 CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAG8o AXBo////AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDamhFAAAWaBo38gBC KgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAABIWaEVGawAwSh0AbUgJAHNICQAAJRVob2geABZo 2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkA cGgAAAAAc0gJAAAaaBQBAGkUAQCHFAEAlxQBAL4UAQDYFAEA4BUBAPMVAQCqFgEAxRYBAJwXAQCf AAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAIUAAAAAAAAAAAAAAABuAAAAAAAAAAAAAAAAVwAAAAAA AAAAAAAAAG4AAAAAAAAAAAAAAABXAAAAAAAAAAAAAAAAbgAAAAAAAAAAAAAAAFcAAAAAAAAAAAAA AABuAAAAAAAAAAAAAAAAABYAAA6EsAQPhLAEE6QAABSkAABbJABcJABdhLAEXoSwBGVkZTVmXmdk RUZrAAAWAAAOhLAED4SABxOkAAAUpAAAWyQAXCQAXYSwBF6EgAdlZGU1Zl5nZEVGawAAFAAADoSw BA+EsAQUpAAAWyQAXCQAXYSwBF6EsARlZGU1Zl5nZEVGawAABAMAZWRLTNY3YAAAa2QERgAAFiQB FyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAA oAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/ HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goA AAD/mQAAAAAAAAq9FAEAvhQBANcUAQDYFAEAwBUBANAVAQDfFQEA4BUBAPIVAQDzFQEAqRYBAKoW AQDEFgEAxRYBAJsXAQCcFwEAsBcBALEXAQAIGAEAChgBAAsYAQAMGAEADRgBACEYAQAiGAEAIxgB ACYYAQAnGAEAKBgBACkYAQAqGAEA7Nns2c/Z7Nns2ezZ7Nns2ezZ7Lrsr6ivlIGUaltUAAAAAAAA AAAAAAAAAAAMFWh2THcAFmjaWPcAAB0VaHZMdwAWaNpY9wBCKghPSgMAUUoDAHBo////AC0DagAA AAAVaHZMdwAWaBo38gA1CIFCKghDShQAT0oEAFFKBABVCAFwaP///wAkFWh2THcAFmhFRmsANQiB QioIQ0oUAE9KBABRSgQAcGj///8AACcVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABvKAFw aP///wAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo38gBVCAEoA2qcRgAAFmgaN/IAQioB T0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAASFmhFRmsAMEodAG1ICQBzSAkAACUVaG9oHgAWaEVG awBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBo AAAAAHNICQAAHpwXAQCxFwEACRgBAAoYAQAMGAEAKRgBACoYAQA6GAEA6AAAAAAAAAAAAAAAANMA AAAAAAAAAAAAAADHAAAAAAAAAAAAAAAAxwAAAAAAAAAAAAAAAKgAAAAAAAAAAAAAAABIAAAAAAAA AAAAAAAAQwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQDAGVkS0zWN2AAAGtkOEcAABYkARckAUlm AQAAAGVkS0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYg DpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAA AP8d1gQAAAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kA AAAAAB8AAAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQA YSQBZ2RvaB4AAAsAABOkAAAUpAAAWyQAXCQAZWRLTNY3ABQAAA6EsAQPhIAHE6QAAFskAFwkAF2E sARehIAHZWRlNWZeZ2RFRmsAABYAAA6EsAQPhLAEE6QAABSkAABbJABcJABdhLAEXoSwBGVkZTVm XmdkRUZrAAAHKhgBADkYAQA6GAEAdhgBAHsYAQCoGAEAqRgBALgYAQC5GAEAvxgBAMAYAQDZGAEA 2hgBAHYZAQCGGQEAlRkBAJYZAQCoGQEAqRkBAK4ZAQCvGQEAyRkBAMoZAQDeGQEA3xkBAPMZAQD0 GQEA+RkBAPsZAQD8GQEA/RkBAP4ZAQASGgEAExoBABQaAQAXGgEAGBoBAPjw3dPdwN3A3cDdwN3T 3cDdwN3A3cDdwN3A3cCrwKCZoIVyhQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAJBVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAHBo////AAAnFWh2THcAFmhF RmsANQiBQioIQ0oUAE9KBABRSgQAbygBcGj///8ADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcA FmgaN/IAVQgBKANq0EcAABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAAJRVob2ge ABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQASFmhFRmsAMEodAG1ICQBzSAkAACUVaG9o HgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkADhZo2lj3AG1ICQBzSAkAAA4WaEVGawBt SAkAc0gJACQ6GAEAqRgBALkYAQDAGAEA2hgBAJYZAQCpGQEArxkBAMoZAQDfGQEA9BkBAPoZAQD7 GQEA/RkBAPoAAAAAAAAAAAAAAADlAAAAAAAAAAAAAAAAzgAAAAAAAAAAAAAAALcAAAAAAAAAAAAA AADOAAAAAAAAAAAAAAAAtwAAAAAAAAAAAAAAAM4AAAAAAAAAAAAAAAC3AAAAAAAAAAAAAAAAzgAA AAAAAAAAAAAAALcAAAAAAAAAAAAAAACiAAAAAAAAAAAAAAAAlgAAAAAAAAAAAAAAAJYAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6QAABSkAABbJABcJABlZEtM1jcAFAAADoSwBA+E gAcTpAAAWyQAXCQAXYSwBF6EgAdlZMIga0pnZEVGawAAFgAADoSwBA+EsAQTpAAAFKQAAFskAFwk AF2EsARehLAEZWTCIGtKZ2RFRmsAABYAAA6EsAQPhIAHE6QAABSkAABbJABcJABdhLAEXoSAB2Vk wiBrSmdkRUZrAAAUAAAOhLAED4SwBBSkAABbJABcJABdhLAEXoSwBGVkwiBrSmdkRUZrAAAEHgBl ZEtM1jcADRgaAQAZGgEAGhoBABsaAQAwGgEAMRoBADsaAQA9GgEAPhoBAD8aAQBAGgEAVBoBAFUa AQBWGgEAWRoBAFoaAQBbGgEAXBoBAF0aAQB2GgEAdxoBAN0bAQDeGwEAyhwBAMscAQAUHQEA6NnS ysKvnIecfHV8YU5h6NnSysKvnK+crwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACQVaHZMdwAW aEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZrADUIgUIqCENKFABPSgQA UUoEAG8oAXBo////AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASgDagRJAAAW aBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABzSAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoD AG1ICQBwaAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAOFmja WPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3AEIq CE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUIAXBo ////AAAZ/RkBABoaAQAbGgEAMRoBADwaAQA9GgEAPxoBAFwaAQDgAAAAAAAAAAAAAAAAgAAAAAAA AAAAAAAAAHsAAAAAAAAAAAAAAAB2AAAAAAAAAAAAAAAAagAAAAAAAAAAAAAAAGoAAAAAAAAAAAAA AADgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAE6QAABSk AABbJABcJABlZEtM1jcABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtkbEgAABYkARckAUlmAQAAAGVk S0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U +P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQA AAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAB8A AAMkARJk4QAAABOkAAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBZ2Rv aB4AAAdcGgEAXRoBAHcaAQDeGwEAyxwBAOUeAQDmHgEA6B4BAAUfAQCfAAAAAAAAAAAAAAAAmgAA AAAAAAAAAAAAAJUAAAAAAAAAAAAAAACVAAAAAAAAAAAAAAAAjQAAAAAAAAAAAAAAAIEAAAAAAAAA AAAAAACBAAAAAAAAAAAAAAAAYgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAyQBEmThAAAAE6QAABSkAAAWJAEYhPj/ GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACwAAE6QAABSkAABbJABcJABlZEtM 1jcABx4AZWRLTNY3Z2T6GiIAAAQeAGVkS0zWNwAEAwBlZEtM1jdgAABrZKBJAAAWJAEXJAFJZgEA AABlZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U +P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/ HdYEAAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAA AAAACBQdAQAiHQEATx0BAFwdAQBqHQEAgB0BAI0dAQCSHQEAnR0BAKIdAQCjHQEApR0BANMdAQDi HQEAHR4BAC4eAQB7HgEAiB4BAKUeAQDFHgEA0R4BAOMeAQDkHgEA5h4BAOceAQDoHgEA6R4BAP0e AQD+HgEA/x4BAO/c79zv3MWx76Tv3O/csdzv3O/c79yRfJFxanFWAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAnFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAbygBcGj///8ADBVodkx3ABZoGjfy AAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBKANqOEoAABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBo AAAAAHNICQAAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAZA2oAAAAAFWga N/IAFmj6GiIAMEpCAFUIASYBCIEESAEAFmj6GiIAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAAAs AAiBFmhFRmsAF2j6GiIAQioBT0oDAFFKAwBjSAEAbUgJAHBoAAAAAHNICQAAJRVob2geABZoRUZr AEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJ AAAd/x4BAAIfAQADHwEABB8BAAUfAQAGHwEAIx8BACQfAQBTHwEAVR8BAFYfAQBXHwEAWB8BAGwf AQBtHwEAbh8BAHEfAQByHwEAcx8BAHQfAQB1HwEAkh8BAJMfAQDSHwEA0x8BANQfAQDt2cKzrKSc iXZhdlZPVtnt2cKzrKSciXaJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMFWh2THcAFmga N/IAABUDagAAAAAVaHZMdwAWaBo38gBVCAEoA2psSwAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkA cGgAAAAAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJACUVaG9oHgAW aEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkADhZo2lj3AG1ICQBzSAkAAA4WaEVGawBtSAkA c0gJAAAMFWh2THcAFmjaWPcAAB0VaHZMdwAWaNpY9wBCKghPSgMAUUoDAHBo////AC0DagAAAAAV aHZMdwAWaBo38gA1CIFCKghDShQAT0oEAFFKBABVCAFwaP///wAnFWh2THcAFmhFRmsANQiBQioI Q0oUAE9KBABRSgQAbygBcGj///8AJBVodkx3ABZoRUZrADUIgUIqCENKFABPSgQAUUoEAHBo//// ABkFHwEABh8BACQfAQBUHwEAVR8BAFcfAQB0HwEAnwAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAACV AAAAAAAAAAAAAAAAiQAAAAAAAAAAAAAAAIkAAAAAAAAAAAAAAABqAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB8AAAMkARJk4QAAABOk AAAUpAAAFiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBZ2RvaB4AAAsAABOkAAAU pAAAWyQAXCQAZWRLTNY3AAQeAGVkS0zWNwAEAwBlZEtM1jdgAABrZNRKAAAWJAEXJAFJZgEAAABl ZEtM1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U+P8P lPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYE AAAA/x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAAAAAA BnQfAQB1HwEAkx8BANMfAQDYHwEAgSABAJUgAQDgIAEAMyEBAJchAQC8IQEAFiIBAFMiAQChIgEA /iIBADQjAQCfAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAJUAAAAAAAAAAAAAAACVAAAAAAAAAAAA AAAAhQAAAAAAAAAAAAAAAIUAAAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAhQAAAAAAAAAAAAAAAIUA AAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAhQAAAAAAAAAAAAAAAIUAAAAAAAAAAAAAAACFAAAAAAAA AAAAAAAAhQAAAAAAAAAAAAAAAIUAAAAAAAAAAAAAAAAAAAAAAAAAEAAACiYAC0YHAA6E4AEPhLAE XYTgAV6EsARlZEtM1jcABB4AZWRLTNY3AAQDAGVkS0zWN2AAAGtkCEwAABYkARckAUlmAQAAAGVk S0zWNweU4QAI1hoAAeL/NAKARsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U +P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQA AAD/HpQtADPWBgABDwMPADTWBgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAAAP 1B8BANcfAQDYHwEAgCABAIEgAQCUIAEAlSABAN8gAQDgIAEAMiEBADMhAQCWIQEAlyEBALshAQC8 IQEAFSIBABYiAQBSIgEAUyIBAKAiAQChIgEA/SIBAP4iAQAzIwEANCMBAHMjAQB0IwEAsyMBALQj AQDjIwEA5CMBAC4kAQAvJAEAMCQBADMkAQA0JAEAjSQBAI4kAQDAJAEAwSQBAPwkAQD9JAEAPCUB AD0lAQB2JQEAdyUBAOwlAQDtJQEATyYBAFAmAQDuJgEA7yYBAEwnAQBNJwEAgicBAIMnAQDVJwEA 1icBAPsnAQD8JwEAACgBAAEoAQAhKAEAIigBAEIoAQBDKAEAhigBAIcoAQDIKAEAySgBABwpAQAd KQEAfSkBAH4pAQDv3+/f79/v3+/f79/v3+/f79/v3+/f79/v3+/f79/v3+/Mucy5zLnMucy5zLnM ucy5zLnMucy5zLnv38y5zLnMucy5zLnMucy5ACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBw aAAAAABzSAkAJRVob2geABZoRUZrAEIqAU9KAwBRSgMAbUgJAHBoAAAAAHNICQAfFmjaWPcAQioB T0oDAFFKAwBtSAkAcGgAAAAAc0gJAB8WaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAAEk0 IwEAdCMBALQjAQDkIwEALyQBADQkAQCOJAEAwSQBAP0kAQA9JQEAdyUBAO0lAQBQJgEA7yYBAE0n AQCDJwEA1icBAPwnAQABKAEAIigBAEMoAQDvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAA AAAAAAAAAADvAAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADXAAAAAAAAAAAA AAAA1wAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANcA AAAAAAAAAAAAAADXAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADXAAAAAAAA AAAAAAAAxwAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAATAAAKJgALRgkADoTAAw+EkAZdhMADXoSQBmVkS0zWN2dkb2geABAA AAomAAtGCAAOhOABD4SwBF2E4AFehLAEZWRLTNY3EwAACiYAC0YIAA6EwAMPhJAGXYTAA16EkAZl ZEtM1jdnZG9oHgAABB4AZWRLTNY3EAAACiYAC0YHAA6E4AEPhLAEXYTgAV6EsARlZEtM1jcAFEMo AQCHKAEAySgBAB0pAQB+KQEAzSkBAPEpAQD2KQEAKCoBAGMqAQCZKgEAxCoBAOwqAQAIKwEAaysB AKErAQCmKwEA0ysBAOwrAQAhLAEAZSwBAKYsAQDTLAEA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAA AADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA5wAA AAAAAAAAAAAAANQAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAANQAAAAAAAAA AAAAAADUAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAA 5wAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAMEAAAAA AAAAAAAAAADBAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAAAAAAAAAAAAEwAACiYAC0YLAA6EwAMP hJAGXYTAA16EkAZlZEtM1jdnZG9oHgATAAAKJgALRgoADoTAAw+EkAZdhMADXoSQBmVkS0zWN2dk b2geAAAEHgBlZEtM1jcTAAAKJgALRgkADoTAAw+EkAZdhMADXoSQBmVkS0zWN2dkb2geAAAWfikB AMwpAQDNKQEA8CkBAPEpAQD1KQEA9ikBACcqAQAoKgEAYioBAGMqAQCYKgEAmSoBAMMqAQDEKgEA 6yoBAOwqAQAHKwEACCsBAGorAQBrKwEAoCsBAKErAQClKwEApisBANIrAQDTKwEA6ysBAOwrAQAg LAEAISwBAGQsAQBlLAEAdywBAIcsAQCVLAEAoywBAKUsAQCmLAEAriwBALIsAQDSLAEA0ywBANcs AQDYLAEADS0BAA4tAQArLQEALC0BAFwtAQBdLQEAgy0BAIQtAQDPLQEA1S0BAN4tAQDfLQEAGS4B ABouAQAxLgEANy4BAEouAQBaLgEAcC4BAHEuAQDNLgEAzi4BAOMuAQDkLgEAPC8BAD0vAQCjLwEA pC8BAMwvAQDNLwEA5C8BAOUvAQD+LwEA/y8BAAMwAQAEMAEAHjABAB8wAQDs2ezZ7Nns2ezZ7Nns 2ezZ7Nns2ezZ7Nns2ezZ7Nns2ezP7M/s2ezP7Nns2ezZ7Nns2ezZ7M/s2ezZ7M/sz+zZ7Nns2ezZ 7Nns2ezZ7Nns2ezZEhZoRUZrADBKHQBtSAkAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBt SAkAcGgAAAAAc0gJACUVaG9oHgAWaEVGawBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkAAFLTLAEA 2CwBAA4tAQAsLQEAXS0BAIQtAQDfLQEAGi4BAHEuAQDOLgEA5C4BAD0vAQCkLwEAzS8BAOUvAQD/ LwEABDABAB8wAQBnMAEAujABAAQxAQA5MQEArzEBAP0xAQACMgEA+gAAAAAAAAAAAAAAAOcAAAAA AAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAA AAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcA AAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA5wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAA ANQAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAEwAACiYAC0YNAA6EwAMPhJAGXYTAA16EkAZlZEtM1jdnZG9o HgATAAAKJgALRgwADoTAAw+EkAZdhMADXoSQBmVkS0zWN2dkb2geAAAEHgBlZEtM1jcAGB8wAQBm MAEAZzABALkwAQC6MAEAzzABAN8wAQADMQEABDEBADgxAQA5MQEAWDEBAGAxAQBuMQEAfjEBAK4x AQCvMQEAszEBALkxAQD8MQEA/TEBAAEyAQACMgEAJTIBACkyAQAqMgEAKzIBAI4yAQCPMgEAzDIB AM0yAQARMwEAEjMBABozAQAfMwEANDMBADUzAQBCMwEAQzMBAGQzAQBlMwEAaTMBAGozAQCNMwEA jjMBAKMzAQCkMwEAyzMBAMwzAQDQMwEA0TMBAOgzAQD0MwEACDQBAAk0AQAPNAEAFDQBACA0AQAh NAEAWjQBAFs0AQBfNAEAYDQBALg0AQC5NAEAzTQBANE0AQAONQEADzUBABM1AQAUNQEAUTUBAFM1 AQBUNQEA7Nns2ezP7Nns2ezP7M/s2ezP7Nns2ezP7Nns2ezZ7Nnsz+zZ7Nns2ezZ7Nns2ezZ7Nns z+zZ7M/s2ezZ7Nns2ezP7Nns2ezZugAAACgDaqBMAAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBw aAAAAABzSAkAABIWaEVGawAwSh0AbUgJAHNICQAAJRVob2geABZo2lj3AEIqAU9KAwBRSgMAbUgJ AHBoAAAAAHNICQAlFWhvaB4AFmhFRmsAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAABJAjIBACsy AQCPMgEAzTIBABIzAQA1MwEAQzMBAGUzAQBqMwEAjjMBAKQzAQDMMwEA0TMBAAk0AQAhNAEAWzQB AGA0AQC5NAEADzUBABQ1AQDsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADs AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA5wAAAAAA AAAAAAAAANQAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAA1AAAAAAAAAAAAAAAAOcAAAAAAAAAAAAA AADBAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAArgAA AAAAAAAAAAAAAK4AAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA EwAACiYAC0YRAA6EwAMPhJAGXYTAA16EkAZlZEtM1jdnZG9oHgATAAAKJgALRhAADoTAAw+EkAZd hMADXoSQBmVkS0zWN2dkb2geABMAAAomAAtGDwAOhMADD4SQBl2EwANehJAGZWRLTNY3Z2RvaB4A AAQeAGVkS0zWNxMAAAomAAtGDgAOhMADD4SQBl2EwANehJAGZWRLTNY3Z2RvaB4AABMUNQEAUjUB AFM1AQBVNQEAcjUBAHM1AQCDNQEAhDUBAIY1AQCjNQEA7AAAAAAAAAAAAAAAAOAAAAAAAAAAAAAA AADgAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAGEAAAAAAAAAAAAAAABcAAAAAAAAAAAAAAAA4AAA AAAAAAAAAAAAAOAAAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQDAGVkS0zWN2AAAGtkPE0AABYkARckAUlmAQAAAGVkS0zWNweU4QAI1hoAAeL/NAKA RsIBAAAAAAAAAAAAAAAAAAAAAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAA ABT2A8IBFTYBF/YDAAAa1gQAAAD/G9YEAAAA/xzWBAAAAP8d1gQAAAD/HpQtADPWBgABDwMPADTW BgABDwMAAELWAwABAWH2AwAAaXRLTNY3cNYKAAAA/5kAAAAAAB8AAAMkARJk4QAAABOkAAAUpAAA FiQBGIT4/xmE+P8bJiAjJAIvhC0ASWYBAAAAWyQAXCQAYSQBZ2RvaB4AAAsAABOkAAAUpAAAWyQA XCQAZWRLTNY3EwAACiYAC0YSAA6EwAMPhJAGXYTAA16EkAZlZEtM1jdnZG9oHgAACVQ1AQBVNQEA VjUBAGo1AQBrNQEAbDUBAG81AQBwNQEAcTUBAHI1AQBzNQEAgjUBAIM1AQCENQEAhTUBAIY1AQCH NQEAmzUBAJw1AQCdNQEAoDUBAKE1AQCiNQEAozUBAKQ1AQC+NQEAvzUBAN41AQDs4drhxrPGnI2G fnbsYezh2uHGs8acjYZ+dk4AAAAAAAAAAAAAAAAAAAAAACUWaEVGawA1CIFCKgFDShQAT0oDAFFK AwBcCIFhShQAcGgAAAAAKANq1E0AABZoGjfyAEIqAU9KAwBRSgMAVQgBbUgJAHBoAAAAAHNICQAA DhZo2lj3AG1ICQBzSAkAAA4WaEVGawBtSAkAc0gJAAAMFWh2THcAFmjaWPcAAB0VaHZMdwAWaNpY 9wBCKghPSgMAUUoDAHBo////AC0DagAAAAAVaHZMdwAWaBo38gA1CIFCKghDShQAT0oEAFFKBABV CAFwaP///wAkFWh2THcAFmhFRmsANQiBQioIQ0oUAE9KBABRSgQAcGj///8AACcVaHZMdwAWaEVG awA1CIFCKghDShQAT0oEAFFKBABvKAFwaP///wAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAW aBo38gBVCAElFWhvaB4AFmjaWPcAQioBT0oDAFFKAwBtSAkAcGgAAAAAc0gJAAAbozUBAKQ1AQC/ NQEA3zUBAIY3AQCHNwEAnwAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAACNAAAAAAAAAAAAAAAAjQAA AAAAAAAAAAAAADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWgAAa2QITwAAFiQBFyQBSWYBAAAA ZWRLTNY3ApYPAAjWMAAC0/9fB18kAEIAAAAAAAAAAAAAAAAAAAAAAACAQgAAAAAAAAAAAAAAAAAA AAAAAAp0AACgBBT2AlYTFTYBF/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d 1ggAAAD/AAAA/zPWBgABDwMPADTWBgABDwMPAELWAwACAWH2AwAAaXRLTNY3DQAAE6QAABSkAAAW JAFJZgEAAABbJABcJAAABAMAZWRLTNY3YAAAa2RwTgAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjW GgAB4v80AoBGwgEAAAAAAAAAAAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goA AAD/mQAAAAAAFPYDwgEVNgEX9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YG AAEPAw8ANNYGAAEPAwAAQtYDAAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAAAXeNQEA3zUBAEw2 AQBNNgEApTYBAKY2AQDeNgEA3zYBACU3AQAmNwEAfjcBAH83AQCCNwEAgzcBAIU3AQCGNwEAhzcB AJA3AQCRNwEAkjcBALc3AQC4NwEAwTcBAMI3AQDHNwEAyDcBAOs3AQDsNwEA+TcBAPo3AQD9NwEA /jcBAC44AQAvOAEAhzgBAIg4AQCkOAEApTgBANw4AQDdOAEA4DgBAOE4AQDjOAEA5DgBAOU4AQDu OAEA7zgBAPA4AQAUOQEAFTkBACA5AQAhOQEAJDkBACU5AQBVOQEAVjkBAI45AQCPOQEAsDkBAO/f 1M3Uv63f1M3Uv63f76aT79TN1L+t39TN1L+t39TN1L+t39TN1L+t3++mk+/UzdS/rd/UzdS/rd8l FmhFRmsANQiBQioBQ0oUAE9KAwBRSgMAXAiBYUoUAHBoAAAAAAwVaHZMdwAWaNpY9wAAIwNqAAAA ABZoGjfyADBKDwBDShQAT0oDAFFKAwBVCAFhShQAGhZoRUZrADBKDwBDShQAT0oDAFFKAwBhShQA AAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIAR8WaEVGawBCKgFDShQAT0oDAFFK AwBhShQAcGgAAAAAHxZo2lj3AEIqAUNKFABPSgMAUUoDAGFKFABwaAAAAAAAOoc3AQCRNwEA5DgB AOU4AQDvOAEAgzoBAIQ6AQCOOgEA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAACYAAAAAAAAAAAA AAAA8gAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAABa AABrZOBPAAAWJAEXJAFJZgEAAABlZEtM1jcClg8ACNYwAALT/xQHXyQAQgAAAAAAAAAAAAAAAAAA AAAAAIBCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8AAAD/G9YI AAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAw8ANNYGAAEPAw8AQtYDAAIBYfYD AABpdEtM1jdaAABrZHRPAAAWJAEXJAFJZgEAAABlZEtM1jcClg8ACNYwAALT/8sGXyQAQgAAAAAA AAAAAAAAAAAAAAAAAIBCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAA AP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAw8ANNYGAAEPAw8A QtYDAAIBYfYDAABpdEtM1jcNAAATpAAAFKQAABYkAUlmAQAAAFskAFwkAAAHsDkBALE5AQDoOQEA 6TkBAOw5AQDtOQEA7zkBAPA5AQAyOgEAMzoBADc6AQA4OgEAOjoBADs6AQB7OgEAfDoBAH86AQCA OgEAgjoBAIM6AQCEOgEAjToBAI46AQCPOgEAuDoBALk6AQDFOgEAxjoBAMg6AQDJOgEA5zoBAOg6 AQDyOgEA8zoBAPU6AQD2OgEAHDsBAB07AQAmOwEAJzsBACk7AQAqOwEATTsBAE47AQBZOwEAWjsB AFw7AQBdOwEAiTsBAIo7AQCWOwEAlzsBAJk7AQCaOwEAwzsBAMQ7AQDNOwEAzjsBANQ7AQD07fTf zb307fTfzb307fTfzb2tppOt9O3038299O3038299O3038299O3038299O3038299O303829JRZo RUZrADUIgUIqAUNKFABPSgMAUUoDAFwIgWFKFABwaAAAAAAMFWh2THcAFmjaWPcAAB8WaNpY9wBC KgFDShQAT0oDAFFKAwBhShQAcGgAAAAAHxZoRUZrAEIqAUNKFABPSgMAUUoDAGFKFABwaAAAAAAj A2oAAAAAFmgaN/IAMEoPAENKFABPSgMAUUoDAFUIAWFKFAAaFmhFRmsAMEoPAENKFABPSgMAUUoD AGFKFAAADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBADrUOwEA1TsBAPY7AQD3 OwEABTwBAAY8AQAJPAEACjwBADo8AQA7PAEAYjwBAGM8AQB7PAEAfDwBALM8AQC0PAEAtzwBALg8 AQC6PAEAuzwBAPE8AQDyPAEA9DwBAPU8AQD3PAEA+DwBAC89AQAwPQEAMz0BADQ9AQA2PQEANz0B AHk9AQB6PQEAfj0BAH89AQCBPQEAgj0BAMI9AQDDPQEAxj0BAMc9AQDJPQEAyj0BAMs9AQDUPQEA 1T0BANY9AQD8PQEA/T0BAAc+AQAIPgEACj4BAAs+AQAzPgEAND4BAEQ+AQBFPgEARz4BAPTt9N/N vfTt9N/NvfTt9N/NvfTt9N/NvfTt9N/NvfTt9N/NvfTt9N/Nva2mk6307fTfzb307fTfzb0lFmhF RmsANQiBQioBQ0oUAE9KAwBRSgMAXAiBYUoUAHBoAAAAAAwVaHZMdwAWaNpY9wAAHxZo2lj3AEIq AUNKFABPSgMAUUoDAGFKFABwaAAAAAAfFmhFRmsAQioBQ0oUAE9KAwBRSgMAYUoUAHBoAAAAACMD agAAAAAWaBo38gAwSg8AQ0oUAE9KAwBRSgMAVQgBYUoUABoWaEVGawAwSg8AQ0oUAE9KAwBRSgMA YUoUAAAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo38gBVCAEAOo46AQDKPQEAyz0BANU9 AQCXQAEAmEABAKJAAQBIQQEA8gAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA 8gAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAABaAABr ZLhQAAAWJAEXJAFJZgEAAABlZEtM1jcClg8ACNYwAALT/xQHXyQAQgAAAAAAAAAAAAAAAAAAAAAA AIBCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA /wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAw8ANNYGAAEPAw8AQtYDAAIBYfYDAABp dEtM1jdaAABrZExQAAAWJAEXJAFJZgEAAABlZEtM1jcClg8ACNYwAALT/xQHXyQAQgAAAAAAAAAA AAAAAAAAAAAAAIBCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8A AAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAw8ANNYGAAEPAw8AQtYD AAIBYfYDAABpdEtM1jcNAAATpAAAFKQAABYkAUlmAQAAAFskAFwkAAAHRz4BAEg+AQBvPgEAcD4B AH0+AQB+PgEAgD4BAIE+AQCqPgEAqz4BALc+AQC4PgEAuj4BALs+AQDkPgEA5T4BAO4+AQDvPgEA Az8BAAQ/AQAvPwEAMD8BADo/AQA7PwEAPj8BAD8/AQBvPwEAcD8BAKs/AQCsPwEAxD8BAMU/AQD8 PwEA/T8BAABAAQABQAEAA0ABAARAAQBGQAEAR0ABAEtAAQBMQAEATkABAE9AAQCPQAEAkEABAJNA AQCUQAEAlkABAJdAAQCYQAEAoUABAKJAAQCxQAEAskABAOJAAQDjQAEA8EABAPFAAQD07fTfzb30 7fTfzb307fTfzb307fTfzb307fTfzb307fTfzb307fTfzb307fTfzb2tppOtvfTt9N/NJRZoRUZr ADUIgUIqAUNKFABPSgMAUUoDAFwIgWFKFABwaAAAAAAMFWh2THcAFmjaWPcAAB8WaNpY9wBCKgFD ShQAT0oDAFFKAwBhShQAcGgAAAAAHxZoRUZrAEIqAUNKFABPSgMAUUoDAGFKFABwaAAAAAAjA2oA AAAAFmgaN/IAMEoPAENKFABPSgMAUUoDAFUIAWFKFAAaFmhFRmsAMEoPAENKFABPSgMAUUoDAGFK FAAADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBADrxQAEACEEBAAlBAQBAQQEA QUEBAERBAQBFQQEAR0EBAEhBAQBJQQEAUkEBAFNBAQBgQQEAYUEBAJFBAQCSQQEArEEBAK1BAQDE QQEAxUEBAPxBAQD9QQEAAEIBAAFCAQADQgEABEIBAAVCAQAOQgEAD0IBADpCAQA7QgEAa0IBAGxC AQB7QgEAfEIBAJdCAQCYQgEAz0IBANBCAQDTQgEA1EIBANZCAQDXQgEA2EIBAOFCAQDiQgEA/0IB AABDAQAwQwEAMUMBAIlDAQCKQwEApkMBAKdDAQDeQwEA30MBAOJDAQDjQwEA5UMBAO/k3eTPve+t ppOt7+Td5M+97+Td5M+9762mk63v5N3kz73v5N3kz73vraaTre/k3eTPve/k3eTPve8lFmhFRmsA NQiBQioBQ0oUAE9KAwBRSgMAXAiBYUoUAHBoAAAAAAwVaHZMdwAWaNpY9wAAHxZo2lj3AEIqAUNK FABPSgMAUUoDAGFKFABwaAAAAAAjA2oAAAAAFmgaN/IAMEoPAENKFABPSgMAUUoDAFUIAWFKFAAa FmhFRmsAMEoPAENKFABPSgMAUUoDAGFKFAAADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmga N/IAVQgBHxZoRUZrAEIqAUNKFABPSgMAUUoDAGFKFABwaAAAAAAAOkhBAQBJQQEAU0EBAARCAQAF QgEAD0IBANdCAQClAAAAAAAAAAAAAAAAmAAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAAA+AAAAAAAA AAAAAAAAmAAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABaAABrZJBR AAAWJAEXJAFJZgEAAABlZEtM1jcClg8ACNYwAALT/xQHXyQAQgAAAAAAAAAAAAAAAAAAAAAAAIBC AAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAA AP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAw8ANNYGAAEPAw8AQtYDAAIBYfYDAABpdEtM 1jcNAAATpAAAFKQAABYkAUlmAQAAAFskAFwkAFoAAGtkJFEAABYkARckAUlmAQAAAGVkS0zWNwKW DwAI1jAAAtP/FAdfJABCAAAAAAAAAAAAAAAAAAAAAAAAgEIAAAAAAAAAAAAAAAAAAAAAAAAKdAAA oAQU9gJWExU2ARf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAA AP8z1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFh9gMAAGl0S0zWNwAG10IBANhCAQDiQgEA5kMBAOdD AQDxQwEAwUQBAKUAAAAAAAAAAAAAAACYAAAAAAAAAAAAAAAAmAAAAAAAAAAAAAAAAD4AAAAAAAAA AAAAAACYAAAAAAAAAAAAAAAAmAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFoAAGtkaFIA ABYkARckAUlmAQAAAGVkS0zWNwKWDwAI1jAAAtP/FAdfJABCAAAAAAAAAAAAAAAAAAAAAAAAgEIA AAAAAAAAAAAAAAAAAAAAAAAKdAAAoAQU9gJWExU2ARf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA /xzWCAAAAP8AAAD/HdYIAAAA/wAAAP8z1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFh9gMAAGl0S0zW Nw0AABOkAAAUpAAAFiQBSWYBAAAAWyQAXCQAWgAAa2T8UQAAFiQBFyQBSWYBAAAAZWRLTNY3ApYP AAjWMAAC0/8UB18kAEIAAAAAAAAAAAAAAAAAAAAAAACAQgAAAAAAAAAAAAAAAAAAAAAAAAp0AACg BBT2AlYTFTYBF/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA /zPWBgABDwMPADTWBgABDwMPAELWAwACAWH2AwAAaXRLTNY3AAblQwEA5kMBAOdDAQDwQwEA8UMB AP9DAQAARAEAMEQBADFEAQBcRAEAXUQBAIFEAQCCRAEAuUQBALpEAQC9RAEAvkQBAMBEAQDBRAEA wkQBAMtEAQDMRAEAzUQBAO5EAQDvRAEA/kQBAP9EAQABRQEAAkUBAChFAQApRQEANUUBADZFAQA8 RQEAPUUBAF1FAQBeRQEAaUUBAGpFAQBtRQEAbkUBAJ5FAQCfRQEA0EUBANFFAQD0RQEA9UUBACxG AQAtRgEAMEYBADFGAQAzRgEANEYBAHZGAQB3RgEAe0YBAHxGAQB+RgEAf0YBAO/o1e/FurO6pZPF urO6pZPF7+jV77qzuqWTxbqzuqWTxbqzuqWTxbqzuqWTxbqzuqWTxbqzuqWTxbojA2oAAAAAFmga N/IAMEoPAENKFABPSgMAUUoDAFUIAWFKFAAaFmhFRmsAMEoPAENKFABPSgMAUUoDAGFKFAAADBVo dkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBHxZoRUZrAEIqAUNKFABPSgMAUUoDAGFK FABwaAAAAAAlFmhFRmsANQiBQioBQ0oUAE9KAwBRSgMAXAiBYUoUAHBoAAAAAAwVaHZMdwAWaNpY 9wAAHxZo2lj3AEIqAUNKFABPSgMAUUoDAGFKFABwaAAAAAAAOsFEAQDCRAEAzEQBAMdGAQDIRgEA 0kYBALJHAQClAAAAAAAAAAAAAAAAmAAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAAA+AAAAAAAAAAAA AAAAmAAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABaAABrZEBTAAAW JAEXJAFJZgEAAABlZEtM1jcClg8ACNYwAALT/xQHXyQAQgAAAAAAAAAAAAAAAAAAAAAAAIBCAAAA AAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c 1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAw8ANNYGAAEPAw8AQtYDAAIBYfYDAABpdEtM1jcN AAATpAAAFKQAABYkAUlmAQAAAFskAFwkAFoAAGtk1FIAABYkARckAUlmAQAAAGVkS0zWNwKWDwAI 1jAAAtP/FAdfJABCAAAAAAAAAAAAAAAAAAAAAAAAgEIAAAAAAAAAAAAAAAAAAAAAAAAKdAAAoAQU 9gJWExU2ARf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP8z 1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFh9gMAAGl0S0zWNwAGf0YBAL9GAQDARgEAw0YBAMRGAQDG RgEAx0YBAMhGAQDRRgEA0kYBAOJGAQDjRgEAE0cBABRHAQBZRwEAWkcBAHJHAQBzRwEAqkcBAKtH AQCuRwEAr0cBALFHAQCyRwEAs0cBALxHAQC9RwEA3EcBAN1HAQANSAEADkgBAEtIAQBMSAEAa0gB AGxIAQCjSAEApEgBAKdIAQCoSAEAqkgBAKtIAQCsSAEAtUgBALZIAQDTSAEA1EgBAARJAQAFSQEA PEkBAD1JAQBXSQEAWEkBAI9JAQCQSQEAk0kBAJRJAQCWSQEAl0kBAJhJAQD57uDOvq6nlK6+7vnu 4M6+7vnu4M6+rqeUrr7u+e7gzr7u+e7gzr6up5Suvu757uDOvu757uDOvq6nAAAlFmhFRmsANQiB QioBQ0oUAE9KAwBRSgMAXAiBYUoUAHBoAAAAAAwVaHZMdwAWaNpY9wAAHxZo2lj3AEIqAUNKFABP SgMAUUoDAGFKFABwaAAAAAAfFmhFRmsAQioBQ0oUAE9KAwBRSgMAYUoUAHBoAAAAACMDagAAAAAW aBo38gAwSg8AQ0oUAE9KAwBRSgMAVQgBYUoUABoWaEVGawAwSg8AQ0oUAE9KAwBRSgMAYUoUAAAV A2oAAAAAFWh2THcAFmgaN/IAVQgBDBVodkx3ABZoGjfyADqyRwEAs0cBAL1HAQCrSAEArEgBALZI AQCXSQEApQAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAACYAAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAA AJgAAAAAAAAAAAAAAACYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWgAAa2QYVAAAFiQB FyQBSWYBAAAAZWRLTNY3ApYPAAjWMAAC0/8UB18kAEIAAAAAAAAAAAAAAAAAAAAAAACAQgAAAAAA AAAAAAAAAAAAAAAAAAp0AACgBBT2AlYTFTYBF/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYI AAAA/wAAAP8d1ggAAAD/AAAA/zPWBgABDwMPADTWBgABDwMPAELWAwACAWH2AwAAaXRLTNY3DQAA E6QAABSkAAAWJAFJZgEAAABbJABcJABaAABrZKxTAAAWJAEXJAFJZgEAAABlZEtM1jcClg8ACNYw AALT/xQHXyQAQgAAAAAAAAAAAAAAAAAAAAAAAIBCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYC VhMVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YG AAEPAw8ANNYGAAEPAw8AQtYDAAIBYfYDAABpdEtM1jcABpdJAQCYSQEAokkBAFdKAQBYSgEAc0oB AIdLAQClAAAAAAAAAAAAAAAAmAAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAA mAAAAAAAAAAAAAAAAJgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABaAABrZPBUAAAWJAEX JAFJZgEAAABlZEtM1jcClg8ACNYwAALT/xQHXyQAQgAAAAAAAAAAAAAAAAAAAAAAAIBCAAAAAAAA AAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggA AAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAw8ANNYGAAEPAw8AQtYDAAIBYfYDAABpdEtM1jcNAAAT pAAAFKQAABYkAUlmAQAAAFskAFwkAFoAAGtkhFQAABYkARckAUlmAQAAAGVkS0zWNwKWDwAI1jAA AtP/FAdfJABCAAAAAAAAAAAAAAAAAAAAAAAAgEIAAAAAAAAAAAAAAAAAAAAAAAAKdAAAoAQU9gJW ExU2ARf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP8z1gYA AQ8DDwA01gYAAQ8DDwBC1gMAAgFh9gMAAGl0S0zWNwAGmEkBAKFJAQCiSQEAtUkBALZJAQDmSQEA 50kBAP1JAQD+SQEAF0oBABhKAQBPSgEAUEoBAFNKAQBUSgEAVkoBAFdKAQBYSgEAckoBAHNKAQCa SgEAm0oBANdKAQDYSgEA70oBAPBKAQBBSwEAQksBAH5LAQB/SwEAg0sBAIRLAQCGSwEAh0sBAIhL AQCJSwEAiksBAItLAQCMSwEAoEsBAKFLAQDs3MzBusGsmszBusGsmszck+zczMG6wayazMG6waya zNyTgGuAwbrBAAAAAAAAAAAAACgDashVAAAWaBo38gBCKgFPSgMAUUoDAFUIAW1ICQBwaAAAAABz SAkAACUVaG9oHgAWaNpY9wBCKgFPSgMAUUoDAG1ICQBwaAAAAABzSAkADBVodkx3ABZo2lj3AAAj A2oAAAAAFmgaN/IAMEoPAENKFABPSgMAUUoDAFUIAWFKFAAaFmhFRmsAMEoPAENKFABPSgMAUUoD AGFKFAAADBVodkx3ABZoGjfyAAAVA2oAAAAAFWh2THcAFmgaN/IAVQgBHxZoRUZrAEIqAUNKFABP SgMAUUoDAGFKFABwaAAAAAAfFmjaWPcAQioBQ0oUAE9KAwBRSgMAYUoUAHBoAAAAACUWaEVGawA1 CIFCKgFDShQAT0oDAFFKAwBcCIFhShQAcGgAAAAAACiHSwEAiEsBAIlLAQCLSwEAqEsBAKUAAAAA AAAAAAAAAACZAAAAAAAAAAAAAAAAmQAAAAAAAAAAAAAAAHoAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHwAAAyQBEmTh AAAAE6QAABSkAAAWJAEYhPj/GYT4/xsmICMkAi+ELQBJZgEAAABbJABcJABhJAFnZG9oHgAACwAA E6QAABSkAABbJABcJABlZEtM1jdaAABrZFxVAAAWJAEXJAFJZgEAAABlZEtM1jcClg8ACNYwAALT /xQHXyQAQgAAAAAAAAAAAAAAAAAAAAAAAIBCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMV NgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEP Aw8ANNYGAAEPAw8AQtYDAAIBYfYDAABpdEtM1jcABKFLAQCiSwEApUsBAKZLAQCnSwEAqEsBAKlL AQDFSwEAxksBAN5LAQDfSwEA4EsBAAVMAQAGTAEAEEwBABFMAQATTAEAFEwBADxMAQA9TAEARUwB AOvY68Gyq6ObiHhtZm1YRjZtZm1YAAAAAB8WaEVGawBCKgFDShQAT0oDAFFKAwBhShQAcGgAAAAA IwNqAAAAABZoGjfyADBKDwBDShQAT0oDAFFKAwBVCAFhShQAGhZoRUZrADBKDwBDShQAT0oDAFFK AwBhShQAAAwVaHZMdwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIAR8WaNpY9wBCKgFDShQA T0oDAFFKAwBhShQAcGgAAAAAJRZoRUZrADUIgUIqAUNKFABPSgMAUUoDAFwIgWFKFABwaAAAAAAO FmjaWPcAbUgJAHNICQAADhZoRUZrAG1ICQBzSAkAAAwVaHZMdwAWaNpY9wAAHRVodkx3ABZo2lj3 AEIqCE9KAwBRSgMAcGj///8ALQNqAAAAABVodkx3ABZoGjfyADUIgUIqCENKFABPSgQAUUoEAFUI AXBo////ACQVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABwaP///wAAJxVodkx3ABZoRUZr ADUIgUIqCENKFABPSgQAUUoEAG8oAXBo////AAAUqEsBAKlLAQDGSwEA30sBAJZNAQCXTQEAnwAA AAAAAAAAAAAAAJoAAAAAAAAAAAAAAACNAAAAAAAAAAAAAAAAjQAAAAAAAAAAAAAAADMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAWgAAa2T8VgAAFiQBFyQBSWYBAAAAZWRLTNY3ApYPAAjWMAAC0/+/ B18kAEIAAAAAAAAAAAAAAAAAAAAAAACAQgAAAAAAAAAAAAAAAAAAAAAAAAp0AACgBBT2AlYTFTYB F/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zPWBgABDwMP ADTWBgABDwMPAELWAwACAWH2AwAAaXRLTNY3DQAAE6QAABSkAAAWJAFJZgEAAABbJABcJAAABAMA ZWRLTNY3YAAAa2RkVgAAFiQBFyQBSWYBAAAAZWRLTNY3B5ThAAjWGgAB4v80AoBGwgEAAAAAAAAA AAAAAAAAAAAACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEX 9gMAABrWBAAAAP8b1gQAAAD/HNYEAAAA/x3WBAAAAP8elC0AM9YGAAEPAw8ANNYGAAEPAwAAQtYD AAEBYfYDAABpdEtM1jdw1goAAAD/mQAAAAAAAAVFTAEARkwBAEhMAQBJTAEAd0wBAHhMAQCETAEA hUwBAItMAQCMTAEAskwBALNMAQC7TAEAvEwBAL9MAQDATAEAEE0BABFNAQBlTQEAZk0BAJVNAQCW TQEAl00BAJhNAQCZTQEAmk0BAJtNAQCvTQEAsE0BALFNAQC0TQEAtU0BAO3d0svSve3d0svSve3d 0svSve3draaTfpPSy9JqV2oAAAAAAAAAAAAAAAAAAAAkFWh2THcAFmhFRmsANQiBQioIQ0oUAE9K BABRSgQAcGj///8AACcVaHZMdwAWaEVGawA1CIFCKghDShQAT0oEAFFKBABvKAFwaP///wAoA2po VwAAFmgaN/IAQioBT0oDAFFKAwBVCAFtSAkAcGgAAAAAc0gJAAAlFWhvaB4AFmjaWPcAQioBT0oD AFFKAwBtSAkAcGgAAAAAc0gJAAwVaHZMdwAWaNpY9wAAHxZo2lj3AEIqAUNKFABPSgMAUUoDAGFK FABwaAAAAAAaFmhFRmsAMEoPAENKFABPSgMAUUoDAGFKFAAADBVodkx3ABZoGjfyAAAVA2oAAAAA FWh2THcAFmgaN/IAVQgBHxZoRUZrAEIqAUNKFABPSgMAUUoDAGFKFABwaAAAAAAjA2oAAAAAFmga N/IAMEoPAENKFABPSgMAUUoDAFUIAWFKFAAAH5dNAQCYTQEAmk0BALdNAQC4TQEAy00BAM1NAQDo TQEA8wAAAAAAAAAAAAAAAPMAAAAAAAAAAAAAAADUAAAAAAAAAAAAAAAAdAAAAAAAAAAAAAAAAG8A AAAAAAAAAAAAAABiAAAAAAAAAAAAAAAAYgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAT pAAAFKQAABYkAUlmAQAAAFskAFwkAAAEAwBlZEtM1jdgAABrZARYAAAWJAEXJAFJZgEAAABlZEtM 1jcHlOEACNYaAAHi/zQCgEbCAQAAAAAAAAAAAAAAAAAAAAAJ1gKgAQp0AACgBA02IA6U+P8PlPj/ EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2ARf2AwAAGtYEAAAA/xvWBAAAAP8c1gQAAAD/HdYEAAAA /x6ULQAz1gYAAQ8DDwA01gYAAQ8DAABC1gMAAQFh9gMAAGl0S0zWN3DWCgAAAP+ZAAAAAAAfAAAD JAESZOEAAAATpAAAFKQAABYkARiE+P8ZhPj/GyYgIyQCL4QtAElmAQAAAFskAFwkAGEkAWdkb2ge AAALAAATpAAAFKQAAFskAFwkAGVkS0zWNwAHtU0BALZNAQC3TQEAuE0BAMpNAQDLTQEAzE0BAM1N AQDnTQEA6E0BAOlNAQDqTQEA600BAPFNAQDyTQEA800BAPpNAQD7TQEA/E0BACROAQAlTgEAOE4B ADlOAQA6TgEAO04BAEBOAQBBTgEAQk4BAGVOAQDo2dLKwrKisqLSsqKyotKPfHFqcVxKotKPfHFq AAAAACMDagAAAAAWaBo38gAwSg8AQ0oUAE9KAwBRSgMAVQgBYUoUABoWaEVGawAwSg8AQ0oUAE9K AwBRSgMAYUoUAAAMFWh2THcAFmgaN/IAABUDagAAAAAVaHZMdwAWaBo38gBVCAElFmjaWPcANQiB QioBQ0oUAE9KAwBRSgMAXAiBYUoUAHBoAAAAACUWaEVGawA1CIFCKgFDShQAT0oDAFFKAwBcCIFh ShQAcGgAAAAAHxZo2lj3AEIqAUNKFABPSgMAUUoDAGFKFABwaAAAAAAfFmhFRmsAQioBQ0oUAE9K AwBRSgMAYUoUAHBoAAAAAA4WaNpY9wBtSAkAc0gJAAAOFmhFRmsAbUgJAHNICQAADBVodkx3ABZo 2lj3AAAdFWh2THcAFmjaWPcAQioIT0oDAFFKAwBwaP///wAtA2oAAAAAFWh2THcAFmgaN/IANQiB QioIQ0oUAE9KBABRSgQAVQgBcGj///8AABzoTQEA6U0BAOtNAQDyTQEA800BAPtNAQCnAAAAAAAA AAAAAAAAmgAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAABCAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAA AAAAABQAAAMkAg+EwAMTpAAAFKQAABYkAUlmAQAAAFskAFwkAF6EwANhJAJYAABrZABZAAAWJAEX JAFJZgEAAABlZEtM1jcI1jAAAgAAXQsyJIBCAAAAAAAAAAAAAAAAAAAAAAAAgEIAAAAAAAAAAAAA AAAAAAAAAAAKdAAAoAQU9gJWExU2ARf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8A AAD/HdYIAAAA/wAAAP8z1gYAAQ8DAAA01gYAAQ8DAABC1gMAAgFh9gMAAGl0S0zWNw0AABOkAAAU pAAAFiQBSWYBAAAAWyQAXCQAWAAAa2ScWAAAFiQBFyQBSWYBAAAAZWRLTNY3CNYwAAIAAF0LMiSA QgAAAAAAAAAAAAAAAAAAAAAAAIBCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMA ABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAwAANNYG AAEPAwAAQtYDAAIBYfYDAABpdEtM1jcABftNAQA6TgEAO04BAEFOAQB9TgEAfk4BAPIAAAAAAAAA AAAAAACaAAAAAAAAAAAAAAAAhgAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAA AAAAWAAAa2TIWQAAFiQBFyQBSWYBAAAAZWRLTNY3CNYwAAIAAF0LMiSAQgAAAAAAAAAAAAAAAAAA AAAAAIBCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8AAAD/G9YI AAAA/wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAwAANNYGAAEPAwAAQtYDAAIBYfYD AABpdEtM1jcUAAADJAIPhMADE6QAABSkAAAWJAFJZgEAAABbJABcJABehMADYSQCWAAAa2RkWQAA FiQBFyQBSWYBAAAAZWRLTNY3CNYwAAIAAF0LMiSAQgAAAAAAAAAAAAAAAAAAAAAAAIBCAAAAAAAA AAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggA AAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAwAANNYGAAEPAwAAQtYDAAIBYfYDAABpdEtM1jcNAAAT pAAAFKQAABYkAUlmAQAAAFskAFwkAAAFZU4BAGZOAQB7TgEAfE4BAH1OAQB+TgEAf04BAIBOAQCB TgEAgk4BAINOAQCETgEAhU4BAJNOAQCUTgEAlU4BAJZOAQCXTgEAn04BAKBOAQChTgEAqE4BAKlO AQCqTgEA2U4BANpOAQD0TgEA9U4BAPZOAQD3TgEA/E4BAP1OAQD+TgEAKU8BACpPAQBHTwEASE8B AElPAQBKTwEA9ObUxL2un66fvY/Ej8S9j8SPxL18afRi9ObUxL18afRi9ObUxL0AAAwVaHZMdwAW aBo38gAAJRZo2lj3ADUIgUIqAUNKFABPSgMAUUoDAFwIgWFKFABwaAAAAAAlFmhFRmsANQiBQioB Q0oUAE9KAwBRSgMAXAiBYUoUAHBoAAAAAB8WaEVGawBCKgFDShQAT0oDAFFKAwBhShQAcGgAAAAA HRVodkx3ABZo2lj3AEIqAU9KAwBRSgMAcGgAAAAAHRVodkx3ABZoRUZrAEIqAU9KAwBRSgMAcGgA AAAADBVodkx3ABZo2lj3AAAfFmjaWPcAQioBQ0oUAE9KAwBRSgMAYUoUAHBoAAAAACMDagAAAAAW aBo38gAwSg8AQ0oUAE9KAwBRSgMAVQgBYUoUABoWaEVGawAwSg8AQ0oUAE9KAwBRSgMAYUoUAAAV A2oAAAAAFWh2THcAFmgaN/IAVQgBACZ+TgEAgE4BAIJOAQCDTgEAhU4BAJROAQCVTgEAl04BAPIA AAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADyAAAAAAAA AAAAAAAAQgAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAAAAAAAAAAAAABYAABrZJBaAAAWJAEXJAFJ ZgEAAABlZEtM1jcI1jAAAgAAXQsyJIBCAAAAAAAAAAAAAAAAAAAAAAAAgEIAAAAAAAAAAAAAAAAA AAAAAAAKdAAAoAQU9gJWExU2ARf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/ HdYIAAAA/wAAAP8z1gYAAQ8DAAA01gYAAQ8DAABC1gMAAgFh9gMAAGl0S0zWN1gAAGtkLFoAABYk ARckAUlmAQAAAGVkS0zWNwjWMAACAABdCzIkgEIAAAAAAAAAAAAAAAAAAAAAAACAQgAAAAAAAAAA AAAAAAAAAAAAAAp0AACgBBT2AlYTFTYBF/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA /wAAAP8d1ggAAAD/AAAA/zPWBgABDwMAADTWBgABDwMAAELWAwACAWH2AwAAaXRLTNY3DQAAE6QA ABSkAAAWJAFJZgEAAABbJABcJAAAB5dOAQCgTgEAoU4BAKlOAQD2TgEA904BAPIAAAAAAAAAAAAA AACaAAAAAAAAAAAAAAAAhgAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAAuAAAAAAAAAAAAAAAAAAAA WAAAa2RYWwAAFiQBFyQBSWYBAAAAZWRLTNY3CNYwAAIAAF0LMiSAQgAAAAAAAAAAAAAAAAAAAAAA AIBCAAAAAAAAAAAAAAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA /wAAAP8c1ggAAAD/AAAA/x3WCAAAAP8AAAD/M9YGAAEPAwAANNYGAAEPAwAAQtYDAAIBYfYDAABp dEtM1jcUAAADJAIPhMADE6QAABSkAAAWJAFJZgEAAABbJABcJABehMADYSQCWAAAa2T0WgAAFiQB FyQBSWYBAAAAZWRLTNY3CNYwAAIAAF0LMiSAQgAAAAAAAAAAAAAAAAAAAAAAAIBCAAAAAAAAAAAA AAAAAAAAAAAACnQAAKAEFPYCVhMVNgEX9gMAABrWCAAAAP8AAAD/G9YIAAAA/wAAAP8c1ggAAAD/ AAAA/x3WCAAAAP8AAAD/M9YGAAEPAwAANNYGAAEPAwAAQtYDAAIBYfYDAABpdEtM1jcNAAATpAAA FKQAABYkAUlmAQAAAFskAFwkAAAF904BAP1OAQBJTwEASk8BAExPAQBOTwEA6wAAAAAAAAAAAAAA AN4AAAAAAAAAAAAAAACGAAAAAAAAAAAAAAAA3gAAAAAAAAAAAAAAAN4AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAFgAAGtkvFsAABYkARckAUlmAQAAAGVkS0zWNwjWMAACAABdCzIkgEIAAAAAAAAAAAAAAAAA AAAAAACAQgAAAAAAAAAAAAAAAAAAAAAAAAp0AACgBBT2AlYTFTYBF/YDAAAa1ggAAAD/AAAA/xvW CAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zPWBgABDwMAADTWBgABDwMAAELWAwACAWH2 AwAAaXRLTNY3DQAAE6QAABSkAAAWJAFJZgEAAABbJABcJAAUAAADJAIPhMADE6QAABSkAAAWJAFJ ZgEAAABbJABcJABehMADYSQCAAVKTwEAS08BAExPAQBNTwEATk8BAE9PAQBQTwEAUU8BAFtPAQBc TwEAXU8BAF5PAQBfTwEAaE8BAGlPAQBqTwEAcU8BAHJPAQBzTwEAnE8BAJ1PAQCxTwEAsk8BALNP AQC0TwEAuU8BALpPAQC7TwEA3k8BAN9PAQD0TwEA9U8BAPZPAQD3TwEA+E8BAPDh8OHayrrKutrK usq62qeUiYKJdGK62qeUiYKJdGK62l4AAAAAAAAAAAAAAAAAAAYWaEVGawAAIwNqAAAAABZoGjfy ADBKDwBDShQAT0oDAFFKAwBVCAFhShQAGhZoRUZrADBKDwBDShQAT0oDAFFKAwBhShQAAAwVaHZM dwAWaBo38gAAFQNqAAAAABVodkx3ABZoGjfyAFUIASUWaNpY9wA1CIFCKgFDShQAT0oDAFFKAwBc CIFhShQAcGgAAAAAJRZoRUZrADUIgUIqAUNKFABPSgMAUUoDAFwIgWFKFABwaAAAAAAfFmjaWPcA QioBQ0oUAE9KAwBRSgMAYUoUAHBoAAAAAB8WaEVGawBCKgFDShQAT0oDAFFKAwBhShQAcGgAAAAA DBVodkx3ABZo2lj3AAAdFWh2THcAFmjaWPcAQioBT0oDAFFKAwBwaAAAAAAdFWh2THcAFmhFRmsA QioBT0oDAFFKAwBwaAAAAAAAIk5PAQBPTwEAUU8BAFxPAQBdTwEAX08BAGlPAQCnAAAAAAAAAAAA AAAAmgAAAAAAAAAAAAAAAJoAAAAAAAAAAAAAAABCAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAJoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAAGtkhFwAABYkARckAUlmAQAA AGVkS0zWNwjWMAACAABdCzIkgEIAAAAAAAAAAAAAAAAAAAAAAACAQgAAAAAAAAAAAAAAAAAAAAAA AAp0AACgBBT2AlYTFTYBF/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggA AAD/AAAA/zPWBgABDwMAADTWBgABDwMAAELWAwACAWH2AwAAaXRLTNY3DQAAE6QAABSkAAAWJAFJ ZgEAAABbJABcJABYAABrZCBcAAAWJAEXJAFJZgEAAABlZEtM1jcI1jAAAgAAXQsyJIBCAAAAAAAA AAAAAAAAAAAAAAAAgEIAAAAAAAAAAAAAAAAAAAAAAAAKdAAAoAQU9gJWExU2ARf2AwAAGtYIAAAA /wAAAP8b1ggAAAD/AAAA/xzWCAAAAP8AAAD/HdYIAAAA/wAAAP8z1gYAAQ8DAAA01gYAAQ8DAABC 1gMAAgFh9gMAAGl0S0zWNwAGaU8BAGpPAQByTwEAs08BALRPAQC6TwEApwAAAAAAAAAAAAAAAJMA AAAAAAAAAAAAAACGAAAAAAAAAAAAAAAALgAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAAAAAABYAABr ZExdAAAWJAEXJAFJZgEAAABlZEtM1jcI1jAAAgAAXQsyJIBCAAAAAAAAAAAAAAAAAAAAAAAAgEIA AAAAAAAAAAAAAAAAAAAAAAAKdAAAoAQU9gJWExU2ARf2AwAAGtYIAAAA/wAAAP8b1ggAAAD/AAAA /xzWCAAAAP8AAAD/HdYIAAAA/wAAAP8z1gYAAQ8DAAA01gYAAQ8DAABC1gMAAgFh9gMAAGl0S0zW Nw0AABOkAAAUpAAAFiQBSWYBAAAAWyQAXCQAFAAAAyQCD4TAAxOkAAAUpAAAFiQBSWYBAAAAWyQA XCQAXoTAA2EkAlgAAGtk6FwAABYkARckAUlmAQAAAGVkS0zWNwjWMAACAABdCzIkgEIAAAAAAAAA AAAAAAAAAAAAAACAQgAAAAAAAAAAAAAAAAAAAAAAAAp0AACgBBT2AlYTFTYBF/YDAAAa1ggAAAD/ AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d1ggAAAD/AAAA/zPWBgABDwMAADTWBgABDwMAAELW AwACAWH2AwAAaXRLTNY3AAW6TwEA9k8BAPdPAQD4TwEA+k8BAPtPAQD9TwEA/k8BAABQAQABUAEA A1ABAARQAQAFUAEABlABAAdQAQDyAAAAAAAAAAAAAAAAmgAAAAAAAAAAAAAAAI4AAAAAAAAAAAAA AACFAAAAAAAAAAAAAAAAgwAAAAAAAAAAAAAAAIUAAAAAAAAAAAAAAACDAAAAAAAAAAAAAAAAhQAA AAAAAAAAAAAAAIMAAAAAAAAAAAAAAACFAAAAAAAAAAAAAAAAgwAAAAAAAAAAAAAAAIEAAAAAAAAA AAAAAACDAAAAAAAAAAAAAAAAgQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUcAAAEAAAAI AAATpAAAFKQAAGdk5AaQAAALAAATpAAAFKQAAFskAFwkAGVkS0zWN1gAAGtksF0AABYkARckAUlm AQAAAGVkS0zWNwjWMAACAABdCzIkgEIAAAAAAAAAAAAAAAAAAAAAAACAQgAAAAAAAAAAAAAAAAAA AAAAAAp0AACgBBT2AlYTFTYBF/YDAAAa1ggAAAD/AAAA/xvWCAAAAP8AAAD/HNYIAAAA/wAAAP8d 1ggAAAD/AAAA/zPWBgABDwMAADTWBgABDwMAAELWAwACAWH2AwAAaXRLTNY3DQAAE6QAABSkAAAW JAFJZgEAAABbJABcJAAADvhPAQD5TwEA+08BAPxPAQD+TwEA/08BAAFQAQACUAEABFABAAVQAQAG UAEAB1ABAAhQAQAJUAEAClABAAtQAQAMUAEADVABAA5QAQAPUAEAEVABABJQAQA2UAEAN1ABAFlQ AQBbUAEAplABAKdQAQATUQEAFFEBAEFRAQBCUQEAZlEBAGdRAQBsUQEAelEBAJFRAQCSUQEAplEB ALxRAQC9UQEA51EBAOhRAQChUgEAolIBAPNSAQD0UgEAclMBAHNTAQCDUwEAhFMBAClUAQAqVAEA O1QBADxUAQCnVAEAqFQBAKxUAQCtVAEAsVQBALJUAQC2VAEAt1QBAO1UAQD38/fz9/P38+/z7/Pv 8+/z7/Pv8+Xh5eHZ4eXh5eHl4eXh1eHl1eHL1cG9s6+zr7Ovs6+zr6WhpaGloaWhpaEAAAAGFmjk fO0AABMDagAAAAAWaOR87QAwSkIAVQgBBhZodEUuAAATA2oAAAAAFmh0RS4AMEpCAFUIAQYWaC0t +AAAEwNqAAAAABZoLS34ADBKQgBVCAETA2oAAAAAFmiTbLgAMEpCAFUIAQYWaJNsuAAADxVoZUdZ ABZoZUdZAEgqAQYWaGVHWQAAEwNqAAAAABZoZUdZADBKQgBVCAEGFmjkBpAAAAYWaBo38gAADwNq AAAAABZoGjfyAFUIAQA/B1ABAAhQAQAJUAEAClABAAtQAQAMUAEADVABAA5QAQAPUAEAEFABABFQ AQA2UAEAplABABNRAQBBUQEAZlEBAJBRAQCRUQEAu1EBALxRAQDmUQEA51EBAKFSAQDzUgEAclMB AINTAQApVAEAO1QBAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcA AAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAAD3AAAAAAAA AAAAAAAA8gAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAA APcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAA AAAAAAAAAAAA9wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARDAGdkk2y4AAAEQwBnZGVHWQAAAUMA AAFHAAABSQAAAQAAABs7VAEAp1QBAKxUAQCxVAEAtlQBAO1UAQAyVQEAWlUBAFtVAQBcVQEA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAABOkAAAUpAAAWyQAXCQAZWRL TNY3AAEAAAABQwAACe1UAQDuVAEAMlUBADNVAQBaVQEAW1UBAFxVAQD18efj39sAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYWaEVG awAABhZoGjfyAAAGFmj6GiIAABMDagAAAAAWaPoaIgAwSkIAVQgBBhZo5HztAAATA2oAAAAAFmjk fO0AMEpCAFUIAQAGLAAxkGgBH7DQLyCw4D0hsKAFIrCgBSOQoAUkkKAFJbAAABew0AIYsNACDJDQ AgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAACWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnW AqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXW BQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAJAAFiQBSWYC AAAASyQBTCQBAZYeACF2AAJoASN2AAIRDDpWCwAClh4ACdYE4AHgAQp0AACgBBLWFAAAAP9mZmYA AAAAAAD/ZmZmAAAAFPYCiBMVNgE11gUAAgJyBjPWBgABDwMHADTWBgABDwMeAELWAwACAXDWFAAA AP9mZmYAAAAAAAD/ZmZmAAAAeXRvaB4AkAAWJAFJZgIAAABLJAFMJAEBlh4AIXYAAmgBI3YAAhEM OlYLAAKWHgAJ1gTgAeABCnQAAKAEEtYUAAAA/2ZmZgAAAAAAAP9mZmYAAAAU9gKIExU2ATXWBQAC AnIGM9YGAAEPAwcANNYGAAEPAx4AQtYDAAIBcNYUAAAA/2ZmZgAAAAAAAP9mZmYAAAB5dG9oHgCQ ABYkAUlmAgAAAEskAUwkAQGWHgAhdgACaAEjdgACEQw6VgsAApYeAAnWBOAB4AEKdAAAoAQS1hQA AAD/ZmZmAAAAAAAA/2ZmZgAAABT2AogTFTYBNdYFAAICcgYz1gYAAQ8DBwA01gYAAQ8DHgBC1gMA AgFw1hQAAAD/ZmZmAAAAAAAA/2ZmZgAAAHl0b2geAJAAFiQBSWYCAAAASyQBTCQBAZYeACF2AAJo ASN2AAIRDDpWCwAClh4ACdYE4AHgAQp0AACgBBLWFAAAAP9mZmYAAAAAAAD/ZmZmAAAAFPYCiBMV NgE11gUAAgJyBjPWBgABDwMHADTWBgABDwMeAELWAwACAXDWFAAAAP9mZmYAAAAAAAD/ZmZmAAAA eXRvaB4AigAWJAFJZgIAAABLJAFMJAEBlh4AIXYAAmgBI3YAAhEMOlYLAAKWHgAJ1gTgAeABCnQA AKAEEtYUAAAA/2ZmZgAAAAAAAP9mZmYAAAAU9gKIExU2ATXWBQACAnIGM9YGAAEPAwcANNYGAAEP Ax4AQtYDAAIBcNYUAAAA/2ZmZgAAAAAAAP9mZmYAAACQABYkAUlmAgAAAEskAUwkAQGWHgAhdgAC aAEjdgACEQw6VgsAApYeAAnWBOAB4AEKdAAAoAQS1hQAAAD/ZmZmAAAAAAAA/2ZmZgAAABT2AogT FTYBNdYFAAICcgYz1gYAAQ8DBwA01gYAAQ8DHgBC1gMAAgFw1hQAAAD/ZmZmAAAAAAAA/2ZmZgAA AHl0b2geAIoAFiQBSWYCAAAASyQBTCQBAZYeACF2AAJoASN2AAIRDDpWCwAClh4ACdYE4AHgAQp0 AACgBBLWFAAAAP9mZmYAAAAAAAD/ZmZmAAAAFPYCiBMVNgE11gUAAgJyBjPWBgABDwMHADTWBgAB DwMeAELWAwACAXDWFAAAAP9mZmYAAAAAAAD/ZmZmAAAAXAAWJAEXJAFJZgEAAABlZEtM1jchdgAB aAEjdgABIhg6VgsACnQAAKAEFPYC5AwVNgEs1gMAAQE11gUAAQEAADPWBgABDwMAADTWBgABCgMA AELWAwABAWl0S0zWN5wAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArwCAAAAAEEAAAACgAAMwAL8BIAAACB AaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAAAAAAgJwA AABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAADwAE8FAAAAASAArwCAAAAAIEAAAACgAAMwAL8BIAAACBAaCgoAC/ARAAEAD/AQAA CAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAAAQAAgJYAFiQBFyQBSWYBAAAAZWRL TNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goA AAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMA AQFpdEtM1jdw1goAAAD/mQAAAAAAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAIAAAAAwQAAAAKAAAz AAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQA AAACAACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0 AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPC ATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAARABkAAAAAAAA AA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A BPBQAAAAEgAK8AgAAAAEBAAAAAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi8RIAAACU AwEAAACVAw8AAAC/AwAoACgAABDwBAAAAAMAAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgAB aAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2 A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYK AAAA/5kAAAAAAJwAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArwCAAAAAUEAAAACgAAMwAL8BIAAACBAaCg oAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAABAAAgJYAFiQB FyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/ D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA0 1gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAogAAAEQAZAAAAAAAAAAOAAAAAAAAAAAA AAAAAAEADwDoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwVgAAABIACvAI AAAABgQAAAAKAAAjAAvwDAAAAIEBzMzMAP8BAAAIAFMAIvEeAAAAkwMgAwAAlAMBAAAAlQMPAAAA lgMBAAAAvwMAOAA4AAAQ8AQAAAAFAACAZAAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YA AcwIOlYLAAp0AACgBBT2AQAAFTYBLNYDAAEBNdYFAAEBAAAz1gYAAQ8DDwA01gYAAQoDAABC1gMA AQFpdEtM1jeKVAEAogAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAAEADwDoA+gDAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwVgAAABIACvAIAAAABwQAAAAKAAAjAAvwDAAAAIEB zMzMAP8BAAAIAFMAIvEeAAAAkwMgAwAAlAMBAAAAlQMPAAAAlgMBAAAAvwMAOAA4AAAQ8AQAAAAG AACAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAIAAAACAQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQ AP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAAHAACAlgAWJAEXJAFJZgEA AABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQt ABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgABCgMA AELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDg EAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQAAAAEgAK8AgAAAAJBAAA AAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgA ABDwBAAAAAgAAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnW AqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXW BQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAKIAAABEAGQA AAAAAAAADgAAAAAAAAAAAAAAAAABAA8A6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADwAE8FYAAAASAArwCAAAAAoEAAAACgAAIwAL8AwAAACBAczMzAD/AQAACABTACLxHgAAAJMD IAMAAJQDAQAAAJUDDwAAAJYDAQAAAL8DADgAOAAAEPAEAAAACQAAgGQAFiQBFyQBSWYBAAAAZWRL TNY3AZbi/yF2AAFoASN2AAFjCzpWCwAKdAAAoAQU9gEAABU2ASzWAwABATXWBQABAQAAM9YGAAEP Aw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3ilQBAKIAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAAAB AA8A6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FYAAAASAArwCAAAAAsE AAAACgAAIwAL8AwAAACBAczMzAD/AQAACABTACLxHgAAAJMDIAMAAJQDAQAAAJUDDwAAAJYDAQAA AL8DADgAOAAAEPAEAAAACgAAgJwAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArwCAAAAAwEAAAACgAAMwAL 8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAA CwAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAA oAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz 1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAogAAAEQAZAAAAAAAAAAO AAAAAAAAAAAAAAAAAAEADwDoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATw VgAAABIACvAIAAAADQQAAAAKAAAjAAvwDAAAAIEBzMzMAP8BAAAIAFMAIvEeAAAAkwMgAwAAlAMB AAAAlQMPAAAAlgMBAAAAvwMAOAA4AAAQ8AQAAAAMAACAZAAWJAEXJAFJZgEAAABlZEtM1jcBluL/ IXYAAWgBI3YAAXAPOlYLAAp0AACgBBT2AQAAFTYBLNYDAAEBNdYFAAEBAAAz1gYAAQ8DDwA01gYA AQoDAABC1gMAAQFpdEtM1jeKVAEAogAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAAEADwDoA+gD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwVgAAABIACvAIAAAADgQAAAAKAAAj AAvwDAAAAIEBzMzMAP8BAAAIAFMAIvEeAAAAkwMgAwAAlAMBAAAAlQMPAAAAlgMBAAAAvwMAOAA4 AAAQ8AQAAAANAACAlgAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwSgAAABIACvAIAAAADwQAAAAKAAAjAAvwDAAAAIEB oKCgAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAAOAACAlgAWJAEXJAFJ ZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/ EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgAB CgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACWAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA 4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBKAAAAEgAK8AgAAAAQ BAAAAAoAACMAC/AMAAAAgQGgoKAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDw BAAAAA8AAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqAB CnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXWBQAB A8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAKIAAABEAGQAAAAA AAAADgAAAAAAAAAAAAAAAAABAA8A6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DwAE8FYAAAASAArwCAAAABEEAAAACgAAIwAL8AwAAACBAczMzAD/AQAACABTACLxHgAAAJMDIAMA AJQDAQAAAJUDDwAAAJYDAQAAAL8DADgAOAAAEPAEAAAAEAAAgGQAFiQBFyQBSWYBAAAAZWRLTNY3 AZbi/yF2AAFoASN2AAEECjpWCwAKdAAAoAQU9gEAABU2ASzWAwABATXWBQABAQAAM9YGAAEPAw8A NNYGAAEKAwAAQtYDAAEBaXRLTNY3ilQBAKIAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAAABAA8A 6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FYAAAASAArwCAAAABIEAAAA CgAAIwAL8AwAAACBAczMzAD/AQAACABTACLxHgAAAJMDIAMAAJQDAQAAAJUDDwAAAJYDAQAAAL8D ADgAOAAAEPAEAAAAEQAAgJYAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8EoAAAASAArwCAAAABMEAAAACgAAIwAL8AwA AACBAaCgoAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAAEgAAgJYAFiQB FyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/ D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA0 1gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAlgAAAEQAZAAAAAAAAAAOAAAAAAAAAAAA AAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwSgAAABIACvAI AAAAFAQAAAAKAAAjAAvwDAAAAIEBoKCgAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAo AAAQ8AQAAAATAACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ 1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE1 1gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACWAAAARABk AAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA8ABPBKAAAAEgAK8AgAAAAVBAAAAAoAACMAC/AMAAAAgQGgoKAA/wEAAAgAMwAi8RIAAACU AwEAAACVAw8AAAC/AwAoACgAABDwBAAAABQAAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgAB aAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2 A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYK AAAA/5kAAAAAAKIAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAAABAA8A6APoAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FYAAAASAArwCAAAABYEAAAACgAAIwAL8AwAAACBAczM zAD/AQAACABTACLxHgAAAJMDIAMAAJQDAQAAAJUDDwAAAJYDAQAAAL8DADgAOAAAEPAEAAAAFQAA gGQAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFVBzpWCwAKdAAAoAQU9gEAABU2ASzW AwABATXWBQABAQAAM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3ilQBAKIAAABEAGQAAAAA AAAADgAAAAAAAAAAAAAAAAABAA8A6APoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA DwAE8FYAAAASAArwCAAAABcEAAAACgAAIwAL8AwAAACBAczMzAD/AQAACABTACLxHgAAAJMDIAMA AJQDAQAAAJUDDwAAAJYDAQAAAL8DADgAOAAAEPAEAAAAFgAAgJwAAABEAGQAAAAAAAAADgAAAAAA AAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAAS AArwCAAAABgEAAAACgAAMwAL8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUD DwAAAL8DACgAKAAAEPAEAAAAFwAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFS AjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEe lC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAA AAAAogAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAAEADwDoA+gDAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAPAATwVgAAABIACvAIAAAAGQQAAAAKAAAjAAvwDAAAAIEBzMzMAP8BAAAI AFMAIvEeAAAAkwMgAwAAlAMBAAAAlQMPAAAAlgMBAAAAvwMAOAA4AAAQ8AQAAAAYAACAZAAWJAEX JAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAATgHOlYLAAp0AACgBBT2AQAAFTYBLNYDAAEBNdYF AAEBAAAz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jeKVAEAogAAAEQAZAAAAAAAAAAOAAAA AAAAAAAAAAAAAAEADwDoA+gDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwVgAA ABIACvAIAAAAGgQAAAAKAAAjAAvwDAAAAIEBzMzMAP8BAAAIAFMAIvEeAAAAkwMgAwAAlAMBAAAA lQMPAAAAlgMBAAAAvwMAOAA4AAAQ8AQAAAAZAACAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAA AOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAIAAAA GwQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMA KAAoAAAQ8AQAAAAaAACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU 4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMA AQE11gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAA RABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA8ABPBQAAAAEgAK8AgAAAAcBAAAAAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgA MwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDwBAAAABsAAICWABYkARckAUlmAQAAAGVkS0zW NwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA /5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEB aXRLTNY3cNYKAAAA/5kAAAAAAJwAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArwCAAAAB0EAAAACgAAMwAL 8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAA HAAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAA oAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz 1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAnAAAAEQAZAAAAAAAAAAO AAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATw UAAAABIACvAIAAAAHgQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAAlAMB AAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAAdAACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgB I3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPC ARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAA AP+ZAAAAAACcAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQAAAAEgAK8AgAAAAfBAAAAAoAADMAC/ASAAAAgQGgoKAA vwEQABAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDwBAAAAB4AAICWABYkARck AUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4/w+U +P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8ANNYG AAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAJwAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAA AADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArwCAAA ACAEAAAACgAAMwAL8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8D ACgAKAAAEPAEAAAAHwAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAH lOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYD AAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAnAAA AEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAPAATwUAAAABIACvAIAAAAIQQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAI ADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAAgAACAlgAWJAEXJAFJZgEAAABlZEtM 1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAA AP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwAB AWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQAAAAEgAK8AgAAAAiBAAAAAoAADMA C/ASAAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDwBAAA ACEAAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqABCnQA AKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXWBQABA8IB M9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAJYAAABEAGQAAAAAAAAA DgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE 8EoAAAASAArwCAAAACMEAAAACgAAIwAL8AwAAACBAaCgoAD/AQAACAAzACLxEgAAAJQDAQAAAJUD DwAAAL8DACgAKAAAEPAEAAAAIgAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFS AjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEe lC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAA AAAAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAIAAAAJAQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQ AP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAAjAACAlgAWJAEXJAFJZgEA AABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQt ABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgABCgMA AELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDg EAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQAAAAEgAK8AgAAAAlBAAA AAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgA ABDwBAAAACQAAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnW AqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXW BQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAJwAAABEAGQA AAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAADwAE8FAAAAASAArwCAAAACYEAAAACgAAMwAL8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLx EgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAAJQAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi /yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAA AAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM 1jdw1goAAAD/mQAAAAAAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAIAAAAJwQAAAAKAAAzAAvwEgAA AIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAAmAACA lgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02 IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgAB DwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAARABkAAAAAAAAAA4AAAAA AAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQAAAA EgAK8AgAAAAoBAAAAAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi8RIAAACUAwEAAACV Aw8AAAC/AwAoACgAABDwBAAAACcAAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgAB UgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYB HpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kA AAAAAJwAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArwCAAAACkEAAAACgAAMwAL8BIAAACBAaCgoAC/ARAA EAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAAKAAAgJYAFiQBFyQBSWYB AAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCU LQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoD AABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ 4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAIAAAAKgQA AAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAo AAAQ8AQAAAApAACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ 1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE1 1gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAARABk AAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA8ABPBQAAAAEgAK8AgAAAArBAAAAAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi 8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDwBAAAACoAAICWABYkARckAUlmAQAAAGVkS0zWNwGW 4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kA AAAAABT2A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRL TNY3cNYKAAAA/5kAAAAAAJYAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8EoAAAASAArwCAAAACwEAAAACgAAIwAL8AwA AACBAaCgoAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAAKwAAgJYAFiQB FyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/ D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA0 1gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAA AAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAI AAAALQQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAA vwMAKAAoAAAQ8AQAAAAsAACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYL AAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs 1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACc AAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA8ABPBQAAAAEgAK8AgAAAAuBAAAAAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEA AAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDwBAAAAC0AAICWABYkARckAUlmAQAAAGVk S0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYK AAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYD AAEBaXRLTNY3cNYKAAAA/5kAAAAAAJwAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAAD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArwCAAAAC8EAAAACgAA MwAL8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAE AAAALgAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEK dAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAED wgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAnAAAAEQAZAAAAAAA AAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP AATwUAAAABIACvAIAAAAMAQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAA lAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAAvAACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYA AWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU 9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DW CgAAAP+ZAAAAAACcAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQAAAAEgAK8AgAAAAxBAAAAAoAADMAC/ASAAAAgQGg oKAAvwEQABAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDwBAAAADAAAICWABYk ARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4 /w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8A NNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAJwAAABEAGQAAAAAAAAADgAAAAAAAAAA AAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArw CAAAADIEAAAACgAAMwAL8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAA AL8DACgAKAAAEPAEAAAAMQAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpW CwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0A LNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAA lgAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAPAATwSgAAABIACvAIAAAAMwQAAAAKAAAjAAvwDAAAAIEBoKCgAP8BAAAIADMA IvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAAyAACAlgAWJAEXJAFJZgEAAABlZEtM1jcB luL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+Z AAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0 S0zWN3DWCgAAAP+ZAAAAAACWAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBKAAAAEgAK8AgAAAA0BAAAAAoAACMAC/AM AAAAgQGgoKAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDwBAAAADMAAICWABYk ARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4 /w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8A NNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAJYAAABEAGQAAAAAAAAADgAAAAAAAAAA AAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8EoAAAASAArw CAAAADUEAAAACgAAIwAL8AwAAACBAaCgoAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgA KAAAEPAEAAAANAAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEA CdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEB NdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAnAAAAEQA ZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAPAATwUAAAABIACvAIAAAANgQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAIADMA IvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAA1AACAlgAWJAEXJAFJZgEAAABlZEtM1jcB luL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+Z AAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0 S0zWN3DWCgAAAP+ZAAAAAACcAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQAAAAEgAK8AgAAAA3BAAAAAoAADMAC/AS AAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDwBAAAADYA AICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAE DTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YG AAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAJwAAABEAGQAAAAAAAAADgAA AAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAA AAASAArwCAAAADgEAAAACgAAMwAL8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAA AJUDDwAAAL8DACgAKAAAEPAEAAAANwAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2 AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEV NgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/ mQAAAAAAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAIAAAAOQQAAAAKAAAzAAvwEgAAAIEBoKCgAL8B EAAQAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAA4AACAlgAWJAEXJAFJ ZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/ EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgAB CgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA 4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQAAAAEgAK8AgAAAA6 BAAAAAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAo ACgAABDwBAAAADkAAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5Th AAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwAB ATXWBQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAJwAAABE AGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADwAE8FAAAAASAArwCAAAADsEAAAACgAAMwAL8BIAAACBAaCgoAC/ARAAEAD/AQAACAAz ACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAAOgAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3 AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/ mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFp dEtM1jdw1goAAAD/mQAAAAAAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAIAAAAPAQAAAAKAAAzAAvw EgAAAIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMAKAAoAAAQ8AQAAAA7 AACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU4QAJ1gKgAQp0AACg BA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMAAQE11gUAAQPCATPW BgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAARABkAAAAAAAAAA4A AAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQ AAAAEgAK8AgAAAA9BAAAAAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi8RIAAACUAwEA AACVAw8AAAC/AwAoACgAABDwBAAAADwAAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEj dgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IB FTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA /5kAAAAAAJwAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArwCAAAAD4EAAAACgAAMwAL8BIAAACBAaCgoAC/ ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAAPQAAgJYAFiQBFyQB SWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4 /xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYA AQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAnAAAAEQAZAAAAAAAAAAOAAAAAAAAAAAAAAAA AOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATwUAAAABIACvAIAAAA PwQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAAlAMBAAAAlQMPAAAAvwMA KAAoAAAQ8AQAAAA+AACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgBI3YAAVICOlYLAAeU 4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPCARU2AR6ULQAs1gMA AQE11gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAAAP+ZAAAAAACcAAAA RABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDgEAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA8ABPBQAAAAEgAK8AgAAABABAAAAAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgA MwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgAABDwBAAAAD8AAICWABYkARckAUlmAQAAAGVkS0zW NwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnWAqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA /5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXWBQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEB aXRLTNY3cNYKAAAA/5kAAAAAAJwAAABEAGQAAAAAAAAADgAAAAAAAAAAAAAAAADgEOAQAAADAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE8FAAAAASAArwCAAAAEEEAAAACgAAMwAL 8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQDAQAAAJUDDwAAAL8DACgAKAAAEPAEAAAA QAAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFoASN2AAFSAjpWCwAHlOEACdYCoAEKdAAA oAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYDwgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz 1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goAAAD/mQAAAAAAnAAAAEQAZAAAAAAAAAAO AAAAAAAAAAAAAAAAAOAQ4BAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATw UAAAABIACvAIAAAAQgQAAAAKAAAzAAvwEgAAAIEBoKCgAL8BEAAQAP8BAAAIADMAIvESAAAAlAMB AAAAlQMPAAAAvwMAKAAoAAAQ8AQAAABBAACAlgAWJAEXJAFJZgEAAABlZEtM1jcBluL/IXYAAWgB I3YAAVICOlYLAAeU4QAJ1gKgAQp0AACgBA02IA6U+P8PlPj/EJQtABLWCgAAAP+ZAAAAAAAU9gPC ARU2AR6ULQAs1gMAAQE11gUAAQPCATPWBgABDwMPADTWBgABCgMAAELWAwABAWl0S0zWN3DWCgAA AP+ZAAAAAABqABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgACaAEjdgABjAcjdgECAB06VgsAApYP AAp0AACgBBT2AlYTFTYBLNYDAQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM 1jdqABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgACaAEjdgAB+AYjdgEClB06VgsAApYPAAp0AACg BBT2AlYTFTYBLNYDAQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYk ARckAUlmAQAAAGVkS0zWNwGW4v8hdgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYT FTYBLNYDAQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYkARckAUlm AQAAAGVkS0zWNwGW4v8hdgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYTFTYBLNYD AQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYkARckAUlmAQAAAGVk S0zWNwGW4v8hdgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYTFTYBLNYDAQIBNdYF AAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYkARckAUlmAQAAAGVkS0zWNwGW 4v8hdgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYTFTYBLNYDAQIBNdYFAAIBAAAz 1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgAC aAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYTFTYBLNYDAQIBNdYFAAIBAAAz1gYAAQ8D DwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgACaAEjdgAB QQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYTFTYBLNYDAQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYA AQ8DDwBC1gMAAgFpdEtM1jdqABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgACaAEjdgABQQcjdgEC Sx06VgsAApYPAAp0AACgBBT2AlYTFTYBLNYDAQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC 1gMAAgFpdEtM1jdqABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgACaAEjdgABQQcjdgECSx06VgsA ApYPAAp0AACgBBT2AlYTFTYBLNYDAQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFp dEtM1jdqABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0 AACgBBT2AlYTFTYBLNYDAQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdq ABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2 AlYTFTYBLNYDAQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYkARck AUlmAQAAAGVkS0zWNwGW4v8hdgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYTFTYB LNYDAQIBNdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYkARckAUlmAQAA AGVkS0zWNwGW4v8hdgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYTFTYBLNYDAQIB NdYFAAIBAAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYkARckAUlmAQAAAGVkS0zW NwGW4v8hdgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYTFTYBLNYDAQIBNdYFAAIB AAAz1gYAAQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jdqABYkARckAUlmAQAAAGVkS0zWNwGW4v8h dgACaAEjdgABQQcjdgECSx06VgsAApYPAAp0AACgBBT2AlYTFTYBLNYDAQIBNdYFAAIBAAAz1gYA AQ8DDwA01gYAAQ8DDwBC1gMAAgFpdEtM1jecAAAARABkAAAAAAAAAA4AAAAAAAAAAAAAAAAA4BDg EAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBQAAAAEgAK8AgAAABDBAAA AAoAADMAC/ASAAAAgQGgoKAAvwEQABAA/wEAAAgAMwAi8RIAAACUAwEAAACVAw8AAAC/AwAoACgA ABDwBAAAAEIAAICWABYkARckAUlmAQAAAGVkS0zWNwGW4v8hdgABaAEjdgABUgI6VgsAB5ThAAnW AqABCnQAAKAEDTYgDpT4/w+U+P8QlC0AEtYKAAAA/5kAAAAAABT2A8IBFTYBHpQtACzWAwABATXW BQABA8IBM9YGAAEPAw8ANNYGAAEKAwAAQtYDAAEBaXRLTNY3cNYKAAAA/5kAAAAAAGoAFiQBFyQB SWYBAAAAZWRLTNY3AZbi/yF2AAJoASN2AAHsByN2AQKgHDpWCwAClg8ACnQAAKAEFPYCVhMVNgEs 1gMBAgE11gUAAgEAADPWBgABDwMPADTWBgABDwMPAELWAwACAWl0S0zWN5wAAABEAGQAAAAAAAAA DgAAAAAAAAAAAAAAAADgEOAQAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwAE 8FAAAAASAArwCAAAAEQEAAAACgAAMwAL8BIAAACBAaCgoAC/ARAAEAD/AQAACAAzACLxEgAAAJQD AQAAAJUDDwAAAL8DACgAKAAAEPAEAAAAQwAAgJYAFiQBFyQBSWYBAAAAZWRLTNY3AZbi/yF2AAFo ASN2AAFSAjpWCwAHlOEACdYCoAEKdAAAoAQNNiAOlPj/D5T4/xCULQAS1goAAAD/mQAAAAAAFPYD wgEVNgEelC0ALNYDAAEBNdYFAAEDwgEz1gYAAQ8DDwA01gYAAQoDAABC1gMAAQFpdEtM1jdw1goA AAD/mQAAAAAAYgAWJAEXJAFJZgEAAABlZEtM1jchdgACaAEjdgABXQsjdgEC1Rg6VgsACnQAAKAE FPYCVhMVNgEs1gMAAgE11gUAAgEAADPWBgABDwMAADTWBgABCgMAAELWAwACAWl0S0zWN2IAFiQB FyQBSWYBAAAAZWRLTNY3IXYAAmgBI3YAAV0LI3YBAtUYOlYLAAp0AACgBBT2AlYTFTYBLNYDAAIB NdYFAAIBAAAz1gYAAQ8DAAA01gYAAQoDAABC1gMAAgFpdEtM1jdiABYkARckAUlmAQAAAGVkS0zW NyF2AAJoASN2AAFdCyN2AQLVGDpWCwAKdAAAoAQU9gJWExU2ASzWAwACATXWBQACAQAAM9YGAAEP AwAANNYGAAEKAwAAQtYDAAIBaXRLTNY3YgAWJAEXJAFJZgEAAABlZEtM1jchdgACaAEjdgABXQsj dgEC1Rg6VgsACnQAAKAEFPYCVhMVNgEs1gMAAgE11gUAAgEAADPWBgABDwMAADTWBgABCgMAAELW AwACAWl0S0zWN2IAFiQBFyQBSWYBAAAAZWRLTNY3IXYAAmgBI3YAAV0LI3YBAtUYOlYLAAp0AACg BBT2AlYTFTYBLNYDAAIBNdYFAAIBAAAz1gYAAQ8DAAA01gYAAQoDAABC1gMAAgFpdEtM1jdiABYk ARckAUlmAQAAAGVkS0zWNyF2AAJoASN2AAFdCyN2AQLVGDpWCwAKdAAAoAQU9gJWExU2ASzWAwAC ATXWBQACAQAAM9YGAAEPAwAANNYGAAEKAwAAQtYDAAIBaXRLTNY3YgAWJAEXJAFJZgEAAABlZEtM 1jchdgACaAEjdgABXQsjdgEC1Rg6VgsACnQAAKAEFPYCVhMVNgEs1gMAAgE11gUAAgEAADPWBgAB DwMAADTWBgABCgMAAELWAwACAWl0S0zWN2IAFiQBFyQBSWYBAAAAZWRLTNY3IXYAAmgBI3YAAV0L I3YBAtUYOlYLAAp0AACgBBT2AlYTFTYBLNYDAAIBNdYFAAIBAAAz1gYAAQ8DAAA01gYAAQoDAABC 1gMAAgFpdEtM1jdiABYkARckAUlmAQAAAGVkS0zWNyF2AAJoASN2AAFdCyN2AQLVGDpWCwAKdAAA oAQU9gJWExU2ASzWAwACATXWBQACAQAAM9YGAAEPAwAANNYGAAEKAwAAQtYDAAIBaXRLTNY3YgAW JAEXJAFJZgEAAABlZEtM1jchdgACaAEjdgABXQsjdgEC1Rg6VgsACnQAAKAEFPYCVhMVNgEs1gMA AgE11gUAAgEAADPWBgABDwMAADTWBgABCgMAAELWAwACAWl0S0zWN2IAFiQBFyQBSWYBAAAAZWRL TNY3IXYAAmgBI3YAAV0LI3YBAtUYOlYLAAp0AACgBBT2AlYTFTYBLNYDAAIBNdYFAAIBAAAz1gYA AQ8DAAA01gYAAQoDAABC1gMAAgFpdEtM1jdiABYkARckAUlmAQAAAGVkS0zWNyF2AAJoASN2AAFd CyN2AQLVGDpWCwAKdAAAoAQU9gJWExU2ASzWAwACATXWBQACAQAAM9YGAAEPAwAANNYGAAEKAwAA QtYDAAIBaXRLTNY3YgAWJAEXJAFJZgEAAABlZEtM1jchdgACaAEjdgABXQsjdgEC1Rg6VgsACnQA AKAEFPYCVhMVNgEs1gMAAgE11gUAAgEAADPWBgABDwMAADTWBgABCgMAAELWAwACAWl0S0zWN2IA FiQBFyQBSWYBAAAAZWRLTNY3IXYAAmgBI3YAAV0LI3YBAtUYOlYLAAp0AACgBBT2AlYTFTYBLNYD AAIBNdYFAAIBAAAz1gYAAQ8DAAA01gYAAQoDAABC1gMAAgFpdEtM1jcAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABeBEsAEgABAAsBDwAHAAAAAAAAAAAABAAIAAAAmAAAAJgAAACY AAAAmAAAAJgAAACYAAAAngAAAJ4AAACeAAAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAAdgIAAHYCAAB2AgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAAPgIAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAAKgAAAA2BgAANgYAABYAAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAALgA AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAABoAQAASAEA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAA NgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2 BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYG AAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAANgYA ADYGAAA2BgAANgYAADYGAAA2BgAANgYAADYGAAA2BgAAsAMAADYGAAAyBgAAGAAAAMADAADQAwAA 4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQBAAAwAMAANADAADg AwAA8AMAAAAEAAAQBAAAMgYAACgCAADYAQAA6AEAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAE AACQBAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQA AJAEAADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAA kAQAAMADAADQAwAA4AMAAPADAAAABAAAEAQAACAEAAAwBAAAQAQAAFAEAABgBAAAcAQAAIAEAACQ BAAAwAMAANADAADgAwAA8AMAAAAEAAAQBAAAIAQAADAEAABABAAAUAQAAGAEAABwBAAAgAQAAJAE AADAAwAA0AMAAOADAADwAwAAAAQAABAEAAAgBAAAMAQAAEAEAABQBAAAYAQAAHAEAACABAAAkAQA ADgBAABYAQAA+AEAAAgCAAAYAgAAVgIAAH4CAAAUAAAAX0gBBG1ICQRuSAkEc0gJBHRICQQAAAAA TgAAYPH/AgBOAAwQAAAAAAAAAAAGAE4AbwByAG0AYQBsAAAAEAAAABOkZAAUpGQAWyQBXCQBGABD ShgAX0gBBGFKGABtSAkEc0gJBHRICQRcAAFAAQASAFwADBAUAAAAAACQAAkASABlAGEAZABpAG4A ZwAgADEAAAAIAAEAQCYAYSQCJwA1CIFCKg1DSjAAS0gkAE9KBABRSgQAXAiBXkoEAGFKMABwaJkA AAAATAACQAEAIgBMAAwQFQAAAAAAkAAJAEgAZQBhAGQAaQBuAGcAIAAyAAAABQACAEAmAQAaADUI gUNKJABPSgQAUUoEAFwIgV5KBABhSiQAVgADQAEAMgBWAAwQFgAAAAAAkAAJAEgAZQBhAGQAaQBu AGcAIAAzAAAABQADAEAmAgAjADUIgUIqAUNKGwBPSgQAUUoEAFwIgV5KBABhShsAcGgzMzMAAEQA BEABAEIARAAMEBcAAAAAAJAACQBIAGUAYQBkAGkAbgBnACAANAAAAAUABABAJgMAEgA1CIFPSgQA UUoEAFwIgV5KBABMAAVAAQBSAEwADBAYAAAAAACQAAkASABlAGEAZABpAG4AZwAgADUAAAAFAAUA QCYEABoANQiBQ0oUAE9KBABRSgQAXAiBXkoEAGFKFABMAAZAAQBiAEwADBAZAAAAAACQAAkASABl AGEAZABpAG4AZwAgADYAAAAFAAYAQCYFABoANQiBQ0oPAE9KBABRSgQAXAiBXkoEAGFKDwAAAAAA AABEAEFg8v+hAEQADA0AAAAAAAAQABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABo ACAARgBvAG4AdAAAAAAAUgBpQPP/swBSAAwNAAAAAAAAMAYMAFQAYQBiAGwAZQAgAE4AbwByAG0A YQBsAAAAHAAX9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABrIPT/wQAoAAANAAAA AAAAMAYHAE4AbwAgAEwAaQBzAHQAAAACAAwAAAAAAEoAVWDy//EASgAMCQAAAAAAADAGCQBIAHkA cABlAHIAbABpAG4AawAAAB8ANQiBPioBQioNXAiBcGiZAAAAccoKAAAA/wAAAP8AAABaAFZg8v8B AVoADAkAAAAAAAAwBhEARgBvAGwAbABvAHcAZQBkAEgAeQBwAGUAcgBsAGkAbgBrAAAAHwA1CIE+ KgFCKg1cCIFwaGYzMwBxygoAAAD/AAAA/wAAADYAYWDy/xEBNgAMCQAAAAAAADAGCQBIAFQATQBM ACAAQwBpAHQAZQAAAAwANQiANgiAXAiAXQiAQgBjYPL/IQFCAAwJAAAAAAAAMAYPAEgAVABNAEwA IABEAGUAZgBpAG4AaQB0AGkAbwBuAAAADAA1CIE2CIBcCIFdCIAuAFhg8v8xAS4ADBAAAAAAAABA AQgARQBtAHAAaABhAHMAaQBzAAAABgA2CIFdCIFcAP5v8v9BAVwADAABAAAAAACQAA4ASABlAGEA ZABpAG4AZwAgADEAIABDAGgAYQByAAAAJwA1CIFCKgBDShwAT0oGAFBKAABRSgYAXAiBXkoAAGFK HABwaDZfkQAAXAD+b/L/UQFcAAwBAgAAAAAAkAAOAEgAZQBhAGQAaQBuAGcAIAAyACAAQwBoAGEA cgAAACcANQiBQioAQ0oaAE9KBgBQSgAAUUoGAFwIgV5KAABhShoAcGhPgb0AAFwA/m/y/2EBXAAM AQMAAAAAAJAADgBIAGUAYQBkAGkAbgBnACAAMwAgAEMAaABhAHIAAAAnADUIgUIqAENKGABPSgYA UEoAAFFKBgBcCIFeSgAAYUoYAHBoT4G9AABiAP5v8v9xAWIADAEEAAAAAACQAA4ASABlAGEAZABp AG4AZwAgADQAIABDAGgAYQByAAAALQA1CIE2CIFCKgBDShgAT0oGAFBKAABRSgYAXAiBXQiBXkoA AGFKGABwaE+BvQAAVgD+b/L/gQFWAAwBBQAAAAAAkAAOAEgAZQBhAGQAaQBuAGcAIAA1ACAAQwBo AGEAcgAAACEAQioAQ0oYAE9KBgBQSgAAUUoGAF5KAABhShgAcGgkP2AAAFwA/m/y/5EBXAAMAQYA AAAAAJAADgBIAGUAYQBkAGkAbgBnACAANgAgAEMAaABhAHIAAAAnADYIgUIqAENKGABPSgYAUEoA AFFKBgBdCIFeSgAAYUoYAHBoJD9gAACkAGVAAQCiAaQADAkbAAAAAAAwBhEASABUAE0ATAAgAFAA cgBlAGYAbwByAG0AYQB0AHQAZQBkAAAAUgAaABOkAAAUpAAAFcYyABCUAygHvApQDuQReBUMGaAc NCDII1wn8CqELhgyrDVAOQAAAAAAAAAAAAAAAAAAAABNxgoAAAD/zMzMAAAAWyQAXCQAFQBCKgFP SgcAUUoHAF5KBwBwaAAAAAAAUAD+b/L/sQFQAAwBGgAAAAAAMAYWAEgAVABNAEwAIABQAHIAZQBm AG8AcgBtAGEAdAB0AGUAZAAgAEMAaABhAHIAAAAMAE9KCABQSgAAUUoIACoAV2Dy/8EBKgAMEAAA AAAAAGABBgBTAHQAcgBvAG4AZwAAAAYANQiBXAiBWgBnYPL/0QFaAAwJAAAAAAAAMAYPAEgAVABN AEwAIABUAHkAcABlAHcAcgBpAHQAZQByAAAAJABCKgpDShgAT0oHAFBKAABRSgcAXkoHAGFKGABv KABwaAAzZgA8AF5AAQDiATwADAkAAAAAAAAwBgwATgBvAHIAbQBhAGwAIAAoAFcAZQBiACkAAAAK AB4AXYTgAV6E4AEAAD4A/k8BAPIBPgAMAAAAAAAAAAAACQBjAG8AcAB5AHIAaQBnAGgAdAAAAAoA HwBdhOABXoTgAQgAQ0oUAGFKFAAwAP5PAQACAjAADAAAAEVGawAAAAMAdABvAGMAAAAKACAAXYTg AV6E0AIGADUIgVwIgSoA/g8BABICKgAMAAAAAAAAAAAAAwBrAGUAeQAAAAoAIQBdhOABXoTgAQAA KAD+DwEAIgIoAAwAAAAAAAAAAAACAGkAZAAAAAoAIgBdhOABXoTgAQAAKgD+DwEAMgIqAAwAAAAA AAAAAAADAHMAdAByAAAACgAjAF2E4AFehOABAAAqAP4PAQBCAioADAAAAAAAAAAAAAMAdgBhAGwA AAAKACQAXYTgAV6E4AEAACoA/g8BAFICKgAMAAAAAAAAAAAAAwByAGUAcAAAAAoAJQBdhOABXoTg AQAAKgD+DwEAYgIqAAwAAAAAAAAAAAADAG8AdABoAAAACgAmAF2E4AFehOABAAAqAP4PAQByAioA DAAAAAAAAAAAAAMAZQByAHIAAAAKACcAXYTgAV6E4AEAAB4A/g+iAIECHgAMAAAAAAAAAAAAAwBy AGYAYwAAAAAAJgD+D6IAkQImAAwAAAAAAAAAAAAHAGgAbwB0AHQAZQB4AHQAAAAAACAA/g+iAKEC IAAMAAAAAAAAAAAABABpAG4AZgBvAAAAAAA+AP5v8v+xAj4ADAAAAEVGawAAAAQAcgBmAGMAMQAA AB4ANQiBQioPT0oEAFFKBABcCIFeSgQAbygAcGhmZmYARgD+b/L/wQJGAAwAAABFRmsAAAAIAGgA bwB0AHQAZQB4AHQAMQAAAB4ANQiAQioIT0oEAFFKBABcCIBeSgQAbygAcGj///8AVAD+b/L/0QJU AAwAAAAAAAAAAAAFAGkAbgBmAG8AMQAAADIAEQiAGAiAPAiAQioNQ0oUAGFKFABwaJkAAABxygoA AAD/7u7uAAAAcsoIMzMzAAYBQgA8AP5PAQDiAjwADAAAAAAAAAAAAAQAawBlAHkAMQAAAAoALgBd hOABXoTgAQ8ANQiBQioCXAiBcGgzM8wAADQA/k8BAPICNAAMAAAAAAAAAAAAAwBpAGQAMQAAAAoA LwBdhOABXoTgAQkAQioNcGiZAAAAAEQA/k8BAAIDRAAMAAAAAAAAAAAABABzAHQAcgAxAAAAFwAw AE3GCgAAAP/M//8AAABdhOABXoTgAQAJAEIqAXBoAAAAAAA2AP5PAQASAzYADAAAAAAAAAAAAAQA dgBhAGwAMQAAAAoAMQBdhOABXoTgAQkAQioKcGgAZmYAADYA/k8BACIDNgAMAAAAAAAAAAAABABy AGUAcAAxAAAACgAyAF2E4AFehOABCQBCKgxwaJkAmQAARAD+TwEAMgNEAAwAAAAAAAAAAAAEAG8A dABoADEAAAAXADMATcYKAAAA///M/wAAAF2E4AFehOABAAkAQioBcGgAAAAAADoA/g8BAEIDOgAM AAAAAAAAAAAABABlAHIAcgAxAAAAFwA0AE3GCgAAAP//zMwAAABdhOABXoTgAQAAAD4A/m/y/1ED PgAMAAAARUZrAAAABAByAGYAYwAyAAAAHgA1CIFCKg9PSgQAUUoEAFwIgV5KBABvKABwaGZmZgBG AP5v8v9hA0YADAAAAEVGawAAAAgAaABvAHQAdABlAHgAdAAyAAAAHgA1CIBCKghPSgQAUUoEAFwI gF5KBABvKABwaP///wBUAP5v8v9xA1QADAAAAAAAAAAAAAUAaQBuAGYAbwAyAAAAMgARCIAYCIA8 CIBCKg1DShQAYUoUAHBomQAAAHHKCgAAAP/u7u4AAAByyggzMzMABgFCADwA/k8BAIIDPAAMAAAA AAAAAAAABABrAGUAeQAyAAAACgA4AF2E4AFehOABDwA1CIFCKgJcCIFwaDMzzAAANAD+TwEAkgM0 AAwAAAAAAAAAAAADAGkAZAAyAAAACgA5AF2E4AFehOABCQBCKg1waJkAAAAARAD+TwEAogNEAAwA AAAAAAAAAAAEAHMAdAByADIAAAAXADoATcYKAAAA/8z//wAAAF2E4AFehOABAAkAQioBcGgAAAAA ADYA/k8BALIDNgAMAAAAAAAAAAAABAB2AGEAbAAyAAAACgA7AF2E4AFehOABCQBCKgpwaABmZgAA NgD+TwEAwgM2AAwAAAAAAAAAAAAEAHIAZQBwADIAAAAKADwAXYTgAV6E4AEJAEIqDHBomQCZAABE AP5PAQDSA0QADAAAAAAAAAAAAAQAbwB0AGgAMgAAABcAPQBNxgoAAAD//8z/AAAAXYTgAV6E4AEA CQBCKgFwaAAAAAAAOgD+DwEA4gM6AAwAAAAAAAAAAAAEAGUAcgByADIAAAAXAD4ATcYKAAAA///M zAAAAF2E4AFehOABAAAAUACZQAEA8gNQAAwJQABFRmsAMAYMAEIAYQBsAGwAbwBvAG4AIABUAGUA eAB0AAAACgA/ABOkAAAUpAAAFABDShAAT0oJAFFKCQBeSgkAYUoQAFIA/m/y/wEEUgAMAT8ARUZr ADAGEQBCAGEAbABsAG8AbwBuACAAVABlAHgAdAAgAEMAaABhAHIAAAAYAENKEABPSgkAUEoAAFFK CQBeSgkAYUoQAEQAsmDx/xIERAAOAQAARUZrADAGCABSAGUAdgBpAHMAaQBvAG4AAAACAEEAGABD ShgAX0gBBGFKGABtSAkEc0gJBHRICQRCACdg8v8hBEIADAkAAGVHWQAwBhEAQwBvAG0AbQBlAG4A dAAgAFIAZQBmAGUAcgBlAG4AYwBlAAAACABDShAAYUoQADwAHkABADIEPAAMCUQAZUdZADAGDABD AG8AbQBtAGUAbgB0ACAAVABlAHgAdAAAAAIAQwAIAENKFABhShQAPgD+b/L/QQQ+AAwBQwBlR1kA MAYRAEMAbwBtAG0AZQBuAHQAIABUAGUAeAB0ACAAQwBoAGEAcgAAAAQAUEoAAEAAakAxBDIEQAAM CUYAZUdZADAGDwBDAG8AbQBtAGUAbgB0ACAAUwB1AGIAagBlAGMAdAAAAAIARQAGADUIgVwIgUoA /m/y/2EESgAMAUUAZUdZADAGFABDAG8AbQBtAGUAbgB0ACAAUwB1AGIAagBlAGMAdAAgAEMAaABh AHIAAAAKADUIgVBKAABcCIE0AB9AAQByBDQADAxIAOQGkAAwBgYASABlAGEAZABlAHIAAAANAEcA DcYIAAJIEpAkAQIAAAA2AP4v8v+BBDYADABHAOQGkAAwBgsASABlAGEAZABlAHIAIABDAGgAYQBy AAAACABDShgAYUoYADQAIEABAJIENAAMDEoA5AaQADAGBgBGAG8AbwB0AGUAcgAAAA0ASQANxggA AkgSkCQBAgAAADYA/i/y/6EENgAMAEkA5AaQADAGCwBGAG8AbwB0AGUAcgAgAEMAaABhAHIAAAAI AENKGABhShgAUEsDBBQABgAIAAAAIQDp3g+//wAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnht bKyRy07DMBBF90j8g+UtSpyyQAgl6YLHjseifMDImSQWydiyp1X790zSVEKoIBZsLNkz954743K9 Hwe1w5icp0qv8kIrJOsbR12l3zdP2a1WiYEaGDxhpQ+Y9Lq+vCg3h4BJiZpSpXvmcGdMsj2OkHIf kKTS+jgCyzV2JoD9gA7NdVHcGOuJkTjjyUPX5QO2sB1YPe7l+Zgk4pC0uj82TqxKQwiDs8CS1Oyo +UbJFkIuyrkn9S6kK4mhzVnCVPkZsOheZTXRNajeIPILjBLDsAyJX89nIBkt5r87nons29ZZbLzd jrKOfDZezE7B/xRg9T/oE9PMf1t/AgAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAA AF9yZWxzLy5yZWxzhI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiE pO/3qT3+rov54ZTnIBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCV Eg+I2U+8Uq5CZNHJENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVF BG43lExp5GKhqC/jU72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoA AAAcAAAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuu u/YAQ5waQceg0p/b1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSN E99JyHNRfSPVkIWttd0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQA BgAIAAAAIQAw3UMpqAYAAKQbAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3 IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rjgAHDumGHFdhth2FbgRbYpfs02TpsHdCv sEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/aXv1yzUMk8XlAk7Dt3R72L615SCqcBJjx hLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NYXuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZb XYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkTZ4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7y EMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4inBUMK33G60rWwV9A2BqHtfr9bq9ekHP ALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMytTqfTbGWyWKIGZB8bc/i12mpjc9nBG5DF N+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrvZ9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjz RC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGlGTvky7khzQtJX9BUtb0PUwwZMaP36vn3 r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cfoz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJn Js6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMYFDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9 nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG 7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz/ICQCu3uUurYdZf6gks+VuguRR1MK00y pCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswqhB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjB VPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGLFIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/ kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0CxA9MxEVvrxOuBO/gykbY2JKDRR1p1bH NPm7ws0oVG7L4eIKN5TKF18/rpD7bS3Zm7B7VeXM9olCvQh3sjx3uQjo21+dt/Ak2SOQEPNb1Lvi /K44e//54rwony++JM+qMBRo3YvYRtu03fHCrntMGRuoKSM3pGm8Jew9QR8G9Tpz4iTFKSyN4FFn MjBwcKHAZg0SXH1EVTSIcApNe93TREKZkQ4lSrmEw6IZrqSt8dD4K3vUbOpDiK0cEqtdHtjhFT2c nzUKMkaq0Bxoc0YrmsBZma1cyYiCbq/DrK6FOjO3uhHNFEWHW6GyNrE5lIPJC9VgsLAmNDUIWiGw 8iqc+TVrOOxgRgJtd+uj3C3GCxfpIhnhgGQ+0nrP+6hunJTHypwiWg8bDPrgeIrVStxamuwbcDuL k8rsGgvY5d57Ey/lETzzElA7mY4sKScnS9BR22s1l5se8nHa9sZwTobHOAWvS91HYhbCZZOvhA37 U5PZZPnMm61cMTcJ6nD1Ye0+p7BTB1Ih1RaWkQ0NM5WFAEs0Jyv/chPMelEKVFSjs0mxsgbB8K9J AXZ0XUvGY+KrsrNLI9p29jUrpXyiiBhEwREasYnYx+B+HaqgT0AlXHeYiqBf4G5OW9tMucU5S7ry jZjB2XHM0ghn5VanaJ7JFm4KUiGDeSuJB7pVym6UO78qJuUvSJVyGP/PVNH7Cdw+rATaAz5cDQuM dKa0PS5UxKEKpRH1+wIaB1M7IFrgfhemIajggtr8F+RQ/7c5Z2mYtIZDpNqnIRIU9iMVCUL2oCyZ 6DuFWD3buyxJlhEyEVUSV6ZW7BE5JGyoa+Cq3ts9FEGom2qSlQGDOxl/7nuWQaNQNznlfHMqWbH3 2hz4pzsfm8yglFuHTUOT278QsWgPZruqXW+W53tvWRE9MWuzGnlWALPSVtDK0v41RTjnVmsr1pzG y81cOPDivMYwWDREKdwhIf0H9j8qfGa/dugNdcj3obYi+HihiUHYQFRfso0H0gXSDo6gcbKDNpg0 KWvarHXSVss36wvudAu+J4ytJTuLv89p7KI5c9k5uXiRxs4s7Njaji00NXj2ZIrC0Dg/yBjHmM9k 5S9ZfHQPHL0F3wwmTEkTTPCdSmDooQcmDyD5LUezdOMvAAAA//8DAFBLAwQUAAYACAAAACEADdGQ n7YAAAAbAQAAJwAAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFuYWdlci54bWwucmVsc4SPTQrC MBSE94J3CG9v07oQkSbdiNCt1AOE5DUNNj8kUeztDa4sCC6HYb6ZabuXnckTYzLeMWiqGgg66ZVx msFtuOyOQFIWTonZO2SwYIKObzftFWeRSyhNJiRSKC4xmHIOJ0qTnNCKVPmArjijj1bkIqOmQci7 0Ej3dX2g8ZsBfMUkvWIQe9UAGZZQmv+z/TgaiWcvHxZd/lFBc9mFBSiixszgI5uqTATKW7q6xN8A AAD//wMAUEsBAi0AFAAGAAgAAAAhAOneD7//AAAAHAIAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250 ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEApdan58AAAAA2AQAACwAAAAAAAAAAAAAAAAAw AQAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEAa3mWFoMAAACKAAAAHAAAAAAAAAAAAAAAAAAZ AgAAdGhlbWUvdGhlbWUvdGhlbWVNYW5hZ2VyLnhtbFBLAQItABQABgAIAAAAIQAw3UMpqAYAAKQb AAAWAAAAAAAAAAAAAAAAANYCAAB0aGVtZS90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAh AA3RkJ+2AAAAGwEAACcAAAAAAAAAAAAAAAAAsgkAAHRoZW1lL3RoZW1lL19yZWxzL3RoZW1lTWFu YWdlci54bWwucmVsc1BLBQYAAAAABQAFAF0BAACtCgAAAAA8P3htbCB2ZXJzaW9uPSIxLjAiIGVu Y29kaW5nPSJVVEYtOCIgc3RhbmRhbG9uZT0ieWVzIj8+DQo8YTpjbHJNYXAgeG1sbnM6YT0iaHR0 cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL2RyYXdpbmdtbC8yMDA2L21haW4iIGJnMT0i bHQxIiB0eDE9ImRrMSIgYmcyPSJsdDIiIHR4Mj0iZGsyIiBhY2NlbnQxPSJhY2NlbnQxIiBhY2Nl bnQyPSJhY2NlbnQyIiBhY2NlbnQzPSJhY2NlbnQzIiBhY2NlbnQ0PSJhY2NlbnQ0IiBhY2NlbnQ1 PSJhY2NlbnQ1IiBhY2NlbnQ2PSJhY2NlbnQ2IiBobGluaz0iaGxpbmsiIGZvbEhsaW5rPSJmb2xI bGluayIvPgYAQQB1AHQAaABvAHIAshsAAP0bAAAEHwAAri0AAOctAABWNQAAMDYAAIY2AADUQgAA b0oAANFRAAALUgAAvlgAAKxiAADVcAAAmXIAABZzAADBeQAAIHoAACuEAACiFQEAXE0BAAEAQQBK AE4AAAAAAAAAAAAAAAAAAAAAAAAAIbbWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAIrbWEAEA QQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAI7bWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAJLbW EAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAJbbWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAA JrbWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAJ7bWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAA AAAAKLbWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAKbbWEAEAQQBKAE4AAAAAAAAAAAAAAAAA AAAAAAAAKrbWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAK7bWEAEAQQBKAE4AAAAAAAAAAAAA AAAAAAAAAAAALLbWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAALbbWEAEAQQBKAE4AAAAAAAAA AAAAAAAAAAAAAAAALrbWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAL7bWEAEAQQBKAE4AAAAA AAAAAAAAAAAAAAAAAAAAMLbWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAMbbWEAEAQQBKAE4A AAAAAAAAAAAAAAAAAAAAAAAAMrbWEAEAQQBKAE4AAAAAAAAAAAAAAAAAAAAAAAAAM7bWEAEAQQBK AE4AAAAAAAAAAAAAAAAAAAAAAAAANLbWEAEAQQBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAArnWEAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAAAAlQAAAAIBAAAwAQAAVQEA AIABAACrAQAA1gEAAJACAADiAgAAYQMAAHIDAAAYBAAAKgQAAJYEAACbBAAAoAQAAKUEAADcBAAA IQUAAEkFAABMBQAAAAAAAFxNAQANAAAEAwAKAP////8AAAAAAwAAAAYAAAAGAAAACQAAAAwAAAAM AAAADgAAABAAAAASAAAAFAAAABYAAAAYAAAAGwAAAAAIAAC1CAAA5A4AADoQAAAZEgAA9RMAAO0V AAD0FwAAWxoAACYcAACaIQAAOSgAAEMqAAC6NAAAoTYAAOk7AAB0PwAApkAAAPxEAAChSgAA3U0A AA1QAADDUQAATlYAAPhbAABwXQAAhF8AAFlgAADMZQAAQWoAACxwAADQdgAA1XgAADaBAACMhQAA NYkAACqNAADykAAAcZkAAEmfAABopgAArK0AAEGzAAASuwAAXb0AAEXAAABvwwAARskAADnNAAAL zgAAd9IAAB3WAADu1wAAedkAAGTcAAAp4QAAzuMAAJ3rAACa7gAAZPEAALn0AABh9wAAwfgAAHv/ AADqAAEAbwYBAPcGAQBLCgEAQQsBAN4MAQBEDgEAwQ4BAL0UAQAqGAEAGBoBABQdAQD/HgEA1B8B AH4pAQAfMAEAVDUBAN41AQCwOQEA1DsBAEc+AQDxQAEA5UMBAH9GAQCYSQEAoUsBAEVMAQC1TQEA ZU4BAEpPAQD4TwEA7VQBAFxVAQCrAAAArwAAALYAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9 AAAAvwAAAMEAAADDAAAAxgAAAMcAAADKAAAAzAAAAM8AAADRAAAA0wAAANUAAADXAAAA2QAAANwA AADeAAAA4QAAAOMAAADlAAAA5wAAAOkAAADsAAAA7gAAAPEAAADzAAAA9QAAAPYAAAD5AAAA+wAA AP4AAAAAAQAAAgEAAAQBAAAGAQAACAEAAAoBAAAMAQAADwEAABEBAAATAQAAFQEAABgBAAAbAQAA HQEAAB8BAAAhAQAAJAEAACcBAAApAQAAKwEAAC4BAAAwAQAAMgEAADQBAAA2AQAAOAEAADsBAAA9 AQAAPwEAAEEBAABDAQAARQEAAEgBAABKAQAATAEAAE4BAABRAQAAUgEAAFUBAABYAQAAWgEAAF0B AABfAQAAYQEAAGIBAABkAQAAZQEAAGgBAABqAQAAbQEAAG8BAABxAQAAcwEAAHYBAAB6AQAAfgEA AIEBAAAACAAATAgAAGMIAADBCAAA7AgAAAwJAAAZCQAALQkAAHIJAABHHAAAHCgAAEIqAADGKwAA CDQAABE4AADDOwAAMj0AAJA/AACLQAAA1EIAADdFAACLSgAAnU4AABRQAADJUQAAIlUAAJ9YAAD5 WwAAb10AAIRfAABHYAAAKGMAAM5lAAAqagAAxW4AAEZzAADQdgAAhHgAABaBAABwhQAAGokAAFuL AABgjQAA85AAAISVAAC0mQAAlaAAAP2nAACvrQAApLUAAC67AAAAvgAAR8AAANnBAAB2wwAAtckA ADrNAAAMzgAA/c4AAGHSAACc0wAAPNYAAA3YAAD/2QAAZdwAADHeAABG4QAAw+MAABrqAAC76wAA m+4AAGHwAACb9AAAYPcAAOP3AABY+gAAJgABALgBAQBsBgEAvgYBABYHAQCbCgEAvwwBABsOAQBj DgEAnA4BAGgUAQCcFwEAOhgBAP0ZAQBcGgEABR8BAHQfAQA0IwEAQygBANMsAQACMgEAFDUBAKM1 AQCHNwEAjjoBAEhBAQDXQgEAwUQBALJHAQCXSQEAh0sBAKhLAQCXTQEA6E0BAPtNAQB+TgEAl04B APdOAQBOTwEAaU8BALpPAQAHUAEAO1QBAFxVAQCsAAAArQAAAK4AAACwAAAAsQAAALIAAACzAAAA tAAAALUAAAC+AAAAwAAAAMIAAADEAAAAxQAAAMgAAADJAAAAywAAAM0AAADOAAAA0AAAANIAAADU AAAA1gAAANgAAADaAAAA2wAAAN0AAADfAAAA4AAAAOIAAADkAAAA5gAAAOgAAADqAAAA6wAAAO0A AADvAAAA8AAAAPIAAAD0AAAA9wAAAPgAAAD6AAAA/AAAAP0AAAD/AAAAAQEAAAMBAAAFAQAABwEA AAkBAAALAQAADQEAAA4BAAAQAQAAEgEAABQBAAAWAQAAFwEAABkBAAAaAQAAHAEAAB4BAAAgAQAA IgEAACMBAAAlAQAAJgEAACgBAAAqAQAALAEAAC0BAAAvAQAAMQEAADMBAAA1AQAANwEAADkBAAA6 AQAAPAEAAD4BAABAAQAAQgEAAEQBAABGAQAARwEAAEkBAABLAQAATQEAAE8BAABQAQAAUwEAAFQB AABWAQAAVwEAAFkBAABbAQAAXAEAAF4BAABgAQAAYwEAAGYBAABnAQAAaQEAAGsBAABsAQAAbgEA AHABAAByAQAAdAEAAHUBAAB3AQAAeAEAAHkBAAB7AQAAfAEAAH0BAAB/AQAAgAEAAAAAAAAYAAAA HgAAAG8AAACgAAAApQAAAPoGAAATBwAAFgcAACoHAABDBwAASAcAAGYHAAB/BwAAhAcAAJcHAACw BwAAtQcAAMUHAADeBwAA4wcAAPwHAAAVCAAAHAgAADoIAABTCAAAWggAAIkIAACiCAAAqQgAAMcI AADgCAAA5wgAAAAJAAAaCQAAIQkAAC4JAABICQAASwkAAGIJAAB8CQAAgQkAAJMJAACvCQAAtAkA AMYJAADgCQAA5QkAAP8JAAAZCgAAHgoAACwKAABTCgAAVgoAAHAKAACKCgAAjwoAALIKAADMCgAA 0QoAAPEKAAAVCwAAGAsAAEALAABaCwAAXwsAAHwLAACWCwAAmwsAALkLAADVCwAA2gsAAPQLAAAW DAAAHQwAACwMAABNDAAAUAwAAHEMAACVDAAAmgwAALgMAADZDAAA4AwAAP4MAAAYDQAAHw0AAE4N AABoDQAAbw0AAI0NAACsDQAAsw0AAMwNAADmDQAA7Q0AAP4NAAAlDgAAKg4AAEcOAABkDgAAaQ4A AIMOAACmDgAArQ4AALwOAADdDgAA4A4AAAYPAAAjDwAAKA8AAEIPAABgDwAAZQ8AAJsPAADBDwAA yA8AANcPAADxDwAA9A8AAAkQAAAjEAAAKBAAAFUQAABvEAAAdBAAAJwQAAC2EAAAuxAAAOcQAAAB EQAABhEAACkRAABDEQAARhEAAGERAAB7EQAAfhEAAJkRAAC+EQAAwxEAAOwRAAAGEgAADRIAAC4S AABIEgAATxIAAFoSAAB0EgAAgBIAAIwSAACmEgAAshIAAMISAADcEgAA6BIAAPwSAAAWEwAAIhMA ADYTAABXEwAAWxMAAG0TAACOEwAAlBMAALATAADREwAA1xMAAPETAAAOFAAAEBQAACoUAAA/FAAA RRQAAB4gAAAzIAAAOSAAACUiAAA6IgAAQCIAALwsAADRLAAA1ywAAHM3AACINwAAjjcAAG44AACD OAAAiTgAAItCAACgQgAApkIAAPdHAAAMSAAAEkgAAKxJAADBSQAAx0kAAFJVAABnVQAAbVUAAGdX AAB8VwAAglcAACpYAAA/WAAARVgAACpiAAA/YgAARWIAAGdwAAB8cAAAgnAAABl5AAAueQAANHkA AHB9AACFfQAAi30AABqBAAAvgQAANYEAANCGAADlhgAA64YAAHGRAACGkQAAjJEAAEmXAABelwAA ZJcAAJGlAACmpQAArKUAABGzAAAmswAALLMAACq4AAA/uAAARbgAAFm7AABuuwAAdLsAAB3FAAAy xQAAOMUAAO/FAAAExgAACsYAAGHKAAB2ygAAfMoAAB/OAAA0zgAAOs4AAPDPAAAF0AAAC9AAAEjU AABd1AAAY9QAACnZAAA+2QAARNkAAIjjAACd4wAAo+MAANLnAADn5wAA7ecAAJvsAACw7AAAtuwA AEPvAABY7wAAXu8AAMbvAADb7wAA4e8AAM34AADi+AAA6PgAAG7+AACD/gAAif4AAKH+AAC2/gAA vP4AAPn+AAAO/wAAFP8AAJsCAQCwAgEAtgIBAMEEAQDWBAEA3AQBAP4FAQATBgEAGQYBAEYGAQBb BgEAYQYBAH8GAQCUBgEAmgYBAEsMAQBgDAEAZgwBAAwQAQAhEAEAJxABAP0RAQASEgEAGBIBAD8S AQBUEgEAWhIBAOgWAQD9FgEAAxcBAFcXAQBsFwEAchcBAFUtAQBqLQEAcC0BAIYtAQCbLQEAoS0B AEwuAQClLgEA3i4BACUvAQB+LwEAgi8BAJEvAQC3LwEAwS8BAMcvAQDrLwEA+S8BAP0vAQAuMAEA hzABAKQwAQDcMAEA4DABAO8wAQAUMQEAIDEBACQxAQBVMQEAjjEBALAxAQDoMQEA7DEBAO8xAQAy MgEANzIBADoyAQB7MgEAfzIBAI4yAQC4MgEAxTIBAMgyAQDnMgEA8jIBAPUyAQAcMwEAJjMBACkz AQBNMwEAWTMBAFwzAQCJMwEAljMBAJkzAQDDMwEAzTMBANQzAQD2MwEABTQBAAk0AQA6NAEAYjQB AHs0AQCzNAEAtzQBALo0AQDxNAEA9DQBAPc0AQAvNQEAMzUBADY1AQB5NQEAfjUBAIE1AQDCNQEA xjUBANU1AQD8NQEABzYBAAo2AQAzNgEARDYBAEc2AQBvNgEAfTYBAIA2AQCqNgEAtzYBALo2AQDk NgEA7jYBAAM3AQAvNwEAOjcBAD43AQBvNwEAqzcBAMQ3AQD8NwEAADgBAAM4AQBGOAEASzgBAE44 AQCPOAEAkzgBALE4AQDiOAEA8DgBAAg5AQBAOQEARDkBAGA5AQCROQEArDkBAMQ5AQD8OQEAADoB ADo6AQBrOgEAezoBAJc6AQDPOgEA0zoBAP86AQAwOwEAiTsBAKY7AQDeOwEA4jsBAP87AQAwPAEA XDwBAIE8AQC5PAEAvTwBAMw8AQDuPAEA/jwBAAE9AQAoPQEANT0BADw9AQBdPQEAaT0BAG09AQCe PQEA0D0BAPQ9AQAsPgEAMD4BADM+AQB2PgEAez4BAH4+AQC/PgEAwz4BAOI+AQATPwEAWT8BAHI/ AQCqPwEArj8BANw/AQANQAEAS0ABAGtAAQCjQAEAp0ABANNAAQAEQQEAPEEBAFdBAQCPQQEAk0EB ALVBAQDmQQEA/UEBABdCAQBPQgEAU0IBAJpCAQDXQgEA70IBAEFDAQB+QwEAg0MBAItDAQCgQwEA pkMBAN9DAQAFRAEAEEQBABNEAQA8RAEARUQBAEhEAQB3RAEAhEQBAItEAQCyRAEAu0QBAL9EAQAQ RQEAZUUBAJpFAQCvRQEAtUUBAPtFAQAkRgEAOEYBAEFGAQBlRgEAe0YBAKlGAQDZRgEA9EYBAP1G AQApRwEAR0cBAHJHAQCcRwEAsUcBALpHAQDeRwEA9EcBAFxNAQATWJT/lYATWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwT WBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/lYwTWBT/ lYwPAADwVAAAAAAABvAgAAAAAQgAAAMAAAACAAAAAgAAAAEAAAACAAAAAgAAAAEAAAAjAAvwDAAA AIbBAAAAAMXBAAAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAEPAALwSAAAACAACPAIAAAAAQAA AAAIAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAA BQAAAAAPAALwkgAAABAACPAIAAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/Ae AAAAvwEQABAAywEAAAAA/wEAAAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA//+GAAAAAwB0AG8A YwAHAGEAbgBjAGgAbwByADEADQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgAxAAcAYQBuAGMAaABv AHIAMgAPAHIAZgBjAC4AcwBlAGMAdABpAG8AbgAuADEALgAxAAcAYQBuAGMAaABvAHIAMwAPAHIA ZgBjAC4AcwBlAGMAdABpAG8AbgAuADEALgAyAAcAYQBuAGMAaABvAHIANAAPAHIAZgBjAC4AcwBl AGMAdABpAG8AbgAuADEALgAzAAgARgBpAGcAdQByAGUAXwAxAAcAYQBuAGMAaABvAHIANQAPAHIA ZgBjAC4AcwBlAGMAdABpAG8AbgAuADEALgA0AAcAYQBuAGMAaABvAHIANgARAHIAZgBjAC4AcwBl AGMAdABpAG8AbgAuADEALgA0AC4AMQAIAEYAaQBnAHUAcgBlAF8AMgAHAGEAbgBjAGgAbwByADcA EQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgAxAC4ANAAuADIACABGAGkAZwB1AHIAZQBfADMABwBh AG4AYwBoAG8AcgA4ABEAcgBmAGMALgBzAGUAYwB0AGkAbwBuAC4AMQAuADQALgAzAAcAYQBuAGMA aABvAHIAOQARAHIAZgBjAC4AcwBlAGMAdABpAG8AbgAuADEALgA0AC4ANAAIAEYAaQBnAHUAcgBl AF8ANAAIAGEAbgBjAGgAbwByADEAMAARAHIAZgBjAC4AcwBlAGMAdABpAG8AbgAuADEALgA0AC4A NQAIAGEAbgBjAGgAbwByADEAMQANAHIAZgBjAC4AcwBlAGMAdABpAG8AbgAuADIACABhAG4AYwBo AG8AcgAxADIADwByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgAyAC4AMQAIAEYAaQBnAHUAcgBlAF8A NgAKAHUAcwBlAHIALQBhAGcAZQBuAHQADwByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgAyAC4AMgAI AEYAaQBnAHUAcgBlAF8ANwAIAEYAaQBnAHUAcgBlAF8ANQAIAGEAbgBjAGgAbwByADEAMwAPAHIA ZgBjAC4AcwBlAGMAdABpAG8AbgAuADIALgAzAAgAYQBuAGMAaABvAHIAMQA0AA8AcgBmAGMALgBz AGUAYwB0AGkAbwBuAC4AMgAuADQAFQBjAGwAaQBlAG4AdAAtAGEAdQB0AGgAZQBuAHQAaQBjAGEA dABpAG8AbgANAHIAZgBjAC4AcwBlAGMAdABpAG8AbgAuADMACABhAG4AYwBoAG8AcgAxADUADwBy AGYAYwAuAHMAZQBjAHQAaQBvAG4ALgAzAC4AMQAIAGEAbgBjAGgAbwByADEANgAPAHIAZgBjAC4A cwBlAGMAdABpAG8AbgAuADMALgAyABIAdQBzAGUAcgAtAGEAdQB0AGgAbwByAGkAegBhAHQAaQBv AG4ADQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgA0AAgAYQBuAGMAaABvAHIAMQA3AA8AcgBmAGMA LgBzAGUAYwB0AGkAbwBuAC4ANAAuADEACABhAG4AYwBoAG8AcgAxADgADwByAGYAYwAuAHMAZQBj AHQAaQBvAG4ALgA0AC4AMgAKAGEAdQB0AGgALQBlAHIAcgBvAHIADwByAGYAYwAuAHMAZQBjAHQA aQBvAG4ALgA0AC4AMwAQAGEAdQB0AGgALQBlAHIAcgBvAHIALQBjAG8AZABlAHMAEQByAGYAYwAu AHMAZQBjAHQAaQBvAG4ALgA0AC4AMwAuADEADwBvAGIAdABhAGkAbgBpAG4AZwAtAHQAbwBrAGUA bgANAHIAZgBjAC4AcwBlAGMAdABpAG8AbgAuADUAEgBhAGMAYwBlAHMAcwAtAGcAcgBhAG4AdAAt AHQAeQBwAGUAcwAPAHIAZgBjAC4AcwBlAGMAdABpAG8AbgAuADUALgAxAA8AYwBvAGQAZQAtAGcA cgBhAG4AdAAtAHQAeQBwAGUAEQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgA1AC4AMQAuADEACABh AG4AYwBoAG8AcgAxADkAEQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgA1AC4AMQAuADIACABhAG4A YwBoAG8AcgAyADAAEQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgA1AC4AMQAuADMADQB0AG8AawBl AG4ALQByAGUAZgByAGUAcwBoABEAcgBmAGMALgBzAGUAYwB0AGkAbwBuAC4ANQAuADEALgA0AAgA YQBuAGMAaABvAHIAMgAxABEAcgBmAGMALgBzAGUAYwB0AGkAbwBuAC4ANQAuADEALgA1ABUAYQBj AGMAZQBzAHMALQB0AG8AawBlAG4ALQByAGUAcwBwAG8AbgBzAGUADwByAGYAYwAuAHMAZQBjAHQA aQBvAG4ALgA1AC4AMgALAHQAbwBrAGUAbgAtAGUAcgByAG8AcgAPAHIAZgBjAC4AcwBlAGMAdABp AG8AbgAuADUALgAzABEAdABvAGsAZQBuAC0AZQByAHIAbwByAC0AYwBvAGQAZQBzABEAcgBmAGMA LgBzAGUAYwB0AGkAbwBuAC4ANQAuADMALgAxAA8AYQBjAGMAZQBzAHMALQByAGUAcwBvAHUAcgBj AGUADQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgA2AAsAdABvAGsAZQBuAC0AdAB5AHAAZQBzAA8A cgBmAGMALgBzAGUAYwB0AGkAbwBuAC4ANgAuADEADABhAHUAdABoAHoALQBoAGUAYQBkAGUAcgAM AGEAdQB0AGgAbgAtAGgAZQBhAGQAZQByAA8AcgBmAGMALgBzAGUAYwB0AGkAbwBuAC4ANgAuADIA CgBiAG8AZAB5AC0AcABhAHIAYQBtABQAcgBlAHMAbwB1AHIAYwBlAC0AZQByAHIAbwByAC0AYwBv AGQAZQBzABEAcgBmAGMALgBzAGUAYwB0AGkAbwBuAC4ANgAuADIALgAxAAgAYQBuAGMAaABvAHIA MgAyAA0AcgBmAGMALgBzAGUAYwB0AGkAbwBuAC4ANwAIAGEAbgBjAGgAbwByADIAMwAPAHIAZgBj AC4AcwBlAGMAdABpAG8AbgAuADcALgAxAAgAYQBuAGMAaABvAHIAMgA0AA8AcgBmAGMALgBzAGUA YwB0AGkAbwBuAC4ANwAuADIACABhAG4AYwBoAG8AcgAyADUADwByAGYAYwAuAHMAZQBjAHQAaQBv AG4ALgA3AC4AMwAIAGEAbgBjAGgAbwByADIANgAPAHIAZgBjAC4AcwBlAGMAdABpAG8AbgAuADcA LgA0AAgAYQBuAGMAaABvAHIAMgA3AA0AcgBmAGMALgBzAGUAYwB0AGkAbwBuAC4AOAAIAGEAbgBj AGgAbwByADIAOAANAHIAZgBjAC4AcwBlAGMAdABpAG8AbgAuADkAEwBwAGEAcgBhAG0AZQB0AGUA cgBzAC0AcgBlAGcAaQBzAHQAcgB5AA8AcgBmAGMALgBzAGUAYwB0AGkAbwBuAC4AOQAuADEACABh AG4AYwBoAG8AcgAyADkAEQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgA5AC4AMQAuADEACABhAG4A YwBoAG8AcgAzADAAEQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgA5AC4AMQAuADIACABhAG4AYwBo AG8AcgAzADEADQByAGYAYwAuAHMAZQBjAHQAaQBvAG4ALgBBAAgAYQBuAGMAaABvAHIAMwAyAA0A cgBmAGMALgBzAGUAYwB0AGkAbwBuAC4AQgAIAGEAbgBjAGgAbwByADMAMwANAHIAZgBjAC4AcwBl AGMAdABpAG8AbgAuAEMACABhAG4AYwBoAG8AcgAzADQADQByAGYAYwAuAHMAZQBjAHQAaQBvAG4A LgBEAA4AcgBmAGMALgByAGUAZgBlAHIAZQBuAGMAZQBzAA4AcgBmAGMALgBzAGUAYwB0AGkAbwBu AC4AMQAwAA8AcgBmAGMALgByAGUAZgBlAHIAZQBuAGMAZQBzADEAHQBJAC0ARAAuAGkAZQB0AGYA LQBoAHQAdABwAGIAaQBzAC0AcAAxAC0AbQBlAHMAcwBhAGcAaQBuAGcABwBSAEYAQwAyADAANAA1 AAcAUgBGAEMAMgAxADEAOQAHAFIARgBDADIANgAxADYABwBSAEYAQwAyADYAMQA3AAcAUgBGAEMA MgA4ADEAOAAHAFIARgBDADIAOAAyADgABwBSAEYAQwAzADAAMgAzAAcAUgBGAEMAMwA0ADQANwAH AFIARgBDADMANgAyADkABwBSAEYAQwAzADkAOAA2AAcAUgBGAEMANAA2ADIANwAHAFIARgBDADUA MgAyADYABwBSAEYAQwA1ADIANAA2AAcAUgBGAEMANQA4ADQAOQAYAFcAMwBDAC4AUgBFAEMALQBo AHQAbQBsADQAMAAxAC0AMQA5ADkAOQAxADIAMgA0AA8AcgBmAGMALgByAGUAZgBlAHIAZQBuAGMA ZQBzADIAFgBPAEEAUwBJAFMALgBzAGEAbQBsAC0AYwBvAHIAZQAtADIALgAwAC0AbwBzAAsAcgBm AGMALgBhAHUAdABoAG8AcgBzAOUGAAAnFAAASBQAABsgAAA8IAAAIiIAAEMiAAC5LAAA2iwAABMw AABwNwAAkTcAAGs4AACMOAAAhzoAAIhCAACpQgAAnEYAAPRHAAAVSAAAqUkAAMpJAADnSwAAT1UA AHBVAABkVwAAhVcAACdYAABIWAAAX1kAACdiAABIYgAAw2YAAMNmAABkcAAAhXAAABZ5AAA3eQAA bX0AAI59AAAXgQAAOIEAAM2GAADuhgAAbpEAAI+RAABGlwAAZ5cAAI6lAACvpQAADrMAAC+zAAAn uAAASLgAAFa7AAB3uwAAGsUAADvFAADsxQAADcYAAF7KAAB/ygAAHM4AAD3OAADtzwAADtAAAEXU AABm1AAAJtkAAEfZAACF4wAApuMAAM/nAADw5wAAmOwAALnsAABA7wAAYe8AAHrvAADD7wAA5O8A AOXvAADK+AAA6/gAAGv+AACM/gAAnv4AAL/+AAD2/gAAF/8AAJgCAQC5AgEAvgQBAN8EAQD7BQEA HAYBAEMGAQBkBgEAfAYBAJ0GAQBIDAEAaQwBAAkQAQAqEAEA+hEBABsSAQA8EgEAXRIBAOUWAQAG FwEAVBcBAHUXAQBSLQEAcy0BAIMtAQC/LQEAhy8BAOUwAQCEMgEAyzUBAJg4AQBJOQEABToBANg6 AQDnOwEAwjwBAMg+AQCzPwEArEABAJhBAQBYQgEAiEMBAMZDAQCXRQEAXU0BAAAAAAABAAAAAgAA AAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAA EQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAf AAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0A AAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAA ADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAA SgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABY AAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAAZQAAAGYA AABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAAdAAA AHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAAgAAAAIEAAACCAAAA gwAAAIQAAACFAAAA5QYAACcUAABIFAAAGyAAADwgAAAiIgAAQyIAALksAADaLAAAEzAAAHA3AACR NwAAazgAAIw4AACHOgAAiEIAAKlCAACcRgAA9EcAABVIAACpSQAAykkAAOdLAABPVQAAcFUAAGRX AACFVwAAJ1gAAEhYAABfWQAAJ2IAAEhiAADDZgAAw2YAAGRwAACFcAAAFnkAADd5AABtfQAAjn0A ABeBAAA4gQAAzYYAAO6GAABukQAAj5EAAEaXAABnlwAAjqUAAK+lAAAOswAAL7MAACe4AABIuAAA VrsAAHe7AAAaxQAAO8UAAOzFAAANxgAAXsoAAH/KAAAczgAAPc4AAO3PAAAO0AAARdQAAGbUAAAm 2QAAR9kAAIXjAACm4wAAz+cAAPDnAACY7AAAuewAAEDvAABh7wAAeu8AAMPvAADk7wAA5e8AAMr4 AADr+AAAa/4AAIz+AACe/gAAv/4AAPb+AAAX/wAAmAIBALkCAQC+BAEA3wQBAPsFAQAcBgEAQwYB AGQGAQB8BgEAnQYBAEgMAQBpDAEACRABACoQAQD6EQEAGxIBADwSAQBdEgEA5RYBAAYXAQBUFwEA dRcBAFItAQBzLQEAgy0BAN4tAQCQLwEA7jABAI0yAQDUNQEAoTgBAFI5AQAOOgEA4ToBAPA7AQDL PAEA0T4BALw/AQC1QAEAoUEBAHJCAQCIQwEA3kMBAJdFAQBdTQEA//8VAAoAAAAAASG21hD///// AAAAASK21hD/////AAAAASO21hD/////AAAAASS21hD/////AAAAASW21hD/////AAAAASa21hD/ ////AAAAASe21hD/////AAAAASi21hD/////AAAAASm21hD/////AAAAASq21hD/////AAAAASu2 1hD/////AAAAASy21hD/////AAAAAS221hD/////AAAAAS621hD/////AAAAAS+21hD/////AAAA ATC21hD/////AAAAATG21hD/////AAAAATK21hD/////AAAAATO21hD/////AAAAATS21hD///// AAAAAQK51hD/////mhsAAPEbAADvHgAAkS0AANotAABJNQAAJDYAAHo2AACxQgAAbEoAAKpRAAD8 UQAAqFgAAKJiAADGcAAAlXIAABNzAAC+eQAAF3oAAMaDAACNFQEA+kcBAAAAAAABAAAAAgAAAAMA AAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAA ABIAAAATAAAAFAAAALIbAAD9GwAABB8AAK4tAADnLQAAVjUAADA2AACGNgAA1EIAAG9KAADRUQAA C1IAAL5YAACsYgAA1XAAAJlyAAAWcwAAwXkAACB6AAArhAAAohUBAPpHAQAAAAAAsmUAAL1lAABP gwAAWYMAAF2DAABngwAAaIMAAH+DAACOgwAAmoMAAC+EAAA4hAAAW4QAAGiEAAAehQAAKIUAACyF AAA2hQAAN4UAAFOFAABihQAAb4UAAI6FAACahQAAyYoAAN6KAABRiwAAYYsAAH+MAACJjAAAjYwA AJeMAACYjAAAr4wAAL6MAADOjAAAz4wAANmMAAD+jAAAE40AAEyNAABYjQAAJo4AAC+OAABymAAA fJgAAJWYAACimAAAbZkAAHuZAADjmQAA7JkAACCaAAAsmgAAhJ8AAJufAACcnwAAqp8AAL2fAADJ nwAAA6IAAAqiAADnpgAA9aYAAMmoAADVqAAAAKkAAA6pAABmqQAAcKkAAD6qAABIqgAAXa4AAGqu AAAKrwAAFK8AABOwAAAhsAAAm7AAAKWwAAC8sQAAxrEAAMexAADZsQAAWrQAAGS0AAC0tAAAxbQA AFO1AABctQAAubgAAMi4AABIuQAAVrkAAIO5AACWuQAA2bkAAO65AAA0ugAAQboAAHy6AACVugAA 4boAAO66AACMwAAAlsAAAMDAAADKwAAAGcEAACvBAAA3wQAARMEAAF3GAABvxgAA8MYAAPzGAACe xwAAq8cAAHDIAAB6yAAAfsgAAIjIAACJyAAApcgAALTIAADByAAA4MgAAOzIAAA0zAAAQcwAAAbN AAAQzQAAFM0AAB7NAAAfzQAAMc0AAEDNAABNzQAAX80AAG/NAACrzgAAvc4AAFTQAABh0AAAktAA AJ/QAABU0QAAYdEAACbSAAAw0gAANNIAAD7SAAA/0gAAVtIAAGXSAABy0gAAD9UAABnVAACK1gAA lNYAAJjWAACi1gAA4tYAAOzWAADH2gAA09oAABTbAAAe2wAAw9sAAM3bAACn3AAAtNwAAMXfAADJ 3wAAueEAAL3hAAAD4gAAF+IAAH3kAACB5AAAxuQAANfkAABl5QAAbuUAAFnmAABd5gAAiuYAAJnm AABh6AAAcOgAAGTpAABy6QAAOuoAAE3qAACh6gAAruoAAHvrAACR6wAA/esAAArsAABp8QAAbvEA AKXxAACp8QAAsvEAALXxAAC78wAAv/MAAMjzAADZ8wAA9fMAAPjzAAAC9AAAC/QAACD2AAAx9gAA c/YAAHb2AADd9gAA7vYAAPT2AAD99gAAePgAAIX4AACc+AAArfgAALj5AADH+QAA7PoAAPn6AADx +wAAA/wAALsBAQDAAQEATQIBAFICAQC5AwEAvgMBAAoEAQAPBAEAkQQBAJYEAQBfCgEAZAoBAGUK AQBoCgEAHBUBACAVAQA0FQEAPBUBAGoVAQB0FQEAdRUBAH4VAQCwFQEAthUBAMAVAQDHFQEAyBUB ANMVAQDeFQEA4hUBAHsWAQCBFgEAnRYBAKMWAQCvFgEAthYBAM4WAQDRFgEAHRkBAC8ZAQCgGQEA rRkBAMsZAQDZGQEAHxoBAC0aAQBEGgEAThoBANMaAQDdGgEABRsBAAgbAQAbHQEAJh0BAIAdAQCR HQEAox0BAL0dAQDEHQEA1R0BANsdAQDpHQEAih8BAJMfAQC4IgEAwSIBAHckAQCHJAEAlSQBAKMk AQBKJgEAWiYBAFgpAQBgKQEAbikBAH4pAQDoKwEA9CsBAPE2AQD5NgEAUzkBAFk5AQAkPwEAKD8B ALZAAQC8QAEAc0IBAHpCAQD4RwEA+kcBAPtHAQD9RwEA/kcBAABIAQABSAEAA0gBAARIAQAQSAEA EUgBAD9IAQBFSAEAd0gBAHxIAQAuSQEAM0kBAONKAQDmSgEAe0sBAIJLAQB0TAEAe0wBAIhMAQCP TAEAXU0BAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHAAcAAgAHAAIABwACAAcAAgAHAAIABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAAAAAAEsHAACEBwAAhwcAALUHAAC4BwAA4wcAAB8IAABaCAAA6ggAACEJ AAAkCQAASwkAAIQJAAC0CQAAtwkAAOUJAADoCQAAHgoAACEKAABWCgAA1AoAABgLAABiCwAAmwsA AJ4LAADaCwAA3QsAAB0MAAAgDAAAUAwAAFMMAACaDAAA4wwAAB8NAAC2DQAA7Q0AAPANAAAqDgAA LQ4AAGkOAABsDgAArQ4AALAOAADgDgAAaA8AAMgPAADLDwAA9A8AAPcPAAAoEAAACREAAEYRAABJ EQAAfhEAAIERAADDEQAAxhEAAA0SAAAQEgAATxIAAFISAABbEwAAXhMAAJQTAABAIAAATCAAAFYh AABaIQAAiiEAAJAhAABHIgAAVCIAAFUiAABeIgAAaCIAAMEiAADDIgAAyyIAACEjAAAnIwAAeCMA AIAjAACHIwAAxCMAAMYjAADOIwAAzyMAAOYjAADoIwAA7SMAAFQmAABaJgAAvSYAAMQmAAAyJwAA PycAAEUnAACRJwAA4ScAAOcnAABkKQAAcSkAAJsqAACjKgAAuyoAACcrAABZKwAAXSsAAF8rAABk KwAAwCsAAMcrAADwKwAA9CsAAPYrAAD8KwAAsywAALcsAADeLAAA6CwAAMgtAADMLQAAyi4AANAu AABiMAAAZDAAANwwAADiMAAAoDEAAKQxAAAaMgAAIDIAAN4yAADkMgAAWDMAAFwzAAAHNAAAFDQA AJU3AACdNwAAkjgAAKE4AABnOQAAbTkAAEA7AABEOwAAbjsAAHU7AACsOwAAtDsAADg8AAA7PAAA wjwAAMM8AADiPAAA6zwAAGI9AABuPQAAgkIAAIZCAACvQgAAuUIAAGtFAABvRQAA3kUAAOJFAADm RgAA6EYAAD1HAABFRwAAVkcAAFlHAAAbSAAAI0gAANBJAADZSQAANUwAADhMAACtTAAAskwAAG5N AAB0TQAA5k0AAOlNAABeTgAAZE4AANZOAADZTgAAl08AAJpPAAAPUAAAFVAAAMVQAADRUAAAdlUA AIFVAACaVwAAn1cAAExYAABRWAAAsFkAALVZAAArWgAALVoAAGlaAABzWgAAuloAAL1aAADlWwAA 5lsAAGJcAABmXAAAklwAAJtcAADOXAAA0lwAAApdAAATXQAAUl0AAFZdAADwXQAA/F0AAJZeAACa XgAAnmEAAKJhAABMYgAAUmIAACNnAAAnZwAApmcAAKpnAABIaAAATGgAAH5oAACHaAAAy2gAAM1o AAAOaQAAGGkAAHlpAAB9aQAAMWoAADpqAABRagAAVWoAAIxqAACVagAA2GoAAOBqAABpawAAdWsA AORrAADoawAAiXAAAJFwAABTcwAAWXMAAEd1AABNdQAAgHYAAIV2AAA7eQAAR3kAACp8AAAufAAA 13wAAP18AAA8gQAARIEAADmEAABChAAAQ4QAAFmEAABphAAAcoQAAHOEAACHhAAA8oYAAPqGAAA4 iQAAPIkAAOWJAAALigAA34oAAOiKAADpigAALIsAAGKLAABriwAAbIsAAIGLAADPjAAA2owAABeN AAAbjQAA7o0AAPKNAADQlQAA25UAAGuXAAB6lwAAj5gAAJOYAACjmAAArJgAAO2ZAAD2mQAAGpoA AB6aAAAtmgAAoZoAAKKaAAAmmwAAgpsAAIebAACImwAAkZsAAMmcAADOnAAAz5wAANicAACNnwAA lp8AAA2iAAAWogAA+qMAAP6jAACzpQAAwqUAALmmAAC9pgAAF6cAAFSnAABxqQAAo6kAADiqAAA8 qgAASaoAAFKqAABTqgAAp6oAAEGrAABGqwAAR6sAAFCrAABRqwAAs6sAAButAAAgrQAAIa0AAHGt AAAnrwAAK68AALiwAAC8sAAAXbIAAGSyAAAzswAAOrMAAHe0AAB7tAAAfbQAAIK0AACDtAAAjLQA AK60AACytAAAxrQAAM+0AABdtQAAZrUAAAC2AAAFtgAABrYAAFa2AABOuAAAVbgAACi7AAAtuwAA l70AAJu9AAAwvwAANL8AAMvAAADUwAAA1cAAAAPBAAC1wQAAusEAALvBAADEwQAAccQAAHXEAAA/ xQAAR8UAABPGAAAixgAAocYAAKXGAACmxgAAr8YAAP3GAAAGxwAAwMcAAMfHAABYygAAXMoAAIXK AACPygAAIssAACfLAABpywAAccsAAHLLAAB7ywAAfMsAAJrLAACcywAApMsAAKXLAACuywAAr8sA AM3LAABWzAAAXcwAABbOAAAazgAAQ84AAEvOAAAU0AAAHdAAAKDQAACp0AAAdtEAAH3RAACf0wAA o9MAAGzUAAB31AAATNUAAFXVAABW1QAAX9UAAGDVAABu1QAA2NYAAOLWAACm1wAAqtcAAEvZAABT 2QAA1NoAAN3aAAAf2wAAKNsAAL3bAADB2wAAztsAANfbAADY2wAADdwAALXcAAC+3AAAJN0AACjd AACv3QAAtN0AALXdAAC+3QAAv90AAALeAADg3wAA5N8AANTiAADb4gAAquMAALHjAACP5AAAlOQA AJXkAACe5AAAwOQAAMTkAADY5AAA4eQAAG/lAAB45QAAguYAAIfmAAD25wAA/ecAALPpAADA6QAA lusAAKLrAABq7AAAb+wAANzsAADj7AAAZe8AAG3vAAB77wAAgO8AAOjvAADt7wAAJvEAACzxAAA7 8QAARPEAAGnxAABu8QAAl/EAAJzxAADM8QAA0/EAAPfxAAD88QAAN/IAAD7yAABa8gAAZfIAAIfz AACM8wAAtfMAAL/zAADv8wAA+PMAAOr1AADu9QAAcfgAAHb4AADx+AAA+PgAAPz8AAAB/QAAw/4A AM3+AADs/gAA8f4AABv/AAAl/wAACgIBAA8CAQBTAgEAWgIBAGkCAQByAgEAvQIBAMcCAQCPAwEA kwMBANYDAQDbAwEAlwQBAJ8EAQDjBAEA7QQBADkGAQA+BgEAoQYBAKYGAQDfCQEA5QkBAE8KAQBw CgEAbwwBAH0MAQDYDAEABA0BAJgNAQCbDQEAMBABADkQAQC5EAEAvhABANoQAQCUEQEAyxEBANER AQAbEgEAJhIBADISAQA3EgEAXRIBAGgSAQCKEwEAjRMBAFsUAQBfFAEABhcBABEXAQAlFwEAKhcB AHUXAQCAFwEAlBcBAJgXAQDmGAEA8hgBAG8cAQB2HAEAcSMBAH0jAQBFJQEAUSUBANknAQDiJwEA risBALMrAQD4RwEA+kcBAPtHAQD9RwEA/kcBAABIAQABSAEAA0gBAARIAQAQSAEAEUgBAHhJAQB8 SQEAo0kBAKdJAQDOSQEA0kkBAF1NAQAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcABwACAAcAAgAH AAIABwACAAcAAgAHADMABwAzAAcAMwAHAAAAAAAfAAAAESEAABEhAABZIQAAWSEAAI8hAACPIQAA qSEAAKkhAABcKwAAXCsAAPMrAADzKwAAtiwAALYsAAAKNAAACjQAAGU9AABlPQAAhUIAAIVCAABu RQAAbkUAAOFFAADhRQAAyFAAAMhQAADzXQAA810AAJleAACZXgAAoWEAAKFhAABsawAAbGsAAOdr AADnawAAVnMAAFZzAABKdQAASnUAACx8AAAsfAAALIIAACyCAAA6iQAAOokAAPGNAADxjQAA05UA ANOVAACSmAAAkpgAAB2aAAAdmgAA/aMAAP2jAAA7qgAAO6oAACqvAAAqrwAAu7AAALuwAAB6tAAA erQAALG0AACxtAAAmr0AAJq9AAAzvwAAM78AAHTEAAB0xAAAw8cAAMPHAABbygAAW8oAAFnMAABZ zAAAGc4AABnOAAB50QAAedEAAKLTAACi0wAAqdcAAKnXAADA2wAAwNsAACfdAAAn3QAA498AAOPf AADD5AAAw+QAACnxAAAp8QAA7fUAAO31AAAvAAEALwABAJIDAQCSAwEAeAgBAHgIAQDLFAEAyxQB AJIVAQCcFQEAnRUBAJ0VAQCiFQEAoxUBAB0WAQAuFgEA5hYBAOYWAQD3RwEAEUgBADNNAQBZTQEA XU0BAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAE AAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQA AwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAAD AAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAMABAACAAQAAgAEAAIA BAACAAQAAgAEAAMABwADAAQABwAkAIRqYgf8vEhG/w//D/8P/w//D/8P/w//D/8PAABgUt0HXGQG zv8P/w//D/8P/w//D/8P/w//DwAAnFmzCNzzYgj/D/8P/w//D/8P/w//D/8P/w8AAKAtzAjucrw/ /w//D/8P/w//D/8P/w//D/8PAADdFQUOjCl6x/8P/w//D/8P/w//D/8P/w//DwAASQcUEKJQumb/ D/8P/w//D/8P/w//D/8P/w8AADQ9fRDuKj5q/w//D/8P/w//D/8P/w//D/8PAAAYZqUTRPeq+v8P /w//D/8P/w//D/8P/w//DwAAcS+BFfgKXJT/D/8P/w//D/8P/w//D/8P/w8AAPJ10xnw6jBA/w// D/8P/w//D/8P/w//D/8PAACZWlsaQPIK4f8P/w//D/8P/w//D/8P/w//DwAANDncHbbhiHb/D/8P /w//D/8P/w//D/8P/w8AADVNLSKCeBRN/w//D/8P/w//D/8P/w//D/8PAADcL64i6hSUgP8P/w// D/8P/w//D/8P/w//DwAA7DMRLaT8uFD/D/8P/w//D/8P/w//D/8P/w8AALZwXTl2vk6I/w//D/8P /w//D/8P/w//D/8PAADKbJY5OidQp/8P/w//D/8P/w//D/8P/w//DwAA8GZyOiTbCMn/D/8P/w// D/8P/w//D/8P/w8AAF8b5jt4RrCh/w//D/8P/w//D/8P/w//D/8PAAD3SIg9FmOa5v8P/w//D/8P /w//D/8P/w//DwAA8hm1QML2LDz/D/8P/w//D/8P/w//D/8P/w8AAKkPSEWWBqj4/w//D/8P/w// D/8P/w//D/8PAABvLHdFGofixP8P/w//D/8P/w//D/8P/w//DwAAcjPWRwzzdqf/D/8P/w//D/8P /w//D/8P/w8AANk2QEpgFR6z/w//D/8P/w//D/8P/w//D/8PAAC+OcpMQF/Q3v8P/w//D/8P/w// D/8P/w//DwAAURh6TXaYdPz/D/8P/w//D/8P/w//D/8P/w8AAPJpmVZE5hJ7/w//D/8P/w//D/8P /w//D/8PAABvUrtYdq5GWv8P/w//D/8P/w//D/8P/w//DwAAPk4WWvr8JuH/D/8P/w//D/8P/w// D/8P/w8AANILkF42A3Jy/w//D/8P/w//D/8P/w//D/8PAACacP5q9OhiOf8P/w//D/8P/w//D/8P /w//DwAAawvrdYLrVlT/D/8P/w//D/8P/w//D/8P/w8AALtddHeYnHBL/w//D/8P/w//D/8P/w// D/8PAADAHVt4hB4wB/8P/w//D/8P/w//D/8P/w//DwAAhRiUeGzIFtn/D/8P/w//D/8P/w//D/8P /w8AAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5D ShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYF AAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAP GAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAAB AKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNK FABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUA AeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8Y AAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEA p/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oU AE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB 0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgA AA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn 8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQA T0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQ DgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAA D4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfw AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABP SgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZ Bl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAP hNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwAB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9K CgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsG XoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+E EA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oK AFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZe hIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQ GRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcA UUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6E cAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEAL EYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBR SgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSw E2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYR hJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFK AQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAF YISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGE mP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoK AG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBg hJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoA bygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCE mP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBv KAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY /kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4V xgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA AA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8o AAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+ Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXG BQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA DxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygA AQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5D ShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYF AAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAP GAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAAB AKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNK FABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUA AVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8Y AAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEA bwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oU AE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgA AA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn 8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQA T0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGA FgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAA D4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfw AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABP SgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAI Bl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAP hEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/AB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9K CgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMG XoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+E gBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oB AFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZe hKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4Rw CBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoA UUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E 4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLAT EYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBR SgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQ AmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAUR hJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFK CgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAO YISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGE mP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoK AG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlg hJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY /hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoA bygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CE mP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+ FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBv KAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY /kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4V xgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA AA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8o AAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+ Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXG BQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA DxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygA AQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5D ShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYF AAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAP GAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAAB ALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNK FABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUA AXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8Y AAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEA p/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oU AE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQAB sBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgA AA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQA T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGg BQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAA D4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfw AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABP SgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQ Bl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAP hLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/AB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9K CgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIG XoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+E oAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oK AFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZe hBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4Tg EBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoA UUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6E UBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNAC EYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBR SgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRA C2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4R hJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFK CgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAW YISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGE mP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAA AAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoH AG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhg hJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY /hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoA bygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CE mP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+ FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBv KAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY /kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4V xgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA AA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8o AAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+ Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXG BQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA DxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygA AQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5D ShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYF AAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAP GAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAAB AKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNK FABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUA AeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8Y AAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEA p/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oU AE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB 0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgA AA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn 8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQA T0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQ DgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAA D4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfw AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABP SgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZ Bl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAP hNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwAB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9K CgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsG XoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+E EA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oK AFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZe hIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQ GRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcA UUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6E cAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEAL EYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBR SgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSw E2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYR hJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFK AQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAF YISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGE mP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoK AG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBg hJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY /hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoA bygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCE mP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+ FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBv KAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY /kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4V xgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAA AA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8o AAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+ Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXG BQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA DxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygA AQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5D ShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYF AAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAP GAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAA AAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAAB AKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNK FABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUA AVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8Y AAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEA bwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oU AE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQAB QAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgA AA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn 8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQA T0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGA FgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAA D4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfw AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABP SgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAI Bl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAP hEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/AB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9K CgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMG XoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+E gBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oB AFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZe hKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4Rw CBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoA UUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E 4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLAT EYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBR SgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQ AmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAUR hJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFK CgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAO YISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGE mP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAA AAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeA AAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoK AG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlg hJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY /hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAA AAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AA AAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoA bygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CE mP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+ FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAA AAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAA AAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBv KAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY /kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4V xgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA AA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAA AAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8o AAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+ Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXG BQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAA DxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAA AAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygA AQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5D ShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYF AAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAP GAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAAB ALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNK FABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUA AXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8Y AAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAA AAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEA p/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oU AE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQAB sBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgA AA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAA AAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIGXoTQAmCEmP5DShQA T0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EoAURhJj+FcYFAAGg BQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAA D4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAA AAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oKAFFKCgBvKAABAKfw AQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY/kNKFABP SgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQ Bl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAP hLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAA AAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoAUUoKAG8oAAEAp/AB AAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9K CgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNACEYSY/hXGBQAB0AIG XoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+E oAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAAF4AAAAAAAAAAAAAA AAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEA AAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRAC2CEmP5DShQAT0oK AFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4RhJj+FcYFAAEQDgZe hBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4Tg EBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAA AAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAA ABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAWYISY/kNKFABPSgoA UUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGEmP4VxgUAAVAZBl6E UBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhNAC EYSY/hXGBQAB0AIGXoTQAmCEmP5DShQAT0oBAFFKAQBvKAABALfwAQAAABeAAAAAAAAAAAAAAAAA AAAAAAAADxgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/kNKFABPSgcAUUoHAG8oAAEAbwABAAAA F4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RwCBGEmP4VxgUAAXAIBl6EcAhghJj+Q0oUAE9KCgBR SgoAbygAAQCn8AEAAAAXgAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhEALEYSY/hXGBQABQAsGXoRA C2CEmP5DShQAT0oKAFFKCgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EEA4R hJj+FcYFAAEQDgZehBAOYISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAA AAAAAAAPGAAAD4TgEBGEmP4VxgUAAeAQBl6E4BBghJj+Q0oUAE9KCgBRSgoAbygAAQCn8AEAAAAX gAAAAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLATEYSY/hXGBQABsBMGXoSwE2CEmP5DShQAT0oKAFFK CgBvKAABAKfwAQAAABeAAAAAAAAAAAAAAAAAAAAAAAAADxgAAA+EgBYRhJj+FcYFAAGAFgZehIAW YISY/kNKFABPSgoAUUoKAG8oAAEAp/ABAAAAF4AAAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4RQGRGE mP4VxgUAAVAZBl6EUBlghJj+Q0oUAE9KCgBRSgoAbygAAQCn8CQAAACZWlsaAAAAAAAAAAAAAAAA 0guQXgAAAAAAAAAAAAAAALZwXTkAAAAAAAAAAAAAAACgLcwIAAAAAAAAAAAAAAAA8GZyOgAAAAAA AAAAAAAAAJxZswgAAAAAAAAAAAAAAADAHVt4AAAAAAAAAAAAAAAAGGalEwAAAAAAAAAAAAAAANk2 QEoAAAAAAAAAAAAAAACpD0hFAAAAAAAAAAAAAAAA3RUFDgAAAAAAAAAAAAAAADVNLSIAAAAAAAAA AAAAAADyaZlWAAAAAAAAAAAAAAAA90iIPQAAAAAAAAAAAAAAAFEYek0AAAAAAAAAAAAAAADKbJY5 AAAAAAAAAAAAAAAAcS+BFQAAAAAAAAAAAAAAAPJ10xkAAAAAAAAAAAAAAABrC+t1AAAAAAAAAAAA AAAAPk4WWgAAAAAAAAAAAAAAAPIZtUAAAAAAAAAAAAAAAABgUt0HAAAAAAAAAAAAAAAA3C+uIgAA AAAAAAAAAAAAAEkHFBAAAAAAAAAAAAAAAACEamIHAAAAAAAAAAAAAAAAhRiUeAAAAAAAAAAAAAAA AG8sd0UAAAAAAAAAAAAAAABfG+Y7AAAAAAAAAAAAAAAAu110dwAAAAAAAAAAAAAAADQ9fRAAAAAA AAAAAAAAAAA0OdwdAAAAAAAAAAAAAAAAb1K7WAAAAAAAAAAAAAAAAL45ykwAAAAAAAAAAAAAAABy M9ZHAAAAAAAAAAAAAAAAmnD+agAAAAAAAAAAAAAAAOwzES0AAAAAAAAAAAAAAAD///////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////yQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//yQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABlAP0nPAC9DLgjAAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQAjZesAvQy4IwAAAAABAAQA 0AIAAEculwFLTNY3AAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQDwE1sCvQy4IwAAAAABAAQA0AIA AGFfjAK9DLgjAAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQDiYJQES0zWNwAAAAABAAQA0AIAAOB/ 7wRLTNY3AAAAAAEABADQAgAAHEYPBb0MuCMAAAAAAQAEANACAADxIo0FvQy4IwAAAAAPARIA0AIA ANACAABkAAAAZAAAAAEAQCW5Br0MuCMAAAAADwESANACAADQAgAAZAAAAGQAAAABAFxrhwe9DLgj AAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQBMTMkHvQy4IwAAAAABAAQA0AIAAEgdTQhLTNY3AAAA AA8BEgDQAgAA0AIAAGQAAABkAAAAAQAeMUgJS0zWNwAAAAABAAQA0AIAAElQRA9LTNY3AAAAAAEA BADQAgAA3jaNEEtM1jcAAAAADwESANACAADQAgAAZAAAAGQAAAABAOIfGhK9DLgjAAAAAAEABADQ AgAAxlQbEr0MuCMAAAAAAQAEANACAABJOHITS0zWNwAAAAAPARIA0AIAANACAABkAAAAZAAAAAEA sWAdFL0MuCMAAAAADwESANACAADQAgAAZAAAAGQAAAABAJtRkhS9DLgjAAAAAAEABADQAgAAVX+7 FL0MuCMAAAAAAQAEANACAAC9K1kVvQy4IwAAAAAPARIA0AIAANACAABkAAAAZAAAAAEAQSq1F70M uCMAAAAAAQAEANACAADyDRoavQy4IwAAAAAPARIA0AIAANACAABkAAAAZAAAAAEAqlf+Hb0MuCMA AAAADwESANACAADQAgAAZAAAAGQAAAABAFZZih69DLgjAAAAAA8BEgDQAgAA0AIAAGQAAABkAAAA AQC9DLgjAAAAAAAAAAAPARIA4AEAAOABAADgAQAA4AEAAAIAFy6LJEtM1jcAAAAAAQAEANACAAA0 MKMkS0zWNwAAAAABAAQA0AIAAJdvyiW9DLgjAAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQATBREm vQy4IwAAAAAPARIA0AIAANACAABkAAAAZAAAAAEAfRPTJr0MuCMAAAAADwESANACAADQAgAAZAAA AGQAAAABAA5a/Ca9DLgjAAAAAAEABADQAgAAcUAGJ0tM1jcAAAAADwESANACAADQAgAAZAAAAGQA AAABAOofuii9DLgjAAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQB4b1IsS0zWNwAAAAAPARIA0AIA ANACAABkAAAAZAAAAAEAPCllLb0MuCMAAAAADwESANACAADQAgAAZAAAAGQAAAABAA1auS29DLgj AAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQAzG2kuS0zWNwAAAAAPARIA0AIAANACAABkAAAAZAAA AAEAJ23mLr0MuCMAAAAAAQAEANACAAASETAvS0zWNwAAAAABAAQA0AIAAKZacTJLTNY3AAAAAAEA BADQAgAAeQJ5Mr0MuCMAAAAAAQAEANACAABYZCwzS0zWNwAAAAAPARIA0AIAANACAABkAAAAZAAA AAEAT2lBN70MuCMAAAAAAQAEANACAAC5XEQ3vQy4IwAAAAABAAQA0AIAAEtM1jcAAAAAAAAAAA8B EgDgAQAA4AEAAOABAADgAQAAAgBDLFY6vQy4IwAAAAABAAQA0AIAAJ08iTtLTNY3AAAAAAEABADQ AgAA2y2zPUtM1jcAAAAADwESANACAADQAgAAZAAAAGQAAAABALp8p0C9DLgjAAAAAA8BEgDQAgAA 0AIAAGQAAABkAAAAAQCBIgVBS0zWNwAAAAAPARIA0AIAANACAABkAAAAZAAAAAEAvh3eQb0MuCMA AAAAAQAEANACAABoQN9BvQy4IwAAAAAPARIA0AIAANACAABkAAAAZAAAAAEADGY+Q0tM1jcAAAAA DwESANACAADQAgAAZAAAAGQAAAABANMyP0ZLTNY3AAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQDb JmVHS0zWNwAAAAAPARIA0AIAANACAABkAAAAZAAAAAEAdjXXR0tM1jcAAAAAAQAEANACAAD2AARI S0zWNwAAAAABAAQA0AIAAKI0i0hLTNY3AAAAAAEABADQAgAA/1/FSUtM1jcAAAAAAQAEANACAADn E1pKS0zWNwAAAAABAAQA0AIAAMIga0pLTNY3AAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQCKE5JK vQy4IwAAAAAPARIA0AIAANACAABkAAAAZAAAAAEAAjX0Sr0MuCMAAAAAAQAEANACAACrA7hMvQy4 IwAAAAAPARIA0AIAANACAABkAAAAZAAAAAEAY0qnTUtM1jcAAAAADwESANACAADQAgAAZAAAAGQA AAABACVOq01LTNY3AAAAAAEABADQAgAAJxkoTktM1jcAAAAAAQAEANACAAD2FU1OS0zWNwAAAAAB AAQA0AIAAMVZdVBLTNY3AAAAAAEABADQAgAAEjkRVUtM1jcAAAAADwESANACAADQAgAAZAAAAGQA AAABAIkMW1e9DLgjAAAAAAEABADQAgAAHSRDWUtM1jcAAAAAAQAEANACAADrQqRZS0zWNwAAAAAP ARIA0AIAANACAABkAAAAZAAAAAEAgDamW70MuCMAAAAADwESANACAADQAgAAZAAAAGQAAAABADhZ vltLTNY3AAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQCXPy9cS0zWNwAAAAABAAQA0AIAAGUMHl29 DLgjAAAAAAEABADQAgAAw3mtXUtM1jcAAAAADwESANACAADQAgAAZAAAAGQAAAABAGU1Zl5LTNY3 AAAAAA8BEgDQAgAA0AIAAGQAAABkAAAAAQDKFpphvQy4IwAAAAABAAQA0AIAABRd7WK9DLgjAAAA AAEABADQAgAAuDZQY70MuCMAAAAAAQAEANACAADGa81kS0zWNwAAAAABAAQA0AIAAApoA2W9DLgj AAAAAAEABADQAgAAPCVhaEtM1jcAAAAAAQAEANACAAA7BxFpvQy4IwAAAAABAAQA0AIAAKMoXW5L TNY3AAAAAAEABADQAgAA51mDbr0MuCMAAAAAAQAEANACAAAoMqFvvQy4IwAAAAABAAQA0AIAANNK oW9LTNY3AAAAAAEABADQAgAA+ClAc70MuCMAAAAAAQAEANACAACJBkp0S0zWNwAAAAAPARIA0AIA ANACAABkAAAAZAAAAAEAuga0d70MuCMAAAAADwESANACAADQAgAAZAAAAGQAAAABAH1H/He9DLgj AAAAAAEABADQAgAArXT4eUtM1jcAAAAAAQAEANACAABVRcl6S0zWNwAAAAAPARIA0AIAANACAABk AAAAZAAAAAEAKQzQfL0MuCMAAAAADwESANACAADQAgAAZAAAAGQAAAABALBdA39LTNY3AAAAAA8B EgDQAgAA0AIAAGQAAABkAAAAAQAOAAAABAAAAAgAAADlAAAAAAAAAAQAAABvaB4A+hoiAHRFLgC7 KkQANG9NAGVHWQBFRmsAdkx3AOQGkACTbLgA5HztABo38gDaWPcALS34AAAAAAD4RwEA+kcBAAAA AAABAAAA/0ABgAEASAUAAEgFAAAAAAAAAQABAEgFAAAAAAAASAUAAAAAAAACEAAAAAAAAABcTQEA aAAAEABAAAD//wIAAAAHAFUAbgBrAG4AbwB3AG4ABgBBAHUAdABoAG8AcgD//wIACAAAAAAAAAAA AAAAAAAAAAAAAAABAP//AgAAAAAAAAD//wAAAgD//wAAAAD//wAAAgD//wAAAAAMAAAARx6QAQAA AgIGAwUEBQIDBP8qAOBBeADACQAAAAAAAAD/AQAAAAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAANR6QAQIABQUBAgEHBgIFBwAAAAAAAAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIA bwBsAAAAMy6QAQAAAgsGBAICAgICBP8qAOBDeADACQAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAA ADcukAEAAAILBgQDBQQEAgT/BgChWyAAQBAAAAAAAAAAnwEAAAAAAABWAGUAcgBkAGEAbgBhAAAA Oy6QAQAAAgsGBAICAgICBP8qAOBDeADACQAAAAAAAAD/AQAAAAAAAEgAZQBsAHYAZQB0AGkAYwBh AAAAYxCQAQAOAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAE0AUwAgAFMAYQBuAHMA IABTAGUAcgBpAGYAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADcekAEAAAIEBQMF BAYDAgT/AgDg/wQAQAAAAAAAAAAAnwEAAAAAAABDAGEAbQBiAHIAaQBhAAAAPz2QAQAAAgcDCQIC BQIEBP8qAOBDeADACQAAAAAAAAD/AQAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADk9kAEA AAILBgkCAgQDAgT/AgDh//wAQAkAAAAAAAAAnwEAAAAAAABDAG8AbgBzAG8AbABhAHMAAAA1LpAB AAACCwYEAwUEBAIE/y4A4VtgAMApAAAAAAAAAP8BAQAAAAAAVABhAGgAbwBtAGEAAAA7DpABAgAF AAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAVwBpAG4AZwBkAGkAbgBnAHMAAABBHpAB AAACBAUDBQQGAwIE/wIA4P8kAEIAAAAAAAAAAJ8BAAAAAAAAQwBhAG0AYgByAGkAYQAgAE0AYQB0 AGgAAAAiAAQAcYiIGADw0AKwBGgBAAAAAMta8UbMWvFGAAAAAAEAAAAAAPMwAAAFFwEAIQCnAAAA BAADEFMCAADzMAAABRcBACEApwAAAFMCAAAAAAAAJQMA8BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAeAAAALQAtACBgTIwAAAAAAAAAAAAAAAAAABRRwEAUUcBAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAASoMR APAQAAjI/v0BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACMxYAAAAAAnw/w8ACSRQAADkBAAAjRUB AP///38AAAAAAAAAAP///3////9/////fzRvTQAABAAANgAAAAAAAAAAAAAAAAAAAAAAAAAAACEE AAAAAAAAAAAAAAAAAAAAAAAAEBwAAAsAAAAAAAAAAAB4AAAAeAAAAAAAAAAAAAAAoAUAAAAAAAAL AAAAAAAAANwAAAD//xIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcAAAA BgAAACQAAAAAAAwAAQAMAAIADAADAAwABAAMAAUADAAGAAwABwAMAAgADAAJAAwACgAMAAsADAAM AAwADQAMAA4ADAAPAAwAEAAMABEADAASAAwAEwAMABQADAAVAAwAFgAMABcADAAYAAwAGQAMABoA DAAbAAwAHAAMAB0ADAAeAAwAHwAMACAADAAhAAwAIgAMACMADAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAYBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQ q5EIACsns9kwAAAAKAEAAA4AAAABAAAAeAAAAAIAAACAAAAABAAAAIwAAAAHAAAAmAAAAAgAAACs AAAACQAAALgAAAASAAAAxAAAAAoAAADkAAAADAAAAPAAAAANAAAA/AAAAA4AAAAIAQAADwAAABAB AAAQAAAAGAEAABMAAAAgAQAAAgAAAOQEAAAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAeAAAADAAA AE5vcm1hbC5kb3RtAB4AAAAEAAAAAAAAAB4AAAAEAAAAMQAAAB4AAAAYAAAATWljcm9zb2Z0IE9m ZmljZSBXb3JkAAAAQAAAAAAAAAAAAAAAQAAAAAD6TUjDscsBQAAAAABAEWzDscsBAwAAACEAAAAD AAAA8zAAAAMAAAAFFwEAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAP7/AAAGAQIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmu RAAAAAXVzdWcLhsQk5cIACss+a4sAQAA6AAAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAHwAAAAG AAAAhAAAABEAAACMAAAAFwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAAAKwAAAAWAAAAtAAAAA0A AAC8AAAADAAAAMkAAAACAAAA5AQAAB4AAAAEAAAAAAAAAAMAAABTAgAAAwAAAKcAAAADAAAAUUcB AAMAAAAAAA4ACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAAAEAAAAADBAA AAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAMhBAAADAAAAAAAAACAAAAABAAAAOAAAAAIAAABA AAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAAgEEAAFAEAAADAAAAUgBKAAMA AAAlAgAAAwAAAAAAAAADAAAABQAAAB8AAAAWAAAAaAB0AHQAcAA6AC8ALwBkAGkAYwBrAGgAYQBy AGQAdAAuAG8AcgBnAC8AAAAfAAAAAQAAAAAAAAADAAAALwBLAAMAAAAiAgAAAwAAAAAAAAADAAAA BQAAAB8AAAAcAAAAbQBhAGkAbAB0AG8AOgBkAGkAYwBrAC4AaABhAHIAZAB0AEAAZwBtAGEAaQBs AC4AYwBvAG0AAAAfAAAAAQAAAAAAAAADAAAAFQBTAAMAAAAfAgAAAwAAAAAAAAADAAAABQAAAB8A AAAeAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGQAYQB2AGkAZAByAGUAYwBvAHIAZABvAG4ALgBj AG8AbQAvAAAAHwAAAAEAAAAAAAAAAwAAAG0AXQADAAAAHAIAAAMAAAAAAAAAAwAAAAUAAAAfAAAA IgAAAG0AYQBpAGwAdABvADoAZABhAHYAaQBkAHIAZQBjAG8AcgBkAG8AbgBAAGYAYQBjAGUAYgBv AG8AawAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAAH0ANwADAAAAGQIAAAMAAAAAAAAAAwAAAAUA AAAfAAAAFwAAAGgAdAB0AHAAOgAvAC8AaAB1AGUAbgBpAHYAZQByAHMAZQAuAGMAbwBtAC8AAAAA AB8AAAABAAAAAAAAAAMAAABlAFIAAwAAABYCAAADAAAAAAAAAAMAAAAFAAAAHwAAABsAAABtAGEA aQBsAHQAbwA6AGUAcgBhAG4AQABoAHUAZQBuAGkAdgBlAHIAcwBlAC4AYwBvAG0AAAAAAB8AAAAB AAAAAAAAAAMAAAB0AG8AAwAAABMCAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAAQA AAB0AG8AYwAAAAMAAAAuACUAAwAAABACAAADAAAAAAAAAAMAAAAFAAAAHwAAAEMAAABoAHQAdABw ADoALwAvAGQAbwBjAHMALgBvAGEAcwBpAHMALQBvAHAAZQBuAC4AbwByAGcALwBzAGUAYwB1AHIA aQB0AHkALwBzAGEAbQBsAC8AdgAyAC4AMAAvAHMAYQBtAGwALQBjAG8AcgBlAC0AMgAuADAALQBv AHMALgBwAGQAZgAAAAAAHwAAAAEAAAAAAAAAAwAAAGIAAgADAAAADQIAAAMAAAAAAAAAAwAAAAUA AAAfAAAAGQAAAG0AYQBpAGwAdABvADoAZQB2AGUALgBtAGEAbABlAHIAQABzAHUAbgAuAGMAbwBt AAAAAAAfAAAAAQAAAAAAAAADAAAAMwASAAMAAAAKAgAAAwAAAAAAAAADAAAABQAAAB8AAAAhAAAA bQBhAGkAbAB0AG8AOgByAHAAaABpAGwAcABvAHQAdABAAHIAcwBhAHMAZQBjAHUAcgBpAHQAeQAu AGMAbwBtAAAAAAAfAAAAAQAAAAAAAAADAAAASgAxAAMAAAAHAgAAAwAAAAAAAAADAAAABQAAAB8A AAAbAAAAbQBhAGkAbAB0AG8AOgBKAG8AaABuAC4ASwBlAG0AcABAAG4AbwBrAGkAYQAuAGMAbwBt AAAAAAAfAAAAAQAAAAAAAAADAAAAYABXAAMAAAAEAgAAAwAAAAAAAAADAAAABQAAAB8AAAAYAAAA bQBhAGkAbAB0AG8AOgBjAGEAbgB0AG8AcgAuADIAQABvAHMAdQAuAGUAZAB1AAAAHwAAAAEAAAAA AAAAAwAAAHQAbwADAAAAAQIAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAABAAAAHQA bwBjAAAAAwAAACoAMQADAAAA/gEAAAMAAAAAAAAAAwAAAAUAAAAfAAAALwAAAGgAdAB0AHAAOgAv AC8AdwB3AHcALgB3ADMALgBvAHIAZwAvAFQAUgAvADEAOQA5ADkALwBSAEUAQwAtAGgAdABtAGwA NAAwADEALQAxADkAOQA5ADEAMgAyADQAAAAAAB8AAAABAAAAAAAAAAMAAAAqADEAAwAAAPsBAAAD AAAAAAAAAAMAAAAFAAAAHwAAAC8AAABoAHQAdABwADoALwAvAHcAdwB3AC4AdwAzAC4AbwByAGcA LwBUAFIALwAxADkAOQA5AC8AUgBFAEMALQBoAHQAbQBsADQAMAAxAC0AMQA5ADkAOQAxADIAMgA0 AAAAAAAfAAAAAQAAAAAAAAADAAAABABSAAMAAAD4AQAAAwAAAAAAAAADAAAABQAAAB8AAAAqAAAA aAB0AHQAcAA6AC8ALwB3AHcAdwAuAHIAZgBjAC0AZQBkAGkAdABvAHIALgBvAHIAZwAvAHIAZgBj AC8AcgBmAGMANQA4ADQAOQAuAHQAeAB0AAAAHwAAAAEAAAAAAAAAAwAAAGIAJQADAAAA9QEAAAMA AAAAAAAAAwAAAAUAAAAfAAAAIwAAAGgAdAB0AHAAOgAvAC8AdABvAG8AbABzAC4AaQBlAHQAZgAu AG8AcgBnAC8AaAB0AG0AbAAvAHIAZgBjADUAOAA0ADkAAAAAAB8AAAABAAAAAAAAAAMAAAABAFIA AwAAAPIBAAADAAAAAAAAAAMAAAAFAAAAHwAAACoAAABoAHQAdABwADoALwAvAHcAdwB3AC4AcgBm AGMALQBlAGQAaQB0AG8AcgAuAG8AcgBnAC8AcgBmAGMALwByAGYAYwA1ADIANAA2AC4AdAB4AHQA AAAfAAAAAQAAAAAAAAADAAAAYgAgAAMAAADvAQAAAwAAAAAAAAADAAAABQAAAB8AAAAjAAAAaAB0 AHQAcAA6AC8ALwB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcALwBoAHQAbQBsAC8AcgBmAGMA NQAyADQANgAAAAAAHwAAAAEAAAAAAAAAAwAAAAEAVAADAAAA7AEAAAMAAAAAAAAAAwAAAAUAAAAf AAAAKgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgByAGYAYwAtAGUAZABpAHQAbwByAC4AbwByAGcA LwByAGYAYwAvAHIAZgBjADUAMgAyADYALgB0AHgAdAAAAB8AAAABAAAAAAAAAAMAAABkACAAAwAA AOkBAAADAAAAAAAAAAMAAAAFAAAAHwAAACMAAABoAHQAdABwADoALwAvAHQAbwBvAGwAcwAuAGkA ZQB0AGYALgBvAHIAZwAvAGgAdABtAGwALwByAGYAYwA1ADIAMgA2AAAAAAAfAAAAAQAAAAAAAAAD AAAABABVAAMAAADmAQAAAwAAAAAAAAADAAAABQAAAB8AAAAqAAAAaAB0AHQAcAA6AC8ALwB3AHcA dwAuAHIAZgBjAC0AZQBkAGkAdABvAHIALgBvAHIAZwAvAHIAZgBjAC8AcgBmAGMANAA2ADIANwAu AHQAeAB0AAAAHwAAAAEAAAAAAAAAAwAAAGUAJQADAAAA4wEAAAMAAAAAAAAAAwAAAAUAAAAfAAAA IwAAAGgAdAB0AHAAOgAvAC8AdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnAC8AaAB0AG0AbAAv AHIAZgBjADQANgAyADcAAAAAAB8AAAABAAAAAAAAAAMAAAAuAC4AAwAAAOABAAADAAAAAAAAAAMA AAAFAAAAHwAAADMAAABoAHQAdABwADoALwAvAHgAbQBsAC4AcgBlAHMAbwB1AHIAYwBlAC4AbwBy AGcALwBwAHUAYgBsAGkAYwAvAHIAZgBjAC8AeABtAGwALwByAGYAYwAzADkAOAA2AC4AeABtAGwA AAAAAB8AAAABAAAAAAAAAAMAAABBAEEAAwAAAN0BAAADAAAAAAAAAAMAAAAFAAAAHwAAADUAAABo AHQAdABwADoALwAvAHgAbQBsAC4AcgBlAHMAbwB1AHIAYwBlAC4AbwByAGcALwBwAHUAYgBsAGkA YwAvAHIAZgBjAC8AaAB0AG0AbAAvAHIAZgBjADMAOQA4ADYALgBoAHQAbQBsAAAAAAAfAAAAAQAA AAAAAAADAAAACgBYAAMAAADaAQAAAwAAAAAAAAADAAAABQAAAB8AAAAqAAAAaAB0AHQAcAA6AC8A LwB3AHcAdwAuAHIAZgBjAC0AZQBkAGkAdABvAHIALgBvAHIAZwAvAHIAZgBjAC8AcgBmAGMAMwA5 ADgANgAuAHQAeAB0AAAAHwAAAAEAAAAAAAAAAwAAAGgAKwADAAAA1wEAAAMAAAAAAAAAAwAAAAUA AAAfAAAAIwAAAGgAdAB0AHAAOgAvAC8AdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnAC8AaAB0 AG0AbAAvAHIAZgBjADMAOQA4ADYAAAAAAB8AAAABAAAAAAAAAAMAAABYAGcAAwAAANQBAAADAAAA AAAAAAMAAAAFAAAAHwAAABMAAABtAGEAaQBsAHQAbwA6AEwATQBNAEAAYQBjAG0ALgBvAHIAZwAA AAAAHwAAAAEAAAAAAAAAAwAAAA4AMQADAAAA0QEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAGQAAAG0A YQBpAGwAdABvADoAZgBpAGUAbABkAGkAbgBnAEAAZwBiAGkAdgAuAGMAbwBtAAAAAAAfAAAAAQAA AAAAAAADAAAAXQA8AAMAAADOAQAAAwAAAAAAAAADAAAABQAAAB8AAAAUAAAAbQBhAGkAbAB0AG8A OgB0AGkAbQBiAGwAQAB3ADMALgBvAHIAZwAAAB8AAAABAAAAAAAAAAMAAAAKAFIAAwAAAMsBAAAD AAAAAAAAAAMAAAAFAAAAHwAAACoAAABoAHQAdABwADoALwAvAHcAdwB3AC4AcgBmAGMALQBlAGQA aQB0AG8AcgAuAG8AcgBnAC8AcgBmAGMALwByAGYAYwAzADYAMgA5AC4AdAB4AHQAAAAfAAAAAQAA AAAAAAADAAAAYgArAAMAAADIAQAAAwAAAAAAAAADAAAABQAAAB8AAAAjAAAAaAB0AHQAcAA6AC8A LwB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwByAGcALwBoAHQAbQBsAC8AcgBmAGMAMwA2ADIAOQAA AAAAHwAAAAEAAAAAAAAAAwAAAAYAVAADAAAAxQEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAKgAAAGgA dAB0AHAAOgAvAC8AdwB3AHcALgByAGYAYwAtAGUAZABpAHQAbwByAC4AbwByAGcALwByAGYAYwAv AHIAZgBjADMANAA0ADcALgB0AHgAdAAAAB8AAAABAAAAAAAAAAMAAABkACcAAwAAAMIBAAADAAAA AAAAAAMAAAAFAAAAHwAAACMAAABoAHQAdABwADoALwAvAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBv AHIAZwAvAGgAdABtAGwALwByAGYAYwAzADQANAA3AAAAAAAfAAAAAQAAAAAAAAADAAAABgBSAAMA AAC/AQAAAwAAAAAAAAADAAAABQAAAB8AAAAqAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHIAZgBj AC0AZQBkAGkAdABvAHIALgBvAHIAZwAvAHIAZgBjAC8AcgBmAGMAMwAwADIAMwAuAHQAeAB0AAAA HwAAAAEAAAAAAAAAAwAAAGIAJwADAAAAvAEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIwAAAGgAdAB0 AHAAOgAvAC8AdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnAC8AaAB0AG0AbAAvAHIAZgBjADMA MAAyADMAAAAAAB8AAAABAAAAAAAAAAMAAAAFAFMAAwAAALkBAAADAAAAAAAAAAMAAAAFAAAAHwAA ACoAAABoAHQAdABwADoALwAvAHcAdwB3AC4AcgBmAGMALQBlAGQAaQB0AG8AcgAuAG8AcgBnAC8A cgBmAGMALwByAGYAYwAyADgAMgA4AC4AdAB4AHQAAAAfAAAAAQAAAAAAAAADAAAAYwAkAAMAAAC2 AQAAAwAAAAAAAAADAAAABQAAAB8AAAAjAAAAaAB0AHQAcAA6AC8ALwB0AG8AbwBsAHMALgBpAGUA dABmAC4AbwByAGcALwBoAHQAbQBsAC8AcgBmAGMAMgA4ADIAOAAAAAAAHwAAAAEAAAAAAAAAAwAA AAUAUAADAAAAswEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAKgAAAGgAdAB0AHAAOgAvAC8AdwB3AHcA LgByAGYAYwAtAGUAZABpAHQAbwByAC4AbwByAGcALwByAGYAYwAvAHIAZgBjADIAOAAxADgALgB0 AHgAdAAAAB8AAAABAAAAAAAAAAMAAABgACQAAwAAALABAAADAAAAAAAAAAMAAAAFAAAAHwAAACMA AABoAHQAdABwADoALwAvAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwAvAGgAdABtAGwALwBy AGYAYwAyADgAMQA4AAAAAAAfAAAAAQAAAAAAAAADAAAAJgAgAAMAAACtAQAAAwAAAAAAAAADAAAA BQAAAB8AAAAzAAAAaAB0AHQAcAA6AC8ALwB4AG0AbAAuAHIAZQBzAG8AdQByAGMAZQAuAG8AcgBn AC8AcAB1AGIAbABpAGMALwByAGYAYwAvAHgAbQBsAC8AcgBmAGMAMgA2ADEANwAuAHgAbQBsAAAA AAAfAAAAAQAAAAAAAAADAAAATwBJAAMAAACqAQAAAwAAAAAAAAADAAAABQAAAB8AAAA1AAAAaAB0 AHQAcAA6AC8ALwB4AG0AbAAuAHIAZQBzAG8AdQByAGMAZQAuAG8AcgBnAC8AcAB1AGIAbABpAGMA LwByAGYAYwAvAGgAdABtAGwALwByAGYAYwAyADYAMQA3AC4AaAB0AG0AbAAAAAAAHwAAAAEAAAAA AAAAAwAAAAQAUAADAAAApwEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAKgAAAGgAdAB0AHAAOgAvAC8A dwB3AHcALgByAGYAYwAtAGUAZABpAHQAbwByAC4AbwByAGcALwByAGYAYwAvAHIAZgBjADIANgAx ADcALgB0AHgAdAAAAB8AAAABAAAAAAAAAAMAAABgACUAAwAAAKQBAAADAAAAAAAAAAMAAAAFAAAA HwAAACMAAABoAHQAdABwADoALwAvAHQAbwBvAGwAcwAuAGkAZQB0AGYALgBvAHIAZwAvAGgAdABt AGwALwByAGYAYwAyADYAMQA3AAAAAAAfAAAAAQAAAAAAAAADAAAAeABQAAMAAAChAQAAAwAAAAAA AAADAAAABQAAAB8AAAAeAAAAbQBhAGkAbAB0AG8AOgBzAHQAZQB3AGEAcgB0AEAATwBwAGUAbgBN AGEAcgBrAGUAdAAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAADsABAADAAAAngEAAAMAAAAAAAAA AwAAAAUAAAAfAAAAHAAAAG0AYQBpAGwAdABvADoAcABhAHUAbABsAGUAQABtAGkAYwByAG8AcwBv AGYAdAAuAGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAADgAGQADAAAAmwEAAAMAAAAAAAAAAwAAAAUA AAAfAAAAHAAAAG0AYQBpAGwAdABvADoAbABhAHcAcgBlAG4AYwBlAEAAYQBnAHIAYQBuAGEAdAAu AGMAbwBtAAAAHwAAAAEAAAAAAAAAAwAAAFoAaAADAAAAmAEAAAMAAAAAAAAAAwAAAAUAAAAfAAAA GgAAAG0AYQBpAGwAdABvADoAagBlAGYAZgBAAEEAYgBpAFMAbwB1AHIAYwBlAC4AYwBvAG0AAAAf AAAAAQAAAAAAAAADAAAAYABTAAMAAACVAQAAAwAAAAAAAAADAAAABQAAAB8AAAAbAAAAbQBhAGkA bAB0AG8AOgBwAGIAYQBrAGUAcgBAAHYAZQByAGkAcwBpAGcAbgAuAGMAbwBtAAAAAAAfAAAAAQAA AAAAAAADAAAAQQAiAAMAAACSAQAAAwAAAAAAAAADAAAABQAAAB8AAAAZAAAAbQBhAGkAbAB0AG8A OgBqAG8AaABuAEAAbQBhAHQAaAAuAG4AdwB1AC4AZQBkAHUAAAAAAB8AAAABAAAAAAAAAAMAAAAm ACEAAwAAAI8BAAADAAAAAAAAAAMAAAAFAAAAHwAAADMAAABoAHQAdABwADoALwAvAHgAbQBsAC4A cgBlAHMAbwB1AHIAYwBlAC4AbwByAGcALwBwAHUAYgBsAGkAYwAvAHIAZgBjAC8AeABtAGwALwBy AGYAYwAyADYAMQA2AC4AeABtAGwAAAAAAB8AAAABAAAAAAAAAAMAAABOAEkAAwAAAIwBAAADAAAA AAAAAAMAAAAFAAAAHwAAADUAAABoAHQAdABwADoALwAvAHgAbQBsAC4AcgBlAHMAbwB1AHIAYwBl AC4AbwByAGcALwBwAHUAYgBsAGkAYwAvAHIAZgBjAC8AaAB0AG0AbAAvAHIAZgBjADIANgAxADYA LgBoAHQAbQBsAAAAAAAfAAAAAQAAAAAAAAADAAAAAQBMAAMAAACJAQAAAwAAAAAAAAADAAAABQAA AB8AAAAqAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHIAZgBjAC0AZQBkAGkAdABvAHIALgBvAHIA ZwAvAHIAZgBjAC8AcgBmAGMAMgA2ADEANgAuAHAAZABmAAAAHwAAAAEAAAAAAAAAAwAAAAEAWwAD AAAAhgEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAKQAAAGgAdAB0AHAAOgAvAC8AdwB3AHcALgByAGYA YwAtAGUAZABpAHQAbwByAC4AbwByAGcALwByAGYAYwAvAHIAZgBjADIANgAxADYALgBwAHMAAAAA AB8AAAABAAAAAAAAAAMAAAAFAFAAAwAAAIMBAAADAAAAAAAAAAMAAAAFAAAAHwAAACoAAABoAHQA dABwADoALwAvAHcAdwB3AC4AcgBmAGMALQBlAGQAaQB0AG8AcgAuAG8AcgBnAC8AcgBmAGMALwBy AGYAYwAyADYAMQA2AC4AdAB4AHQAAAAfAAAAAQAAAAAAAAADAAAAYAAkAAMAAACAAQAAAwAAAAAA AAADAAAABQAAAB8AAAAjAAAAaAB0AHQAcAA6AC8ALwB0AG8AbwBsAHMALgBpAGUAdABmAC4AbwBy AGcALwBoAHQAbQBsAC8AcgBmAGMAMgA2ADEANgAAAAAAHwAAAAEAAAAAAAAAAwAAAF0APAADAAAA fQEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAFAAAAG0AYQBpAGwAdABvADoAdABpAG0AYgBsAEAAdwAz AC4AbwByAGcAAAAfAAAAAQAAAAAAAAADAAAAOwAEAAMAAAB6AQAAAwAAAAAAAAADAAAABQAAAB8A AAAcAAAAbQBhAGkAbAB0AG8AOgBwAGEAdQBsAGwAZQBAAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBv AG0AAAAfAAAAAQAAAAAAAAADAAAAIwBJAAMAAAB3AQAAAwAAAAAAAAADAAAABQAAAB8AAAAfAAAA bQBhAGkAbAB0AG8AOgBtAGEAcwBpAG4AdABlAHIAQABwAGEAcgBjAC4AeABlAHIAbwB4AC4AYwBv AG0AAAAAAB8AAAABAAAAAAAAAAMAAAAuAEkAAwAAAHQBAAADAAAAAAAAAAMAAAAFAAAAHwAAABYA AABtAGEAaQBsAHQAbwA6AGYAcgB5AHMAdAB5AGsAQAB3ADMALgBvAHIAZwAAAB8AAAABAAAAAAAA AAMAAABoABYAAwAAAHEBAAADAAAAAAAAAAMAAAAFAAAAHwAAABkAAABtAGEAaQBsAHQAbwA6AG0A bwBnAHUAbABAAHcAcgBsAC4AZABlAGMALgBjAG8AbQAAAAAAHwAAAAEAAAAAAAAAAwAAAAYAcwAD AAAAbgEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAEQAAAG0AYQBpAGwAdABvADoAagBnAEAAdwAzAC4A bwByAGcAAAAAAB8AAAABAAAAAAAAAAMAAAAiAE8AAwAAAGsBAAADAAAAAAAAAAMAAAAFAAAAHwAA ABwAAABtAGEAaQBsAHQAbwA6AGYAaQBlAGwAZABpAG4AZwBAAGkAYwBzAC4AdQBjAGkALgBlAGQA dQAAAB8AAAABAAAAAAAAAAMAAAAmACkAAwAAAGgBAAADAAAAAAAAAAMAAAAFAAAAHwAAADMAAABo AHQAdABwADoALwAvAHgAbQBsAC4AcgBlAHMAbwB1AHIAYwBlAC4AbwByAGcALwBwAHUAYgBsAGkA YwAvAHIAZgBjAC8AeABtAGwALwByAGYAYwAyADEAMQA5AC4AeABtAGwAAAAAAB8AAAABAAAAAAAA AAMAAABGAEkAAwAAAGUBAAADAAAAAAAAAAMAAAAFAAAAHwAAADUAAABoAHQAdABwADoALwAvAHgA bQBsAC4AcgBlAHMAbwB1AHIAYwBlAC4AbwByAGcALwBwAHUAYgBsAGkAYwAvAHIAZgBjAC8AaAB0 AG0AbAAvAHIAZgBjADIAMQAxADkALgBoAHQAbQBsAAAAAAAfAAAAAQAAAAAAAAADAAAADQBQAAMA AABiAQAAAwAAAAAAAAADAAAABQAAAB8AAAAqAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAHIAZgBj AC0AZQBkAGkAdABvAHIALgBvAHIAZwAvAHIAZgBjAC8AcgBmAGMAMgAxADEAOQAuAHQAeAB0AAAA HwAAAAEAAAAAAAAAAwAAAGAALAADAAAAXwEAAAMAAAAAAAAAAwAAAAUAAAAfAAAAIwAAAGgAdAB0 AHAAOgAvAC8AdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnAC8AaAB0AG0AbAAvAHIAZgBjADIA MQAxADkAAAAAAB8AAAABAAAAAAAAAAMAAABKAHwAAwAAAFwBAAADAAAAAAAAAAMAAAAFAAAAHwAA ABcAAABtAGEAaQBsAHQAbwA6AHMAbwBiAEAAaABhAHIAdgBhAHIAZAAuAGUAZAB1AAAAAAAfAAAA AQAAAAAAAAADAAAAAABVAAMAAABZAQAAAwAAAAAAAAADAAAABQAAAB8AAAAqAAAAaAB0AHQAcAA6 AC8ALwB3AHcAdwAuAHIAZgBjAC0AZQBkAGkAdABvAHIALgBvAHIAZwAvAHIAZgBjAC8AcgBmAGMA MgAwADQANQAuAHQAeAB0AAAAHwAAAAEAAAAAAAAAAwAAAGUAIQADAAAAVgEAAAMAAAAAAAAAAwAA AAUAAAAfAAAAIwAAAGgAdAB0AHAAOgAvAC8AdABvAG8AbABzAC4AaQBlAHQAZgAuAG8AcgBnAC8A aAB0AG0AbAAvAHIAZgBjADIAMAA0ADUAAAAAAB8AAAABAAAAAAAAAAMAAAAxAEUAAwAAAFMBAAAD AAAAAAAAAAMAAAAFAAAAHwAAABYAAABtAGEAaQBsAHQAbwA6AG4AcwBiAEAAbgBzAGIALgBmAHYA LgBjAG8AbQAAAB8AAAABAAAAAAAAAAMAAAAWADsAAwAAAFABAAADAAAAAAAAAAMAAAAFAAAAHwAA ABgAAABtAGEAaQBsAHQAbwA6AG4AZQBkAEAAaQBuAG4AbwBzAG8AZgB0AC4AYwBvAG0AAAAfAAAA AQAAAAAAAAADAAAAPABrAAMAAABNAQAAAwAAAAAAAAADAAAABQAAAB8AAABLAAAAaAB0AHQAcAA6 AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBvAHIAZwAvAGkAbgB0AGUAcgBuAGUAdAAtAGQAcgBhAGYA dABzAC8AZAByAGEAZgB0AC0AaQBlAHQAZgAtAGgAdAB0AHAAYgBpAHMALQBwADEALQBtAGUAcwBz AGEAZwBpAG4AZwAtADAAOQAuAHQAeAB0AAAAAAAfAAAAAQAAAAAAAAADAAAAPABrAAMAAABKAQAA AwAAAAAAAAADAAAABQAAAB8AAABLAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGkAZQB0AGYALgBv AHIAZwAvAGkAbgB0AGUAcgBuAGUAdAAtAGQAcgBhAGYAdABzAC8AZAByAGEAZgB0AC0AaQBlAHQA ZgAtAGgAdAB0AHAAYgBpAHMALQBwADEALQBtAGUAcwBzAGEAZwBpAG4AZwAtADAAOQAuAHQAeAB0 AAAAAAAfAAAAAQAAAAAAAAADAAAAdABvAAMAAABHAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAA AAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAABEAQAAAwAAAAAAAAADAAAABQAAAB8AAAAB AAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAABBAQAAAwAAAAAAAAADAAAABQAAAB8A AAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAA+AQAAAwAAAAAAAAADAAAABQAA AB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAA7AQAAAwAAAAAAAAADAAAA BQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAA4AQAAAwAAAAAAAAAD AAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAA1AQAAAwAAAAAA AAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAAyAQAAAwAA AAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAAvAQAA AwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAAs AQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMA AAApAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABv AAMAAAAmAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAA dABvAAMAAAAjAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAAD AAAAdABvAAMAAAAgAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMA AAADAAAAdABvAAMAAAAdAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABv AGMAAAADAAAAdABvAAMAAAAaAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAA dABvAGMAAAADAAAAdABvAAMAAAAXAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAE AAAAdABvAGMAAAADAAAAdABvAAMAAAAUAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8A AAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAARAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAA AB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAAOAQAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAA AAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAALAQAAAwAAAAAAAAADAAAABQAAAB8AAAAB AAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAAIAQAAAwAAAAAAAAADAAAABQAAAB8A AAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAAFAQAAAwAAAAAAAAADAAAABQAA AB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAACAQAAAwAAAAAAAAADAAAA BQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAD/AAAAAwAAAAAAAAAD AAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAD8AAAAAwAAAAAA AAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAD5AAAAAwAA AAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAD2AAAA AwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADz AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMA AADwAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABv AAMAAADtAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAA dABvAAMAAADqAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAAD AAAAdABvAAMAAADnAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMA AAADAAAAdABvAAMAAADkAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABv AGMAAAADAAAAdABvAAMAAADhAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAA dABvAGMAAAADAAAAdABvAAMAAADeAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAE AAAAdABvAGMAAAADAAAAdABvAAMAAADbAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8A AAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADYAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAA AB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADVAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAA AAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADSAAAAAwAAAAAAAAADAAAABQAAAB8AAAAB AAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADPAAAAAwAAAAAAAAADAAAABQAAAB8A AAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADMAAAAAwAAAAAAAAADAAAABQAA AB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADJAAAAAwAAAAAAAAADAAAA BQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADGAAAAAwAAAAAAAAAD AAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADDAAAAAwAAAAAA AAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAADAAAAAAwAA AAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAC9AAAA AwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMAAAC6 AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABvAAMA AAC3AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAAdABv AAMAAAC0AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAADAAAA dABvAAMAAACxAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAAD AAAAdABvAAMAAACuAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMA AAADAAAAdABvAAMAAACrAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABv AGMAAAADAAAAawAnAAMAAACoAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAMAAAA cgBmAGMALgBhAHUAdABoAG8AcgBzAAAAAwAAAHwAPQADAAAApQAAAAMAAAAAAAAAAwAAAAUAAAAf AAAAAQAAAAAAAAAfAAAAEAAAAHIAZgBjAC4AcgBlAGYAZQByAGUAbgBjAGUAcwAyAAAAAwAAAHwA PQADAAAAogAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAAEAAAAHIAZgBjAC4AcgBl AGYAZQByAGUAbgBjAGUAcwAxAAAAAwAAAHwAPQADAAAAnwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA AQAAAAAAAAAfAAAAEAAAAHIAZgBjAC4AcgBlAGYAZQByAGUAbgBjAGUAcwAxAAAAAwAAAF4AQAAD AAAAnAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACQAAAGEAbgBjAGgAbwByADMA NAAAAAAAAwAAAF4ARwADAAAAmQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACQAA AGEAbgBjAGgAbwByADMAMwAAAAAAAwAAAF4ARgADAAAAlgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA AQAAAAAAAAAfAAAACQAAAGEAbgBjAGgAbwByADMAMgAAAAAAAwAAAF4ARQADAAAAkwAAAAMAAAAA AAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACQAAAGEAbgBjAGgAbwByADMAMQAAAAAAAwAAAF4A RAADAAAAkAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACQAAAGEAbgBjAGgAbwBy ADMAMAAAAAAAAwAAAF8ATQADAAAAjQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAA CQAAAGEAbgBjAGgAbwByADIAOQAAAAAAAwAAADwAZwADAAAAigAAAAMAAAAAAAAAAwAAAAUAAAAf AAAAAQAAAAAAAAAfAAAAFAAAAHAAYQByAGEAbQBlAHQAZQByAHMALQByAGUAZwBpAHMAdAByAHkA AAADAAAAXwBMAAMAAACHAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAJAAAAYQBu AGMAaABvAHIAMgA4AAAAAAADAAAAXwBDAAMAAACEAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAA AAAAAB8AAAAJAAAAYQBuAGMAaABvAHIAMgA3AAAAAAADAAAAXwBCAAMAAACBAAAAAwAAAAAAAAAD AAAABQAAAB8AAAABAAAAAAAAAB8AAAAJAAAAYQBuAGMAaABvAHIAMgA2AAAAAAADAAAAXwBBAAMA AAB+AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAJAAAAYQBuAGMAaABvAHIAMgA1 AAAAAAADAAAAXwBAAAMAAAB7AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAJAAAA YQBuAGMAaABvAHIAMgA0AAAAAAADAAAAXwBHAAMAAAB4AAAAAwAAAAAAAAADAAAABQAAAB8AAAAB AAAAAAAAAB8AAAAJAAAAYQBuAGMAaABvAHIAMgAzAAAAAAADAAAAXwBGAAMAAAB1AAAAAwAAAAAA AAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAJAAAAYQBuAGMAaABvAHIAMgAyAAAAAAADAAAAAAAM AAMAAAByAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAVAAAAcgBlAHMAbwB1AHIA YwBlAC0AZQByAHIAbwByAC0AYwBvAGQAZQBzAAAAAAADAAAAFwBDAAMAAABvAAAAAwAAAAAAAAAD AAAABQAAAB8AAAABAAAAAAAAAB8AAAANAAAAYQB1AHQAaABuAC0AaABlAGEAZABlAHIAAAAAAAMA AAB1ADsAAwAAAGwAAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAAwAAAB0AG8AawBl AG4ALQB0AHkAcABlAHMAAAADAAAAJABiAAMAAABpAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAA AAAAAB8AAAAQAAAAYQBjAGMAZQBzAHMALQByAGUAcwBvAHUAcgBjAGUAAAADAAAAEwAdAAMAAABm AAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAASAAAAdABvAGsAZQBuAC0AZQByAHIA bwByAC0AYwBvAGQAZQBzAAAAAwAAAGYAOgADAAAAYwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAA AAAAAAAfAAAADAAAAHQAbwBrAGUAbgAtAGUAcgByAG8AcgAAAAMAAAAAABkAAwAAAGAAAAADAAAA AAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAABYAAABhAGMAYwBlAHMAcwAtAHQAbwBrAGUAbgAt AHIAZQBzAHAAbwBuAHMAZQAAAAMAAABfAEUAAwAAAF0AAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEA AAAAAAAAHwAAAAkAAABhAG4AYwBoAG8AcgAyADEAAAAAAAMAAAAAAEMAAwAAAFoAAAADAAAAAAAA AAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAA4AAAB0AG8AawBlAG4ALQByAGUAZgByAGUAcwBoAAAA AwAAAF8ARAADAAAAVwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACQAAAGEAbgBj AGgAbwByADIAMAAAAAAAAwAAAFwATQADAAAAVAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAA AAAfAAAACQAAAGEAbgBjAGgAbwByADEAOQAAAAAAAwAAAGIAfAADAAAAUQAAAAMAAAAAAAAAAwAA AAUAAAAfAAAAAQAAAAAAAAAfAAAAEAAAAGMAbwBkAGUALQBnAHIAYQBuAHQALQB0AHkAcABlAAAA AwAAAHEAcAADAAAATgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAAEwAAAGEAYwBj AGUAcwBzAC0AZwByAGEAbgB0AC0AdAB5AHAAZQBzAAAAAAADAAAAYwAkAAMAAABLAAAAAwAAAAAA AAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAQAAAAbwBiAHQAYQBpAG4AaQBuAGcALQB0AG8AawBl AG4AAAADAAAAAgAMAAMAAABIAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAARAAAA YQB1AHQAaAAtAGUAcgByAG8AcgAtAGMAbwBkAGUAcwAAAAAAAwAAACUAeAADAAAARQAAAAMAAAAA AAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACwAAAGEAdQB0AGgALQBlAHIAcgBvAHIAAAAAAAMA AABcAEwAAwAAAEIAAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAAkAAABhAG4AYwBo AG8AcgAxADgAAAAAAAMAAABcAEMAAwAAAD8AAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAA HwAAAAkAAABhAG4AYwBoAG8AcgAxADcAAAAAAAMAAAAzAHQAAwAAADwAAAADAAAAAAAAAAMAAAAF AAAAHwAAAAEAAAAAAAAAHwAAABMAAAB1AHMAZQByAC0AYQB1AHQAaABvAHIAaQB6AGEAdABpAG8A bgAAAAAAAwAAAFwAQgADAAAAOQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACQAA AGEAbgBjAGgAbwByADEANgAAAAAAAwAAAFwAQQADAAAANgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAA AQAAAAAAAAAfAAAACQAAAGEAbgBjAGgAbwByADEANQAAAAAAAwAAAFsAAQADAAAAMwAAAAMAAAAA AAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAAFgAAAGMAbABpAGUAbgB0AC0AYQB1AHQAaABlAG4A dABpAGMAYQB0AGkAbwBuAAAAAwAAAFwAQAADAAAAMAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAA AAAAAAAfAAAACQAAAGEAbgBjAGgAbwByADEANAAAAAAAAwAAAFwARwADAAAALQAAAAMAAAAAAAAA AwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACQAAAGEAbgBjAGgAbwByADEAMwAAAAAAAwAAADQAcQAD AAAAKgAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACwAAAHUAcwBlAHIALQBhAGcA ZQBuAHQAAAAAAAMAAABcAEYAAwAAACcAAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAA AAkAAABhAG4AYwBoAG8AcgAxADIAAAAAAAMAAABcAEUAAwAAACQAAAADAAAAAAAAAAMAAAAFAAAA HwAAAAEAAAAAAAAAHwAAAAkAAABhAG4AYwBoAG8AcgAxADEAAAAAAAMAAABcAEQAAwAAACEAAAAD AAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAAkAAABhAG4AYwBoAG8AcgAxADAAAAAAAAMA AABtAHQAAwAAAB4AAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAAgAAABhAG4AYwBo AG8AcgA5AAAAAwAAAG0AdAADAAAAGwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAA CAAAAGEAbgBjAGgAbwByADgAAAADAAAAbQB0AAMAAAAYAAAAAwAAAAAAAAADAAAABQAAAB8AAAAB AAAAAAAAAB8AAAAIAAAAYQBuAGMAaABvAHIANwAAAAMAAABtAHQAAwAAABUAAAADAAAAAAAAAAMA AAAFAAAAHwAAAAEAAAAAAAAAHwAAAAgAAABhAG4AYwBoAG8AcgA2AAAAAwAAAG0AdAADAAAAEgAA AAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAAAAAAAAAfAAAACAAAAGEAbgBjAGgAbwByADUAAAADAAAA bQB0AAMAAAAPAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAIAAAAYQBuAGMAaABv AHIANAAAAAMAAABtAHQAAwAAAAwAAAADAAAAAAAAAAMAAAAFAAAAHwAAAAEAAAAAAAAAHwAAAAgA AABhAG4AYwBoAG8AcgAzAAAAAwAAAG0AdAADAAAACQAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAAQAA AAAAAAAfAAAACAAAAGEAbgBjAGgAbwByADIAAAADAAAAbQB0AAMAAAAGAAAAAwAAAAAAAAADAAAA BQAAAB8AAAABAAAAAAAAAB8AAAAIAAAAYQBuAGMAaABvAHIAMQAAAAMAAABiACUAAwAAAAMAAAAD AAAAAAAAAAMAAAAFAAAAHwAAACMAAABoAHQAdABwADoALwAvAHQAbwBvAGwAcwAuAGkAZQB0AGYA LgBvAHIAZwAvAGgAdABtAGwALwByAGYAYwA1ADgANAA5AAAAAAAfAAAAAQAAAAAAAAADAAAAdABv AAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8AAAABAAAAAAAAAB8AAAAEAAAAdABvAGMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAG AAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQA AAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAA ACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA MQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/ AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0A AABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABUAAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAA AFwAAABdAAAAXgAAAF8AAABgAAAAYQAAAGIAAABjAAAAZAAAAGUAAABmAAAAZwAAAGgAAABpAAAA agAAAGsAAABsAAAAbQAAAG4AAABvAAAAcAAAAHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4 AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAAfwAAAIAAAACBAAAAggAAAIMAAACEAAAAhQAAAIYA AACHAAAAiAAAAIkAAACKAAAAiwAAAIwAAACNAAAAjgAAAI8AAACQAAAAkQAAAJIAAACTAAAAlAAA AJUAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsAAACcAAAAnQAAAJ4AAACfAAAAoAAAAKEAAACiAAAA owAAAKQAAAClAAAApgAAAKcAAACoAAAAqQAAAKoAAACrAAAArAAAAK0AAACuAAAArwAAALAAAACx AAAAsgAAALMAAAC0AAAAtQAAALYAAAC3AAAAuAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8A AADAAAAAwQAAAMIAAADDAAAAxAAAAMUAAADGAAAAxwAAAMgAAADJAAAAygAAAMsAAADMAAAAzQAA AM4AAADPAAAA0AAAANEAAADSAAAA0wAAANQAAADVAAAA1gAAANcAAADYAAAA2QAAANoAAADbAAAA 3AAAAN0AAADeAAAA3wAAAOAAAADhAAAA4gAAAOMAAADkAAAA5QAAAOYAAADnAAAA6AAAAOkAAADq AAAA6wAAAOwAAADtAAAA7gAAAO8AAADwAAAA8QAAAPIAAADzAAAA9AAAAPUAAAD2AAAA9wAAAPgA AAD5AAAA+gAAAPsAAAD8AAAA/QAAAP4AAAD/AAAAAAEAAAEBAAACAQAAAwEAAAQBAAAFAQAABgEA AAcBAAAIAQAACQEAAAoBAAALAQAADAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAA FQEAABYBAAAXAQAAGAEAABkBAAAaAQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAAIQEAACIBAAAj AQAAJAEAACUBAAAmAQAAJwEAACgBAAApAQAAKgEAACsBAAAsAQAALQEAAC4BAAAvAQAAMAEAADEB AAAyAQAAMwEAADQBAAA1AQAANgEAADcBAAA4AQAAOQEAADoBAAA7AQAAPAEAAD0BAAA+AQAAPwEA AEABAABBAQAAQgEAAEMBAABEAQAARQEAAEYBAABHAQAASAEAAEkBAABKAQAASwEAAEwBAABNAQAA TgEAAE8BAABQAQAAUQEAAFIBAABTAQAAVAEAAFUBAABWAQAAVwEAAFgBAABZAQAAWgEAAFsBAABc AQAAXQEAAF4BAABfAQAAYAEAAGEBAABiAQAAYwEAAGQBAABlAQAAZgEAAGcBAABoAQAAaQEAAGoB AABrAQAAbAEAAG0BAABuAQAAbwEAAHABAABxAQAAcgEAAHMBAAB0AQAAdQEAAHYBAAB3AQAAeAEA AHkBAAB6AQAAewEAAHwBAAB9AQAAfgEAAH8BAACAAQAAgQEAAIIBAAD+////hAEAAIUBAACGAQAA hwEAAIgBAACJAQAAigEAAIsBAACMAQAAjQEAAI4BAACPAQAAkAEAAJEBAACSAQAAkwEAAJQBAACV AQAAlgEAAJcBAACYAQAAmQEAAJoBAACbAQAAnAEAAJ0BAACeAQAAnwEAAKABAAChAQAAogEAAKMB AACkAQAApQEAAKYBAACnAQAAqAEAAKkBAACqAQAAqwEAAKwBAACtAQAArgEAAK8BAACwAQAAsQEA ALIBAAD+////tAEAALUBAAC2AQAAtwEAALgBAAC5AQAAugEAALsBAAC8AQAAvQEAAL4BAAC/AQAA wAEAAMEBAADCAQAAwwEAAMQBAADFAQAAxgEAAMcBAADIAQAAyQEAAMoBAADLAQAAzAEAAM0BAADO AQAAzwEAANABAADRAQAA0gEAANMBAADUAQAA1QEAANYBAADXAQAA2AEAANkBAADaAQAA2wEAANwB AADdAQAA3gEAAN8BAADgAQAA4QEAAOIBAADjAQAA5AEAAOUBAADmAQAA5wEAAOgBAADpAQAA6gEA AOsBAADsAQAA7QEAAO4BAADvAQAA8AEAAPEBAADyAQAA8wEAAPQBAAD1AQAA9gEAAPcBAAD4AQAA +QEAAPoBAAD7AQAA/AEAAP0BAAD+AQAA/wEAAAACAAABAgAAAgIAAAMCAAAEAgAABQIAAAYCAAAH AgAACAIAAAkCAAAKAgAACwIAAAwCAAANAgAADgIAAA8CAAAQAgAAEQIAABICAAATAgAAFAIAABUC AAAWAgAAFwIAABgCAAAZAgAAGgIAABsCAAAcAgAAHQIAAB4CAAAfAgAAIAIAACECAAAiAgAAIwIA AP7///8lAgAAJgIAACcCAAAoAgAAKQIAACoCAAArAgAA/v///y0CAAAuAgAALwIAADACAAAxAgAA MgIAADMCAAA0AgAANQIAADYCAAA3AgAAOAIAADkCAAA6AgAAOwIAADwCAAA9AgAAPgIAAD8CAABA AgAAQQIAAEICAABDAgAARAIAAEUCAABGAgAARwIAAEgCAABJAgAASgIAAEsCAABMAgAATQIAAP7/ ///9/////f////3////9/////f///1QCAABVAgAA/v////7///9YAgAA/v////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkC AAAAAADAAAAAAAAARgAAAAAAAAAAAAAAAGDOPm7DscsBVwIAAAADAAAAAAAARABhAHQAYQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACDAQAAFF4AAAAA AAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAADgACAAEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAALMBAAAt4QAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBCgAAAAUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4EAwAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBt AGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkAgAAABAAAAAAAAAFAEQAbwBjAHUAbQBl AG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAQQA AAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwCAAD0QgAAAAAA AE0AcwBvAEQAYQB0AGEAUwB0AG8AcgBlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAaAAEA//////////8HAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgjC9uw7HLAZDSPG7D scsBAAAAAAAAAAAAAAAAzwDFAMYA3QAxAEgAwADVAFgAVQBXAMAA3wBUADQAwwBOAEEAWgBMADQA UQA9AD0AAAAAAAAAAAAAAAAAAAAAADIAAQH//////////wgAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ACCML27DscsBkNI8bsOxywEAAAAAAAAAAAAAAABJAHQAZQBtAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAf////8JAAAA/////wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADYAAAAAAAAAFAAcgBvAHAAZQByAHQA aQBlAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAIA//// ////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAFUBAAAAAAAA AQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABIAAgECAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAKAAAAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAP7///8FAAAABgAAAAcAAAAI AAAACQAAAP7///8LAAAA/v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////PGI6U291cmNlcyBTZWxlY3RlZFN0eWxlPSJcQVBB LlhTTCIgU3R5bGVOYW1lPSJBUEEiIHhtbG5zOmI9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3Jt YXRzLm9yZy9vZmZpY2VEb2N1bWVudC8yMDA2L2JpYmxpb2dyYXBoeSIgeG1sbnM9Imh0dHA6Ly9z Y2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9vZmZpY2VEb2N1bWVudC8yMDA2L2JpYmxpb2dyYXBo eSI+PC9iOlNvdXJjZXM+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADw/ eG1sIHZlcnNpb249IjEuMCIgZW5jb2Rpbmc9IlVURi04IiBzdGFuZGFsb25lPSJubyI/Pg0KPGRz OmRhdGFzdG9yZUl0ZW0gZHM6aXRlbUlEPSJ7NkNCRDU5QkUtMzU3OC00NTVELUEwRkQtMzdBMzM0 MDY0Qjc5fSIgeG1sbnM6ZHM9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9vZmZp Y2VEb2N1bWVudC8yMDA2L2N1c3RvbVhtbCI+PGRzOnNjaGVtYVJlZnM+PGRzOnNjaGVtYVJlZiBk czp1cmk9Imh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3JtYXRzLm9yZy9vZmZpY2VEb2N1bWVudC8y MDA2L2JpYmxpb2dyYXBoeSIvPjwvZHM6c2NoZW1hUmVmcz48L2RzOmRhdGFzdG9yZUl0ZW0+AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA/v8DCgAA/////wYJAgAA AAAAwAAAAAAAAEYgAAAATWljcm9zb2Z0IFdvcmQgOTctMjAwMyBEb2N1bWVudAAKAAAATVNXb3Jk RG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --_004_4E1F6AAD24975D4BA5B1680429673943246DF492TK5EX14MBXC202r_-- From beaton@google.com Tue Jan 11 11:51:21 2011 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 ABCB13A6A96 for ; Tue, 11 Jan 2011 11:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjt6SnLpIPJe for ; Tue, 11 Jan 2011 11:51:18 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 92CD63A67D2 for ; Tue, 11 Jan 2011 11:51:17 -0800 (PST) Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p0BJrY0d024115 for ; Tue, 11 Jan 2011 11:53:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294775614; bh=kk54Ep6geRtL3DQ6aDYLlSvaP/I=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=Bj8ZWBoQwVwlriLBSTIVPSYUaKROAqPmRW/ghHFB7OQAwbFP0NFdhmcM+UWBe3lD6 pZRGHiqZOKH0EMv/O/GCA== Received: from pzk12 (pzk12.prod.google.com [10.243.19.140]) by kpbe14.cbf.corp.google.com with ESMTP id p0BJrCkw021905 for ; Tue, 11 Jan 2011 11:53:33 -0800 Received: by pzk12 with SMTP id 12so4447702pzk.20 for ; Tue, 11 Jan 2011 11:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Yc/9E6T0W9+v38+TL8wcuM3vzdw8/chyNATPy5Igmi8=; b=Li9t0AmWskQcqKOJVyEEeFKlygz6DEEt3NMdKe/aFNrYCjEjXt/KZOsHuW7JATS/F8 KeqYaFPaAm/UO/aCxliA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rgzixPn55stmTdmbHod/CFp1ttZL1h960FiWt1d1ppTL1NmsVOL6gtPTrVCqpYW8aY xc1X7xSXDS1OwifUdbFQ== MIME-Version: 1.0 Received: by 10.142.115.6 with SMTP id n6mr173407wfc.169.1294775612730; Tue, 11 Jan 2011 11:53:32 -0800 (PST) Received: by 10.142.213.7 with HTTP; Tue, 11 Jan 2011 11:53:32 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 11 Jan 2011 11:53:32 -0800 Message-ID: From: Brian Eaton 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] Proposal to drop/relocate response_type=code_and_token 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, 11 Jan 2011 19:51:21 -0000 On Mon, Jan 10, 2011 at 3:42 PM, Eran Hammer-Lahav wr= ote: > These are two very different client profiles. In one, the client is compl= etely authenticated, residing solely in the user-agent. The other is a mix = authenticated and unauthenticated, where parts of the client can keep a sec= rets but others can't. > > Being able to keep a secret is the primary differentiator when picking wh= ich profile to use. I agree that the hybrid one is an optimization of the w= eb-server profile (removing the need to wait for the server to send a token= back to the user-agent after exchanging the code). But that only means the= code_and_token really belongs with the web-server profile than with the us= er-agent. The two paragraphs above didn't make sense to me. Once you have the hybrid flow, it meets all of the use cases that the user-agent flow was trying to solve. The hybrid flow is more powerful, and has the same or better security characteristics. So the sensible thing to do is replace the user-agent flow, 100%, with the hybrid flow. From eran@hueniverse.com Tue Jan 11 12:43:01 2011 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 951F028C117 for ; Tue, 11 Jan 2011 12:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 5s3GpQdL45D2 for ; Tue, 11 Jan 2011 12:43:00 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id AEA3B28C115 for ; Tue, 11 Jan 2011 12:43:00 -0800 (PST) Received: (qmail 11676 invoked from network); 11 Jan 2011 20:45:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 11 Jan 2011 20:45:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 11 Jan 2011 13:45:05 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 11 Jan 2011 13:45:01 -0700 Thread-Topic: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token Thread-Index: AcuxyTzc5aXgwvNNQWCSVzlL9Q+IXwABwaNg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 11 Jan 2011 20:43:01 -0000 The exact same argument can be made that the hybrid flow meets all the use = cases of the web-server flow... which means we can keep the current single = flow specification as is... :-) What am I missing? (I'm asking). EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Tuesday, January 11, 2011 11:54 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=3Dcode_and_token >=20 > On Mon, Jan 10, 2011 at 3:42 PM, Eran Hammer-Lahav > wrote: > > These are two very different client profiles. In one, the client is com= pletely > authenticated, residing solely in the user-agent. The other is a mix > authenticated and unauthenticated, where parts of the client can keep a > secrets but others can't. > > > > Being able to keep a secret is the primary differentiator when picking = which > profile to use. I agree that the hybrid one is an optimization of the web= - > server profile (removing the need to wait for the server to send a token = back > to the user-agent after exchanging the code). But that only means the > code_and_token really belongs with the web-server profile than with the > user-agent. >=20 > The two paragraphs above didn't make sense to me. >=20 > Once you have the hybrid flow, it meets all of the use cases that the use= r- > agent flow was trying to solve. The hybrid flow is more powerful, and ha= s > the same or better security characteristics. So the sensible thing to do= is > replace the user-agent flow, 100%, with the hybrid flow. From beaton@google.com Tue Jan 11 12:46:18 2011 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 C26AC28C0F9 for ; Tue, 11 Jan 2011 12:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8clVvmaDj36w for ; Tue, 11 Jan 2011 12:46:18 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id CA55028C30E for ; Tue, 11 Jan 2011 12:46:17 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p0BKmYgx020692 for ; Tue, 11 Jan 2011 12:48:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294778914; bh=H03K5ygaKE3Ifska8+RyWTVk4mM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=o1p1rf3ywQWKgTa/5pdSNZnvtlDxyqENNa0cE0XauiKwf8fFH1wsco3o7cRQiM2WS 55nuyq8j/2erxGNuql6hw== Received: from pvg7 (pvg7.prod.google.com [10.241.210.135]) by wpaz33.hot.corp.google.com with ESMTP id p0BKmW9k022259 for ; Tue, 11 Jan 2011 12:48:32 -0800 Received: by pvg7 with SMTP id 7so4249894pvg.36 for ; Tue, 11 Jan 2011 12:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ESTAP8D9kNGZlNO1JpfFmoLNZd++6CSJHZ3iD29GwgM=; b=kSyqm1AGzIwQiLd4/zKuPMcpcyOKuFcs1KU1CzKJkqyUZnQsnniQz/QKNi2TLxjRDu PynbEJb8q7E/xG/t8mYA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ydObKUztu86nfJP7E+7PNKtF83+uajBedYpq/MxHezL44yY72sXrmbrtgvfAvgoYRi AQOpIPAoO9Ob2Im9AJHw== MIME-Version: 1.0 Received: by 10.143.42.12 with SMTP id u12mr189062wfj.304.1294778912166; Tue, 11 Jan 2011 12:48:32 -0800 (PST) Received: by 10.142.213.7 with HTTP; Tue, 11 Jan 2011 12:48:32 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 11 Jan 2011 12:48:32 -0800 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] Proposal to drop/relocate response_type=code_and_token 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, 11 Jan 2011 20:46:18 -0000 On Tue, Jan 11, 2011 at 12:45 PM, Eran Hammer-Lahav wrote: > The exact same argument can be made that the hybrid flow meets all the use cases of the web-server flow... which means we can keep the current single flow specification as is... :-) > > What am I missing? (I'm asking). The hybrid flow does not work well for applications that consist mainly of server-side code. The URL fragment is not transferred to the web server, so they have to write extra client-side code to send it up to their server. From eran@hueniverse.com Tue Jan 11 13:19:57 2011 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 4B9673A67B3 for ; Tue, 11 Jan 2011 13:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn-VM46EvWG3 for ; Tue, 11 Jan 2011 13:19:55 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E6A863A67B6 for ; Tue, 11 Jan 2011 13:19:54 -0800 (PST) Received: (qmail 10404 invoked from network); 11 Jan 2011 21:22:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 11 Jan 2011 21:22:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 11 Jan 2011 14:22:02 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Tue, 11 Jan 2011 14:21:57 -0700 Thread-Topic: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token Thread-Index: Acux0O2wt44XwpcWT5OZrhCWb4QMigABD+5g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 11 Jan 2011 21:19:57 -0000 But that's just an annoying implementation detail. If the only different no= w between the hybrid and web server flows is one character ('?' vs '#'), an= d all the other security considerations and rules (matching, registration, = etc.) are the same, I don't see any point in going back to -05 structure. O= therwise, we have exactly the same section repeating twice or three times, = with almost no differences (which actually makes it harder to pick). EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Tuesday, January 11, 2011 12:49 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=3Dcode_and_token >=20 > On Tue, Jan 11, 2011 at 12:45 PM, Eran Hammer-Lahav > wrote: > > The exact same argument can be made that the hybrid flow meets all the > > use cases of the web-server flow... which means we can keep the > > current single flow specification as is... :-) > > > > What am I missing? (I'm asking). >=20 > The hybrid flow does not work well for applications that consist mainly o= f > server-side code. The URL fragment is not transferred to the web server,= so > they have to write extra client-side code to send it up to their server. From torsten@lodderstedt.net Tue Jan 11 14:16:11 2011 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 BC1323A6A9D for ; Tue, 11 Jan 2011 14:16:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 CtQ0QGhTl0v0 for ; Tue, 11 Jan 2011 14:16:11 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.29.23]) by core3.amsl.com (Postfix) with ESMTP id A8B1B3A6A99 for ; Tue, 11 Jan 2011 14:16:10 -0800 (PST) Received: from [87.142.249.57] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PcmXm-0005pZ-RI; Tue, 11 Jan 2011 23:18:22 +0100 Message-ID: <4D2CD72F.3020604@lodderstedt.net> Date: Tue, 11 Jan 2011 23:18:23 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Manger, James H" References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2B7523.5030908@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A5AB74E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> <255B9BB34FB7D647A506DC292726F6E1127B45344D@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1127B45344D@WSMSG3153V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 11 Jan 2011 22:16:11 -0000 Am 11.01.2011 06:44, schrieb Manger, James H: >>> - Authentication schemes >>> You propose to use the authentication scheme name "OAuth2" for the >>> WWW-Authenticate header but another scheme name "MAC" for the >>> authorization header. I've never seen such an asymmetric approach before. >>> Don't you think people get confused about that? >> This was proposed by James Manger and discussed earlier on the list. I'll let James explain it. > The MAC draft doesn't bother to define a "WWW-Authenticate: MAC ..." response header because Eran is only interested in using MAC in conjunction with OAuth2. > The server can say (in response to an unauthenticated request): "you can use OAuth flows to be delegated access to this server". It says this with a "WWW-Authenticate: OAuth2" response. This statement is not specific to MAC. > > I think the MAC scheme should define its own "WWW-Authenticate: MAC ..." response header. It might not be used by systems using OAuth2, but it makes MAC a more complete standalone HTTP authentication mechanism. >>> Moreover, the bearer draft >>> also uses the name "OAuth2" in the authorization header. Why this >>> difference? Why don't you just add some parameters to the "OAuth2" >>> scheme? > The bearer draft should change to use its own scheme name (eg "BEARER") in Authorization request headers. I'm trying to understand your proposal. Let's assume a client sends a unauthorized request to a protected resource. The resource server answers with 401/WWW-Authenticate OAuth2. What is the client supposed to learn from this response? It can use an OAuth2-Server to obtain a token, correct? The client additionally needs an indication which authorization header (== mechanism) to use for the service invocation. An additional header WWW-Authenticate "MAC" could indicate support for MAC authorization headers whereas WWW-Authenticate "BEARER" could indicate support for BEARER authorization headers. Bottom line: The server has at least to send "MAC" or "BEARER" and can additionally send "OAuth2". As far as I understand, WWW-Authenticate headers are intended to signal the authentication methods a certain server supports + to deliver method specific parameters to the caller. Nothing more. I feel your interpretation goes beyond that point in that this headers shall tell the client not only (1) how to send credentials accross but als (2) how to obtain this credentials. I would suggest to publish (2) by other means than a WWW-Authenticate header. regards, Torsten. > -- > James Manger > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Tue Jan 11 14:20:38 2011 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 084E23A6405 for ; Tue, 11 Jan 2011 14:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFePJElxBO0m for ; Tue, 11 Jan 2011 14:20:36 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 82C1E3A6872 for ; Tue, 11 Jan 2011 14:20:36 -0800 (PST) Received: from [87.142.249.57] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Pcmc8-0000hl-Qw; Tue, 11 Jan 2011 23:22:52 +0100 Message-ID: <4D2CD83D.2010507@lodderstedt.net> Date: Tue, 11 Jan 2011 23:22:53 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Hannes Tschofenig References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? 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, 11 Jan 2011 22:20:38 -0000 I just posted a new revision of http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/. Please consider it for the re-chartering process. Additionally, Mark and me are still working on the security document. It takes longer time than expected because of the topic's inherent complexity. We plan to have a new revision ready for IETF-80. regards, Torsten. Am 10.01.2011 10:55, schrieb Hannes Tschofenig: > Hi all, > > In preparing the charter text we need your feedback. > > First, the new charter needs to include the two new items we had already accepted, namely > * SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 > http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > * The OAuth 2.0 Protocol: Bearer Tokens > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > In the past (around September / October 2010 timeframe) we had also discussed other proposals. See attachment below. > > We cannot just add everything to the charter because we will never be able to finish it. > To make it more complicated there were other proposals floating around but no drafts are available (e.g. security, discovery). > > It would be great to have a complete list of documents that should be considered. > We would suggest to wait till the end of the month for new document submissions to show up. > > Then, we will start a Doodle poll to see your preference. > > Ciao > Hannes& Blaine > > PS: Here are some of the other documents that people wanted to spend time on. There are more on the OAuth WG page. > > * Messaging Signing > Examples: > http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ > http://www.ietf.org/mail-archive/web/oauth/current/msg04250.html > > * User Experience Extensions > Example: > http://datatracker.ietf.org/doc/draft-recordon-oauth-v2-ux/ > > * Artifact Binding > Example: > http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ > > * Dynamic Client Registration > Example: > http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt > > * Token Revocation: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > * Use Cases > http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Tue Jan 11 14:31:26 2011 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 CC9343A67EC for ; Tue, 11 Jan 2011 14:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tf0kRBNjsF2n for ; Tue, 11 Jan 2011 14:31:25 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id 29BB13A6AB8 for ; Tue, 11 Jan 2011 14:31:24 -0800 (PST) Received: from [87.142.249.57] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Pcmmc-0007JD-3k; Tue, 11 Jan 2011 23:33:42 +0100 Message-ID: <4D2CDAC6.2010309@lodderstedt.net> Date: Tue, 11 Jan 2011 23:33:42 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 11 Jan 2011 22:31:26 -0000 the only difference I see is the code in the fragement will not show up in HTTP referers. Am 11.01.2011 22:21, schrieb Eran Hammer-Lahav: > But that's just an annoying implementation detail. If the only different now between the hybrid and web server flows is one character ('?' vs '#'), and all the other security considerations and rules (matching, registration, etc.) are the same, I don't see any point in going back to -05 structure. Otherwise, we have exactly the same section repeating twice or three times, with almost no differences (which actually makes it harder to pick). > > EHL > >> -----Original Message----- >> From: Brian Eaton [mailto:beaton@google.com] >> Sent: Tuesday, January 11, 2011 12:49 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Proposal to drop/relocate >> response_type=code_and_token >> >> On Tue, Jan 11, 2011 at 12:45 PM, Eran Hammer-Lahav >> wrote: >>> The exact same argument can be made that the hybrid flow meets all the >>> use cases of the web-server flow... which means we can keep the >>> current single flow specification as is... :-) >>> >>> What am I missing? (I'm asking). >> The hybrid flow does not work well for applications that consist mainly of >> server-side code. The URL fragment is not transferred to the web server, so >> they have to write extra client-side code to send it up to their server. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Tue Jan 11 14:41:55 2011 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 C8CA63A6ABB for ; Tue, 11 Jan 2011 14:41:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGefZeHBs3Xg for ; Tue, 11 Jan 2011 14:41:55 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 027103A6879 for ; Tue, 11 Jan 2011 14:41:54 -0800 (PST) Received: from [87.142.249.57] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Pcmwl-0006n2-H3; Tue, 11 Jan 2011 23:44:11 +0100 Message-ID: <4D2CDD3C.1010801@lodderstedt.net> Date: Tue, 11 Jan 2011 23:44:12 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian Eaton References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5CD15420-0309-4D44-A2F8-F256FCE2C299@oracle.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 11 Jan 2011 22:41:55 -0000 >The frames timing issue is interesting, but doesn't it suggest a profile where the whole code step is bypassed (e.g. by receiving code and token)? > The user-agent profile callback URL should end up looking like this: > > /callback#code=&token= > > The token component is there so immediately return a usable access > token to the relying party/client server. Do you see any need to restrict the power of this token or is it as powerful as the tokens obtained using the code? I'm asking because this token is sent out without authenticating the client whereas exchange of code to tokens can be authenticated. A malicious client app could initiate the hybrid authorization process in a browser (embedded or external), pretend to be a legitimate client and obtain the token from the redirect_uri after the redirect. regards, Torsten. > The code component is there so the server-side components of the RP > can obtain a refresh token and additional access tokens. > From beaton@google.com Tue Jan 11 16:38:39 2011 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 CD3D33A67E3 for ; Tue, 11 Jan 2011 16:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wxy42Z32MQTE for ; Tue, 11 Jan 2011 16:38:39 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 9D45D3A67DA for ; Tue, 11 Jan 2011 16:38:38 -0800 (PST) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p0C0etjV018707 for ; Tue, 11 Jan 2011 16:40:55 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294792855; bh=F57OvDuGcgdfLS+shG6ZrHXmSSM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Ypiznk9t9kX6rrocX3cqJYYUd+Ytn81RS2rBNRzbu7hkaOcLvZqDxMYQVtegCtyho Zk9T51d8U1SkSEoKTYVsg== Received: from pvc30 (pvc30.prod.google.com [10.241.209.158]) by hpaq6.eem.corp.google.com with ESMTP id p0C0eroD008622 for ; Tue, 11 Jan 2011 16:40:54 -0800 Received: by pvc30 with SMTP id 30so11105pvc.0 for ; Tue, 11 Jan 2011 16:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Gu0I9bzRyhGXnuC2ErgF71HZrZoJB3mkVw/t0b+nwhQ=; b=uDJxSHa3HgKCMBV8MTE9OOQ/Bl2JHG1vMt7IPdqp4hLrFQ0XAbsnsrDKVwnI40AgSo Nc0fdPjE4nSs2/sWa/Wg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Goaa905gUHm+ooi3JRa79eG4BpnIi7BHkI9B8nXCtbq7JkxWomnOv4MuCRQKXlOE3l aJk3eFyS46aRICKnrTxw== MIME-Version: 1.0 Received: by 10.142.148.14 with SMTP id v14mr341425wfd.283.1294792853488; Tue, 11 Jan 2011 16:40:53 -0800 (PST) Received: by 10.142.213.7 with HTTP; Tue, 11 Jan 2011 16:40:53 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 11 Jan 2011 16:40:53 -0800 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] Proposal to drop/relocate response_type=code_and_token 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, 12 Jan 2011 00:38:39 -0000 On Tue, Jan 11, 2011 at 1:21 PM, Eran Hammer-Lahav wrote: > But that's just an annoying implementation detail. Yes. The user-agent flow is a set of annoying implementation details that are very, very useful if you want to make the protocol efficient. > If the only different now between the hybrid and web server flows is one character ('?' vs '#'), and all the other security considerations and rules (matching, registration, etc.) are the same, I don't see any point in going back to -05 structure. > Otherwise, we have exactly the same section repeating twice or three times, with almost no differences (which actually makes it harder to pick). There is another important difference in the protocol flows. The web-server flow only returns a verification code on the query. It does not return a token. There are a couple of reasons for that. - tokens returned on query strings have more ways to leak than tokens returned in fragments. A shorter-lived code is safer. - the verification code requires client authentication to use. This makes it safer. It also will, I think, get oauth2 based login protocols up to LoA 2. Cheers, Brian From beaton@google.com Tue Jan 11 16:41:16 2011 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 A5C953A67EF for ; Tue, 11 Jan 2011 16:41:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRyOMnS6JiDn for ; Tue, 11 Jan 2011 16:41:15 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 97CBE3A67DA for ; Tue, 11 Jan 2011 16:41:15 -0800 (PST) Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p0C0hWqX002569 for ; Tue, 11 Jan 2011 16:43:32 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294793013; bh=y9mmrywL4YcigYxoiBpIEA9P66E=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JpOtP9/daZwdu1x4YGbTNeCAM9PR+zH+f5S3ex79a/0khtVmKoFof4l4yUpnmencK lYJmD/wg4xE4uqe99fNzg== Received: from pvg2 (pvg2.prod.google.com [10.241.210.130]) by kpbe13.cbf.corp.google.com with ESMTP id p0C0hSro012096 for ; Tue, 11 Jan 2011 16:43:31 -0800 Received: by pvg2 with SMTP id 2so8459pvg.30 for ; Tue, 11 Jan 2011 16:43:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Jxlz0XtVX2327WhtB9bogJuUApInHUEybkRRBSSXElE=; b=ZSpQy2I6WYZWwe9LicB8ClSEHluboe6IVzUaE82B+oH4p3cf9T+M0rqP+QutXDacz0 O6UU13hAdaauCL5VmT5A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mjrDs5XgFwO3nkNbXAe0kQJna9H6ovaKQAYSOe8ylEL2fAnw3gcs3Y3jfoOaWRdMcC eJ6PPonlPYPTAx+04VQQ== MIME-Version: 1.0 Received: by 10.142.48.12 with SMTP id v12mr335147wfv.397.1294793008682; Tue, 11 Jan 2011 16:43:28 -0800 (PST) Received: by 10.142.213.7 with HTTP; Tue, 11 Jan 2011 16:43:28 -0800 (PST) In-Reply-To: <4D2CDD3C.1010801@lodderstedt.net> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5CD15420-0309-4D44-A2F8-F256FCE2C299@oracle.com> <4D2CDD3C.1010801@lodderstedt.net> Date: Tue, 11 Jan 2011 16:43:28 -0800 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 12 Jan 2011 00:41:16 -0000 On Tue, Jan 11, 2011 at 2:44 PM, Torsten Lodderstedt wrote: > Do you see any need to restrict the power of this token or is it as powerful > as the tokens obtained using the code? I'm asking because this token is sent > out without authenticating the client whereas exchange of code to tokens can > be authenticated. A malicious client app could initiate the hybrid > authorization process in a browser (embedded or external), pretend to be a > legitimate client and obtain the token from the redirect_uri after the > redirect. This is a good point, I think there are a set of people who won't deploy the user-agent flow because it returns a token without seeing the client secret. They might choose to support the user-agent flow, but return less privileged tokens. I doubt we could standardize anything like that. From eran@hueniverse.com Tue Jan 11 23:17:14 2011 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 B64C63A699D for ; Tue, 11 Jan 2011 23:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.061, 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 wT99uaHcs5Qf for ; Tue, 11 Jan 2011 23:17:05 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 86BA43A6AF5 for ; Tue, 11 Jan 2011 23:17:05 -0800 (PST) Received: (qmail 10088 invoked from network); 12 Jan 2011 07:19:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Jan 2011 07:19:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 12 Jan 2011 00:19:23 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 12 Jan 2011 00:19:17 -0700 Thread-Topic: Specification organization (Endpoints vs. Flows) - Vote by 1/17 Thread-Index: AcuyIY22G2hH/OGZS4Wn+iVIj7vDiw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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, 12 Jan 2011 07:17:14 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (Vote at the end, please read) Background Between draft -00 and -05 the document used a flow-based organization. This= was changed to an endpoint-based organization in draft -06. I have receive= d requests to go back to the flow-based organization, and with -12, have be= en planning to do that. It is important to note that -12 is not meant to in= clude any change in normative language and that -11 code would remain uncha= nged under -12. This is purely editorial. Part of that effort included reviewing the various flows in -05. The flow c= ategories and definitions have always been a source of confusion. Some targ= et specific client architecture (user-agent, web server, device), some are = abstractions for future extensibility (assertion), and some are useful fea= tures that can apply to a wide range of clients (client credentials, userna= me and password). We also have the odd anti-profile of the native applicati= on flow, which in practice is a half-baked guide to navigating the entire r= ange of flows. In practice we have a few ways to get an access token which can be categori= zed in multiple ways: 1. How authorization is obtained? a. Redirection-based - user-agent, web-server b. Direct credentials - client credentials, username and password, ass= ertion 2. Is the client authenticated? a. Yes - web-server, client credentials, username and password, asser= tion (based on type) b. No - user-agent, assertion (based on type) In the past we had another (broken) organization of User delegation, User c= redentials, and Autonomous. Analysis After studying the document and breaking it apart (in my editor) I came to = a few conclusions (which you are invited to disprove): 1. Flow names must be consistent and based on the key differentiator = of each flow. I believe the ability of the client to authenticate is the mo= st significant aspect of each flow. I agree that ease of deployment and per= formance are important, but this is a security protocol and the security co= nsiderations should be the primary attribute used to select flows. 2. The endpoint-based organization turned a few discrete flows into a= single protocol. This protocol should be profiled based on some key client= characteristics (such as redirection and ability of the client to authenti= cate). The main objective of the profiles would be to provide a security-fo= cused description. 3. The hybrid flow, combining the user-agent and web-server into a co= de-and-token solution is a distinct profile with its own unique security pr= operties. While its implementation details are important for efficiency, th= e main differentiator is the client dual nature of being able to maintain s= ecret credentials in some parts, but not in others. It produces two access = tokens using a single authorization and client identifier. 4. The document must not repeat the mistake of 1.0, focusing on a sin= gle client type at the expense of others. OAuth 1.0 focused on the web-serv= er flow and treated everything else as second class citizens. -05 treated n= ative applications similarly, giving much more attentions to the web-server= and user-agent clients, even when their underlying flows could have been w= ritten primarily for some native applications. The issue is mostly in namin= g the profiles after one typical client type instead of their key property. Options I came up with two options for finalizing the specification's structure (pl= ease feel to suggest additional ideas): 1. Keep the document's endpoint-based organization (-11) and add a Cl= ient Profiles section describing specific client implementations based on t= he protocol. These profiles will not include wire information (parameters, = values, etc.), but will include security-minded normative language (MUST re= gister, SHOULD match redirection URI, etc.). 2. Switch back to flow-based organization and include 5 flows in 2 gr= oups (note the new names), plus extensions: a. Redirection-based i. Auth= enticated client (web server) ii. Unaut= henticated client (user-agent) iii. Mix a= uthentication client (code-and-token) b. Direct Credentials i. User= name and password ii. Clien= t credentials c. Extensions Option 1 - Easier for server developers because it will include all the wir= e-protocol details for each endpoint in one place (single list of parameter= s, error codes, etc.). - Shorter, no repeating the same examples, parameters, and error d= efinitions for each flow. - Reads like a reference. - Client developers are instructed which parameter values to use. - Server developer focus helps make security-based decisions (whic= h are primarily the role of the server developer in OAuth). Option 2 - Easier for client developers focused on one flow at a time. - Longer, duplicating examples, parameters, and error definitions.= Currently about 20-30 more pages. - Reads like a narrative / tutorial. - Client developers are instructed which client flow to use. - Client developer focus helps novice developers interoperate with= protected resources. I don't believe there is an obvious winner here because we each have a bias= based on who we believe is the primary target audience (after all, this is= a purely editorial decision - the protocol itself is mostly complete). In = addition, I have done 80% of the work to get -12 to option 2 so it is no lo= nger about investing the time in the transition. Vote Given the stable state of the specification, this might be the last big dec= ision we get to make about the main specification. I've been planning to ju= st come up with a new draft and ask for feedback but I rather take another = week and ask this explicitly. Which option do you prefer (or suggest another)? Please reply with your preference by 1/17. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(Vote at the end= , please read)

 

Background

 <= /o:p>

Between draft -00 and -05 the document used a= flow-based organization. This was changed to an endpoint-based organizatio= n in draft -06. I have received requests to go back to the flow-based organ= ization, and with -12, have been planning to do that. It is important to no= te that -12 is not meant to include any change in normative language and th= at -11 code would remain unchanged under -12. This is purely editorial.

 

P= art of that effort included reviewing the various flows in -05. The flow ca= tegories and definitions have always been a source of confusion. Some targe= t specific client architecture (user-agent, web server, device), some are a= bstractions for future extensibility (assertion),  and some are useful= features that can apply to a wide range of clients (client credentials, us= ername and password). We also have the odd anti-profile of the native appli= cation flow, which in practice is a half-baked guide to navigating the enti= re range of flows.

 

=

In practice we have a few ways to get an access token = which can be categorized in multiple ways:

 

1.   &n= bsp;   How authorization is obtained?

a.  &nb= sp;    Redirection-based – use= r-agent, web-server

b.      Direct crede= ntials – client credentials, username and password, assertion

2.       = Is the client authenticated?

a.     &nbs= p; Yes – web-server, client credentials, user= name and password, assertion (based on type)

b.      No – user-agent, assertion (based on type)

 

In the pas= t we had another (broken) organization of User delegation, User credentials= , and Autonomous.

 

<= p class=3DMsoNormal>Analysis

 =

After studying the document and breaking it = apart (in my editor) I came to a few conclusions (which you are invited to = disprove):

 

1.       <= ![endif]>Flow names must be consistent and based on the key differentiator = of each flow. I believe the ability of the client to authenticate is the mo= st significant aspect of each flow. I agree that ease of deployment and per= formance are important, but this is a security protocol and the security co= nsiderations should be the primary attribute used to select flows.

2.       <= /span>The endpoint-based organization turned a few discret= e flows into a single protocol. This protocol should be profiled based on s= ome key client characteristics (such as redirection and ability of the clie= nt to authenticate). The main objective of the profiles would be to provide= a security-focused description.

<= span style=3D'mso-list:Ignore'>3.       The d= ocument must not repeat the mistake of 1.0, focusing on a single client typ= e at the expense of others. OAuth 1.0 focused on the web-server flow and tr= eated everything else as second class citizens. -05 treated native applicat= ions similarly, giving much more attentions to the web-server and user-agen= t clients, even when their underlying flows could have been written primari= ly for some native applications. The issue is mostly in naming the profiles= after one typical client type instead of their key property.

 

Options

 

I= came up with two options for finalizing the specification’s structur= e (please feel to suggest additional ideas):

 

1.   =     Keep the document’s endpoi= nt-based organization (-11) and add a Client Profiles section describing sp= ecific client implementations based on the protocol. These profiles will no= t include wire information (parameters, values, etc.), but will include sec= urity-minded normative language (MUST register, SHOULD match redirection UR= I, etc.).

2.   &n= bsp;   Switch back to flow-based organiza= tion and include 5 flows in 2 groups (note the new names), plus extensions:=

a. &nbs= p;     Redirection-based <= /o:p>

           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp; i.  &nb= sp;   Authenticated client (web server)

          &nb= sp;            =             &nb= sp;            =              ii.   &nbs= p;  Unauthenticated client (user-agent)

           &n= bsp;            = ;            &n= bsp;            = ;           iii.      <= /span>Mix authentication client (code-and-token)

b.   &nb= sp;  Direct Credentials

 &nb= sp;            =             &nb= sp;            =             &nb= sp;           i.      <= /span>Username and password

   = ;            &n= bsp;            = ;            &n= bsp;            = ;        ii.      Client credentials

c.       Ext= ensions

 

Option 1

-  =         Easier f= or server developers because it will include all the wire-protocol details = for each endpoint in one place (single list of parameters, error codes, etc= .).

-    &nb= sp;     Shorter, no repeating t= he same examples, parameters, and error definitions for each flow.

-      &nb= sp;   Reads like a reference.<= /p>

-       = ;   Client developers are instructed whic= h parameter values to use.

-&nb= sp;         Server developer focus helps make security-based decisions (which are prim= arily the role of the server developer in OAuth).

 

Option 2

=

-       &nb= sp;  Easier for client developers focused on o= ne flow at a time.

-  =         Longer, = duplicating examples, parameters, and error definitions. Currently about 20= -30 more pages.

-  &nb= sp;       Reads like = a narrative / tutorial.

- &= nbsp;        Cli= ent developers are instructed which client flow to use.

-        &n= bsp; Client developer focus helps novice developers= interoperate with protected resources.

=  

I don’t believe there is an= obvious winner here because we each have a bias based on who we believe is= the primary target audience (after all, this is a purely editorial decisio= n – the protocol itself is mostly complete). In addition, I have done= 80% of the work to get -12 to option 2 so it is no longer about investing = the time in the transition.

 =

Vote

 

Given the stable state of the specifi= cation, this might be the last big decision we get to make about the main s= pecification. I’ve been planning to just come up with a new draft and= ask for feedback but I rather take another week and ask this explicitly.

 

Which option do you prefer (or suggest another)?

 

Please reply with your = preference by 1/17.

 

EHL

 

 

=  

 

 

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jan 11 23:23:55 2011 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 1C46A3A6AF8 for ; Tue, 11 Jan 2011 23:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, 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 kMLf58op5XB5 for ; Tue, 11 Jan 2011 23:23:45 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 968D33A6AF5 for ; Tue, 11 Jan 2011 23:23:45 -0800 (PST) Received: (qmail 18562 invoked from network); 12 Jan 2011 07:26:03 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 12 Jan 2011 07:26:03 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 12 Jan 2011 00:26:03 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 12 Jan 2011 00:25:57 -0700 Thread-Topic: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 Thread-Index: AcuyIY22G2hH/OGZS4Wn+iVIj7vDiwACD6qQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB77D6P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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, 12 Jan 2011 07:23:55 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB77D6P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I prefer #1. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, January 11, 2011 11:19 PM To: OAuth WG Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote= by 1/17 (Vote at the end, please read) Background Between draft -00 and -05 the document used a flow-based organization. This= was changed to an endpoint-based organization in draft -06. I have receive= d requests to go back to the flow-based organization, and with -12, have be= en planning to do that. It is important to note that -12 is not meant to in= clude any change in normative language and that -11 code would remain uncha= nged under -12. This is purely editorial. Part of that effort included reviewing the various flows in -05. The flow c= ategories and definitions have always been a source of confusion. Some targ= et specific client architecture (user-agent, web server, device), some are = abstractions for future extensibility (assertion), and some are useful fea= tures that can apply to a wide range of clients (client credentials, userna= me and password). We also have the odd anti-profile of the native applicati= on flow, which in practice is a half-baked guide to navigating the entire r= ange of flows. In practice we have a few ways to get an access token which can be categori= zed in multiple ways: 1. How authorization is obtained? a. Redirection-based - user-agent, web-server b. Direct credentials - client credentials, username and password, ass= ertion 2. Is the client authenticated? a. Yes - web-server, client credentials, username and password, asser= tion (based on type) b. No - user-agent, assertion (based on type) In the past we had another (broken) organization of User delegation, User c= redentials, and Autonomous. Analysis After studying the document and breaking it apart (in my editor) I came to = a few conclusions (which you are invited to disprove): 1. Flow names must be consistent and based on the key differentiator = of each flow. I believe the ability of the client to authenticate is the mo= st significant aspect of each flow. I agree that ease of deployment and per= formance are important, but this is a security protocol and the security co= nsiderations should be the primary attribute used to select flows. 2. The endpoint-based organization turned a few discrete flows into a= single protocol. This protocol should be profiled based on some key client= characteristics (such as redirection and ability of the client to authenti= cate). The main objective of the profiles would be to provide a security-fo= cused description. 3. The hybrid flow, combining the user-agent and web-server into a co= de-and-token solution is a distinct profile with its own unique security pr= operties. While its implementation details are important for efficiency, th= e main differentiator is the client dual nature of being able to maintain s= ecret credentials in some parts, but not in others. It produces two access = tokens using a single authorization and client identifier. 4. The document must not repeat the mistake of 1.0, focusing on a sin= gle client type at the expense of others. OAuth 1.0 focused on the web-serv= er flow and treated everything else as second class citizens. -05 treated n= ative applications similarly, giving much more attentions to the web-server= and user-agent clients, even when their underlying flows could have been w= ritten primarily for some native applications. The issue is mostly in namin= g the profiles after one typical client type instead of their key property. Options I came up with two options for finalizing the specification's structure (pl= ease feel to suggest additional ideas): 1. Keep the document's endpoint-based organization (-11) and add a Cl= ient Profiles section describing specific client implementations based on t= he protocol. These profiles will not include wire information (parameters, = values, etc.), but will include security-minded normative language (MUST re= gister, SHOULD match redirection URI, etc.). 2. Switch back to flow-based organization and include 5 flows in 2 gr= oups (note the new names), plus extensions: a. Redirection-based i. A= uthenticated client (web server) ii. U= nauthenticated client (user-agent) iii. Mi= x authentication client (code-and-token) b. Direct Credentials i. U= sername and password ii. C= lient credentials c. Extensions Option 1 - Easier for server developers because it will include all the wir= e-protocol details for each endpoint in one place (single list of parameter= s, error codes, etc.). - Shorter, no repeating the same examples, parameters, and error d= efinitions for each flow. - Reads like a reference. - Client developers are instructed which parameter values to use. - Server developer focus helps make security-based decisions (whic= h are primarily the role of the server developer in OAuth). Option 2 - Easier for client developers focused on one flow at a time. - Longer, duplicating examples, parameters, and error definitions.= Currently about 20-30 more pages. - Reads like a narrative / tutorial. - Client developers are instructed which client flow to use. - Client developer focus helps novice developers interoperate with= protected resources. I don't believe there is an obvious winner here because we each have a bias= based on who we believe is the primary target audience (after all, this is= a purely editorial decision - the protocol itself is mostly complete). In = addition, I have done 80% of the work to get -12 to option 2 so it is no lo= nger about investing the time in the transition. Vote Given the stable state of the specification, this might be the last big dec= ision we get to make about the main specification. I've been planning to ju= st come up with a new draft and ask for feedback but I rather take another = week and ask this explicitly. Which option do you prefer (or suggest another)? Please reply with your preference by 1/17. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB77D6P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I prefer #1.

 

EHL

<= span style=3D'color:#1F497D'> 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ie= tf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, Janu= ary 11, 2011 11:19 PM
To: OAuth WG
Subject: [OAUTH-WG] = Specification organization (Endpoints vs. Flows) - Vote by 1/17<= /span>

 

(Vote at the end, please read)

 

Background

 

Between draft -00 a= nd -05 the document used a flow-based organization. This was changed to an = endpoint-based organization in draft -06. I have received requests to go ba= ck to the flow-based organization, and with -12, have been planning to do t= hat. It is important to note that -12 is not meant to include any change in= normative language and that -11 code would remain unchanged under -12. Thi= s is purely editorial.

 =

Part of that effort included reviewing the various= flows in -05. The flow categories and definitions have always been a sourc= e of confusion. Some target specific client architecture (user-agent, web s= erver, device), some are abstractions for future extensibility (assertion),=  and some are useful features that can apply to a wide range of clien= ts (client credentials, username and password). We also have the odd anti-p= rofile of the native application flow, which in practice is a half-baked gu= ide to navigating the entire range of flows.

 

In practice we have a few wa= ys to get an access token which can be categorized in multiple ways:

 

1.       How auth= orization is obtained?

a.       Red= irection-based – user-agent, web-server

b.      Direct credentials – client credentials, username and p= assword, assertion

2.  = ;     Is the client authenticat= ed?

a. &= nbsp;     Yes – web-serve= r, client credentials, username and password, assertion (based on type)

b.  &nb= sp;   No – user-agent, assertion (b= ased on type)

 

In the past we had another (broken) organization of User de= legation, User credentials, and Autonomous.

 

Analysis

 

After studying the= document and breaking it apart (in my editor) I came to a few conclusions = (which you are invited to disprove):

 

1.    &n= bsp;  Flow names must be consistent and based = on the key differentiator of each flow. I believe the ability of the client= to authenticate is the most significant aspect of each flow. I agree that = ease of deployment and performance are important, but this is a security pr= otocol and the security considerations should be the primary attribute used= to select flows.

2.  =      The endpoint-based organiz= ation turned a few discrete flows into a single protocol. This protocol sho= uld be profiled based on some key client characteristics (such as redirecti= on and ability of the client to authenticate). The main objective of the pr= ofiles would be to provide a security-focused description.

3.       The hybrid flow, combining the user-agent and web-server int= o a code-and-token solution is a distinct profile with its own unique secur= ity properties. While its implementation details are important for efficien= cy, the main differentiator is the client dual nature of being able to main= tain secret credentials in some parts, but not in others. It produces two a= ccess tokens using a single authorization and client identifier.=

4.       The document must not repeat the mistake of 1.0, focus= ing on a single client type at the expense of others. OAuth 1.0 focused on = the web-server flow and treated everything else as second class citizens. -= 05 treated native applications similarly, giving much more attentions to th= e web-server and user-agent clients, even when their underlying flows could= have been written primarily for some native applications. The issue is mos= tly in naming the profiles after one typical client type instead of their k= ey property.

 

Options

 =

I came up with two options for finalizing the spec= ification’s structure (please feel to suggest additional ideas):=

 

1.       Keep t= he document’s endpoint-based organization (-11) and add a Client Prof= iles section describing specific client implementations based on the protoc= ol. These profiles will not include wire information (parameters, values, e= tc.), but will include security-minded normative language (MUST register, S= HOULD match redirection URI, etc.).

2.       Switch b= ack to flow-based organization and include 5 flows in 2 groups (note the ne= w names), plus extensions:

a.       Redirection-based

       = ;            &n= bsp;            = ;            &n= bsp;            = ;         i.      <= ![endif]>Authenticated client (web server)

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           ii= .     = ; Unauthenticated client (user-agent)

=             &nb= sp;            =             &nb= sp;            =              iii.   &nb= sp;  Mix authentication client (code-and-token= )

b. &nbs= p;    Direct Credentials<= /p>

= &nb= sp;     Username and password

          &nb= sp;            =             &nb= sp;            =             &nb= sp;    ii.c.  = ;     Extensions

=

 

Option 1

-     &nbs= p;    Easier for server developers b= ecause it will include all the wire-protocol details for each endpoint in o= ne place (single list of parameters, error codes, etc.).

-        &= nbsp; Shorter, no repeating the same examples, para= meters, and error definitions for each flow.

-          Reads like a reference.

-          Client developers are instructed which parameter values to u= se.

-    &nb= sp;     Server developer focus = helps make security-based decisions (which are primarily the role of the se= rver developer in OAuth).

 

Option 2

-          = Easier for client developers focused on one flow at a time.<= /o:p>

-      =     Longer, duplicating examples, pa= rameters, and error definitions. Currently about 20-30 more pages.

-      &nb= sp;   Reads like a narrative / tutorial.<= o:p>

-<= span style=3D'font:7.0pt "Times New Roman"'>     &= nbsp;    Client developers are instr= ucted which client flow to use.

-          Client developer focus helps novice developers interoperate with prote= cted resources.

 

I don’t believe there is an obvious winner here bec= ause we each have a bias based on who we believe is the primary target audi= ence (after all, this is a purely editorial decision – the protocol i= tself is mostly complete). In addition, I have done 80% of the work to get = -12 to option 2 so it is no longer about investing the time in the transiti= on.

 

Vote

 

Given the stable state of the specification, this might be th= e last big decision we get to make about the main specification. I’ve= been planning to just come up with a new draft and ask for feedback but I = rather take another week and ask this explicitly.

 

Which option do you pre= fer (or suggest another)?

 

Please reply with your preference by 1/17.=

 

EH= L

 

 

 

 

 

 

 =

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB77D6P3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Tue Jan 11 23:25:23 2011 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 7E69A3A6AF8 for ; Tue, 11 Jan 2011 23:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.581 X-Spam-Level: X-Spam-Status: No, score=-10.581 tagged_above=-999 required=5 tests=[AWL=0.017, 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 pM8owVKVU0di for ; Tue, 11 Jan 2011 23:25:14 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 3B2A93A6AFD for ; Tue, 11 Jan 2011 23:25:14 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 11 Jan 2011 23:27:27 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Tue, 11 Jan 2011 23:27:26 -0800 From: Mike Jones To: Eran Hammer-Lahav , OAuth WG Thread-Topic: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 Thread-Index: AcuyIY22G2hH/OGZS4Wn+iVIj7vDiwACIA0w Date: Wed, 12 Jan 2011 07:27:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246E0640@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246E0640TK5EX14MBXC202r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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, 12 Jan 2011 07:25:23 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246E0640TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 for option 2 - flow based organization From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, January 11, 2011 11:19 PM To: OAuth WG Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote= by 1/17 (Vote at the end, please read) Background Between draft -00 and -05 the document used a flow-based organization. This= was changed to an endpoint-based organization in draft -06. I have receive= d requests to go back to the flow-based organization, and with -12, have be= en planning to do that. It is important to note that -12 is not meant to in= clude any change in normative language and that -11 code would remain uncha= nged under -12. This is purely editorial. Part of that effort included reviewing the various flows in -05. The flow c= ategories and definitions have always been a source of confusion. Some targ= et specific client architecture (user-agent, web server, device), some are = abstractions for future extensibility (assertion), and some are useful fea= tures that can apply to a wide range of clients (client credentials, userna= me and password). We also have the odd anti-profile of the native applicati= on flow, which in practice is a half-baked guide to navigating the entire r= ange of flows. In practice we have a few ways to get an access token which can be categori= zed in multiple ways: 1. How authorization is obtained? a. Redirection-based - user-agent, web-server b. Direct credentials - client credentials, username and password, ass= ertion 2. Is the client authenticated? a. Yes - web-server, client credentials, username and password, assert= ion (based on type) b. No - user-agent, assertion (based on type) In the past we had another (broken) organization of User delegation, User c= redentials, and Autonomous. Analysis After studying the document and breaking it apart (in my editor) I came to = a few conclusions (which you are invited to disprove): 1. Flow names must be consistent and based on the key differentiator o= f each flow. I believe the ability of the client to authenticate is the mos= t significant aspect of each flow. I agree that ease of deployment and perf= ormance are important, but this is a security protocol and the security con= siderations should be the primary attribute used to select flows. 2. The endpoint-based organization turned a few discrete flows into a = single protocol. This protocol should be profiled based on some key client = characteristics (such as redirection and ability of the client to authentic= ate). The main objective of the profiles would be to provide a security-foc= used description. 3. The hybrid flow, combining the user-agent and web-server into a cod= e-and-token solution is a distinct profile with its own unique security pro= perties. While its implementation details are important for efficiency, the= main differentiator is the client dual nature of being able to maintain se= cret credentials in some parts, but not in others. It produces two access t= okens using a single authorization and client identifier. 4. The document must not repeat the mistake of 1.0, focusing on a sing= le client type at the expense of others. OAuth 1.0 focused on the web-serve= r flow and treated everything else as second class citizens. -05 treated na= tive applications similarly, giving much more attentions to the web-server = and user-agent clients, even when their underlying flows could have been wr= itten primarily for some native applications. The issue is mostly in naming= the profiles after one typical client type instead of their key property. Options I came up with two options for finalizing the specification's structure (pl= ease feel to suggest additional ideas): 1. Keep the document's endpoint-based organization (-11) and add a Cli= ent Profiles section describing specific client implementations based on th= e protocol. These profiles will not include wire information (parameters, v= alues, etc.), but will include security-minded normative language (MUST reg= ister, SHOULD match redirection URI, etc.). 2. Switch back to flow-based organization and include 5 flows in 2 gro= ups (note the new names), plus extensions: a. Redirection-based i. Authenticated cl= ient (web server) ii. Unauthenticated = client (user-agent) iii. Mix authenticati= on client (code-and-token) b. Direct Credentials i. Username and pas= sword ii. Client credentia= ls c. Extensions Option 1 - Easier for server developers because it will include all the wire-= protocol details for each endpoint in one place (single list of parameters,= error codes, etc.). - Shorter, no repeating the same examples, parameters, and error def= initions for each flow. - Reads like a reference. - Client developers are instructed which parameter values to use. - Server developer focus helps make security-based decisions (which = are primarily the role of the server developer in OAuth). Option 2 - Easier for client developers focused on one flow at a time. - Longer, duplicating examples, parameters, and error definitions. C= urrently about 20-30 more pages. - Reads like a narrative / tutorial. - Client developers are instructed which client flow to use. - Client developer focus helps novice developers interoperate with p= rotected resources. I don't believe there is an obvious winner here because we each have a bias= based on who we believe is the primary target audience (after all, this is= a purely editorial decision - the protocol itself is mostly complete). In = addition, I have done 80% of the work to get -12 to option 2 so it is no lo= nger about investing the time in the transition. Vote Given the stable state of the specification, this might be the last big dec= ision we get to make about the main specification. I've been planning to ju= st come up with a new draft and ask for feedback but I rather take another = week and ask this explicitly. Which option do you prefer (or suggest another)? Please reply with your preference by 1/17. EHL --_000_4E1F6AAD24975D4BA5B1680429673943246E0640TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 for option 2 &#= 8211; flow based organization

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Tuesday, January 11, 2011 11:19 PM
To: OAuth WG
Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows)= - Vote by 1/17

 

(Vote at the end, please read)

 

Background

 

Between draft -00 and -05 the document used a flow-b= ased organization. This was changed to an endpoint-based organization in dr= aft -06. I have received requests to go back to the flow-based organization= , and with -12, have been planning to do that. It is important to note that -12 is not meant to include any c= hange in normative language and that -11 code would remain unchanged under = -12. This is purely editorial.

 

Part of that effort included reviewing the various f= lows in -05. The flow categories and definitions have always been a source = of confusion. Some target specific client architecture (user-agent, web ser= ver, device), some are abstractions for future extensibility (assertion),  and some are useful features t= hat can apply to a wide range of clients (client credentials, username and = password). We also have the odd anti-profile of the native application flow= , which in practice is a half-baked guide to navigating the entire range of flows.

 

In practice we have a few ways to get an access toke= n which can be categorized in multiple ways:

 

1.      How authorization is obtained?

a.      Redirection-based – user-agent, web-server

b.      Direct credentials – client credentials, user= name and password, assertion

2.      Is the client authenticated?

a.      Yes – web-server, client credentials, usernam= e and password, assertion (based on type)

b.      No – user-agent, assertion (based on type)

 

In the past we had another (broken) organization of = User delegation, User credentials, and Autonomous.

 

Analysis

 

After studying the document and breaking it apart (i= n my editor) I came to a few conclusions (which you are invited to disprove= ):

 

1.      Flow names must be consistent and based on the key = differentiator of each flow. I believe the ability of the client to authent= icate is the most significant aspect of each flow. I agree that ease of dep= loyment and performance are important, but this is a security protocol and the security considerations should be = the primary attribute used to select flows.

2.      The endpoint-based organization turned a few discre= te flows into a single protocol. This protocol should be profiled based on = some key client characteristics (such as redirection and ability of the cli= ent to authenticate). The main objective of the profiles would be to provide a security-focused description.

3.      The hybrid flow, combining the user-agent and web-s= erver into a code-and-token solution is a distinct profile with its own uni= que security properties. While its implementation details are important for= efficiency, the main differentiator is the client dual nature of being able to maintain secret credentials in = some parts, but not in others. It produces two access tokens using a single= authorization and client identifier.

4.      The document must not repeat the mistake of 1.0, fo= cusing on a single client type at the expense of others. OAuth 1.0 focused = on the web-server flow and treated everything else as second class citizens= . -05 treated native applications similarly, giving much more attentions to the web-server and user-agent cl= ients, even when their underlying flows could have been written primarily f= or some native applications. The issue is mostly in naming the profiles aft= er one typical client type instead of their key property.

 

Options

 

I came up with two options for finalizing the specif= ication’s structure (please feel to suggest additional ideas):

 

1.      Keep the document’s endpoint-based organizati= on (-11) and add a Client Profiles section describing specific client imple= mentations based on the protocol. These profiles will not include wire info= rmation (parameters, values, etc.), but will include security-minded normative language (MUST register, SHOULD mat= ch redirection URI, etc.).

2.      Switch back to flow-based organization and include = 5 flows in 2 groups (note the new names), plus extensions:

a.      Redirection-based

       =             &nb= sp;            =             &nb= sp;       i.  = ;   Authenticated client (web server)

       =             &nb= sp;            =             &nb= sp;      ii. &nbs= p;   Unauthenticated client (user-agent)<= o:p>

       =             &nb= sp;            =             &nb= sp;     iii. &nb= sp;   Mix authentication client (code-and= -token)

b.      Direct Credentials

       =             &nb= sp;            =             &nb= sp;       i.  = ;   Username and password

       =             &nb= sp;            =             &nb= sp;      ii. &nbs= p;   Client credentials

c.      Extensions

 

Option 1

-     &= nbsp;  Easier for server developers because it will includ= e all the wire-protocol details for each endpoint in one place (single list= of parameters, error codes, etc.).

-     &= nbsp;  Shorter, no repeating the same examples, parameters= , and error definitions for each flow.

-     &= nbsp;  Reads like a reference.

-     &= nbsp;  Client developers are instructed which parameter va= lues to use.

-     &= nbsp;  Server developer focus helps make security-based de= cisions (which are primarily the role of the server developer in OAuth).

 

Option 2

-     &= nbsp;  Easier for client developers focused on one flow at= a time.

-     &= nbsp;  Longer, duplicating examples, parameters, and error= definitions. Currently about 20-30 more pages.

-     &= nbsp;  Reads like a narrative / tutorial.

-     &= nbsp;  Client developers are instructed which client flow = to use.

-     &= nbsp;  Client developer focus helps novice developers inte= roperate with protected resources.

 

I don’t believe there is an obvious winner her= e because we each have a bias based on who we believe is the primary target= audience (after all, this is a purely editorial decision – the proto= col itself is mostly complete). In addition, I have done 80% of the work to get -12 to option 2 so it is no longer about = investing the time in the transition.

 

Vote

 

Given the stable state of the specification, this mi= ght be the last big decision we get to make about the main specification. I= ’ve been planning to just come up with a new draft and ask for feedba= ck but I rather take another week and ask this explicitly.

 

Which option do you prefer (or suggest another)?

 

Please reply with your preference by 1/17.

 

EHL

 

 

 

 

 

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943246E0640TK5EX14MBXC202r_-- From jricher@mitre.org Wed Jan 12 06:43:08 2011 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 C41AC28C108 for ; Wed, 12 Jan 2011 06:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 vXlj8a-Tv-Oz for ; Wed, 12 Jan 2011 06:43:07 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id C41063A6A01 for ; Wed, 12 Jan 2011 06:43:07 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3B71A21B075F; Wed, 12 Jan 2011 09:45:27 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3259721B074A; Wed, 12 Jan 2011 09:45:27 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 12 Jan 2011 09:45:27 -0500 From: "Richer, Justin P." To: Torsten Lodderstedt , Hannes Tschofenig Date: Wed, 12 Jan 2011 09:43:37 -0500 Thread-Topic: [OAUTH-WG] Re-Chartering: What Items to work on? Thread-Index: Acux3hlaVIDHNUnRScm8s8wJnYOgEAAiP9yl Message-ID: References: , <4D2CD83D.2010507@lodderstedt.net> In-Reply-To: <4D2CD83D.2010507@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? 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, 12 Jan 2011 14:43:08 -0000 I don't quite understand the need for "token_type" in the request. The toke= n being presented is going to have a type associated with it on the server = -- that is, that text blob is going to have been issued by the server as an= access token or a refresh token, no matter what the client claims in this = request. Seems like this is at best an optional sanity check. Unless of course you want to revoke all "related" tokens at once, in which = case I think you need a different mechanism to do so. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Torsten = Lodderstedt [torsten@lodderstedt.net] Sent: Tuesday, January 11, 2011 5:22 PM To: Hannes Tschofenig Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? I just posted a new revision of http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/. Please consider it for the re-chartering process. Additionally, Mark and me are still working on the security document. It takes longer time than expected because of the topic's inherent complexity. We plan to have a new revision ready for IETF-80. regards, Torsten. Am 10.01.2011 10:55, schrieb Hannes Tschofenig: > Hi all, > > In preparing the charter text we need your feedback. > > First, the new charter needs to include the two new items we had already = accepted, namely > * SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 > http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ > * The OAuth 2.0 Protocol: Bearer Tokens > http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ > > In the past (around September / October 2010 timeframe) we had also discu= ssed other proposals. See attachment below. > > We cannot just add everything to the charter because we will never be abl= e to finish it. > To make it more complicated there were other proposals floating around bu= t no drafts are available (e.g. security, discovery). > > It would be great to have a complete list of documents that should be con= sidered. > We would suggest to wait till the end of the month for new document submi= ssions to show up. > > Then, we will start a Doodle poll to see your preference. > > Ciao > Hannes& Blaine > > PS: Here are some of the other documents that people wanted to spend time= on. There are more on the OAuth WG page. > > * Messaging Signing > Examples: > http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ > http://www.ietf.org/mail-archive/web/oauth/current/msg04250.html > > * User Experience Extensions > Example: > http://datatracker.ietf.org/doc/draft-recordon-oauth-v2-ux/ > > * Artifact Binding > Example: > http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ > > * Dynamic Client Registration > Example: > http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt > > * Token Revocation: > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ > > * Use Cases > http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Wed Jan 12 07:03:31 2011 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 28E9528C12B for ; Wed, 12 Jan 2011 07:03:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.83 X-Spam-Level: X-Spam-Status: No, score=-3.83 tagged_above=-999 required=5 tests=[AWL=-1.231, 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 Tihvy1DirZw1 for ; Wed, 12 Jan 2011 07:03:30 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id CC2C028C126 for ; Wed, 12 Jan 2011 07:03:29 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6FD3621B0760; Wed, 12 Jan 2011 10:05:49 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 603C821B076B; Wed, 12 Jan 2011 10:05:49 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 12 Jan 2011 10:05:49 -0500 From: "Richer, Justin P." To: Eran Hammer-Lahav , OAuth WG Date: Wed, 12 Jan 2011 10:02:50 -0500 Thread-Topic: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 Thread-Index: AcuyIY22G2hH/OGZS4Wn+iVIj7vDiwASDqHc Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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, 12 Jan 2011 15:03:31 -0000 +1 for option 2 I see, and have always seen, the target audience as server and client devel= opers who are likely to be working against one flow and use case at a time.= Also, I disagree that the primary role of the server developer is the secu= rity considerations. In theory, you may be right, but in practice, I think = you'll find that many are going to be more concerned with just making it wo= rk at all with their API/framework/server. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Wednesday, January 12, 2011 2:19 AM To: OAuth WG Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote= by 1/17 (Vote at the end, please read) Background Between draft -00 and -05 the document used a flow-based organization. This= was changed to an endpoint-based organization in draft -06. I have receive= d requests to go back to the flow-based organization, and with -12, have be= en planning to do that. It is important to note that -12 is not meant to in= clude any change in normative language and that -11 code would remain uncha= nged under -12. This is purely editorial. Part of that effort included reviewing the various flows in -05. The flow c= ategories and definitions have always been a source of confusion. Some targ= et specific client architecture (user-agent, web server, device), some are = abstractions for future extensibility (assertion), and some are useful fea= tures that can apply to a wide range of clients (client credentials, userna= me and password). We also have the odd anti-profile of the native applicati= on flow, which in practice is a half-baked guide to navigating the entire r= ange of flows. In practice we have a few ways to get an access token which can be categori= zed in multiple ways: 1. How authorization is obtained? a. Redirection-based =96 user-agent, web-server b. Direct credentials =96 client credentials, username and password, a= ssertion 2. Is the client authenticated? a. Yes =96 web-server, client credentials, username and password, ass= ertion (based on type) b. No =96 user-agent, assertion (based on type) In the past we had another (broken) organization of User delegation, User c= redentials, and Autonomous. Analysis After studying the document and breaking it apart (in my editor) I came to = a few conclusions (which you are invited to disprove): 1. Flow names must be consistent and based on the key differentiator = of each flow. I believe the ability of the client to authenticate is the mo= st significant aspect of each flow. I agree that ease of deployment and per= formance are important, but this is a security protocol and the security co= nsiderations should be the primary attribute used to select flows. 2. The endpoint-based organization turned a few discrete flows into a= single protocol. This protocol should be profiled based on some key client= characteristics (such as redirection and ability of the client to authenti= cate). The main objective of the profiles would be to provide a security-fo= cused description. 3. The hybrid flow, combining the user-agent and web-server into a co= de-and-token solution is a distinct profile with its own unique security pr= operties. While its implementation details are important for efficiency, th= e main differentiator is the client dual nature of being able to maintain s= ecret credentials in some parts, but not in others. It produces two access = tokens using a single authorization and client identifier. 4. The document must not repeat the mistake of 1.0, focusing on a sin= gle client type at the expense of others. OAuth 1.0 focused on the web-serv= er flow and treated everything else as second class citizens. -05 treated n= ative applications similarly, giving much more attentions to the web-server= and user-agent clients, even when their underlying flows could have been w= ritten primarily for some native applications. The issue is mostly in namin= g the profiles after one typical client type instead of their key property. Options I came up with two options for finalizing the specification=92s structure (= please feel to suggest additional ideas): 1. Keep the document=92s endpoint-based organization (-11) and add a = Client Profiles section describing specific client implementations based on= the protocol. These profiles will not include wire information (parameters= , values, etc.), but will include security-minded normative language (MUST = register, SHOULD match redirection URI, etc.). 2. Switch back to flow-based organization and include 5 flows in 2 gr= oups (note the new names), plus extensions: a. Redirection-based i. Auth= enticated client (web server) ii. Unaut= henticated client (user-agent) iii. Mix a= uthentication client (code-and-token) b. Direct Credentials i. User= name and password ii. Clien= t credentials c. Extensions Option 1 - Easier for server developers because it will include all the wir= e-protocol details for each endpoint in one place (single list of parameter= s, error codes, etc.). - Shorter, no repeating the same examples, parameters, and error d= efinitions for each flow. - Reads like a reference. - Client developers are instructed which parameter values to use. - Server developer focus helps make security-based decisions (whic= h are primarily the role of the server developer in OAuth). Option 2 - Easier for client developers focused on one flow at a time. - Longer, duplicating examples, parameters, and error definitions.= Currently about 20-30 more pages. - Reads like a narrative / tutorial. - Client developers are instructed which client flow to use. - Client developer focus helps novice developers interoperate with= protected resources. I don=92t believe there is an obvious winner here because we each have a bi= as based on who we believe is the primary target audience (after all, this = is a purely editorial decision =96 the protocol itself is mostly complete).= In addition, I have done 80% of the work to get -12 to option 2 so it is n= o longer about investing the time in the transition. Vote Given the stable state of the specification, this might be the last big dec= ision we get to make about the main specification. I=92ve been planning to = just come up with a new draft and ask for feedback but I rather take anothe= r week and ask this explicitly. Which option do you prefer (or suggest another)? Please reply with your preference by 1/17. EHL From mscurtescu@google.com Wed Jan 12 07:08:42 2011 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 A50A228C11C for ; Wed, 12 Jan 2011 07:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.313 X-Spam-Level: X-Spam-Status: No, score=-104.313 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 qnQtAEI2j-CY for ; Wed, 12 Jan 2011 07:08:41 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3A2D428C107 for ; Wed, 12 Jan 2011 07:08:41 -0800 (PST) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p0CFB0Ln008421 for ; Wed, 12 Jan 2011 07:11:00 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294845060; bh=+ApQKM2++Ey+XRd5arbs5KxEVc0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=hZgy/xM5iyOOcyVBZrPTYYUeEFE1WESqk8dqxaNXUTyVTvxUdUM7ZlUcR2tuSppCK eWB6ZH5NnNwHjSRoFeGRA== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by kpbe20.cbf.corp.google.com with ESMTP id p0CFAxNk014508 for ; Wed, 12 Jan 2011 07:10:59 -0800 Received: by gwj20 with SMTP id 20so241433gwj.19 for ; Wed, 12 Jan 2011 07:10:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=kMtzqcJy+8K3eR9pD5OOaxp6GDKAs44qer50nw3FfXE=; b=vP3mbXJTppOiraubdCu+wAZSv2sWOrvjqvGyuhMBoSR7pu6csCFPp0iFT6mnKLlxxF 3NM2cBATE/TSmV6DyZ1g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=u00erWLaAddZ6I3M5f6mE8vY8B5r1nfAcdCplujFrzFm/UbYQtew0+5vrDHv/AGF+d GurtTK9Ww0q4IqNQRxxw== Received: by 10.100.32.10 with SMTP id f10mr678718anf.201.1294845058340; Wed, 12 Jan 2011 07:10:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.123.14 with HTTP; Wed, 12 Jan 2011 07:10:38 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 12 Jan 2011 10:10:38 -0500 Message-ID: To: "Richer, Justin P." Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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, 12 Jan 2011 15:08:42 -0000 +1 for option 2 as well Not convinced that naming the main flows Authenticated and Unauthenticated makes sense, I think it will only increase confusion. For example, native apps are not authenticated and they would be using the "Authenticated" flow. I think we should stick with something along the lines of "Code" and "Token". Marius On Wed, Jan 12, 2011 at 10:02 AM, Richer, Justin P. wro= te: > +1 for option 2 > > I see, and have always seen, the target audience as server and client dev= elopers who are likely to be working against one flow and use case at a tim= e. Also, I disagree that the primary role of the server developer is the se= curity considerations. In theory, you may be right, but in practice, I thin= k you'll find that many are going to be more concerned with just making it = work at all with their API/framework/server. > > =A0-- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran H= ammer-Lahav [eran@hueniverse.com] > Sent: Wednesday, January 12, 2011 2:19 AM > To: OAuth WG > Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vo= te =A0 =A0 by 1/17 > > (Vote at the end, please read) > > Background > > Between draft -00 and -05 the document used a flow-based organization. Th= is was changed to an endpoint-based organization in draft -06. I have recei= ved requests to go back to the flow-based organization, and with -12, have = been planning to do that. It is important to note that -12 is not meant to = include any change in normative language and that -11 code would remain unc= hanged under -12. This is purely editorial. > > Part of that effort included reviewing the various flows in -05. The flow= categories and definitions have always been a source of confusion. Some ta= rget specific client architecture (user-agent, web server, device), some ar= e abstractions for future extensibility (assertion), =A0and some are useful= features that can apply to a wide range of clients (client credentials, us= ername and password). We also have the odd anti-profile of the native appli= cation flow, which in practice is a half-baked guide to navigating the enti= re range of flows. > > In practice we have a few ways to get an access token which can be catego= rized in multiple ways: > > > 1. =A0 =A0 =A0 How authorization is obtained? > > a. =A0 =A0 =A0 Redirection-based =96 user-agent, web-server > > b. =A0 =A0 =A0Direct credentials =96 client credentials, username and pas= sword, assertion > > 2. =A0 =A0 =A0 Is the client authenticated? > > a. =A0 =A0 =A0 Yes =96 web-server, client credentials, username and passw= ord, assertion (based on type) > > b. =A0 =A0 =A0No =96 user-agent, assertion (based on type) > > In the past we had another (broken) organization of User delegation, User= credentials, and Autonomous. > > Analysis > > After studying the document and breaking it apart (in my editor) I came t= o a few conclusions (which you are invited to disprove): > > > 1. =A0 =A0 =A0 Flow names must be consistent and based on the key differe= ntiator of each flow. I believe the ability of the client to authenticate i= s the most significant aspect of each flow. I agree that ease of deployment= and performance are important, but this is a security protocol and the sec= urity considerations should be the primary attribute used to select flows. > > 2. =A0 =A0 =A0 The endpoint-based organization turned a few discrete flow= s into a single protocol. This protocol should be profiled based on some ke= y client characteristics (such as redirection and ability of the client to = authenticate). The main objective of the profiles would be to provide a sec= urity-focused description. > > 3. =A0 =A0 =A0 The hybrid flow, combining the user-agent and web-server i= nto a code-and-token solution is a distinct profile with its own unique sec= urity properties. While its implementation details are important for effici= ency, the main differentiator is the client dual nature of being able to ma= intain secret credentials in some parts, but not in others. It produces two= access tokens using a single authorization and client identifier. > > 4. =A0 =A0 =A0 The document must not repeat the mistake of 1.0, focusing = on a single client type at the expense of others. OAuth 1.0 focused on the = web-server flow and treated everything else as second class citizens. -05 t= reated native applications similarly, giving much more attentions to the we= b-server and user-agent clients, even when their underlying flows could hav= e been written primarily for some native applications. The issue is mostly = in naming the profiles after one typical client type instead of their key p= roperty. > > Options > > I came up with two options for finalizing the specification=92s structure= (please feel to suggest additional ideas): > > > 1. =A0 =A0 =A0 Keep the document=92s endpoint-based organization (-11) an= d add a Client Profiles section describing specific client implementations = based on the protocol. These profiles will not include wire information (pa= rameters, values, etc.), but will include security-minded normative languag= e (MUST register, SHOULD match redirection URI, etc.). > > 2. =A0 =A0 =A0 Switch back to flow-based organization and include 5 flows= in 2 groups (note the new names), plus extensions: > > a. =A0 =A0 =A0 Redirection-based > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i. =A0 =A0 =A0Authentic= ated client (web server) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ii. =A0 =A0 =A0Unauthentica= ted client (user-agent) > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0iii. =A0 =A0 =A0Mix authenti= cation client (code-and-token) > > b. =A0 =A0 =A0Direct Credentials > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i. =A0 =A0 =A0Username = and password > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ii. =A0 =A0 =A0Client crede= ntials > > c. =A0 =A0 =A0 Extensions > > Option 1 > > - =A0 =A0 =A0 =A0 =A0Easier for server developers because it will include= all the wire-protocol details for each endpoint in one place (single list = of parameters, error codes, etc.). > > - =A0 =A0 =A0 =A0 =A0Shorter, no repeating the same examples, parameters,= and error definitions for each flow. > > - =A0 =A0 =A0 =A0 =A0Reads like a reference. > > - =A0 =A0 =A0 =A0 =A0Client developers are instructed which parameter val= ues to use. > > - =A0 =A0 =A0 =A0 =A0Server developer focus helps make security-based dec= isions (which are primarily the role of the server developer in OAuth). > > Option 2 > > - =A0 =A0 =A0 =A0 =A0Easier for client developers focused on one flow at = a time. > > - =A0 =A0 =A0 =A0 =A0Longer, duplicating examples, parameters, and error = definitions. Currently about 20-30 more pages. > > - =A0 =A0 =A0 =A0 =A0Reads like a narrative / tutorial. > > - =A0 =A0 =A0 =A0 =A0Client developers are instructed which client flow t= o use. > > - =A0 =A0 =A0 =A0 =A0Client developer focus helps novice developers inter= operate with protected resources. > > I don=92t believe there is an obvious winner here because we each have a = bias based on who we believe is the primary target audience (after all, thi= s is a purely editorial decision =96 the protocol itself is mostly complete= ). In addition, I have done 80% of the work to get -12 to option 2 so it is= no longer about investing the time in the transition. > > Vote > > Given the stable state of the specification, this might be the last big d= ecision we get to make about the main specification. I=92ve been planning t= o just come up with a new draft and ask for feedback but I rather take anot= her week and ask this explicitly. > > Which option do you prefer (or suggest another)? > > Please reply with your preference by 1/17. > > EHL > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From jricher@mitre.org Wed Jan 12 07:14:33 2011 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 576CB28C13A for ; Wed, 12 Jan 2011 07:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.143, 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 TCfKqXuZtuMI for ; Wed, 12 Jan 2011 07:14:32 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id D07B228C123 for ; Wed, 12 Jan 2011 07:14:31 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5CD5521B0767; Wed, 12 Jan 2011 10:16:51 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 4DE3621B0766; Wed, 12 Jan 2011 10:16:51 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Wed, 12 Jan 2011 10:16:51 -0500 From: "Richer, Justin P." To: Marius Scurtescu Date: Wed, 12 Jan 2011 10:15:54 -0500 Thread-Topic: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 Thread-Index: Acuyau6ik+xMwhqHQ6edNhlkwj7JhAAAKy0K Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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, 12 Jan 2011 15:14:33 -0000 Marius makes a good point -- we probably want to avoid using language like = that for part descriptions. I don't think "code" and "token" quite get it, = but I don't have a better suggestion at the moment though... -- Justin ________________________________________ From: Marius Scurtescu [mscurtescu@google.com] Sent: Wednesday, January 12, 2011 10:10 AM To: Richer, Justin P. Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - = Vote by 1/17 +1 for option 2 as well Not convinced that naming the main flows Authenticated and Unauthenticated makes sense, I think it will only increase confusion. For example, native apps are not authenticated and they would be using the "Authenticated" flow. I think we should stick with something along the lines of "Code" and "Token". Marius On Wed, Jan 12, 2011 at 10:02 AM, Richer, Justin P. wro= te: > +1 for option 2 > > I see, and have always seen, the target audience as server and client dev= elopers who are likely to be working against one flow and use case at a tim= e. Also, I disagree that the primary role of the server developer is the se= curity considerations. In theory, you may be right, but in practice, I thin= k you'll find that many are going to be more concerned with just making it = work at all with their API/framework/server. > > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran H= ammer-Lahav [eran@hueniverse.com] > Sent: Wednesday, January 12, 2011 2:19 AM > To: OAuth WG > Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vo= te by 1/17 > > (Vote at the end, please read) > > Background > > Between draft -00 and -05 the document used a flow-based organization. Th= is was changed to an endpoint-based organization in draft -06. I have recei= ved requests to go back to the flow-based organization, and with -12, have = been planning to do that. It is important to note that -12 is not meant to = include any change in normative language and that -11 code would remain unc= hanged under -12. This is purely editorial. > > Part of that effort included reviewing the various flows in -05. The flow= categories and definitions have always been a source of confusion. Some ta= rget specific client architecture (user-agent, web server, device), some ar= e abstractions for future extensibility (assertion), and some are useful f= eatures that can apply to a wide range of clients (client credentials, user= name and password). We also have the odd anti-profile of the native applica= tion flow, which in practice is a half-baked guide to navigating the entire= range of flows. > > In practice we have a few ways to get an access token which can be catego= rized in multiple ways: > > > 1. How authorization is obtained? > > a. Redirection-based =96 user-agent, web-server > > b. Direct credentials =96 client credentials, username and password,= assertion > > 2. Is the client authenticated? > > a. Yes =96 web-server, client credentials, username and password, a= ssertion (based on type) > > b. No =96 user-agent, assertion (based on type) > > In the past we had another (broken) organization of User delegation, User= credentials, and Autonomous. > > Analysis > > After studying the document and breaking it apart (in my editor) I came t= o a few conclusions (which you are invited to disprove): > > > 1. Flow names must be consistent and based on the key differentiato= r of each flow. I believe the ability of the client to authenticate is the = most significant aspect of each flow. I agree that ease of deployment and p= erformance are important, but this is a security protocol and the security = considerations should be the primary attribute used to select flows. > > 2. The endpoint-based organization turned a few discrete flows into= a single protocol. This protocol should be profiled based on some key clie= nt characteristics (such as redirection and ability of the client to authen= ticate). The main objective of the profiles would be to provide a security-= focused description. > > 3. The hybrid flow, combining the user-agent and web-server into a = code-and-token solution is a distinct profile with its own unique security = properties. While its implementation details are important for efficiency, = the main differentiator is the client dual nature of being able to maintain= secret credentials in some parts, but not in others. It produces two acces= s tokens using a single authorization and client identifier. > > 4. The document must not repeat the mistake of 1.0, focusing on a s= ingle client type at the expense of others. OAuth 1.0 focused on the web-se= rver flow and treated everything else as second class citizens. -05 treated= native applications similarly, giving much more attentions to the web-serv= er and user-agent clients, even when their underlying flows could have been= written primarily for some native applications. The issue is mostly in nam= ing the profiles after one typical client type instead of their key propert= y. > > Options > > I came up with two options for finalizing the specification=92s structure= (please feel to suggest additional ideas): > > > 1. Keep the document=92s endpoint-based organization (-11) and add = a Client Profiles section describing specific client implementations based = on the protocol. These profiles will not include wire information (paramete= rs, values, etc.), but will include security-minded normative language (MUS= T register, SHOULD match redirection URI, etc.). > > 2. Switch back to flow-based organization and include 5 flows in 2 = groups (note the new names), plus extensions: > > a. Redirection-based > > i. Aut= henticated client (web server) > > ii. Unau= thenticated client (user-agent) > > iii. Mix = authentication client (code-and-token) > > b. Direct Credentials > > i. Use= rname and password > > ii. Clie= nt credentials > > c. Extensions > > Option 1 > > - Easier for server developers because it will include all the w= ire-protocol details for each endpoint in one place (single list of paramet= ers, error codes, etc.). > > - Shorter, no repeating the same examples, parameters, and error= definitions for each flow. > > - Reads like a reference. > > - Client developers are instructed which parameter values to use= . > > - Server developer focus helps make security-based decisions (wh= ich are primarily the role of the server developer in OAuth). > > Option 2 > > - Easier for client developers focused on one flow at a time. > > - Longer, duplicating examples, parameters, and error definition= s. Currently about 20-30 more pages. > > - Reads like a narrative / tutorial. > > - Client developers are instructed which client flow to use. > > - Client developer focus helps novice developers interoperate wi= th protected resources. > > I don=92t believe there is an obvious winner here because we each have a = bias based on who we believe is the primary target audience (after all, thi= s is a purely editorial decision =96 the protocol itself is mostly complete= ). In addition, I have done 80% of the work to get -12 to option 2 so it is= no longer about investing the time in the transition. > > Vote > > Given the stable state of the specification, this might be the last big d= ecision we get to make about the main specification. I=92ve been planning t= o just come up with a new draft and ask for feedback but I rather take anot= her week and ask this explicitly. > > Which option do you prefer (or suggest another)? > > Please reply with your preference by 1/17. > > EHL > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From dick.hardt@gmail.com Wed Jan 12 08:20:44 2011 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 15E4D3A6A5C for ; Wed, 12 Jan 2011 08:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 Y9DW+4JQS0qT for ; Wed, 12 Jan 2011 08:20:41 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 43DC13A67FA for ; Wed, 12 Jan 2011 08:20:40 -0800 (PST) Received: by fxm9 with SMTP id 9so784906fxm.31 for ; Wed, 12 Jan 2011 08:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to:x-mailer; bh=ML1PJMSO/UQAe5mwtuyCwssAfy56chEofwBTilld0S4=; b=BJaGsySF6a+NAnjcchDxTbSiiqRmZFF3AO5qMacdCNSMQijCCzi64/1kNeVWVVai31 fjQGdGKqtzCFlW7dBHLiEjLSg1V+0QXhugYTlndU9X9vWRYyn1VzPoagbFmHIBZeMhIB MK5SKNQXZhjSpHthtcIxiSPJEpf0qfToVzYZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; b=NwAYYZYw3tY3AnDgC7u2iEFIwW3ABdd2cT6RTRhP6m1uRlf/bBYJSt9/ArbxhWu6Ok XhMCDlJ1WT2AvSJ/Y+kCcjq0BtNeVZb5fV2l26jzwsZHKvNCUMRv62lrly5xiJbvhkZb yDTHsanV7WEWF6GhJlK50oJyvypB+Uc2Cuteg= Received: by 10.223.105.139 with SMTP id t11mr1160944fao.111.1294849379397; Wed, 12 Jan 2011 08:22:59 -0800 (PST) Received: from [192.168.1.40] (c-69-181-71-149.hsd1.ca.comcast.net [69.181.71.149]) by mx.google.com with ESMTPS id a25sm274467fak.44.2011.01.12.08.22.53 (version=SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 08:22:56 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-9-862075973 From: Dick Hardt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 12 Jan 2011 08:22:52 -0800 Message-Id: <60754B4A-2DE9-4DC4-88A8-7993EA9CD76F@gmail.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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, 12 Jan 2011 16:20:44 -0000 --Apple-Mail-9-862075973 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 +1 for flow based option (#2) -- it prioritizes the security = implications, and then readability for a much larger audience (client = developer) On 2011-01-11, at 11:19 PM, Eran Hammer-Lahav wrote: > (Vote at the end, please read) > =20 > Background > =20 > Between draft -00 and -05 the document used a flow-based organization. = This was changed to an endpoint-based organization in draft -06. I have = received requests to go back to the flow-based organization, and with = -12, have been planning to do that. It is important to note that -12 is = not meant to include any change in normative language and that -11 code = would remain unchanged under -12. This is purely editorial. > =20 > Part of that effort included reviewing the various flows in -05. The = flow categories and definitions have always been a source of confusion. = Some target specific client architecture (user-agent, web server, = device), some are abstractions for future extensibility (assertion), = and some are useful features that can apply to a wide range of clients = (client credentials, username and password). We also have the odd = anti-profile of the native application flow, which in practice is a = half-baked guide to navigating the entire range of flows. > =20 > In practice we have a few ways to get an access token which can be = categorized in multiple ways: > =20 > 1. How authorization is obtained? > a. Redirection-based =96 user-agent, web-server > b. Direct credentials =96 client credentials, username and = password, assertion > 2. Is the client authenticated? > a. Yes =96 web-server, client credentials, username and = password, assertion (based on type) > b. No =96 user-agent, assertion (based on type) > =20 > In the past we had another (broken) organization of User delegation, = User credentials, and Autonomous. > =20 > Analysis > =20 > After studying the document and breaking it apart (in my editor) I = came to a few conclusions (which you are invited to disprove): > =20 > 1. Flow names must be consistent and based on the key = differentiator of each flow. I believe the ability of the client to = authenticate is the most significant aspect of each flow. I agree that = ease of deployment and performance are important, but this is a security = protocol and the security considerations should be the primary attribute = used to select flows. > 2. The endpoint-based organization turned a few discrete flows = into a single protocol. This protocol should be profiled based on some = key client characteristics (such as redirection and ability of the = client to authenticate). The main objective of the profiles would be to = provide a security-focused description. > 3. The hybrid flow, combining the user-agent and web-server into = a code-and-token solution is a distinct profile with its own unique = security properties. While its implementation details are important for = efficiency, the main differentiator is the client dual nature of being = able to maintain secret credentials in some parts, but not in others. It = produces two access tokens using a single authorization and client = identifier. > 4. The document must not repeat the mistake of 1.0, focusing on = a single client type at the expense of others. OAuth 1.0 focused on the = web-server flow and treated everything else as second class citizens. = -05 treated native applications similarly, giving much more attentions = to the web-server and user-agent clients, even when their underlying = flows could have been written primarily for some native applications. = The issue is mostly in naming the profiles after one typical client type = instead of their key property. > =20 > Options > =20 > I came up with two options for finalizing the specification=92s = structure (please feel to suggest additional ideas): > =20 > 1. Keep the document=92s endpoint-based organization (-11) and = add a Client Profiles section describing specific client implementations = based on the protocol. These profiles will not include wire information = (parameters, values, etc.), but will include security-minded normative = language (MUST register, SHOULD match redirection URI, etc.). > 2. Switch back to flow-based organization and include 5 flows in = 2 groups (note the new names), plus extensions: > a. Redirection-based > i. = Authenticated client (web server) > ii. = Unauthenticated client (user-agent) > iii. = Mix authentication client (code-and-token) > b. Direct Credentials > i. = Username and password > ii. = Client credentials > c. Extensions > =20 > Option 1 > - Easier for server developers because it will include all = the wire-protocol details for each endpoint in one place (single list of = parameters, error codes, etc.). > - Shorter, no repeating the same examples, parameters, and = error definitions for each flow. > - Reads like a reference. > - Client developers are instructed which parameter values to = use. > - Server developer focus helps make security-based decisions = (which are primarily the role of the server developer in OAuth). > =20 > Option 2 > - Easier for client developers focused on one flow at a time. > - Longer, duplicating examples, parameters, and error = definitions. Currently about 20-30 more pages. > - Reads like a narrative / tutorial. > - Client developers are instructed which client flow to use. > - Client developer focus helps novice developers interoperate = with protected resources. > =20 > I don=92t believe there is an obvious winner here because we each have = a bias based on who we believe is the primary target audience (after = all, this is a purely editorial decision =96 the protocol itself is = mostly complete). In addition, I have done 80% of the work to get -12 to = option 2 so it is no longer about investing the time in the transition. > =20 > Vote > =20 > Given the stable state of the specification, this might be the last = big decision we get to make about the main specification. I=92ve been = planning to just come up with a new draft and ask for feedback but I = rather take another week and ask this explicitly. > =20 > Which option do you prefer (or suggest another)? > =20 > Please reply with your preference by 1/17. > =20 > EHL > =20 > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-9-862075973 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 +1 for flow based option (#2) -- it prioritizes the = security implications, and then readability for a much larger audience = (client developer)

On 2011-01-11, at 11:19 PM, Eran = Hammer-Lahav wrote:

(Vote at the end, please = read)
 
 
 
 
In practice we have = a few ways to get an access token which can be categorized in multiple = ways:
 
       How = authorization is obtained?
       Redirection-bas= ed =96 user-agent, web-server
      Direct = credentials =96 client credentials, username and password, = assertion
2. Is the client = authenticated?
       Yes =96 = web-server, client credentials, username and password, assertion (based = on type)
b. No =96 = user-agent, assertion (based on type)
In the past we had another (broken) = organization of User delegation, User credentials, and = Autonomous.
 
 
 
1. Flow names = must be consistent and based on the key differentiator of each flow. I = believe the ability of the client to authenticate is the most = significant aspect of each flow. I agree that ease of deployment and = performance are important, but this is a security protocol and the = security considerations should be the primary attribute used to select = flows.
2. The = endpoint-based organization turned a few discrete flows into a single = protocol. This protocol should be profiled based on some key client = characteristics (such as redirection and ability of the client to = authenticate). The main objective of the profiles would be to provide a = security-focused description.
       The hybrid = flow, combining the user-agent and web-server into a code-and-token = solution is a distinct profile with its own unique security properties. = While its implementation details are important for efficiency, the main = differentiator is the client dual nature of being able to maintain = secret credentials in some parts, but not in others. It produces two = access tokens using a single authorization and client = identifier.
4. The document = must not repeat the mistake of 1.0, focusing on a single client type at = the expense of others. OAuth 1.0 focused on the web-server flow and = treated everything else as second class citizens. -05 treated native = applications similarly, giving much more attentions to the web-server = and user-agent clients, even when their underlying flows could have been = written primarily for some native applications. The issue is mostly in = naming the profiles after one typical client type instead of their key = property.
 
 
I = came up with two options for finalizing the specification=92s structure = (please feel to suggest additional ideas):
1. Keep the = document=92s endpoint-based organization (-11) and add a Client Profiles = section describing specific client implementations based on the = protocol. These profiles will not include wire information (parameters, = values, etc.), but will include security-minded normative language (MUST = register, SHOULD match redirection URI, etc.).
2. Switch back = to flow-based organization and include 5 flows in 2 groups (note the new = names), plus extensions:
       Redirection-bas= ed
 i. Authenticated = client (web server)
            =             &n= bsp;           &nbs= p;            =             ii. Unauthenticated= client (user-agent)
            =             &n= bsp;           &nbs= p;            =            iii. Mix = authentication client (code-and-token)
b. Direct = Credentials
 i. Username and = password
 ii. Client = credentials
c. Extensions=
 
Option = 1
- Easier for = server developers because it will include all the wire-protocol details = for each endpoint in one place (single list of parameters, error codes, = etc.).
- Shorter, no = repeating the same examples, parameters, and error definitions for each = flow.
- Reads like a = reference.
- Client = developers are instructed which parameter values to = use.
- Server = developer focus helps make security-based decisions (which are primarily = the role of the server developer in OAuth).
Option 2
- Easier for = client developers focused on one flow at a time.
- Longer, = duplicating examples, parameters, and error definitions. Currently about = 20-30 more pages.
          Reads like a = narrative / tutorial.
          Client = developers are instructed which client flow to use.
- Client = developer focus helps novice developers interoperate with protected = resources.
 
I = don=92t believe there is an obvious winner here because we each have a = bias based on who we believe is the primary target audience (after all, = this is a purely editorial decision =96 the protocol itself is mostly = complete). In addition, I have done 80% of the work to get -12 to option = 2 so it is no longer about investing the time in the = transition.
 
 
Given the stable = state of the specification, this might be the last big decision we get = to make about the main specification. I=92ve been planning to just come = up with a new draft and ask for feedback but I rather take another week = and ask this explicitly.
 
Please reply with your preference by = 1/17.
 
 
 
 
To: "'Eran Hammer-Lahav'" , Torsten Lodderstedt Date: Wed, 12 Jan 2011 13:46:10 -0600 Thread-Topic: [OAUTH-WG] OAuth MAC token type draft Thread-Index: AcuxCvKIPAG8RHKbReG0rfWAAgFAUAAA/ykgAF8qElA= Message-ID: <5710F82C0E73B04FA559560098BF95B12505F04090@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2B7523.5030908@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A5AB74E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB74E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 12 Jan 2011 19:43:55 -0000 Eran, >> - 6.3. Spoofing by Counterfeit Servers >> The protocol does not support server authentication but it should preven= t >> token abuse by the Counterfeit server, shouldn't it? > It does because the token secret is never sent. According to section 6.3 a counterfeit server may intercept client's reques= t. Cannot a counterfeit server use the intercepted signed request for getti= ng access to the resource at the real server? Zachary=20 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, January 10, 2011 4:46 PM To: Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, January 10, 2011 1:08 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft >=20 > Eran, >=20 > - Authentication schemes > You propose to use the authentication scheme name "OAuth2" for the > WWW-Authenticate header but another scheme name "MAC" for the > authorization header. I've never seen such an asymmetric approach before. > Don't you think people get confused about that? Moreover, the bearer draf= t > also uses the name "OAuth2" in the authorization header.=A0 Why this > difference? Why don't you just add some parameters to the "OAuth2" > scheme? This was proposed by James Manger and discussed earlier on the list. I'll l= et James explain it. > - 6.3. Spoofing by Counterfeit Servers > The protocol does not support server authentication but it should prevent > token abuse by the Counterfeit server, shouldn't it? It does because the token secret is never sent. EHL >=20 > regards, > Torsten. >=20 > Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >=20 > Feedback appreciated, especially for section 3.2.1 (the new normalized > request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a > and simplify it. >=20 > No body signature support yet, but will add that in -01. >=20 > EHL >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From igor.faynberg@alcatel-lucent.com Wed Jan 12 11:54:42 2011 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 D198B3A6A90 for ; Wed, 12 Jan 2011 11:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, 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 xJszwenvSRkU for ; Wed, 12 Jan 2011 11:54:40 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 87ED03A6A8B for ; Wed, 12 Jan 2011 11:54:40 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0CJuxIP024719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Jan 2011 13:56:59 -0600 (CST) Received: from [135.244.34.246] (faynberg.lra.lucent.com [135.244.34.246]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p0CJuws7005810; Wed, 12 Jan 2011 13:56:58 -0600 (CST) Message-ID: <4D2E078C.60404@alcatel-lucent.com> Date: Wed, 12 Jan 2011 14:57:00 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2B7523.5030908@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A5AB74E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB74E5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 12 Jan 2011 19:54:42 -0000 Eran, I still don't understand, sorry. Here is the scenario: When a principal that impersonates the resource server gets a token (already signed and ready to go, of course) it can present it to the real resource server and get access to resources. This is what I thought Torsten meant by "token abuse", and what, for sure, I meant. I don't see how this threat is addressed. I do think it must be addressed. The simplest thing, I believe, is always to require server authentication. (This will cover the case of the counterfeit servers, but it would not cover any case in which the token is intercepted or stolen. For the latter case client authentication must be nundatory.) Igor Eran Hammer-Lahav wrote: > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Monday, January 10, 2011 1:08 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] OAuth MAC token type draft >> >> Eran, >> >> - Authentication schemes >> You propose to use the authentication scheme name "OAuth2" for the >> WWW-Authenticate header but another scheme name "MAC" for the >> authorization header. I've never seen such an asymmetric approach before. >> Don't you think people get confused about that? Moreover, the bearer draft >> also uses the name "OAuth2" in the authorization header. Why this >> difference? Why don't you just add some parameters to the "OAuth2" >> scheme? >> > > This was proposed by James Manger and discussed earlier on the list. I'll let James explain it. > > >> - 6.3. Spoofing by Counterfeit Servers >> The protocol does not support server authentication but it should prevent >> token abuse by the Counterfeit server, shouldn't it? >> > > It does because the token secret is never sent. > > EHL > > >> regards, >> Torsten. >> >> Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: >> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token >> >> Feedback appreciated, especially for section 3.2.1 (the new normalized >> request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a >> and simplify it. >> >> No body signature support yet, but will add that in -01. >> >> 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 Wed Jan 12 11:55:22 2011 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 D83EA3A6A8B for ; Wed, 12 Jan 2011 11:55:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, 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 kftYkSG74ZDV for ; Wed, 12 Jan 2011 11:55:16 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 335973A69A4 for ; Wed, 12 Jan 2011 11:55:16 -0800 (PST) Received: (qmail 16374 invoked from network); 12 Jan 2011 19:57:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 12 Jan 2011 19:57:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 12 Jan 2011 12:57:29 -0700 From: Eran Hammer-Lahav To: "Zeltsan, Zachary (Zachary)" , Torsten Lodderstedt Date: Wed, 12 Jan 2011 12:57:26 -0700 Thread-Topic: [OAUTH-WG] OAuth MAC token type draft Thread-Index: AcuxCvKIPAG8RHKbReG0rfWAAgFAUAAA/ykgAF8qElAAAdX20w== Message-ID: In-Reply-To: <5710F82C0E73B04FA559560098BF95B12505F04090@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_C95347A6EEB0eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 12 Jan 2011 19:55:22 -0000 --_000_C95347A6EEB0eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, its still open to a limited MITM attack, but the real issue is of conf= identiality of the request (addressed in 6.2) or blocking the request. The = client request will either: 1. read data 2. write/delete data If the attacker executes the #1, they get to see the result (6.2). If they = execute #2, nothing bad happens because that's just what the user wanted (a= ssuming the body is protected, which is coming in -01). The only problem is= if they attacker does not execute the captured request, but that's just a = DOS attack of sorts (and should be easy to detect). I'll see if I can make this clearer, but at most, a MITM can see confidenti= al data (in which case use TLS), or can block execution. It cannot do anyth= ing other than what the client was trying to do, as-is. EHL On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)" wrote: Eran, >> - 6.3. Spoofing by Counterfeit Servers >> The protocol does not support server authentication but it should preven= t >> token abuse by the Counterfeit server, shouldn't it? > It does because the token secret is never sent. According to section 6.3 a counterfeit server may intercept client's reques= t. Cannot a counterfeit server use the intercepted signed request for getti= ng access to the resource at the real server? Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, January 10, 2011 4:46 PM To: Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, January 10, 2011 1:08 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft > > Eran, > > - Authentication schemes > You propose to use the authentication scheme name "OAuth2" for the > WWW-Authenticate header but another scheme name "MAC" for the > authorization header. I've never seen such an asymmetric approach before. > Don't you think people get confused about that? Moreover, the bearer draf= t > also uses the name "OAuth2" in the authorization header. Why this > difference? Why don't you just add some parameters to the "OAuth2" > scheme? This was proposed by James Manger and discussed earlier on the list. I'll l= et James explain it. > - 6.3. Spoofing by Counterfeit Servers > The protocol does not support server authentication but it should prevent > token abuse by the Counterfeit server, shouldn't it? It does because the token secret is never sent. EHL > > regards, > Torsten. > > Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > Feedback appreciated, especially for section 3.2.1 (the new normalized > request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a > and simplify it. > > No body signature support yet, but will add that in -01. > > 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 --_000_C95347A6EEB0eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] OAuth MAC token type draft Yes, its still open to a limited MITM attack, but the real issue is o= f confidentiality of the request (addressed in 6.2) or blocking the request= . The client request will either:

  1. read data
  2. write/delete data

If the attacker executes the #1, they get to see the result (6.2). If they = execute #2, nothing bad happens because that’s just what the user wan= ted (assuming the body is protected, which is coming in –01). The onl= y problem is if they attacker does not execute the captured request, but th= at’s just a DOS attack of sorts (and should be easy to detect).

I’ll see if I can make this clearer, but at most, a MITM can see conf= idential data (in which case use TLS), or can block execution. It cannot do= anything other than what the client was trying to do, as-is.

EHL




On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com&= gt; wrote:

Eran,

>> - 6.3. Spoofing by Counterfeit Servers
>> The protocol does not support server authentication but it should = prevent
>> token abuse by the Counterfeit server, shouldn't it?

> It does because the token secret is never sent.

According to section 6.3 a counterfeit server may intercept client's reques= t. Cannot a counterfeit server use the intercepted signed request for getti= ng access to the resource at the real server?

Zachary

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On B= ehalf Of Eran Hammer-Lahav
Sent: Monday, January 10, 2011 4:46 PM
To: Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth MAC token type draft



> -----Original Message-----
> From: Torsten Lodderstedt [= mailto:torsten@lodderstedt.net]
> Sent: Monday, January 10, 2011 1:08 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] OAuth MAC token type draft
>
> Eran,
>
> - Authentication schemes
> You propose to use the authentication scheme name "OAuth2" f= or the
> WWW-Authenticate header but another scheme name "MAC" for th= e
> authorization header. I've never seen such an asymmetric approach befo= re.
> Don't you think people get confused about that? Moreover, the bearer d= raft
> also uses the name "OAuth2" in the authorization header.=A0 = Why this
> difference? Why don't you just add some parameters to the "OAuth2= "
> scheme?

This was proposed by James Manger and discussed earlier on the list. I'll l= et James explain it.

> - 6.3. Spoofing by Counterfeit Servers
> The protocol does not support server authentication but it should prev= ent
> token abuse by the Counterfeit server, shouldn't it?

It does because the token secret is never sent.

EHL

>
> regards,
> Torsten.
>
> Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav:
> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>
> Feedback appreciated, especially for section 3.2.1 (the new normalized=
> request string) which is an attempt to take the HMAC-SHA1 flow from 1.= 0a
> and simplify it.
>
> No body signature support yet, but will add that in -01.
>
> EHL
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ie= tf.org/mailman/listinfo/oauth

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

--_000_C95347A6EEB0eranhueniversecom_-- From torsten@lodderstedt.net Wed Jan 12 12:33:37 2011 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 2810B3A69C5 for ; Wed, 12 Jan 2011 12:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu8dkG5wKuyi for ; Wed, 12 Jan 2011 12:33:36 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id 5913F3A6A93 for ; Wed, 12 Jan 2011 12:33:36 -0800 (PST) Received: from [87.142.243.222] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Pd7QA-0006cg-Un; Wed, 12 Jan 2011 21:35:54 +0100 Message-ID: <4D2E10AB.3000701@lodderstedt.net> Date: Wed, 12 Jan 2011 21:35:55 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Brian Eaton References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <5CD15420-0309-4D44-A2F8-F256FCE2C299@oracle.com> <4D2CDD3C.1010801@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 12 Jan 2011 20:33:37 -0000 Am 12.01.2011 01:43, schrieb Brian Eaton: > On Tue, Jan 11, 2011 at 2:44 PM, Torsten Lodderstedt > wrote: >> Do you see any need to restrict the power of this token or is it as powerful >> as the tokens obtained using the code? I'm asking because this token is sent >> out without authenticating the client whereas exchange of code to tokens can >> be authenticated. A malicious client app could initiate the hybrid >> authorization process in a browser (embedded or external), pretend to be a >> legitimate client and obtain the token from the redirect_uri after the >> redirect. > This is a good point, I think there are a set of people who won't > deploy the user-agent flow because it returns a token without seeing > the client secret. > > They might choose to support the user-agent flow, but return less > privileged tokens. I doubt we could standardize anything like that. I would not want to standardize it either. My suggesstion would be to add a respective note to the security considerations. Based on that every deployment shall decide how to handle it. regards, Torsten. From torsten@lodderstedt.net Wed Jan 12 12:38:11 2011 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 59A7A3A6A96 for ; Wed, 12 Jan 2011 12:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-y32iKghHKk for ; Wed, 12 Jan 2011 12:38:05 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id EB6CD3A69A4 for ; Wed, 12 Jan 2011 12:38:04 -0800 (PST) Received: from [87.142.243.222] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Pd7UV-0004Ec-F4; Wed, 12 Jan 2011 21:40:23 +0100 Message-ID: <4D2E11B8.4040303@lodderstedt.net> Date: Wed, 12 Jan 2011 21:40:24 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050106090505060107060007" X-Df-Sender: torsten@lodderstedt-online.de Cc: "Zeltsan, Zachary \(Zachary\)" , OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 12 Jan 2011 20:38:11 -0000 This is a multi-part message in MIME format. --------------050106090505060107060007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Shouldn't signature verification fail on the real server because of different hostnames/ports? regards, Torsten. Am 12.01.2011 20:57, schrieb Eran Hammer-Lahav: > Yes, its still open to a limited MITM attack, but the real issue is of > confidentiality of the request (addressed in 6.2) or blocking the > request. The client request will either: > > 1. read data > 2. write/delete data > > > If the attacker executes the #1, they get to see the result (6.2). If > they execute #2, nothing bad happens because that's just what the user > wanted (assuming the body is protected, which is coming in --01). The > only problem is if they attacker does not execute the captured > request, but that's just a DOS attack of sorts (and should be easy to > detect). > > I'll see if I can make this clearer, but at most, a MITM can see > confidential data (in which case use TLS), or can block execution. It > cannot do anything other than what the client was trying to do, as-is. > > EHL > > > > > On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)" > wrote: > > Eran, > > >> - 6.3. Spoofing by Counterfeit Servers > >> The protocol does not support server authentication but it > should prevent > >> token abuse by the Counterfeit server, shouldn't it? > > > It does because the token secret is never sent. > > According to section 6.3 a counterfeit server may intercept > client's request. Cannot a counterfeit server use the intercepted > signed request for getting access to the resource at the real server? > > Zachary > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf Of Eran Hammer-Lahav > Sent: Monday, January 10, 2011 4:46 PM > To: Torsten Lodderstedt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft > > > > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: Monday, January 10, 2011 1:08 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] OAuth MAC token type draft > > > > Eran, > > > > - Authentication schemes > > You propose to use the authentication scheme name "OAuth2" for the > > WWW-Authenticate header but another scheme name "MAC" for the > > authorization header. I've never seen such an asymmetric approach > before. > > Don't you think people get confused about that? Moreover, the > bearer draft > > also uses the name "OAuth2" in the authorization header. Why this > > difference? Why don't you just add some parameters to the "OAuth2" > > scheme? > > This was proposed by James Manger and discussed earlier on the > list. I'll let James explain it. > > > - 6.3. Spoofing by Counterfeit Servers > > The protocol does not support server authentication but it should > prevent > > token abuse by the Counterfeit server, shouldn't it? > > It does because the token secret is never sent. > > EHL > > > > > regards, > > Torsten. > > > > Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > > > Feedback appreciated, especially for section 3.2.1 (the new > normalized > > request string) which is an attempt to take the HMAC-SHA1 flow > from 1.0a > > and simplify it. > > > > No body signature support yet, but will add that in -01. > > > > 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 > --------------050106090505060107060007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Shouldn't signature verification fail on the real server because of different hostnames/ports?

regards,
Torsten.

Am 12.01.2011 20:57, schrieb Eran Hammer-Lahav:
Re: [OAUTH-WG] OAuth MAC token type draft Yes, its still open to a limited MITM attack, but the real issue is of confidentiality of the request (addressed in 6.2) or blocking the request. The client request will either:
  1. read data
  2. write/delete data

If the attacker executes the #1, they get to see the result (6.2). If they execute #2, nothing bad happens because that’s just what the user wanted (assuming the body is protected, which is coming in –01). The only problem is if they attacker does not execute the captured request, but that’s just a DOS attack of sorts (and should be easy to detect).

I’ll see if I can make this clearer, but at most, a MITM can see confidential data (in which case use TLS), or can block execution. It cannot do anything other than what the client was trying to do, as-is.

EHL




On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> wrote:
Eran,

>> - 6.3. Spoofing by Counterfeit Servers
>> The protocol does not support server authentication but it should prevent
>> token abuse by the Counterfeit server, shouldn't it?

> It does because the token secret is never sent.

According to section 6.3 a counterfeit server may intercept client's request. Cannot a counterfeit server use the intercepted signed request for getting access to the resource at the real server?

Zachary

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, January 10, 2011 4:46 PM
To: Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth MAC token type draft



> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Monday, January 10, 2011 1:08 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] OAuth MAC token type draft
>
> Eran,
>
> - Authentication schemes
> You propose to use the authentication scheme name "OAuth2" for the
> WWW-Authenticate header but another scheme name "MAC" for the
> authorization header. I've never seen such an asymmetric approach before.
> Don't you think people get confused about that? Moreover, the bearer draft
> also uses the name "OAuth2" in the authorization header.  Why this
> difference? Why don't you just add some parameters to the "OAuth2"
> scheme?

This was proposed by James Manger and discussed earlier on the list. I'll let James explain it.

> - 6.3. Spoofing by Counterfeit Servers
> The protocol does not support server authentication but it should prevent
> token abuse by the Counterfeit server, shouldn't it?

It does because the token secret is never sent.

EHL

>
> regards,
> Torsten.
>
> Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav:
> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>
> Feedback appreciated, especially for section 3.2.1 (the new normalized
> request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a
> and simplify it.
>
> No body signature support yet, but will add that in -01.
>
> 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


--------------050106090505060107060007-- From torsten@lodderstedt.net Wed Jan 12 13:03:54 2011 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 73BCE3A6A9B for ; Wed, 12 Jan 2011 13:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwF8mDkfT9Vq for ; Wed, 12 Jan 2011 13:03:53 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by core3.amsl.com (Postfix) with ESMTP id CCDBE3A6A82 for ; Wed, 12 Jan 2011 13:03:52 -0800 (PST) Received: from [87.142.243.222] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Pd7tR-0002a8-PI; Wed, 12 Jan 2011 22:06:09 +0100 Message-ID: <4D2E17C2.60205@lodderstedt.net> Date: Wed, 12 Jan 2011 22:06:10 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Richer, Justin P." References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> , In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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, 12 Jan 2011 21:03:54 -0000 +1 for option 2 because it will facilitates security analysis of the protocol. From a security analysis perspective, I think we need two views: 1) A structural view, describing the OAuth architecture (entities, interfaces, communication paths) and 2) a flow-oriented view, which is built based on this interfaces, this is where the more complex threats show up. For example, the session fixation attack makes use of properties of the flow along both OAuth end-points. I assume a structural view will given as well? I agree with Marius regarding naming. I don't believe we can forsee today which clients will be authenticated in the future and which not. I could imagine deployments with support for web applications w/o authentication. It depends on the security policy and the value someone sees in client authentication (for the purpose of client authorization). On the other hand, by using dynamically created client_ids and secrets, even native apps could authenticate to the authorization server. regards, Torsten. Am 12.01.2011 16:15, schrieb Richer, Justin P.: > Marius makes a good point -- we probably want to avoid using language like that for part descriptions. I don't think "code" and "token" quite get it, but I don't have a better suggestion at the moment though... > > -- Justin > ________________________________________ > From: Marius Scurtescu [mscurtescu@google.com] > Sent: Wednesday, January 12, 2011 10:10 AM > To: Richer, Justin P. > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 > > +1 for option 2 as well > > Not convinced that naming the main flows Authenticated and > Unauthenticated makes sense, I think it will only increase confusion. > For example, native apps are not authenticated and they would be using > the "Authenticated" flow. I think we should stick with something along > the lines of "Code" and "Token". > > Marius > > > > On Wed, Jan 12, 2011 at 10:02 AM, Richer, Justin P. wrote: >> +1 for option 2 >> >> I see, and have always seen, the target audience as server and client developers who are likely to be working against one flow and use case at a time. Also, I disagree that the primary role of the server developer is the security considerations. In theory, you may be right, but in practice, I think you'll find that many are going to be more concerned with just making it work at all with their API/framework/server. >> >> -- Justin >> ________________________________________ >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav [eran@hueniverse.com] >> Sent: Wednesday, January 12, 2011 2:19 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 >> >> (Vote at the end, please read) >> >> Background >> >> Between draft -00 and -05 the document used a flow-based organization. This was changed to an endpoint-based organization in draft -06. I have received requests to go back to the flow-based organization, and with -12, have been planning to do that. It is important to note that -12 is not meant to include any change in normative language and that -11 code would remain unchanged under -12. This is purely editorial. >> >> Part of that effort included reviewing the various flows in -05. The flow categories and definitions have always been a source of confusion. Some target specific client architecture (user-agent, web server, device), some are abstractions for future extensibility (assertion), and some are useful features that can apply to a wide range of clients (client credentials, username and password). We also have the odd anti-profile of the native application flow, which in practice is a half-baked guide to navigating the entire range of flows. >> >> In practice we have a few ways to get an access token which can be categorized in multiple ways: >> >> >> 1. How authorization is obtained? >> >> a. Redirection-based – user-agent, web-server >> >> b. Direct credentials – client credentials, username and password, assertion >> >> 2. Is the client authenticated? >> >> a. Yes – web-server, client credentials, username and password, assertion (based on type) >> >> b. No – user-agent, assertion (based on type) >> >> In the past we had another (broken) organization of User delegation, User credentials, and Autonomous. >> >> Analysis >> >> After studying the document and breaking it apart (in my editor) I came to a few conclusions (which you are invited to disprove): >> >> >> 1. Flow names must be consistent and based on the key differentiator of each flow. I believe the ability of the client to authenticate is the most significant aspect of each flow. I agree that ease of deployment and performance are important, but this is a security protocol and the security considerations should be the primary attribute used to select flows. >> >> 2. The endpoint-based organization turned a few discrete flows into a single protocol. This protocol should be profiled based on some key client characteristics (such as redirection and ability of the client to authenticate). The main objective of the profiles would be to provide a security-focused description. >> >> 3. The hybrid flow, combining the user-agent and web-server into a code-and-token solution is a distinct profile with its own unique security properties. While its implementation details are important for efficiency, the main differentiator is the client dual nature of being able to maintain secret credentials in some parts, but not in others. It produces two access tokens using a single authorization and client identifier. >> >> 4. The document must not repeat the mistake of 1.0, focusing on a single client type at the expense of others. OAuth 1.0 focused on the web-server flow and treated everything else as second class citizens. -05 treated native applications similarly, giving much more attentions to the web-server and user-agent clients, even when their underlying flows could have been written primarily for some native applications. The issue is mostly in naming the profiles after one typical client type instead of their key property. >> >> Options >> >> I came up with two options for finalizing the specification’s structure (please feel to suggest additional ideas): >> >> >> 1. Keep the document’s endpoint-based organization (-11) and add a Client Profiles section describing specific client implementations based on the protocol. These profiles will not include wire information (parameters, values, etc.), but will include security-minded normative language (MUST register, SHOULD match redirection URI, etc.). >> >> 2. Switch back to flow-based organization and include 5 flows in 2 groups (note the new names), plus extensions: >> >> a. Redirection-based >> >> i. Authenticated client (web server) >> >> ii. Unauthenticated client (user-agent) >> >> iii. Mix authentication client (code-and-token) >> >> b. Direct Credentials >> >> i. Username and password >> >> ii. Client credentials >> >> c. Extensions >> >> Option 1 >> >> - Easier for server developers because it will include all the wire-protocol details for each endpoint in one place (single list of parameters, error codes, etc.). >> >> - Shorter, no repeating the same examples, parameters, and error definitions for each flow. >> >> - Reads like a reference. >> >> - Client developers are instructed which parameter values to use. >> >> - Server developer focus helps make security-based decisions (which are primarily the role of the server developer in OAuth). >> >> Option 2 >> >> - Easier for client developers focused on one flow at a time. >> >> - Longer, duplicating examples, parameters, and error definitions. Currently about 20-30 more pages. >> >> - Reads like a narrative / tutorial. >> >> - Client developers are instructed which client flow to use. >> >> - Client developer focus helps novice developers interoperate with protected resources. >> >> I don’t believe there is an obvious winner here because we each have a bias based on who we believe is the primary target audience (after all, this is a purely editorial decision – the protocol itself is mostly complete). In addition, I have done 80% of the work to get -12 to option 2 so it is no longer about investing the time in the transition. >> >> Vote >> >> Given the stable state of the specification, this might be the last big decision we get to make about the main specification. I’ve been planning to just come up with a new draft and ask for feedback but I rather take another week and ask this explicitly. >> >> Which option do you prefer (or suggest another)? >> >> Please reply with your preference by 1/17. >> >> 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 Wed Jan 12 13:05:20 2011 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 1C1013A6A82 for ; Wed, 12 Jan 2011 13:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yegcre-XdcSw for ; Wed, 12 Jan 2011 13:05:19 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.29.7]) by core3.amsl.com (Postfix) with ESMTP id D1E7C3A69C5 for ; Wed, 12 Jan 2011 13:05:18 -0800 (PST) Received: from [87.142.243.222] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Pd7us-000408-E1; Wed, 12 Jan 2011 22:07:38 +0100 Message-ID: <4D2E181B.90400@lodderstedt.net> Date: Wed, 12 Jan 2011 22:07:39 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Richer, Justin P." References: , <4D2CD83D.2010507@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? 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, 12 Jan 2011 21:05:20 -0000 thank you for your feedback. So you would suggest to let the authorization server auto-detect the correct type? regards, Torsten. Am 12.01.2011 15:43, schrieb Richer, Justin P.: > I don't quite understand the need for "token_type" in the request. The token being presented is going to have a type associated with it on the server -- that is, that text blob is going to have been issued by the server as an access token or a refresh token, no matter what the client claims in this request. Seems like this is at best an optional sanity check. > > Unless of course you want to revoke all "related" tokens at once, in which case I think you need a different mechanism to do so. > > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt [torsten@lodderstedt.net] > Sent: Tuesday, January 11, 2011 5:22 PM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? > > I just posted a new revision of > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/. > Please consider it for the re-chartering process. > > Additionally, Mark and me are still working on the security document. It > takes longer time than expected because of the topic's inherent > complexity. We plan to have a new revision ready for IETF-80. > > regards, > Torsten. > > Am 10.01.2011 10:55, schrieb Hannes Tschofenig: >> Hi all, >> >> In preparing the charter text we need your feedback. >> >> First, the new charter needs to include the two new items we had already accepted, namely >> * SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 >> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ >> * The OAuth 2.0 Protocol: Bearer Tokens >> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >> >> In the past (around September / October 2010 timeframe) we had also discussed other proposals. See attachment below. >> >> We cannot just add everything to the charter because we will never be able to finish it. >> To make it more complicated there were other proposals floating around but no drafts are available (e.g. security, discovery). >> >> It would be great to have a complete list of documents that should be considered. >> We would suggest to wait till the end of the month for new document submissions to show up. >> >> Then, we will start a Doodle poll to see your preference. >> >> Ciao >> Hannes& Blaine >> >> PS: Here are some of the other documents that people wanted to spend time on. There are more on the OAuth WG page. >> >> * Messaging Signing >> Examples: >> http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ >> http://www.ietf.org/mail-archive/web/oauth/current/msg04250.html >> >> * User Experience Extensions >> Example: >> http://datatracker.ietf.org/doc/draft-recordon-oauth-v2-ux/ >> >> * Artifact Binding >> Example: >> http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ >> >> * Dynamic Client Registration >> Example: >> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >> >> * Token Revocation: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >> >> * Use Cases >> http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From zachary.zeltsan@alcatel-lucent.com Wed Jan 12 13:10:29 2011 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 3B3BF3A6A91 for ; Wed, 12 Jan 2011 13:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 gvYIqbPu0xYI for ; Wed, 12 Jan 2011 13:10:22 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id C9EB93A6A9B for ; Wed, 12 Jan 2011 13:10:21 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0CLCed1026671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Jan 2011 15:12:40 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p0CLCe3J019632 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Jan 2011 15:12:40 -0600 Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 12 Jan 2011 15:12:40 -0600 From: "Zeltsan, Zachary (Zachary)" To: "'Torsten Lodderstedt'" , Eran Hammer-Lahav Date: Wed, 12 Jan 2011 15:12:39 -0600 Thread-Topic: [OAUTH-WG] OAuth MAC token type draft Thread-Index: AcuymPOmLdak3p4TR0yOhocRhe1mwAAARYTw Message-ID: <5710F82C0E73B04FA559560098BF95B12505F04091@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> References: <4D2E11B8.4040303@lodderstedt.net> In-Reply-To: <4D2E11B8.4040303@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5710F82C0E73B04FA559560098BF95B12505F04091USNAVSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 12 Jan 2011 21:10:29 -0000 --_000_5710F82C0E73B04FA559560098BF95B12505F04091USNAVSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It should not fail because the intercepted signed request included the hos= tname and port of the real resource server. Zachary ________________________________ From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Wednesday, January 12, 2011 3:40 PM To: Eran Hammer-Lahav Cc: Zeltsan, Zachary (Zachary); OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft Shouldn't signature verification fail on the real server because of differe= nt hostnames/ports? regards, Torsten. Am 12.01.2011 20:57, schrieb Eran Hammer-Lahav: Yes, its still open to a limited MITM attack, but the real issue is of conf= identiality of the request (addressed in 6.2) or blocking the request. The = client request will either: 1. read data 2. write/delete data If the attacker executes the #1, they get to see the result (6.2). If they = execute #2, nothing bad happens because that's just what the user wanted (a= ssuming the body is protected, which is coming in -01). The only problem is= if they attacker does not execute the captured request, but that's just a = DOS attack of sorts (and should be easy to detect). I'll see if I can make this clearer, but at most, a MITM can see confidenti= al data (in which case use TLS), or can block execution. It cannot do anyth= ing other than what the client was trying to do, as-is. EHL On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)" wrote: Eran, >> - 6.3. Spoofing by Counterfeit Servers >> The protocol does not support server authentication but it should preven= t >> token abuse by the Counterfeit server, shouldn't it? > It does because the token secret is never sent. According to section 6.3 a counterfeit server may intercept client's reques= t. Cannot a counterfeit server use the intercepted signed request for getti= ng access to the resource at the real server? Zachary -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Monday, January 10, 2011 4:46 PM To: Torsten Lodderstedt Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, January 10, 2011 1:08 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft > > Eran, > > - Authentication schemes > You propose to use the authentication scheme name "OAuth2" for the > WWW-Authenticate header but another scheme name "MAC" for the > authorization header. I've never seen such an asymmetric approach before. > Don't you think people get confused about that? Moreover, the bearer draf= t > also uses the name "OAuth2" in the authorization header. Why this > difference? Why don't you just add some parameters to the "OAuth2" > scheme? This was proposed by James Manger and discussed earlier on the list. I'll l= et James explain it. > - 6.3. Spoofing by Counterfeit Servers > The protocol does not support server authentication but it should prevent > token abuse by the Counterfeit server, shouldn't it? It does because the token secret is never sent. EHL > > regards, > Torsten. > > Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > Feedback appreciated, especially for section 3.2.1 (the new normalized > request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a > and simplify it. > > No body signature support yet, but will add that in -01. > > 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 --_000_5710F82C0E73B04FA559560098BF95B12505F04091USNAVSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [OAUTH-WG] OAuth MAC token type draft

 It should not fail because the i= ntercepted signed request included the hostname and port of the real resource server. =

 

Zachary

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Wednesday, January 12,= 2011 3:40 PM
To: Eran Hammer-Lahav
Cc: Zeltsan, Zachary (Zachar= y); OAuth WG
Subject: Re: [OAUTH-WG] OAut= h MAC token type draft

=  

= Shouldn't signature verification fail on the rea= l server because of different hostnames/ports?

regards,
Torsten.

Am 12.01.2011 20:57, schrieb Eran Hammer-Lahav:

Yes, it= s still open to a limited MITM attack, but the real issue is of confidentiality of = the request (addressed in 6.2) or blocking the request. The client request will either:

  1. <= span style=3D'font-size:11.0pt;font-family:Calibri'>read data
  2. <= span style=3D'font-size:11.0pt;font-family:Calibri'>write/delete data


If the attacker executes the #1, they get to see the result (6.2). If they execute #2, nothing bad happens because that’s just what the user wan= ted (assuming the body is protected, which is coming in –01). The only problem is if they attacker does not execute the captured request, but that’s just a DOS attack of sorts (and should be easy to detect).

I’ll see if I can make this clearer, but at most, a MITM can see confidential data (in which case use TLS), or can block execution. It canno= t do anything other than what the client was trying to do, as-is.

EHL




On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)" <zachary.= zeltsan@alcatel-lucent.com> wrote:

Eran,
>> - 6.3. Spoofing by Counterfeit Servers
>> The protocol does not support server authentication but it should prevent
>> token abuse by the Counterfeit server, shouldn't it?

> It does because the token secret is never sent.

According to section 6.3 a counterfeit server may intercept client's reques= t. Cannot a counterfeit server use the intercepted signed request for getting access to the resource at the real server?

Zachary

-----Original Message-----
From: oauth-bounc= es@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, January 10, 2011 4:46 PM
To: Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth MAC token type draft



> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Monday, January 10, 2011 1:08 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] OAuth MAC token type draft
>
> Eran,
>
> - Authentication schemes
> You propose to use the authentication scheme name "OAuth2" f= or the
> WWW-Authenticate header but another scheme name "MAC" for th= e
> authorization header. I've never seen such an asymmetric approach befo= re.
> Don't you think people get confused about that? Moreover, the bearer d= raft
> also uses the name "OAuth2" in the authorization header.&nbs= p; Why this
> difference? Why don't you just add some parameters to the "OAuth2"
> scheme?

This was proposed by James Manger and discussed earlier on the list. I'll l= et James explain it.

> - 6.3. Spoofing by Counterfeit Servers
> The protocol does not support server authentication but it should prev= ent
> token abuse by the Counterfeit server, shouldn't it?

It does because the token secret is never sent.

EHL

>
> regards,
> Torsten.
>
> Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav:
> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac= -token
>
> Feedback appreciated, especially for section 3.2.1 (the new normalized=
> request string) which is an attempt to take the HMAC-SHA1 flow from 1.= 0a
> and simplify it.
>
> No body signature support yet, but will add that in -01.
>
> 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

=  

--_000_5710F82C0E73B04FA559560098BF95B12505F04091USNAVSXCHMBSA_-- From torsten@lodderstedt.net Wed Jan 12 13:15:12 2011 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 427923A6A91 for ; Wed, 12 Jan 2011 13:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhjlO8d2d2rg for ; Wed, 12 Jan 2011 13:15:06 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.40]) by core3.amsl.com (Postfix) with ESMTP id 3813D3A69C5 for ; Wed, 12 Jan 2011 13:15:06 -0800 (PST) Received: from [87.142.243.222] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Pd84K-0002ln-7e; Wed, 12 Jan 2011 22:17:24 +0100 Message-ID: <4D2E1A64.9040205@lodderstedt.net> Date: Wed, 12 Jan 2011 22:17:24 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Zeltsan, Zachary (Zachary)" References: <4D2E11B8.4040303@lodderstedt.net> <5710F82C0E73B04FA559560098BF95B12505F04091@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> In-Reply-To: <5710F82C0E73B04FA559560098BF95B12505F04091@USNAVSXCHMBSA3.ndc.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------020504040301000504030908" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 12 Jan 2011 21:15:12 -0000 This is a multi-part message in MIME format. --------------020504040301000504030908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ok, understood, I had a proxying server with another address in mind. You assume an attack on unencrypted channels, which could by prevented using HTTPS (as Eran described). regards, Torsten. Am 12.01.2011 22:12, schrieb Zeltsan, Zachary (Zachary): > > It should not fail because the intercepted signed request included > the hostname and port of the real resource server. > > Zachary > > ------------------------------------------------------------------------ > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Wednesday, January 12, 2011 3:40 PM > *To:* Eran Hammer-Lahav > *Cc:* Zeltsan, Zachary (Zachary); OAuth WG > *Subject:* Re: [OAUTH-WG] OAuth MAC token type draft > > Shouldn't signature verification fail on the real server because of > different hostnames/ports? > > regards, > Torsten. > > Am 12.01.2011 20:57, schrieb Eran Hammer-Lahav: > > Yes, its still open to a limited MITM attack, but the real issue is of > confidentiality of the request (addressed in 6.2) or blocking the > request. The client request will either: > > 1. read data > 2. write/delete data > > > If the attacker executes the #1, they get to see the result (6.2). If > they execute #2, nothing bad happens because that's just what the user > wanted (assuming the body is protected, which is coming in --01). The > only problem is if they attacker does not execute the captured > request, but that's just a DOS attack of sorts (and should be easy to > detect). > > I'll see if I can make this clearer, but at most, a MITM can see > confidential data (in which case use TLS), or can block execution. It > cannot do anything other than what the client was trying to do, as-is. > > EHL > > > > > On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)" > wrote: > > Eran, > > >> - 6.3. Spoofing by Counterfeit Servers > >> The protocol does not support server authentication but it should > prevent > >> token abuse by the Counterfeit server, shouldn't it? > > > It does because the token secret is never sent. > > According to section 6.3 a counterfeit server may intercept client's > request. Cannot a counterfeit server use the intercepted signed > request for getting access to the resource at the real server? > > Zachary > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Monday, January 10, 2011 4:46 PM > To: Torsten Lodderstedt > Cc: OAuth WG > Subject: Re: [OAUTH-WG] OAuth MAC token type draft > > > > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: Monday, January 10, 2011 1:08 PM > > To: Eran Hammer-Lahav > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] OAuth MAC token type draft > > > > Eran, > > > > - Authentication schemes > > You propose to use the authentication scheme name "OAuth2" for the > > WWW-Authenticate header but another scheme name "MAC" for the > > authorization header. I've never seen such an asymmetric approach before. > > Don't you think people get confused about that? Moreover, the bearer > draft > > also uses the name "OAuth2" in the authorization header. Why this > > difference? Why don't you just add some parameters to the "OAuth2" > > scheme? > > This was proposed by James Manger and discussed earlier on the list. > I'll let James explain it. > > > - 6.3. Spoofing by Counterfeit Servers > > The protocol does not support server authentication but it should prevent > > token abuse by the Counterfeit server, shouldn't it? > > It does because the token secret is never sent. > > EHL > > > > > regards, > > Torsten. > > > > Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav: > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > > > Feedback appreciated, especially for section 3.2.1 (the new normalized > > request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a > > and simplify it. > > > > No body signature support yet, but will add that in -01. > > > > 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 > --------------020504040301000504030908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ok, understood, I had a proxying server with another address in mind.

You assume an attack on unencrypted channels, which could by prevented using HTTPS (as Eran described).

regards,
Torsten.

Am 12.01.2011 22:12, schrieb Zeltsan, Zachary (Zachary):
Re: [OAUTH-WG] OAuth MAC token type draft

 It should not fail because the intercepted signed request included the hostname and port of the real resource server.

 

Zachary

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Wednesday, January 12, 2011 3:40 PM
To: Eran Hammer-Lahav
Cc: Zeltsan, Zachary (Zachary); OAuth WG
Subject: Re: [OAUTH-WG] OAuth MAC token type draft

 

Shouldn't signature verification fail on the real server because of different hostnames/ports?

regards,
Torsten.

Am 12.01.2011 20:57, schrieb Eran Hammer-Lahav:

Yes, its still open to a limited MITM attack, but the real issue is of confidentiality of the request (addressed in 6.2) or blocking the request. The client request will either:

  1. read data
  2. write/delete data


If the attacker executes the #1, they get to see the result (6.2). If they execute #2, nothing bad happens because that’s just what the user wanted (assuming the body is protected, which is coming in –01). The only problem is if they attacker does not execute the captured request, but that’s just a DOS attack of sorts (and should be easy to detect).

I’ll see if I can make this clearer, but at most, a MITM can see confidential data (in which case use TLS), or can block execution. It cannot do anything other than what the client was trying to do, as-is.

EHL




On 1/12/11 11:46 AM, "Zeltsan, Zachary (Zachary)" <zachary.zeltsan@alcatel-lucent.com> wrote:

Eran,

>> - 6.3. Spoofing by Counterfeit Servers
>> The protocol does not support server authentication but it should prevent
>> token abuse by the Counterfeit server, shouldn't it?

> It does because the token secret is never sent.

According to section 6.3 a counterfeit server may intercept client's request. Cannot a counterfeit server use the intercepted signed request for getting access to the resource at the real server?

Zachary

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Monday, January 10, 2011 4:46 PM
To: Torsten Lodderstedt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] OAuth MAC token type draft



> -----Original Message-----
> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
> Sent: Monday, January 10, 2011 1:08 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] OAuth MAC token type draft
>
> Eran,
>
> - Authentication schemes
> You propose to use the authentication scheme name "OAuth2" for the
> WWW-Authenticate header but another scheme name "MAC" for the
> authorization header. I've never seen such an asymmetric approach before.
> Don't you think people get confused about that? Moreover, the bearer draft
> also uses the name "OAuth2" in the authorization header.  Why this
> difference? Why don't you just add some parameters to the "OAuth2"
> scheme?

This was proposed by James Manger and discussed earlier on the list. I'll let James explain it.

> - 6.3. Spoofing by Counterfeit Servers
> The protocol does not support server authentication but it should prevent
> token abuse by the Counterfeit server, shouldn't it?

It does because the token secret is never sent.

EHL

>
> regards,
> Torsten.
>
> Am 09.01.2011 18:18, schrieb Eran Hammer-Lahav:
> http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token
>
> Feedback appreciated, especially for section 3.2.1 (the new normalized
> request string) which is an attempt to take the HMAC-SHA1 flow from 1.0a
> and simplify it.
>
> No body signature support yet, but will add that in -01.
>
> 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

 


--------------020504040301000504030908-- From jbhate@exacttarget.com Wed Jan 12 13:19:54 2011 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 A87DF3A6A82 for ; Wed, 12 Jan 2011 13:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdChddlpPbIe for ; Wed, 12 Jan 2011 13:19:53 -0800 (PST) Received: from hub02.exacttarget.com (hub02.exacttarget.com [207.67.98.220]) by core3.amsl.com (Postfix) with ESMTP id 7624A3A6774 for ; Wed, 12 Jan 2011 13:19:50 -0800 (PST) From: Jitesh Bhate To: "OAuth@ietf.org" Date: Wed, 12 Jan 2011 16:22:07 -0500 Thread-Topic: xAuth use in OAuth2.0? Thread-Index: AcuynsQPDcBMnvbKT7W3QFXor+tr9A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: IgA= dok= Ayqa CGbW CSHs Chgo C44+ Dytm Fsyw IyV2 JelJ KoOI K+NU LFDh LyDk MJlh; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {4B5B93CF-E551-45B6-A56A-D7B0B20E33C3}; agBiAGgAYQB0AGUAQABlAHgAYQBjAHQAdABhAHIAZwBlAHQALgBjAG8AbQA=; Wed, 12 Jan 2011 21:22:07 GMT;eABBAHUAdABoACAAdQBzAGUAIABpAG4AIABPAEEAdQB0AGgAMgAuADAAPwA= x-cr-puzzleid: {4B5B93CF-E551-45B6-A56A-D7B0B20E33C3} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A72BD02C502A0F48AFA56C4A84CB23E579CFAA7265ETINMBCLUSTER_" MIME-Version: 1.0 Subject: [OAUTH-WG] xAuth use in OAuth2.0? 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, 12 Jan 2011 21:19:54 -0000 --_000_A72BD02C502A0F48AFA56C4A84CB23E579CFAA7265ETINMBCLUSTER_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there any provision in OAuth2.0 specs. to use xAuth to exchange a usern= ame and password for an OAuth access token? Something twitter does using OAuth 1.0 http://dev.twitter.com/pages/xauth Regards Jitesh --_000_A72BD02C502A0F48AFA56C4A84CB23E579CFAA7265ETINMBCLUSTER_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Is there any provision  in OAuth2.0 specs. t= o use xAuth to exchange a username and password for an OAuth access token?<= o:p>

Something twitter does using OAuth 1.0 <= a href=3D"http://dev.twitter.com/pages/xauth">http://dev.twitter.com/pages/= xauth

 

Regards

Jitesh

= --_000_A72BD02C502A0F48AFA56C4A84CB23E579CFAA7265ETINMBCLUSTER_-- From jricher@mitre.org Wed Jan 12 13:20:16 2011 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 2E1F73A67AA for ; Wed, 12 Jan 2011 13:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.666 X-Spam-Level: X-Spam-Status: No, score=-3.666 tagged_above=-999 required=5 tests=[AWL=-1.067, 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 Wr4IuuOZpSCU for ; Wed, 12 Jan 2011 13:20:15 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id CF4E53A6774 for ; Wed, 12 Jan 2011 13:20:14 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1C7BD21B07AB; Wed, 12 Jan 2011 16:22:35 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1609221B0045; Wed, 12 Jan 2011 16:22:35 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Wed, 12 Jan 2011 16:21:40 -0500 From: "Richer, Justin P." To: Torsten Lodderstedt Date: Wed, 12 Jan 2011 16:19:27 -0500 Thread-Topic: [OAUTH-WG] Re-Chartering: What Items to work on? Thread-Index: AcuynL8lvMCT9PbeQ+WdBpYv52Wg9gAAaXG5 Message-ID: References: , <4D2CD83D.2010507@lodderstedt.net> , <4D2E181B.90400@lodderstedt.net> In-Reply-To: <4D2E181B.90400@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? 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, 12 Jan 2011 21:20:16 -0000 Yes, let the server do the work. In practice, it's going to be looking up t= he token based on the token value anyway (for bearer tokens, at least). All= the client really cares about is asking to "revoke this token that I am se= nding you". If the client credentials and token are correct and verifiable,= then the revoke should go through. A client wanting to revoke both a reque= st token and an access token will have to make several calls to this, unles= s you want to put in a way to put multiple token values in. I don't recomme= nd that though, as it seems to me an optimization for a problem nobody has = yet. -- Justin ________________________________________ From: Torsten Lodderstedt [torsten@lodderstedt.net] Sent: Wednesday, January 12, 2011 4:07 PM To: Richer, Justin P. Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? thank you for your feedback. So you would suggest to let the authorization server auto-detect the correct type? regards, Torsten. Am 12.01.2011 15:43, schrieb Richer, Justin P.: > I don't quite understand the need for "token_type" in the request. The to= ken being presented is going to have a type associated with it on the serve= r -- that is, that text blob is going to have been issued by the server as = an access token or a refresh token, no matter what the client claims in thi= s request. Seems like this is at best an optional sanity check. > > Unless of course you want to revoke all "related" tokens at once, in whic= h case I think you need a different mechanism to do so. > > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Torste= n Lodderstedt [torsten@lodderstedt.net] > Sent: Tuesday, January 11, 2011 5:22 PM > To: Hannes Tschofenig > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? > > I just posted a new revision of > http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/. > Please consider it for the re-chartering process. > > Additionally, Mark and me are still working on the security document. It > takes longer time than expected because of the topic's inherent > complexity. We plan to have a new revision ready for IETF-80. > > regards, > Torsten. > > Am 10.01.2011 10:55, schrieb Hannes Tschofenig: >> Hi all, >> >> In preparing the charter text we need your feedback. >> >> First, the new charter needs to include the two new items we had already= accepted, namely >> * SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 >> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ >> * The OAuth 2.0 Protocol: Bearer Tokens >> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >> >> In the past (around September / October 2010 timeframe) we had also disc= ussed other proposals. See attachment below. >> >> We cannot just add everything to the charter because we will never be ab= le to finish it. >> To make it more complicated there were other proposals floating around b= ut no drafts are available (e.g. security, discovery). >> >> It would be great to have a complete list of documents that should be co= nsidered. >> We would suggest to wait till the end of the month for new document subm= issions to show up. >> >> Then, we will start a Doodle poll to see your preference. >> >> Ciao >> Hannes& Blaine >> >> PS: Here are some of the other documents that people wanted to spend tim= e on. There are more on the OAuth WG page. >> >> * Messaging Signing >> Examples: >> http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ >> http://www.ietf.org/mail-archive/web/oauth/current/msg04250.html >> >> * User Experience Extensions >> Example: >> http://datatracker.ietf.org/doc/draft-recordon-oauth-v2-ux/ >> >> * Artifact Binding >> Example: >> http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ >> >> * Dynamic Client Registration >> Example: >> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >> >> * Token Revocation: >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >> >> * Use Cases >> http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Wed Jan 12 13:29:20 2011 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 A75CA3A67B0 for ; Wed, 12 Jan 2011 13:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv9i9hcbBKN1 for ; Wed, 12 Jan 2011 13:29:19 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id 677BC3A6774 for ; Wed, 12 Jan 2011 13:29:19 -0800 (PST) Received: from [87.142.243.222] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Pd8I6-0000mX-A9; Wed, 12 Jan 2011 22:31:38 +0100 Message-ID: <4D2E1DBB.70500@lodderstedt.net> Date: Wed, 12 Jan 2011 22:31:39 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Richer, Justin P." References: , <4D2CD83D.2010507@lodderstedt.net> , <4D2E181B.90400@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? 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, 12 Jan 2011 21:29:20 -0000 Am 12.01.2011 22:19, schrieb Richer, Justin P.: > Yes, let the server do the work. In practice, it's going to be looking up the token based on the token value anyway (for bearer tokens, at least). All the client really cares about is asking to "revoke this token that I am sending you". If the client credentials and token are correct and verifiable, then the revoke should go through. What do others think? > A client wanting to revoke both a request token and an access token will have to make several calls to this, unless you want to put in a way to put multiple token values in. I don't recommend that though, as it seems to me an optimization for a problem nobody has yet. the token_type does not control whether the server deletes all access tokens associated with a refresh token. This depends on the authorization servers policy. regards, Torsten. > -- Justin > ________________________________________ > From: Torsten Lodderstedt [torsten@lodderstedt.net] > Sent: Wednesday, January 12, 2011 4:07 PM > To: Richer, Justin P. > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? > > thank you for your feedback. > > So you would suggest to let the authorization server auto-detect the > correct type? > > regards, > Torsten. > > Am 12.01.2011 15:43, schrieb Richer, Justin P.: >> I don't quite understand the need for "token_type" in the request. The token being presented is going to have a type associated with it on the server -- that is, that text blob is going to have been issued by the server as an access token or a refresh token, no matter what the client claims in this request. Seems like this is at best an optional sanity check. >> >> Unless of course you want to revoke all "related" tokens at once, in which case I think you need a different mechanism to do so. >> >> -- Justin >> ________________________________________ >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt [torsten@lodderstedt.net] >> Sent: Tuesday, January 11, 2011 5:22 PM >> To: Hannes Tschofenig >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] Re-Chartering: What Items to work on? >> >> I just posted a new revision of >> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/. >> Please consider it for the re-chartering process. >> >> Additionally, Mark and me are still working on the security document. It >> takes longer time than expected because of the topic's inherent >> complexity. We plan to have a new revision ready for IETF-80. >> >> regards, >> Torsten. >> >> Am 10.01.2011 10:55, schrieb Hannes Tschofenig: >>> Hi all, >>> >>> In preparing the charter text we need your feedback. >>> >>> First, the new charter needs to include the two new items we had already accepted, namely >>> * SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ >>> * The OAuth 2.0 Protocol: Bearer Tokens >>> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-bearer/ >>> >>> In the past (around September / October 2010 timeframe) we had also discussed other proposals. See attachment below. >>> >>> We cannot just add everything to the charter because we will never be able to finish it. >>> To make it more complicated there were other proposals floating around but no drafts are available (e.g. security, discovery). >>> >>> It would be great to have a complete list of documents that should be considered. >>> We would suggest to wait till the end of the month for new document submissions to show up. >>> >>> Then, we will start a Doodle poll to see your preference. >>> >>> Ciao >>> Hannes& Blaine >>> >>> PS: Here are some of the other documents that people wanted to spend time on. There are more on the OAuth WG page. >>> >>> * Messaging Signing >>> Examples: >>> http://datatracker.ietf.org/doc/draft-hammer-oauth-v2-mac-token/ >>> http://www.ietf.org/mail-archive/web/oauth/current/msg04250.html >>> >>> * User Experience Extensions >>> Example: >>> http://datatracker.ietf.org/doc/draft-recordon-oauth-v2-ux/ >>> >>> * Artifact Binding >>> Example: >>> http://datatracker.ietf.org/doc/draft-sakimura-oauth-requrl/ >>> >>> * Dynamic Client Registration >>> Example: >>> http://www.ietf.org/id/draft-oauth-dyn-reg-v1-00.txt >>> >>> * Token Revocation: >>> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/ >>> >>> * Use Cases >>> http://datatracker.ietf.org/doc/draft-zeltsan-oauth-use-cases/ >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth From aaron@parecki.com Wed Jan 12 14:06:22 2011 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 61AC53A67C3 for ; Wed, 12 Jan 2011 14:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aU0DYbQue7Mu for ; Wed, 12 Jan 2011 14:06:21 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 28C513A67BD for ; Wed, 12 Jan 2011 14:06:21 -0800 (PST) Received: by wyf23 with SMTP id 23so1124877wyf.31 for ; Wed, 12 Jan 2011 14:08:40 -0800 (PST) Received: by 10.216.176.80 with SMTP id a58mr1276477wem.82.1294870118049; Wed, 12 Jan 2011 14:08:38 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by mx.google.com with ESMTPS id t11sm627725wes.17.2011.01.12.14.08.36 (version=SSLv3 cipher=RC4-MD5); Wed, 12 Jan 2011 14:08:36 -0800 (PST) Received: by wyf23 with SMTP id 23so1124795wyf.31 for ; Wed, 12 Jan 2011 14:08:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.50.72 with SMTP id y50mr4635303web.28.1294870115023; Wed, 12 Jan 2011 14:08:35 -0800 (PST) Received: by 10.216.173.78 with HTTP; Wed, 12 Jan 2011 14:08:34 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Jan 2011 14:08:34 -0800 Message-ID: From: Aaron Parecki To: "OAuth@ietf.org" Content-Type: multipart/alternative; boundary=0016e6db2ca43c7b900499ad71e4 Subject: Re: [OAUTH-WG] xAuth use in OAuth2.0? 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, 12 Jan 2011 22:06:22 -0000 --0016e6db2ca43c7b900499ad71e4 Content-Type: text/plain; charset=UTF-8 Jitesh, See section 5.1.2of the Draft 11 spec which provides a way to exchange the resource owner's username and password for an access token. This is probably what you're looking for. Aaron On Wed, Jan 12, 2011 at 1:22 PM, Jitesh Bhate wrote: > > > Is there any provision in OAuth2.0 specs. to use xAuth to exchange a > username and password for an OAuth access token? > > Something twitter does using OAuth 1.0 http://dev.twitter.com/pages/xauth > > > > Regards > > Jitesh > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --0016e6db2ca43c7b900499ad71e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jitesh,

See section 5.1.2 of the Draft 11 spec whic= h provides a way to exchange the resource owner's username and password= for an access token. This is probably what you're looking for.

Aaron



On Wed, Jan 12, 2011 at 1:22 PM, Jitesh Bhate = <jbhate@exacttarget.com>= ; wrote:

=C2=A0

Is the= re any provision =C2=A0in OAuth2.0 specs. to use xAuth to exchange a userna= me and password for an OAuth access token?

Something twitter does using OAuth 1.0 http://dev.twitter.com/= pages/xauth

=C2=A0

= Regards

Jitesh


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


--0016e6db2ca43c7b900499ad71e4-- From jbhate@exacttarget.com Wed Jan 12 14:10:21 2011 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 E4DD53A67B6 for ; Wed, 12 Jan 2011 14:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WaQIhwzC5Ewc for ; Wed, 12 Jan 2011 14:10:20 -0800 (PST) Received: from hub02.exacttarget.com (hub02.exacttarget.com [207.67.98.220]) by core3.amsl.com (Postfix) with ESMTP id 94AF73A69C5 for ; Wed, 12 Jan 2011 14:10:20 -0800 (PST) From: Jitesh Bhate To: Aaron Parecki , "OAuth@ietf.org" Date: Wed, 12 Jan 2011 17:12:40 -0500 Thread-Topic: [OAUTH-WG] xAuth use in OAuth2.0? Thread-Index: AcuypW24AFmHPBicSCidQdgOdVoD2gAAFOtQ 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_A72BD02C502A0F48AFA56C4A84CB23E579CFAA7279ETINMBCLUSTER_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] xAuth use in OAuth2.0? 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, 12 Jan 2011 22:10:22 -0000 --_000_A72BD02C502A0F48AFA56C4A84CB23E579CFAA7279ETINMBCLUSTER_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyZmVjdCAhIFRoYW5rcyBBYXJvbg0KDQpGcm9tOiBBYXJvbiBQYXJlY2tpIFttYWlsdG86YWFy b25AcGFyZWNraS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMTIsIDIwMTEgNTowOSBQ TQ0KVG86IE9BdXRoQGlldGYub3JnDQpDYzogSml0ZXNoIEJoYXRlDQpTdWJqZWN0OiBSZTogW09B VVRILVdHXSB4QXV0aCB1c2UgaW4gT0F1dGgyLjA/DQoNCkppdGVzaCwNCg0KU2VlIHNlY3Rpb24g NS4xLjI8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC12Mi0xMSNz ZWN0aW9uLTUuMS4yPiBvZiB0aGUgRHJhZnQgMTEgc3BlYyB3aGljaCBwcm92aWRlcyBhIHdheSB0 byBleGNoYW5nZSB0aGUgcmVzb3VyY2Ugb3duZXIncyB1c2VybmFtZSBhbmQgcGFzc3dvcmQgZm9y IGFuIGFjY2VzcyB0b2tlbi4gVGhpcyBpcyBwcm9iYWJseSB3aGF0IHlvdSdyZSBsb29raW5nIGZv ci4NCg0KQWFyb24NCg0KDQpPbiBXZWQsIEphbiAxMiwgMjAxMSBhdCAxOjIyIFBNLCBKaXRlc2gg QmhhdGUgPGpiaGF0ZUBleGFjdHRhcmdldC5jb208bWFpbHRvOmpiaGF0ZUBleGFjdHRhcmdldC5j b20+PiB3cm90ZToNCg0KSXMgdGhlcmUgYW55IHByb3Zpc2lvbiAgaW4gT0F1dGgyLjAgc3BlY3Mu IHRvIHVzZSB4QXV0aCB0byBleGNoYW5nZSBhIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBmb3IgYW4g T0F1dGggYWNjZXNzIHRva2VuPw0KU29tZXRoaW5nIHR3aXR0ZXIgZG9lcyB1c2luZyBPQXV0aCAx LjAgaHR0cDovL2Rldi50d2l0dGVyLmNvbS9wYWdlcy94YXV0aA0KDQpSZWdhcmRzDQpKaXRlc2gN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRo IG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_A72BD02C502A0F48AFA56C4A84CB23E579CFAA7279ETINMBCLUSTER_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48aGVhZD48bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlw ZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxtZXRhIG5hbWU9R2VuZXJhdG9y IGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj48c3R5bGU+PCEt LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2Ft YnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAz IDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9 RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QZXJmZWN0ICEgVGhhbmtzIEFh cm9uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+IEFhcm9uIFBhcmVja2kgW21haWx0bzphYXJvbkBwYXJlY2tpLmNvbV0gPGJyPjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMTIsIDIwMTEgNTowOSBQTTxicj48Yj5Ubzo8L2I+IE9B dXRoQGlldGYub3JnPGJyPjxiPkNjOjwvYj4gSml0ZXNoIEJoYXRlPGJyPjxiPlN1YmplY3Q6PC9i PiBSZTogW09BVVRILVdHXSB4QXV0aCB1c2UgaW4gT0F1dGgyLjA/PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+Sml0ZXNoLDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNlZSA8 YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLTEx I3NlY3Rpb24tNS4xLjIiPnNlY3Rpb24gNS4xLjI8L2E+IG9mIHRoZSBEcmFmdCAxMSBzcGVjIHdo aWNoIHByb3ZpZGVzIGEgd2F5IHRvIGV4Y2hhbmdlIHRoZSByZXNvdXJjZSBvd25lcidzIHVzZXJu YW1lIGFuZCBwYXNzd29yZCBmb3IgYW4gYWNjZXNzIHRva2VuLiBUaGlzIGlzIHByb2JhYmx5IHdo YXQgeW91J3JlIGxvb2tpbmcgZm9yLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPkFhcm9uPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5PbiBXZWQsIEphbiAxMiwgMjAxMSBhdCAxOjIyIFBNLCBKaXRlc2ggQmhhdGUgJmx0 OzxhIGhyZWY9Im1haWx0bzpqYmhhdGVAZXhhY3R0YXJnZXQuY29tIj5qYmhhdGVAZXhhY3R0YXJn ZXQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPklzIHRo ZXJlIGFueSBwcm92aXNpb24gJm5ic3A7aW4gT0F1dGgyLjAgc3BlY3MuIHRvIHVzZSB4QXV0aCB0 byBleGNoYW5nZSBhIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBmb3IgYW4gT0F1dGggYWNjZXNzIHRv a2VuPzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPlNvbWV0aGluZyB0d2l0dGVy IGRvZXMgdXNpbmcgT0F1dGggMS4wIDxhIGhyZWY9Imh0dHA6Ly9kZXYudHdpdHRlci5jb20vcGFn ZXMveGF1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGV2LnR3aXR0ZXIuY29tL3BhZ2VzL3hh dXRoPC9hPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPlJlZ2FyZHM8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz5KaXRlc2g8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJy PjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9h PjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_A72BD02C502A0F48AFA56C4A84CB23E579CFAA7279ETINMBCLUSTER_-- From mscurtescu@google.com Thu Jan 13 08:37:25 2011 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 671EA3A6A11 for ; Thu, 13 Jan 2011 08:37:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.78 X-Spam-Level: X-Spam-Status: No, score=-104.78 tagged_above=-999 required=5 tests=[AWL=-1.803, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 bZ-atJQROYDp for ; Thu, 13 Jan 2011 08:37:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 461993A69ED for ; Thu, 13 Jan 2011 08:37:24 -0800 (PST) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p0DGdjI9032046 for ; Thu, 13 Jan 2011 08:39:46 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294936786; bh=HGR9GkYsMhA3DxfiRUuJ1Wn4qn8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=lveuQi16e3KO8lQ07cgqnILXf+GCnZFa/KX4CZn+WQiE5EM9y1Kf24dmBuR7zL084 IKZlOd0VN0UK3sG/0bJIw== Received: from yxi11 (yxi11.prod.google.com [10.190.3.11]) by wpaz29.hot.corp.google.com with ESMTP id p0DGdioZ023483 for ; Thu, 13 Jan 2011 08:39:44 -0800 Received: by yxi11 with SMTP id 11so1217506yxi.15 for ; Thu, 13 Jan 2011 08:39:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ftQrrTaWzDRRcViTGcYlHS2fxMYUONdM30oLG7h2CpE=; b=Px0N2SQbEN12JFUklUmGhVnnw+kQmSk7L5n+03gcAS7jamU+Wpxn+i9OWGCUsz6rIq Gfgwz599w7xrl/i5Cbtw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=BVqgF44ps/UM4bGsGYnaHUCa3Q2eT9wyr5XYuEk42fs9mUx4YJTEa2jyddXB+wIXbg xMS2cEK4WAZw68GjqZwA== Received: by 10.100.48.4 with SMTP id v4mr1608258anv.47.1294936784281; Thu, 13 Jan 2011 08:39:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Thu, 13 Jan 2011 08:39:24 -0800 (PST) In-Reply-To: <4D2E1DBB.70500@lodderstedt.net> References: <4D2CD83D.2010507@lodderstedt.net> <4D2E181B.90400@lodderstedt.net> <4D2E1DBB.70500@lodderstedt.net> From: Marius Scurtescu Date: Thu, 13 Jan 2011 11:39:24 -0500 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] Re-Chartering: What Items to work on? 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, 13 Jan 2011 16:37:25 -0000 On Wed, Jan 12, 2011 at 4:31 PM, Torsten Lodderstedt wrote: > Am 12.01.2011 22:19, schrieb Richer, Justin P.: >> >> Yes, let the server do the work. In practice, it's going to be looking up >> the token based on the token value anyway (for bearer tokens, at least). All >> the client really cares about is asking to "revoke this token that I am >> sending you". If the client credentials and token are correct and >> verifiable, then the revoke should go through. > > What do others think? I agree with Justin's suggestion, let the server figure the token type. The server should be able to do that anyhow. >> A client wanting to revoke both a request token and an access token will >> have to make several calls to this, unless you want to put in a way to put >> multiple token values in. I don't recommend that though, as it seems to me >> an optimization for a problem nobody has yet. > > the token_type does not control whether the server deletes all access tokens > associated with a refresh token. > > This depends on the authorization servers policy. There are cases when the server cannot revoke the access tokens associated with a refresh token (static access tokens for example). That being said, I think the server SHOULD revoke all access tokens if possible. Marius From mscurtescu@google.com Thu Jan 13 09:13:58 2011 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 16A0B3A6B3D for ; Thu, 13 Jan 2011 09:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.574 X-Spam-Level: X-Spam-Status: No, score=-104.574 tagged_above=-999 required=5 tests=[AWL=-1.731, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTTP_ESCAPED_HOST=0.134, RCVD_IN_DNSWL_LOW=-1, 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 qeenRka17GqQ for ; Thu, 13 Jan 2011 09:13:56 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 242AE3A6B39 for ; Thu, 13 Jan 2011 09:13:55 -0800 (PST) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p0DHGIq0017950 for ; Thu, 13 Jan 2011 09:16:18 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1294938978; bh=HTAEVNVs99DoLdmcPr0DcGNQOoo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=HVjH3V4bFlqGcxhIROhAHtKaXmqNuS1eq9ZuQONCwmcKj3We/fWOV9U+LE5jSrPSg cWV4+FkJd21LbpZIKL6fw== Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by hpaq7.eem.corp.google.com with ESMTP id p0DHGGEC030578 for ; Thu, 13 Jan 2011 09:16:17 -0800 Received: by gyg8 with SMTP id 8so947940gyg.24 for ; Thu, 13 Jan 2011 09:16:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=bHbX6AE1kMRVx2sfdQRRbt/Cdt/if0gBylkEe7izKVM=; b=K2tugiG8SOU6NddQUhE75KOxqsNbdIKYJyvYnQTnDuYGss2t5GCBp0AjbJP2h1adXf /VmBp4KL4XM7PHk4xviQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=SAfAZ2YLfoW64la4PO1r2JYanTr1GNogIhub7ba3N931IOTZjNswTS7OvUUP8tT67T aM9H/Tvs7LtALM5LFfMA== Received: by 10.100.106.4 with SMTP id e4mr1624705anc.81.1294938976236; Thu, 13 Jan 2011 09:16:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Thu, 13 Jan 2011 09:15:56 -0800 (PST) In-Reply-To: References: From: Marius Scurtescu Date: Thu, 13 Jan 2011 12:15:56 -0500 Message-ID: To: David Recordon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , OAuth WG Subject: Re: [OAUTH-WG] OAuth 2.0 Token Upgrade Extension 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, 13 Jan 2011 17:13:58 -0000 One more issue:, section 3 states: "...the authorization server issues an access token response as described in Section 4.2 of [I-D.ietf.oauth-v2]. The new access token SHOULD have the same expiration and scope as the OAuth 1.0 token which the client is upgrading." First, only access tokens are mentioned here, and I think both refresh and access tokens should be mentioned. Second, it is the refresh token that should have same expiration as the OAuth 1 token, and not the access token. Marius On Wed, Dec 29, 2010 at 5:40 PM, Marius Scurtescu w= rote: > Hi David, > > A few suggestions for this extension. I am assuming that you will > update it soon to conform to draft 11 of the core protocol. > > > 1. Instead of passing an assertion why not treat it as another grant > type and pass all parameters as POST parameters. For example: > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=3Dhttp%3A%2F%2Foauth.net%2Ftoken%2F1.0& > oauth_token=3DrjmaGaw9ATW& > oauth_token_secret=3DOgFcfEjBR& > client_id=3D8eSEIpnqmM& > client_secret=3Ds6BhdRkqt3 > > > 2. I think it should also require the OAuth 1 consumer key and secret. > Maybe the assumption was that these are the same as the OAuth 2 client > id and secret, but that may not always be the case. Example: > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > grant_type=3Dhttp%3A%2F%2Foauth.net%2Ftoken%2F1.0& > oauth_token=3DrjmaGaw9ATW& > oauth_token_secret=3DOgFcfEjBR& > oauth_consumer_key=3D8eSEIpnqmM& > oauth_consumer_secret=3Ds6BhdRkqt3 > client_id=3D8eSEIpnqmM& > client_secret=3Ds6BhdRkqt3 > > > Marius > > > > On Fri, Aug 27, 2010 at 1:26 PM, David Recordon wro= te: >> This draft is now an Internet Draft and I'm curious if anyone has any >> feedback on >> it?=A0http://tools.ietf.org/html/draft-recordon-oauth-v2-upgrade-00 >> I'd also like to request that this draft moves to become a Working Group >> item. I'm am happy to act as the editor unless someone else wishes to do= so >> moving forward. >> Thanks, >> --David >> >> On Mon, Jul 12, 2010 at 10:39 PM, David Recordon >> wrote: >>> >>> The ability to upgrade OAuth 1.0 tokens and secrets to OAuth 2.0 access >>> tokens has come up on the list a few times. Attached is a draft asserti= on >>> format which allows a client to trade an OAuth 1.0 token/secret pair fo= r an >>> OAuth 2.0 access token. The assertion format is a JSON object with valu= es >>> for the token and token secret. My goal is that this draft become a wor= king >>> group document. >>> A question for the group is if upgrading multiple tokens at once is >>> a=A0necessary=A0use case? The assertion format within the core spec onl= y >>> supports issuing a single access token. Facebook has a custom endpoint = which >>> allows upgrading multiple tokens at once, but I don't actually have dat= a >>> about how many developers make use of that functionality. >>> Thanks, >>> --David >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> > From sakimura@gmail.com Thu Jan 13 15:22:15 2011 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 55ABE3A6C11 for ; Thu, 13 Jan 2011 15:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2jUf8W8o9Nk for ; Thu, 13 Jan 2011 15:22:11 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B9E343A6872 for ; Thu, 13 Jan 2011 15:22:10 -0800 (PST) Received: by fxm9 with SMTP id 9so2434519fxm.31 for ; Thu, 13 Jan 2011 15:24:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kGYQe05vCKP4RnjXKQla8s0MxgMwRg6UGuBKOTvAJLk=; b=Kb5pi27PrGzCfUFIyTrxCd6MBUPeMpK8EQ+PmmE7P3/Hn2IYae6TUVOJ64V/4Quuqs V19Kuyp5q17UHw+iGEeNBeHuVvbKNOhY/THxfx0Hvrrr9mqdI3UwlZOCfc9iIcQYyXmj x73LnJfOEaTA/JckpFknMg0LTuIj2qMd0xDkw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=rDxKcBLDTnOc77dpDSTLGGHt/tHSu+cSZFSyUVfTGxLWfhFHhFMDmjsWSnQDPt+CIa BcdU0XRVvw0k4nXjN7hKq5uQtrCMjrgttjhi74tifySa7mXxeg2TvEjDkmK2WuDeCsk0 nELMNSD1hF9Cr61r+QSdcejAWkclPUWlVAI8o= MIME-Version: 1.0 Received: by 10.223.86.13 with SMTP id q13mr17030fal.53.1294961073497; Thu, 13 Jan 2011 15:24:33 -0800 (PST) Sender: sakimura@gmail.com Received: by 10.223.126.1 with HTTP; Thu, 13 Jan 2011 15:24:33 -0800 (PST) In-Reply-To: <685598.65613.qm@web55808.mail.re3.yahoo.com> References: <4E1F6AAD24975D4BA5B1680429673943246AE7AD@TK5EX14MBXC202.redmond.corp.microsoft.com> <685598.65613.qm@web55808.mail.re3.yahoo.com> Date: Fri, 14 Jan 2011 08:24:33 +0900 X-Google-Sender-Auth: tbZI1a7sPK-zIavJ8_x88agRlio Message-ID: From: Nat Sakimura To: fcorella@pomcor.com Content-Type: multipart/alternative; boundary=20cf30434204c8a6a80499c29e69 Cc: "Karen P. Lewison" , John Bradley , "oauth@ietf.org" Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client 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, 13 Jan 2011 23:22:15 -0000 --20cf30434204c8a6a80499c29e69 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 9:16 AM, Francisco Corella wrote: > Mike, > > Thank you very much for sending the links to the artifact binding home page > and spec. I've had a quick look, and maybe I'm missing something, but it > seems that this completely ignores the problem of authenticating the relying > party. In section 7.4.1, the RP registers on the fly just by telling the OP > who it claims to be, and the OP takes the RP's word for it without any > verification and issues a client_secret. Same as OpenID Connect. > 7.4.1 was taken from OpenID Connect proposal. Primary mode for Artifact Binding was the Asymmetric Keys. Whether allowing dynamic association is entirely at the discretion of the IdP. I can imagine that IdP whitelisting or using whitelist from a trust framework will be the main mode of operation. This is not going to be in the protocol spec, but should be dealt with the Profiles that are defined by some sort of Trust Framework. > > OpenID 2.0 at least goes to the trouble of asking the user whether he/she > trusts the realm, and then verifying the return_url against the realm. I > don't think that's sufficient, but it's better than nothing. > ABC may go much further than this, especially when using the asymmetric signatures and encryption. Whether the IdP is going to be operating in that mode is dependent on what kind of Trust Framework it is going to use. We should not conflate the protocol and the trust framework issues. FYI, the refactoring that we are doing for ABC spec right now is: 0. Signature, Encryption and Token. (JWT) 1. Core: defines the message format and abstract protocols. 2. Protocol Binding binds the Core into a specific flow/protocols. 3. Profiles (which are to be defined by the Trust Frameworks) further constrains the bindings. 4. Discovery 5. Dynamic Registration 6. Session Management =nat > > Francisco > > --- On *Wed, 1/5/11, Mike Jones * wrote: > > > From: Mike Jones > Subject: RE: [OAUTH-WG] TLS is needed for redirecting back to the client > To: "fcorella@pomcor.com" , "Marius Scurtescu" < > mscurtescu@google.com>, "Justin Richer" > Cc: "oauth@ietf.org" , "Karen P. Lewison" < > kplewison@pomcor.com>, "Nat Sakimura (nat@sakimura.org)" , > "John Bradley" > Date: Wednesday, January 5, 2011, 5:18 PM > > > You can read about the Artifact Binding at > https://bitbucket.org/openid/ab/wiki/Home. The latest draft is at > https://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_0.html. > Nat Sakimura is actively updating the specification as we speak, > incorporating some of the ideas from OpenID Connect. The merger of the > specs that Nat is working on is sometimes referred to as OpenID Artifact > Binding/Connect or OpenID ABC for short. FYI, specification will be using > JSON Web Tokens (JWTs). > > > > -- Mike > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Francisco Corella > *Sent:* Tuesday, January 04, 2011 5:04 PM > *To:* Marius Scurtescu; Justin Richer > *Cc:* oauth@ietf.org; Karen P. Lewison > *Subject:* Re: [OAUTH-WG] TLS is needed for redirecting back to the client > > > > --- On Tue, 1/4/11, Justin Richer > > wrote: > > > > We need a protocol that does both authentication and > > > > authorization. We can take OAuth and adapt it for > > > > authentication, or take OpenID and adapt it for > > > > authorization, or combine OpenID and OAuth (great > > > > solution > > > > for people who love complexity) or... take the best > > > > ideas > > > > from OpenID and OAuth and incorporate them into a new > > > > protocol that's designed from the start for both > > > > authentication and authorization. That's one of my > > > > motivations for proposing PKAuth. > > > > > > Are you aware of OpenIDConnect? > > > > > > http://openidconnect.com/ > > > > And also the latest drafts of OpenID Artifact Binding: > > > > http://wiki.openid.net/w/page/12995134/Artifact-Binding > > I'm not familiar with that, and I haven't been able to find > a draft at the site. > > Francisco > > > > --20cf30434204c8a6a80499c29e69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 6, 2011 at 9:16 AM, Francisc= o Corella <fcor= ella@pomcor.com> wrote:
Mike,

Thank you very much for send= ing the links to the artifact binding home page and spec.=A0 I've had a= quick look, and maybe I'm missing something, but it seems that this co= mpletely ignores the problem of authenticating the relying party.=A0 In sec= tion 7.4.1, the RP registers on the fly just by telling the OP who it claim= s to be, and the OP takes the RP's word for it without any verification= and issues a client_secret.=A0 Same as OpenID Connect.

7.4.1 was taken = from OpenID Connect proposal. Primary mode for Artifact Binding was the Asy= mmetric Keys.=A0
Whether allowing dynamic association is entirely= at the discretion of the IdP.=A0
I can imagine that IdP whitelisting or using whitelist from a trust fr= amework will be the main mode of operation. This is not going to be in the = protocol spec, but should be dealt with the Profiles that are defined by so= me sort of Trust Framework.=A0
=A0

OpenID 2.0 at least goes to the trouble of asking the user whether= he/she trusts the realm, and then verifying the return_url against the rea= lm.=A0 I don't think that's sufficient, but it's better than no= thing.

ABC may go much = further than this, especially when using the asymmetric signatures and encr= yption. Whether the IdP is going to be operating in that mode is dependent = on what kind of Trust Framework it is going to use. We should not conflate = the protocol and the trust framework issues.=A0

FYI, the refactoring that we are doing for ABC spec rig= ht now is:=A0

0. Signature, Encryption and Token. = (JWT)
1. Core: defines the message format and abstract protocols.= =A0
2. Protocol Binding binds the Core into a specific flow/protocols.=A0<= /div>
3. Profiles (which are to be defined by the Trust Frameworks) fur= ther constrains the bindings.=A0
4. Discovery=A0
5. Dyn= amic Registration
6. Session Management

=3Dnat
=A0

Francisco

-= -- On Wed, 1/5/11, Mike Jones <Michael.Jones@microsoft.com> w= rote:

From: Mike Jones <Michael.Jones@microsoft.com>
Su= bject: RE: [OAUTH-WG] TLS is needed for redirecting back to the client
To: "fcorella= @pomcor.com" <fcorella@pomcor.com>, "Marius Scurtescu" <mscurtescu@google.com= >, "Justin Richer" <jricher@mitre.org>
Cc: "oauth@ietf.or= g" <oauth@i= etf.org>, "Karen P. Lewison" <kplewison@pomcor.com>, "Nat Sa= kimura (nat@sakimura.= org)" <na= t@sakimura.org>, "John Bradley" <ve7jtb@ve7jtb.com>
Date: Wednesday, January 5, 2011, 5:18 PM
=

=20 =20

You can read about t= he Artifact Binding at https://bitbucket.org/openid/ab/wiki/Home.=A0 The latest = draft is at https://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_= 0.html.=A0 Nat Sakimura is actively updating the specification as we sp= eak, incorporating some of the ideas from OpenID Connect.=A0 The merger of = the specs that Nat is working on is sometimes referred to as OpenID Artifact Binding/Connect or OpenID ABC for= short.=A0 FYI, specification will be using JSON Web Tokens (JWTs).<= /p>=20

=A0

=20

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

=20

=A0

=20

From: oauth= -bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Francisco Corella
Sent: Tuesday, January 04, 2011 5:04 PM
To: Marius Scurtescu; Justin Richer
Cc: oauth@ietf.o= rg; Karen P. Lewison
Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the cl= ient

=20

=A0

=20

--- On Tue, 1/4/11, Justin Richer <jricher@mitre.org> wrote:
> > > We need a protocol that does both authentication and
> > > authorization.=A0 We can take OAuth and adapt it for
> > > authentication, or take OpenID and adapt it for
> > > authorization, or combine OpenID and OAuth (great
> > > solution
> > > for people who love complexity) or... take the best
> > > ideas
> > > from OpenID and OAuth and incorporate them into a new
> > > protocol that's designed from the start for both
> > > authentication and authorization.=A0 That's one of my > > > motivations for proposing PKAuth.
> >
> > Are you aware of OpenIDConnect?
> >
> > http://openidconnect.com/
>
> And also the latest drafts of OpenID Artifact Binding:
>
> http://wiki.openid.net/w/page/12995134/Art= ifact-Binding

I'm not familiar with that, and I haven't been able to find
a draft at the site.

Francisco

=20

=A0

=20
=20

--20cf30434204c8a6a80499c29e69-- From sakimura@gmail.com Thu Jan 13 15:24:07 2011 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 9218228C0FE for ; Thu, 13 Jan 2011 15:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 TbUV4vErQHbD for ; Thu, 13 Jan 2011 15:24:05 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id AB99B3A6872 for ; Thu, 13 Jan 2011 15:24:04 -0800 (PST) Received: by fxm9 with SMTP id 9so2436022fxm.31 for ; Thu, 13 Jan 2011 15:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=uNtj73qBGZws0HwOKSRNviuWGw9X0MqiPk70wROSKT4=; b=N0I2JSJ5NFQ9RbyjwrqbY1pupXP3XNeu2TwA4u0QiU5kMbnFGCHzkQlfCWC5cVMY39 HuInE7xhzHycR5fOaloPzQVYCYeOBQ/xo+nNJzfJQhbWp3Cx0AEDKfHXckTyf9lHDsa0 noGqkkwGxv2ux6oN4mZX5/d7wNsW+wB8+SZfE= 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 :content-type; b=SONEdbMm7CDBQJaHa/ompxXotYkrYyZNlD6ThfYpETzU7ZNeyGokR9hvMAUqoiEs14 ka1tUY8m7IfSMqJmVigs7e952ZWJUQAynMZWOE/p7V+NOWwgH8BQqCzKIhRrfojJeb77 8/MQCRvWXhzHIf+dtZtuI30O7mmIWMSEO6rkE= MIME-Version: 1.0 Received: by 10.223.86.13 with SMTP id q13mr18484fal.53.1294961187661; Thu, 13 Jan 2011 15:26:27 -0800 (PST) Received: by 10.223.126.1 with HTTP; Thu, 13 Jan 2011 15:26:27 -0800 (PST) In-Reply-To: <685598.65613.qm@web55808.mail.re3.yahoo.com> References: <4E1F6AAD24975D4BA5B1680429673943246AE7AD@TK5EX14MBXC202.redmond.corp.microsoft.com> <685598.65613.qm@web55808.mail.re3.yahoo.com> Date: Fri, 14 Jan 2011 08:26:27 +0900 Message-ID: From: Nat Sakimura To: oauth Content-Type: multipart/alternative; boundary=20cf3043420496c7b70499c2a501 Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the client 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, 13 Jan 2011 23:24:07 -0000 --20cf3043420496c7b70499c2a501 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jan 6, 2011 at 9:16 AM, Francisco Corella wrote: > Mike, > > Thank you very much for sending the links to the artifact binding home page > and spec. I've had a quick look, and maybe I'm missing something, but it > seems that this completely ignores the problem of authenticating the relying > party. In section 7.4.1, the RP registers on the fly just by telling the OP > who it claims to be, and the OP takes the RP's word for it without any > verification and issues a client_secret. Same as OpenID Connect. > 7.4.1 was taken from OpenID Connect proposal. Primary mode for Artifact Binding was the Asymmetric Keys. Whether allowing dynamic association is entirely at the discretion of the IdP. I can imagine that IdP whitelisting or using whitelist from a trust framework will be the main mode of operation. This is not going to be in the protocol spec, but should be dealt with the Profiles that are defined by some sort of Trust Framework. > OpenID 2.0 at least goes to the trouble of asking the user whether he/she > trusts the realm, and then verifying the return_url against the realm. I > don't think that's sufficient, but it's better than nothing. > ABC may go much further than this, especially when using the asymmetric signatures and encryption. Whether the IdP is going to be operating in that mode is dependent on what kind of Trust Framework it is going to use. We should not conflate the protocol and the trust framework issues. FYI, the refactoring that we are doing for ABC spec right now is: 0. Signature, Encryption and Token. (JWT) 1. Core: defines the message format and abstract protocols. 2. Protocol Binding binds the Core into a specific flow/protocols. 3. Profiles (which are to be defined by the Trust Frameworks) further constrains the bindings. 4. Discovery 5. Dynamic Registration 6. Session Management =nat > > Francisco > > --- On *Wed, 1/5/11, Mike Jones * wrote: > > > From: Mike Jones > Subject: RE: [OAUTH-WG] TLS is needed for redirecting back to the client > To: "fcorella@pomcor.com" , "Marius Scurtescu" < > mscurtescu@google.com>, "Justin Richer" > Cc: "oauth@ietf.org" , "Karen P. Lewison" < > kplewison@pomcor.com>, "Nat Sakimura (nat@sakimura.org)" , > "John Bradley" > Date: Wednesday, January 5, 2011, 5:18 PM > > > You can read about the Artifact Binding at > https://bitbucket.org/openid/ab/wiki/Home. The latest draft is at > https://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_0.html. > Nat Sakimura is actively updating the specification as we speak, > incorporating some of the ideas from OpenID Connect. The merger of the > specs that Nat is working on is sometimes referred to as OpenID Artifact > Binding/Connect or OpenID ABC for short. FYI, specification will be using > JSON Web Tokens (JWTs). > > > > -- Mike > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Francisco Corella > *Sent:* Tuesday, January 04, 2011 5:04 PM > *To:* Marius Scurtescu; Justin Richer > *Cc:* oauth@ietf.org; Karen P. Lewison > *Subject:* Re: [OAUTH-WG] TLS is needed for redirecting back to the client > > > > --- On Tue, 1/4/11, Justin Richer > > wrote: > > > > We need a protocol that does both authentication and > > > > authorization. We can take OAuth and adapt it for > > > > authentication, or take OpenID and adapt it for > > > > authorization, or combine OpenID and OAuth (great > > > > solution > > > > for people who love complexity) or... take the best > > > > ideas > > > > from OpenID and OAuth and incorporate them into a new > > > > protocol that's designed from the start for both > > > > authentication and authorization. That's one of my > > > > motivations for proposing PKAuth. > > > > > > Are you aware of OpenIDConnect? > > > > > > http://openidconnect.com/ > > > > And also the latest drafts of OpenID Artifact Binding: > > > > http://wiki.openid.net/w/page/12995134/Artifact-Binding > > I'm not familiar with that, and I haven't been able to find > a draft at the site. > > Francisco > > > > -- Nat Sakimura (=nat) http://www.sakimura.org/en/ http://twitter.com/_nat_en --20cf3043420496c7b70499c2a501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 6, 2011 at 9:16 AM, Francisc= o Corella <fcor= ella@pomcor.com> wrote:
Mike,

Thank you very much for send= ing the links to the artifact binding home page and spec.=A0 I've had a= quick look, and maybe I'm missing something, but it seems that this co= mpletely ignores the problem of authenticating the relying party.=A0 In sec= tion 7.4.1, the RP registers on the fly just by telling the OP who it claim= s to be, and the OP takes the RP's word for it without any verification= and issues a client_secret.=A0 Same as OpenID Connect.
=A0
7.4.1 was taken from OpenID Connect proposal. P= rimary mode for Artifact Binding was the Asymmetric Keys.=A0
Whether allowing dynamic association is entirely at the discretion of = the IdP.=A0
I= can imagine that IdP whitelisting or using whitelist from a trust framewor= k will be the main mode of operation. This is not going to be in the protoc= ol spec, but should be dealt with the Profiles that are defined by some sor= t of Trust Framework.=A0=A0


OpenID 2.0 at least goes to the trouble of asking the user whether he/she t= rusts the realm, and then verifying the return_url against the realm.=A0 I = don't think that's sufficient, but it's better than nothing.

ABC may go much further than this, especially = when using the asymmetric signatures and encryption. Whether the IdP is goi= ng to be operating in that mode is dependent on what kind of Trust Framewor= k it is going to use. We should not conflate the protocol and the trust fra= mework issues.=A0

FYI, the refactoring that we are doing for ABC spec rig= ht now is:=A0

0. Signature, Encryption and Token. = (JWT)
1. Core: defines the message format and abstract protocols.= =A0
2. Protocol Binding binds the Core into a specific flow/protocols.=A0<= /div>
3. Profiles (which are to be defined by the Trust Frameworks) fur= ther constrains the bindings.=A0
4. Discovery=A0
5. Dyn= amic Registration
6. Session Management

=3Dnat=A0

Francisco

--- On Wed, 1/5/1= 1, Mike Jones <Michael.Jones@microsoft.com> wrote:

From: Mike Jones <Michael.Jones@microsoft.com>
Su= bject: RE: [OAUTH-WG] TLS is needed for redirecting back to the client
To: "fcorella= @pomcor.com" <fcorella@pomcor.com>, "Marius Scurtescu" <mscurtescu@google.com= >, "Justin Richer" <jricher@mitre.org>
Cc: "oauth@ietf.or= g" <oauth@i= etf.org>, "Karen P. Lewison" <kplewison@pomcor.com>, "Nat Sa= kimura (nat@sakimura.= org)" <na= t@sakimura.org>, "John Bradley" <ve7jtb@ve7jtb.com>
Date: Wednesday, January 5, 2011, 5:18 PM
=

=20 =20

You can read about t= he Artifact Binding at https://bitbucket.org/openid/ab/wiki/Home.=A0 The latest = draft is at https://bitbucket.org/openid/ab/raw/c1eaac175dc8/openid-artifact-binding-1_= 0.html.=A0 Nat Sakimura is actively updating the specification as we sp= eak, incorporating some of the ideas from OpenID Connect.=A0 The merger of = the specs that Nat is working on is sometimes referred to as OpenID Artifact Binding/Connect or OpenID ABC for= short.=A0 FYI, specification will be using JSON Web Tokens (JWTs).<= /p>=20

=A0

=20

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

=20

=A0

=20

From: oauth= -bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Francisco Corella
Sent: Tuesday, January 04, 2011 5:04 PM
To: Marius Scurtescu; Justin Richer
Cc: oauth@ietf.o= rg; Karen P. Lewison
Subject: Re: [OAUTH-WG] TLS is needed for redirecting back to the cl= ient

=20

=A0

=20

--- On Tue, 1/4/11, Justin Richer <jricher@mitre.org> wrote:
> > > We need a protocol that does both authentication and
> > > authorization.=A0 We can take OAuth and adapt it for
> > > authentication, or take OpenID and adapt it for
> > > authorization, or combine OpenID and OAuth (great
> > > solution
> > > for people who love complexity) or... take the best
> > > ideas
> > > from OpenID and OAuth and incorporate them into a new
> > > protocol that's designed from the start for both
> > > authentication and authorization.=A0 That's one of my > > > motivations for proposing PKAuth.
> >
> > Are you aware of OpenIDConnect?
> >
> > http://openidconnect.com/
>
> And also the latest drafts of OpenID Artifact Binding:
>
> http://wiki.openid.net/w/page/12995134/Art= ifact-Binding

I'm not familiar with that, and I haven't been able to find
a draft at the site.

Francisco

=20

=A0

=20
=20



--
Nat Sakimura (=3Dnat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
--20cf3043420496c7b70499c2a501-- From Michael.Jones@microsoft.com Fri Jan 14 17:37:16 2011 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 A22C23A6CF0 for ; Fri, 14 Jan 2011 17:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.582 X-Spam-Level: X-Spam-Status: No, score=-10.582 tagged_above=-999 required=5 tests=[AWL=0.016, 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 0LqHnrYHRxJP for ; Fri, 14 Jan 2011 17:37:13 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id A515B3A67E5 for ; Fri, 14 Jan 2011 17:37:13 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Jan 2011 17:39:34 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Fri, 14 Jan 2011 17:39:34 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Preparation for draft-ietf-oauth-v2-bearer-02 Thread-Index: Acu0VQ64lM4ZZ9AAQ/Km1fXzE9itTA== Date: Sat, 15 Jan 2011 01:39:33 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246E834E@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246E834ETK5EX14MBXC202r_" MIME-Version: 1.0 Subject: [OAUTH-WG] Preparation for draft-ietf-oauth-v2-bearer-02 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: Sat, 15 Jan 2011 01:37:16 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246E834ETK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to publish draft -02 of the bearer token specification next week. = As a heads-up, I have made no normative changes to date. Most changes are= in the security considerations section, which reflects the nature of the m= ajority of feedback received. I'm about to send replies to a number of messages providing feedback. If I= did not respond to your feedback or you disagree with my response, feel fr= ee to bring it to my attention. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943246E834ETK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to publish draft -02 of the bearer to= ken specification next week.  As a heads-up, I have made no normative = changes to date.  Most changes are in the security considerations sect= ion, which reflects the nature of the majority of feedback received.

 

I’m about to send replies to a number of messa= ges providing feedback.  If I did not respond to your feedback or you = disagree with my response, feel free to bring it to my attention.

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943246E834ETK5EX14MBXC202r_-- From Michael.Jones@microsoft.com Fri Jan 14 17:38:01 2011 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 5D1C53A6CF2 for ; Fri, 14 Jan 2011 17:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, 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 I65wE-3W-AiE for ; Fri, 14 Jan 2011 17:38:00 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 8AD8C3A6CF0 for ; Fri, 14 Jan 2011 17:38:00 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Jan 2011 17:40:27 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Fri, 14 Jan 2011 17:40:27 -0800 From: Mike Jones To: 'Torsten Lodderstedt' , OAuth WG Thread-Topic: Comments on OAuth 2.0 Bearer Token specification draft -01 Thread-Index: Acu0VSOnYp/x3UCaRWaS7tydW0UygQ== Date: Sat, 15 Jan 2011 01:40:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246E7E6D@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Comments on OAuth 2.0 Bearer Token specification draft -01 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: Sat, 15 Jan 2011 01:38:01 -0000 Thanks for your comments, Torsten. I've removed the sentence "Encrypting the token contents is another alterna= tive ..." from draft -02 since it was redundant and potentially confusing. I deleted the word "rare", since I agree with your conclusion. The "reuse" phrase now reads: "To deal with token capture and replay, ..." -- Mike -----Original Message----- From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=20 Sent: Monday, January 10, 2011 12:04 PM To: Mike Jones; OAuth WG Cc: Hannes Tschofenig Subject: Comments on OAuth 2.0 Bearer Token specification draft -01 Hi Mike, I've got some more comments on =A7 3.2 of your I-D. paragraph 4: "Encrypting the token contents is another alternative ..." How does token content encryption prevent the disclosure and abuse of a tok= en? paragraph 5: "For those rare cases where the client is prevented from obser= ving the contents of the token, token encryption has to be applied in addit= ion to the usage of TLS protection" How did you come to the conclusion these are _rare_ cases? The token is use= d to pass data between authorization server and resource server via the cli= ent as a intermediary. A self-contained token may contain a lot of user-spe= cific or service provider internal information neither end-user nor authori= zation server would like to disclose to the client. Therefore, here at Deut= sche Telekom we encrypt token contents per default. paragraph 6: "To deal with token reuse, ... " The "reuse" appears a bit misleading, isn't this paragraph talking about ca= pture/tap and replay attacks? regards, Torsten. From Michael.Jones@microsoft.com Fri Jan 14 17:38:16 2011 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 B30553A6CFB for ; Fri, 14 Jan 2011 17:38:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.584 X-Spam-Level: X-Spam-Status: No, score=-10.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, 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 XF66XWLRcr5a for ; Fri, 14 Jan 2011 17:38:15 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id CA2A83A67E5 for ; Fri, 14 Jan 2011 17:38:15 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Jan 2011 17:40:42 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Fri, 14 Jan 2011 17:40:42 -0800 From: Mike Jones To: 'Brian Campbell' , oauth Thread-Topic: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations Thread-Index: Acu0VTXpUIsMDbsTSSysOJUnTwqrGw== Date: Sat, 15 Jan 2011 01:40:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246E7E60@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations 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: Sat, 15 Jan 2011 01:38:16 -0000 Thanks for your input, Brian. I accepted these suggestions for draft -02. = The referenced text now reads: Furthermore, the authorization server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the authorization server. The authorization server MUST also obtain the consent of the resource owner prior to providing a token to the client.=20 I'll leave it up to Eran how much of this security considerations text to i= ncorporate into the framework specification. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Thursday, December 09, 2010 1:38 PM To: oauth Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 secur= ity considerations I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however= , a couple things jumped out at me in areas that hadn't received much atten= tion yet so I wanted to raise the questions on a separate thread. Near the end of section 3.2. Threat Mitigation, it says: " Furthermore, the resource server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the resource server. " Was the intent here to say authorization server rather than resource server= ? The resource server doesn't hand out tokens. Also, aren't there legitimat= e cases where the client isn't authenticated (anonymous or other cases wher= e the client can't keep secrets)? Then it says: "The authorization server MUST also receive a confirmation (the consent of the resource owner) prior to providing a token to the client." Does this allow for implicit consent? On my first read of it, I interpret t= his as potentially being more restrictive than what is in draft-ietf-oauth-v2-11 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Fri Jan 14 17:39:24 2011 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 92BEE3A67E5 for ; Fri, 14 Jan 2011 17:39:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, 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 RF5ANSTzuZlw for ; Fri, 14 Jan 2011 17:39:23 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id B43713A67D4 for ; Fri, 14 Jan 2011 17:39:23 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Jan 2011 17:41:50 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Fri, 14 Jan 2011 17:41:50 -0800 From: Mike Jones To: "'Manger, James H'" , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: Acu0VVoSuhbjJgstR1GVG/40ZLVktQ== Date: Sat, 15 Jan 2011 01:41:49 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246E7D94@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 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: Sat, 15 Jan 2011 01:39:24 -0000 Thanks James, I wanted to provide feedback on your comments. You wrote "token_type should be an HTTP authentication scheme name". I dis= agree with this. The token_type is intended be used to identify the type o= f the token, meaning that it is likely to take on values like: SWT JWT urn:oasis:names:tc:SAML:1.0:assertion urn:oasis:names:tc:SAML:2.0:assertion http://service.example.com/oauth/custom_token_format You wrote "the bearer spec (draft-ietf-oauth-v2-bearer) must not use the 'O= Auth2' scheme name. It needs its own scheme name, eg 'BEARER'". I also dis= agree with this. For the same reason that it was appropriate for draft 11 = to use the scheme name "OAuth", it is appropriate for the bearer token spec= to use the scheme name "OAuth2" for the corresponding text. In the intere= st of completing the specification, I'm not prone to introduce a breaking c= hange by modifying the scheme name at this time. Working group feedback is welcome. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= anger, James H Sent: Thursday, December 02, 2010 3:42 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 token_type should be an HTTP authentication scheme name (eg "BASIC" or "BEA= RER" or "MAC"...). The core spec (draft-ietf-oauth-v2) should explicitly state this rule. >From the token_type, the client app knows which auth scheme to use. [renaming the parameter from "token_type" to "scheme" would help.] Defining token_type to be an HTTP authentication scheme name effectively de= fines how OAuth2 can deliver credentials for auth schemes that are independ= ent of OAuth2, eg schemes specified before OAuth2 existed. It eliminates th= e need for additional specs just to provide a link from OAuth2 to every aut= hentication mechanism. Some auth mechanisms for which OAuth2 could deliver credentials are not act= ually HTTP authentication schemes. Eg OAuth2 delivering an id/secret to use= in TLS-PSK (pre-shared key). For that you will need a small additional spe= c to define a token_type value -- ie define a pseudo-HTTP-auth-scheme-name. P.S. Related to this, the bearer spec (draft-ietf-oauth-v2-bearer) must not= use the "OAuth2" scheme name. It needs its own scheme name, eg "BEARER". -- James Manger _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jan 14 21:54:46 2011 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 C97CC3A6CA2 for ; Fri, 14 Jan 2011 21:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdBcW7DnO4-x for ; Fri, 14 Jan 2011 21:54:45 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8FD3C3A6A93 for ; Fri, 14 Jan 2011 21:54:45 -0800 (PST) Received: (qmail 1311 invoked from network); 15 Jan 2011 05:57:12 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jan 2011 05:57:12 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 14 Jan 2011 22:57:12 -0700 From: Eran Hammer-Lahav To: Mike Jones , "'Manger, James H'" , "oauth@ietf.org" Date: Fri, 14 Jan 2011 22:57:02 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 Thread-Index: Acu0VVoSuhbjJgstR1GVG/40ZLVktQAIxinw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F69@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943246E7D94@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246E7D94@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 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: Sat, 15 Jan 2011 05:54:46 -0000 When the decision was made to break the specification, we discussed giving = the bearer token a different scheme name. This has been the implicit consen= sus for over a year, though not necessarily for the bearer token but for th= e signed request. IOW, there was consensus NOT to use a single scheme for a= ll token types. Since we now split the bearer token out of the specificatio= n, it should have a new scheme name. This is the obvious conclusion of the = new organization and separation of authorization from authentication. As for the token type, it is meant to identify the characteristics of the t= oken needed by the client to use the token. The only value of the token typ= e is to inform the client how it should be used. The authentication scheme = (HTTP or otherwise) used it the primary goal. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Mike Jones > Sent: Friday, January 14, 2011 5:42 PM > To: 'Manger, James H'; oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >=20 > Thanks James, >=20 > I wanted to provide feedback on your comments. >=20 > You wrote "token_type should be an HTTP authentication scheme name". I > disagree with this. The token_type is intended be used to identify the t= ype > of the token, meaning that it is likely to take on values like: > SWT > JWT > urn:oasis:names:tc:SAML:1.0:assertion > urn:oasis:names:tc:SAML:2.0:assertion > http://service.example.com/oauth/custom_token_format >=20 > You wrote "the bearer spec (draft-ietf-oauth-v2-bearer) must not use the > 'OAuth2' scheme name. It needs its own scheme name, eg 'BEARER'". I also > disagree with this. For the same reason that it was appropriate for draf= t 11 to > use the scheme name "OAuth", it is appropriate for the bearer token spec = to > use the scheme name "OAuth2" for the corresponding text. In the interest > of completing the specification, I'm not prone to introduce a breaking ch= ange > by modifying the scheme name at this time. >=20 > Working group feedback is welcome. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Manger, James H > Sent: Thursday, December 02, 2010 3:42 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token specification draft -01 >=20 > token_type should be an HTTP authentication scheme name (eg "BASIC" or > "BEARER" or "MAC"...). > The core spec (draft-ietf-oauth-v2) should explicitly state this rule. > From the token_type, the client app knows which auth scheme to use. > [renaming the parameter from "token_type" to "scheme" would help.] >=20 > Defining token_type to be an HTTP authentication scheme name effectively > defines how OAuth2 can deliver credentials for auth schemes that are > independent of OAuth2, eg schemes specified before OAuth2 existed. It > eliminates the need for additional specs just to provide a link from OAut= h2 to > every authentication mechanism. >=20 > Some auth mechanisms for which OAuth2 could deliver credentials are not > actually HTTP authentication schemes. Eg OAuth2 delivering an id/secret t= o > use in TLS-PSK (pre-shared key). For that you will need a small additiona= l spec > to define a token_type value -- ie define a pseudo-HTTP-auth-scheme- > name. >=20 > P.S. Related to this, the bearer spec (draft-ietf-oauth-v2-bearer) must n= ot > use the "OAuth2" scheme name. It needs its own scheme name, eg > "BEARER". >=20 >=20 > -- > James Manger > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Fri Jan 14 22:29:50 2011 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 64AF33A6CA2 for ; Fri, 14 Jan 2011 22:29:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.057, 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 2PvevGmUWB37 for ; Fri, 14 Jan 2011 22:29:43 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id AEEFD3A6D0F for ; Fri, 14 Jan 2011 22:29:43 -0800 (PST) Received: (qmail 30990 invoked from network); 15 Jan 2011 06:32:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Jan 2011 06:32:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 14 Jan 2011 23:32:10 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 14 Jan 2011 23:32:00 -0700 Thread-Topic: Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu0eqc8OI1TGx2yS4KwfqhDmZy6TQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6AP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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: Sat, 15 Jan 2011 06:29:50 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6AP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One of the main problems with OAuth in general has always been the unsanita= ry mix of authorization and authentication ("it's an authentication protoco= l... authorization protocol... authentication protocol" [1]). It has always= been a confusing mess. The work on 2.0 has provided a valuable abstraction= and separation of the two components, especially the recent document split= . In addition, the recent work on the bearer token document and the MAC tok= en type have raised issues about OAuth and its relationship with HTTP authe= ntication. I would like to suggest we drop the 'OAuth2' WWW-Authenticate header comple= tely from the specification for the following reasons: 1. Draft oauth-v2 is clearly not an authentication protocol. It *util= izes* client authentication. It offers one fully defined method for client = authentication (which is basically HTTP Basic+), provides a half-baked clie= nt assertion authentication hook, and leaves all end-user authentication ou= t of scope. 2. The WWW-Authenticate header has absolutely no value, interoperabil= ity-wise or otherwise. Discovery was rules to be beyond the scope of this s= pecification. Having a protected resource declare it supports authenticatio= n using some unspecified credentials obtained using some unspecified client= flow is confusing at best. In the future, an interoperable discovery mecha= nism will be needed to allow clients to interact with completely unknown pr= otected resources, but this has been consistently ruled to be premature sta= ndardization at this point. 3. OAuth is agnostic to token authentication, and we already have thr= ee discrete token type proposals - all with active deployment plans in the = coming months. Two of these methods have already defined a full HTTP authen= tication scheme (even if the bearer token specification has not yet been up= dated to change its scheme name). 4. HTTP *authentication* is not an appropriate facility to negotiate = *authorization*. OAuth authorization discovery can be added to HTTP authent= ication schemes as attributes, but makes no sense as a scheme of its own. T= he issues we are having with 'realm' is one of the examples showing that we= are abusing the header. 5. Again, as specified, it adds no value and I am not aware of any ex= isting OAuth 1.0a implementation making use of the response header for clie= nt interoperability (yes, many include it, but how many clients actually re= ly on it, and if they do, how?). For these reasons I would like to suggest we: 1. Drop the WWW-Authenticate header definition and OAuth2 scheme from= the specification, leaving it up to each token type to define its own auth= entication flow. In the future, a comprehensive discovery specification sho= uld define a new HTTP response header for providing discovery information. = I have suggested using Link: rel=3D'authorization' as a simple yet powerful= solution. 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' to m= ake it clear what this document is really about. Comments? Counter argument? EHL [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6AP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One of the main = problems with OAuth in general has always been the unsanitary mix of author= ization and authentication (“it’s an authentication protocol= 230; authorization protocol… authentication protocol” [1]). It = has always been a confusing mess. The work on 2.0 has provided a valuable a= bstraction and separation of the two components, especially the recent docu= ment split. In addition, the recent work on the bearer token document and t= he MAC token type have raised issues about OAuth and its relationship with = HTTP authentication.

 

I would like to suggest we drop the ‘OAuth2= 217; WWW-Authenticate header completely from the specification for the foll= owing reasons:

 

1.       Draft oauth-v2 is clearly not an authentication protocol. It *= utilizes* client authentication. It offers one fully defined method = for client authentication (which is basically HTTP Basic+), provides a half= -baked client assertion authentication hook, and leaves all end-user authen= tication out of scope.

2. &= nbsp;     The WWW-Authenticate = header has absolutely no value, interoperability-wise or otherwise. Discove= ry was rules to be beyond the scope of this specification. Having a protect= ed resource declare it supports authentication using some unspecified crede= ntials obtained using some unspecified client flow is confusing at best. In= the future, an interoperable discovery mechanism will be needed to allow c= lients to interact with completely unknown protected resources, but this ha= s been consistently ruled to be premature standardization at this point.

3.     &n= bsp; OAuth is agnostic to token authentication, and= we already have three discrete token type proposals – all with activ= e deployment plans in the coming months. Two of these methods have already = defined a full HTTP authentication scheme (even if the bearer token specifi= cation has not yet been updated to change its scheme name).

<= p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 l= fo1'>4.       <= /span>HTTP *authentication* is not an appropriate facility= to negotiate *authorization*. OAuth authorization discovery can be = added to HTTP authentication schemes as attributes, but makes no sense as a= scheme of its own. The issues we are having with ‘realm’ is on= e of the examples showing that we are abusing the header.

5.       Again, as specified, it adds no value and I am not aware of a= ny existing OAuth 1.0a implementation making use of the response header for= client interoperability (yes, many include it, but how many clients actual= ly rely on it, and if they do, how?).

 

For these reasons I would like to s= uggest we:

 

1.       <= ![endif]>Drop the WWW-Authenticate header definition and OAuth2 scheme from= the specification, leaving it up to each token type to define its own auth= entication flow. In the future, a comprehensive discovery specification sho= uld define a new HTTP response header for providing discovery information. = I have suggested using Link: rel=3D’authorization’ as a simple = yet powerful solution.

2. &= nbsp;     Rename the document t= o ‘The OAuth 2.0 Authorization Protocol’ to make it clear what = this document is really about.

&nbs= p;

Comments? Counter argument?

=

 

EHL

 

[1] http://www.youtube.c= om/watch?v=3D0IBZocFkXGY

 =

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6AP3PW5EX1MB01E_-- From eran@hueniverse.com Fri Jan 14 22:42:59 2011 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 30BE03A6D11 for ; Fri, 14 Jan 2011 22:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, 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 7CFDNg135-bU for ; Fri, 14 Jan 2011 22:42:57 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 4E6E43A6D10 for ; Fri, 14 Jan 2011 22:42:57 -0800 (PST) Received: (qmail 23037 invoked from network); 15 Jan 2011 06:45:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jan 2011 06:45:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 14 Jan 2011 23:45:24 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 14 Jan 2011 23:45:14 -0700 Thread-Topic: Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6CP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Removal: Client Assertion Credentials 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: Sat, 15 Jan 2011 06:42:59 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would like to suggest we drop the client assertion credentials (-11 secti= on 3.2) from the specification, and if needed, publish it as a separate spe= cification for the following reasons: 1. The mechanism is under specified, especially in its handling of th= e client_id identifier (when used to obtain end-user authorization). It doe= s not contain any implementation details to accomplish any level of interop= erability or functionality. This is in contrast to the assertion grant type= which has matured over a year into a fully thought-out extension mechanism= , as well as a separate SAML assertion specification with active deployment= (the two, together with running code, show clear consensus). 2. The section is a confused mix of security considerations sprinkled= with normative language. Instead, it should be replaced with guidelines fo= r extending the set of supported client credentials, but without defining a= new registry. It is clearly an area of little deployment experience for OA= uth, and that includes using HTTP Basic authentication for client authentic= ation (more on that to come). 3. The section has received a little support and a little objection. = Those who still want to advocate for it need to show not only consensus for= keeping it, but also active community support for deploying it. Deployment= , of course, will also require showing progress on public specifications pr= ofiling the mechanism into a useful interoperable feature. Comments? Counter-arguments? EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would like to = suggest we drop the client assertion credentials (-11 section 3.2) from the= specification, and if needed, publish it as a separate specification for t= he following reasons:

 <= /p>

1.       The mechanism is under specified, especially in its han= dling of the client_id identifier (when used to obtain end-user authorizati= on). It does not contain any implementation details to accomplish any level= of interoperability or functionality. This is in contrast to the assertion= grant type which has matured over a year into a fully thought-out extensio= n mechanism, as well as a separate SAML assertion specification with active= deployment (the two, together with running code, show clear consensus).

2.     &n= bsp; The section is a confused mix of security cons= iderations sprinkled with normative language. Instead, it should be replace= d with guidelines for extending the set of supported client credentials, bu= t without defining a new registry. It is clearly an area of little deployme= nt experience for OAuth, and that includes using HTTP Basic authentication = for client authentication (more on that to come).

3.       The section has received a little support and a little objection. Tho= se who still want to advocate for it need to show not only consensus for ke= eping it, but also active community support for deploying it. Deployment, o= f course, will also require showing progress on public specifications profi= ling the mechanism into a useful interoperable feature.

 

Comments? Counter= -arguments?

 

EHL

 

<= p class=3DMsoNormal> 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6CP3PW5EX1MB01E_-- From eran@hueniverse.com Fri Jan 14 22:52:00 2011 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 ABDC93A6D13 for ; Fri, 14 Jan 2011 22:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, 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 25dSzjoyvdgg for ; Fri, 14 Jan 2011 22:51:40 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id CCE2E28C0CE for ; Fri, 14 Jan 2011 22:51:19 -0800 (PST) Received: (qmail 32110 invoked from network); 15 Jan 2011 06:53:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jan 2011 06:53:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 14 Jan 2011 23:53:36 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 14 Jan 2011 23:53:26 -0700 Thread-Topic: Removal: HTTP Basic Authentication for Client Credentials Thread-Index: Acu0f9IqxkhbY4HfQHS+hXiSb6TXlg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials 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: Sat, 15 Jan 2011 06:52:01 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable OAuth 2.0 provides two methods for client authentication using password cre= dentials: request parameters and HTTP Basic authentication. I suggest we dr= op the requirement to support HTTP Basic authentication, and only mention i= t as an example for alternative methods. My reasons are: 1. A few providers have expressed concerns over the need to support B= asic authentication, and some explicitly said they will not support it. Par= ameter-based authentication, OTOH, is widely deployed in 2.0. 2. Due to the way OAuth is being implemented at the HTTP authenticati= on layer (even if it is wrong), can conflict within the framework as both a= consumer and provider of authentication components. 3. The mapping between username and client_id, while not complicated,= is still a big awkward, and can be confusing when combined with the userna= me and password grant type. On the other hand, the use of client_id in the = end-user authorization endpoint lends itself nicely to the use of the same = parameter elsewhere. 4. Some existing authentication frameworks will have an issue handlin= g the mix of Basic authentication and parameters authentication due to how = each is deployed. In cases where a front gate handles Basic, it will be har= d to let requests through for parameter processing. Comments? Counter-arguments? EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OAuth 2.0 provid= es two methods for client authentication using password credentials: reques= t parameters and HTTP Basic authentication. I suggest we drop the requireme= nt to support HTTP Basic authentication, and only mention it as an example = for alternative methods. My reasons are:

 

1.   &nbs= p;   A few providers have expressed conce= rns over the need to support Basic authentication, and some explicitly said= they will not support it. Parameter-based authentication, OTOH, is widely = deployed in 2.0.

2.  &= nbsp;    Due to the way OAuth is bei= ng implemented at the HTTP authentication layer (even if it is wrong), can = conflict within the framework as both a consumer and provider of authentica= tion components.

3.  &= nbsp;    The mapping between usernam= e and client_id, while not complicated, is still a big awkward, and can be = confusing when combined with the username and password grant type. On the o= ther hand, the use of client_id in the end-user authorization endpoint lend= s itself nicely to the use of the same parameter elsewhere.

<= p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 l= fo1'>4.       <= /span>Some existing authentication frameworks will have an issue = handling the mix of Basic authentication and parameters authentication due = to how each is deployed. In cases where a front gate handles Basic, it will= be hard to let requests through for parameter processing.

 

Comments? Coun= ter-arguments?

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6DP3PW5EX1MB01E_-- From elena.lozano@prise.es Sat Jan 15 03:34:14 2011 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 E5DAC3A6B63 for ; Sat, 15 Jan 2011 03:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, 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 PWn288aSno8Z for ; Sat, 15 Jan 2011 03:34:11 -0800 (PST) Received: from prise.siliconpeople.net (iditinere.com [93.189.88.154]) by core3.amsl.com (Postfix) with ESMTP id 64C013A6B49 for ; Sat, 15 Jan 2011 03:34:10 -0800 (PST) Received: from 237.221.222.87.dynamic.jazztel.es ([87.222.221.237]:58588 helo=[192.168.1.129]) by prise.siliconpeople.net with esmtpsa (TLS-1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.63) (envelope-from ) id 1Pe4Qt-0006rC-Uy; Sat, 15 Jan 2011 12:36:36 +0100 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4--1043384436 From: Elena Lozano Rosch In-Reply-To: <7D961CA4-4D2E-4126-8ECC-6C448DEB06A1@prise.es> Date: Sat, 15 Jan 2011 12:36:35 +0100 Message-Id: <9091D23D-773B-4032-A40A-2A49A7A89040@prise.es> References: <90C41DD21FB7C64BB94121FBBC2E723445328CB1D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> <21ED318E-24D6-4932-B748-B02F99BCFD8D@rediris.es> <7D961CA4-4D2E-4126-8ECC-6C448DEB06A1@prise.es> To: oauth@ietf.org X-Mailer: Apple Mail (2.1082) Subject: Re: [OAUTH-WG] Final cuts and 3 interoperable implementations 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: Sat, 15 Jan 2011 11:34:15 -0000 --Apple-Mail-4--1043384436 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I would like to be included on behalf of PRiSE[1] We've developed an OAuth2 open source library[2] and we intend to keep = doing the adaptation to the new versions. Regards,=20 Elena Lozano. [1] http://www.prise.es/en [2] http://www.rediris.es/oauth2/ > Begin forwarded message: >=20 >> From: Eran Hammer-Lahav >> Date: 5 January 2011 19:26:22 GMT+01:00 >> To: OAuth WG >> Subject: [OAUTH-WG] Final cuts and 3 interoperable implementations >>=20 >> In the next few weeks I plan to survey existing and planned = implementations of each feature of the specification and those = components without at least 3 interoperable (or compliant) = implementations will be a candidate for removal from the specification = (can still be published as an extension). The goal is to publish a = specification which has complete code coverage. I should strive to = produce a specification that is grounded in actual deployment plans, not = just projected theory. >> =20 >> If you (or your company) are implementing or plan to, please let me = know so I can include you in the survey. >> =20 >> EHL >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 --Apple-Mail-4--1043384436 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii http://www.prise.es/en
[2]&n= bsp;http://www.rediris.es/oauth2/
From: Eran = Hammer-Lahav <eran@hueniverse.com>
Date: 5 January = 2011 19:26:22 GMT+01:00
OAuth WG = <oauth@ietf.org>
Subject: 
In the next few weeks I plan = to survey existing and planned implementations of each feature of the = specification and those components without at least 3 interoperable (or = compliant) implementations will be a candidate for removal from the = specification (can still be published as an extension). The goal is to = publish a specification which has complete code coverage. I should = strive to produce a specification that is grounded in actual deployment = plans, not just projected theory.
If you (or your company) are = implementing or plan to, please let me know so I can include you in the = survey.
 
A strong client credential is need= ed in many cases. I had assumed client assertion would fulfill this need.&nb= sp;

Phil

Sent from my phone. 

On 2011-01-14, at 22:45, Eran Hammer-Lahav <eran@hueniverse= .com> wrote:

I would like to sugges= t we drop the client assertion credentials (-11 section 3.2) from the specif= ication, and if needed, publish it as a separate specification for the follo= wing reasons:

 

1.       The mecha= nism is under specified, especially in its handling of the client_id identif= ier (when used to obtain end-user authorization). It does not contain any im= plementation details to accomplish any level of interoperability or function= ality. This is in contrast to the assertion grant type which has matured ove= r a year into a fully thought-out extension mechanism, as well as a separate= SAML assertion specification with active deployment (the two, together with= running code, show clear consensus).

2.&nbs= p;      The section is a confused mix= of security considerations sprinkled with normative language. Instead, it s= hould be replaced with guidelines for extending the set of supported client c= redentials, but without defining a new registry. It is clearly an area of li= ttle deployment experience for OAuth, and that includes using HTTP Basic aut= hentication for client authentication (more on that to come).

=

3.       The s= ection has received a little support and a little objection. Those who still= want to advocate for it need to show not only consensus for keeping it, but= also active community support for deploying it. Deployment, of course, will= also require showing progress on public specifications profiling the mechan= ism into a useful interoperable feature.

 

Comments? Counter-arguments?

 

EHL

 

 

_______________________________________________
= OAuth mailing list
<= a href=3D"mailto:OAuth@ietf.org">OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth<= /a>
= --Apple-Mail-3--1052987690-- From eran@hueniverse.com Sat Jan 15 11:30:13 2011 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 13D8B28C0D8 for ; Sat, 15 Jan 2011 11:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.054, 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 UN1pbYe19DGs for ; Sat, 15 Jan 2011 11:30:11 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8F5C43A6E23 for ; Sat, 15 Jan 2011 11:30:11 -0800 (PST) Received: (qmail 29861 invoked from network); 15 Jan 2011 19:32:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 15 Jan 2011 19:32:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 15 Jan 2011 12:32:33 -0700 From: Eran Hammer-Lahav To: Phillip Hunt Date: Sat, 15 Jan 2011 12:32:23 -0700 Thread-Topic: [OAUTH-WG] Removal: Client Assertion Credentials Thread-Index: Acu06KZK0f+gW2RLT/az63vSSrhVBAAAYD5g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0DB1EE65-8D69-4B2F-8550-248BC10B076A@oracle.com> In-Reply-To: <0DB1EE65-8D69-4B2F-8550-248BC10B076A@oracle.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_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F94P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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: Sat, 15 Jan 2011 19:30:13 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F94P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IHN0aWxsIG5lZWQgdG8gZGVmaW5lIGl0LiBUaGUgdHdvIHBhcmFtZXRlcnMgZG9u4oCZdCBh Y2NvbXBsaXNoIGFueXRoaW5nIHNpbmNlIHlvdSBjYW7igJl0IHVzZSB0aGVtIHdpdGhvdXQgYSBt b3JlIGRldGFpbGVkIHNwZWNpZmljYXRpb24sIGluIHdoaWNoIGNhc2UsIHdoYXQgaXMgdGhlIHZh bHVlIG9mIHRoaXM/IFdoZXJlIGlzIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGdhaW4/DQoNClRoaXMg aXMgY2xlYXJseSBub3QgYSBmZWF0dXJlIHRoYXQgaXMgbGlrZWx5IHRvIGJlIGltcGxlbWVudGVk IGluIGFueSBnZW5lcmFsIHB1cnBvc2UgbGlicmFyeSwgdW5saWtlIHRoZSDigJhzY29wZeKAmSBw YXJhbWV0ZXIgd2hpY2ggaXMgdW5kZXItZGVmaW5lZCBidXQgc3RpbGwgdXNlZnVsIGZvciBsaWJy YXJ5IHN1cHBvcnQuDQoNCkluY2x1ZGluZyBpdCBpbiB0aGUgc3BlY2lmaWNhdGlvbiBpcyBjb25m dXNpbmcgKHRoZSB1bmFuaW1vdXMgZmVlZGJhY2sgSSByZWNlaXZlZCBzbyBmYXIpLCB3aXRob3V0 IGFueSBiZW5lZml0LiBUaGUgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIGNsZWFyIGV4dGVuc2lv biBtZWNoYW5pc20gZm9yIG5ldyBwYXJhbWV0ZXJzLiBXaHkgaXMgdGhhdCBub3QgZW5vdWdoPw0K DQpFSEwNCg0KRnJvbTogUGhpbGxpcCBIdW50IFttYWlsdG86cGhpbC5odW50QE9yYWNsZS5jb21d DQpTZW50OiBTYXR1cmRheSwgSmFudWFyeSAxNSwgMjAxMSAxMjo1MiBBTQ0KVG86IEVyYW4gSGFt bWVyLUxhaGF2DQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIFJlbW92YWw6 IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMNCg0KQSBzdHJvbmcgY2xpZW50IGNyZWRlbnRp YWwgaXMgbmVlZGVkIGluIG1hbnkgY2FzZXMuIEkgaGFkIGFzc3VtZWQgY2xpZW50IGFzc2VydGlv biB3b3VsZCBmdWxmaWxsIHRoaXMgbmVlZC4NCg0KUGhpbA0KDQpTZW50IGZyb20gbXkgcGhvbmUu DQoNCk9uIDIwMTEtMDEtMTQsIGF0IDIyOjQ1LCBFcmFuIEhhbW1lci1MYWhhdiA8ZXJhbkBodWVu aXZlcnNlLmNvbTxtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbT4+IHdyb3RlOg0KSSB3b3VsZCBs aWtlIHRvIHN1Z2dlc3Qgd2UgZHJvcCB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyAo LTExIHNlY3Rpb24gMy4yKSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uLCBhbmQgaWYgbmVlZGVkLCBw dWJsaXNoIGl0IGFzIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIGZvbGxvd2luZyBy ZWFzb25zOg0KDQoNCjEuICAgICAgIFRoZSBtZWNoYW5pc20gaXMgdW5kZXIgc3BlY2lmaWVkLCBl c3BlY2lhbGx5IGluIGl0cyBoYW5kbGluZyBvZiB0aGUgY2xpZW50X2lkIGlkZW50aWZpZXIgKHdo ZW4gdXNlZCB0byBvYnRhaW4gZW5kLXVzZXIgYXV0aG9yaXphdGlvbikuIEl0IGRvZXMgbm90IGNv bnRhaW4gYW55IGltcGxlbWVudGF0aW9uIGRldGFpbHMgdG8gYWNjb21wbGlzaCBhbnkgbGV2ZWwg b2YgaW50ZXJvcGVyYWJpbGl0eSBvciBmdW5jdGlvbmFsaXR5LiBUaGlzIGlzIGluIGNvbnRyYXN0 IHRvIHRoZSBhc3NlcnRpb24gZ3JhbnQgdHlwZSB3aGljaCBoYXMgbWF0dXJlZCBvdmVyIGEgeWVh ciBpbnRvIGEgZnVsbHkgdGhvdWdodC1vdXQgZXh0ZW5zaW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBh cyBhIHNlcGFyYXRlIFNBTUwgYXNzZXJ0aW9uIHNwZWNpZmljYXRpb24gd2l0aCBhY3RpdmUgZGVw bG95bWVudCAodGhlIHR3bywgdG9nZXRoZXIgd2l0aCBydW5uaW5nIGNvZGUsIHNob3cgY2xlYXIg Y29uc2Vuc3VzKS4NCg0KMi4gICAgICAgVGhlIHNlY3Rpb24gaXMgYSBjb25mdXNlZCBtaXggb2Yg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc3ByaW5rbGVkIHdpdGggbm9ybWF0aXZlIGxhbmd1YWdl LiBJbnN0ZWFkLCBpdCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBndWlkZWxpbmVzIGZvciBleHRl bmRpbmcgdGhlIHNldCBvZiBzdXBwb3J0ZWQgY2xpZW50IGNyZWRlbnRpYWxzLCBidXQgd2l0aG91 dCBkZWZpbmluZyBhIG5ldyByZWdpc3RyeS4gSXQgaXMgY2xlYXJseSBhbiBhcmVhIG9mIGxpdHRs ZSBkZXBsb3ltZW50IGV4cGVyaWVuY2UgZm9yIE9BdXRoLCBhbmQgdGhhdCBpbmNsdWRlcyB1c2lu ZyBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gKG1v cmUgb24gdGhhdCB0byBjb21lKS4NCg0KMy4gICAgICAgVGhlIHNlY3Rpb24gaGFzIHJlY2VpdmVk IGEgbGl0dGxlIHN1cHBvcnQgYW5kIGEgbGl0dGxlIG9iamVjdGlvbi4gVGhvc2Ugd2hvIHN0aWxs IHdhbnQgdG8gYWR2b2NhdGUgZm9yIGl0IG5lZWQgdG8gc2hvdyBub3Qgb25seSBjb25zZW5zdXMg Zm9yIGtlZXBpbmcgaXQsIGJ1dCBhbHNvIGFjdGl2ZSBjb21tdW5pdHkgc3VwcG9ydCBmb3IgZGVw bG95aW5nIGl0LiBEZXBsb3ltZW50LCBvZiBjb3Vyc2UsIHdpbGwgYWxzbyByZXF1aXJlIHNob3dp bmcgcHJvZ3Jlc3Mgb24gcHVibGljIHNwZWNpZmljYXRpb25zIHByb2ZpbGluZyB0aGUgbWVjaGFu aXNtIGludG8gYSB1c2VmdWwgaW50ZXJvcGVyYWJsZSBmZWF0dXJlLg0KDQpDb21tZW50cz8gQ291 bnRlci1hcmd1bWVudHM/DQoNCkVITA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1h aWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb2F1dGgNCg== --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F94P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFk Pjxib2R5IGJnY29sb3I9d2hpdGUgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxk aXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPllvdSBzdGlsbCBuZWVkIHRvIGRlZmluZSBpdC4gVGhlIHR3byBwYXJhbWV0ZXJzIGRv buKAmXQgYWNjb21wbGlzaCBhbnl0aGluZyBzaW5jZSB5b3UgY2Fu4oCZdCB1c2UgdGhlbSB3aXRo b3V0IGEgbW9yZSBkZXRhaWxlZCBzcGVjaWZpY2F0aW9uLCBpbiB3aGljaCBjYXNlLCB3aGF0IGlz IHRoZSB2YWx1ZSBvZiB0aGlzPyBXaGVyZSBpcyB0aGUgaW50ZXJvcGVyYWJpbGl0eSBnYWluPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+VGhpcyBpcyBjbGVhcmx5IG5vdCBhIGZlYXR1cmUgdGhhdCBpcyBs aWtlbHkgdG8gYmUgaW1wbGVtZW50ZWQgaW4gYW55IGdlbmVyYWwgcHVycG9zZSBsaWJyYXJ5LCB1 bmxpa2UgdGhlIOKAmHNjb3Bl4oCZIHBhcmFtZXRlciB3aGljaCBpcyB1bmRlci1kZWZpbmVkIGJ1 dCBzdGlsbCB1c2VmdWwgZm9yIGxpYnJhcnkgc3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklu Y2x1ZGluZyBpdCBpbiB0aGUgc3BlY2lmaWNhdGlvbiBpcyBjb25mdXNpbmcgKHRoZSB1bmFuaW1v dXMgZmVlZGJhY2sgSSByZWNlaXZlZCBzbyBmYXIpLCB3aXRob3V0IGFueSBiZW5lZml0LiBUaGUg c3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIGNsZWFyIGV4dGVuc2lvbiBtZWNoYW5pc20gZm9yIG5l dyBwYXJhbWV0ZXJzLiBXaHkgaXMgdGhhdCBub3QgZW5vdWdoPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ RUhMPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBQaGlsbGlwIEh1bnQgW21haWx0bzpwaGls Lmh1bnRAT3JhY2xlLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSmFudWFyeSAxNSwg MjAxMSAxMjo1MiBBTTxicj48Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2PGJyPjxiPkNjOjwv Yj4gT0F1dGggV0c8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIFJlbW92YWw6IENs aWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+QSBzdHJvbmcgY2xpZW50IGNyZWRlbnRpYWwgaXMgbmVlZGVkIGluIG1h bnkgY2FzZXMuIEkgaGFkIGFzc3VtZWQgY2xpZW50IGFzc2VydGlvbiB3b3VsZCBmdWxmaWxsIHRo aXMgbmVlZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48YnI+UGhpbDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlNlbnQgZnJvbSBteSBw aG9uZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5PbiAyMDExLTAxLTE0LCBhdCAy Mjo0NSwgRXJhbiBIYW1tZXItTGFoYXYgJmx0OzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVy c2UuY29tIj5lcmFuQGh1ZW5pdmVyc2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCc+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPkkgd291bGQgbGlrZSB0byBzdWdn ZXN0IHdlIGRyb3AgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgKC0xMSBzZWN0aW9u IDMuMikgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbiwgYW5kIGlmIG5lZWRlZCwgcHVibGlzaCBpdCBh cyBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczo8bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBj bGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW4nPjEuPHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDwvc3Bhbj5UaGUgbWVjaGFuaXNtIGlzIHVuZGVyIHNwZWNpZmllZCwgZXNwZWNpYWxseSBp biBpdHMgaGFuZGxpbmcgb2YgdGhlIGNsaWVudF9pZCBpZGVudGlmaWVyICh3aGVuIHVzZWQgdG8g b2J0YWluIGVuZC11c2VyIGF1dGhvcml6YXRpb24pLiBJdCBkb2VzIG5vdCBjb250YWluIGFueSBp bXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRvIGFjY29tcGxpc2ggYW55IGxldmVsIG9mIGludGVyb3Bl cmFiaWxpdHkgb3IgZnVuY3Rpb25hbGl0eS4gVGhpcyBpcyBpbiBjb250cmFzdCB0byB0aGUgYXNz ZXJ0aW9uIGdyYW50IHR5cGUgd2hpY2ggaGFzIG1hdHVyZWQgb3ZlciBhIHllYXIgaW50byBhIGZ1 bGx5IHRob3VnaHQtb3V0IGV4dGVuc2lvbiBtZWNoYW5pc20sIGFzIHdlbGwgYXMgYSBzZXBhcmF0 ZSBTQU1MIGFzc2VydGlvbiBzcGVjaWZpY2F0aW9uIHdpdGggYWN0aXZlIGRlcGxveW1lbnQgKHRo ZSB0d28sIHRvZ2V0aGVyIHdpdGggcnVubmluZyBjb2RlLCBzaG93IGNsZWFyIGNvbnNlbnN1cyku PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRl bnQ6LS4yNWluJz4yLjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+VGhlIHNlY3Rpb24gaXMgYSBjb25mdXNlZCBt aXggb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc3ByaW5rbGVkIHdpdGggbm9ybWF0aXZlIGxh bmd1YWdlLiBJbnN0ZWFkLCBpdCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBndWlkZWxpbmVzIGZv ciBleHRlbmRpbmcgdGhlIHNldCBvZiBzdXBwb3J0ZWQgY2xpZW50IGNyZWRlbnRpYWxzLCBidXQg d2l0aG91dCBkZWZpbmluZyBhIG5ldyByZWdpc3RyeS4gSXQgaXMgY2xlYXJseSBhbiBhcmVhIG9m IGxpdHRsZSBkZXBsb3ltZW50IGV4cGVyaWVuY2UgZm9yIE9BdXRoLCBhbmQgdGhhdCBpbmNsdWRl cyB1c2luZyBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIGZvciBjbGllbnQgYXV0aGVudGljYXRp b24gKG1vcmUgb24gdGhhdCB0byBjb21lKS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0 UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDotLjI1aW4nPjMuPHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5U aGUgc2VjdGlvbiBoYXMgcmVjZWl2ZWQgYSBsaXR0bGUgc3VwcG9ydCBhbmQgYSBsaXR0bGUgb2Jq ZWN0aW9uLiBUaG9zZSB3aG8gc3RpbGwgd2FudCB0byBhZHZvY2F0ZSBmb3IgaXQgbmVlZCB0byBz aG93IG5vdCBvbmx5IGNvbnNlbnN1cyBmb3Iga2VlcGluZyBpdCwgYnV0IGFsc28gYWN0aXZlIGNv bW11bml0eSBzdXBwb3J0IGZvciBkZXBsb3lpbmcgaXQuIERlcGxveW1lbnQsIG9mIGNvdXJzZSwg d2lsbCBhbHNvIHJlcXVpcmUgc2hvd2luZyBwcm9ncmVzcyBvbiBwdWJsaWMgc3BlY2lmaWNhdGlv bnMgcHJvZmlsaW5nIHRoZSBtZWNoYW5pc20gaW50byBhIHVzZWZ1bCBpbnRlcm9wZXJhYmxlIGZl YXR1cmUuPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Q29tbWVudHM/IENvdW50ZXItYXJndW1lbnRzPzxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPkVITDxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPiZuYnNwOzxvOnA+PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0aCBt YWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm Lm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48 bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5 PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7F94P3PW5EX1MB01E_-- From phil.hunt@oracle.com Sat Jan 15 12:06:05 2011 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 83E473A6E35 for ; Sat, 15 Jan 2011 12:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.668 X-Spam-Level: X-Spam-Status: No, score=-4.668 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 bIPsoaCKAuRv for ; Sat, 15 Jan 2011 12:06:04 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 4336D3A6E34 for ; Sat, 15 Jan 2011 12:06:04 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0FK8VG2025890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 15 Jan 2011 20:08:32 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0FGtOcC021335; Sat, 15 Jan 2011 20:08:30 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 928391741295122023; Sat, 15 Jan 2011 12:07:03 -0800 Received: from [25.66.116.102] (/74.198.150.230) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 15 Jan 2011 12:07:02 -0800 References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0DB1EE65-8D69-4B2F-8550-248BC10B076A@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Type: multipart/alternative; boundary=Apple-Mail-4--1012762294 Message-Id: <4CB6C3F5-3C9E-4484-958A-A912EED0F6A6@oracle.com> Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (8C148a) From: Phillip Hunt Date: Sat, 15 Jan 2011 12:06:50 -0800 To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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: Sat, 15 Jan 2011 20:06:05 -0000 --Apple-Mail-4--1012762294 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It just needs to be defined properly. I was speaking only to the requirement= . Not whether what is spec'd now is good or not.=20 I will blog more on this shortly.=20 Cheers, Phil Sent from my phone.=20 On 2011-01-15, at 11:32, Eran Hammer-Lahav wrote: > You still need to define it. The two parameters don=E2=80=99t accomplish a= nything since you can=E2=80=99t use them without a more detailed specificati= on, in which case, what is the value of this? Where is the interoperability g= ain? >=20 > =20 >=20 > This is clearly not a feature that is likely to be implemented in any gene= ral purpose library, unlike the =E2=80=98scope=E2=80=99 parameter which is u= nder-defined but still useful for library support. >=20 > =20 >=20 > Including it in the specification is confusing (the unanimous feedback I r= eceived so far), without any benefit. The specification provides a clear ext= ension mechanism for new parameters. Why is that not enough? >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: Phillip Hunt [mailto:phil.hunt@Oracle.com]=20 > Sent: Saturday, January 15, 2011 12:52 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials >=20 > =20 >=20 > A strong client credential is needed in many cases. I had assumed client a= ssertion would fulfill this need.=20 >=20 >=20 > Phil >=20 > =20 >=20 > Sent from my phone.=20 >=20 >=20 > On 2011-01-14, at 22:45, Eran Hammer-Lahav wrote: >=20 > I would like to suggest we drop the client assertion credentials (-11 sect= ion 3.2) from the specification, and if needed, publish it as a separate spe= cification for the following reasons: >=20 > =20 >=20 > 1. The mechanism is under specified, especially in its handling of t= he client_id identifier (when used to obtain end-user authorization). It doe= s not contain any implementation details to accomplish any level of interope= rability or functionality. This is in contrast to the assertion grant type w= hich has matured over a year into a fully thought-out extension mechanism, a= s well as a separate SAML assertion specification with active deployment (th= e two, together with running code, show clear consensus). >=20 > 2. The section is a confused mix of security considerations sprinkle= d with normative language. Instead, it should be replaced with guidelines fo= r extending the set of supported client credentials, but without defining a n= ew registry. It is clearly an area of little deployment experience for OAuth= , and that includes using HTTP Basic authentication for client authenticatio= n (more on that to come). >=20 > 3. The section has received a little support and a little objection.= Those who still want to advocate for it need to show not only consensus for= keeping it, but also active community support for deploying it. Deployment,= of course, will also require showing progress on public specifications prof= iling the mechanism into a useful interoperable feature. >=20 > =20 >=20 > Comments? Counter-arguments? >=20 > =20 >=20 > EHL >=20 > =20 >=20 > =20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4--1012762294 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
It just needs to be defined properly. I= was speaking only to the requirement. Not whether what is spec'd now is goo= d or not. 

I will blog more on this shortly.&n= bsp;

Cheers,

Phil

= Sent from my phone. 

On 2011-01-15, at 11:32, Eran H= ammer-Lahav <eran@hueniverse.com> wrote:

You st= ill need to define it. The two parameters don=E2=80=99t accomplish anything s= ince you can=E2=80=99t use them without a more detailed specification, in wh= ich case, what is the value of this? Where is the interoperability gain?

&nbs= p;

This is c= learly not a feature that is likely to be implemented in any general purpose= library, unlike the =E2=80=98scope=E2=80=99 parameter which is under-define= d but still useful for library support.

 

Including it in the specification is conf= using (the unanimous feedback I received so far), without any benefit. The s= pecification provides a clear extension mechanism for new parameters. Why is= that not enough?

 

EHL

 

 

A= strong client credential is needed in many cases. I had assumed client asse= rtion would fulfill this need. 


Phil

 

Sent from my phone. <= /p>

I would like to suggest we drop the clien= t assertion credentials (-11 section 3.2) from the specification, and if nee= ded, publish it as a separate specification for the following reasons:<= /o:p>

 

1.   &nb= sp;   The mechanism is under specified, especially in its h= andling of the client_id identifier (when used to obtain end-user authorizat= ion). It does not contain any implementation details to accomplish any level= of interoperability or functionality. This is in contrast to the assertion g= rant type which has matured over a year into a fully thought-out extension m= echanism, as well as a separate SAML assertion specification with active dep= loyment (the two, together with running code, show clear consensus).

2.       The sect= ion is a confused mix of security considerations sprinkled with normative la= nguage. Instead, it should be replaced with guidelines for extending the set= of supported client credentials, but without defining a new registry. It is= clearly an area of little deployment experience for OAuth, and that include= s using HTTP Basic authentication for client authentication (more on that to= come).

3.       <= /span>The section has received a little support and a little objection. Thos= e who still want to advocate for it need to show not only consensus for keep= ing it, but also active community support for deploying it. Deployment, of c= ourse, will also require showing progress on public specifications profiling= the mechanism into a useful interoperable feature.

&nb= sp;

Comments? Counter-arguments?

 

EHL

 

 

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

= --Apple-Mail-4--1012762294-- From Michael.Jones@microsoft.com Sat Jan 15 14:26:42 2011 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 90B5B3A6B96 for ; Sat, 15 Jan 2011 14:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.013, 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 2YIiUvT8C3wa for ; Sat, 15 Jan 2011 14:26:38 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id D86A33A6B46 for ; Sat, 15 Jan 2011 14:26:37 -0800 (PST) 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; Sat, 15 Jan 2011 14:29:07 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Sat, 15 Jan 2011 14:29:07 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Preparation for draft-ietf-oauth-v2-bearer-02 Thread-Index: Acu0VQ64lM4ZZ9AAQ/Km1fXzE9itTAArmjhA Date: Sat, 15 Jan 2011 22:29:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246E97E2@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943246E834E@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246E834E@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246E97E2TK5EX14MBXC202r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Preparation for draft-ietf-oauth-v2-bearer-02 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: Sat, 15 Jan 2011 22:26:42 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246E97E2TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, people can have a look at the current draft in the SubVersion reposito= ry if they're interested: http://svn.openid.net/repos/specifications/oauth= /2.0/. -- Mike From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, January 14, 2011 5:40 PM To: oauth@ietf.org Subject: [OAUTH-WG] Preparation for draft-ietf-oauth-v2-bearer-02 I'd like to publish draft -02 of the bearer token specification next week. = As a heads-up, I have made no normative changes to date. Most changes are= in the security considerations section, which reflects the nature of the m= ajority of feedback received. I'm about to send replies to a number of messages providing feedback. If I= did not respond to your feedback or you disagree with my response, feel fr= ee to bring it to my attention. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943246E97E2TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI, people can have a= look at the current draft in the SubVersion repository if they’re in= terested:  http://sv= n.openid.net/repos/specifications/oauth/2.0/.

 

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

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, January 14, 2011 5:40 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] Preparation for draft-ietf-oauth-v2-bearer-02

 

I’d like to publish draft -02 of the bearer to= ken specification next week.  As a heads-up, I have made no normative = changes to date.  Most changes are in the security considerations sect= ion, which reflects the nature of the majority of feedback received.

 

I’m about to send replies to a number of messa= ges providing feedback.  If I did not respond to your feedback or you = disagree with my response, feel free to bring it to my attention.

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943246E97E2TK5EX14MBXC202r_-- From eran@hueniverse.com Sat Jan 15 23:39:29 2011 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 A31263A6CA2 for ; Sat, 15 Jan 2011 23:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.053, 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 I4HQx5LjEUUV for ; Sat, 15 Jan 2011 23:39:28 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BC32B3A6D0D for ; Sat, 15 Jan 2011 23:39:28 -0800 (PST) Received: (qmail 28162 invoked from network); 16 Jan 2011 07:41:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jan 2011 07:41:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 16 Jan 2011 00:41:57 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Sun, 16 Jan 2011 00:41:46 -0700 Thread-Topic: Format of user-agent response parameters Thread-Index: Acu1T+xU239cl6M9T2Wib1+6iVxBOA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Format of user-agent response parameters 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: Sun, 16 Jan 2011 07:39:29 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why is the token returned in the fragment using form-encoding? This makes n= o sense. It should be a JSON string for the following reasons: 1. All token responses should be the same, which will enable returnin= g structured responses in the future as needed. 2. Using fragments is specifically done to accommodate the user-agent= environment, which means JavaScript. Why create extra work when JSON.parse= () does it for you for free. Returning the authorization code alone using form-encoded in the query stil= l makes sense. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Why is the token= returned in the fragment using form-encoding? This makes no sense. It shou= ld be a JSON string for the following reasons:

 

1.  &nbs= p;    All token responses should be = the same, which will enable returning structured responses in the future as= needed.

2.   &nb= sp;   Using fragments is specifically don= e to accommodate the user-agent environment, which means JavaScript. Why cr= eate extra work when JSON.parse() does it for you for free.

<= p class=3DMsoNormal> 

Returning the= authorization code alone using form-encoded in the query still makes sense= .

 

EHL

 

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4P3PW5EX1MB01E_-- From torsten@lodderstedt.net Sun Jan 16 10:52:05 2011 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 BBC153A6E59 for ; Sun, 16 Jan 2011 10:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.015, 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 BApzxk8jinjf for ; Sun, 16 Jan 2011 10:52:04 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by core3.amsl.com (Postfix) with ESMTP id A42A13A6E5D for ; Sun, 16 Jan 2011 10:52:03 -0800 (PST) Received: from [79.253.20.132] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PeXkG-0001kw-Rk; Sun, 16 Jan 2011 19:54:32 +0100 Message-ID: <4D333EE9.1030706@lodderstedt.net> Date: Sun, 16 Jan 2011 19:54:33 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------020902020904010503030506" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters 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: Sun, 16 Jan 2011 18:52:05 -0000 This is a multi-part message in MIME format. --------------020902020904010503030506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Eran, you made some good points and I agree with most of your analysis. The way we use BASIC in the current draft is not perfect, mainly because it is a compromise. It was basically the attempt to be more HTTP compliant while still supporting the parameter-based approach. I would strongly object against removing BASIC and relying on body parameters, only. We (Deutsche Telekom) have implemented that scheme and do not see a real problem with it. In order to overcome the problems you listed, I would like to propose an alternative approach. I would suggest to drop support for passing any credentials to the tokens endpoint in the body of the POST request. Instead, I would suggest to define one HTTP authentication scheme per grant type and send the corresponding parameters within the Authorization header. Conceptually, the tokens endpoint is a resource URI clients use to obtain tokens. The expected token scope can be explicitely specified by the corresponding URI query parameter. So the simplest, complete request to obtain a token could look as follows: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded scope=something Most authorization servers will certainly need credentials of some kind as pre-requisite for token issuance. These credentials actually authenticate the resource owner and the client to the authorization server as well as prove the client's authorization to get the token. Such credentials are usually passed using authorization headers in HTTP requests. Let's take the example of the grant type "code". We could define a scheme "CODE", which carries the parameters code, redirect_uri, client_id and client_secret (optionally) as named values. An example request could look as follows POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: CODE code='i1WsRn1uB1', redirect_uri='https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb', client_id='s6BhdRkqt3', client_secret='gX1fBat3bV' scope=something The following examples illustrate the approach with respect to the grant types "password" and "refresh_token", respectively. POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: PWD username='johndoe', password='A3ddj3w', client_id='s6BhdRkqt3', client_secret='gX1fBat3bV' scope=something POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: REFRESH token='n4E9O119d', client_id='s6BhdRkqt3', client_secret='gX1fBat3bV' scope=something I see the following advantages: 1) The suggest approach is aligned with HTTP. So instead of using HTTP as "transport protocol" only (as in the dark times of SOAP), we could make better use of the existing framework for messaging, caching, and security. 2) Since the proposed approach is alligned with HTTP authentication and authorization in general, it would be an easy task to add support for additional, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or GBA to an OAuth authorization server. 3) WWW-Authenticate headers could be used to provide clients with useful information about the capabilities of the authorization server. In the following example, the server reacts to an unauthenticated request with the following response HTTP/1.1 401 Unauthorized WWW-Authenticate: CODE uri="tokenservice.example.com/authorize" WWW-Authenticate: PWD realm='users.example.com' WWW-Authenticate: REFRESH which indicates its support for the grant types authorization_code, username/password and refresh token. Additionally it provides the client with the end-user endpoint URI of the authorization server and the user realm supported for password authentication. 4) The proposed mechanism should work nicely with existing authentication frameworks, since we would no longer use a mixed model for passing credentials and dedicated HTTP authentication schemes. What do you think? What do others think? regards, Torsten. Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav: > > OAuth 2.0 provides two methods for client authentication using > password credentials: request parameters and HTTP Basic > authentication. I suggest we drop the requirement to support HTTP > Basic authentication, and only mention it as an example for > alternative methods. My reasons are: > > 1.A few providers have expressed concerns over the need to support > Basic authentication, and some explicitly said they will not support > it. Parameter-based authentication, OTOH, is widely deployed in 2.0. > > 2.Due to the way OAuth is being implemented at the HTTP authentication > layer (even if it is wrong), can conflict within the framework as both > a consumer and provider of authentication components. > > 3.The mapping between username and client_id, while not complicated, > is still a big awkward, and can be confusing when combined with the > username and password grant type. On the other hand, the use of > client_id in the end-user authorization endpoint lends itself nicely > to the use of the same parameter elsewhere. > > 4.Some existing authentication frameworks will have an issue handling > the mix of Basic authentication and parameters authentication due to > how each is deployed. In cases where a front gate handles Basic, it > will be hard to let requests through for parameter processing. > > Comments? Counter-arguments? > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020902020904010503030506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Eran,

you made some good points and I agree with most of your analysis. The way we use BASIC in the current draft is not perfect, mainly because it is a compromise. It was basically the attempt to be more HTTP compliant while still supporting the parameter-based approach.

I would strongly object against removing BASIC and relying on body parameters, only.  We (Deutsche Telekom) have implemented that scheme and do not see a real problem with it.

In order to overcome the problems you listed, I would like to propose an alternative approach.

I would suggest to drop support for passing any credentials to the tokens endpoint in the body of the POST request. Instead, I would suggest to define one HTTP authentication scheme per grant type and send the corresponding parameters within the Authorization header.

Conceptually, the tokens endpoint is a resource URI clients use to obtain tokens. The expected token scope can be explicitely specified by the corresponding URI query parameter. So the simplest, complete request to obtain a token could look as follows:

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     scope=something

Most authorization servers will certainly need credentials of some kind as pre-requisite for token issuance. These credentials actually authenticate the resource owner and the client to the authorization server as well as prove the client's authorization to get the token. Such credentials are usually passed using authorization headers in HTTP requests.

Let's take the example of the grant type "code". We could define a scheme "CODE", which carries the parameters code, redirect_uri, client_id and client_secret (optionally) as named values. An example request could look as follows

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: CODE code='i1WsRn1uB1',
                         redirect_uri='https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb',
                         client_id='s6BhdRkqt3',
                         client_secret='gX1fBat3bV'

     scope=something

The following examples illustrate the approach with respect to the grant types "password" and "refresh_token", respectively.

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: PWD username='johndoe',
                        password='A3ddj3w',
                         client_id='s6BhdRkqt3',
                         client_secret='gX1fBat3bV'

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: REFRESH token='n4E9O119d',
                            client_id='s6BhdRkqt3',
                            client_secret='gX1fBat3bV'

     scope=something

I see the following advantages:
1) The suggest approach is aligned with HTTP. So instead of using HTTP as "transport protocol" only (as in the dark times of SOAP), we could make better use of the existing framework for messaging, caching, and security.

2) Since the proposed approach is alligned with HTTP authentication and authorization in general, it would be an easy task to add support for additional, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or GBA to an OAuth authorization server.

3) WWW-Authenticate headers could be used to provide clients with useful information about the capabilities of the authorization server. In the following example, the server reacts to an unauthenticated request with the following response

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: CODE uri="tokenservice.example.com/authorize"
     WWW-Authenticate: PWD realm='users.example.com'
     WWW-Authenticate: REFRESH

which indicates its support for the grant types authorization_code, username/password and refresh token. Additionally it provides the client with the end-user endpoint URI of the authorization server and the user realm supported for password authentication.

4) The proposed mechanism should work nicely with existing authentication frameworks, since we would no longer use a mixed model for passing credentials and dedicated HTTP authentication schemes.

What do you think? What do others think?

regards,
Torsten.


Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav:

OAuth 2.0 provides two methods for client authentication using password credentials: request parameters and HTTP Basic authentication. I suggest we drop the requirement to support HTTP Basic authentication, and only mention it as an example for alternative methods. My reasons are:

 

1.       A few providers have expressed concerns over the need to support Basic authentication, and some explicitly said they will not support it. Parameter-based authentication, OTOH, is widely deployed in 2.0.

2.       Due to the way OAuth is being implemented at the HTTP authentication layer (even if it is wrong), can conflict within the framework as both a consumer and provider of authentication components.

3.       The mapping between username and client_id, while not complicated, is still a big awkward, and can be confusing when combined with the username and password grant type. On the other hand, the use of client_id in the end-user authorization endpoint lends itself nicely to the use of the same parameter elsewhere.

4.       Some existing authentication frameworks will have an issue handling the mix of Basic authentication and parameters authentication due to how each is deployed. In cases where a front gate handles Basic, it will be hard to let requests through for parameter processing.

 

Comments? Counter-arguments?

 

EHL


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

--------------020902020904010503030506-- From torsten@lodderstedt.net Sun Jan 16 10:57:11 2011 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 70BB83A6E5A for ; Sun, 16 Jan 2011 10:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.015, 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 w6Qc7N84TH76 for ; Sun, 16 Jan 2011 10:57:05 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by core3.amsl.com (Postfix) with ESMTP id 24F8D3A6E04 for ; Sun, 16 Jan 2011 10:57:04 -0800 (PST) Received: from [79.253.20.132] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PeXp9-0003Up-Jm; Sun, 16 Jan 2011 19:59:35 +0100 Message-ID: <4D334018.3020602@lodderstedt.net> Date: Sun, 16 Jan 2011 19:59:36 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------050107080007060307070506" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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: Sun, 16 Jan 2011 18:57:11 -0000 This is a multi-part message in MIME format. --------------050107080007060307070506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit wouldn't that mean to drop section 6 completely? regards, Torsten. Am 15.01.2011 07:32, schrieb Eran Hammer-Lahav: > > One of the main problems with OAuth in general has always been the > unsanitary mix of authorization and authentication ("it's an > authentication protocol... authorization protocol... authentication > protocol" [1]). It has always been a confusing mess. The work on 2.0 > has provided a valuable abstraction and separation of the two > components, especially the recent document split. In addition, the > recent work on the bearer token document and the MAC token type have > raised issues about OAuth and its relationship with HTTP authentication. > > I would like to suggest we drop the 'OAuth2' WWW-Authenticate header > completely from the specification for the following reasons: > > 1.Draft oauth-v2 is clearly not an authentication protocol. It > **utilizes** client authentication. It offers one fully defined method > for client authentication (which is basically HTTP Basic+), provides a > half-baked client assertion authentication hook, and leaves all > end-user authentication out of scope. > > 2.The WWW-Authenticate header has absolutely no value, > interoperability-wise or otherwise. Discovery was rules to be beyond > the scope of this specification. Having a protected resource declare > it supports authentication using some unspecified credentials obtained > using some unspecified client flow is confusing at best. In the > future, an interoperable discovery mechanism will be needed to allow > clients to interact with completely unknown protected resources, but > this has been consistently ruled to be premature standardization at > this point. > > 3.OAuth is agnostic to token authentication, and we already have three > discrete token type proposals -- all with active deployment plans in > the coming months. Two of these methods have already defined a full > HTTP authentication scheme (even if the bearer token specification has > not yet been updated to change its scheme name). > > 4.HTTP **authentication** is not an appropriate facility to negotiate > **authorization**. OAuth authorization discovery can be added to HTTP > authentication schemes as attributes, but makes no sense as a scheme > of its own. The issues we are having with 'realm' is one of the > examples showing that we are abusing the header. > > 5.Again, as specified, it adds no value and I am not aware of any > existing OAuth 1.0a implementation making use of the response header > for client interoperability (yes, many include it, but how many > clients actually rely on it, and if they do, how?). > > For these reasons I would like to suggest we: > > 1.Drop the WWW-Authenticate header definition and OAuth2 scheme from > the specification, leaving it up to each token type to define its own > authentication flow. In the future, a comprehensive discovery > specification should define a new HTTP response header for providing > discovery information. I have suggested using Link: > rel='authorization' as a simple yet powerful solution. > > 2.Rename the document to 'The OAuth 2.0 Authorization Protocol' to > make it clear what this document is really about. > > Comments? Counter argument? > > EHL > > [1] http://www.youtube.com/watch?v=0IBZocFkXGY > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------050107080007060307070506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit wouldn't that mean to drop section 6 completely?

regards,
Torsten.

Am 15.01.2011 07:32, schrieb Eran Hammer-Lahav:

One of the main problems with OAuth in general has always been the unsanitary mix of authorization and authentication (“it’s an authentication protocol… authorization protocol… authentication protocol” [1]). It has always been a confusing mess. The work on 2.0 has provided a valuable abstraction and separation of the two components, especially the recent document split. In addition, the recent work on the bearer token document and the MAC token type have raised issues about OAuth and its relationship with HTTP authentication.

 

I would like to suggest we drop the ‘OAuth2’ WWW-Authenticate header completely from the specification for the following reasons:

 

1.       Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* client authentication. It offers one fully defined method for client authentication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all end-user authentication out of scope.

2.       The WWW-Authenticate header has absolutely no value, interoperability-wise or otherwise. Discovery was rules to be beyond the scope of this specification. Having a protected resource declare it supports authentication using some unspecified credentials obtained using some unspecified client flow is confusing at best. In the future, an interoperable discovery mechanism will be needed to allow clients to interact with completely unknown protected resources, but this has been consistently ruled to be premature standardization at this point.

3.       OAuth is agnostic to token authentication, and we already have three discrete token type proposals – all with active deployment plans in the coming months. Two of these methods have already defined a full HTTP authentication scheme (even if the bearer token specification has not yet been updated to change its scheme name).

4.       HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery can be added to HTTP authentication schemes as attributes, but makes no sense as a scheme of its own. The issues we are having with ‘realm’ is one of the examples showing that we are abusing the header.

5.       Again, as specified, it adds no value and I am not aware of any existing OAuth 1.0a implementation making use of the response header for client interoperability (yes, many include it, but how many clients actually rely on it, and if they do, how?).

 

For these reasons I would like to suggest we:

 

1.       Drop the WWW-Authenticate header definition and OAuth2 scheme from the specification, leaving it up to each token type to define its own authentication flow. In the future, a comprehensive discovery specification should define a new HTTP response header for providing discovery information. I have suggested using Link: rel=’authorization’ as a simple yet powerful solution.

2.       Rename the document to ‘The OAuth 2.0 Authorization Protocol’ to make it clear what this document is really about.

 

Comments? Counter argument?

 

EHL

 

[1] http://www.youtube.com/watch?v=0IBZocFkXGY

 


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

--------------050107080007060307070506-- From torsten@lodderstedt.net Sun Jan 16 10:59:09 2011 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 214783A6E59 for ; Sun, 16 Jan 2011 10:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.234 X-Spam-Level: X-Spam-Status: No, score=-2.234 tagged_above=-999 required=5 tests=[AWL=0.014, 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 6YavqyAHYxdG for ; Sun, 16 Jan 2011 10:59:08 -0800 (PST) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by core3.amsl.com (Postfix) with ESMTP id E1A2F3A6E04 for ; Sun, 16 Jan 2011 10:59:07 -0800 (PST) Received: from [79.253.20.132] (helo=[192.168.71.49]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PeXr9-0006qQ-31; Sun, 16 Jan 2011 20:01:39 +0100 Message-ID: <4D334093.1050006@lodderstedt.net> Date: Sun, 16 Jan 2011 20:01:39 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------020903050309060007090301" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Format of user-agent response parameters 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: Sun, 16 Jan 2011 18:59:09 -0000 This is a multi-part message in MIME format. --------------020903050309060007090301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 pro JSON Am 16.01.2011 08:41, schrieb Eran Hammer-Lahav: > > Why is the token returned in the fragment using form-encoding? This > makes no sense. It should be a JSON string for the following reasons: > > 1.All token responses should be the same, which will enable returning > structured responses in the future as needed. > > 2.Using fragments is specifically done to accommodate the user-agent > environment, which means JavaScript. Why create extra work when > JSON.parse() does it for you for free. > > Returning the authorization code alone using form-encoded in the query > still makes sense. > > EHL > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --------------020903050309060007090301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1 pro JSON

Am 16.01.2011 08:41, schrieb Eran Hammer-Lahav:

Why is the token returned in the fragment using form-encoding? This makes no sense. It should be a JSON string for the following reasons:

 

1.       All token responses should be the same, which will enable returning structured responses in the future as needed.

2.       Using fragments is specifically done to accommodate the user-agent environment, which means JavaScript. Why create extra work when JSON.parse() does it for you for free.

 

Returning the authorization code alone using form-encoded in the query still makes sense.

 

EHL

 

 


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

--------------020903050309060007090301-- From recordond@gmail.com Sun Jan 16 12:34:27 2011 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 DFA8C3A6E15 for ; Sun, 16 Jan 2011 12:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=1.429, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 eK7rqq6A8ZIM for ; Sun, 16 Jan 2011 12:34:26 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 9AF313A6E04 for ; Sun, 16 Jan 2011 12:34:26 -0800 (PST) Received: by iwn40 with SMTP id 40so4407144iwn.31 for ; Sun, 16 Jan 2011 12:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vL90qF16YQSkOWSY4Q6edG11WxXtN3RRZA1a8yo2tac=; b=YDks8U5ZZR2Nq7YhizBDLfS5EpYPnyqmBL9zJ+21NAM94Q/jb0vV+oYbtNErtWiauj uyidW+RpJimIHaCkyQdABxS0wqoAGIxyQaGXGY7dKgNGf5uELO3ctwnFAAi1125tWP1Q MkEqjbNLxPY2uUbSKyOBgU7rge1pEHWOJ/7Tc= 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=bSWuK72UbH1X3IdB5RN/sqJcX0Zds56w85wWRUUyE2hWNQ1a7Nxp09wqdIDKq9k9kT EjdD70xrP4iWoxT2caO+6VPOwTwyf6M6LqkAubAHcWyvu1FdAAfXlSW7TWdMzvE86Dsl InuWrXA9dGgGVDqWWtS1pjEHPvuwYysmEdxZw= MIME-Version: 1.0 Received: by 10.231.12.10 with SMTP id v10mr3275073ibv.171.1295210218689; Sun, 16 Jan 2011 12:36:58 -0800 (PST) Received: by 10.231.160.21 with HTTP; Sun, 16 Jan 2011 12:36:58 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0DB1EE65-8D69-4B2F-8550-248BC10B076A@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F94@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sun, 16 Jan 2011 12:36:58 -0800 Message-ID: From: David Recordon To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0022152d6181fe94bf0499fca05d Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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: Sun, 16 Jan 2011 20:34:28 -0000 --0022152d6181fe94bf0499fca05d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Seems good enough to me. +1 to removing it so that it will become fully fleshed out in a useful manner. On Sat, Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav wr= ote: > You still need to define it. The two parameters don=92t accomplish anythi= ng > since you can=92t use them without a more detailed specification, in whic= h > case, what is the value of this? Where is the interoperability gain? > > > > This is clearly not a feature that is likely to be implemented in any > general purpose library, unlike the =91scope=92 parameter which is under-= defined > but still useful for library support. > > > > Including it in the specification is confusing (the unanimous feedback I > received so far), without any benefit. The specification provides a clear > extension mechanism for new parameters. Why is that not enough? > > > > EHL > > > > *From:* Phillip Hunt [mailto:phil.hunt@Oracle.com] > *Sent:* Saturday, January 15, 2011 12:52 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Removal: Client Assertion Credentials > > > > A strong client credential is needed in many cases. I had assumed client > assertion would fulfill this need. > > > Phil > > > > Sent from my phone. > > > On 2011-01-14, at 22:45, Eran Hammer-Lahav wrote: > > I would like to suggest we drop the client assertion credentials (-11 > section 3.2) from the specification, and if needed, publish it as a separ= ate > specification for the following reasons: > > > > 1. The mechanism is under specified, especially in its handling of > the client_id identifier (when used to obtain end-user authorization). It > does not contain any implementation details to accomplish any level of > interoperability or functionality. This is in contrast to the assertion > grant type which has matured over a year into a fully thought-out extensi= on > mechanism, as well as a separate SAML assertion specification with active > deployment (the two, together with running code, show clear consensus). > > 2. The section is a confused mix of security considerations > sprinkled with normative language. Instead, it should be replaced with > guidelines for extending the set of supported client credentials, but > without defining a new registry. It is clearly an area of little deployme= nt > experience for OAuth, and that includes using HTTP Basic authentication f= or > client authentication (more on that to come). > > 3. The section has received a little support and a little objection= . > Those who still want to advocate for it need to show not only consensus f= or > keeping it, but also active community support for deploying it. Deploymen= t, > of course, will also require showing progress on public specifications > profiling the mechanism into a useful interoperable feature. > > > > Comments? Counter-arguments? > > > > 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 > > --0022152d6181fe94bf0499fca05d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Seems good enough to me. +1 to removing it so that it will become fully fle= shed out in a useful manner.


On Sat,= Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

You still need to define it. The two parameters = don=92t accomplish anything since you can=92t use them without a more detai= led specification, in which case, what is the value of this? Where is the i= nteroperability gain?

=A0

This is clearly not a feature that is likely to be implemented in any g= eneral purpose library, unlike the =91scope=92 parameter which is under-def= ined but still useful for library support.

=A0

Including it in the specification is confusing (the unanimous feedback = I received so far), without any benefit. The specification provides a clear= extension mechanism for new parameters. Why is that not enough?

=A0

EHL

=A0

From: Phillip Hunt [mailto= :phil.hunt@Oracle= .com]
Sent: Saturday, January 15, 2011 12:52 AM
To: Eran Hammer-= Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: Cli= ent Assertion Credentials

=A0

A strong cli= ent credential is needed in many cases. I had assumed client assertion woul= d fulfill this need.=A0


Phil

=A0

Sent from my phone.=A0


On 2011-= 01-14, at 22:45, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

=

I would like to suggest we drop the client assertion= credentials (-11 section 3.2) from the specification, and if needed, publi= sh it as a separate specification for the following reasons:

=A0

1.=A0=A0= =A0=A0=A0=A0 The mechanism is under specified, especially in its han= dling of the client_id identifier (when used to obtain end-user authorizati= on). It does not contain any implementation details to accomplish any level= of interoperability or functionality. This is in contrast to the assertion= grant type which has matured over a year into a fully thought-out extensio= n mechanism, as well as a separate SAML assertion specification with active= deployment (the two, together with running code, show clear consensus).

2.=A0=A0=A0=A0=A0=A0 The section = is a confused mix of security considerations sprinkled with normative langu= age. Instead, it should be replaced with guidelines for extending the set o= f supported client credentials, but without defining a new registry. It is = clearly an area of little deployment experience for OAuth, and that include= s using HTTP Basic authentication for client authentication (more on that t= o come).

3.=A0=A0=A0=A0=A0=A0 The section = has received a little support and a little objection. Those who still want = to advocate for it need to show not only consensus for keeping it, but also= active community support for deploying it. Deployment, of course, will als= o require showing progress on public specifications profiling the mechanism= into a useful interoperable feature.

=A0

Comments? Counter-argu= ments?

=A0

EHL

=A0

=A0

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


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


--0022152d6181fe94bf0499fca05d-- From eran@hueniverse.com Sun Jan 16 14:03:14 2011 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 380113A67DF for ; Sun, 16 Jan 2011 14:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, 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 8w4lP6EpwJzk for ; Sun, 16 Jan 2011 14:03:07 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 024E63A6CEF for ; Sun, 16 Jan 2011 14:03:06 -0800 (PST) Received: (qmail 21002 invoked from network); 16 Jan 2011 22:05:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jan 2011 22:05:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 16 Jan 2011 15:05:37 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Sun, 16 Jan 2011 15:05:35 -0700 Thread-Topic: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu1r4ahlz6fBrinS3a7VTAdUYSiJQAGedkw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FE5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D334018.3020602@lodderstedt.net> In-Reply-To: <4D334018.3020602@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FE5P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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: Sun, 16 Jan 2011 22:03:14 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FE5P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, it will just be very short giving an introduction to how to use tokens = in general, how to define token types, and will include two examples for be= arer tokens and mac tokens. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, January 16, 2011 11:00 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme wouldn't that mean to drop section 6 completely? regards, Torsten. Am 15.01.2011 07:32, schrieb Eran Hammer-Lahav: One of the main problems with OAuth in general has always been the unsanita= ry mix of authorization and authentication ("it's an authentication protoco= l... authorization protocol... authentication protocol" [1]). It has always= been a confusing mess. The work on 2.0 has provided a valuable abstraction= and separation of the two components, especially the recent document split= . In addition, the recent work on the bearer token document and the MAC tok= en type have raised issues about OAuth and its relationship with HTTP authe= ntication. I would like to suggest we drop the 'OAuth2' WWW-Authenticate header comple= tely from the specification for the following reasons: Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* cli= ent authentication. It offers one fully defined method for client authentic= ation (which is basically HTTP Basic+), provides a half-baked client assert= ion authentication hook, and leaves all end-user authentication out of scop= e. The WWW-Authenticate header has absolutely no value, interoperability-wise = or otherwise. Discovery was rules to be beyond the scope of this specificat= ion. Having a protected resource declare it supports authentication using s= ome unspecified credentials obtained using some unspecified client flow is = confusing at best. In the future, an interoperable discovery mechanism will= be needed to allow clients to interact with completely unknown protected r= esources, but this has been consistently ruled to be premature standardizat= ion at this point. OAuth is agnostic to token authentication, and we already have three discre= te token type proposals - all with active deployment plans in the coming mo= nths. Two of these methods have already defined a full HTTP authentication = scheme (even if the bearer token specification has not yet been updated to = change its scheme name). HTTP *authentication* is not an appropriate facility to negotiate *authoriz= ation*. OAuth authorization discovery can be added to HTTP authentication s= chemes as attributes, but makes no sense as a scheme of its own. The issues= we are having with 'realm' is one of the examples showing that we are abus= ing the header. Again, as specified, it adds no value and I am not aware of any existing OA= uth 1.0a implementation making use of the response header for client intero= perability (yes, many include it, but how many clients actually rely on it,= and if they do, how?). For these reasons I would like to suggest we: Drop the WWW-Authenticate header definition and OAuth2 scheme from the spec= ification, leaving it up to each token type to define its own authenticatio= n flow. In the future, a comprehensive discovery specification should defin= e a new HTTP response header for providing discovery information. I have su= ggested using Link: rel=3D'authorization' as a simple yet powerful solution= . Rename the document to 'The OAuth 2.0 Authorization Protocol' to make it cl= ear what this document is really about. Comments? Counter argument? EHL [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FE5P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= No, it will just be very short giving an intr= oduction to how to use tokens in general, how to define token types, and wi= ll include two examples for bearer tokens and mac tokens.=

 

EHL

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
= Sent: Sunday, January 16, 2011 11:00 AM
To: Eran Hammer-La= hav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: 'OAut= h2' HTTP Authentication Scheme

 

wouldn't that mean to d= rop section 6 completely?

regards,
Torsten.

Am 15.01.2011 = 07:32, schrieb Eran Hammer-Lahav:

One o= f the main problems with OAuth in general has always been the unsanitary mi= x of authorization and authentication (“it’s an authentication = protocol… authorization protocol… authentication protocol”= ; [1]). It has always been a confusing mess. The work on 2.0 has provided a= valuable abstraction and separation of the two components, especially the = recent document split. In addition, the recent work on the bearer token doc= ument and the MAC token type have raised issues about OAuth and its relatio= nship with HTTP authentication.

 

I would like to suggest we drop the ̵= 6;OAuth2’ WWW-Authenticate header completely from the specification f= or the following reasons:

 

Draft oauth= -v2 is clearly not an authentication protocol. It *utilizes* client = authentication. It offers one fully defined method for client authenticatio= n (which is basically HTTP Basic+), provides a half-baked client assertion = authentication hook, and leaves all end-user authentication out of scope.

The W= WW-Authenticate header has absolutely no value, interoperability-wise or ot= herwise. Discovery was rules to be beyond the scope of this specification. = Having a protected resource declare it supports authentication using some u= nspecified credentials obtained using some unspecified client flow is confu= sing at best. In the future, an interoperable discovery mechanism will be n= eeded to allow clients to interact with completely unknown protected resour= ces, but this has been consistently ruled to be premature standardization a= t this point.

OAuth is agnostic to token authentication, and we already have th= ree discrete token type proposals – all with active deployment plans = in the coming months. Two of these methods have already defined a full HTTP= authentication scheme (even if the bearer token specification has not yet = been updated to change its scheme name).

HTTP *authentication* is not an= appropriate facility to negotiate *authorization*. OAuth authorizat= ion discovery can be added to HTTP authentication schemes as attributes, bu= t makes no sense as a scheme of its own. The issues we are having with R= 16;realm’ is one of the examples showing that we are abusing the head= er.

= Again, as specified, it adds no value and I am not aware of any existing OA= uth 1.0a implementation making use of the response header for client intero= perability (yes, many include it, but how many clients actually rely on it,= and if they do, how?).

 

For these reasons I would like to suggest we:

 

Drop the WWW-Authenticate header definit= ion and OAuth2 scheme from the specification, leaving it up to each token t= ype to define its own authentication flow. In the future, a comprehensive d= iscovery specification should define a new HTTP response header for providi= ng discovery information. I have suggested using Link: rel=3D’authori= zation’ as a simple yet powerful solution.

Rename the document to ‘= The OAuth 2.0 Authorization Protocol’ to make it clear what this docu= ment is really about.

 <= /p>

Comments? Counter argument?

 

EHL

 

[1] http://www.youtube.com/watch= ?v=3D0IBZocFkXGY

 

 
 
____________=
___________________________________
OAuth mailing list=

OAuth@ietf.org<=
o:p>
https://www.ietf.org/mailman/listinfo/oauth

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FE5P3PW5EX1MB01E_-- From bcampbell@pingidentity.com Sun Jan 16 19:27:10 2011 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 30ED428C0E3 for ; Sun, 16 Jan 2011 19:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0zrUfaXfvDEv for ; Sun, 16 Jan 2011 19:27:07 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 5CDB528C0EB for ; Sun, 16 Jan 2011 19:27:07 -0800 (PST) Received: from source ([209.85.161.46]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTTO3o+91amHarn9aylhoFZTAzSUTpf2A@postini.com; Sun, 16 Jan 2011 19:29:40 PST Received: by mail-fx0-f46.google.com with SMTP id 20so6007699fxm.5 for ; Sun, 16 Jan 2011 19:29:39 -0800 (PST) Received: by 10.223.93.140 with SMTP id v12mr4216132fam.96.1295234979613; Sun, 16 Jan 2011 19:29:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.55.9 with HTTP; Sun, 16 Jan 2011 19:29:09 -0800 (PST) In-Reply-To: <4D2E17C2.60205@lodderstedt.net> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2E17C2.60205@lodderstedt.net> From: Brian Campbell Date: Sun, 16 Jan 2011 20:29:09 -0700 Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=20cf3054a619dc4c0d049a026441 Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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: Mon, 17 Jan 2011 03:27:10 -0000 --20cf3054a619dc4c0d049a026441 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess I'm in the minority but I prefer option #1. I do agree with others that naming with respect to authenticated vs. unauthenticated clients is likely problematic. On Wed, Jan 12, 2011 at 2:06 PM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > +1 for option 2 because it will facilitates security analysis of the > protocol. > > From a security analysis perspective, I think we need two views: > 1) A structural view, describing the OAuth architecture (entities, > interfaces, communication paths) and > 2) a flow-oriented view, which is built based on this interfaces, this is > where the more complex threats show up. For example, the session fixation > attack makes use of properties of the flow along both OAuth end-points. > > I assume a structural view will given as well? > > I agree with Marius regarding naming. I don't believe we can forsee today > which clients will be authenticated in the future and which not. I could > imagine deployments with support for web applications w/o authentication.= It > depends on the security policy and the value someone sees in client > authentication (for the purpose of client authorization). On the other ha= nd, > by using dynamically created client_ids and secrets, even native apps cou= ld > authenticate to the authorization server. > > regards, > Torsten. > > Am 12.01.2011 16:15, schrieb Richer, Justin P.: > > Marius makes a good point -- we probably want to avoid using language li= ke >> that for part descriptions. I don't think "code" and "token" quite get i= t, >> but I don't have a better suggestion at the moment though... >> >> -- Justin >> ________________________________________ >> From: Marius Scurtescu [mscurtescu@google.com] >> Sent: Wednesday, January 12, 2011 10:10 AM >> To: Richer, Justin P. >> Cc: Eran Hammer-Lahav; OAuth WG >> Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows)= - >> Vote by 1/17 >> >> +1 for option 2 as well >> >> Not convinced that naming the main flows Authenticated and >> Unauthenticated makes sense, I think it will only increase confusion. >> For example, native apps are not authenticated and they would be using >> the "Authenticated" flow. I think we should stick with something along >> the lines of "Code" and "Token". >> >> Marius >> >> >> >> On Wed, Jan 12, 2011 at 10:02 AM, Richer, Justin P. >> wrote: >> >>> +1 for option 2 >>> >>> I see, and have always seen, the target audience as server and client >>> developers who are likely to be working against one flow and use case a= t a >>> time. Also, I disagree that the primary role of the server developer is= the >>> security considerations. In theory, you may be right, but in practice, = I >>> think you'll find that many are going to be more concerned with just ma= king >>> it work at all with their API/framework/server. >>> >>> -- Justin >>> ________________________________________ >>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran >>> Hammer-Lahav [eran@hueniverse.com] >>> Sent: Wednesday, January 12, 2011 2:19 AM >>> To: OAuth WG >>> Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - >>> Vote by 1/17 >>> >>> (Vote at the end, please read) >>> >>> Background >>> >>> Between draft -00 and -05 the document used a flow-based organization. >>> This was changed to an endpoint-based organization in draft -06. I have >>> received requests to go back to the flow-based organization, and with -= 12, >>> have been planning to do that. It is important to note that -12 is not = meant >>> to include any change in normative language and that -11 code would rem= ain >>> unchanged under -12. This is purely editorial. >>> >>> Part of that effort included reviewing the various flows in -05. The fl= ow >>> categories and definitions have always been a source of confusion. Some >>> target specific client architecture (user-agent, web server, device), s= ome >>> are abstractions for future extensibility (assertion), and some are us= eful >>> features that can apply to a wide range of clients (client credentials, >>> username and password). We also have the odd anti-profile of the native >>> application flow, which in practice is a half-baked guide to navigating= the >>> entire range of flows. >>> >>> In practice we have a few ways to get an access token which can be >>> categorized in multiple ways: >>> >>> >>> 1. How authorization is obtained? >>> >>> a. Redirection-based =96 user-agent, web-server >>> >>> b. Direct credentials =96 client credentials, username and passwor= d, >>> assertion >>> >>> 2. Is the client authenticated? >>> >>> a. Yes =96 web-server, client credentials, username and password, >>> assertion (based on type) >>> >>> b. No =96 user-agent, assertion (based on type) >>> >>> In the past we had another (broken) organization of User delegation, Us= er >>> credentials, and Autonomous. >>> >>> Analysis >>> >>> After studying the document and breaking it apart (in my editor) I came >>> to a few conclusions (which you are invited to disprove): >>> >>> >>> 1. Flow names must be consistent and based on the key >>> differentiator of each flow. I believe the ability of the client to >>> authenticate is the most significant aspect of each flow. I agree that = ease >>> of deployment and performance are important, but this is a security pro= tocol >>> and the security considerations should be the primary attribute used to >>> select flows. >>> >>> 2. The endpoint-based organization turned a few discrete flows in= to >>> a single protocol. This protocol should be profiled based on some key c= lient >>> characteristics (such as redirection and ability of the client to >>> authenticate). The main objective of the profiles would be to provide a >>> security-focused description. >>> >>> 3. The hybrid flow, combining the user-agent and web-server into = a >>> code-and-token solution is a distinct profile with its own unique secur= ity >>> properties. While its implementation details are important for efficien= cy, >>> the main differentiator is the client dual nature of being able to main= tain >>> secret credentials in some parts, but not in others. It produces two ac= cess >>> tokens using a single authorization and client identifier. >>> >>> 4. The document must not repeat the mistake of 1.0, focusing on a >>> single client type at the expense of others. OAuth 1.0 focused on the >>> web-server flow and treated everything else as second class citizens. -= 05 >>> treated native applications similarly, giving much more attentions to t= he >>> web-server and user-agent clients, even when their underlying flows cou= ld >>> have been written primarily for some native applications. The issue is >>> mostly in naming the profiles after one typical client type instead of = their >>> key property. >>> >>> Options >>> >>> I came up with two options for finalizing the specification=92s structu= re >>> (please feel to suggest additional ideas): >>> >>> >>> 1. Keep the document=92s endpoint-based organization (-11) and ad= d a >>> Client Profiles section describing specific client implementations base= d on >>> the protocol. These profiles will not include wire information (paramet= ers, >>> values, etc.), but will include security-minded normative language (MUS= T >>> register, SHOULD match redirection URI, etc.). >>> >>> 2. Switch back to flow-based organization and include 5 flows in = 2 >>> groups (note the new names), plus extensions: >>> >>> a. Redirection-based >>> >>> i. >>> Authenticated client (web server) >>> >>> ii. >>> Unauthenticated client (user-agent) >>> >>> iii. Mi= x >>> authentication client (code-and-token) >>> >>> b. Direct Credentials >>> >>> i. >>> Username and password >>> >>> ii. >>> Client credentials >>> >>> c. Extensions >>> >>> Option 1 >>> >>> - Easier for server developers because it will include all the >>> wire-protocol details for each endpoint in one place (single list of >>> parameters, error codes, etc.). >>> >>> - Shorter, no repeating the same examples, parameters, and err= or >>> definitions for each flow. >>> >>> - Reads like a reference. >>> >>> - Client developers are instructed which parameter values to >>> use. >>> >>> - Server developer focus helps make security-based decisions >>> (which are primarily the role of the server developer in OAuth). >>> >>> Option 2 >>> >>> - Easier for client developers focused on one flow at a time. >>> >>> - Longer, duplicating examples, parameters, and error >>> definitions. Currently about 20-30 more pages. >>> >>> - Reads like a narrative / tutorial. >>> >>> - Client developers are instructed which client flow to use. >>> >>> - Client developer focus helps novice developers interoperate >>> with protected resources. >>> >>> I don=92t believe there is an obvious winner here because we each have = a >>> bias based on who we believe is the primary target audience (after all,= this >>> is a purely editorial decision =96 the protocol itself is mostly comple= te). In >>> addition, I have done 80% of the work to get -12 to option 2 so it is n= o >>> longer about investing the time in the transition. >>> >>> Vote >>> >>> Given the stable state of the specification, this might be the last big >>> decision we get to make about the main specification. I=92ve been plann= ing to >>> just come up with a new draft and ask for feedback but I rather take an= other >>> week and ask this explicitly. >>> >>> Which option do you prefer (or suggest another)? >>> >>> Please reply with your preference by 1/17. >>> >>> 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 > --20cf3054a619dc4c0d049a026441 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess I'm in the minority but I prefer option #1.=A0

I do agr= ee with others that naming with respect to authenticated vs. unauthenticate= d clients is likely problematic.

On Wed, = Jan 12, 2011 at 2:06 PM, Torsten Lodderstedt <torsten@lodderstedt.net> = wrote:
+1 for option 2 b= ecause it will facilitates security analysis of the protocol.

>From a security analysis perspective, I think we need two views:
1) A structural view, describing the OAuth architecture (entities, interfac= es, communication paths) and
2) a flow-oriented view, which is built based on this interfaces, this is w= here the more complex threats show up. For example, the session fixation at= tack makes use of properties of the flow along both OAuth end-points.

I assume a structural view will given as well?

I agree with Marius regarding naming. I don't believe we can forsee tod= ay which clients will be authenticated in the future and which not. I could= imagine deployments with support for web applications w/o authentication. = It depends on the security policy and the value someone sees in client auth= entication (for the purpose of client authorization). On the other hand, by= using dynamically created client_ids and secrets, even native apps could a= uthenticate to the authorization server.

regards,
Torsten.

Am 12.01.2011 16:15, schrieb Richer, Justin P.:

Marius makes a good point -- we probably want to avoid using language like = that for part descriptions. I don't think "code" and "to= ken" quite get it, but I don't have a better suggestion at the mom= ent though...

=A0-- Justin
________________________________________
From: Marius Scurtescu [mscurtescu@google.com]
Sent: Wednesday, January 12, 2011 10:10 AM
To: Richer, Justin P.
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - = Vote by 1/17

+1 for option 2 as well

Not convinced that naming the main flows Authenticated and
Unauthenticated makes sense, I think it will only increase confusion.
For example, native apps are not authenticated and they would be using
the "Authenticated" flow. I think we should stick with something = along
the lines of "Code" and "Token".

Marius



On Wed, Jan 12, 2011 at 10:02 AM, Richer, Justin P.<jricher@mitre.org> =A0wrote:
+1 for option 2

I see, and have always seen, the target audience as server and client devel= opers who are likely to be working against one flow and use case at a time.= Also, I disagree that the primary role of the server developer is the secu= rity considerations. In theory, you may be right, but in practice, I think = you'll find that many are going to be more concerned with just making i= t work at all with their API/framework/server.

=A0-- Justin
________________________________________
From: oauth-bou= nces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav [eran@hueniverse.com]
Sent: Wednesday, January 12, 2011 2:19 AM
To: OAuth WG
Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote= =A0 =A0 by 1/17

(Vote at the end, please read)

Background

Between draft -00 and -05 the document used a flow-based organization. This= was changed to an endpoint-based organization in draft -06. I have receive= d requests to go back to the flow-based organization, and with -12, have be= en planning to do that. It is important to note that -12 is not meant to in= clude any change in normative language and that -11 code would remain uncha= nged under -12. This is purely editorial.

Part of that effort included reviewing the various flows in -05. The flow c= ategories and definitions have always been a source of confusion. Some targ= et specific client architecture (user-agent, web server, device), some are = abstractions for future extensibility (assertion), =A0and some are useful f= eatures that can apply to a wide range of clients (client credentials, user= name and password). We also have the odd anti-profile of the native applica= tion flow, which in practice is a half-baked guide to navigating the entire= range of flows.

In practice we have a few ways to get an access token which can be categori= zed in multiple ways:


1. =A0 =A0 =A0 How authorization is obtained?

a. =A0 =A0 =A0 Redirection-based =96 user-agent, web-server

b. =A0 =A0 =A0Direct credentials =96 client credentials, username and passw= ord, assertion

2. =A0 =A0 =A0 Is the client authenticated?

a. =A0 =A0 =A0 Yes =96 web-server, client credentials, username and passwor= d, assertion (based on type)

b. =A0 =A0 =A0No =96 user-agent, assertion (based on type)

In the past we had another (broken) organization of User delegation, User c= redentials, and Autonomous.

Analysis

After studying the document and breaking it apart (in my editor) I came to = a few conclusions (which you are invited to disprove):


1. =A0 =A0 =A0 Flow names must be consistent and based on the key different= iator of each flow. I believe the ability of the client to authenticate is = the most significant aspect of each flow. I agree that ease of deployment a= nd performance are important, but this is a security protocol and the secur= ity considerations should be the primary attribute used to select flows.
2. =A0 =A0 =A0 The endpoint-based organization turned a few discrete flows = into a single protocol. This protocol should be profiled based on some key = client characteristics (such as redirection and ability of the client to au= thenticate). The main objective of the profiles would be to provide a secur= ity-focused description.

3. =A0 =A0 =A0 The hybrid flow, combining the user-agent and web-server int= o a code-and-token solution is a distinct profile with its own unique secur= ity properties. While its implementation details are important for efficien= cy, the main differentiator is the client dual nature of being able to main= tain secret credentials in some parts, but not in others. It produces two a= ccess tokens using a single authorization and client identifier.

4. =A0 =A0 =A0 The document must not repeat the mistake of 1.0, focusing on= a single client type at the expense of others. OAuth 1.0 focused on the we= b-server flow and treated everything else as second class citizens. -05 tre= ated native applications similarly, giving much more attentions to the web-= server and user-agent clients, even when their underlying flows could have = been written primarily for some native applications. The issue is mostly in= naming the profiles after one typical client type instead of their key pro= perty.

Options

I came up with two options for finalizing the specification=92s structure (= please feel to suggest additional ideas):


1. =A0 =A0 =A0 Keep the document=92s endpoint-based organization (-11) and = add a Client Profiles section describing specific client implementations ba= sed on the protocol. These profiles will not include wire information (para= meters, values, etc.), but will include security-minded normative language = (MUST register, SHOULD match redirection URI, etc.).

2. =A0 =A0 =A0 Switch back to flow-based organization and include 5 flows i= n 2 groups (note the new names), plus extensions:

a. =A0 =A0 =A0 Redirection-based

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i. =A0 =A0 =A0Authentic= ated client (web server)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ii. =A0 =A0 =A0Unauthentica= ted client (user-agent)

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0iii. =A0 =A0 =A0Mix authenti= cation client (code-and-token)

b. =A0 =A0 =A0Direct Credentials

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 i. =A0 =A0 =A0Username = and password

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ii. =A0 =A0 =A0Client crede= ntials

c. =A0 =A0 =A0 Extensions

Option 1

- =A0 =A0 =A0 =A0 =A0Easier for server developers because it will include a= ll the wire-protocol details for each endpoint in one place (single list of= parameters, error codes, etc.).

- =A0 =A0 =A0 =A0 =A0Shorter, no repeating the same examples, parameters, a= nd error definitions for each flow.

- =A0 =A0 =A0 =A0 =A0Reads like a reference.

- =A0 =A0 =A0 =A0 =A0Client developers are instructed which parameter value= s to use.

- =A0 =A0 =A0 =A0 =A0Server developer focus helps make security-based decis= ions (which are primarily the role of the server developer in OAuth).

Option 2

- =A0 =A0 =A0 =A0 =A0Easier for client developers focused on one flow at a = time.

- =A0 =A0 =A0 =A0 =A0Longer, duplicating examples, parameters, and error de= finitions. Currently about 20-30 more pages.

- =A0 =A0 =A0 =A0 =A0Reads like a narrative / tutorial.

- =A0 =A0 =A0 =A0 =A0Client developers are instructed which client flow to = use.

- =A0 =A0 =A0 =A0 =A0Client developer focus helps novice developers interop= erate with protected resources.

I don=92t believe there is an obvious winner here because we each have a bi= as based on who we believe is the primary target audience (after all, this = is a purely editorial decision =96 the protocol itself is mostly complete).= In addition, I have done 80% of the work to get -12 to option 2 so it is n= o longer about investing the time in the transition.

Vote

Given the stable state of the specification, this might be the last big dec= ision we get to make about the main specification. I=92ve been planning to = just come up with a new draft and ask for feedback but I rather take anothe= r week and ask this explicitly.

Which option do you prefer (or suggest another)?

Please reply with your preference by 1/17.

EHL







_______________________________________________
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

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

--20cf3054a619dc4c0d049a026441-- From fcorella@pomcor.com Sun Jan 16 23:28:40 2011 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 809FA3A6E84 for ; Sun, 16 Jan 2011 23:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.319, 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 vhDmJLAszKWy for ; Sun, 16 Jan 2011 23:28:39 -0800 (PST) Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by core3.amsl.com (Postfix) with SMTP id ADB533A6E83 for ; Sun, 16 Jan 2011 23:28:38 -0800 (PST) Received: from [98.139.52.188] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 17 Jan 2011 07:31:09 -0000 Received: from [98.139.52.175] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 17 Jan 2011 07:31:09 -0000 Received: from [127.0.0.1] by omp1058.mail.ac4.yahoo.com with NNFMP; 17 Jan 2011 07:31:09 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 320490.87320.bm@omp1058.mail.ac4.yahoo.com Received: (qmail 20645 invoked by uid 60001); 17 Jan 2011 07:31:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295249469; bh=0taSQBn5xiPNxUKsNeh/poH3vzVNwkn88kXfZqBBwgs=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AVw/zed0eLoKeAKsOZWCjAFOKqigvUsknUipfYfLnyrH//M2Q5umY7OnRYeDbyIPPSqpYfV6yashTox4nahVRHWE5Qu/opQ7seJgJcm+sarGxSvnY7WN8PWyorIiolpay0jmkz6A7qeNbw/Qasx2quQ7dcPkC2ht1T4IfOOl14k= Message-ID: <96513.20589.qm@web55801.mail.re3.yahoo.com> X-YMail-OSG: AL99WiEVM1kFKKQXvXBAAEmJjdQoa1AgA3muGlQvuanZT7p d6CgNYYihFapybq7KEQK4uAndcIN8JxnvrA4KEgMuUuyNRD_4jwnzkNRYH7A os_GQBgC2zOhwyI1oo7MSvhhu_9FPqIjihFhMhdzOuQL2Hw9v8G7sS7eGy47 LJbhvmPcKwYZNO9HgrnFDaXtmFDOXPLa95K3SfJqutfwXmDtXErFVVOr90jP whRvceBhaVZ1q1d1qKxPK9PiYfHJL3EAu6B4Qsjmv_mW7gE7jx5NfAQQkmQ1 jDPIb4s3wGtTmKl_KoYzcX06a6BS1zPEjqoEAGd7A6cqqycvutBgOeQZhknd BBCjkdcTYJwDotkI4Z2S_34YCqJ20NQepa_00Unc_IW_4AjtdcTcGndrKOG2 iv2koVR7UmW4- Received: from [174.65.103.16] by web55801.mail.re3.yahoo.com via HTTP; Sun, 16 Jan 2011 23:31:08 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Sun, 16 Jan 2011 23:31:08 -0800 (PST) From: Francisco Corella To: Eran Hammer-Lahav , David Recordon In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-939087779-1295249468=:20589" Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 07:28:40 -0000 --0-939087779-1295249468=:20589 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I wanted to point out that an assertion by itself cannot authenticate the client, contrary to what the draft seems to imply. Section 3.2 of the spec says that, when using a client assertion, the client sends two parameters: client_assertion_type and client_assertion.=C2=A0 This does not work.=C2=A0 A client assertion will typically bind a public key to some information about the client.=C2=A0 Sending the assertion will not by itself authenticate the client.=C2=A0 The client must also demonstrate that it owns the corresponding private key. To look at it from a different angle, section 3.2 also says: > The assertion format, the process by which the assertion is > obtained, and the method of validating the assertion are > defined by the assertion issuer and the authorization > server, and are beyond the scope of this specification. This misses an essential element of an assertion, what the SAML spec calls "subject confirmation" (section 2.4.1.1). Subject confirmation is not a private matter between the assertion and the authorization server, it must also involve the client, and hence it must be an integral part of the protocol. Another thing that's wrong is that the client assertion is obtained too late in the protocol flow.=C2=A0 An assertion can provide information that the server can use to identify the client application to the user as it authenticates the user and asks for permission to grant the client application's request.=C2=A0 But that has already been done by the time the server obtains the assertion. On the other hand I like assertions because they could help identify unregistered applications, which is what I'm trying to achieve with my PKAuth protocol.=C2=A0 So I'm thinking about adding them to PKAuth.=C2=A0 That should be easy, because in PKAuth the client authenticates itself by presenting its TLS certificate and demonstrating knowledge of the corresponding private key in a TLS handshake.=C2=A0 An assertion can then simply bind additional information to the certificate, and "subject confirmation" is already taken care of. Francisco --- On Sun, 1/16/11, David Recordon wrote: From: David Recordon Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials To: "Eran Hammer-Lahav" Cc: "OAuth WG" Date: Sunday, January 16, 2011, 8:36 PM Seems good enough to me. +1 to removing it so that it will become fully fle= shed out in a useful manner. On Sat, Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav w= rote: =0AYou still need to define it. The two parameters don=E2=80=99t accomplish= anything since you can=E2=80=99t use them without a more detailed specific= ation, in which case, what is the value of this? Where is the interoperabil= ity gain?=0A=C2=A0This is clearly not a feature that is likely to be implem= ented in any general purpose library, unlike the =E2=80=98scope=E2=80=99 pa= rameter which is under-defined but still useful for library support.=0A=C2= =A0Including it in the specification is confusing (the unanimous feedback I= received so far), without any benefit. The specification provides a clear = extension mechanism for new parameters. Why is that not enough?=0A=C2=A0EHL= =C2=A0=0AFrom: Phillip Hunt [mailto:phil.hunt@Oracle.com]=20 =0ASent: Saturday, January 15, 2011 12:52 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials=0A=C2=A0A str= ong client credential is needed in many cases. I had assumed client asserti= on would fulfill this need.=C2=A0 Phil=0A=C2=A0Sent from my phone.=C2=A0 On 2011-01-14, at 22:45, Eran Hammer-Lahav wrote:=0AI= would like to suggest we drop the client assertion credentials (-11 sectio= n 3.2) from the specification, and if needed, publish it as a separate spec= ification for the following reasons:=0A=C2=A01.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 The mechanism is under specified, especially in its handling of t= he client_id identifier (when used to obtain end-user authorization). It do= es not contain any implementation details to accomplish any level of intero= perability or functionality. This is in contrast to the assertion grant typ= e which has matured over a year into a fully thought-out extension mechanis= m, as well as a separate SAML assertion specification with active deploymen= t (the two, together with running code, show clear consensus).=0A2.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The section is a confused mix of security co= nsiderations sprinkled with normative language. Instead, it should be repla= ced with guidelines for extending the set of supported client credentials, = but without defining a new registry. It is clearly an area of little deploy= ment experience for OAuth, and that includes using HTTP Basic authenticatio= n for client authentication (more on that to come).=0A3.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 The section has received a little support and a little o= bjection. Those who still want to advocate for it need to show not only con= sensus for keeping it, but also active community support for deploying it. = Deployment, of course, will also require showing progress on public specifi= cations profiling the mechanism into a useful interoperable feature.=0A=C2= =A0Comments? Counter-arguments?=C2=A0EHL=C2=A0=C2=A0=0A____________________= ___________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth=0A _______________________________________________ =0AOAuth mailing list =0AOAuth@ietf.org =0Ahttps://www.ietf.org/mailman/listinfo/oauth =0A =0A -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0-939087779-1295249468=:20589 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I wanted to point out that an assertion by it= self cannot
authenticate the client, contrary to what the draft seems to=
imply.

Section 3.2 of the spec says that, when using a clientassertion, the client sends two parameters:
client_assertion_type and c= lient_assertion.  This does not
work.  A client assertion will= typically bind a public key
to some information about the client. = Sending the assertion
will not by itself authenticate the client. = The client must
also demonstrate that it owns the corresponding private= key.

To look at it from a different angle, section 3.2 also says:
> The assertion format, the process by which the assertion is
&= gt; obtained, and the method of validating the assertion are
> define= d by the assertion issuer and the authorization
> server, and are bey= ond the scope of this specification.

This misses an essential element o= f an assertion, what the
SAML spec calls "subject confirmation" (section= 2.4.1.1).
Subject confirmation is not a private matter between the
a= ssertion and the authorization server, it must also involve
the client, = and hence it must be an integral part of the
protocol.

Another th= ing that's wrong is that the client assertion is
obtained too late in th= e protocol flow.  An assertion can
provide information that the ser= ver can use to identify the
client application to the user as it authent= icates the user
and asks for permission to grant the client application'= s
request.  But that has already been done by the time the
serve= r obtains the assertion.

On the other hand I like assertions because= they could
help identify unregistered applications, which is what I'mtrying to achieve with my PKAuth protocol.  So I'm thinking
about adding them to PKAuth.  That should be easy, becaus= e
in PKAuth the client authenticates itself by presenting its
TLS cer= tificate and demonstrating knowledge of the
corresponding private key in= a TLS handshake.  An assertion
can then simply bind additional inf= ormation to the
certificate, and "subject confirmation" is already taken=
care of.

Francisco

--- On Sun, 1/16/11, David Recordon= <recordond@gmail.com> wrote:
=
From: David Recordon <recordond@gmail.com>
Subject: Re: [OAUTH= -WG] Removal: Client Assertion Credentials
To: "Eran Hammer-Lahav" <e= ran@hueniverse.com>
Cc: "OAuth WG" <oauth@ietf.org>
Date: Su= nday, January 16, 2011, 8:36 PM

Seems good= enough to me. +1 to removing it so that it will become fully fleshed out in a useful manner.


On Sat, Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav <= ;eran@hueniverse.com>= ; wrote:
=0A

You still ne= ed to define it. The two parameters don=E2=80=99t accomplish anything since= you can=E2=80=99t use them without a more detailed specification, in which= case, what is the value of this? Where is the interoperability gain?

=0A

 

This is clea= rly not a feature that is likely to be implemented in any general purpose l= ibrary, unlike the =E2=80=98scope=E2=80=99 parameter which is under-defined= but still useful for library support.

=0A

&nbs= p;

Including it in the specification is confus= ing (the unanimous feedback I received so far), without any benefit. The sp= ecification provides a clear extension mechanism for new parameters. Why is= that not enough?

=0A

 

EHL

 

=0A

From: Phillip= Hunt [mailto:phil.hunt@O= racle.com]
=0ASent: Saturday, January 15, 2011 12:52 AM
<= b>To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [= OAUTH-WG] Removal: Client Assertion Credentials

=
=0A

 

A strong clie= nt credential is needed in many cases. I had assumed client assertion would= fulfill this need. 


Phil

=0A 

Sent from my phone. 

<= /div>

eran@hueniverse.com> wrote:

=0A

I would like to suggest we drop the client asse= rtion credentials (-11 section 3.2) from the specification, and if needed, = publish it as a separate specification for the following reasons:

=0A

 

1.       The mechanism is under spe= cified, especially in its handling of the client_id identifier (when used t= o obtain end-user authorization). It does not contain any implementation de= tails to accomplish any level of interoperability or functionality. This is= in contrast to the assertion grant type which has matured over a year into= a fully thought-out extension mechanism, as well as a separate SAML assert= ion specification with active deployment (the two, together with running co= de, show clear consensus).

=0A

2. = ;      The section is a confused mix of sec= urity considerations sprinkled with normative language. Instead, it should = be replaced with guidelines for extending the set of supported client crede= ntials, but without defining a new registry. It is clearly an area of littl= e deployment experience for OAuth, and that includes using HTTP Basic authe= ntication for client authentication (more on that to come).

=0A

3.       The= section has received a little support and a little objection. Those who st= ill want to advocate for it need to show not only consensus for keeping it,= but also active community support for deploying it. Deployment, of course,= will also require showing progress on public specifications profiling the = mechanism into a useful interoperable feature.

=0A

 

Comments? Count= er-arguments?

 

EHL

 

 

=0A

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


__________= _____________________________________
=0AOAuth mailing list
=0AOAuth@ietf.org
=0Aht= tps://www.ietf.org/mailman/listinfo/oauth
=0A
=
=0A
-----Inline Attachment Follows-----

_______________________________________________
OAuth ma= iling list
OAuth@ietf.org
https://www.ietf.org/mailman/listin= fo/oauth
--0-939087779-1295249468=:20589-- From eran@hueniverse.com Mon Jan 17 00:03:49 2011 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 E92913A6EA0 for ; Mon, 17 Jan 2011 00:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.051, 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 WyEboFv2tJJV for ; Mon, 17 Jan 2011 00:03:48 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 239DD3A6EA1 for ; Mon, 17 Jan 2011 00:03:47 -0800 (PST) Received: (qmail 30605 invoked from network); 17 Jan 2011 08:06:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Jan 2011 08:06:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 17 Jan 2011 01:06:20 -0700 From: Eran Hammer-Lahav To: "fcorella@pomcor.com" , David Recordon Date: Mon, 17 Jan 2011 01:06:17 -0700 Thread-Topic: [OAUTH-WG] Removal: Client Assertion Credentials Thread-Index: Acu2GIRXH6QcSD8kTlSQRBHQ69R4+wABNYtg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FFF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <96513.20589.qm@web55801.mail.re3.yahoo.com> In-Reply-To: <96513.20589.qm@web55801.mail.re3.yahoo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FFFP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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: Mon, 17 Jan 2011 08:03:50 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FFFP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T25lIG1vcmUgcmVhc29uIHRvIHJlbW92ZSB0aGUgaGFsZi1iYWtlZCB0ZXh0IGZyb20gdGhlIHNw ZWMgYW5kIHJlaW50cm9kdWNlIGl0IHdpdGggYSBmdWxsIHNwZWNpZmljYXRpb24gZWxzZXdoZXJl Lg0KDQpFSEwNCg0KRnJvbTogRnJhbmNpc2NvIENvcmVsbGEgW21haWx0bzpmY29yZWxsYUBwb21j b3IuY29tXQ0KU2VudDogU3VuZGF5LCBKYW51YXJ5IDE2LCAyMDExIDExOjMxIFBNDQpUbzogRXJh biBIYW1tZXItTGFoYXY7IERhdmlkIFJlY29yZG9uDQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJl OiBbT0FVVEgtV0ddIFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMNCg0KSSB3 YW50ZWQgdG8gcG9pbnQgb3V0IHRoYXQgYW4gYXNzZXJ0aW9uIGJ5IGl0c2VsZiBjYW5ub3QNCmF1 dGhlbnRpY2F0ZSB0aGUgY2xpZW50LCBjb250cmFyeSB0byB3aGF0IHRoZSBkcmFmdCBzZWVtcyB0 bw0KaW1wbHkuDQoNClNlY3Rpb24gMy4yIG9mIHRoZSBzcGVjIHNheXMgdGhhdCwgd2hlbiB1c2lu ZyBhIGNsaWVudA0KYXNzZXJ0aW9uLCB0aGUgY2xpZW50IHNlbmRzIHR3byBwYXJhbWV0ZXJzOg0K Y2xpZW50X2Fzc2VydGlvbl90eXBlIGFuZCBjbGllbnRfYXNzZXJ0aW9uLiAgVGhpcyBkb2VzIG5v dA0Kd29yay4gIEEgY2xpZW50IGFzc2VydGlvbiB3aWxsIHR5cGljYWxseSBiaW5kIGEgcHVibGlj IGtleQ0KdG8gc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY2xpZW50LiAgU2VuZGluZyB0aGUg YXNzZXJ0aW9uDQp3aWxsIG5vdCBieSBpdHNlbGYgYXV0aGVudGljYXRlIHRoZSBjbGllbnQuICBU aGUgY2xpZW50IG11c3QNCmFsc28gZGVtb25zdHJhdGUgdGhhdCBpdCBvd25zIHRoZSBjb3JyZXNw b25kaW5nIHByaXZhdGUga2V5Lg0KDQpUbyBsb29rIGF0IGl0IGZyb20gYSBkaWZmZXJlbnQgYW5n bGUsIHNlY3Rpb24gMy4yIGFsc28gc2F5czoNCg0KPiBUaGUgYXNzZXJ0aW9uIGZvcm1hdCwgdGhl IHByb2Nlc3MgYnkgd2hpY2ggdGhlIGFzc2VydGlvbiBpcw0KPiBvYnRhaW5lZCwgYW5kIHRoZSBt ZXRob2Qgb2YgdmFsaWRhdGluZyB0aGUgYXNzZXJ0aW9uIGFyZQ0KPiBkZWZpbmVkIGJ5IHRoZSBh c3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbg0KPiBzZXJ2ZXIsIGFuZCBhcmUg YmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClRoaXMgbWlzc2VzIGFu IGVzc2VudGlhbCBlbGVtZW50IG9mIGFuIGFzc2VydGlvbiwgd2hhdCB0aGUNClNBTUwgc3BlYyBj YWxscyAic3ViamVjdCBjb25maXJtYXRpb24iIChzZWN0aW9uIDIuNC4xLjEpLg0KU3ViamVjdCBj b25maXJtYXRpb24gaXMgbm90IGEgcHJpdmF0ZSBtYXR0ZXIgYmV0d2VlbiB0aGUNCmFzc2VydGlv biBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBpdCBtdXN0IGFsc28gaW52b2x2ZQ0KdGhl IGNsaWVudCwgYW5kIGhlbmNlIGl0IG11c3QgYmUgYW4gaW50ZWdyYWwgcGFydCBvZiB0aGUNCnBy b3RvY29sLg0KDQpBbm90aGVyIHRoaW5nIHRoYXQncyB3cm9uZyBpcyB0aGF0IHRoZSBjbGllbnQg YXNzZXJ0aW9uIGlzDQpvYnRhaW5lZCB0b28gbGF0ZSBpbiB0aGUgcHJvdG9jb2wgZmxvdy4gIEFu IGFzc2VydGlvbiBjYW4NCnByb3ZpZGUgaW5mb3JtYXRpb24gdGhhdCB0aGUgc2VydmVyIGNhbiB1 c2UgdG8gaWRlbnRpZnkgdGhlDQpjbGllbnQgYXBwbGljYXRpb24gdG8gdGhlIHVzZXIgYXMgaXQg YXV0aGVudGljYXRlcyB0aGUgdXNlcg0KYW5kIGFza3MgZm9yIHBlcm1pc3Npb24gdG8gZ3JhbnQg dGhlIGNsaWVudCBhcHBsaWNhdGlvbidzDQpyZXF1ZXN0LiAgQnV0IHRoYXQgaGFzIGFscmVhZHkg YmVlbiBkb25lIGJ5IHRoZSB0aW1lIHRoZQ0Kc2VydmVyIG9idGFpbnMgdGhlIGFzc2VydGlvbi4N Cg0KT24gdGhlIG90aGVyIGhhbmQgSSBsaWtlIGFzc2VydGlvbnMgYmVjYXVzZSB0aGV5IGNvdWxk DQpoZWxwIGlkZW50aWZ5IHVucmVnaXN0ZXJlZCBhcHBsaWNhdGlvbnMsIHdoaWNoIGlzIHdoYXQg SSdtDQp0cnlpbmcgdG8gYWNoaWV2ZSB3aXRoIG15IFBLQXV0aCBwcm90b2NvbC4gIFNvIEknbSB0 aGlua2luZw0KYWJvdXQgYWRkaW5nIHRoZW0gdG8gUEtBdXRoLiAgVGhhdCBzaG91bGQgYmUgZWFz eSwgYmVjYXVzZQ0KaW4gUEtBdXRoIHRoZSBjbGllbnQgYXV0aGVudGljYXRlcyBpdHNlbGYgYnkg cHJlc2VudGluZyBpdHMNClRMUyBjZXJ0aWZpY2F0ZSBhbmQgZGVtb25zdHJhdGluZyBrbm93bGVk Z2Ugb2YgdGhlDQpjb3JyZXNwb25kaW5nIHByaXZhdGUga2V5IGluIGEgVExTIGhhbmRzaGFrZS4g IEFuIGFzc2VydGlvbg0KY2FuIHRoZW4gc2ltcGx5IGJpbmQgYWRkaXRpb25hbCBpbmZvcm1hdGlv biB0byB0aGUNCmNlcnRpZmljYXRlLCBhbmQgInN1YmplY3QgY29uZmlybWF0aW9uIiBpcyBhbHJl YWR5IHRha2VuDQpjYXJlIG9mLg0KDQpGcmFuY2lzY28NCg0KLS0tIE9uIFN1biwgMS8xNi8xMSwg RGF2aWQgUmVjb3Jkb24gPHJlY29yZG9uZEBnbWFpbC5jb208bWFpbHRvOnJlY29yZG9uZEBnbWFp bC5jb20+PiB3cm90ZToNCg0KRnJvbTogRGF2aWQgUmVjb3Jkb24gPHJlY29yZG9uZEBnbWFpbC5j b208bWFpbHRvOnJlY29yZG9uZEBnbWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g UmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFscw0KVG86ICJFcmFuIEhhbW1lci1M YWhhdiIgPGVyYW5AaHVlbml2ZXJzZS5jb208bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20+Pg0K Q2M6ICJPQXV0aCBXRyIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQpE YXRlOiBTdW5kYXksIEphbnVhcnkgMTYsIDIwMTEsIDg6MzYgUE0NClNlZW1zIGdvb2QgZW5vdWdo IHRvIG1lLiArMSB0byByZW1vdmluZyBpdCBzbyB0aGF0IGl0IHdpbGwgYmVjb21lIGZ1bGx5IGZs ZXNoZWQgb3V0IGluIGEgdXNlZnVsIG1hbm5lci4NCg0KT24gU2F0LCBKYW4gMTUsIDIwMTEgYXQg MTE6MzIgQU0sIEVyYW4gSGFtbWVyLUxhaGF2IDxlcmFuQGh1ZW5pdmVyc2UuY29tPC9tYy9jb21w b3NlP3RvPWVyYW5AaHVlbml2ZXJzZS5jb20+PiB3cm90ZToNCg0KWW91IHN0aWxsIG5lZWQgdG8g ZGVmaW5lIGl0LiBUaGUgdHdvIHBhcmFtZXRlcnMgZG9u4oCZdCBhY2NvbXBsaXNoIGFueXRoaW5n IHNpbmNlIHlvdSBjYW7igJl0IHVzZSB0aGVtIHdpdGhvdXQgYSBtb3JlIGRldGFpbGVkIHNwZWNp ZmljYXRpb24sIGluIHdoaWNoIGNhc2UsIHdoYXQgaXMgdGhlIHZhbHVlIG9mIHRoaXM/IFdoZXJl IGlzIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGdhaW4/DQoNCg0KDQpUaGlzIGlzIGNsZWFybHkgbm90 IGEgZmVhdHVyZSB0aGF0IGlzIGxpa2VseSB0byBiZSBpbXBsZW1lbnRlZCBpbiBhbnkgZ2VuZXJh bCBwdXJwb3NlIGxpYnJhcnksIHVubGlrZSB0aGUg4oCYc2NvcGXigJkgcGFyYW1ldGVyIHdoaWNo IGlzIHVuZGVyLWRlZmluZWQgYnV0IHN0aWxsIHVzZWZ1bCBmb3IgbGlicmFyeSBzdXBwb3J0Lg0K DQoNCg0KSW5jbHVkaW5nIGl0IGluIHRoZSBzcGVjaWZpY2F0aW9uIGlzIGNvbmZ1c2luZyAodGhl IHVuYW5pbW91cyBmZWVkYmFjayBJIHJlY2VpdmVkIHNvIGZhciksIHdpdGhvdXQgYW55IGJlbmVm aXQuIFRoZSBzcGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEgY2xlYXIgZXh0ZW5zaW9uIG1lY2hhbmlz bSBmb3IgbmV3IHBhcmFtZXRlcnMuIFdoeSBpcyB0aGF0IG5vdCBlbm91Z2g/DQoNCg0KDQpFSEwN Cg0KDQoNCkZyb206IFBoaWxsaXAgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBPcmFjbGUuY29tPC9t Yy9jb21wb3NlP3RvPXBoaWwuaHVudEBPcmFjbGUuY29tPl0NClNlbnQ6IFNhdHVyZGF5LCBKYW51 YXJ5IDE1LCAyMDExIDEyOjUyIEFNDQpUbzogRXJhbiBIYW1tZXItTGFoYXYNCkNjOiBPQXV0aCBX Rw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVk ZW50aWFscw0KDQoNCg0KQSBzdHJvbmcgY2xpZW50IGNyZWRlbnRpYWwgaXMgbmVlZGVkIGluIG1h bnkgY2FzZXMuIEkgaGFkIGFzc3VtZWQgY2xpZW50IGFzc2VydGlvbiB3b3VsZCBmdWxmaWxsIHRo aXMgbmVlZC4NCg0KUGhpbA0KDQoNCg0KU2VudCBmcm9tIG15IHBob25lLg0KDQpPbiAyMDExLTAx LTE0LCBhdCAyMjo0NSwgRXJhbiBIYW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb208L21j L2NvbXBvc2U/dG89ZXJhbkBodWVuaXZlcnNlLmNvbT4+IHdyb3RlOg0KDQpJIHdvdWxkIGxpa2Ug dG8gc3VnZ2VzdCB3ZSBkcm9wIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzICgtMTEg c2VjdGlvbiAzLjIpIGZyb20gdGhlIHNwZWNpZmljYXRpb24sIGFuZCBpZiBuZWVkZWQsIHB1Ymxp c2ggaXQgYXMgYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgZm9sbG93aW5nIHJlYXNv bnM6DQoNCg0KDQoxLiAgICAgICBUaGUgbWVjaGFuaXNtIGlzIHVuZGVyIHNwZWNpZmllZCwgZXNw ZWNpYWxseSBpbiBpdHMgaGFuZGxpbmcgb2YgdGhlIGNsaWVudF9pZCBpZGVudGlmaWVyICh3aGVu IHVzZWQgdG8gb2J0YWluIGVuZC11c2VyIGF1dGhvcml6YXRpb24pLiBJdCBkb2VzIG5vdCBjb250 YWluIGFueSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRvIGFjY29tcGxpc2ggYW55IGxldmVsIG9m IGludGVyb3BlcmFiaWxpdHkgb3IgZnVuY3Rpb25hbGl0eS4gVGhpcyBpcyBpbiBjb250cmFzdCB0 byB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUgd2hpY2ggaGFzIG1hdHVyZWQgb3ZlciBhIHllYXIg aW50byBhIGZ1bGx5IHRob3VnaHQtb3V0IGV4dGVuc2lvbiBtZWNoYW5pc20sIGFzIHdlbGwgYXMg YSBzZXBhcmF0ZSBTQU1MIGFzc2VydGlvbiBzcGVjaWZpY2F0aW9uIHdpdGggYWN0aXZlIGRlcGxv eW1lbnQgKHRoZSB0d28sIHRvZ2V0aGVyIHdpdGggcnVubmluZyBjb2RlLCBzaG93IGNsZWFyIGNv bnNlbnN1cykuDQoNCjIuICAgICAgIFRoZSBzZWN0aW9uIGlzIGEgY29uZnVzZWQgbWl4IG9mIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHNwcmlua2xlZCB3aXRoIG5vcm1hdGl2ZSBsYW5ndWFnZS4g SW5zdGVhZCwgaXQgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggZ3VpZGVsaW5lcyBmb3IgZXh0ZW5k aW5nIHRoZSBzZXQgb2Ygc3VwcG9ydGVkIGNsaWVudCBjcmVkZW50aWFscywgYnV0IHdpdGhvdXQg ZGVmaW5pbmcgYSBuZXcgcmVnaXN0cnkuIEl0IGlzIGNsZWFybHkgYW4gYXJlYSBvZiBsaXR0bGUg ZGVwbG95bWVudCBleHBlcmllbmNlIGZvciBPQXV0aCwgYW5kIHRoYXQgaW5jbHVkZXMgdXNpbmcg SFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIChtb3Jl IG9uIHRoYXQgdG8gY29tZSkuDQoNCjMuICAgICAgIFRoZSBzZWN0aW9uIGhhcyByZWNlaXZlZCBh IGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3NlIHdobyBzdGlsbCB3 YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkgY29uc2Vuc3VzIGZv ciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBvcnQgZm9yIGRlcGxv eWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsIGFsc28gcmVxdWlyZSBzaG93aW5n IHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9maWxpbmcgdGhlIG1lY2hhbmlz bSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS4NCg0KDQoNCkNvbW1lbnRzPyBD b3VudGVyLWFyZ3VtZW50cz8NCg0KDQoNCkVITA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRo QGlldGYub3JnPC9tYy9jb21wb3NlP3RvPU9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y ZzwvbWMvY29tcG9zZT90bz1PQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQotLS0tLUlubGluZSBBdHRhY2htZW50IEZvbGxvd3Mt LS0tLQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8L21jL2NvbXBvc2U/dG89T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FFFP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAueWl2MTg5MjA3MjQ1Mm1zb25v cm1hbCwgbGkueWl2MTg5MjA3MjQ1Mm1zb25vcm1hbCwgZGl2LnlpdjE4OTIwNzI0NTJtc29ub3Jt YWwNCgl7bXNvLXN0eWxlLW5hbWU6eWl2MTg5MjA3MjQ1Mm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYg Y2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPk9uZSBtb3JlIHJlYXNvbiB0byByZW1vdmUgdGhlIGhhbGYtYmFrZWQgdGV4dCBmcm9tIHRo ZSBzcGVjIGFuZCByZWludHJvZHVjZSBpdCB3aXRoIGEgZnVsbCBzcGVjaWZpY2F0aW9uIGVsc2V3 aGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Jz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4g RnJhbmNpc2NvIENvcmVsbGEgW21haWx0bzpmY29yZWxsYUBwb21jb3IuY29tXSA8YnI+PGI+U2Vu dDo8L2I+IFN1bmRheSwgSmFudWFyeSAxNiwgMjAxMSAxMTozMSBQTTxicj48Yj5Ubzo8L2I+IEVy YW4gSGFtbWVyLUxhaGF2OyBEYXZpZCBSZWNvcmRvbjxicj48Yj5DYzo8L2I+IE9BdXRoIFdHPGJy PjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9u IENyZWRlbnRpYWxzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUg Ym9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wPjx0cj48dGQgdmFsaWduPXRvcCBz dHlsZT0ncGFkZGluZzowaW4gMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD5JIHdhbnRl ZCB0byBwb2ludCBvdXQgdGhhdCBhbiBhc3NlcnRpb24gYnkgaXRzZWxmIGNhbm5vdDxicj5hdXRo ZW50aWNhdGUgdGhlIGNsaWVudCwgY29udHJhcnkgdG8gd2hhdCB0aGUgZHJhZnQgc2VlbXMgdG88 YnI+aW1wbHkuPGJyPjxicj5TZWN0aW9uIDMuMiBvZiB0aGUgc3BlYyBzYXlzIHRoYXQsIHdoZW4g dXNpbmcgYSBjbGllbnQ8YnI+YXNzZXJ0aW9uLCB0aGUgY2xpZW50IHNlbmRzIHR3byBwYXJhbWV0 ZXJzOjxicj5jbGllbnRfYXNzZXJ0aW9uX3R5cGUgYW5kIGNsaWVudF9hc3NlcnRpb24uJm5ic3A7 IFRoaXMgZG9lcyBub3Q8YnI+d29yay4mbmJzcDsgQSBjbGllbnQgYXNzZXJ0aW9uIHdpbGwgdHlw aWNhbGx5IGJpbmQgYSBwdWJsaWMga2V5PGJyPnRvIHNvbWUgaW5mb3JtYXRpb24gYWJvdXQgdGhl IGNsaWVudC4mbmJzcDsgU2VuZGluZyB0aGUgYXNzZXJ0aW9uPGJyPndpbGwgbm90IGJ5IGl0c2Vs ZiBhdXRoZW50aWNhdGUgdGhlIGNsaWVudC4mbmJzcDsgVGhlIGNsaWVudCBtdXN0PGJyPmFsc28g ZGVtb25zdHJhdGUgdGhhdCBpdCBvd25zIHRoZSBjb3JyZXNwb25kaW5nIHByaXZhdGUga2V5Ljxi cj48YnI+VG8gbG9vayBhdCBpdCBmcm9tIGEgZGlmZmVyZW50IGFuZ2xlLCBzZWN0aW9uIDMuMiBh bHNvIHNheXM6PGJyPjxicj4mZ3Q7IFRoZSBhc3NlcnRpb24gZm9ybWF0LCB0aGUgcHJvY2VzcyBi eSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlzPGJyPiZndDsgb2J0YWluZWQsIGFuZCB0aGUgbWV0aG9k IG9mIHZhbGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmU8YnI+Jmd0OyBkZWZpbmVkIGJ5IHRoZSBh c3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbjxicj4mZ3Q7IHNlcnZlciwgYW5k IGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48YnI+PGJyPlRoaXMg bWlzc2VzIGFuIGVzc2VudGlhbCBlbGVtZW50IG9mIGFuIGFzc2VydGlvbiwgd2hhdCB0aGU8YnI+ U0FNTCBzcGVjIGNhbGxzICZxdW90O3N1YmplY3QgY29uZmlybWF0aW9uJnF1b3Q7IChzZWN0aW9u IDIuNC4xLjEpLjxicj5TdWJqZWN0IGNvbmZpcm1hdGlvbiBpcyBub3QgYSBwcml2YXRlIG1hdHRl ciBiZXR3ZWVuIHRoZTxicj5hc3NlcnRpb24gYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwg aXQgbXVzdCBhbHNvIGludm9sdmU8YnI+dGhlIGNsaWVudCwgYW5kIGhlbmNlIGl0IG11c3QgYmUg YW4gaW50ZWdyYWwgcGFydCBvZiB0aGU8YnI+cHJvdG9jb2wuPGJyPjxicj5Bbm90aGVyIHRoaW5n IHRoYXQncyB3cm9uZyBpcyB0aGF0IHRoZSBjbGllbnQgYXNzZXJ0aW9uIGlzPGJyPm9idGFpbmVk IHRvbyBsYXRlIGluIHRoZSBwcm90b2NvbCBmbG93LiZuYnNwOyBBbiBhc3NlcnRpb24gY2FuPGJy PnByb3ZpZGUgaW5mb3JtYXRpb24gdGhhdCB0aGUgc2VydmVyIGNhbiB1c2UgdG8gaWRlbnRpZnkg dGhlPGJyPmNsaWVudCBhcHBsaWNhdGlvbiB0byB0aGUgdXNlciBhcyBpdCBhdXRoZW50aWNhdGVz IHRoZSB1c2VyPGJyPmFuZCBhc2tzIGZvciBwZXJtaXNzaW9uIHRvIGdyYW50IHRoZSBjbGllbnQg YXBwbGljYXRpb24nczxicj5yZXF1ZXN0LiZuYnNwOyBCdXQgdGhhdCBoYXMgYWxyZWFkeSBiZWVu IGRvbmUgYnkgdGhlIHRpbWUgdGhlPGJyPnNlcnZlciBvYnRhaW5zIHRoZSBhc3NlcnRpb24uPGJy Pjxicj5PbiB0aGUgb3RoZXIgaGFuZCBJIGxpa2UgYXNzZXJ0aW9ucyBiZWNhdXNlIHRoZXkgY291 bGQ8YnI+aGVscCBpZGVudGlmeSB1bnJlZ2lzdGVyZWQgYXBwbGljYXRpb25zLCB3aGljaCBpcyB3 aGF0IEknbTxicj50cnlpbmcgdG8gYWNoaWV2ZSB3aXRoIG15IFBLQXV0aCBwcm90b2NvbC4mbmJz cDsgU28gSSdtIHRoaW5raW5nPGJyPmFib3V0IGFkZGluZyB0aGVtIHRvIFBLQXV0aC4mbmJzcDsg VGhhdCBzaG91bGQgYmUgZWFzeSwgYmVjYXVzZTxicj5pbiBQS0F1dGggdGhlIGNsaWVudCBhdXRo ZW50aWNhdGVzIGl0c2VsZiBieSBwcmVzZW50aW5nIGl0czxicj5UTFMgY2VydGlmaWNhdGUgYW5k IGRlbW9uc3RyYXRpbmcga25vd2xlZGdlIG9mIHRoZTxicj5jb3JyZXNwb25kaW5nIHByaXZhdGUg a2V5IGluIGEgVExTIGhhbmRzaGFrZS4mbmJzcDsgQW4gYXNzZXJ0aW9uPGJyPmNhbiB0aGVuIHNp bXBseSBiaW5kIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gdGhlPGJyPmNlcnRpZmljYXRlLCBh bmQgJnF1b3Q7c3ViamVjdCBjb25maXJtYXRpb24mcXVvdDsgaXMgYWxyZWFkeSB0YWtlbjxicj5j YXJlIG9mLjxicj48YnI+RnJhbmNpc2NvPGJyPjxicj4tLS0gT24gPGI+U3VuLCAxLzE2LzExLCBE YXZpZCBSZWNvcmRvbiA8aT4mbHQ7PGEgaHJlZj0ibWFpbHRvOnJlY29yZG9uZEBnbWFpbC5jb20i PnJlY29yZG9uZEBnbWFpbC5jb208L2E+Jmd0OzwvaT48L2I+IHdyb3RlOjxvOnA+PC9vOnA+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5Gcm9t OiBEYXZpZCBSZWNvcmRvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJlY29yZG9uZEBnbWFpbC5jb20i PnJlY29yZG9uZEBnbWFpbC5jb208L2E+Jmd0Ozxicj5TdWJqZWN0OiBSZTogW09BVVRILVdHXSBS ZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPGJyPlRvOiAmcXVvdDtFcmFuIEhh bW1lci1MYWhhdiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb20i PmVyYW5AaHVlbml2ZXJzZS5jb208L2E+Jmd0Ozxicj5DYzogJnF1b3Q7T0F1dGggV0cmcXVvdDsg Jmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj5EYXRlOiBTdW5kYXksIEphbnVhcnkgMTYsIDIwMTEsIDg6MzYgUE08bzpwPjwvbzpwPjwv cD48ZGl2IGlkPXlpdjE4OTIwNzI0NTI+PHAgY2xhc3M9TXNvTm9ybWFsPlNlZW1zIGdvb2QgZW5v dWdoIHRvIG1lLiArMSB0byByZW1vdmluZyBpdCBzbyB0aGF0IGl0IHdpbGwgYmVjb21lIGZ1bGx5 IGZsZXNoZWQgb3V0IGluIGEgdXNlZnVsIG1hbm5lci48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFNhdCwgSmFuIDE1LCAyMDExIGF0IDEx OjMyIEFNLCBFcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEgaHJlZj0iL21jL2NvbXBvc2U/dG89ZXJh bkBodWVuaXZlcnNlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVyYW5AaHVlbml2ZXJzZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9eWl2MTg5MjA3MjQ1 Mm1zb25vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz5Z b3Ugc3RpbGwgbmVlZCB0byBkZWZpbmUgaXQuIFRoZSB0d28gcGFyYW1ldGVycyBkb27igJl0IGFj Y29tcGxpc2ggYW55dGhpbmcgc2luY2UgeW91IGNhbuKAmXQgdXNlIHRoZW0gd2l0aG91dCBhIG1v cmUgZGV0YWlsZWQgc3BlY2lmaWNhdGlvbiwgaW4gd2hpY2ggY2FzZSwgd2hhdCBpcyB0aGUgdmFs dWUgb2YgdGhpcz8gV2hlcmUgaXMgdGhlIGludGVyb3BlcmFiaWxpdHkgZ2Fpbj88L3NwYW4+PG86 cD48L286cD48L3A+PHAgY2xhc3M9eWl2MTg5MjA3MjQ1Mm1zb25vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+PHAgY2xhc3M9eWl2MTg5MjA3MjQ1Mm1zb25vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtjb2xvcjojMUY0OTdEJz5UaGlzIGlzIGNsZWFybHkgbm90IGEgZmVhdHVyZSB0aGF0 IGlzIGxpa2VseSB0byBiZSBpbXBsZW1lbnRlZCBpbiBhbnkgZ2VuZXJhbCBwdXJwb3NlIGxpYnJh cnksIHVubGlrZSB0aGUg4oCYc2NvcGXigJkgcGFyYW1ldGVyIHdoaWNoIGlzIHVuZGVyLWRlZmlu ZWQgYnV0IHN0aWxsIHVzZWZ1bCBmb3IgbGlicmFyeSBzdXBwb3J0Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2NvbG9yOiMxRjQ5N0QnPkluY2x1ZGluZyBpdCBpbiB0aGUgc3BlY2lmaWNhdGlvbiBpcyBjb25m dXNpbmcgKHRoZSB1bmFuaW1vdXMgZmVlZGJhY2sgSSByZWNlaXZlZCBzbyBmYXIpLCB3aXRob3V0 IGFueSBiZW5lZml0LiBUaGUgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIGNsZWFyIGV4dGVuc2lv biBtZWNoYW5pc20gZm9yIG5ldyBwYXJhbWV0ZXJzLiBXaHkgaXMgdGhhdCBub3QgZW5vdWdoPzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QnPkVITDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuNXB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNC4wcHQ7Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11 c2UtdGV4dC1jb2xvciAtbW96LXVzZS10ZXh0LWNvbG9yIGJsdWUnPjxkaXY+PGRpdiBzdHlsZT0n Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOi1tb3otdXNlLXRleHQtY29sb3IgLW1vei11c2Ut dGV4dC1jb2xvcic+PHAgY2xhc3M9eWl2MTg5MjA3MjQ1Mm1zb25vcm1hbD48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Jz4gUGhpbGxpcCBIdW50IFttYWlsdG86PGEgaHJlZj0iL21jL2NvbXBvc2U/dG89 cGhpbC5odW50QE9yYWNsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5waGlsLmh1bnRAT3JhY2xlLmNv bTwvYT5dIDxicj48Yj5TZW50OjwvYj4gU2F0dXJkYXksIEphbnVhcnkgMTUsIDIwMTEgMTI6NTIg QU08YnI+PGI+VG86PC9iPiBFcmFuIEhhbW1lci1MYWhhdjxicj48Yj5DYzo8L2I+IE9BdXRoIFdH PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0 aW9uIENyZWRlbnRpYWxzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRp dj48cCBjbGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxk aXY+PGRpdj48cCBjbGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPkEgc3Ryb25nIGNsaWVudCBj cmVkZW50aWFsIGlzIG5lZWRlZCBpbiBtYW55IGNhc2VzLiBJIGhhZCBhc3N1bWVkIGNsaWVudCBh c3NlcnRpb24gd291bGQgZnVsZmlsbCB0aGlzIG5lZWQuJm5ic3A7PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPjxicj5QaGlsPG86cD48L286 cD48L3A+PGRpdj48cCBjbGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPiZuYnNwOzxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9eWl2MTg5MjA3MjQ1Mm1zb25vcm1hbD5TZW50IGZy b20gbXkgcGhvbmUuJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFz cz15aXYxODkyMDcyNDUybXNvbm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGJy Pk9uIDIwMTEtMDEtMTQsIGF0IDIyOjQ1LCBFcmFuIEhhbW1lci1MYWhhdiAmbHQ7PGEgaHJlZj0i L21jL2NvbXBvc2U/dG89ZXJhbkBodWVuaXZlcnNlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVyYW5A aHVlbml2ZXJzZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2tx dW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz48ZGl2Pjxk aXY+PHAgY2xhc3M9eWl2MTg5MjA3MjQ1Mm1zb25vcm1hbD5JIHdvdWxkIGxpa2UgdG8gc3VnZ2Vz dCB3ZSBkcm9wIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzICgtMTEgc2VjdGlvbiAz LjIpIGZyb20gdGhlIHNwZWNpZmljYXRpb24sIGFuZCBpZiBuZWVkZWQsIHB1Ymxpc2ggaXQgYXMg YSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6PG86cD48 L286cD48L3A+PHAgY2xhc3M9eWl2MTg5MjA3MjQ1Mm1zb25vcm1hbD4mbmJzcDs8bzpwPjwvbzpw PjwvcD48cD4xLjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny4wcHQnPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+VGhlIG1lY2hhbmlzbSBpcyB1bmRlciBzcGVjaWZp ZWQsIGVzcGVjaWFsbHkgaW4gaXRzIGhhbmRsaW5nIG9mIHRoZSBjbGllbnRfaWQgaWRlbnRpZmll ciAod2hlbiB1c2VkIHRvIG9idGFpbiBlbmQtdXNlciBhdXRob3JpemF0aW9uKS4gSXQgZG9lcyBu b3QgY29udGFpbiBhbnkgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byBhY2NvbXBsaXNoIGFueSBs ZXZlbCBvZiBpbnRlcm9wZXJhYmlsaXR5IG9yIGZ1bmN0aW9uYWxpdHkuIFRoaXMgaXMgaW4gY29u dHJhc3QgdG8gdGhlIGFzc2VydGlvbiBncmFudCB0eXBlIHdoaWNoIGhhcyBtYXR1cmVkIG92ZXIg YSB5ZWFyIGludG8gYSBmdWxseSB0aG91Z2h0LW91dCBleHRlbnNpb24gbWVjaGFuaXNtLCBhcyB3 ZWxsIGFzIGEgc2VwYXJhdGUgU0FNTCBhc3NlcnRpb24gc3BlY2lmaWNhdGlvbiB3aXRoIGFjdGl2 ZSBkZXBsb3ltZW50ICh0aGUgdHdvLCB0b2dldGhlciB3aXRoIHJ1bm5pbmcgY29kZSwgc2hvdyBj bGVhciBjb25zZW5zdXMpLjxvOnA+PC9vOnA+PC9wPjxwPjIuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5UaGUg c2VjdGlvbiBpcyBhIGNvbmZ1c2VkIG1peCBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzcHJp bmtsZWQgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UuIEluc3RlYWQsIGl0IHNob3VsZCBiZSByZXBs YWNlZCB3aXRoIGd1aWRlbGluZXMgZm9yIGV4dGVuZGluZyB0aGUgc2V0IG9mIHN1cHBvcnRlZCBj bGllbnQgY3JlZGVudGlhbHMsIGJ1dCB3aXRob3V0IGRlZmluaW5nIGEgbmV3IHJlZ2lzdHJ5LiBJ dCBpcyBjbGVhcmx5IGFuIGFyZWEgb2YgbGl0dGxlIGRlcGxveW1lbnQgZXhwZXJpZW5jZSBmb3Ig T0F1dGgsIGFuZCB0aGF0IGluY2x1ZGVzIHVzaW5nIEhUVFAgQmFzaWMgYXV0aGVudGljYXRpb24g Zm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAobW9yZSBvbiB0aGF0IHRvIGNvbWUpLjxvOnA+PC9v OnA+PC9wPjxwPjMuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5UaGUgc2VjdGlvbiBoYXMgcmVjZWl2ZWQgYSBs aXR0bGUgc3VwcG9ydCBhbmQgYSBsaXR0bGUgb2JqZWN0aW9uLiBUaG9zZSB3aG8gc3RpbGwgd2Fu dCB0byBhZHZvY2F0ZSBmb3IgaXQgbmVlZCB0byBzaG93IG5vdCBvbmx5IGNvbnNlbnN1cyBmb3Ig a2VlcGluZyBpdCwgYnV0IGFsc28gYWN0aXZlIGNvbW11bml0eSBzdXBwb3J0IGZvciBkZXBsb3lp bmcgaXQuIERlcGxveW1lbnQsIG9mIGNvdXJzZSwgd2lsbCBhbHNvIHJlcXVpcmUgc2hvd2luZyBw cm9ncmVzcyBvbiBwdWJsaWMgc3BlY2lmaWNhdGlvbnMgcHJvZmlsaW5nIHRoZSBtZWNoYW5pc20g aW50byBhIHVzZWZ1bCBpbnRlcm9wZXJhYmxlIGZlYXR1cmUuPG86cD48L286cD48L3A+PHAgY2xh c3M9eWl2MTg5MjA3MjQ1Mm1zb25vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz15 aXYxODkyMDcyNDUybXNvbm9ybWFsPkNvbW1lbnRzPyBDb3VudGVyLWFyZ3VtZW50cz88bzpwPjwv bzpwPjwvcD48cCBjbGFzcz15aXYxODkyMDcyNDUybXNvbm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPXlpdjE4OTIwNzI0NTJtc29ub3JtYWw+RUhMPG86cD48L286cD48L3A+PHAg Y2xhc3M9eWl2MTg5MjA3MjQ1Mm1zb25vcm1hbD4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz15aXYxODkyMDcyNDUybXNvbm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2 PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Jz48ZGl2PjxwIGNsYXNzPXlpdjE4OTIwNzI0NTJtc29ub3JtYWw+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGlu ZyBsaXN0PGJyPjxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPU9BdXRoQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjwv YmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJy PjxhIGhyZWY9Ii9tYy9jb21wb3NlP3RvPU9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+LS0tLS1JbmxpbmUgQXR0YWNobWVu dCBGb2xsb3dzLS0tLS08bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWls aW5nIGxpc3Q8YnI+PGEgaHJlZj0iL21jL2NvbXBvc2U/dG89T0F1dGhAaWV0Zi5vcmciPk9BdXRo QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48L3RkPjwvdHI+PC90YWJs ZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_90C41DD21FB7C64BB94121FBBC2E723445A5AB7FFFP3PW5EX1MB01E_-- From bcampbell@pingidentity.com Mon Jan 17 06:07:44 2011 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 CFBC628C0EF for ; Mon, 17 Jan 2011 06:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 oB4ELBiOWYr7 for ; Mon, 17 Jan 2011 06:07:43 -0800 (PST) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with SMTP id 3968728C0EB for ; Mon, 17 Jan 2011 06:07:42 -0800 (PST) Received: from source ([209.85.161.50]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKTTRNyPND+Hd+Yc43xTsMOicEtMHhf36l@postini.com; Mon, 17 Jan 2011 06:10:18 PST Received: by fxm14 with SMTP id 14so6287576fxm.23 for ; Mon, 17 Jan 2011 06:10:14 -0800 (PST) Received: by 10.223.96.195 with SMTP id i3mr4878958fan.77.1295273413788; Mon, 17 Jan 2011 06:10:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.55.9 with HTTP; Mon, 17 Jan 2011 06:09:43 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246E7E60@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943246E7E60@TK5EX14MBXC202.redmond.corp.microsoft.com> From: Brian Campbell Date: Mon, 17 Jan 2011 07:09:43 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=20cf3054a4d7b7537c049a0b5731 Cc: oauth Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations 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: Mon, 17 Jan 2011 14:07:44 -0000 --20cf3054a4d7b7537c049a0b5731 Content-Type: text/plain; charset=ISO-8859-1 That text still seems more restrictive than what is in the framework specification. And it's probably unnecessary - to the point James made previously, any mention of the AS (beyond specifying the token_type) in a "using a token" specification should probably be avoided unless there is a very specific reason for including it. In general, the AS is involved when "getting a token" and the RS is involved when "using a token." On Fri, Jan 14, 2011 at 6:40 PM, Mike Jones wrote: > Thanks for your input, Brian. I accepted these suggestions for draft -02. > The referenced text now reads: > > Furthermore, the > authorization server MUST ensure that it only hands out tokens to > clients it has authenticated first and authorized. For this > purpose, the client MUST be authenticated and authorized by > the authorization server. The authorization server MUST also > obtain the consent of the resource owner > prior to providing a token to the client. > > I'll leave it up to Eran how much of this security considerations text to > incorporate into the framework specification. > > -- Mike > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Brian Campbell > Sent: Thursday, December 09, 2010 1:38 PM > To: oauth > Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 > security considerations > > I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, > however, a couple things jumped out at me in areas that hadn't received much > attention yet so I wanted to raise the questions on a separate thread. > > Near the end of section 3.2. Threat Mitigation, it says: > > " Furthermore, the resource server MUST ensure that it only hands out > tokens to clients it has authenticated first and authorized. For > this purpose, the client MUST be authenticated and authorized by the > resource server. " > > Was the intent here to say authorization server rather than resource > server? The resource server doesn't hand out tokens. Also, aren't there > legitimate cases where the client isn't authenticated (anonymous or other > cases where the client can't keep secrets)? > > Then it says: > > "The authorization server MUST also receive a > confirmation (the consent of the resource owner) prior to providing a > token to the client." > > Does this allow for implicit consent? On my first read of it, I interpret > this as potentially being more restrictive than what is in > draft-ietf-oauth-v2-11 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --20cf3054a4d7b7537c049a0b5731 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That text still seems more restrictive than what is in the framework specif= ication.=A0 And it's probably unnecessary - to the point James made pre= viously, any mention of the AS (beyond specifying the token_type) in a &quo= t;using a token" specification should probably be avoided unless there= is a very specific reason for including it.=A0 In general, the AS is invol= ved when "getting a token" and the RS is involved when "usin= g a token."

On Fri, Jan 14, 2011 at 6:40 PM, Mike Jones = <Michae= l.Jones@microsoft.com> wrote:
Thanks for your input, Brian. =A0I accepted these suggestions for draft -02= . =A0The referenced text now reads:

=A0 =A0 =A0 =A0 Furthermore, the
=A0 =A0 =A0 =A0 =A0authorization server MUST ensure that it only hands out= tokens to
=A0 =A0 =A0 =A0 =A0clients it has authenticated first an= d authorized. For this
=A0 =A0 =A0 =A0 =A0purpose, the client MUST be authenticated and authorize= d by
=A0 =A0 =A0 =A0 =A0the authorization server. The authorization serve= r MUST also
=A0 =A0 =A0 =A0 =A0obtain the consent of the resource owner
=A0 =A0 =A0 =A0 =A0prior to providing a token to the cli= ent.

I'll leave it up to Eran how much of this security considerations= text to incorporate into the framework specification.

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

-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, December 09, 2010 1:38 PM
To: oauth
Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 secur= ity considerations

I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however= , a couple things jumped out at me in areas that hadn't received much a= ttention yet so I wanted to raise the questions on a separate thread.

Near the end of section 3.2. Threat Mitigation, it says:

" Furthermore, the resource server MUST ensure that it only hands out<= br> =A0 tokens to clients it has authenticated first and authorized. =A0For =A0 this purpose, the client MUST be authenticated and authorized by the =A0 resource server. "

Was the intent here to say authorization server rather than resource server= ? The resource server doesn't hand out tokens. Also, aren't there l= egitimate cases where the client isn't authenticated (anonymous or othe= r cases where the client can't keep secrets)?

Then it says:

"The authorization server MUST also receive a
=A0 confirmation (the consent of the resource owner) prior to providing a<= br> =A0 token to the client."

Does this allow for implicit consent? On my first read of it, I interpret t= his as potentially being more restrictive than what is in
draft-ietf-oauth-v2-11
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth


--20cf3054a4d7b7537c049a0b5731-- From jricher@mitre.org Mon Jan 17 07:40:38 2011 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 B76683A6F46 for ; Mon, 17 Jan 2011 07:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 V7qwPBqCo2kC for ; Mon, 17 Jan 2011 07:40:38 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id D4C253A6F42 for ; Mon, 17 Jan 2011 07:40:37 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8AB9021B06F4; Mon, 17 Jan 2011 10:43:11 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 83E9121B06F2; Mon, 17 Jan 2011 10:43:11 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Mon, 17 Jan 2011 10:43:11 -0500 From: "Richer, Justin P." To: Eran Hammer-Lahav , OAuth WG Date: Mon, 17 Jan 2011 10:42:51 -0500 Thread-Topic: Removal: HTTP Basic Authentication for Client Credentials Thread-Index: Acu0f9IqxkhbY4HfQHS+hXiSb6TXlgB3WFJP Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials 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: Mon, 17 Jan 2011 15:40:38 -0000 +1 to making BASIC optional. I don't think we were going to be supporting i= t in general, either. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Saturday, January 15, 2011 1:53 AM To: OAuth WG Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentia= ls OAuth 2.0 provides two methods for client authentication using password cre= dentials: request parameters and HTTP Basic authentication. I suggest we dr= op the requirement to support HTTP Basic authentication, and only mention i= t as an example for alternative methods. My reasons are: 1. A few providers have expressed concerns over the need to support B= asic authentication, and some explicitly said they will not support it. Par= ameter-based authentication, OTOH, is widely deployed in 2.0. 2. Due to the way OAuth is being implemented at the HTTP authenticati= on layer (even if it is wrong), can conflict within the framework as both a= consumer and provider of authentication components. 3. The mapping between username and client_id, while not complicated,= is still a big awkward, and can be confusing when combined with the userna= me and password grant type. On the other hand, the use of client_id in the = end-user authorization endpoint lends itself nicely to the use of the same = parameter elsewhere. 4. Some existing authentication frameworks will have an issue handlin= g the mix of Basic authentication and parameters authentication due to how = each is deployed. In cases where a front gate handles Basic, it will be har= d to let requests through for parameter processing. Comments? Counter-arguments? EHL From jricher@mitre.org Mon Jan 17 07:56:16 2011 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 BFFBF3A6BD8 for ; Mon, 17 Jan 2011 07:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=-0.941, 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 6TPAdAXVepZN for ; Mon, 17 Jan 2011 07:56:15 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 567473A6BD7 for ; Mon, 17 Jan 2011 07:56:15 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A25AA21B06F7; Mon, 17 Jan 2011 10:58:49 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 91AD221B06EF; Mon, 17 Jan 2011 10:58:49 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Mon, 17 Jan 2011 10:58:49 -0500 From: "Richer, Justin P." To: Torsten Lodderstedt , Eran Hammer-Lahav Date: Mon, 17 Jan 2011 10:55:05 -0500 Thread-Topic: [OAUTH-WG] Removal: credential body parameters Thread-Index: Acu1rtbMJGlngNoQRYqIfC/Sg0vnYwAsBIPm Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <4D333EE9.1030706@lodderstedt.net> In-Reply-To: <4D333EE9.1030706@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters 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: Mon, 17 Jan 2011 15:56:16 -0000 I absolutely don't want to drop credentials being passed as parameters. I t= hink that's more widely deployed than using the BASIC style auth as well. I do think that Torsten's approach below has a certain elegance to it, but = it would require deeper access to queries that not all deployment framework= s allow (or at least, make easy to access). For part 3 below, it's usually = the PR and not the AS that's returning the 401, so this would require the P= R to know what kinds of things the AS will accept. Right now, the client ne= eds to know that, which I think is more reasonable. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Torsten = Lodderstedt [torsten@lodderstedt.net] Sent: Sunday, January 16, 2011 1:54 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters Hi Eran, you made some good points and I agree with most of your analysis. The way w= e use BASIC in the current draft is not perfect, mainly because it is a com= promise. It was basically the attempt to be more HTTP compliant while still= supporting the parameter-based approach. I would strongly object against removing BASIC and relying on body paramete= rs, only. We (Deutsche Telekom) have implemented that scheme and do not se= e a real problem with it. In order to overcome the problems you listed, I would like to propose an al= ternative approach. I would suggest to drop support for passing any credentials to the tokens e= ndpoint in the body of the POST request. Instead, I would suggest to define= one HTTP authentication scheme per grant type and send the corresponding p= arameters within the Authorization header. Conceptually, the tokens endpoint is a resource URI clients use to obtain t= okens. The expected token scope can be explicitely specified by the corresp= onding URI query parameter. So the simplest, complete request to obtain a t= oken could look as follows: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded scope=3Dsomething Most authorization servers will certainly need credentials of some kind as = pre-requisite for token issuance. These credentials actually authenticate t= he resource owner and the client to the authorization server as well as pro= ve the client's authorization to get the token. Such credentials are usuall= y passed using authorization headers in HTTP requests. Let's take the example of the grant type "code". We could define a scheme "= CODE", which carries the parameters code, redirect_uri, client_id and clien= t_secret (optionally) as named values. An example request could look as fol= lows POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: CODE code=3D'i1WsRn1uB1', redirect_uri=3D'https%3A%2F%2Fclient%2Eexample%2Ec= om%2Fcb', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething The following examples illustrate the approach with respect to the grant ty= pes "password" and "refresh_token", respectively. POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: PWD username=3D'johndoe', password=3D'A3ddj3w', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: REFRESH token=3D'n4E9O119d', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething I see the following advantages: 1) The suggest approach is aligned with HTTP. So instead of using HTTP as "= transport protocol" only (as in the dark times of SOAP), we could make bett= er use of the existing framework for messaging, caching, and security. 2) Since the proposed approach is alligned with HTTP authentication and aut= horization in general, it would be an easy task to add support for addition= al, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or = GBA to an OAuth authorization server. 3) WWW-Authenticate headers could be used to provide clients with useful in= formation about the capabilities of the authorization server. In the follow= ing example, the server reacts to an unauthenticated request with the follo= wing response HTTP/1.1 401 Unauthorized WWW-Authenticate: CODE uri=3D"tokenservice.example.com/authorize" WWW-Authenticate: PWD realm=3D'users.example.com' WWW-Authenticate: REFRESH which indicates its support for the grant types authorization_code, usernam= e/password and refresh token. Additionally it provides the client with the = end-user endpoint URI of the authorization server and the user realm suppor= ted for password authentication. 4) The proposed mechanism should work nicely with existing authentication f= rameworks, since we would no longer use a mixed model for passing credentia= ls and dedicated HTTP authentication schemes. What do you think? What do others think? regards, Torsten. Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav: OAuth 2.0 provides two methods for client authentication using password cre= dentials: request parameters and HTTP Basic authentication. I suggest we dr= op the requirement to support HTTP Basic authentication, and only mention i= t as an example for alternative methods. My reasons are: 1. A few providers have expressed concerns over the need to support B= asic authentication, and some explicitly said they will not support it. Par= ameter-based authentication, OTOH, is widely deployed in 2.0. 2. Due to the way OAuth is being implemented at the HTTP authenticati= on layer (even if it is wrong), can conflict within the framework as both a= consumer and provider of authentication components. 3. The mapping between username and client_id, while not complicated,= is still a big awkward, and can be confusing when combined with the userna= me and password grant type. On the other hand, the use of client_id in the = end-user authorization endpoint lends itself nicely to the use of the same = parameter elsewhere. 4. Some existing authentication frameworks will have an issue handlin= g the mix of Basic authentication and parameters authentication due to how = each is deployed. In cases where a front gate handles Basic, it will be har= d to let requests through for parameter processing. Comments? Counter-arguments? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Mon Jan 17 10:16:18 2011 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 1233828C16C for ; Mon, 17 Jan 2011 10:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 UfBVyLUvRFHi for ; Mon, 17 Jan 2011 10:16:16 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id EA7A33A6D6D for ; Mon, 17 Jan 2011 10:16:15 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0HIIk3I030334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 17 Jan 2011 18:18:48 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0HHKKcH012398; Mon, 17 Jan 2011 18:18:41 GMT Received: from abhmt014.oracle.com by acsmt355.oracle.com with ESMTP id 966265321295288270; Mon, 17 Jan 2011 10:17:50 -0800 Received: from [192.168.1.8] (/24.85.235.164) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 17 Jan 2011 10:17:49 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-3--846512643 From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FFF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 17 Jan 2011 10:17:47 -0800 Message-Id: References: <96513.20589.qm@web55801.mail.re3.yahoo.com> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FFF@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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: Mon, 17 Jan 2011 18:16:18 -0000 --Apple-Mail-3--846512643 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 What if strong authentication of client (between client and AM) happened = OOB? Instead of passing a client_assertion, why not pass a client_token? = In a sense we would be repeating the pattern for users and applying it = to clients. A client use its own client_token to obtain access tokens. I can see this approach having an advantage when a client is a web = service supporting multiple end-users. It could re-use its own = authentication tokens many times and wouldn't have to incur an expensive = strong-authentication every time it handles an OAuth token request. The only concern I see with this, is whether a bearer token would work. = You'd want to strongly bind the client with the token. IMHO Phil phil.hunt@oracle.com On 2011-01-17, at 12:06 AM, Eran Hammer-Lahav wrote: > One more reason to remove the half-baked text from the spec and = reintroduce it with a full specification elsewhere. > =20 > EHL > =20 > From: Francisco Corella [mailto:fcorella@pomcor.com]=20 > Sent: Sunday, January 16, 2011 11:31 PM > To: Eran Hammer-Lahav; David Recordon > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials > =20 > I wanted to point out that an assertion by itself cannot > authenticate the client, contrary to what the draft seems to > imply. >=20 > Section 3.2 of the spec says that, when using a client > assertion, the client sends two parameters: > client_assertion_type and client_assertion. This does not > work. A client assertion will typically bind a public key > to some information about the client. Sending the assertion > will not by itself authenticate the client. The client must > also demonstrate that it owns the corresponding private key. >=20 > To look at it from a different angle, section 3.2 also says: >=20 > > The assertion format, the process by which the assertion is > > obtained, and the method of validating the assertion are > > defined by the assertion issuer and the authorization > > server, and are beyond the scope of this specification. >=20 > This misses an essential element of an assertion, what the > SAML spec calls "subject confirmation" (section 2.4.1.1). > Subject confirmation is not a private matter between the > assertion and the authorization server, it must also involve > the client, and hence it must be an integral part of the > protocol. >=20 > Another thing that's wrong is that the client assertion is > obtained too late in the protocol flow. An assertion can > provide information that the server can use to identify the > client application to the user as it authenticates the user > and asks for permission to grant the client application's > request. But that has already been done by the time the > server obtains the assertion. >=20 > On the other hand I like assertions because they could > help identify unregistered applications, which is what I'm > trying to achieve with my PKAuth protocol. So I'm thinking > about adding them to PKAuth. That should be easy, because > in PKAuth the client authenticates itself by presenting its > TLS certificate and demonstrating knowledge of the > corresponding private key in a TLS handshake. An assertion > can then simply bind additional information to the > certificate, and "subject confirmation" is already taken > care of. >=20 > Francisco >=20 > --- On Sun, 1/16/11, David Recordon wrote: >=20 > From: David Recordon > Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials > To: "Eran Hammer-Lahav" > Cc: "OAuth WG" > Date: Sunday, January 16, 2011, 8:36 PM >=20 > Seems good enough to me. +1 to removing it so that it will become = fully fleshed out in a useful manner. > =20 >=20 > On Sat, Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav = wrote: > You still need to define it. The two parameters don=92t accomplish = anything since you can=92t use them without a more detailed = specification, in which case, what is the value of this? Where is the = interoperability gain? >=20 > =20 >=20 > This is clearly not a feature that is likely to be implemented in any = general purpose library, unlike the =91scope=92 parameter which is = under-defined but still useful for library support. >=20 > =20 >=20 > Including it in the specification is confusing (the unanimous feedback = I received so far), without any benefit. The specification provides a = clear extension mechanism for new parameters. Why is that not enough? >=20 > =20 >=20 > EHL >=20 > =20 >=20 > From: Phillip Hunt [mailto:phil.hunt@Oracle.com]=20 > Sent: Saturday, January 15, 2011 12:52 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials >=20 > =20 >=20 > A strong client credential is needed in many cases. I had assumed = client assertion would fulfill this need.=20 >=20 >=20 > Phil >=20 > =20 >=20 > Sent from my phone.=20 >=20 >=20 > On 2011-01-14, at 22:45, Eran Hammer-Lahav = wrote: >=20 > I would like to suggest we drop the client assertion credentials (-11 = section 3.2) from the specification, and if needed, publish it as a = separate specification for the following reasons: >=20 > =20 >=20 > 1. The mechanism is under specified, especially in its handling = of the client_id identifier (when used to obtain end-user = authorization). It does not contain any implementation details to = accomplish any level of interoperability or functionality. This is in = contrast to the assertion grant type which has matured over a year into = a fully thought-out extension mechanism, as well as a separate SAML = assertion specification with active deployment (the two, together with = running code, show clear consensus). >=20 > 2. The section is a confused mix of security considerations = sprinkled with normative language. Instead, it should be replaced with = guidelines for extending the set of supported client credentials, but = without defining a new registry. It is clearly an area of little = deployment experience for OAuth, and that includes using HTTP Basic = authentication for client authentication (more on that to come). >=20 > 3. The section has received a little support and a little = objection. Those who still want to advocate for it need to show not only = consensus for keeping it, but also active community support for = deploying it. Deployment, of course, will also require showing progress = on public specifications profiling the mechanism into a useful = interoperable feature. >=20 > =20 >=20 > Comments? Counter-arguments? >=20 > =20 >=20 > EHL >=20 > =20 >=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 > =20 >=20 > -----Inline Attachment Follows----- >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-3--846512643 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 What = if strong authentication of client (between client and AM) happened OOB? = Instead of passing a client_assertion, why not pass a client_token? In a = sense we would be repeating the pattern for users and applying it to = clients.  A client use its own client_token to obtain access = tokens.

I can see this approach having an advantage = when a client is a web service supporting multiple end-users.  It = could re-use its own authentication tokens many times and wouldn't have = to incur an expensive strong-authentication every time it handles an = OAuth token request.

The only concern I see = with this, is whether a bearer token would work. You'd want to strongly = bind the client with the token. IMHO


On 2011-01-17, at 12:06 AM, Eran Hammer-Lahav = wrote:

One more reason to remove the half-baked text from = the spec and reintroduce it with a full specification = elsewhere.
 
EHL
 Francisco= Corella [mailto:fcorella@pomcor.com] 
Sent: Sunday, January 16, 2011 = 11:31 PM
To: Eran Hammer-Lahav; David = Recordon
Cc: OAuth = WG
Subject: Re: [OAUTH-WG] Removal: = Client Assertion Credentials
 
I wanted to point out = that an assertion by itself cannot
authenticate the client, contrary = to what the draft seems to
imply.

Section 3.2 of the spec says = that, when using a client
assertion, the client sends two = parameters:
client_assertion_type and client_assertion.  This = does not
work.  A client assertion will typically bind a public = key
to some information about the client.  Sending the = assertion
will not by itself authenticate the client.  The = client must
also demonstrate that it owns the corresponding private = key.

To look at it from a different angle, section 3.2 also = says:

> The assertion format, the process by which the = assertion is
> obtained, and the method of validating the = assertion are
> defined by the assertion issuer and the = authorization
> server, and are beyond the scope of this = specification.

This misses an essential element of an assertion, = what the
SAML spec calls "subject confirmation" (section = 2.4.1.1).
Subject confirmation is not a private matter between = the
assertion and the authorization server, it must also = involve
the client, and hence it must be an integral part of = the
protocol.

Another thing that's wrong is that the client = assertion is
obtained too late in the protocol flow.  An = assertion can
provide information that the server can use to identify = the
client application to the user as it authenticates the = user
and asks for permission to grant the client = application's
request.  But that has already been done by the = time the
server obtains the assertion.

On the other hand I = like assertions because they could
help identify unregistered = applications, which is what I'm
trying to achieve with my PKAuth = protocol.  So I'm thinking
about adding them to PKAuth.  = That should be easy, because
in PKAuth the client authenticates = itself by presenting its
TLS certificate and demonstrating knowledge = of the
corresponding private key in a TLS handshake.  An = assertion
can then simply bind additional information to = the
certificate, and "subject confirmation" is already taken
care = of.

Francisco

--- On Sun, 1/16/11, David = Recordon <recordond@gmail.com> wrote:


From: David Recordon <recordond@gmail.com>
Subject: = Re: [OAUTH-WG] Removal: Client Assertion Credentials
To: "Eran = Hammer-Lahav" <eran@hueniverse.com>
Cc: = "OAuth WG" <oauth@ietf.org>
Date: Sunday, = January 16, 2011, 8:36 PM

Seems good enough to me. +1 to removing it so that it will = become fully fleshed out in a useful manner.

 

On Sat, Jan 15, 2011 at 11:32 AM, Eran Hammer-Lahav <You = still need to define it. The two parameters don=92t accomplish anything = since you can=92t use them without a more detailed specification, in = which case, what is the value of this? Where is the interoperability = gain?

 

This = is clearly not a feature that is likely to be implemented in any general = purpose library, unlike the =91scope=92 parameter which is under-defined = but still useful for library support.

Including it in the specification is = confusing (the unanimous feedback I received so far), without any = benefit. The specification provides a clear extension mechanism for new = parameters. Why is that not enough?

EHL

From: Phillip Hunt [mailto: 
Sent: Saturday, January 15, 2011 = 12:52 AM
To: Eran = Hammer-Lahav
Cc: OAuth = WG
Subject: Re: [OAUTH-WG] Removal: = Client Assertion = Credentials

 


On 2011-01-14, at 22:45, Eran = Hammer-Lahav <

I would like to suggest we drop the client assertion = credentials (-11 section 3.2) from the specification, and if needed, = publish it as a separate specification for the following = reasons:

 

1.       The mechanism is = under specified, especially in its handling of the client_id identifier = (when used to obtain end-user authorization). It does not contain any = implementation details to accomplish any level of interoperability or = functionality. This is in contrast to the assertion grant type which has = matured over a year into a fully thought-out extension mechanism, as = well as a separate SAML assertion specification with active deployment = (the two, together with running code, show clear = consensus).

2.       The section is a = confused mix of security considerations sprinkled with normative = language. Instead, it should be replaced with guidelines for extending = the set of supported client credentials, but without defining a new = registry. It is clearly an area of little deployment experience for = OAuth, and that includes using HTTP Basic authentication for client = authentication (more on that to come).

3.       The section has = received a little support and a little objection. Those who still want = to advocate for it need to show not only consensus for keeping it, but = also active community support for deploying it. Deployment, of course, = will also require showing progress on public specifications profiling = the mechanism into a useful interoperable feature.

 

Comments? = Counter-arguments?

 

EHL

 

 


-----Inline Attachment Follows-----

_______________________________________________
OAuth = mailing list
OAuth@ietf.org
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 07:25:31 -0000 --0-866750199-1295335683=:9226 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Phil, > What if strong authentication of client (between client and > AM) happened OOB? Instead of passing a client_assertion, why > not pass a client_token? In a sense we would be repeating > the pattern for users and applying it to clients.=A0 A client > use its own client_token to obtain access tokens. Interesting question.=A0 Two answers: 1. That works, but the client_token is then a shared secret between client and server, and there is no difference with a client password established by registration of the client with the server.=A0 Registration is an out-of-bound process that establishes a shared secret.=A0 The registration process can use a SAML assertion. 2. The best answer, though, is that client authentication after the double redirection (after the client redirects the user to the server for user authentication, and the server redirects the user back to the client with the authorization code) only provides an illusion of security. Security hinges on the fact that the authorization code goes to the legitimate client.=A0 If it goes to an attacker, the attacker can send the authorization code to the client from its own browser, thus impersonating the legitimate user. The client will send the authorization code to the server to get an access token, and use the access token to access the legitimate user's resources for the benefit of the attacker. It does not matter how strongly the client authenticates itself to the server; the legitimate client is now working for the attacker! And if the authorization code is guaranteed to go to the legitimate client, there is no need for the client to authenticate itself to the server. Actually, client authentication after redirection is not completely useless.=A0 It can help limit the damage done by a successful attack.=A0 Here's how that goes. Without client authentication after the double redirection, if an attacker somehow gets the authorization code, he/she can do two kinds of damage: (i) he/she can use it to get an access token from the server (masquerading as a legitimate client vis-a-vis the server) and thus gain direct access to the legitimate user's resources, and (ii) he/she can use it to impersonate the legitimate user and log in to the client (in the common case where the client uses OAuth for "social login" a la Facebook Connect; the client will log the user in after successfully exchanging the authorization code for an access token). With client authentication after the double redirection, the attacker can do less damage after a successful attack.=A0=20 The attacker can try to get the authorization code in two different ways: (1) by setting up a bogus client that masquerades as the legitimate client vis-a-vis the user, and tricking the user into granting access to the bogus client; or (2) by somehow intercepting the authorization code as the server sends it to the legitimate client. If the attacker gets the authorization code by method (1), the attacker can do damage (i), but cannot do damage (ii) because, when the legitimate client tries to verify the authorization code by sending it to the server, the server will detect that the authorization code was not sent to the legitimate client (it was sent to the bogus client); the server will not send the access token, and the legitimate client will not log in the attacker. If the attacker obtained the authorization code by method (2), the attacker can do damage (ii), but cannot do damage (i) because the attacker will not be able to exchange the authorization code for an access token, given that the authorization code was sent to the legitimate client and the server wants the authorization code to be presented by whichever client it was sent to. Francisco --0-866750199-1295335683=:9226 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Phil,

> What if strong authenticati= on of client (between client and
> AM) happened OOB? Instead of passi= ng a client_assertion, why
> not pass a client_token? In a sense we w= ould be repeating
> the pattern for users and applying it to clients.=   A client
> use its own client_token to obtain access tokens.
Interesting question.  Two answers:

1. That works, but th= e client_token is then a shared secret
between client and server, and th= ere is no difference with a
client password established by registration = of the client
with the server.  Registration is an out-of-bound pro= cess
that establishes a shared secret.  The registration processcan use a SAML assertion.

2. The best answer, though, is that clien= t authentication
after the double redirection (after the client redirect= s the
user to the server for user authentication, and the server
redir= ects the user back to the client with the authorization
code) only provi= des an illusion of security.

Security hinges on the fact that the au= thorization code goes
to the legitimate client.  If it goes to an a= ttacker, the
attacker can send the authorization code to the client from=
its own browser, thus impersonating the legitimate user.
The client = will send the authorization code to the server to
get an access token, a= nd use the access token to access the
legitimate user's resources for th= e benefit of the attacker.
It does not matter how strongly the client au= thenticates
itself to the server; the legitimate client is now workingfor the attacker!

And if the authorization code is guaranteed to g= o to the
legitimate client, there is no need for the client to
authen= ticate itself to the server.

Actually, client authentication after redirection is not
completely useless.  It can help limit th= e damage done by a
successful attack.  Here's how that goes.
Without client authentication after the double redirection,
if an attac= ker somehow gets the authorization code, he/she
can do two kinds of dama= ge:

(i) he/she can use it to get an access token from the server
= (masquerading as a legitimate client vis-a-vis the server)
and thus gain= direct access to the legitimate user's
resources, and

(ii) he/sh= e can use it to impersonate the legitimate user
and log in to the client= (in the common case where the
client uses OAuth for "social login" a la= Facebook Connect;
the client will log the user in after successfullyexchanging the authorization code for an access token).

With client= authentication after the double redirection, the
attacker can do less d= amage after a successful attack. 

The attacker can try to get the authorization code in two
different ways:

(1) by sett= ing up a bogus client that masquerades as the
legitimate client vis-a-vi= s the user, and tricking the user
into granting access to the bogus clie= nt; or

(2) by somehow intercepting the authorization code as the
= server sends it to the legitimate client.

If the attacker gets the a= uthorization code by method (1),
the attacker can do damage (i), but can= not do damage (ii)
because, when the legitimate client tries to verify t= he
authorization code by sending it to the server, the server
will de= tect that the authorization code was not sent to the
legitimate client (= it was sent to the bogus client); the
server will not send the access to= ken, and the legitimate
client will not log in the attacker.

If t= he attacker obtained the authorization code by method
(2), the attacker = can do damage (ii), but cannot do damage
(i) because the attacker will not be able to exchange the
authorization code for an access token= , given that the
authorization code was sent to the legitimate client an= d the
server wants the authorization code to be presented by
whicheve= r client it was sent to.

Francisco

--0-866750199-1295335683=:9226-- From phil.hunt@oracle.com Tue Jan 18 05:33:10 2011 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 1A5AE3A6EF9 for ; Tue, 18 Jan 2011 05:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_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 WbbloLFOeiEZ for ; Tue, 18 Jan 2011 05:33:08 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8388F3A6FDA for ; Tue, 18 Jan 2011 05:33:08 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0IDZaid026060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Jan 2011 13:35:38 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0IDZZko000370; Tue, 18 Jan 2011 13:35:35 GMT Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 968629551295357704; Tue, 18 Jan 2011 05:35:04 -0800 Received: from [10.20.240.94] (/204.239.250.1) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jan 2011 05:31:23 -0800 MIME-Version: 1.0 Message-ID: Date: Tue, 18 Jan 2011 05:31:16 -0800 (PST) From: Phillip Hunt To: "fcorella@pomcor.com" References: <462199.9226.qm@web55802.mail.re3.yahoo.com> In-Reply-To: <462199.9226.qm@web55802.mail.re3.yahoo.com> X-Mailer: iPhone Mail (8C148a) Content-Type: multipart/alternative; boundary="__129535770205012279abhmt010" Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 18 Jan 2011 13:33:10 -0000 --__129535770205012279abhmt010 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Not sure I agree. Yes shared secret But one may be long lived (permanent) w= hile the other may be good for minutes. If a server has both what then? I su= ppose we could detect type in client_secret or do it by policy associated wi= th a client_id. Is that what is intended in the spec? As you say " > Security hinges on the fact that the authorization code goes > to the legitimate client ". Somewhere we should be talking about the importance of this. Too many cur= rent implementations are using permanent shared secrets which as we know are= not secrets.=20 Phil Sent from my phone.=20 On 2011-01-17, at 23:28, Francisco Corella wrote: > Phil, >=20 > > What if strong authentication of client (between client and > > AM) happened OOB? Instead of passing a client_assertion, why > > not pass a client_token? In a sense we would be repeating > > the pattern for users and applying it to clients. A client > > use its own client_token to obtain access tokens. >=20 > Interesting question. Two answers: >=20 > 1. That works, but the client_token is then a shared secret > between client and server, and there is no difference with a > client password established by registration of the client > with the server. Registration is an out-of-bound process > that establishes a shared secret. The registration process > can use a SAML assertion. >=20 > 2. The best answer, though, is that client authentication > after the double redirection (after the client redirects the > user to the server for user authentication, and the server > redirects the user back to the client with the authorization > code) only provides an illusion of security. >=20 > Security hinges on the fact that the authorization code goes > to the legitimate client. If it goes to an attacker, the > attacker can send the authorization code to the client from > its own browser, thus impersonating the legitimate user. > The client will send the authorization code to the server to > get an access token, and use the access token to access the > legitimate user's resources for the benefit of the attacker. > It does not matter how strongly the client authenticates > itself to the server; the legitimate client is now working > for the attacker! >=20 > And if the authorization code is guaranteed to go to the > legitimate client, there is no need for the client to > authenticate itself to the server. >=20 > Actually, client authentication after redirection is not > completely useless. It can help limit the damage done by a > successful attack. Here's how that goes. >=20 > Without client authentication after the double redirection, > if an attacker somehow gets the authorization code, he/she > can do two kinds of damage: >=20 > (i) he/she can use it to get an access token from the server > (masquerading as a legitimate client vis-a-vis the server) > and thus gain direct access to the legitimate user's > resources, and >=20 > (ii) he/she can use it to impersonate the legitimate user > and log in to the client (in the common case where the > client uses OAuth for "social login" a la Facebook Connect; > the client will log the user in after successfully > exchanging the authorization code for an access token). >=20 > With client authentication after the double redirection, the > attacker can do less damage after a successful attack. =20 >=20 > The attacker can try to get the authorization code in two > different ways: >=20 > (1) by setting up a bogus client that masquerades as the > legitimate client vis-a-vis the user, and tricking the user > into granting access to the bogus client; or >=20 > (2) by somehow intercepting the authorization code as the > server sends it to the legitimate client. >=20 > If the attacker gets the authorization code by method (1), > the attacker can do damage (i), but cannot do damage (ii) > because, when the legitimate client tries to verify the > authorization code by sending it to the server, the server > will detect that the authorization code was not sent to the > legitimate client (it was sent to the bogus client); the > server will not send the access token, and the legitimate > client will not log in the attacker. >=20 > If the attacker obtained the authorization code by method > (2), the attacker can do damage (ii), but cannot do damage > (i) because the attacker will not be able to exchange the > authorization code for an access token, given that the > authorization code was sent to the legitimate client and the > server wants the authorization code to be presented by > whichever client it was sent to. >=20 > Francisco >=20 --__129535770205012279abhmt010 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not sure I agree. Yes shared secret &nb= sp;But one may be long lived (permanent) while the other may be good for min= utes. If a server has both what then? I suppose we could detect type in clie= nt_secret or do it by policy associated with a client_id. Is that what is in= tended in the spec?

As you say "
Security hinges on the fact t= hat the authorization code goes
to the legitimate client
". Somewhere we should be talking about t= he importance of this. Too many current implementations are using permanent s= hared secrets which as we know are not secrets. 

Phil

Sent from my phone. 
=
Phil,

> Wha= t if strong authentication of client (between client and
> AM) happene= d OOB? Instead of passing a client_assertion, why
> not pass a client_= token? In a sense we would be repeating
> the pattern for users and ap= plying it to clients.  A client
> use its own client_token to obt= ain access tokens.

Interesting question.  Two answers:

1.= That works, but the client_token is then a shared secret
between client a= nd server, and there is no difference with a
client password established b= y registration of the client
with the server.  Registration is an ou= t-of-bound process
that establishes a shared secret.  The registrati= on process
can use a SAML assertion.

2. The best answer, though, i= s that client authentication
after the double redirection (after the clie= nt redirects the
user to the server for user authentication, and the server
redire= cts the user back to the client with the authorization
code) only provide= s an illusion of security.

Security hinges on the fact that the autho= rization code goes
to the legitimate client.  If it goes to an attac= ker, the
attacker can send the authorization code to the client from
i= ts own browser, thus impersonating the legitimate user.
The client will s= end the authorization code to the server to
get an access token, and use t= he access token to access the
legitimate user's resources for the benefit= of the attacker.
It does not matter how strongly the client authenticate= s
itself to the server; the legitimate client is now working
for the a= ttacker!

And if the authorization code is guaranteed to go to the
= legitimate client, there is no need for the client to
authenticate itself= to the server.

Actually, client authentication after redirection is not
completely useless.  It can help limit the= damage done by a
successful attack.  Here's how that goes.

W= ithout client authentication after the double redirection,
if an attacker= somehow gets the authorization code, he/she
can do two kinds of damage:<= br>
(i) he/she can use it to get an access token from the server
(masq= uerading as a legitimate client vis-a-vis the server)
and thus gain direc= t access to the legitimate user's
resources, and

(ii) he/she can u= se it to impersonate the legitimate user
and log in to the client (in the= common case where the
client uses OAuth for "social login" a la Facebook= Connect;
the client will log the user in after successfully
exchangin= g the authorization code for an access token).

With client authentica= tion after the double redirection, the
attacker can do less damage after a= successful attack. 

The attacker can try to get the authorization code in two
different ways:

(1) by setti= ng up a bogus client that masquerades as the
legitimate client vis-a-vis t= he user, and tricking the user
into granting access to the bogus client; o= r

(2) by somehow intercepting the authorization code as the
server= sends it to the legitimate client.

If the attacker gets the authoriz= ation code by method (1),
the attacker can do damage (i), but cannot do d= amage (ii)
because, when the legitimate client tries to verify the
aut= horization code by sending it to the server, the server
will detect that t= he authorization code was not sent to the
legitimate client (it was sent t= o the bogus client); the
server will not send the access token, and the l= egitimate
client will not log in the attacker.

If the attacker obt= ained the authorization code by method
(2), the attacker can do damage (i= i), but cannot do damage
(i) because the attacker will not be able to exchange the
authorization code for an access token,= given that the
authorization code was sent to the legitimate client and t= he
server wants the authorization code to be presented by
whichever cl= ient it was sent to.

Francisco

= --__129535770205012279abhmt010-- From wmills@yahoo-inc.com Tue Jan 18 08:41:31 2011 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 C06FE28C204 for ; Tue, 18 Jan 2011 08:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.383 X-Spam-Level: X-Spam-Status: No, score=-17.383 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, 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 6UlDYC5HA12x for ; Tue, 18 Jan 2011 08:41:25 -0800 (PST) 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 E54FB28C1E8 for ; Tue, 18 Jan 2011 08:41:24 -0800 (PST) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0IGhZv1065571; Tue, 18 Jan 2011 08:43:35 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Tue, 18 Jan 2011 08:43:34 -0800 From: William Mills To: Eran Hammer-Lahav , OAuth WG Date: Tue, 18 Jan 2011 08:43:34 -0800 Thread-Topic: Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu0eqc8OI1TGx2yS4KwfqhDmZy6TQAZBo3Q Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A3156258BF26F9ASP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 18 Jan 2011 16:41:31 -0000 --_000_FFDFD7371D517847AD71FBB08F9A3156258BF26F9ASP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As long as we can do the discovery in band and it doesn't require major dif= ferences in-band I'm OK. I spinning back up on the SASL mechanism (now tha= t I finally was allowed to opensource it), and my current in-band discovery= is pretty clean using WWW-Authenticate. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 14, 2011 10:32 PM To: OAuth WG Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme One of the main problems with OAuth in general has always been the unsanita= ry mix of authorization and authentication ("it's an authentication protoco= l... authorization protocol... authentication protocol" [1]). It has always= been a confusing mess. The work on 2.0 has provided a valuable abstraction= and separation of the two components, especially the recent document split= . In addition, the recent work on the bearer token document and the MAC tok= en type have raised issues about OAuth and its relationship with HTTP authe= ntication. I would like to suggest we drop the 'OAuth2' WWW-Authenticate header comple= tely from the specification for the following reasons: 1. Draft oauth-v2 is clearly not an authentication protocol. It *util= izes* client authentication. It offers one fully defined method for client = authentication (which is basically HTTP Basic+), provides a half-baked clie= nt assertion authentication hook, and leaves all end-user authentication ou= t of scope. 2. The WWW-Authenticate header has absolutely no value, interoperabil= ity-wise or otherwise. Discovery was rules to be beyond the scope of this s= pecification. Having a protected resource declare it supports authenticatio= n using some unspecified credentials obtained using some unspecified client= flow is confusing at best. In the future, an interoperable discovery mecha= nism will be needed to allow clients to interact with completely unknown pr= otected resources, but this has been consistently ruled to be premature sta= ndardization at this point. 3. OAuth is agnostic to token authentication, and we already have thr= ee discrete token type proposals - all with active deployment plans in the = coming months. Two of these methods have already defined a full HTTP authen= tication scheme (even if the bearer token specification has not yet been up= dated to change its scheme name). 4. HTTP *authentication* is not an appropriate facility to negotiate = *authorization*. OAuth authorization discovery can be added to HTTP authent= ication schemes as attributes, but makes no sense as a scheme of its own. T= he issues we are having with 'realm' is one of the examples showing that we= are abusing the header. 5. Again, as specified, it adds no value and I am not aware of any ex= isting OAuth 1.0a implementation making use of the response header for clie= nt interoperability (yes, many include it, but how many clients actually re= ly on it, and if they do, how?). For these reasons I would like to suggest we: 1. Drop the WWW-Authenticate header definition and OAuth2 scheme from= the specification, leaving it up to each token type to define its own auth= entication flow. In the future, a comprehensive discovery specification sho= uld define a new HTTP response header for providing discovery information. = I have suggested using Link: rel=3D'authorization' as a simple yet powerful= solution. 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' to m= ake it clear what this document is really about. Comments? Counter argument? EHL [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY --_000_FFDFD7371D517847AD71FBB08F9A3156258BF26F9ASP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As long as we can do the discovery in band and it doesn’t require major differences in-band I&= #8217;m OK.  I spinning back up on the SASL mechanism (now that I finally was allowed to o= pensource it), and my current in-band discovery is pretty clean using WWW-Authenticat= e.

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:32 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme

 

One of the main problems with OAuth in general has alw= ays been the unsanitary mix of authorization and authentication (“it̵= 7;s an authentication protocol… authorization protocol… authentication= protocol” [1]). It has always been a confusing mess. The work on 2.0 has provided a valuabl= e abstraction and separation of the two components, especially the recent document split. In addition, the recent work on the bearer token document a= nd the MAC token type have raised issues about OAuth and its relationship with= HTTP authentication.

 

I would like to suggest we drop the ‘OAuth2̵= 7; WWW-Authenticate header completely from the specification for the following reasons:

 

1.&n= bsp;      Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* client authentication. It offers one fully defined method for client authentication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all end-user authentication out of scope.

2.&n= bsp;      The WWW-Authenticate header has absolutely no value= , interoperability-wise or otherwise. Discovery was rules to be beyond the sc= ope of this specification. Having a protected resource declare it supports authentication using some unspecified credentials obtained using some unspe= cified client flow is confusing at best. In the future, an interoperable discovery mechanism will be needed to allow clients to interact with completely unkno= wn protected resources, but this has been consistently ruled to be premature standardization at this point.

3.&n= bsp;      OAuth is agnostic to token authentication, and we already have three discrete token type proposals – all with active de= ployment plans in the coming months. Two of these methods have already defined a ful= l HTTP authentication scheme (even if the bearer token specification has not = yet been updated to change its scheme name).

4.&n= bsp;      HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery= can be added to HTTP authentication schemes as attributes, but makes no sense a= s a scheme of its own. The issues we are having with ‘realm’ is one= of the examples showing that we are abusing the header.

5.&n= bsp;      Again, as specified, it adds no value and I am not aware of any existing OAuth 1.0a implementation making use of the response header for client interoperability (yes, many include it, but how many clie= nts actually rely on it, and if they do, how?).

 

For these reasons I would like to suggest we:

 

1.&n= bsp;      Drop the WWW-Authenticate header definition and OAu= th2 scheme from the specification, leaving it up to each token type to define i= ts own authentication flow. In the future, a comprehensive discovery specifica= tion should define a new HTTP response header for providing discovery informatio= n. I have suggested using Link: rel=3D’authorization’ as a simple ye= t powerful solution.

2.&n= bsp;      Rename the document to ‘The OAuth 2.0 Authori= zation Protocol’ to make it clear what this document is really about.

 

Comments? Counter argument?

 

EHL

 

[1] http://www.youtube.com/watch?v=3D0IBZocFkXGY

 

--_000_FFDFD7371D517847AD71FBB08F9A3156258BF26F9ASP2EX07VS06ds_-- From tonynad@microsoft.com Tue Jan 18 09:25:30 2011 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 6BD6D3A7031 for ; Tue, 18 Jan 2011 09:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 btTmV2Gj-sfn for ; Tue, 18 Jan 2011 09:25:29 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id BC5D53A7030 for ; Tue, 18 Jan 2011 09:25:28 -0800 (PST) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 18 Jan 2011 09:28:06 -0800 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.87]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0255.003; Tue, 18 Jan 2011 09:28:06 -0800 From: Anthony Nadalin To: "Richer, Justin P." , Eran Hammer-Lahav , OAuth WG Thread-Topic: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials Thread-Index: AQHLtl1nSm3qABc5GUyMqtbd/Xypq5PW/OGw Date: Tue, 18 Jan 2011 17:28:05 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F0338ABF3@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials 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, 18 Jan 2011 17:25:30 -0000 Concern here is that HTTP Basic Auth provides a straightforward interop pro= file for the web server profile -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of R= icher, Justin P. Sent: Monday, January 17, 2011 7:43 AM To: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Crede= ntials +1 to making BASIC optional. I don't think we were going to be supporting i= t in general, either. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Ham= mer-Lahav [eran@hueniverse.com] Sent: Saturday, January 15, 2011 1:53 AM To: OAuth WG Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentia= ls OAuth 2.0 provides two methods for client authentication using password cre= dentials: request parameters and HTTP Basic authentication. I suggest we dr= op the requirement to support HTTP Basic authentication, and only mention i= t as an example for alternative methods. My reasons are: 1. A few providers have expressed concerns over the need to support B= asic authentication, and some explicitly said they will not support it. Par= ameter-based authentication, OTOH, is widely deployed in 2.0. 2. Due to the way OAuth is being implemented at the HTTP authenticati= on layer (even if it is wrong), can conflict within the framework as both a= consumer and provider of authentication components. 3. The mapping between username and client_id, while not complicated,= is still a big awkward, and can be confusing when combined with the userna= me and password grant type. On the other hand, the use of client_id in the = end-user authorization endpoint lends itself nicely to the use of the same = parameter elsewhere. 4. Some existing authentication frameworks will have an issue handlin= g the mix of Basic authentication and parameters authentication due to how = each is deployed. In cases where a front gate handles Basic, it will be har= d to let requests through for parameter processing. Comments? Counter-arguments? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Jan 18 09:33:20 2011 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 D45563A6FAB for ; Tue, 18 Jan 2011 09:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.586 X-Spam-Level: X-Spam-Status: No, score=-10.586 tagged_above=-999 required=5 tests=[AWL=0.012, 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 32Ri8Gk5QKxq for ; Tue, 18 Jan 2011 09:33:15 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 012933A6F6C for ; Tue, 18 Jan 2011 09:33:14 -0800 (PST) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 18 Jan 2011 09:35:52 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Tue, 18 Jan 2011 09:35:52 -0800 From: Mike Jones To: Eran Hammer-Lahav Thread-Topic: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme Thread-Index: Acu3NiSHXpF3O14eTPqlwk2IwSAdgA== Date: Tue, 18 Jan 2011 17:35:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246EDAA6TK5EX14MBXC202r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 18 Jan 2011 17:33:20 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246EDAA6TK5EX14MBXC202r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Having spoken to a number of people implementing the spec here, I've encoun= tered strong objections to removing Client Assertion Credentials and the OA= uth2 HTTP Authentication Scheme. It's also not clear to me why we would ma= ke substantial breaking changes to the specification when it is essentially= ready for approval. I've summarized the reasons I believe we should keep = these two features below. Client Assertion Credentials: Many of the scenarios we care about require = this capability. They were key motivators for the Assertion Profile in WRAP= (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have ru= nning code that requires this support. For example, the Azure Access Contro= l Service is a cloud Authorization server that supports several protocols, = including parts of OAuth 2.0 draft 10 (autonomous and web server profiles).= We are happy to update our implementation to subsequent drafts & agree tha= t the spec leaves a lot of ambiguity. In our implementation of the autonomous and web server profiles, ACS allows= clients to authenticate using a signed assertion as well as with a usernam= e/password. The username/pwd option is for clients that don't mind sending = credentials over the wire, while the signed assertion mechanism is for clie= nts that are more reticent to send raw credentials and for scenarios where = it isn't possible. To illustrate an example where username/pwd isn't viable= , consider the case of a client that needs to use an enterprise identity to= gain access to a cloud service. In many cases, corporate policy demands th= at a client use an identity managed by the organization. This means that th= e client should obtain an assertion from an enterprise identity provider (A= ctive Directory, Tivoli, etc.) and use that assertion to obtain an access t= oken which grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and reverting e= xclusively to username/pwd isn't an option for us. 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943246EDAA6TK5EX14MBXC202r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Having spoken to a number of people implementing the= spec here, I’ve encountered strong objections to removing Client Ass= ertion Credentials and the OAuth2 HTTP Authentication Scheme.  It̵= 7;s also not clear to me why we would make substantial breaking changes to the specification when it is essentially ready for app= roval.  I’ve summarized the reasons I believe we should keep the= se two features below.

Client Assertion Credentials:  Many of t= he scenarios we care about require this capability. They were key motivator= s for the Assertion Profile in WRAP (see =A7 5.2), have been part of OAuth = 2 for quite a while, and we have running code that requires this support. For example, the Azure Access Control Ser= vice is a cloud Authorization server that supports several protocols, inclu= ding parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We a= re happy to update our implementation to subsequent drafts & agree that the spec leaves a lot of ambiguity.<= o:p>

In our implementation of the autonomous and web serv= er profiles, ACS allows clients to authenticate using a signed assertion as= well as with a username/password. The username/pwd option is for clients t= hat don’t mind sending credentials over the wire, while the signed assertion mechanism is for clients that ar= e more reticent to send raw credentials and for scenarios where it isn̵= 7;t possible. To illustrate an example where username/pwd isn’t viabl= e, consider the case of a client that needs to use an enterprise identity to gain access to a cloud service. In many c= ases, corporate policy demands that a client use an identity managed by the= organization. This means that the client should obtain an assertion from a= n enterprise identity provider (Active Directory, Tivoli, etc.) and use that assertion to obtain an access token = which grants access to various web service APIs. Many of our key MSFT custo= mers and internal partner teams rely on this mechanism and reverting exclus= ively to username/pwd isn’t an option for us.

 

'OAuth2' HTTP Authentication Scheme:  Si= mply put, dropping this seems like a huge step away from interoperability.&= nbsp; As one data point, Microsoft implements this in our WIF OAuth2 protec= ted resource code.  All up, clients need a way to authenticate to the protected resource.  Also, existing WRAP imple= mentations need this functionality to migrate to OAuth2.   For al= l these reasons, we support retaining this functionality in OAuth2.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thanks,

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943246EDAA6TK5EX14MBXC202r_-- From tonynad@microsoft.com Tue Jan 18 09:39:36 2011 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 7CDE03A6E7B for ; Tue, 18 Jan 2011 09:39:36 -0800 (PST) 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=[AWL=-0.000, 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 y53Z5de1A3IH for ; Tue, 18 Jan 2011 09:39:31 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 3AEEA3A6E78 for ; Tue, 18 Jan 2011 09:39:31 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 18 Jan 2011 09:42:08 -0800 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.87]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0255.003; Tue, 18 Jan 2011 09:42:09 -0800 From: Anthony Nadalin To: Mike Jones , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme Thread-Index: Acu3NiSHXpF3O14eTPqlwk2IwSAdgAAAGNmQ Date: Tue, 18 Jan 2011 17:42:07 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F0338AC7B@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18F0338AC7BTK5EX14MBXC113r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 18 Jan 2011 17:39:36 -0000 --_000_180155C5EA10854997314CA5E063D18F0338AC7BTK5EX14MBXC113r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agree that these would be code breaking changes and cause interoperability = issues late in the specification cycle From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Tuesday, January 18, 2011 9:36 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and = OAuth2 HTTP Authentication Scheme Having spoken to a number of people implementing the spec here, I've encoun= tered strong objections to removing Client Assertion Credentials and the OA= uth2 HTTP Authentication Scheme. It's also not clear to me why we would ma= ke substantial breaking changes to the specification when it is essentially= ready for approval. I've summarized the reasons I believe we should keep = these two features below. Client Assertion Credentials: Many of the scenarios we care about require = this capability. They were key motivators for the Assertion Profile in WRAP= (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have ru= nning code that requires this support. For example, the Azure Access Contro= l Service is a cloud Authorization server that supports several protocols, = including parts of OAuth 2.0 draft 10 (autonomous and web server profiles).= We are happy to update our implementation to subsequent drafts & agree tha= t the spec leaves a lot of ambiguity. In our implementation of the autonomous and web server profiles, ACS allows= clients to authenticate using a signed assertion as well as with a usernam= e/password. The username/pwd option is for clients that don't mind sending = credentials over the wire, while the signed assertion mechanism is for clie= nts that are more reticent to send raw credentials and for scenarios where = it isn't possible. To illustrate an example where username/pwd isn't viable= , consider the case of a client that needs to use an enterprise identity to= gain access to a cloud service. In many cases, corporate policy demands th= at a client use an identity managed by the organization. This means that th= e client should obtain an assertion from an enterprise identity provider (A= ctive Directory, Tivoli, etc.) and use that assertion to obtain an access t= oken which grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and reverting e= xclusively to username/pwd isn't an option for us. 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. Thanks, -- Mike --_000_180155C5EA10854997314CA5E063D18F0338AC7BTK5EX14MBXC113r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Agree that these would= be code breaking changes and cause interoperability issues late in the spe= cification cycle

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Tuesday, January 18, 2011 9:36 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentia= ls and OAuth2 HTTP Authentication Scheme

 

Having spoken to a number of people implementing the= spec here, I’ve encountered strong objections to removing Client Ass= ertion Credentials and the OAuth2 HTTP Authentication Scheme.  It̵= 7;s also not clear to me why we would make substantial breaking changes to the specification when it is essentially ready for app= roval.  I’ve summarized the reasons I believe we should keep the= se two features below.

 

Client Assertion Credentials:  Many of t= he scenarios we care about require this capability. They were key motivator= s for the Assertion Profile in WRAP (see =A7 5.2), have been part of OAuth = 2 for quite a while, and we have running code that requires this support. For example, the Azure Access Control Ser= vice is a cloud Authorization server that supports several protocols, inclu= ding parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We a= re happy to update our implementation to subsequent drafts & agree that the spec leaves a lot of ambiguity.<= o:p>

 

In our implementation of the autonomous and web serv= er profiles, ACS allows clients to authenticate using a signed assertion as= well as with a username/password. The username/pwd option is for clients t= hat don’t mind sending credentials over the wire, while the signed assertion mechanism is for clients that ar= e more reticent to send raw credentials and for scenarios where it isn̵= 7;t possible. To illustrate an example where username/pwd isn’t viabl= e, consider the case of a client that needs to use an enterprise identity to gain access to a cloud service. In many c= ases, corporate policy demands that a client use an identity managed by the= organization. This means that the client should obtain an assertion from a= n enterprise identity provider (Active Directory, Tivoli, etc.) and use that assertion to obtain an access token = which grants access to various web service APIs. Many of our key MSFT custo= mers and internal partner teams rely on this mechanism and reverting exclus= ively to username/pwd isn’t an option for us.

 

'OAuth2' HTTP Authentication Scheme:  Si= mply put, dropping this seems like a huge step away from interoperability.&= nbsp; As one data point, Microsoft implements this in our WIF OAuth2 protec= ted resource code.  All up, clients need a way to authenticate to the protected resource.  Also, existing WRAP imple= mentations need this functionality to migrate to OAuth2.   For al= l these reasons, we support retaining this functionality in OAuth2.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thanks,

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

 

--_000_180155C5EA10854997314CA5E063D18F0338AC7BTK5EX14MBXC113r_-- From tonynad@microsoft.com Tue Jan 18 09:42:15 2011 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 151DD3A6E78 for ; Tue, 18 Jan 2011 09:42:15 -0800 (PST) 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=[AWL=-0.000, 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 mP9FPDEwpFJ0 for ; Tue, 18 Jan 2011 09:42:01 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 5185928C0F1 for ; Tue, 18 Jan 2011 09:42:01 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 18 Jan 2011 09:44:27 -0800 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.87]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Tue, 18 Jan 2011 09:44:27 -0800 From: Anthony Nadalin To: Brian Campbell , OAuth WG Thread-Topic: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 Thread-Index: AQHLsmsb68xFvwfGDEq1IxNzmcfY55PN+HsAgABh3QCABrRVgIAB+wtA Date: Tue, 18 Jan 2011 17:44:26 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F0338AC97@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB77D4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D2E17C2.60205@lodderstedt.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18F0338AC97TK5EX14MBXC113r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17 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, 18 Jan 2011 17:42:15 -0000 --_000_180155C5EA10854997314CA5E063D18F0338AC97TK5EX14MBXC113r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also support option #1 From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of B= rian Campbell Sent: Sunday, January 16, 2011 7:29 PM To: OAuth WG Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - = Vote by 1/17 I guess I'm in the minority but I prefer option #1. I do agree with others that naming with respect to authenticated vs. unauth= enticated clients is likely problematic. On Wed, Jan 12, 2011 at 2:06 PM, Torsten Lodderstedt > wrote: +1 for option 2 because it will facilitates security analysis of the protoc= ol. >From a security analysis perspective, I think we need two views: 1) A structural view, describing the OAuth architecture (entities, interfac= es, communication paths) and 2) a flow-oriented view, which is built based on this interfaces, this is w= here the more complex threats show up. For example, the session fixation at= tack makes use of properties of the flow along both OAuth end-points. I assume a structural view will given as well? I agree with Marius regarding naming. I don't believe we can forsee today w= hich clients will be authenticated in the future and which not. I could ima= gine deployments with support for web applications w/o authentication. It d= epends on the security policy and the value someone sees in client authenti= cation (for the purpose of client authorization). On the other hand, by usi= ng dynamically created client_ids and secrets, even native apps could authe= nticate to the authorization server. regards, Torsten. Am 12.01.2011 16:15, schrieb Richer, Justin P.: Marius makes a good point -- we probably want to avoid using language like = that for part descriptions. I don't think "code" and "token" quite get it, = but I don't have a better suggestion at the moment though... -- Justin ________________________________________ From: Marius Scurtescu [mscurtescu@google.com= ] Sent: Wednesday, January 12, 2011 10:10 AM To: Richer, Justin P. Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - = Vote by 1/17 +1 for option 2 as well Not convinced that naming the main flows Authenticated and Unauthenticated makes sense, I think it will only increase confusion. For example, native apps are not authenticated and they would be using the "Authenticated" flow. I think we should stick with something along the lines of "Code" and "Token". Marius On Wed, Jan 12, 2011 at 10:02 AM, Richer, Justin P.> wrote: +1 for option 2 I see, and have always seen, the target audience as server and client devel= opers who are likely to be working against one flow and use case at a time.= Also, I disagree that the primary role of the server developer is the secu= rity considerations. In theory, you may be right, but in practice, I think = you'll find that many are going to be more concerned with just making it wo= rk at all with their API/framework/server. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@= ietf.org] On Behalf Of Eran Hammer-Lahav [er= an@hueniverse.com] Sent: Wednesday, January 12, 2011 2:19 AM To: OAuth WG Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote= by 1/17 (Vote at the end, please read) Background Between draft -00 and -05 the document used a flow-based organization. This= was changed to an endpoint-based organization in draft -06. I have receive= d requests to go back to the flow-based organization, and with -12, have be= en planning to do that. It is important to note that -12 is not meant to in= clude any change in normative language and that -11 code would remain uncha= nged under -12. This is purely editorial. Part of that effort included reviewing the various flows in -05. The flow c= ategories and definitions have always been a source of confusion. Some targ= et specific client architecture (user-agent, web server, device), some are = abstractions for future extensibility (assertion), and some are useful fea= tures that can apply to a wide range of clients (client credentials, userna= me and password). We also have the odd anti-profile of the native applicati= on flow, which in practice is a half-baked guide to navigating the entire r= ange of flows. In practice we have a few ways to get an access token which can be categori= zed in multiple ways: 1. How authorization is obtained? a. Redirection-based - user-agent, web-server b. Direct credentials - client credentials, username and password, ass= ertion 2. Is the client authenticated? a. Yes - web-server, client credentials, username and password, asser= tion (based on type) b. No - user-agent, assertion (based on type) In the past we had another (broken) organization of User delegation, User c= redentials, and Autonomous. Analysis After studying the document and breaking it apart (in my editor) I came to = a few conclusions (which you are invited to disprove): 1. Flow names must be consistent and based on the key differentiator = of each flow. I believe the ability of the client to authenticate is the mo= st significant aspect of each flow. I agree that ease of deployment and per= formance are important, but this is a security protocol and the security co= nsiderations should be the primary attribute used to select flows. 2. The endpoint-based organization turned a few discrete flows into a= single protocol. This protocol should be profiled based on some key client= characteristics (such as redirection and ability of the client to authenti= cate). The main objective of the profiles would be to provide a security-fo= cused description. 3. The hybrid flow, combining the user-agent and web-server into a co= de-and-token solution is a distinct profile with its own unique security pr= operties. While its implementation details are important for efficiency, th= e main differentiator is the client dual nature of being able to maintain s= ecret credentials in some parts, but not in others. It produces two access = tokens using a single authorization and client identifier. 4. The document must not repeat the mistake of 1.0, focusing on a sin= gle client type at the expense of others. OAuth 1.0 focused on the web-serv= er flow and treated everything else as second class citizens. -05 treated n= ative applications similarly, giving much more attentions to the web-server= and user-agent clients, even when their underlying flows could have been w= ritten primarily for some native applications. The issue is mostly in namin= g the profiles after one typical client type instead of their key property. Options I came up with two options for finalizing the specification's structure (pl= ease feel to suggest additional ideas): 1. Keep the document's endpoint-based organization (-11) and add a Cl= ient Profiles section describing specific client implementations based on t= he protocol. These profiles will not include wire information (parameters, = values, etc.), but will include security-minded normative language (MUST re= gister, SHOULD match redirection URI, etc.). 2. Switch back to flow-based organization and include 5 flows in 2 gr= oups (note the new names), plus extensions: a. Redirection-based i. Authe= nticated client (web server) ii. Unauth= enticated client (user-agent) iii. Mix au= thentication client (code-and-token) b. Direct Credentials i. Usern= ame and password ii. Client= credentials c. Extensions Option 1 - Easier for server developers because it will include all the wir= e-protocol details for each endpoint in one place (single list of parameter= s, error codes, etc.). - Shorter, no repeating the same examples, parameters, and error d= efinitions for each flow. - Reads like a reference. - Client developers are instructed which parameter values to use. - Server developer focus helps make security-based decisions (whic= h are primarily the role of the server developer in OAuth). Option 2 - Easier for client developers focused on one flow at a time. - Longer, duplicating examples, parameters, and error definitions.= Currently about 20-30 more pages. - Reads like a narrative / tutorial. - Client developers are instructed which client flow to use. - Client developer focus helps novice developers interoperate with= protected resources. I don't believe there is an obvious winner here because we each have a bias= based on who we believe is the primary target audience (after all, this is= a purely editorial decision - the protocol itself is mostly complete). In = addition, I have done 80% of the work to get -12 to option 2 so it is no lo= nger about investing the time in the transition. Vote Given the stable state of the specification, this might be the last big dec= ision we get to make about the main specification. I've been planning to ju= st come up with a new draft and ask for feedback but I rather take another = week and ask this explicitly. Which option do you prefer (or suggest another)? Please reply with your preference by 1/17. 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 --_000_180155C5EA10854997314CA5E063D18F0338AC97TK5EX14MBXC113r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also support option #1<= o:p>

 <= /p>

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Sunday, January 16, 2011 7:29 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Fl= ows) - Vote by 1/17

 

I guess I'm in the mi= nority but I prefer option #1. 

I do agree with others that naming with respect to authenticated vs. unauth= enticated clients is likely problematic.

On Wed, Jan 12, 2011 at 2:06 PM, Torsten Lodderstedt= <torsten@lodderstedt.net= > wrote:

+1 for option 2 because it will facilitates secu= rity analysis of the protocol.

>From a security analysis perspective, I think we need two views:
1) A structural view, describing the OAuth architecture (entities, interfac= es, communication paths) and
2) a flow-oriented view, which is built based on this interfaces, this is w= here the more complex threats show up. For example, the session fixation at= tack makes use of properties of the flow along both OAuth end-points.

I assume a structural view will given as well?

I agree with Marius regarding naming. I don't believe we can forsee today w= hich clients will be authenticated in the future and which not. I could ima= gine deployments with support for web applications w/o authentication. It d= epends on the security policy and the value someone sees in client authentication (for the purpose of client= authorization). On the other hand, by using dynamically created client_ids= and secrets, even native apps could authenticate to the authorization serv= er.

regards,
Torsten.

Am 12.01.2011 16:15, schrieb Richer, Justin P.:

 

Marius makes a good point -- we probably want to avo= id using language like that for part descriptions. I don't think "code= " and "token" quite get it, but I don't have a better sugges= tion at the moment though...

 -- Justin
________________________________________
From: Marius Scurtescu [mscurtescu@google.com]
Sent: Wednesday, January 12, 2011 10:10 AM
To: Richer, Justin P.
Cc: Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - = Vote by 1/17

+1 for option 2 as well

Not convinced that naming the main flows Authenticated and
Unauthenticated makes sense, I think it will only increase confusion.
For example, native apps are not authenticated and they would be using
the "Authenticated" flow. I think we should stick with something = along
the lines of "Code" and "Token".

Marius



On Wed, Jan 12, 2011 at 10:02 AM, Richer, Justin P.<jricher@mitre.org>  wrote:

+1 for option 2
I see, and have always seen, the target audience as server and client devel= opers who are likely to be working against one flow and use case at a time.= Also, I disagree that the primary role of the server developer is the secu= rity considerations. In theory, you may be right, but in practice, I think you'll find that many are going= to be more concerned with just making it work at all with their API/framew= ork/server.

 -- Justin
________________________________________
From: oauth-bou= nces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav [eran@hueniverse.com]
Sent: Wednesday, January 12, 2011 2:19 AM
To: OAuth WG
Subject: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote=     by 1/17

(Vote at the end, please read)

Background

Between draft -00 and -05 the document used a flow-based organization. This= was changed to an endpoint-based organization in draft -06. I have receive= d requests to go back to the flow-based organization, and with -12, have be= en planning to do that. It is important to note that -12 is not meant to include any change in normative language = and that -11 code would remain unchanged under -12. This is purely editoria= l.

Part of that effort included reviewing the various flows in -05. The flow c= ategories and definitions have always been a source of confusion. Some targ= et specific client architecture (user-agent, web server, device), some are = abstractions for future extensibility (assertion),  and some are useful features that can apply to a wide r= ange of clients (client credentials, username and password). We also have t= he odd anti-profile of the native application flow, which in practice is a = half-baked guide to navigating the entire range of flows.

In practice we have a few ways to get an access token which can be categori= zed in multiple ways:


1.       How authorization is obtained?

a.       Redirection-based – user-agent, web-server
b.      Direct credentials – client credentials, usern= ame and password, assertion

2.       Is the client authenticated?

a.       Yes – web-server, client credentials, usernam= e and password, assertion (based on type)

b.      No – user-agent, assertion (based on type)

In the past we had another (broken) organization of User delegation, User c= redentials, and Autonomous.

Analysis

After studying the document and breaking it apart (in my editor) I came to = a few conclusions (which you are invited to disprove):


1.       Flow names must be consistent and based on the key = differentiator of each flow. I believe the ability of the client to authent= icate is the most significant aspect of each flow. I agree that ease of dep= loyment and performance are important, but this is a security protocol and the security considerations should be the prima= ry attribute used to select flows.

2.       The endpoint-based organization turned a few discre= te flows into a single protocol. This protocol should be profiled based on = some key client characteristics (such as redirection and ability of the cli= ent to authenticate). The main objective of the profiles would be to provide a security-focused description.

3.       The hybrid flow, combining the user-agent and web-s= erver into a code-and-token solution is a distinct profile with its own uni= que security properties. While its implementation details are important for= efficiency, the main differentiator is the client dual nature of being able to maintain secret credentials in some parts, bu= t not in others. It produces two access tokens using a single authorization= and client identifier.

4.       The document must not repeat the mistake of 1.0, fo= cusing on a single client type at the expense of others. OAuth 1.0 focused = on the web-server flow and treated everything else as second class citizens= . -05 treated native applications similarly, giving much more attentions to the web-server and user-agent clients, even when t= heir underlying flows could have been written primarily for some native app= lications. The issue is mostly in naming the profiles after one typical cli= ent type instead of their key property.

Options

I came up with two options for finalizing the specification’s structu= re (please feel to suggest additional ideas):


1.       Keep the document’s endpoint-based organizati= on (-11) and add a Client Profiles section describing specific client imple= mentations based on the protocol. These profiles will not include wire info= rmation (parameters, values, etc.), but will include security-minded normative language (MUST register, SHOULD match redirectio= n URI, etc.).

2.       Switch back to flow-based organization and include = 5 flows in 2 groups (note the new names), plus extensions:

a.       Redirection-based

                     = ;                     &nb= sp;                   i.  = ;    Authenticated client (web server)

                     = ;                     &nb= sp;                 ii.   &nbs= p;  Unauthenticated client (user-agent)

                     = ;                     &nb= sp;                iii.   &nbs= p;  Mix authentication client (code-and-token)

b.      Direct Credentials

                     = ;                     &nb= sp;                   i.  = ;    Username and password

                     = ;                     &nb= sp;                 ii.   &nbs= p;  Client credentials

c.       Extensions

Option 1

-          Easier for server developers because it= will include all the wire-protocol details for each endpoint in one place = (single list of parameters, error codes, etc.).

-          Shorter, no repeating the same examples= , parameters, and error definitions for each flow.

-          Reads like a reference.

-          Client developers are instructed which = parameter values to use.

-          Server developer focus helps make secur= ity-based decisions (which are primarily the role of the server developer i= n OAuth).

Option 2

-          Easier for client developers focused on= one flow at a time.

-          Longer, duplicating examples, parameter= s, and error definitions. Currently about 20-30 more pages.

-          Reads like a narrative / tutorial.

-          Client developers are instructed which = client flow to use.

-          Client developer focus helps novice dev= elopers interoperate with protected resources.

I don’t believe there is an obvious winner here because we each have = a bias based on who we believe is the primary target audience (after all, t= his is a purely editorial decision – the protocol itself is mostly co= mplete). In addition, I have done 80% of the work to get -12 to option 2 so it is no longer about investing the time in= the transition.

Vote

Given the stable state of the specification, this might be the last big dec= ision we get to make about the main specification. I’ve been planning= to just come up with a new draft and ask for feedback but I rather take an= other week and ask this explicitly.

Which option do you prefer (or suggest another)?

Please reply with your preference by 1/17.

EHL







_______________________________________________
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


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

 

--_000_180155C5EA10854997314CA5E063D18F0338AC97TK5EX14MBXC113r_-- From eran@hueniverse.com Tue Jan 18 10:02:56 2011 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 B983A3A6FE2 for ; Tue, 18 Jan 2011 10:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 mEzn3xQkbUV7 for ; Tue, 18 Jan 2011 10:02:55 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A361A3A7050 for ; Tue, 18 Jan 2011 10:02:54 -0800 (PST) Received: (qmail 22767 invoked from network); 18 Jan 2011 17:50:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Jan 2011 17:50:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 18 Jan 2011 10:50:01 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin , "Richer, Justin P." , OAuth WG Date: Tue, 18 Jan 2011 10:49:57 -0700 Thread-Topic: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials Thread-Index: AQHLtl1nSm3qABc5GUyMqtbd/Xypq5PW/OGwgAAGYDA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5D35F55@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F0338ABF3@TK5EX14MBXC113.redmond.corp.microsoft.com> In-Reply-To: <180155C5EA10854997314CA5E063D18F0338ABF3@TK5EX14MBXC113.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials 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, 18 Jan 2011 18:02:56 -0000 So does requiring the parameter-based approach which has identical security= properties. We need to require at least one, and we already know some will= not deploy Basic. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Tuesday, January 18, 2011 9:28 AM > To: Richer, Justin P.; Eran Hammer-Lahav; OAuth WG > Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client > Credentials >=20 > Concern here is that HTTP Basic Auth provides a straightforward interop > profile for the web server profile >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Richer, Justin P. > Sent: Monday, January 17, 2011 7:43 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client > Credentials >=20 > +1 to making BASIC optional. I don't think we were going to be supporting= it > in general, either. >=20 > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran > Hammer-Lahav [eran@hueniverse.com] > Sent: Saturday, January 15, 2011 1:53 AM > To: OAuth WG > Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client > Credentials >=20 > OAuth 2.0 provides two methods for client authentication using password > credentials: request parameters and HTTP Basic authentication. I suggest = we > drop the requirement to support HTTP Basic authentication, and only > mention it as an example for alternative methods. My reasons are: >=20 >=20 > 1. A few providers have expressed concerns over the need to support > Basic authentication, and some explicitly said they will not support it. > Parameter-based authentication, OTOH, is widely deployed in 2.0. >=20 > 2. Due to the way OAuth is being implemented at the HTTP authentica= tion > layer (even if it is wrong), can conflict within the framework as both a > consumer and provider of authentication components. >=20 > 3. The mapping between username and client_id, while not complicate= d, > is still a big awkward, and can be confusing when combined with the > username and password grant type. On the other hand, the use of client_id > in the end-user authorization endpoint lends itself nicely to the use of = the > same parameter elsewhere. >=20 > 4. Some existing authentication frameworks will have an issue handl= ing > the mix of Basic authentication and parameters authentication due to how > each is deployed. In cases where a front gate handles Basic, it will be h= ard to > let requests through for parameter processing. >=20 > Comments? Counter-arguments? >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Jan 18 10:05:05 2011 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 311FD3A6FE2 for ; Tue, 18 Jan 2011 10:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 s0G58U6Ge2ed for ; Tue, 18 Jan 2011 10:05:04 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 11BD73A6F0B for ; Tue, 18 Jan 2011 10:05:04 -0800 (PST) Received: (qmail 4284 invoked from network); 18 Jan 2011 17:47:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Jan 2011 17:47:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 18 Jan 2011 10:47:16 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Tue, 18 Jan 2011 10:47:11 -0700 Thread-Topic: draft-hammer-oauth-v2-mac-token-01 Thread-Index: Acu3NxdMxx9i5WNYSWiPF6ae1WUz4Q== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5D35F52@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-01 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, 18 Jan 2011 18:05:05 -0000 UHVibGlzaGVkIC0wMSB3aXRoIHRoZSBmb2xsb3dpbmcgY2hhbmdlczoNCg0KLSBDaGFuZ2VkIHBh cmFtZXRlcnMgc29ydGluZyB0byBjb21lIGFmdGVyIG5hbWU9dmFsdWUgc3RyaW5nIGNvbnN0cnVj dGlvbi4NCi0gQWRkZWQgbmV3IGxpbmUgYXQgdGhlIGVuZCBvZiB0aGUgbm9ybWFsaXplZCByZXF1 ZXN0IHN0cmluZy4NCi0gTW92ZWQgT0F1dGgyIHJlZmVyZW5jZXMgdG8gc2VwYXJhdGUgc2VjdGlv bi4NCi0gQWRkZWQgJ1dXVy1BdXRoZW50aWNhdGUnIGhlYWRlciBkZWZpbml0aW9uLg0KLSBGaXhl ZCBleGFtcGxlIGhlYWRlciB1c2Ugb2Ygc2luZ2xlIHF1b3RlLg0KLSBSZXN0cmljdGVkIHN0cmlu Z3MgdG8gQVNDSUkgc3Vic2V0IChwcmludGFibGUsIG5vIGRvdWJsZS1xdW90ZXMgb3IgYmFjay1z bGFzaCkuDQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhhbW1lci1vYXV0aC12 Mi1tYWMtdG9rZW4NCg0KSW1wbGVtZW50YXRpb24gaXMgYXZhaWxhYmxlIGZvciBOb2RlLmpzOg0K DQpodHRwczovL2dpdGh1Yi5jb20vdGhlUmF6b3JCbGFkZS9jb25uZWN0LWF1dGgvYmxvYi9tYXN0 ZXIvbGliL2F1dGguc3RyYXRlZ2llcy9odHRwL21hYy5qcw0KDQpVc2VyLWFnZW50IGNsaWVudCBj b2RlIGV4YW1wbGUgY29taW5nIHNob3J0bHkgKGFzIHNvb24gYXMgSSBjbGVhbiBpdCB1cCkuDQoN CkZlZWRiYWNrIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQoNCkVITA0K From eran@hueniverse.com Tue Jan 18 10:26:29 2011 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 74D113A7070 for ; Tue, 18 Jan 2011 10:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.049, 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 pjTkxZu4nZut for ; Tue, 18 Jan 2011 10:26:20 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E0DA43A6FE2 for ; Tue, 18 Jan 2011 10:26:19 -0800 (PST) Received: (qmail 18210 invoked from network); 18 Jan 2011 18:12:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Jan 2011 18:12:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 18 Jan 2011 11:12:47 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Tue, 18 Jan 2011 11:12:42 -0700 Thread-Topic: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme Thread-Index: Acu3NiSHXpF3O14eTPqlwk2IwSAdgAAArk0w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5D35F61P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 18 Jan 2011 18:26:29 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5D35F61P3PW5EX1MB01E_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree that at this stage, we should do our best to avoid making breaking = changes. But first, we need to establish what is going to break and how. The argument that removing the client assertion credentials affects interop= erability or breaks implementations is without merit. As currently specified, the text is useless for any level of interoperabili= ty or implementation. This means you must have your own specification provi= ding the actual meaningful information. At most, removing this section will= require you to register the two parameter names it defines. Since neither = is being used for a new purpose, removing this section creates no conflict.= Hopefully, your parameter registration will provide more meaningful inform= ation about them than currently offered. If you are going to object to my conclusions, you first need to show where = my arguments are wrong. I have seen nothing to contradict a single point I = have made about both issues. This goes for both the client assertion creden= tials and OAuth2 scheme. Just in case, I'll repeat my points. Client assertion credentials: 1. The mechanism is under specified, especially in its handling of the cl= ient_id identifier (when used to obtain end-user authorization). 2. It does not contain any implementation details to accomplish any level= of interoperability or functionality. 3. The section is a confused mix of security considerations sprinkled wit= h normative language. 4. Those who still want to advocate for it need to show not only consensu= s for keeping it, but also active community support for deploying it. Deplo= yment, of course, will also require showing progress on public specificatio= ns profiling the mechanism into a useful interoperable feature. Which open = source library supports or plan to support it? 'OAuth2' WWW-Authenticate header: 1. Draft oauth-v2 is clearly not an authentication protocol. It *utilizes= * client authentication. It offers one fully defined method for client auth= entication (which is basically HTTP Basic+), provides a half-baked client a= ssertion authentication hook, and leaves all end-user authentication out of= scope. 2. The WWW-Authenticate header has absolutely no value, interoperability-= wise or otherwise. Discovery was rules to be beyond the scope of this speci= fication. Having a protected resource declare it supports authentication us= ing some unspecified credentials obtained using some unspecified client flo= w is confusing at best. 3. OAuth is agnostic to token authentication, and we already have three d= iscrete token type proposals - all with active deployment plans in the comi= ng months. 4. HTTP *authentication* is not an appropriate facility to negotiate *aut= horization*. OAuth authorization discovery can be added to HTTP authenticat= ion schemes as attributes, but makes no sense as a scheme of its own. The i= ssues we are having with 'realm' is one of the examples showing that we are= abusing the header. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Tuesday, January 18, 2011 9:36 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP= Authentication Scheme Having spoken to a number of people implementing the spec here, I've encoun= tered strong objections to removing Client Assertion Credentials and the OA= uth2 HTTP Authentication Scheme. It's also not clear to me why we would ma= ke substantial breaking changes to the specification when it is essentially= ready for approval. I've summarized the reasons I believe we should keep = these two features below. Client Assertion Credentials: Many of the scenarios we care about require = this capability. They were key motivators for the Assertion Profile in WRAP= (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have ru= nning code that requires this support. For example, the Azure Access Contro= l Service is a cloud Authorization server that supports several protocols, = including parts of OAuth 2.0 draft 10 (autonomous and web server profiles).= We are happy to update our implementation to subsequent drafts & agree tha= t the spec leaves a lot of ambiguity. In our implementation of the autonomous and web server profiles, ACS allows= clients to authenticate using a signed assertion as well as with a usernam= e/password. The username/pwd option is for clients that don't mind sending = credentials over the wire, while the signed assertion mechanism is for clie= nts that are more reticent to send raw credentials and for scenarios where = it isn't possible. To illustrate an example where username/pwd isn't viable= , consider the case of a client that needs to use an enterprise identity to= gain access to a cloud service. In many cases, corporate policy demands th= at a client use an identity managed by the organization. This means that th= e client should obtain an assertion from an enterprise identity provider (A= ctive Directory, Tivoli, etc.) and use that assertion to obtain an access t= oken which grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and reverting e= xclusively to username/pwd isn't an option for us. 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. Thanks, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E723445A5D35F61P3PW5EX1MB01E_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree that at this stage, we should do our best to avoid ma= king breaking changes. But first, we need to establish what is going to bre= ak and how.

 

The argument that removing the client assertion credentials af= fects interoperability or breaks implementations is without merit.

 =

As curr= ently specified, the text is useless for any level of interoperability or i= mplementation. This means you must have your own specification providing th= e actual meaningful information. At most, removing this section will requir= e you to register the two parameter names it defines. Since neither is bein= g used for a new purpose, removing this section creates no conflict. Hopefu= lly, your parameter registration will provide more meaningful information a= bout them than currently offered.

 

If you are going to object to my conclus= ions, you first need to show where my arguments are wrong. I have seen noth= ing to contradict a single point I have made about both issues. This goes f= or both the client assertion credentials and OAuth2 scheme.

 <= /span>

Just in case, = I’ll repeat my points.

 

= Client assertion credentials:

 <= /span>

  1. The mechanism is under= specified, especially in its handling of the client_id identifier (when us= ed to obtain end-user authorization).
  2. It does not contain any imp= lementation details to accomplish any level of interoperability or function= ality.
  3. The section is a confused mix of security considerations s= prinkled with normative language.
  4. Those who still want to advocat= e for it need to show not only consensus for keeping it, but also active co= mmunity support for deploying it. Deployment, of course, will also require = showing progress on public specifications profiling the mechanism into a us= eful interoperable feature. Which open source library supports or plan to s= upport it?

 

‘OAuth2’ WWW-Authenticate header:<= /p>

 

  1. Draft oauth-v2 is clearly= not an authentication protocol. It *utilizes* client authentication= . It offers one fully defined method for client authentication (which is ba= sically HTTP Basic+), provides a half-baked client assertion authentication= hook, and leaves all end-user authentication out of scope.
    2. =
  2. The W= WW-Authenticate header has absolutely no value, interoperability-wise or ot= herwise. Discovery was rules to be beyond the scope of this specification. = Having a protected resource declare it supports authentication using some u= nspecified credentials obtained using some unspecified client flow is confu= sing at best.
  3. OAuth is agnostic to token authentication, and we = already have three discrete token type proposals – all with active de= ployment plans in the coming months.
  4. HTTP *authentication*= is not an appropriate facility to negotiate *authorization*. OAuth = authorization discovery can be added to HTTP authentication schemes as attr= ibutes, but makes no sense as a scheme of its own. The issues we are having= with ‘realm’ is one of the examples showing that we are abusin= g the header.

 

EHL

 

 

 

<= p class=3DMsoNormal>From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Tuesday, January 18, 2011 9:36 AM
To: Eran Hammer-L= ahav
Cc: oauth@ietf.org
Subject: Reasons not to remove = Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

 

Having spoken to a number of people implementing the spec here= , I’ve encountered strong objections to removing Client Assertion Cre= dentials and the OAuth2 HTTP Authentication Scheme.  It’s also n= ot clear to me why we would make substantial breaking changes to the specif= ication when it is essentially ready for approval.  I’ve summari= zed the reasons I believe we should keep these two features below.

 

Cli= ent Assertion Credentials:  Many of the scenarios we care about re= quire this capability. They were key motivators for the Assertion Profile i= n WRAP (see =A7 5.2), have been part of OAuth 2 for quite a while, and we h= ave running code that requires this support. For example, the Azure Access = Control Service is a cloud Authorization server that supports several proto= cols, including parts of OAuth 2.0 draft 10 (autonomous and web server prof= iles). We are happy to update our implementation to subsequent drafts &= agree that the spec leaves a lot of ambiguity.

 

In our implementation of = the autonomous and web server profiles, ACS allows clients to authenticate = using a signed assertion as well as with a username/password. The username/= pwd option is for clients that don’t mind sending credentials over th= e wire, while the signed assertion mechanism is for clients that are more r= eticent to send raw credentials and for scenarios where it isn’t poss= ible. To illustrate an example where username/pwd isn’t viable, consi= der the case of a client that needs to use an enterprise identity to gain a= ccess to a cloud service. In many cases, corporate policy demands that a cl= ient use an identity managed by the organization. This means that the clien= t should obtain an assertion from an enterprise identity provider (Active D= irectory, Tivoli, etc.) and use that assertion to obtain an access token wh= ich grants access to various web service APIs. Many of our key MSFT custome= rs and internal partner teams rely on this mechanism and reverting exclusiv= ely to username/pwd isn’t an option for us.

 

'OAuth2' HTTP Authen= tication Scheme:  Simply put, dropping this seems like a huge step= away from interoperability.  As one data point, Microsoft implements = this in our WIF OAuth2 protected resource code.  All up, clients need = a way to authenticate to the protected resource.  Also, existing WRAP = implementations need this functionality to migrate to OAuth2.   F= or all these reasons, we support retaining this functionality in OAuth2.

 

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

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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5D35F61P3PW5EX1MB01E_-- From torsten@lodderstedt.net Tue Jan 18 11:55:47 2011 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 80F583A6E5D for ; Tue, 18 Jan 2011 11:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.014, 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 eW6hLqrzUaw1 for ; Tue, 18 Jan 2011 11:55:46 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by core3.amsl.com (Postfix) with ESMTP id 94B633A6F02 for ; Tue, 18 Jan 2011 11:55:45 -0800 (PST) Received: from [79.253.55.161] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PfHh7-0006PR-77; Tue, 18 Jan 2011 20:58:21 +0100 Message-ID: <4D35F0DF.3000702@lodderstedt.net> Date: Tue, 18 Jan 2011 20:58:23 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Richer, Justin P." References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET>, <4D333EE9.1030706@lodderstedt.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters 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, 18 Jan 2011 19:55:47 -0000 Justin, WRT 401 - just think of the AS as a RS for tokens. An (ordinary) RS would probably return 401 with WWW-Autenticate MAC/BEARER/OAUTH2 carrying the ASs tokens endpoint URI. Or the client knows the AS URI at development time (more likely these days). The client now makes an unauthorized request to this URI and the AS responds with another 401 and a set of WWW-Authenticate headers as shown in my posting. regards, Torsten. Am 17.01.2011 16:55, schrieb Richer, Justin P.: > I absolutely don't want to drop credentials being passed as parameters. I think that's more widely deployed than using the BASIC style auth as well. > > I do think that Torsten's approach below has a certain elegance to it, but it would require deeper access to queries that not all deployment frameworks allow (or at least, make easy to access). For part 3 below, it's usually the PR and not the AS that's returning the 401, so this would require the PR to know what kinds of things the AS will accept. Right now, the client needs to know that, which I think is more reasonable. > > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt [torsten@lodderstedt.net] > Sent: Sunday, January 16, 2011 1:54 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Removal: credential body parameters > > Hi Eran, > > you made some good points and I agree with most of your analysis. The way we use BASIC in the current draft is not perfect, mainly because it is a compromise. It was basically the attempt to be more HTTP compliant while still supporting the parameter-based approach. > > I would strongly object against removing BASIC and relying on body parameters, only. We (Deutsche Telekom) have implemented that scheme and do not see a real problem with it. > > In order to overcome the problems you listed, I would like to propose an alternative approach. > > I would suggest to drop support for passing any credentials to the tokens endpoint in the body of the POST request. Instead, I would suggest to define one HTTP authentication scheme per grant type and send the corresponding parameters within the Authorization header. > > Conceptually, the tokens endpoint is a resource URI clients use to obtain tokens. The expected token scope can be explicitely specified by the corresponding URI query parameter. So the simplest, complete request to obtain a token could look as follows: > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > scope=something > > Most authorization servers will certainly need credentials of some kind as pre-requisite for token issuance. These credentials actually authenticate the resource owner and the client to the authorization server as well as prove the client's authorization to get the token. Such credentials are usually passed using authorization headers in HTTP requests. > > Let's take the example of the grant type "code". We could define a scheme "CODE", which carries the parameters code, redirect_uri, client_id and client_secret (optionally) as named values. An example request could look as follows > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: CODE code='i1WsRn1uB1', > redirect_uri='https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb', > client_id='s6BhdRkqt3', > client_secret='gX1fBat3bV' > > scope=something > > The following examples illustrate the approach with respect to the grant types "password" and "refresh_token", respectively. > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: PWD username='johndoe', > password='A3ddj3w', > client_id='s6BhdRkqt3', > client_secret='gX1fBat3bV' > > scope=something > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: REFRESH token='n4E9O119d', > client_id='s6BhdRkqt3', > client_secret='gX1fBat3bV' > > scope=something > > I see the following advantages: > 1) The suggest approach is aligned with HTTP. So instead of using HTTP as "transport protocol" only (as in the dark times of SOAP), we could make better use of the existing framework for messaging, caching, and security. > > 2) Since the proposed approach is alligned with HTTP authentication and authorization in general, it would be an easy task to add support for additional, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or GBA to an OAuth authorization server. > > 3) WWW-Authenticate headers could be used to provide clients with useful information about the capabilities of the authorization server. In the following example, the server reacts to an unauthenticated request with the following response > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: CODE uri="tokenservice.example.com/authorize" > WWW-Authenticate: PWD realm='users.example.com' > WWW-Authenticate: REFRESH > > which indicates its support for the grant types authorization_code, username/password and refresh token. Additionally it provides the client with the end-user endpoint URI of the authorization server and the user realm supported for password authentication. > > 4) The proposed mechanism should work nicely with existing authentication frameworks, since we would no longer use a mixed model for passing credentials and dedicated HTTP authentication schemes. > > What do you think? What do others think? > > regards, > Torsten. > > > Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav: > OAuth 2.0 provides two methods for client authentication using password credentials: request parameters and HTTP Basic authentication. I suggest we drop the requirement to support HTTP Basic authentication, and only mention it as an example for alternative methods. My reasons are: > > > 1. A few providers have expressed concerns over the need to support Basic authentication, and some explicitly said they will not support it. Parameter-based authentication, OTOH, is widely deployed in 2.0. > > 2. Due to the way OAuth is being implemented at the HTTP authentication layer (even if it is wrong), can conflict within the framework as both a consumer and provider of authentication components. > > 3. The mapping between username and client_id, while not complicated, is still a big awkward, and can be confusing when combined with the username and password grant type. On the other hand, the use of client_id in the end-user authorization endpoint lends itself nicely to the use of the same parameter elsewhere. > > 4. Some existing authentication frameworks will have an issue handling the mix of Basic authentication and parameters authentication due to how each is deployed. In cases where a front gate handles Basic, it will be hard to let requests through for parameter processing. > > Comments? Counter-arguments? > > EHL > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From gabriel@poken.com Tue Jan 18 11:43:52 2011 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 AA9763A6E7B for ; Tue, 18 Jan 2011 11:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 khm9W1E442J9 for ; Tue, 18 Jan 2011 11:43:51 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 52BD63A6E5D for ; Tue, 18 Jan 2011 11:43:51 -0800 (PST) Received: by wwa36 with SMTP id 36so6475065wwa.13 for ; Tue, 18 Jan 2011 11:46:28 -0800 (PST) Received: by 10.227.141.197 with SMTP id n5mr6071430wbu.100.1295379861079; Tue, 18 Jan 2011 11:44:21 -0800 (PST) Received: from [10.10.1.200] (62-2-189-3.static.cablecom.ch [62.2.189.3]) by mx.google.com with ESMTPS id s9sm3912553wby.4.2011.01.18.11.44.19 (version=SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 11:44:20 -0800 (PST) From: Gabriel Klein To: oauth@ietf.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 18 Jan 2011 20:44:12 +0100 Message-ID: <1295379852.16479.60.camel@GabLap> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: [OAUTH-WG] OAuth2 chain 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, 18 Jan 2011 19:56:14 -0000 Dear oAuth2 team, I'm currently working on the way we will implement oAuth2 in our company. (Poken.com) I've an interesting flow to work on: We delegate the account creation and account authentication mechanism to an external oAuth2 provider. What it means: We have a mobile application, you can choose the way you want to login. - User and Password - Facebook (Microsoft, Google, Twitter, and other oAuth2 provider later) Based on the facebook access_token or code, we return a poken access_token. We have a similar flow in our web application (is on top of our API). >From a technical point: When we login using Facebook, we get the "code" or access_token (linked to our client_id access on Facebook). This part is the responsibility of the UI/mobile application. Facebook client_secret is not shared with Facebook. The mobile application then call our API. (Not implemented yet) https://api.poken.com/oauth2/authorize? grant_type=poken_extenal_oauth2& service=facebook.com& service_secret={facebook_access_token or code}& client_id={appid-phphub}&client_secret={apppass-phphub}& response_type = token In our API we exchange the facebook code for a facebook access_token and get the facebook_account_id of the user on Facebook. If this facebook_account_id is linked to a poken account on our system, we return a poken access_token for this account. With this access_token, the client can use our API. I call this flow "oAuth2 Chain Flow" I think it's a quite interesting flow, because it's more and more frequent to delegate the authentication to another website/service. (Even more when you are not part of the biggest sites.) What do you think of this aspect of authentication? Did you already spoke about this flow? Do we have some specifications for this flow? Best regards, Gabriel Klein (poken.com) From fcorella@pomcor.com Tue Jan 18 12:24:06 2011 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 C6AC028C117 for ; Tue, 18 Jan 2011 12:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.213, 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 X5QDeqmrCZUK for ; Tue, 18 Jan 2011 12:24:05 -0800 (PST) Received: from nm19.bullet.mail.ac4.yahoo.com (nm19.bullet.mail.ac4.yahoo.com [98.139.52.216]) by core3.amsl.com (Postfix) with SMTP id 0092728C108 for ; Tue, 18 Jan 2011 12:24:04 -0800 (PST) Received: from [98.139.52.196] by nm19.bullet.mail.ac4.yahoo.com with NNFMP; 18 Jan 2011 20:26:40 -0000 Received: from [98.139.52.134] by tm9.bullet.mail.ac4.yahoo.com with NNFMP; 18 Jan 2011 20:26:40 -0000 Received: from [127.0.0.1] by omp1017.mail.ac4.yahoo.com with NNFMP; 18 Jan 2011 20:26:40 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 195960.51963.bm@omp1017.mail.ac4.yahoo.com Received: (qmail 91018 invoked by uid 60001); 18 Jan 2011 20:26:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295382400; bh=gLsIuaHzOl0bZFE82vlvop2/yGt+T2BHeVvf0AWydNg=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Lm/4crfSCCbea0fbGWJ3jBecmYsFmTKLFtfuvz98IwH4Ow4Uob7dFlDu+aZ9u/ftkHN54rv+vVu/4phlU0iIl9VgflZeCx15J62tNqFOWU6gHvv1V3JlEKryfwVWVQ56cMiXMP4/9gb8Yfh6BpfYr5PPJlB+tEZCydlj5vRkWfg= Message-ID: <72524.62131.qm@web55804.mail.re3.yahoo.com> X-YMail-OSG: o1OvBm8VM1lo9yCGas.bdiVRGUF86Mi4C83cMxmq0RN0MXp GT6YRYbPztq7_w0kNGUtiubgFaqIMxyOpZz7jvz8wOL_LtzM7A.RXtrHHZm_ FM_wkkYj3Sp0UYaxD3i8n2Jw09VK3raUhTmjoMxpHHc_klNgjhqO3YLq9gtI w4a0G1X1PuJyiLwZLm8em9kwbnIZlsrrbYJC71jDtvuC31.hbUKoTLrnp38p Fy.Hgij9npNnybu2izxlSeBZaVj_X7hkPQ1hKgwLQF7O_TD9nOrFc1tP6lNL i9F2Rm6A7wDg7Q4EHltFxddO1RX5wL6NwH4jT87xjBU.PJe.qZMvZMbFSqgt FkoDA9GHVbBSNMpE4jzMa3k5qCwT3HUTAszuiJov4EFP4ghUT4bWKBtrn5EL rZp_.aOY57g-- Received: from [174.65.103.16] by web55804.mail.re3.yahoo.com via HTTP; Tue, 18 Jan 2011 12:26:39 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Tue, 18 Jan 2011 12:26:39 -0800 (PST) From: Francisco Corella To: Eran Hammer-Lahav , Mike Jones In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-496000018-1295382399=:62131" Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2011 20:24:06 -0000 --0-496000018-1295382399=:62131 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mike, As assertion use is described in the spec, a client assertion does not prov= ide any security whatsoever.=C2=A0 How do you handle subject confirmation i= n your implementation?=C2=A0 (See section 2.4.1.1 of the SAML specification= .)=C2=A0 In other words, how does the authorization server know that the cl= ient sending the assertion is actually the subject of the assertion? Francisco --- On Tue, 1/18/11, Mike Jones wrote: From: Mike Jones Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and = OAuth2 HTTP Authentication Scheme To: "Eran Hammer-Lahav" Cc: "oauth@ietf.org" Date: Tuesday, January 18, 2011, 5:35 PM =0A=0A =0A =0A=0A=0AHaving spoken to a number of people implementing the sp= ec here, I=E2=80=99ve encountered strong objections to removing Client Asse= rtion Credentials and the OAuth2 HTTP Authentication Scheme. =C2=A0It=E2=80= =99s also not clear to me why we would make substantial=0A breaking changes= to the specification when it is essentially ready for approval.=C2=A0 I=E2= =80=99ve summarized the reasons I believe we should keep these two features= below. =0A =0AClient Assertion Credentials:=C2=A0 Many of the scenarios we= care about require this capability. They were key motivators for the Asser= tion Profile in WRAP (see =C2=A7 5.2), have been part of OAuth 2 for quite = a while, and we have running=0A code that requires this support. For exampl= e, the Azure Access Control Service is a cloud Authorization server that su= pports several protocols, including parts of OAuth 2.0 draft 10 (autonomous= and web server profiles). We are happy to update our implementation=0A to = subsequent drafts & agree that the spec leaves a lot of ambiguity. =0A =0AI= n our implementation of the autonomous and web server profiles, ACS allows = clients to authenticate using a signed assertion as well as with a username= /password. The username/pwd option is for clients that don=E2=80=99t mind s= ending credentials=0A over the wire, while the signed assertion mechanism i= s for clients that are more reticent to send raw credentials and for scenar= ios where it isn=E2=80=99t possible. To illustrate an example where usernam= e/pwd isn=E2=80=99t viable, consider the case of a client that needs=0A to = use an enterprise identity to gain access to a cloud service. In many cases= , corporate policy demands that a client use an identity managed by the org= anization. This means that the client should obtain an assertion from an en= terprise identity provider (Active=0A Directory, Tivoli, etc.) and use that= assertion to obtain an access token which grants access to various web ser= vice APIs. Many of our key MSFT customers and internal partner teams rely o= n this mechanism and reverting exclusively to username/pwd isn=E2=80=99t an= option=0A for us. =0A =C2=A0 =0A'OAuth2' HTTP Authentication Scheme:=C2=A0= Simply put, dropping this seems like a huge step away from interoperabilit= y.=C2=A0 As one data point, Microsoft implements this in our WIF OAuth2 pro= tected resource code.=C2=A0 All up, clients need a way=0A to authenticate t= o the protected resource.=C2=A0 Also, existing WRAP implementations need th= is functionality to migrate to OAuth2.=C2=A0=C2=A0 For all these reasons, w= e support retaining this functionality in OAuth2. =0A =C2=A0 =0A=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks, =0A=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike =0A =C2=A0 =0A=0A =0A -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0-496000018-1295382399=:62131 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable --0-496000018-1295382399=:62131-- From phil.hunt@oracle.com Tue Jan 18 14:43:20 2011 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 C875F28C11D for ; Tue, 18 Jan 2011 14:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 ts14cs4laHQ0 for ; Tue, 18 Jan 2011 14:43:19 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0547A28C11B for ; Tue, 18 Jan 2011 14:43:18 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0IMjscg029042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Jan 2011 22:45:56 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0ICw2UG014745; Tue, 18 Jan 2011 22:45:53 GMT Received: from abhmt001.oracle.com by acsmt353.oracle.com with ESMTP id 970667871295390673; Tue, 18 Jan 2011 14:44:33 -0800 Received: from dhcp-rmdc-twvpn-1-vpnpool-10-159-5-242.vpn.oracle.com (/10.159.5.242) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jan 2011 14:44:33 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-4--744107237 From: Phil Hunt In-Reply-To: <72524.62131.qm@web55804.mail.re3.yahoo.com> Date: Tue, 18 Jan 2011 14:44:32 -0800 Message-Id: <3AFB9555-B33E-4534-94F0-521BE821C352@oracle.com> References: <72524.62131.qm@web55804.mail.re3.yahoo.com> To: fcorella@pomcor.com X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 18 Jan 2011 22:43:20 -0000 --Apple-Mail-4--744107237 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 (apologies if this is a re-post, for some reason it was previously = bounced) I've been arguing as well to keep client assertion or some other = stronger alternative to 3.1. Re-reading the introduction to section 3, = I see that the last paragraph says: The authorization server MAY authenticate the client using any = appropriate set of credentials and authentication schemes. The client = MUST NOT include more than one set of credentials or authentication = mechanism with each request. I would suggest the following. That we replace 3.2 with this paragraph = expressed as an alternative (move it from the introduction and a little = massaging). The idea would be to make it clear that using normal web = authentication methodologies is perfectly acceptable. Further, I would = also suggest that if an OOB authentication is use (and preferred), that = the client_id might still be sent. This handles case where mapping = between client_id and the client credentials is not obvious (or easy).=20= How about: 3.2. Client Web (OOB) Credentials The client MAY be authenticated using any appropriate set of credentials = and web authentication scheme supported by the authorization server. In = cases where the client_id cannot be mapped by the authorizing server = from the client credential, the client_id MUST be provided.[should = client_id always be provided?] I would even include language that makes Client Web Credential = authentication the preferred methodology or at least list it first. This makes the spec more consistent in that OAuth is not involved in the = authentication of the user or the client. -- it makes it more = consistent. This approach will allow assertion based authentications (SAML, STS, = etc) or other approaches without having to get hung up on how it should = work inside of OAuth. Phil phil.hunt@oracle.com On 2011-01-18, at 12:26 PM, Francisco Corella wrote: > Mike, >=20 > As assertion use is described in the spec, a client assertion does not = provide any security whatsoever. How do you handle subject confirmation = in your implementation? (See section 2.4.1.1 of the SAML = specification.) In other words, how does the authorization server know = that the client sending the assertion is actually the subject of the = assertion? >=20 > Francisco >=20 > --- On Tue, 1/18/11, Mike Jones wrote: >=20 > From: Mike Jones > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme > To: "Eran Hammer-Lahav" > Cc: "oauth@ietf.org" > Date: Tuesday, January 18, 2011, 5:35 PM >=20 > Having spoken to a number of people implementing the spec here, I=92ve = encountered strong objections to removing Client Assertion Credentials = and the OAuth2 HTTP Authentication Scheme. It=92s also not clear to me = why we would make substantial breaking changes to the specification when = it is essentially ready for approval. I=92ve summarized the reasons I = believe we should keep these two features below. >=20 >=20 > Client Assertion Credentials: Many of the scenarios we care about = require this capability. They were key motivators for the Assertion = Profile in WRAP (see =A7 5.2), have been part of OAuth 2 for quite a = while, and we have running code that requires this support. For example, = the Azure Access Control Service is a cloud Authorization server that = supports several protocols, including parts of OAuth 2.0 draft 10 = (autonomous and web server profiles). We are happy to update our = implementation to subsequent drafts & agree that the spec leaves a lot = of ambiguity. >=20 >=20 > In our implementation of the autonomous and web server profiles, ACS = allows clients to authenticate using a signed assertion as well as with = a username/password. The username/pwd option is for clients that don=92t = mind sending credentials over the wire, while the signed assertion = mechanism is for clients that are more reticent to send raw credentials = and for scenarios where it isn=92t possible. To illustrate an example = where username/pwd isn=92t viable, consider the case of a client that = needs to use an enterprise identity to gain access to a cloud service. = In many cases, corporate policy demands that a client use an identity = managed by the organization. This means that the client should obtain an = assertion from an enterprise identity provider (Active Directory, = Tivoli, etc.) and use that assertion to obtain an access token which = grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and = reverting exclusively to username/pwd isn=92t an option for us. >=20 > =20 > 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems = like a huge step away from interoperability. As one data point, = Microsoft implements this in our WIF OAuth2 protected resource code. = All up, clients need a way to authenticate to the protected resource. = Also, existing WRAP implementations need this functionality to migrate = to OAuth2. For all these reasons, we support retaining this = functionality in OAuth2. >=20 > =20 > Thanks, >=20 > -- Mike >=20 > =20 >=20 > -----Inline Attachment Follows----- >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-4--744107237 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The authorization server MAY = authenticate the client using any appropriate set of credentials and = authentication schemes. The client MUST NOT include more than one set of = credentials or authentication mechanism with each request.

I would suggest the = following.  That we replace 3.2 with this paragraph expressed as an = alternative (move it from the introduction and a little massaging). =  The idea would be to make it clear that using normal web = authentication methodologies is perfectly acceptable.  Further, I = would also suggest that if an OOB authentication is use (and preferred), = that the client_id might still be sent.  This handles case where = mapping between client_id and the client credentials is not obvious (or = easy). 

How = about:

3.2. Client Web (OOB) = Credentials

On 2011-01-18, at 12:26 PM, Francisco Corella = wrote:

Mike,

As assertion use is described in= the spec, a client assertion does not provide any security whatsoever.&nbs= p; How do you handle subject confirmation in your implementation?  (Se= e section 2.4.1.1 of the SAML specification.)  In other words,= how does the authorization server know that the client sending the asserti= on is actually the subject of the assertion?

Francisco

--- On= Tue, 1/18/11, Mike Jones <Michael.Jones@microsoft.com>= wrote:

From: Mike Jones <Michael.Jones@= microsoft.com>
Subject: [OAUTH-WG] Reasons not to remove Client Asser= tion Credentials and OAuth2 HTTP Authentication Scheme
To: "Eran Hammer-= Lahav" <eran@hueniverse.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>=
Date: Tuesday, January 18, 2011, 5:35 PM

=0A=0A =0A =0A=0A
=0A

Having spoken to a number of people implementing the spe= c here, I=E2=80=99ve encountered strong objections to removing Client Asser= tion Credentials and the OAuth2 HTTP Authentication Scheme.  It=E2=80= =99s also not clear to me why we would make substantial=0A breaking changes= to the specification when it is essentially ready for approval.  I=E2= =80=99ve summarized the reasons I believe we should keep these two features= below.

=0A

=0A

Client Assertion Credentials:  Many of the = scenarios we care about require this capability. They were key motivators f= or the Assertion Profile in WRAP (see =C2=A7 5.2), have been part of OAuth = 2 for quite a while, and we have running=0A code that requires this support= . For example, the Azure Access Control Service is a cloud Authorization se= rver that supports several protocols, including parts of OAuth 2.0 draft 10= (autonomous and web server profiles). We are happy to update our implement= ation=0A to subsequent drafts & agree that the spec leaves a lot of amb= iguity.

=0A

=0A

In our implementation of the autonomous and web server = profiles, ACS allows clients to authenticate using a signed assertion as we= ll as with a username/password. The username/pwd option is for clients that= don=E2=80=99t mind sending credentials=0A over the wire, while the signed = assertion mechanism is for clients that are more reticent to send raw crede= ntials and for scenarios where it isn=E2=80=99t possible. To illustrate an = example where username/pwd isn=E2=80=99t viable, consider the case of a cli= ent that needs=0A to use an enterprise identity to gain access to a cloud s= ervice. In many cases, corporate policy demands that a client use an identi= ty managed by the organization. This means that the client should obtain an= assertion from an enterprise identity provider (Active=0A Directory, Tivol= i, etc.) and use that assertion to obtain an access token which grants acce= ss to various web service APIs. Many of our key MSFT customers and internal= partner teams rely on this mechanism and reverting exclusively to username= /pwd isn=E2=80=99t an option=0A for us.

=0A

 

=0A

'OAuth2' HTTP= Authentication Scheme:  Simply put, dropping this seems like a hu= ge step away from interoperability.  As one data point, Microsoft impl= ements this in our WIF OAuth2 protected resource code.  All up, client= s need a way=0A to authenticate to the protected resource.  Also, exis= ting WRAP implementations need this functionality to migrate to OAuth2.&nbs= p;  For all these reasons, we support retaining this functionality in = OAuth2.

=0A

 

=0A

        = ;            &n= bsp;            = ;            &n= bsp;            = ;  Thanks,

=0A

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

=0A

 

=0A
=0A =0A

-----Inline Attachment= Follows-----

_____________________________= __________________
OAuth mailing list
OAuth@ietf.org
https:/= /www.ietf.org/mailman/listinfo/oauth
Mike,

As assertion use is described in the spec, a = client assertion does not provide any security whatsoever.  How do = you handle subject confirmation in your implementation?  (See = section 2.4.1.1 of the SAML specification.)  In other words, how does the = authorization server know that the client sending the assertion is = actually the subject of the assertion?

Francisco

--- On = Tue, 1/18/11, Mike Jones <Michael.Jones@microsoft.com> wrote:

From: Mike = Jones <Michael.Jones@microsoft.com>
Subject: [OAUTH-WG] Reasons not to remove Client Assertion = Credentials and OAuth2 HTTP Authentication Scheme
To: "Eran = Hammer-Lahav" <eran@hueniverse.com>
Cc: = "oauth@ietf.org" <oauth@ietf.org>
Date: Tuesday, = January 18, 2011, 5:35 PM

=20 =20

Having spoken to a number of people = implementing the spec here, I=92ve encountered strong objections to = removing Client Assertion Credentials and the OAuth2 HTTP Authentication = Scheme.  It=92s also not clear to me why we would make substantial breaking changes to the specification when it is essentially ready for = approval.  I=92ve summarized the reasons I believe we should keep = these two features below.


Client Assertion = Credentials:  Many of the scenarios we care about require this = capability. They were key motivators for the Assertion Profile in WRAP = (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have = running code that requires this support. For example, the Azure Access Control = Service is a cloud Authorization server that supports several protocols, = including parts of OAuth 2.0 draft 10 (autonomous and web server = profiles). We are happy to update our implementation to subsequent drafts & agree that the spec leaves a lot of = ambiguity.


In our implementation of the autonomous = and web server profiles, ACS allows clients to authenticate using a = signed assertion as well as with a username/password. The username/pwd = option is for clients that don=92t mind sending credentials over the wire, while the signed assertion mechanism is for clients that = are more reticent to send raw credentials and for scenarios where it = isn=92t possible. To illustrate an example where username/pwd isn=92t = viable, consider the case of a client that needs to use an enterprise identity to gain access to a cloud service. In = many cases, corporate policy demands that a client use an identity = managed by the organization. This means that the client should obtain an = assertion from an enterprise identity provider (Active Directory, Tivoli, etc.) and use that assertion to obtain an access = token which grants access to various web service APIs. Many of our key = MSFT customers and internal partner teams rely on this mechanism and = reverting exclusively to username/pwd isn=92t an option for us.

 

'OAuth2' HTTP Authentication = Scheme:  Simply put, dropping this seems like a huge step away = from interoperability.  As one data point, Microsoft implements = this in our WIF OAuth2 protected resource code.  All up, clients = need a way to authenticate to the protected resource.  Also, existing WRAP = implementations need this functionality to migrate to = OAuth2.   For all these reasons, we support retaining this = functionality in OAuth2.

 

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

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

 
=20
=20

-----Inline Attachment Follows-----

_______________________________________________
OAu= th mailing list
OAuth@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/oauth" = target=3D"_blank">https://www.ietf.org/mailman/listinfo/oauth
__________________________________= _____________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/= mailman/listinfo/oauth

= --Apple-Mail-4--744107237-- From tonynad@microsoft.com Tue Jan 18 14:52:07 2011 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 628DA28C116 for ; Tue, 18 Jan 2011 14:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 uPbFS-6Q4jcP for ; Tue, 18 Jan 2011 14:51:53 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 3838328C0FA for ; Tue, 18 Jan 2011 14:51:53 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 18 Jan 2011 14:54:31 -0800 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.87]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0255.003; Tue, 18 Jan 2011 14:54:31 -0800 From: Anthony Nadalin To: Eran Hammer-Lahav , "Richer, Justin P." , OAuth WG Thread-Topic: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials Thread-Index: AQHLtl1nSm3qABc5GUyMqtbd/Xypq5PW/OGwgAAGYDCAAFTvkA== Date: Tue, 18 Jan 2011 22:54:30 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F0338AE38@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F0338ABF3@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F55@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5D35F55@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials 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, 18 Jan 2011 22:52:07 -0000 If it is left as optional (not removed) then I'm OK to go with parameter-ba= sed approach as default -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Tuesday, January 18, 2011 9:50 AM To: Anthony Nadalin; Richer, Justin P.; OAuth WG Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Crede= ntials So does requiring the parameter-based approach which has identical security= properties. We need to require at least one, and we already know some will= not deploy Basic. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tonynad@microsoft.com] > Sent: Tuesday, January 18, 2011 9:28 AM > To: Richer, Justin P.; Eran Hammer-Lahav; OAuth WG > Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client=20 > Credentials >=20 > Concern here is that HTTP Basic Auth provides a straightforward=20 > interop profile for the web server profile >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Richer, Justin P. > Sent: Monday, January 17, 2011 7:43 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client=20 > Credentials >=20 > +1 to making BASIC optional. I don't think we were going to be=20 > +supporting it > in general, either. >=20 > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of=20 > Eran Hammer-Lahav [eran@hueniverse.com] > Sent: Saturday, January 15, 2011 1:53 AM > To: OAuth WG > Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client=20 > Credentials >=20 > OAuth 2.0 provides two methods for client authentication using=20 > password > credentials: request parameters and HTTP Basic authentication. I=20 > suggest we drop the requirement to support HTTP Basic authentication,=20 > and only mention it as an example for alternative methods. My reasons are= : >=20 >=20 > 1. A few providers have expressed concerns over the need to support > Basic authentication, and some explicitly said they will not support it. > Parameter-based authentication, OTOH, is widely deployed in 2.0. >=20 > 2. Due to the way OAuth is being implemented at the HTTP authentica= tion > layer (even if it is wrong), can conflict within the framework as both=20 > a consumer and provider of authentication components. >=20 > 3. The mapping between username and client_id, while not complicate= d, > is still a big awkward, and can be confusing when combined with the=20 > username and password grant type. On the other hand, the use of=20 > client_id in the end-user authorization endpoint lends itself nicely=20 > to the use of the same parameter elsewhere. >=20 > 4. Some existing authentication frameworks will have an issue handl= ing > the mix of Basic authentication and parameters authentication due to=20 > how each is deployed. In cases where a front gate handles Basic, it=20 > will be hard to let requests through for parameter processing. >=20 > Comments? Counter-arguments? >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue Jan 18 15:00:40 2011 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 182F328C0FA for ; Tue, 18 Jan 2011 15:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.702 X-Spam-Level: X-Spam-Status: No, score=-105.702 tagged_above=-999 required=5 tests=[AWL=0.275, 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 84F6FiK6fk7u for ; Tue, 18 Jan 2011 15:00:38 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3EDDA28C0D7 for ; Tue, 18 Jan 2011 15:00:38 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p0IN3Gbm019282 for ; Tue, 18 Jan 2011 15:03:16 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295391796; bh=isqfXw1ntKoOIiFQHBa0GZrxhYs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=iSMd7ryeY9zvNQ+lk0FUesl8/xKQVy+fFKJqMbI1jvI7j2ZtXVLRhPF3DL23nc6Kb to9lQIOm6ad9IQBdsx+mA== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by wpaz1.hot.corp.google.com with ESMTP id p0IN3BXd007254 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Jan 2011 15:03:11 -0800 Received: by gwj20 with SMTP id 20so70578gwj.22 for ; Tue, 18 Jan 2011 15:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=uIlGIorJ/d/OnXncqHS0Vf+OCbvViJ0D+zZ+qJ+8Y4k=; b=szMY9YXxHBkcjx1ZbsUZ/bB1hGdWodK/5argjCwHnwS74n97Og0Oib973XW2WA7IMq 3a75yw0T56F5kXAaahBw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=oHj3qzTVAWYCVPJKmHSyecaDzGmbaQsQhVWrghuXkKEJrjBsKwW7LIqnIpCfHSUkoM zCQ+55EZb2tk505lPHUQ== Received: by 10.100.139.9 with SMTP id m9mr4001793and.183.1295391791472; Tue, 18 Jan 2011 15:03:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Tue, 18 Jan 2011 15:02:51 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 18 Jan 2011 15:02:51 -0800 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] Format of user-agent response parameters 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, 18 Jan 2011 23:00:40 -0000 On Sat, Jan 15, 2011 at 11:41 PM, Eran Hammer-Lahav w= rote: > Why is the token returned in the fragment using form-encoding? This makes= no > sense. It should be a JSON string for the following reasons: > > > > 1.=A0=A0=A0=A0=A0=A0 All token responses should be the same, which will e= nable returning > structured responses in the future as needed. They cannot all be the same. response_type=3Dcode has the response in the query parameter, so I think we should stick with flat name/value pairs. > 2.=A0=A0=A0=A0=A0=A0 Using fragments is specifically done to accommodate = the user-agent > environment, which means JavaScript. Why create extra work when JSON.pars= e() > does it for you for free. The argument was that it is a somewhat more difficult to safely parse JSON in JavaScript (maybe I remember wrong). Unless we have a good reason to change to JSON, considering it is late in the game, I think we should not make changes. Marius From igor.faynberg@alcatel-lucent.com Tue Jan 18 15:17:51 2011 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 B8EB128C145 for ; Tue, 18 Jan 2011 15:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyY9eXDaCU2d for ; Tue, 18 Jan 2011 15:17:50 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id ACE2928C13C for ; Tue, 18 Jan 2011 15:17:50 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0INKS4n023240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 17:20:28 -0600 (CST) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p0INKRc3007958; Tue, 18 Jan 2011 17:20:27 -0600 (CST) Message-ID: <4D36203B.5030306@alcatel-lucent.com> Date: Tue, 18 Jan 2011 18:20:27 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gabriel Klein References: <1295379852.16479.60.camel@GabLap> In-Reply-To: <1295379852.16479.60.camel@GabLap> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 chain flow 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, 18 Jan 2011 23:17:51 -0000 Interesting! I definitely see value in this, and... this appears to me to be a new use case. Gabriel Klein wrote: > Dear oAuth2 team, > > I'm currently working on the way we will implement oAuth2 in our > company. (Poken.com) > > I've an interesting flow to work on: > We delegate the account creation and account authentication mechanism to > an external oAuth2 provider. > > What it means: > We have a mobile application, you can choose the way you want to login. > - User and Password > - Facebook (Microsoft, Google, Twitter, and other oAuth2 provider later) > Based on the facebook access_token or code, we return a poken > access_token. > > We have a similar flow in our web application (is on top of our API). > > >From a technical point: > When we login using Facebook, we get the "code" or access_token (linked > to our client_id access on Facebook). This part is the responsibility of > the UI/mobile application. Facebook client_secret is not shared with > Facebook. > > The mobile application then call our API. (Not implemented yet) > https://api.poken.com/oauth2/authorize? > grant_type=poken_extenal_oauth2& > service=facebook.com& > service_secret={facebook_access_token or code}& > client_id={appid-phphub}&client_secret={apppass-phphub}& > response_type = token > > In our API we exchange the facebook code for a facebook access_token and > get the facebook_account_id of the user on Facebook. > > If this facebook_account_id is linked to a poken account on our system, > we return a poken access_token for this account. With this access_token, > the client can use our API. > > I call this flow "oAuth2 Chain Flow" > > I think it's a quite interesting flow, because it's more and more > frequent to delegate the authentication to another website/service. > (Even more when you are not part of the biggest sites.) > > What do you think of this aspect of authentication? > Did you already spoke about this flow? > Do we have some specifications for this flow? > > Best regards, > Gabriel Klein (poken.com) > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > From igor.faynberg@alcatel-lucent.com Tue Jan 18 15:18:34 2011 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 F2EF728C15E for ; Tue, 18 Jan 2011 15:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnU4Uy76EpHg for ; Tue, 18 Jan 2011 15:18:33 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id D9A2028C13C for ; Tue, 18 Jan 2011 15:18:32 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p0INL96L023517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Jan 2011 17:21:09 -0600 (CST) Received: from [135.222.134.173] (faynberg-c1.mh.lucent.com [135.222.134.173]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p0INL9Iq008396; Tue, 18 Jan 2011 17:21:09 -0600 (CST) Message-ID: <4D362065.1040201@alcatel-lucent.com> Date: Tue, 18 Jan 2011 18:21:09 -0500 From: Igor Faynberg Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Anthony Nadalin References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F0338ABF3@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F55@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F0338AE38@TK5EX14MBXC113.redmond.corp.microsoft.com> In-Reply-To: <180155C5EA10854997314CA5E063D18F0338AE38@TK5EX14MBXC113.redmond.corp.microsoft.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.35 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials 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, 18 Jan 2011 23:18:34 -0000 +1 Igor Anthony Nadalin wrote: > If it is left as optional (not removed) then I'm OK to go with parameter-based approach as default > > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Tuesday, January 18, 2011 9:50 AM > To: Anthony Nadalin; Richer, Justin P.; OAuth WG > Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client Credentials > > So does requiring the parameter-based approach which has identical security properties. We need to require at least one, and we already know some will not deploy Basic. > > EHL > > >> -----Original Message----- >> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >> Sent: Tuesday, January 18, 2011 9:28 AM >> To: Richer, Justin P.; Eran Hammer-Lahav; OAuth WG >> Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >> Credentials >> >> Concern here is that HTTP Basic Auth provides a straightforward >> interop profile for the web server profile >> >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Richer, Justin P. >> Sent: Monday, January 17, 2011 7:43 AM >> To: Eran Hammer-Lahav; OAuth WG >> Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >> Credentials >> >> +1 to making BASIC optional. I don't think we were going to be >> +supporting it >> in general, either. >> >> -- Justin >> ________________________________________ >> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of >> Eran Hammer-Lahav [eran@hueniverse.com] >> Sent: Saturday, January 15, 2011 1:53 AM >> To: OAuth WG >> Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >> Credentials >> >> OAuth 2.0 provides two methods for client authentication using >> password >> credentials: request parameters and HTTP Basic authentication. I >> suggest we drop the requirement to support HTTP Basic authentication, >> and only mention it as an example for alternative methods. My reasons are: >> >> >> 1. A few providers have expressed concerns over the need to support >> Basic authentication, and some explicitly said they will not support it. >> Parameter-based authentication, OTOH, is widely deployed in 2.0. >> >> 2. Due to the way OAuth is being implemented at the HTTP authentication >> layer (even if it is wrong), can conflict within the framework as both >> a consumer and provider of authentication components. >> >> 3. The mapping between username and client_id, while not complicated, >> is still a big awkward, and can be confusing when combined with the >> username and password grant type. On the other hand, the use of >> client_id in the end-user authorization endpoint lends itself nicely >> to the use of the same parameter elsewhere. >> >> 4. Some existing authentication frameworks will have an issue handling >> the mix of Basic authentication and parameters authentication due to >> how each is deployed. In cases where a front gate handles Basic, it >> will be hard to let requests through for parameter processing. >> >> Comments? Counter-arguments? >> >> 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 Michael.Jones@microsoft.com Tue Jan 18 15:29:54 2011 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 C12D728C13C for ; Tue, 18 Jan 2011 15:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.586 X-Spam-Level: X-Spam-Status: No, score=-10.586 tagged_above=-999 required=5 tests=[AWL=0.012, 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 dWc8MffzBBpM for ; Tue, 18 Jan 2011 15:29:44 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 4DC2228C132 for ; Tue, 18 Jan 2011 15:29:44 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 18 Jan 2011 15:32:22 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Tue, 18 Jan 2011 15:32:21 -0800 From: Mike Jones To: Eran Hammer-Lahav Thread-Topic: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme Thread-Index: Acu3NiSHXpF3O14eTPqlwk2IwSAdgAAArk0wAAupkeA= Date: Tue, 18 Jan 2011 23:32:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246EE49E@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246EE49ETK5EX14MBXC202r_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 18 Jan 2011 23:29:54 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246EE49ETK5EX14MBXC202r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You wrote: "Those who still want to advocate for it need to show not only = consensus for keeping it...". This seems backwards to me. In particular, = given the industry consensus that draft 10 was "nearly done", the onus to e= stablish consensus should fall on advocates of any proposals to remove feat= ures - not the other way around - particularly so when the features are imp= lemented and in use. It's also pertinent that the implementation call went out for draft 11. Th= erefore, we should not be removing draft 11 features without decisive conse= nsus for doing so. -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, January 18, 2011 10:13 AM To: Mike Jones Cc: oauth@ietf.org Subject: RE: Reasons not to remove Client Assertion Credentials and OAuth2 = HTTP Authentication Scheme I agree that at this stage, we should do our best to avoid making breaking = changes. But first, we need to establish what is going to break and how. The argument that removing the client assertion credentials affects interop= erability or breaks implementations is without merit. As currently specified, the text is useless for any level of interoperabili= ty or implementation. This means you must have your own specification provi= ding the actual meaningful information. At most, removing this section will= require you to register the two parameter names it defines. Since neither = is being used for a new purpose, removing this section creates no conflict.= Hopefully, your parameter registration will provide more meaningful inform= ation about them than currently offered. If you are going to object to my conclusions, you first need to show where = my arguments are wrong. I have seen nothing to contradict a single point I = have made about both issues. This goes for both the client assertion creden= tials and OAuth2 scheme. Just in case, I'll repeat my points. Client assertion credentials: 1. The mechanism is under specified, especially in its handling of the c= lient_id identifier (when used to obtain end-user authorization). 2. It does not contain any implementation details to accomplish any leve= l of interoperability or functionality. 3. The section is a confused mix of security considerations sprinkled wi= th normative language. 4. Those who still want to advocate for it need to show not only consens= us for keeping it, but also active community support for deploying it. Depl= oyment, of course, will also require showing progress on public specificati= ons profiling the mechanism into a useful interoperable feature. Which open= source library supports or plan to support it? 'OAuth2' WWW-Authenticate header: 1. Draft oauth-v2 is clearly not an authentication protocol. It *utilize= s* client authentication. It offers one fully defined method for client aut= hentication (which is basically HTTP Basic+), provides a half-baked client = assertion authentication hook, and leaves all end-user authentication out o= f scope. 2. The WWW-Authenticate header has absolutely no value, interoperability= -wise or otherwise. Discovery was rules to be beyond the scope of this spec= ification. Having a protected resource declare it supports authentication u= sing some unspecified credentials obtained using some unspecified client fl= ow is confusing at best. 3. OAuth is agnostic to token authentication, and we already have three = discrete token type proposals - all with active deployment plans in the com= ing months. 4. HTTP *authentication* is not an appropriate facility to negotiate *au= thorization*. OAuth authorization discovery can be added to HTTP authentica= tion schemes as attributes, but makes no sense as a scheme of its own. The = issues we are having with 'realm' is one of the examples showing that we ar= e abusing the header. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Tuesday, January 18, 2011 9:36 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP= Authentication Scheme Having spoken to a number of people implementing the spec here, I've encoun= tered strong objections to removing Client Assertion Credentials and the OA= uth2 HTTP Authentication Scheme. It's also not clear to me why we would ma= ke substantial breaking changes to the specification when it is essentially= ready for approval. I've summarized the reasons I believe we should keep = these two features below. Client Assertion Credentials: Many of the scenarios we care about require = this capability. They were key motivators for the Assertion Profile in WRAP= (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have ru= nning code that requires this support. For example, the Azure Access Contro= l Service is a cloud Authorization server that supports several protocols, = including parts of OAuth 2.0 draft 10 (autonomous and web server profiles).= We are happy to update our implementation to subsequent drafts & agree tha= t the spec leaves a lot of ambiguity. In our implementation of the autonomous and web server profiles, ACS allows= clients to authenticate using a signed assertion as well as with a usernam= e/password. The username/pwd option is for clients that don't mind sending = credentials over the wire, while the signed assertion mechanism is for clie= nts that are more reticent to send raw credentials and for scenarios where = it isn't possible. To illustrate an example where username/pwd isn't viable= , consider the case of a client that needs to use an enterprise identity to= gain access to a cloud service. In many cases, corporate policy demands th= at a client use an identity managed by the organization. This means that th= e client should obtain an assertion from an enterprise identity provider (A= ctive Directory, Tivoli, etc.) and use that assertion to obtain an access t= oken which grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and reverting e= xclusively to username/pwd isn't an option for us. 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. Thanks, -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943246EE49ETK5EX14MBXC202r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

You wrote:  ̶= 0;Those who still want to advocate for it need to show not only consensus f= or keeping it…”.  This seems backwards to me.  In par= ticular, given the industry consensus that draft 10 was “nearly done&= #8221;, the onus to establish consensus should fall on advocates of any proposals = to remove features – not the other way around – particularly so= when the features are implemented and in use.

 

It’s also pertin= ent that the implementation call went out for draft 11.  Therefore, we= should not be removing draft 11 features without decisive consensus for do= ing so.

 

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Tuesday, January 18, 2011 10:13 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: RE: Reasons not to remove Client Assertion Credentials and = OAuth2 HTTP Authentication Scheme

 

I agree that at this s= tage, we should do our best to avoid making breaking changes. But first, we= need to establish what is going to break and how.

 

The argument that remo= ving the client assertion credentials affects interoperability or breaks im= plementations is without merit.

 

As currently specified= , the text is useless for any level of interoperability or implementation. = This means you must have your own specification providing the actual meanin= gful information. At most, removing this section will require you to register the two parameter names it defin= es. Since neither is being used for a new purpose, removing this section cr= eates no conflict. Hopefully, your parameter registration will provide more= meaningful information about them than currently offered.

 

If you are going to ob= ject to my conclusions, you first need to show where my arguments are wrong= . I have seen nothing to contradict a single point I have made about both i= ssues. This goes for both the client assertion credentials and OAuth2 scheme.

 

Just in case, I’= ll repeat my points.

 

Client assertion crede= ntials:

 

  1. The= mechanism is under specified, especially in its handling of the client_id = identifier (when used to obtain end-user authorization).
    2. It doe= s not contain any implementation details to accomplish any level of interop= erability or functionality.
  2. The section is a confused mix of se= curity considerations sprinkled with normative language.
    3. Those = who still want to advocate for it need to show not only consensus for keepi= ng it, but also active community support for deploying it. Deployment, of c= ourse, will also require showing progress on public specifications profiling the mechanism into a useful in= teroperable feature. Which open source library supports or plan to support = it?

 

‘OAuth2’ W= WW-Authenticate header:

 

  1. Dra= ft oauth-v2 is clearly not an authentication protocol. It *utilizes*= client authentication. It offers one fully defined method for client authe= ntication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all= end-user authentication out of scope.
  2. The WWW-Authenticate hea= der has absolutely no value, interoperability-wise or otherwise. Discovery = was rules to be beyond the scope of this specification. Having a protected = resource declare it supports authentication using some unspecified credentials obtained usi= ng some unspecified client flow is confusing at best.
  3. OAuth is agnostic to token authentication, and we already have= three discrete token type proposals – all with active deployment pla= ns in the coming months.
  4. HTTP *authentication* is not an= appropriate facility to negotiate *authorization*. OAuth authorizat= ion discovery can be added to HTTP authentication schemes as attributes, bu= t makes no sense as a scheme of its own. The issues we are having with ̵= 6;realm’ is one of the examples showing that we are abusing the heade= r.

 

EHL<= /p>

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Tuesday, January 18, 2011 9:36 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Reasons not to remove Client Assertion Credentials and OAut= h2 HTTP Authentication Scheme

 

Having spoken to a number of people implementing the= spec here, I’ve encountered strong objections to removing Client Ass= ertion Credentials and the OAuth2 HTTP Authentication Scheme.  It̵= 7;s also not clear to me why we would make substantial breaking changes to the specification when it is essentially ready for app= roval.  I’ve summarized the reasons I believe we should keep the= se two features below.

 

Client Assertion Credentials:  Many of t= he scenarios we care about require this capability. They were key motivator= s for the Assertion Profile in WRAP (see =A7 5.2), have been part of OAuth = 2 for quite a while, and we have running code that requires this support. For example, the Azure Access Control Ser= vice is a cloud Authorization server that supports several protocols, inclu= ding parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We a= re happy to update our implementation to subsequent drafts & agree that the spec leaves a lot of ambiguity.<= o:p>

 

In our implementation of the autonomous and web serv= er profiles, ACS allows clients to authenticate using a signed assertion as= well as with a username/password. The username/pwd option is for clients t= hat don’t mind sending credentials over the wire, while the signed assertion mechanism is for clients that ar= e more reticent to send raw credentials and for scenarios where it isn̵= 7;t possible. To illustrate an example where username/pwd isn’t viabl= e, consider the case of a client that needs to use an enterprise identity to gain access to a cloud service. In many c= ases, corporate policy demands that a client use an identity managed by the= organization. This means that the client should obtain an assertion from a= n enterprise identity provider (Active Directory, Tivoli, etc.) and use that assertion to obtain an access token = which grants access to various web service APIs. Many of our key MSFT custo= mers and internal partner teams rely on this mechanism and reverting exclus= ively to username/pwd isn’t an option for us.

 

'OAuth2' HTTP Authentication Scheme:  Si= mply put, dropping this seems like a huge step away from interoperability.&= nbsp; As one data point, Microsoft implements this in our WIF OAuth2 protec= ted resource code.  All up, clients need a way to authenticate to the protected resource.  Also, existing WRAP imple= mentations need this functionality to migrate to OAuth2.   For al= l these reasons, we support retaining this functionality in OAuth2.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; Thanks,

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943246EE49ETK5EX14MBXC202r_-- From jhart@photobucket.com Tue Jan 18 15:58:21 2011 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 C521628C0E1 for ; Tue, 18 Jan 2011 15:58:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 7R2x2mi2eAYm for ; Tue, 18 Jan 2011 15:58:20 -0800 (PST) Received: from exhub003-1.exch003intermedia.net (exhub003-1.exch003intermedia.net [207.5.74.28]) by core3.amsl.com (Postfix) with ESMTP id 9AE5528C0CF for ; Tue, 18 Jan 2011 15:58:20 -0800 (PST) Received: from EXVMBX003-4.exch003intermedia.net ([207.5.74.44]) by exhub003-1.exch003intermedia.net ([207.5.74.28]) with mapi; Tue, 18 Jan 2011 16:00:58 -0800 From: Justin Hart To: "igor.faynberg@alcatel-lucent.com" Date: Tue, 18 Jan 2011 16:00:58 -0800 Thread-Topic: [OAUTH-WG] OAuth2 chain flow Thread-Index: Acu3a/OMTk6IV2IQQSOWN5frtsqZaQ== Message-ID: References: <1295379852.16479.60.camel@GabLap> <4D36203B.5030306@alcatel-lucent.com> In-Reply-To: <4D36203B.5030306@alcatel-lucent.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: Gabriel Klein , "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2 chain 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, 18 Jan 2011 23:58:21 -0000 I've got a spec written for this that I've been quite lax in finishing. I'= ll clean it up a bit tonight/tomorrow and send out a draft link for review. ---- -- Justin Hart -- jhart@photobucket.com On Jan 18, 2011, at 4:20 PM, Igor Faynberg wrote: > Interesting! I definitely see value in this, and... this appears to=20 > me to be a new use case. >=20 > Gabriel Klein wrote: >> Dear oAuth2 team, >>=20 >> I'm currently working on the way we will implement oAuth2 in our >> company. (Poken.com) >>=20 >> I've an interesting flow to work on: >> We delegate the account creation and account authentication mechanism to >> an external oAuth2 provider. >>=20 >> What it means: >> We have a mobile application, you can choose the way you want to login. >> - User and Password >> - Facebook (Microsoft, Google, Twitter, and other oAuth2 provider later) >> Based on the facebook access_token or code, we return a poken >> access_token. >>=20 >> We have a similar flow in our web application (is on top of our API). >>=20 >>> From a technical point: >> When we login using Facebook, we get the "code" or access_token (linked >> to our client_id access on Facebook). This part is the responsibility of >> the UI/mobile application. Facebook client_secret is not shared with >> Facebook. >>=20 >> The mobile application then call our API. (Not implemented yet) >> https://api.poken.com/oauth2/authorize? >> grant_type=3Dpoken_extenal_oauth2& >> service=3Dfacebook.com& >> service_secret=3D{facebook_access_token or code}& >> client_id=3D{appid-phphub}&client_secret=3D{apppass-phphub}& >> response_type =3D token >>=20 >> In our API we exchange the facebook code for a facebook access_token and >> get the facebook_account_id of the user on Facebook. >>=20 >> If this facebook_account_id is linked to a poken account on our system, >> we return a poken access_token for this account. With this access_token, >> the client can use our API. >>=20 >> I call this flow "oAuth2 Chain Flow" >>=20 >> I think it's a quite interesting flow, because it's more and more >> frequent to delegate the authentication to another website/service. >> (Even more when you are not part of the biggest sites.) >>=20 >> What do you think of this aspect of authentication? >> Did you already spoke about this flow? >> Do we have some specifications for this flow? >>=20 >> Best regards, >> Gabriel Klein (poken.com) >>=20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Tue Jan 18 16:51:25 2011 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 BE60A3A7070 for ; Tue, 18 Jan 2011 16:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.723 X-Spam-Level: X-Spam-Status: No, score=-105.723 tagged_above=-999 required=5 tests=[AWL=0.254, 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 gDEeOQdMCxpS for ; Tue, 18 Jan 2011 16:51:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B12EA3A6F68 for ; Tue, 18 Jan 2011 16:51:24 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p0J0s2FM007818 for ; Tue, 18 Jan 2011 16:54:02 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295398443; bh=Pm+ZgICcczEcjbXfuxoysMB6wUA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gk7QGx9tFjK0xjMAQ+uP7Z8Fqi81QtHs0ebWwULDRjVuQfe6KcEpjEy3eVReqjdRV ut0GL7c9vPp2ohnWg0MbQ== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by kpbe19.cbf.corp.google.com with ESMTP id p0J0rSqu020413 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Jan 2011 16:54:01 -0800 Received: by yxm8 with SMTP id 8so78636yxm.35 for ; Tue, 18 Jan 2011 16:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mJ6E4Gw5lPlG+LWlnJwP1wRAtKQDzUnAi0BAbPwVmPg=; b=sP+9JehqS8b1HA5BWT1cSJ2iSdPbC9lMx6XCtxasd9VK1wgdal6VkTG+rCLuCEkGTA mFLBl+MBNkJaEGnGmIvA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=SYQmDXi+ScuPUplZkVt6uU7qghnOROLlWTeXzbVOkxuJ9tSWbLsrcZnK6SXWBH3SvB q4O/HMEVtLNJqZZuhhZQ== Received: by 10.100.139.9 with SMTP id m9mr18148and.183.1295398441097; Tue, 18 Jan 2011 16:54:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Tue, 18 Jan 2011 16:53:40 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D333EE9.1030706@lodderstedt.net> From: Marius Scurtescu Date: Tue, 18 Jan 2011 16:53:40 -0800 Message-ID: To: "Richer, Justin P." Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters 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, 19 Jan 2011 00:51:25 -0000 On Mon, Jan 17, 2011 at 7:55 AM, Richer, Justin P. wrote: > I absolutely don't want to drop credentials being passed as parameters. I think that's more widely deployed than using the BASIC style auth as well. +1 I think it is way too late for drastic changes like this. As shown by existing implementations, pretty much everyone cares only about credentials sent as parameters. Marius From mscurtescu@google.com Tue Jan 18 16:54:33 2011 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 2C78A3A707A for ; Tue, 18 Jan 2011 16:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.517 X-Spam-Level: X-Spam-Status: No, score=-104.517 tagged_above=-999 required=5 tests=[AWL=-1.540, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 uicE1oJZNMAF for ; Tue, 18 Jan 2011 16:54:31 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8B8DD3A7075 for ; Tue, 18 Jan 2011 16:54:31 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p0J0v894007361 for ; Tue, 18 Jan 2011 16:57:09 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295398629; bh=2/kHASnQMoklcYEVQdLZEh4lkbU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=CCTgoug9dUwE0uwqN+BWAuOsVXpC1actejtLMrRRtaGAqxX1SbNqcaPDV7t2Vh1EK 15dbFwFJP+7PgWmFljrmw== Received: from yxt3 (yxt3.prod.google.com [10.190.5.195]) by wpaz33.hot.corp.google.com with ESMTP id p0J0v7c0024115 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 18 Jan 2011 16:57:07 -0800 Received: by yxt3 with SMTP id 3so75820yxt.19 for ; Tue, 18 Jan 2011 16:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=H2gp8QSs11kEjn6Q5j33b0QqIN1KI5StxFzF0Oany2g=; b=kSVdxZMpywHmB19xKZgRR4TiDaas2gges3X53B/Sz4zrAj5Pp/wJBy/CZJAllABPGA hm7oHeoNgNlFBQk2AwiA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=dAARivH367OWC9UggCuwth2vogPNuzroGq977jbb2iSwksqrkhDs25Cfkv1ABRYllE OvlkLBtYkxgDIrYCSsBA== Received: by 10.100.95.20 with SMTP id s20mr8570anb.251.1295398627198; Tue, 18 Jan 2011 16:57:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Tue, 18 Jan 2011 16:56:47 -0800 (PST) In-Reply-To: <4D362065.1040201@alcatel-lucent.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F0338ABF3@TK5EX14MBXC113.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F55@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F0338AE38@TK5EX14MBXC113.redmond.corp.microsoft.com> <4D362065.1040201@alcatel-lucent.com> From: Marius Scurtescu Date: Tue, 18 Jan 2011 16:56:47 -0800 Message-ID: To: igor.faynberg@alcatel-lucent.com 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] Removal: HTTP Basic Authentication for Client Credentials 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, 19 Jan 2011 00:54:33 -0000 +1 I think basic auth for client credentials belongs to an extension, that simplifies the core spec. Is there a good reason to keep an optional feature in core? Marius On Tue, Jan 18, 2011 at 3:21 PM, Igor Faynberg wrote: > +1 > > Igor > > Anthony Nadalin wrote: >> >> If it is left as optional (not removed) then I'm OK to go with >> parameter-based approach as default >> >> -----Original Message----- >> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, >> January 18, 2011 9:50 AM >> To: Anthony Nadalin; Richer, Justin P.; OAuth WG >> Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >> Credentials >> >> So does requiring the parameter-based approach which has identical >> security properties. We need to require at least one, and we already kno= w >> some will not deploy Basic. >> >> EHL >> >> >>> >>> -----Original Message----- >>> From: Anthony Nadalin [mailto:tonynad@microsoft.com] >>> Sent: Tuesday, January 18, 2011 9:28 AM >>> To: Richer, Justin P.; Eran Hammer-Lahav; OAuth WG >>> Subject: RE: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >>> Credentials >>> >>> Concern here is that HTTP Basic Auth provides a straightforward interop >>> profile for the web server profile >>> >>> -----Original Message----- >>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of >>> Richer, Justin P. >>> Sent: Monday, January 17, 2011 7:43 AM >>> To: Eran Hammer-Lahav; OAuth WG >>> Subject: Re: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >>> Credentials >>> >>> +1 to making BASIC optional. I don't think we were going to be >>> +supporting it >>> in general, either. >>> >>> =A0-- Justin >>> ________________________________________ >>> From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Eran >>> Hammer-Lahav [eran@hueniverse.com] >>> Sent: Saturday, January 15, 2011 1:53 AM >>> To: OAuth WG >>> Subject: [OAUTH-WG] Removal: HTTP Basic Authentication for Client >>> Credentials >>> >>> OAuth 2.0 provides two methods for client authentication using password >>> credentials: request parameters and HTTP Basic authentication. I sugges= t >>> we drop the requirement to support HTTP Basic authentication, and only >>> mention it as an example for alternative methods. My reasons are: >>> >>> >>> 1. =A0 =A0 =A0 A few providers have expressed concerns over the need to= support >>> Basic authentication, and some explicitly said they will not support it= . >>> Parameter-based authentication, OTOH, is widely deployed in 2.0. >>> >>> 2. =A0 =A0 =A0 Due to the way OAuth is being implemented at the HTTP >>> authentication >>> layer (even if it is wrong), can conflict within the framework as both = a >>> consumer and provider of authentication components. >>> >>> 3. =A0 =A0 =A0 The mapping between username and client_id, while not >>> complicated, >>> is still a big awkward, and can be confusing when combined with the >>> username and password grant type. On the other hand, the use of client_= id in >>> the end-user authorization endpoint lends itself nicely to the use of t= he >>> same parameter elsewhere. >>> >>> 4. =A0 =A0 =A0 Some existing authentication frameworks will have an iss= ue >>> handling >>> the mix of Basic authentication and parameters authentication due to ho= w >>> each is deployed. In cases where a front gate handles Basic, it will be= hard >>> to let requests through for parameter processing. >>> >>> Comments? Counter-arguments? >>> >>> 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 Tue Jan 18 20:21:38 2011 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 593093A702B for ; Tue, 18 Jan 2011 20:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.048, 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 hR-1JoYoWaOr for ; Tue, 18 Jan 2011 20:21:26 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9ED213A6EEF for ; Tue, 18 Jan 2011 20:21:26 -0800 (PST) Received: (qmail 15371 invoked from network); 19 Jan 2011 04:24:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 04:24:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 18 Jan 2011 21:24:03 -0700 From: Eran Hammer-Lahav To: Phil Hunt , "fcorella@pomcor.com" Date: Tue, 18 Jan 2011 21:23:57 -0700 Thread-Topic: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme Thread-Index: Acu3YXj3q+9Gi0rRQzaQVLE+Lq3CnQALpCtg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5D360C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <72524.62131.qm@web55804.mail.re3.yahoo.com> <3AFB9555-B33E-4534-94F0-521BE821C352@oracle.com> In-Reply-To: <3AFB9555-B33E-4534-94F0-521BE821C352@oracle.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_90C41DD21FB7C64BB94121FBBC2E723445A5D360C3P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 19 Jan 2011 04:21:38 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5D360C3P3PW5EX1MB01E_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks Phil. The problem with this text is that it doesn't add anything new and I am not= sure what Client Web Credentials even mean. I have argued against under-sp= ecified features and will continue to object their inclusion. When I initia= lly agreed to include Yaron's text for client assertion it was based on the= assumption that it will provoke discussion and will mature into a fully ba= ked feature. It has not. Instead, it sits there without enough details to p= roduce even a single working implementation, not to mention any level of in= teroperability what-so-ever. The specification clearly allows any kind of client authentication. How is = that not enough? How is providing two parameters that are useless without f= urther profiling in any way useful? If you need stronger alternatives to 3.= 1 you are very welcome to define and publish such in companion specificatio= ns. It feels like we are going in circles where a few people are arguing to= keep a feature that does not accomplish their reasons for its inclusion. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, January 18, 2011 2:45 PM To: fcorella@pomcor.com Cc: Eran Hammer-Lahav; Mike Jones; oauth@ietf.org; Karen P. Lewison Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme (apologies if this is a re-post, for some reason it was previously bounced) I've been arguing as well to keep client assertion or some other stronger a= lternative to 3.1. Re-reading the introduction to section 3, I see that th= e last paragraph says: The authorization server MAY authenticate the client using any appropriate = set of credentials and authentication schemes. The client MUST NOT include = more than one set of credentials or authentication mechanism with each requ= est. I would suggest the following. That we replace 3.2 with this paragraph exp= ressed as an alternative (move it from the introduction and a little massag= ing). The idea would be to make it clear that using normal web authenticat= ion methodologies is perfectly acceptable. Further, I would also suggest t= hat if an OOB authentication is use (and preferred), that the client_id mig= ht still be sent. This handles case where mapping between client_id and th= e client credentials is not obvious (or easy). How about: 3.2. Client Web (OOB) Credentials The client MAY be authenticated using any appropriate set of credentials an= d web authentication scheme supported by the authorization server. In cases= where the client_id cannot be mapped by the authorizing server from the cl= ient credential, the client_id MUST be provided.[should client_id always be= provided?] I would even include language that makes Client Web Credential authenticati= on the preferred methodology or at least list it first. This makes the spec more consistent in that OAuth is not involved in the au= thentication of the user or the client. -- it makes it more consistent. This approach will allow assertion based authentications (SAML, STS, etc) o= r other approaches without having to get hung up on how it should work insi= de of OAuth. Phil phil.hunt@oracle.com On 2011-01-18, at 12:26 PM, Francisco Corella wrote: Mike, As assertion use is described in the spec, a client assertion does not prov= ide any security whatsoever. How do you handle subject confirmation in you= r implementation? (See section 2.4.1.1 of the SAML specification.) In other word= s, how does the authorization server know that the client sending the asser= tion is actually the subject of the assertion? Francisco --- On Tue, 1/18/11, Mike Jones > wrote: From: Mike Jones > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and = OAuth2 HTTP Authentication Scheme To: "Eran Hammer-Lahav" > Cc: "oauth@ietf.org" > Date: Tuesday, January 18, 2011, 5:35 PM Having spoken to a number of people implementing the spec here, I've encoun= tered strong objections to removing Client Assertion Credentials and the OA= uth2 HTTP Authentication Scheme. It's also not clear to me why we would ma= ke substantial breaking changes to the specification when it is essentially= ready for approval. I've summarized the reasons I believe we should keep = these two features below. Client Assertion Credentials: Many of the scenarios we care about require = this capability. They were key motivators for the Assertion Profile in WRAP= (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have ru= nning code that requires this support. For example, the Azure Access Contro= l Service is a cloud Authorization server that supports several protocols, = including parts of OAuth 2.0 draft 10 (autonomous and web server profiles).= We are happy to update our implementation to subsequent drafts & agree tha= t the spec leaves a lot of ambiguity. In our implementation of the autonomous and web server profiles, ACS allows= clients to authenticate using a signed assertion as well as with a usernam= e/password. The username/pwd option is for clients that don't mind sending = credentials over the wire, while the signed assertion mechanism is for clie= nts that are more reticent to send raw credentials and for scenarios where = it isn't possible. To illustrate an example where username/pwd isn't viable= , consider the case of a client that needs to use an enterprise identity to= gain access to a cloud service. In many cases, corporate policy demands th= at a client use an identity managed by the organization. This means that th= e client should obtain an assertion from an enterprise identity provider (A= ctive Directory, Tivoli, etc.) and use that assertion to obtain an access t= oken which grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and reverting e= xclusively to username/pwd isn't an option for us. 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. Thanks, -- Mike -----Inline Attachment Follows----- _______________________________________________ OAuth mailing 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_90C41DD21FB7C64BB94121FBBC2E723445A5D360C3P3PW5EX1MB01E_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks Ph= il.

 

The problem with this text is that it doe= sn’t add anything new and I am not sure what Client Web Credentials e= ven mean. I have argued against under-specified features and will continue = to object their inclusion. When I initially agreed to include Yaron’s= text for client assertion it was based on the assumption that it will prov= oke discussion and will mature into a fully baked feature. It has not. Inst= ead, it sits there without enough details to produce even a single working = implementation, not to mention any level of interoperability what-so-ever.<= o:p>

 

The specification clearly allows any kind of = client authentication. How is that not enough? How is providing two paramet= ers that are useless without further profiling in any way useful? If you ne= ed stronger alternatives to 3.1 you are very welcome to define and publish = such in companion specifications. It feels like we are going in circles whe= re a few people are arguing to keep a feature that does not accomplish thei= r reasons for its inclusion.

 

EHL

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]=
Sent: Tuesday, January 18, 2011 2:45 PM
To: fcorella@= pomcor.com
Cc: Eran Hammer-Lahav; Mike Jones; oauth@ietf.org; Kar= en P. Lewison
Subject: Re: [OAUTH-WG] Reasons not to remove Clien= t Assertion Credentials and OAuth2 HTTP Authentication Scheme

 

(apologies if this is a re-post, for some reason it was previo= usly bounced)

 

I've been arguing as well to keep client a= ssertion or some other stronger alternative to 3.1.  Re-reading the in= troduction to section 3, I see that the last paragraph says:

=

 

The authorizat= ion server MAY authenticate the client using any appropriate set of credent= ials and authentication schemes. The client MUST NOT include more than one = set of credentials or authentication mechanism with each request.

 

I would suggest the following.  That we replace = 3.2 with this paragraph expressed as an alternative (move it from the intro= duction and a little massaging).  The idea would be to make it clear t= hat using normal web authentication methodologies is perfectly acceptable. =  Further, I would also suggest that if an OOB authentication is use (a= nd preferred), that the client_id might still be sent.  This handles c= ase where mapping between client_id and the client credentials is not obvio= us (or easy). 

&nbs= p;

How about:

=

 

3.2. Client We= b (OOB) Credentials


The client MAY be authenticated using any appropriate set of credentia= ls and web authentication scheme supported by the authorization server. In = cases where the client_id cannot be mapped by the authorizing server f= rom the client credential, the client_id MUST be provided.[should client_id= always be provided?]

 

I would even in= clude language that makes Client Web Credential authentication the preferre= d methodology or at least list it first.

 

This make= s the spec more consistent in that OAuth is not involved in the authenticat= ion of the user or the client. -- it makes it more consistent.

 

This approach will allow assertion based authentications (SAML= , STS, etc) or other approaches without having to get hung up on how it sho= uld work inside of OAuth.

 

= Phil

 

On 2011-01-18, at 12:26 PM, Francisco Corella wrote:<= /o:p>



<= /tr>

Mike,

As a= ssertion use is described in the spec, a client assertion does not provide = any security whatsoever.  How do you handle subject confirmation in yo= ur implementation?  (See section 2.4.1.1 of the SAML specification= .)  In other words, how does the authorization server know that th= e client sending the assertion is actually the subject of the assertion?
Francisco

--- On Tue, 1/18/11, Mike Jones <Michael.Jones@microsoft.com>= wrote:


From: Mike Jones <= Michael.Jones@microsoft.com>
Subject: [OAUTH-WG] Reasons not to r= emove Client Assertion Credentials and OAuth2 HTTP Authentication SchemeTo: "Eran Hammer-Lahav" <eran@hueniverse.com>
Cc: "oauth@ietf.org" <oauth@iet= f.org>
Date: Tuesday, January 18, 2011, 5:35 PM

Having spoken t= o a number of people implementing the spec here, I’ve encountered str= ong objections to removing Client Assertion Credentials and the OAuth2 HTTP= Authentication Scheme.  It’s also not clear to me why we would = make substantial breaking changes to the specification when it is essential= ly ready for approval.  I’ve summarized the reasons I believe we= should keep these two features below.

 

Client = Assertion Credentials:  Many of the scenarios we care about requir= e this capability. They were key motivators for the Assertion Profile in WR= AP (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have = running code that requires this support. For example, the Azure Access Cont= rol Service is a cloud Authorization server that supports several protocols= , including parts of OAuth 2.0 draft 10 (autonomous and web server profiles= ). We are happy to update our implementation to subsequent drafts & agr= ee that the spec leaves a lot of ambiguity.

 

In ou= r implementation of the autonomous and web server profiles, ACS allows clie= nts to authenticate using a signed assertion as well as with a username/pas= sword. The username/pwd option is for clients that don’t mind sending= credentials over the wire, while the signed assertion mechanism is for cli= ents that are more reticent to send raw credentials and for scenarios where= it isn’t possible. To illustrate an example where username/pwd isn&#= 8217;t viable, consider the case of a client that needs to use an enterpris= e identity to gain access to a cloud service. In many cases, corporate poli= cy demands that a client use an identity managed by the organization. This = means that the client should obtain an assertion from an enterprise identit= y provider (Active Directory, Tivoli, etc.) and use that assertion to obtai= n an access token which grants access to various web service APIs. Many of = our key MSFT customers and internal partner teams rely on this mechanism an= d reverting exclusively to username/pwd isn’t an option for us.<= /o:p>

 

'OAuth2' HTTP Authentication Scheme:  Simp= ly put, dropping this seems like a huge step away from interoperability.&nb= sp; As one data point, Microsoft implements this in our WIF OAuth2 protecte= d resource code.  All up, clients need a way to authenticate to the pr= otected resource.  Also, existing WRAP implementations need this funct= ionality to migrate to OAuth2.   For all these reasons, we suppor= t retaining this functionality in OAuth2.

 

 &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        Thanks,

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

 <= /p>

-----Inline Attachment Follows-----

_______________________________________________
OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth

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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A5D360C3P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jan 18 20:31:32 2011 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 CB17F3A70C3 for ; Tue, 18 Jan 2011 20:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.048, 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 AieGlPF6mSpC for ; Tue, 18 Jan 2011 20:31:20 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E0F153A70C7 for ; Tue, 18 Jan 2011 20:31:19 -0800 (PST) Received: (qmail 15417 invoked from network); 19 Jan 2011 04:33:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 04:33:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 18 Jan 2011 21:33:58 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Tue, 18 Jan 2011 21:33:53 -0700 Thread-Topic: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme Thread-Index: Acu3NiSHXpF3O14eTPqlwk2IwSAdgAAArk0wAAupkeAACkwYEA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A5D360C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EE49E@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246EE49E@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A5D360C6P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 19 Jan 2011 04:31:33 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A5D360C6P3PW5EX1MB01E_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First, there was no 'implementation call' or any official process calling a= ny draft final. I consider it stable, and close to finish, but that doesn't= mean every word is now sacred. Playing the 'who needs to get consensus' ga= me is counterproductive. I offered specific concerns about the text, both f= unctionality-wise and prose-wise. You have agreed it is incomplete. Your *sole* argument is that since it is already in the specification and M= icrosoft implemented it, it must say. That argument does not stand. I asked= direct questions which you consistently ignored. I'll try one more time: 1. How does the current language provides interoperability or even en= ough detail for any kind of running-code? 2. Who else besides Microsoft implemented client credentials based on= this section (or plans to), and where is their required addition specifica= tions? 3. How will removing this language break any running code (given that= the two parameters will then become perfectly legal extensions)? How is th= is *any* different from moving the 'assertion' parameter from the framework= specification to the SAML assertion specification (as we agreed on the lis= t already and is partially published)? I took the time and effort to write a thoughtful proposal and raise valid c= oncerns. I would be greatly appreciated if you did the same and actually ad= dressed my concerns instead of using process argument. Process-wise, it is = within my prerogative as editor to remove a section of the specification an= d pass it to the chairs to determine consensus. I rather have a thoughtful= debate instead. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Tuesday, January 18, 2011 3:32 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: RE: Reasons not to remove Client Assertion Credentials and OAuth2 = HTTP Authentication Scheme You wrote: "Those who still want to advocate for it need to show not only = consensus for keeping it...". This seems backwards to me. In particular, = given the industry consensus that draft 10 was "nearly done", the onus to e= stablish consensus should fall on advocates of any proposals to remove feat= ures - not the other way around - particularly so when the features are imp= lemented and in use. It's also pertinent that the implementation call went out for draft 11. Th= erefore, we should not be removing draft 11 features without decisive conse= nsus for doing so. -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, January 18, 2011 10:13 AM To: Mike Jones Cc: oauth@ietf.org Subject: RE: Reasons not to remove Client Assertion Credentials and OAuth2 = HTTP Authentication Scheme I agree that at this stage, we should do our best to avoid making breaking = changes. But first, we need to establish what is going to break and how. The argument that removing the client assertion credentials affects interop= erability or breaks implementations is without merit. As currently specified, the text is useless for any level of interoperabili= ty or implementation. This means you must have your own specification provi= ding the actual meaningful information. At most, removing this section will= require you to register the two parameter names it defines. Since neither = is being used for a new purpose, removing this section creates no conflict.= Hopefully, your parameter registration will provide more meaningful inform= ation about them than currently offered. If you are going to object to my conclusions, you first need to show where = my arguments are wrong. I have seen nothing to contradict a single point I = have made about both issues. This goes for both the client assertion creden= tials and OAuth2 scheme. Just in case, I'll repeat my points. Client assertion credentials: 1. The mechanism is under specified, especially in its handling of the cl= ient_id identifier (when used to obtain end-user authorization). 2. It does not contain any implementation details to accomplish any level= of interoperability or functionality. 3. The section is a confused mix of security considerations sprinkled wit= h normative language. 4. Those who still want to advocate for it need to show not only consensu= s for keeping it, but also active community support for deploying it. Deplo= yment, of course, will also require showing progress on public specificatio= ns profiling the mechanism into a useful interoperable feature. Which open = source library supports or plan to support it? 'OAuth2' WWW-Authenticate header: 1. Draft oauth-v2 is clearly not an authentication protocol. It *utilizes= * client authentication. It offers one fully defined method for client auth= entication (which is basically HTTP Basic+), provides a half-baked client a= ssertion authentication hook, and leaves all end-user authentication out of= scope. 2. The WWW-Authenticate header has absolutely no value, interoperability-= wise or otherwise. Discovery was rules to be beyond the scope of this speci= fication. Having a protected resource declare it supports authentication us= ing some unspecified credentials obtained using some unspecified client flo= w is confusing at best. 3. OAuth is agnostic to token authentication, and we already have three d= iscrete token type proposals - all with active deployment plans in the comi= ng months. 4. HTTP *authentication* is not an appropriate facility to negotiate *aut= horization*. OAuth authorization discovery can be added to HTTP authenticat= ion schemes as attributes, but makes no sense as a scheme of its own. The i= ssues we are having with 'realm' is one of the examples showing that we are= abusing the header. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Tuesday, January 18, 2011 9:36 AM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP= Authentication Scheme Having spoken to a number of people implementing the spec here, I've encoun= tered strong objections to removing Client Assertion Credentials and the OA= uth2 HTTP Authentication Scheme. It's also not clear to me why we would ma= ke substantial breaking changes to the specification when it is essentially= ready for approval. I've summarized the reasons I believe we should keep = these two features below. Client Assertion Credentials: Many of the scenarios we care about require = this capability. They were key motivators for the Assertion Profile in WRAP= (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have ru= nning code that requires this support. For example, the Azure Access Contro= l Service is a cloud Authorization server that supports several protocols, = including parts of OAuth 2.0 draft 10 (autonomous and web server profiles).= We are happy to update our implementation to subsequent drafts & agree tha= t the spec leaves a lot of ambiguity. In our implementation of the autonomous and web server profiles, ACS allows= clients to authenticate using a signed assertion as well as with a usernam= e/password. The username/pwd option is for clients that don't mind sending = credentials over the wire, while the signed assertion mechanism is for clie= nts that are more reticent to send raw credentials and for scenarios where = it isn't possible. To illustrate an example where username/pwd isn't viable= , consider the case of a client that needs to use an enterprise identity to= gain access to a cloud service. In many cases, corporate policy demands th= at a client use an identity managed by the organization. This means that th= e client should obtain an assertion from an enterprise identity provider (A= ctive Directory, Tivoli, etc.) and use that assertion to obtain an access t= oken which grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and reverting e= xclusively to username/pwd isn't an option for us. 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. Thanks, -- Mike --_000_90C41DD21FB7C64BB94121FBBC2E723445A5D360C6P3PW5EX1MB01E_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

First, there was no ‘implementation call’ or any = official process calling any draft final. I consider it stable, and close t= o finish, but that doesn’t mean every word is now sacred. Playing the= ‘who needs to get consensus’ game is counterproductive. I offe= red specific concerns about the text, both functionality-wise and prose-wis= e. You have agreed it is incomplete.

 

Your *sole* argument is that s= ince it is already in the specification and Microsoft implemented it, it mu= st say. That argument does not stand. I asked direct questions which you co= nsistently ignored. I’ll try one more time:

 

=

1.  &n= bsp;    How does the current language provides interoperability or even en= ough detail for any kind of running-code?

2.    &n= bsp;  Who= else besides Microsoft implemented client credentials based on this sectio= n (or plans to), and where is their required addition specifications?<= /o:p>

3.How will removing this language break any running = code (given that the two parameters will then become perfectly legal extens= ions)? How is this *any* different from moving the ‘assertion&= #8217; parameter from the framework specification to the SAML assertion spe= cification (as we agreed on the list already and is partially published)?

 

= I took the time and effort to write a thoughtful proposal and raise valid c= oncerns. I would be greatly appreciated if you did the same and actually ad= dressed my concerns instead of using process argument. Process-wise, it is = within my prerogative as editor to remove a section of the specification an= d pass it to the chairs to determine consensus.=A0 I rather have a thoughtf= ul debate instead.

 

EHL

 

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
= Sent: Tuesday, January 18, 2011 3:32 PM
To: Eran Hammer-Lahav=
Cc: oauth@ietf.org
Subject: RE: Reasons not to remove = Client Assertion Credentials and OAuth2 HTTP Authentication Scheme

 

You wrote:  “Those wh= o still want to advocate for it need to show not only consensus for keeping= it…”.  This seems backwards to me.  In particular, g= iven the industry consensus that draft 10 was “nearly done”, th= e onus to establish consensus should fall on advocates of any proposals to = remove features – not the other way around – particularly so wh= en the features are implemented and in use.

 

It’s also pertinent th= at the implementation call went out for draft 11.  Therefore, we shoul= d not be removing draft 11 features without decisive consensus for doing so= .

<= o:p> 

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

 <= /o:p>

From: Eran Hammer-Lahav = [mailto:eran@hueniverse.com]
Sent: Tuesday, January 18, 2011 10:= 13 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject:<= /b> RE: Reasons not to remove Client Assertion Credentials and OAuth2 HTTP = Authentication Scheme

 

I = agree that at this stage, we should do our best to avoid making breaking ch= anges. But first, we need to establish what is going to break and how.=

&n= bsp;

The= argument that removing the client assertion credentials affects interopera= bility or breaks implementations is without merit.

 

As currently specified,= the text is useless for any level of interoperability or implementation. T= his means you must have your own specification providing the actual meaning= ful information. At most, removing this section will require you to registe= r the two parameter names it defines. Since neither is being used for a new= purpose, removing this section creates no conflict. Hopefully, your parame= ter registration will provide more meaningful information about them than c= urrently offered.

 

If you are going to object to my conclusions, you first = need to show where my arguments are wrong. I have seen nothing to contradic= t a single point I have made about both issues. This goes for both the clie= nt assertion credentials and OAuth2 scheme.

 

Just in case, I’ll rep= eat my points.

 

Client assertion credentials:

 

  1. The mechanism is under specified, es= pecially in its handling of the client_id identifier (when used to obtain e= nd-user authorization).
  2. It does not contain any implementation de= tails to accomplish any level of interoperability or functionality.
  3. The section is a confused mix of security considerations sprinkled with = normative language.
  4. Those who still want to advocate for it need = to show not only consensus for keeping it, but also active community suppor= t for deploying it. Deployment, of course, will also require showing progre= ss on public specifications profiling the mechanism into a useful interoper= able feature. Which open source library supports or plan to support it?

&n= bsp;

= 216;OAuth2’ WWW-Authenticate header:

 

  1. Draft oauth-v2 is clearly not an authen= tication protocol. It *utilizes* client authentication. It offers on= e fully defined method for client authentication (which is basically HTTP B= asic+), provides a half-baked client assertion authentication hook, and lea= ves all end-user authentication out of scope.
  2. The WWW-Authenticat= e header has absolutely no value, interoperability-wise or otherwise. Disco= very was rules to be beyond the scope of this specification. Having a prote= cted resource declare it supports authentication using some unspecified cre= dentials obtained using some unspecified client flow is confusing at best. =
  3. OAuth is agnostic to token authentication, and we already have t= hree discrete token type proposals – all with active deployment plans= in the coming months.
  4. HTTP *authentication* is not an app= ropriate facility to negotiate *authorization*. OAuth authorization = discovery can be added to HTTP authentication schemes as attributes, but ma= kes no sense as a scheme of its own. The issues we are having with ‘r= ealm’ is one of the examples showing that we are abusing the header.<= o:p>

 

= EHL

 

 

 

F= rom: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Tu= esday, January 18, 2011 9:36 AM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Reasons not to remove Client Assertion= Credentials and OAuth2 HTTP Authentication Scheme

 

Hav= ing spoken to a number of people implementing the spec here, I’ve enc= ountered strong objections to removing Client Assertion Credentials and the= OAuth2 HTTP Authentication Scheme.  It’s also not clear to me w= hy we would make substantial breaking changes to the specification when it = is essentially ready for approval.  I’ve summarized the reasons = I believe we should keep these two features below.

 

Client Assertion = Credentials:  Many of the scenarios we care about require this cap= ability. They were key motivators for the Assertion Profile in WRAP (see = =A7 5.2), have been part of OAuth 2 for quite a while, and we have running = code that requires this support. For example, the Azure Access Control Serv= ice is a cloud Authorization server that supports several protocols, includ= ing parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We ar= e happy to update our implementation to subsequent drafts & agree that = the spec leaves a lot of ambiguity.

 

In our implementation of the autonomo= us and web server profiles, ACS allows clients to authenticate using a sign= ed assertion as well as with a username/password. The username/pwd option i= s for clients that don’t mind sending credentials over the wire, whil= e the signed assertion mechanism is for clients that are more reticent to s= end raw credentials and for scenarios where it isn’t possible. To ill= ustrate an example where username/pwd isn’t viable, consider the case= of a client that needs to use an enterprise identity to gain access to a c= loud service. In many cases, corporate policy demands that a client use an = identity managed by the organization. This means that the client should obt= ain an assertion from an enterprise identity provider (Active Directory, Ti= voli, etc.) and use that assertion to obtain an access token which grants a= ccess to various web service APIs. Many of our key MSFT customers and inter= nal partner teams rely on this mechanism and reverting exclusively to usern= ame/pwd isn’t an option for us.

 

'OAuth2' HTTP Authentication Sch= eme:  Simply put, dropping this seems like a huge step away from i= nteroperability.  As one data point, Microsoft implements this in our = WIF OAuth2 protected resource code.  All up, clients need a way to aut= henticate to the protected resource.  Also, existing WRAP implementati= ons need this functionality to migrate to OAuth2.   For all these= reasons, we support retaining this functionality in OAuth2.

=

 

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

          &n= bsp;            = ;            &n= bsp;            = ;            -- Mike=

 

= = --_000_90C41DD21FB7C64BB94121FBBC2E723445A5D360C6P3PW5EX1MB01E_-- From phil.hunt@oracle.com Tue Jan 18 21:39:42 2011 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 6688728C0DC for ; Tue, 18 Jan 2011 21:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.481 X-Spam-Level: X-Spam-Status: No, score=-6.481 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 OgpcBULqb3D0 for ; Tue, 18 Jan 2011 21:39:40 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 1B46A28C0DB for ; Tue, 18 Jan 2011 21:39:40 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0J5gHTY028542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 05:42:18 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0J5HSH1002730; Wed, 19 Jan 2011 05:42:15 GMT Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 935738891295415654; Tue, 18 Jan 2011 21:40:54 -0800 Received: from dhcp184-48-56-187.ssb.sjc.wayport.net (/12.199.6.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jan 2011 21:40:53 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-7--720188964 From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5D360C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 18 Jan 2011 21:23:10 -0800 Message-Id: References: <72524.62131.qm@web55804.mail.re3.yahoo.com> <3AFB9555-B33E-4534-94F0-521BE821C352@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D360C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 19 Jan 2011 05:39:42 -0000 --Apple-Mail-7--720188964 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Eran, Yes, I agree it feels like we're going in circles. Might I point out = who it was that started this round? ;-) Still, I think the discussion = is useful and important. 3.0 introduces the concept (that any client authentication is = acceptable) but then specifies 2 acceptable methods (3.1 and 3.2) and = leaves out other forms of client authentication. The specification can = be interpreted that the "any types" of methods supported are 3.1 and 3.2 = ONLY. It just seems that the current spec has awkward phrasing. My suggestion was simply to drop client_assertion and replace with some = text indicating what "any client authentication" is. Assertion based = authentication would then be supported via the new paragraph 2 which = allows for any kind of client authentication (SAML, Kerberos, STS, = whatever). Just to add another loop, what about cutting out the entire section 3 = and keep client_id as a required parameter in 4 and 5 (related to but = not directly tied to authentication) -- and getting OAuth out of = authentication methods entirely (other then to specify it as a = requirement)? =20 Phil phil.hunt@oracle.com On 2011-01-18, at 8:23 PM, Eran Hammer-Lahav wrote: > Thanks Phil. > =20 > The problem with this text is that it doesn=92t add anything new and I = am not sure what Client Web Credentials even mean. > I have argued against under-specified features and will continue to = object their inclusion. When I initially agreed to include Yaron=92s = text for client assertion it was based on the assumption that it will = provoke discussion and will mature into a fully baked feature. It has = not. Instead, it sits there without enough details to produce even a = single working implementation, not to mention any level of = interoperability what-so-ever. > =20 > The specification clearly allows any kind of client authentication. = How is that not enough? How is providing two parameters that are useless = without further profiling in any way useful? If you need stronger = alternatives to 3.1 you are very welcome to define and publish such in = companion specifications. It feels like we are going in circles where a = few people are arguing to keep a feature that does not accomplish their = reasons for its inclusion. > =20 > EHL > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, January 18, 2011 2:45 PM > To: fcorella@pomcor.com > Cc: Eran Hammer-Lahav; Mike Jones; oauth@ietf.org; Karen P. Lewison > Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion = Credentials and OAuth2 HTTP Authentication Scheme > =20 > (apologies if this is a re-post, for some reason it was previously = bounced) > =20 > I've been arguing as well to keep client assertion or some other = stronger alternative to 3.1. Re-reading the introduction to section 3, = I see that the last paragraph says: > =20 > The authorization server MAY authenticate the client using any = appropriate set of credentials and authentication schemes. The client = MUST NOT include more than one set of credentials or authentication = mechanism with each request. > =20 > I would suggest the following. That we replace 3.2 with this = paragraph expressed as an alternative (move it from the introduction and = a little massaging). The idea would be to make it clear that using = normal web authentication methodologies is perfectly acceptable. = Further, I would also suggest that if an OOB authentication is use (and = preferred), that the client_id might still be sent. This handles case = where mapping between client_id and the client credentials is not = obvious (or easy).=20 > =20 > How about: > =20 > 3.2. Client Web (OOB) Credentials >=20 > The client MAY be authenticated using any appropriate set of = credentials and web authentication scheme supported by the authorization = server. In cases where the client_id cannot be mapped by the authorizing = server from the client credential, the client_id MUST be = provided.[should client_id always be provided?] > =20 > I would even include language that makes Client Web Credential = authentication the preferred methodology or at least list it first. > =20 > This makes the spec more consistent in that OAuth is not involved in = the authentication of the user or the client. -- it makes it more = consistent. > =20 > This approach will allow assertion based authentications (SAML, STS, = etc) or other approaches without having to get hung up on how it should = work inside of OAuth. > =20 > Phil > phil.hunt@oracle.com > =20 >=20 >=20 > =20 > On 2011-01-18, at 12:26 PM, Francisco Corella wrote: >=20 >=20 > Mike, >=20 > As assertion use is described in the spec, a client assertion does not = provide any security whatsoever. How do you handle subject confirmation = in your implementation? (See section 2.4.1.1 of the SAML = specification.) In other words, how does the authorization server know = that the client sending the assertion is actually the subject of the = assertion? >=20 > Francisco >=20 > --- On Tue, 1/18/11, Mike Jones wrote: >=20 > From: Mike Jones > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme > To: "Eran Hammer-Lahav" > Cc: "oauth@ietf.org" > Date: Tuesday, January 18, 2011, 5:35 PM >=20 > Having spoken to a number of people implementing the spec here, I=92ve = encountered strong objections to removing Client Assertion Credentials = and the OAuth2 HTTP Authentication Scheme. It=92s also not clear to me = why we would make substantial breaking changes to the specification when = it is essentially ready for approval. I=92ve summarized the reasons I = believe we should keep these two features below. >=20 > =20 > Client Assertion Credentials: Many of the scenarios we care about = require this capability. They were key motivators for the Assertion = Profile in WRAP (see =A7 5.2), have been part of OAuth 2 for quite a = while, and we have running code that requires this support. For example, = the Azure Access Control Service is a cloud Authorization server that = supports several protocols, including parts of OAuth 2.0 draft 10 = (autonomous and web server profiles). We are happy to update our = implementation to subsequent drafts & agree that the spec leaves a lot = of ambiguity. >=20 > =20 > In our implementation of the autonomous and web server profiles, ACS = allows clients to authenticate using a signed assertion as well as with = a username/password. The username/pwd option is for clients that don=92t = mind sending credentials over the wire, while the signed assertion = mechanism is for clients that are more reticent to send raw credentials = and for scenarios where it isn=92t possible. To illustrate an example = where username/pwd isn=92t viable, consider the case of a client that = needs to use an enterprise identity to gain access to a cloud service. = In many cases, corporate policy demands that a client use an identity = managed by the organization. This means that the client should obtain an = assertion from an enterprise identity provider (Active Directory, = Tivoli, etc.) and use that assertion to obtain an access token which = grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and = reverting exclusively to username/pwd isn=92t an option for us. >=20 > =20 > 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems = like a huge step away from interoperability. As one data point, = Microsoft implements this in our WIF OAuth2 protected resource code. = All up, clients need a way to authenticate to the protected resource. = Also, existing WRAP implementations need this functionality to migrate = to OAuth2. For all these reasons, we support retaining this = functionality in OAuth2. >=20 > =20 > Thanks, >=20 > -- Mike >=20 > =20 >=20 > -----Inline Attachment Follows----- >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-7--720188964 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

My = suggestion was simply to drop client_assertion and replace with = some text indicating what "any client authentication" is. =  Assertion based authentication would then be supported via the new = paragraph 2 which allows for  any kind of client authentication = (SAML, Kerberos, STS, whatever).

Just to add = another loop, what about cutting out the entire section 3 and keep = client_id as a required parameter in 4 and 5 (related to but not = directly tied to authentication) -- and getting OAuth out of = authentication methods entirely (other then to specify it as a = requirement)?
  

On 2011-01-18, at 8:23 PM, Eran Hammer-Lahav = wrote:

The = problem with this text is that it doesn=92t add anything new and I am = not sure what Client Web Credentials even = mean.
I = have argued against under-specified features and will continue to object = their inclusion. When I initially agreed to include Yaron=92s text for = client assertion it was based on the assumption that it will provoke = discussion and will mature into a fully baked feature. It has not. = Instead, it sits there without enough details to produce even a single = working implementation, not to mention any level of interoperability = what-so-ever.
The = specification clearly allows any kind of client authentication. How is = that not enough? How is providing two parameters that are useless = without further profiling in any way useful? If you need stronger = alternatives to 3.1 you are very welcome to define and publish such in = companion specifications. It feels like we are going in circles where a = few people are arguing to keep a feature that does not accomplish their = reasons for its = inclusion.
 Phil = Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday, January 18, 2011 = 2:45 PM
To: fcorella@pomcor.com
Cc: Eran Hammer-Lahav; Mike = Jones; oauth@ietf.org; Karen P. = Lewison
Subject: Re: [OAUTH-WG] Reasons not = to remove Client Assertion Credentials and OAuth2 HTTP Authentication = Scheme
(apologies if this is a = re-post, for some reason it was previously = bounced)
I've been arguing as well = to keep client assertion or some other stronger alternative to 3.1. =  Re-reading the introduction to section 3, I see that the last = paragraph says:
The authorization server MAY authenticate = the client using any appropriate set of credentials and authentication = schemes. The client MUST NOT include more than one set of credentials or = authentication mechanism with each = request.
I would suggest the = following.  That we replace 3.2 with this paragraph expressed as an = alternative (move it from the introduction and a little massaging). =  The idea would be to make it clear that using normal web = authentication methodologies is perfectly acceptable.  Further, I = would also suggest that if an OOB authentication is use (and preferred), = that the client_id might still be sent.  This handles case where = mapping between client_id and the client credentials is not obvious (or = easy). 
How = about:
3.2. Client Web (OOB) = Credentials

The = client MAY be authenticated using any appropriate set of credentials and = web authentication scheme supported by the authorization server. In = cases where the client_id cannot be mapped by the authorizing = server from the client credential, the client_id MUST be = provided.[should client_id always be = provided?]
 
I would even = include language that makes Client Web Credential authentication the = preferred methodology or at least list it = first.
This makes the spec more = consistent in that OAuth is not involved in the authentication of the = user or the client. -- it makes it more = consistent.
This approach will allow = assertion based authentications (SAML, STS, etc) or other approaches = without having to get hung up on how it should work inside of = OAuth.


Mike,

As assertion = use is described in the spec, a client assertion does not provide any = security whatsoever.  How do you handle subject confirmation in = your implementation?  (See section 2.4.1.1 of the SAML = specification.)  In other words, how does the authorization = server know that the client sending the assertion is actually the = subject of the assertion?

Francisco

--- On Tue, 1/18/11, Mike = Jones < wrote:


From: Mike Jones <eran@hueniverse.com>
Cc: "oauth@ietf.org" <

Having spoken to a number of people implementing the spec here, = I=92ve encountered strong objections to removing Client Assertion = Credentials and the OAuth2 HTTP Authentication Scheme.  It=92s also = not clear to me why we would make substantial breaking changes to the = specification when it is essentially ready for approval.  I=92ve = summarized the reasons I believe we should keep these two features = below.

Client Assertion Credentials:  Many of the = scenarios we care about require this capability. They were key = motivators for the Assertion Profile in WRAP (see =A7 5.2), have been = part of OAuth 2 for quite a while, and we have running code that = requires this support. For example, the Azure Access Control Service is = a cloud Authorization server that supports several protocols, including = parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We are = happy to update our implementation to subsequent drafts & agree that = the spec leaves a lot of ambiguity.

In our implementation of the = autonomous and web server profiles, ACS allows clients to authenticate = using a signed assertion as well as with a username/password. The = username/pwd option is for clients that don=92t mind sending credentials = over the wire, while the signed assertion mechanism is for clients that = are more reticent to send raw credentials and for scenarios where it = isn=92t possible. To illustrate an example where username/pwd isn=92t = viable, consider the case of a client that needs to use an enterprise = identity to gain access to a cloud service. In many cases, corporate = policy demands that a client use an identity managed by the = organization. This means that the client should obtain an assertion from = an enterprise identity provider (Active Directory, Tivoli, etc.) and use = that assertion to obtain an access token which grants access to various = web service APIs. Many of our key MSFT customers and internal partner = teams rely on this mechanism and reverting exclusively to username/pwd = isn=92t an option for us.


<= /div>= --Apple-Mail-7--720188964-- From eran@hueniverse.com Tue Jan 18 22:03:55 2011 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 9953C3A6C42 for ; Tue, 18 Jan 2011 22:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.047, 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 nzhMPAwLMN77 for ; Tue, 18 Jan 2011 22:03:43 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 47F093A6DA2 for ; Tue, 18 Jan 2011 22:03:43 -0800 (PST) Received: (qmail 16485 invoked from network); 19 Jan 2011 06:06:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 06:06:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 18 Jan 2011 23:06:20 -0700 From: Eran Hammer-Lahav To: Phil Hunt Date: Tue, 18 Jan 2011 23:06:15 -0700 Thread-Topic: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme Thread-Index: Acu3nBRJei7Ksqq0RDmuyC4MxPMoQAAAo3LA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D88F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <72524.62131.qm@web55804.mail.re3.yahoo.com> <3AFB9555-B33E-4534-94F0-521BE821C352@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D360C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D88FP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 19 Jan 2011 06:03:56 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D88FP3PW5EX1MB01E_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes! This is exactly what I proposed if you combine removing Basic together= with the assertion credentials. Basically, provide the parameter based app= roach as the only one specified, make it clear that *any* suitable client a= uthentication is allowed, and then use HTTP Basic as an example of such oth= er methods. I am even happy to explicitly mention the use of assertions for= client authentication in the prose. I just don't think another sub-section= is needed. Would that be what you had in mind? EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, January 18, 2011 9:23 PM To: Eran Hammer-Lahav Cc: fcorella@pomcor.com; Mike Jones; oauth@ietf.org; Karen P. Lewison Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme Eran, Yes, I agree it feels like we're going in circles. Might I point out who i= t was that started this round? ;-) Still, I think the discussion is useful= and important. 3.0 introduces the concept (that any client authentication is acceptable) b= ut then specifies 2 acceptable methods (3.1 and 3.2) and leaves out other f= orms of client authentication. The specification can be interpreted that t= he "any types" of methods supported are 3.1 and 3.2 ONLY. It just seems th= at the current spec has awkward phrasing. My suggestion was simply to drop client_assertion and replace with some tex= t indicating what "any client authentication" is. Assertion based authenti= cation would then be supported via the new paragraph 2 which allows for an= y kind of client authentication (SAML, Kerberos, STS, whatever). Just to add another loop, what about cutting out the entire section 3 and k= eep client_id as a required parameter in 4 and 5 (related to but not direct= ly tied to authentication) -- and getting OAuth out of authentication metho= ds entirely (other then to specify it as a requirement)? Phil phil.hunt@oracle.com On 2011-01-18, at 8:23 PM, Eran Hammer-Lahav wrote: Thanks Phil. The problem with this text is that it doesn't add anything new and I am not= sure what Client Web Credentials even mean. I have argued against under-specified features and will continue to object = their inclusion. When I initially agreed to include Yaron's text for client= assertion it was based on the assumption that it will provoke discussion a= nd will mature into a fully baked feature. It has not. Instead, it sits the= re without enough details to produce even a single working implementation, = not to mention any level of interoperability what-so-ever. The specification clearly allows any kind of client authentication. How is = that not enough? How is providing two parameters that are useless without f= urther profiling in any way useful? If you need stronger alternatives to 3.= 1 you are very welcome to define and publish such in companion specificatio= ns. It feels like we are going in circles where a few people are arguing to= keep a feature that does not accomplish their reasons for its inclusion. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, January 18, 2011 2:45 PM To: fcorella@pomcor.com Cc: Eran Hammer-Lahav; Mike Jones; oauth@ietf.org; K= aren P. Lewison Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme (apologies if this is a re-post, for some reason it was previously bounced) I've been arguing as well to keep client assertion or some other stronger a= lternative to 3.1. Re-reading the introduction to section 3, I see that th= e last paragraph says: The authorization server MAY authenticate the client using any appropriate = set of credentials and authentication schemes. The client MUST NOT include = more than one set of credentials or authentication mechanism with each requ= est. I would suggest the following. That we replace 3.2 with this paragraph exp= ressed as an alternative (move it from the introduction and a little massag= ing). The idea would be to make it clear that using normal web authenticat= ion methodologies is perfectly acceptable. Further, I would also suggest t= hat if an OOB authentication is use (and preferred), that the client_id mig= ht still be sent. This handles case where mapping between client_id and th= e client credentials is not obvious (or easy). How about: 3.2. Client Web (OOB) Credentials The client MAY be authenticated using any appropriate set of credentials an= d web authentication scheme supported by the authorization server. In cases= where the client_id cannot be mapped by the authorizing server from the cl= ient credential, the client_id MUST be provided.[should client_id always be= provided?] I would even include language that makes Client Web Credential authenticati= on the preferred methodology or at least list it first. This makes the spec more consistent in that OAuth is not involved in the au= thentication of the user or the client. -- it makes it more consistent. This approach will allow assertion based authentications (SAML, STS, etc) o= r other approaches without having to get hung up on how it should work insi= de of OAuth. Phil phil.hunt@oracle.com On 2011-01-18, at 12:26 PM, Francisco Corella wrote: Mike, As assertion use is described in the spec, a client assertion does not prov= ide any security whatsoever. How do you handle subject confirmation in you= r implementation? (See section 2.4.1.1 of the SAML specification.) In other word= s, how does the authorization server know that the client sending the asser= tion is actually the subject of the assertion? Francisco --- On Tue, 1/18/11, Mike Jones > wrote: From: Mike Jones > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and = OAuth2 HTTP Authentication Scheme To: "Eran Hammer-Lahav" > Cc: "oauth@ietf.org" > Date: Tuesday, January 18, 2011, 5:35 PM Having spoken to a number of people implementing the spec here, I've encoun= tered strong objections to removing Client Assertion Credentials and the OA= uth2 HTTP Authentication Scheme. It's also not clear to me why we would ma= ke substantial breaking changes to the specification when it is essentially= ready for approval. I've summarized the reasons I believe we should keep = these two features below. Client Assertion Credentials: Many of the scenarios we care about require = this capability. They were key motivators for the Assertion Profile in WRAP= (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have ru= nning code that requires this support. For example, the Azure Access Contro= l Service is a cloud Authorization server that supports several protocols, = including parts of OAuth 2.0 draft 10 (autonomous and web server profiles).= We are happy to update our implementation to subsequent drafts & agree tha= t the spec leaves a lot of ambiguity. In our implementation of the autonomous and web server profiles, ACS allows= clients to authenticate using a signed assertion as well as with a usernam= e/password. The username/pwd option is for clients that don't mind sending = credentials over the wire, while the signed assertion mechanism is for clie= nts that are more reticent to send raw credentials and for scenarios where = it isn't possible. To illustrate an example where username/pwd isn't viable= , consider the case of a client that needs to use an enterprise identity to= gain access to a cloud service. In many cases, corporate policy demands th= at a client use an identity managed by the organization. This means that th= e client should obtain an assertion from an enterprise identity provider (A= ctive Directory, Tivoli, etc.) and use that assertion to obtain an access t= oken which grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and reverting e= xclusively to username/pwd isn't an option for us. 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. Thanks, -- Mike -----Inline Attachment Follows----- _______________________________________________ OAuth mailing 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_90C41DD21FB7C64BB94121FBBC2E723445A6B9D88FP3PW5EX1MB01E_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Yes! This= is exactly what I proposed if you combine removing Basic together with the= assertion credentials. Basically, provide the parameter based approach as = the only one specified, make it clear that *any* suitable client aut= hentication is allowed, and then use HTTP Basic as an example of such other= methods. I am even happy to explicitly mention the use of assertions for c= lient authentication in the prose. I just don’t think another sub-sec= tion is needed.

 = ;

Would that be what you had in= mind?

 

EHL

 

From: Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Tues= day, January 18, 2011 9:23 PM
To: Eran Hammer-Lahav
Cc:= fcorella@pomcor.com; Mike Jones; oauth@ietf.org; Karen P. Lewison
Su= bject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credential= s and OAuth2 HTTP Authentication Scheme

 

Eran,

 

Yes, I agree it feels like we're going in circles.  Might I = point out who it was that started this round? ;-)  Still, I think the = discussion is useful and important.

 

3.0 introduces = the concept (that any client authentication is acceptable) but then specifi= es 2 acceptable methods (3.1 and 3.2) and leaves out other forms of client = authentication.  The specification can be interpreted that the "a= ny types" of methods supported are 3.1 and 3.2 ONLY.  It just see= ms that the current spec has awkward phrasing.

 

My s= uggestion was simply to drop client_assertion and replace with some te= xt indicating what "any client authentication" is.  Assertio= n based authentication would then be supported via the new paragraph 2 whic= h allows for  any kind of client authentication (SAML, Kerberos, STS, = whatever).

 <= /p>

Just to add another loop, what about cut= ting out the entire section 3 and keep client_id as a required parameter in= 4 and 5 (related to but not directly tied to authentication) -- and gettin= g OAuth out of authentication methods entirely (other then to specify it as= a requirement)?

  =

 

On 2= 011-01-18, at 8:23 PM, Eran Hammer-Lahav wrote:



= Thanks Phil.

&n= bsp;

The proble= m with this text is that it doesn’t add anything new and I am not sur= e what Client Web Credentials even mean.

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

I have argued against under-specified features and wil= l continue to object their inclusion. When I initially agreed to include Ya= ron’s text for client assertion it was based on the assumption that i= t will provoke discussion and will mature into a fully baked feature. It ha= s not. Instead, it sits there without enough details to produce even a sing= le working implementation, not to mention any level of interoperability wha= t-so-ever.

&nbs= p;

The specific= ation clearly allows any kind of client authentication. How is that not eno= ugh? How is providing two parameters that are useless without further profi= ling in any way useful? If you need stronger alternatives to 3.1 you are ve= ry welcome to define and publish such in companion specifications. It feels= like we are going in circles where a few people are arguing to keep a feat= ure that does not accomplish their reasons for its inclusion.

 

EHL

 

 

(apologies if this is a re-post, for some reason it w= as previously bounced)

 

I've been a= rguing as well to keep client assertion or some other stronger alternative = to 3.1.  Re-reading the introduction to section 3, I see that the last= paragraph says:

 <= o:p>

The authorization server MAY authe= nticate the client using any appropriate set of credentials and authenticat= ion schemes. The client MUST NOT include more than one set of credentials o= r authentication mechanism with each request.

 

I would suggest the following.  That we replac= e 3.2 with this paragraph expressed as an alternative (move it from the int= roduction and a little massaging).  The idea would be to make it clear= that using normal web authentication methodologies is perfectly acceptable= .  Further, I would also suggest that if an OOB authentication is use = (and preferred), that the client_id might still be sent.  This handles= case where mapping between client_id and the client credentials is not obv= ious (or easy). 

 

How abo= ut:

 

3.2. Client Web (OOB) Credentials


The client MA= Y be authenticated using any appropriate set of credentials and web authent= ication scheme supported by the authorization server. In cases where the cl= ient_id cannot be mapped by the authorizing server from the client cre= dential, the client_id MUST be provided.[should client_id always be provide= d?]

=  

I would eve= n include language that makes Client Web Credential authentication the pref= erred methodology or at least list it first.

 

This makes the spec more consistent in that OAuth is not in= volved in the authentication of the user or the client. -- it makes it more= consistent.

 = ;

This approach wi= ll allow assertion based authentications (SAML, STS, etc) or other approach= es without having to get hung up on how it should work inside of OAuth.

 

=

Phil

=

 

On 2011= -01-18, at 12:26 PM, Francisco Corella wrote:




Mike,

As= assertion use is described in the spec, a client assertion does not provid= e any security whatsoever.  How do you handle subject confirmation in = your implementation?  (See section 2.4.1.1 of the SAML specification.)  In other wor= ds, how does the authorization server know that the client sending the asse= rtion is actually the subject of the assertion?

Francisco

---= On Tue, 1/18/11, Mike J= ones <Michael.Jones@microsoft.com>=  wrote:


From: Mike Jones &= lt;Michael.Jones@microsoft.c= om>
Subject: [OAUTH-WG] Reasons not to remove Client Assertion Cr= edentials and OAuth2 HTTP Authentication Scheme
To: "Eran Hammer-La= hav" <eran@hueniverse.com>
Cc: "oauth@ietf.org&quo= t; <oauth@ietf.org>
Date: Tu= esday, January 18, 2011, 5:35 PM

Having spoken to a number of people impl= ementing the spec here, I’ve encountered strong objections to removin= g Client Assertion Credentials and the OAuth2 HTTP Authentication Scheme. &= nbsp;It’s also not clear to me why we would make substantial breaking= changes to the specification when it is essentially ready for approval.&nb= sp; I’ve summarized the reasons I believe we should keep these two fe= atures below.

 

Client Assertion Cred= entials:  Many of the scenarios we care about require this capabil= ity. They were key motivators for the Assertion Profile in WRAP (see =A7 5.= 2), have been part of OAuth 2 for quite a while, and we have running code t= hat requires this support. For example, the Azure Access Control Service is= a cloud Authorization server that supports several protocols, including pa= rts of OAuth 2.0 draft 10 (autonomous and web server profiles). We are happ= y to update our implementation to subsequent drafts & agree that the sp= ec leaves a lot of ambiguity.

=  

In our i= mplementation of the autonomous and web server profiles, ACS allows clients= to authenticate using a signed assertion as well as with a username/passwo= rd. The username/pwd option is for clients that don’t mind sending cr= edentials over the wire, while the signed assertion mechanism is for client= s that are more reticent to send raw credentials and for scenarios where it= isn’t possible. To illustrate an example where username/pwd isn̵= 7;t viable, consider the case of a client that needs to use an enterprise i= dentity to gain access to a cloud service. In many cases, corporate policy = demands that a client use an identity managed by the organization. This mea= ns that the client should obtain an assertion from an enterprise identity p= rovider (Active Directory, Tivoli, etc.) and use that assertion to obtain a= n access token which grants access to various web service APIs. Many of our= key MSFT customers and internal partner teams rely on this mechanism and r= everting exclusively to username/pwd isn’t an option for us.

 

'OAuth2' HTTP Authentication Scheme:&nb= sp; Simply put, dropping this seems like a huge step away from interoperabi= lity.  As one data point, Microsoft implements this in our WIF OAuth2 = protected resource code.  All up, clients need a way to authenticate t= o the protected resource.  Also, existing WRAP implementations need th= is functionality to migrate to OAuth2.   For all these reasons, w= e support retaining this functionality in OAuth2.

<= p class=3DMsoNormal> 

          &nb= sp;            =             &nb= sp;            =             Thanks,<= o:p>

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

 


-----Inline Attachment Follows-----

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

_______________________________________________
OAuth mailing listOAuth@ietf.org
https://www.ietf.org/mailman/listinf= o/oauth

 =

&n= bsp;

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D88FP3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jan 18 22:13:40 2011 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 C8D623A6EF5 for ; Tue, 18 Jan 2011 22:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 djzU+VWgMxXz for ; Tue, 18 Jan 2011 22:13:40 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D8CA33A6DA2 for ; Tue, 18 Jan 2011 22:13:39 -0800 (PST) Received: (qmail 1278 invoked from network); 19 Jan 2011 06:16:18 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 06:16:18 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 18 Jan 2011 23:16:18 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 18 Jan 2011 23:16:13 -0700 Thread-Topic: [OAUTH-WG] Format of user-agent response parameters Thread-Index: Acu3Y+QG5DeNGe0nQla1SzpdjSetFAAOzAYw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D890@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7FB4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Format of user-agent response parameters 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, 19 Jan 2011 06:13:41 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, January 18, 2011 3:03 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Format of user-agent response parameters >=20 > On Sat, Jan 15, 2011 at 11:41 PM, Eran Hammer-Lahav > wrote: > > Why is the token returned in the fragment using form-encoding? This > > makes no sense. It should be a JSON string for the following reasons: > > > > > > > > 1.=A0=A0=A0=A0=A0=A0 All token responses should be the same, which will= enable > > returning structured responses in the future as needed. >=20 > They cannot all be the same. response_type=3Dcode has the response in the > query parameter, so I think we should stick with flat name/value pairs. *Token* responses. When a code is returned alone, it is not a token respons= e... >=20 > > 2.=A0=A0=A0=A0=A0=A0 Using fragments is specifically done to accommodat= e the > > user-agent environment, which means JavaScript. Why create extra work > > when JSON.parse() does it for you for free. >=20 > The argument was that it is a somewhat more difficult to safely parse JSO= N in > JavaScript (maybe I remember wrong). Now that most browsers support JSON.parse(), it is trivial. I think the poi= nt was the danger of using eval() which is very bad but common practice. =20 > Unless we have a good reason to change to JSON, considering it is late in= the > game, I think we should not make changes. I agree this is a breaking change that has little immediate value. But long= term it will provide a significant benefit in having a consistent token re= presentation across the two formats. On the other hand, JSON will also requ= ire encoding since '{' and '"' are not allowed unescaped in the fragment. Oh well. EHL From eran@hueniverse.com Tue Jan 18 22:17:39 2011 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 E7E6B3A70E1 for ; Tue, 18 Jan 2011 22:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 KgaFiS1HtNcZ for ; Tue, 18 Jan 2011 22:17:36 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6E5423A6C42 for ; Tue, 18 Jan 2011 22:17:36 -0800 (PST) Received: (qmail 4188 invoked from network); 19 Jan 2011 06:20:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 06:20:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 18 Jan 2011 23:20:15 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Tue, 18 Jan 2011 23:20:09 -0700 Thread-Topic: [OAUTH-WG] Removal: credential body parameters Thread-Index: Acu1rtfc0AazY3T1SS2kFCSiY4cnFwB8duwg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D891@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D333EE9.1030706@lodderstedt.net> In-Reply-To: <4D333EE9.1030706@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D891P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters 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, 19 Jan 2011 06:17:39 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D891P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This seems to conflict with the ability to mix and match grant types and cl= ient authentication. If you define an authentication scheme for each grant = type, how would you also include client authentication using, say, Basic or= Digest? Seems like a complex framework for combining schemes into one head= er. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, January 16, 2011 10:55 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters Hi Eran, you made some good points and I agree with most of your analysis. The way w= e use BASIC in the current draft is not perfect, mainly because it is a com= promise. It was basically the attempt to be more HTTP compliant while still= supporting the parameter-based approach. I would strongly object against removing BASIC and relying on body paramete= rs, only. We (Deutsche Telekom) have implemented that scheme and do not se= e a real problem with it. In order to overcome the problems you listed, I would like to propose an al= ternative approach. I would suggest to drop support for passing any credentials to the tokens e= ndpoint in the body of the POST request. Instead, I would suggest to define= one HTTP authentication scheme per grant type and send the corresponding p= arameters within the Authorization header. Conceptually, the tokens endpoint is a resource URI clients use to obtain t= okens. The expected token scope can be explicitely specified by the corresp= onding URI query parameter. So the simplest, complete request to obtain a t= oken could look as follows: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded scope=3Dsomething Most authorization servers will certainly need credentials of some kind as = pre-requisite for token issuance. These credentials actually authenticate t= he resource owner and the client to the authorization server as well as pro= ve the client's authorization to get the token. Such credentials are usuall= y passed using authorization headers in HTTP requests. Let's take the example of the grant type "code". We could define a scheme "= CODE", which carries the parameters code, redirect_uri, client_id and clien= t_secret (optionally) as named values. An example request could look as fol= lows POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: CODE code=3D'i1WsRn1uB1', redirect_uri=3D'https%3A%2F%2Fclient%2Eexample%2Ec= om%2Fcb', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething The following examples illustrate the approach with respect to the grant ty= pes "password" and "refresh_token", respectively. POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: PWD username=3D'johndoe', password=3D'A3ddj3w', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: REFRESH token=3D'n4E9O119d', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething I see the following advantages: 1) The suggest approach is aligned with HTTP. So instead of using HTTP as "= transport protocol" only (as in the dark times of SOAP), we could make bett= er use of the existing framework for messaging, caching, and security. 2) Since the proposed approach is alligned with HTTP authentication and aut= horization in general, it would be an easy task to add support for addition= al, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or = GBA to an OAuth authorization server. 3) WWW-Authenticate headers could be used to provide clients with useful in= formation about the capabilities of the authorization server. In the follow= ing example, the server reacts to an unauthenticated request with the follo= wing response HTTP/1.1 401 Unauthorized WWW-Authenticate: CODE uri=3D"tokenservice.example.com/authorize" WWW-Authenticate: PWD realm=3D'users.example.com' WWW-Authenticate: REFRESH which indicates its support for the grant types authorization_code, usernam= e/password and refresh token. Additionally it provides the client with the = end-user endpoint URI of the authorization server and the user realm suppor= ted for password authentication. 4) The proposed mechanism should work nicely with existing authentication f= rameworks, since we would no longer use a mixed model for passing credentia= ls and dedicated HTTP authentication schemes. What do you think? What do others think? regards, Torsten. Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav: OAuth 2.0 provides two methods for client authentication using password cre= dentials: request parameters and HTTP Basic authentication. I suggest we dr= op the requirement to support HTTP Basic authentication, and only mention i= t as an example for alternative methods. My reasons are: A few providers have expressed concerns over the need to support Basic auth= entication, and some explicitly said they will not support it. Parameter-ba= sed authentication, OTOH, is widely deployed in 2.0. Due to the way OAuth is being implemented at the HTTP authentication layer = (even if it is wrong), can conflict within the framework as both a consumer= and provider of authentication components. The mapping between username and client_id, while not complicated, is still= a big awkward, and can be confusing when combined with the username and pa= ssword grant type. On the other hand, the use of client_id in the end-user = authorization endpoint lends itself nicely to the use of the same parameter= elsewhere. Some existing authentication frameworks will have an issue handling the mix= of Basic authentication and parameters authentication due to how each is d= eployed. In cases where a front gate handles Basic, it will be hard to let = requests through for parameter processing. Comments? Counter-arguments? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D891P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= This seems to conflict with the ability to mi= x and match grant types and client authentication. If you define an authent= ication scheme for each grant type, how would you also include client authe= ntication using, say, Basic or Digest? Seems like a complex framework for c= ombining schemes into one header.

 

EHL

 

From: Torst= en Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, Ja= nuary 16, 2011 10:55 AM
To: Eran Hammer-Lahav
Cc: OAuth= WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters

 

<= p class=3DMsoNormal>Hi Eran,

you made some good points and I agree w= ith most of your analysis. The way we use BASIC in the current draft is not= perfect, mainly because it is a compromise. It was basically the attempt t= o be more HTTP compliant while still supporting the parameter-based approac= h.

I would strongly object against removing BASIC and relying on bo= dy parameters, only.  We (Deutsche Telekom) have implemented that sche= me and do not see a real problem with it.

In order to overcome the = problems you listed, I would like to propose an alternative approach.
<= br>I would suggest to drop support for passing any credentials to the token= s endpoint in the body of the POST request. Instead, I would suggest to def= ine one HTTP authentication scheme per grant type and send the correspondin= g parameters within the Authorization header.

Conceptually, the tok= ens endpoint is a resource URI clients use to obtain tokens. The expected t= oken scope can be explicitely specified by the corresponding URI query para= meter. So the simplest, complete request to obtain a token could look as fo= llows:

     POST /token HTTP/1.1
  =    Host: server.example.com
     Content-T= ype: application/x-www-form-urlencoded

     scop= e=3Dsomething

Most authorization servers will certainly need credent= ials of some kind as pre-requisite for token issuance. These credentials ac= tually authenticate the resource owner and the client to the authorization = server as well as prove the client's authorization to get the token. Such c= redentials are usually passed using authorization headers in HTTP requests.=

Let's take the example of the grant type "code". We could= define a scheme "CODE", which carries the parameters code, redir= ect_uri, client_id and client_secret (optionally) as named values. An examp= le request could look as follows

     POST /toke= n HTTP/1.1
     Host: server.example.com
 &n= bsp;   Content-Type: application/x-www-form-urlencoded
 &= nbsp;   Authorization: CODE code=3D'i1WsRn1uB1',
  &= nbsp;           &nbs= p;          redirect_uri=3D'ht= tps%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb',
     =             &nb= sp;       client_id=3D's6BhdRkqt3',
 =             &nb= sp;           client_secr= et=3D'gX1fBat3bV'

     scope=3Dsomething

= The following examples illustrate the approach with respect to the grant ty= pes "password" and "refresh_token", respectively.
     POST /token HTTP/1.1
    = Host: server.example.com
     Content-Type: applica= tion/x-www-form-urlencoded
     Authorization: PWD u= sername=3D'johndoe',
        &nb= sp;            =    password=3D'A3ddj3w',
      &= nbsp;           &nbs= p;      client_id=3D's6BhdRkqt3',
  &= nbsp;           &nbs= p;          client_secret=3D'g= X1fBat3bV'

     scope=3Dsomething

 &= nbsp;   POST /token HTTP/1.1
     Host: se= rver.example.com
     Content-Type: application/x-ww= w-form-urlencoded
     Authorization: REFRESH token= =3D'n4E9O119d',
         &n= bsp;            = ;      client_id=3D's6BhdRkqt3',
  &n= bsp;            = ;             c= lient_secret=3D'gX1fBat3bV'

     scope=3Dsomethi= ng

I see the following advantages:
1) The suggest approach is ali= gned with HTTP. So instead of using HTTP as "transport protocol" = only (as in the dark times of SOAP), we could make better use of the existi= ng framework for messaging, caching, and security.

2) Since the pro= posed approach is alligned with HTTP authentication and authorization in ge= neral, it would be an easy task to add support for additional, existing aut= hentication mechanisms, such as Kerberos/SPNEGO, Digest or GBA to an OAuth = authorization server.

3) WWW-Authenticate headers could be used to p= rovide clients with useful information about the capabilities of the author= ization server. In the following example, the server reacts to an unauthent= icated request with the following response

     = HTTP/1.1 401 Unauthorized
     WWW-Authenticate: COD= E uri=3D"tokenservice.example.com/authorize"
   = ;  WWW-Authenticate: PWD realm=3D'users.example.com'
  &n= bsp;  WWW-Authenticate: REFRESH

which indicates its support for= the grant types authorization_code, username/password and refresh token. A= dditionally it provides the client with the end-user endpoint URI of the au= thorization server and the user realm supported for password authentication= .

4) The proposed mechanism should work nicely with existing authent= ication frameworks, since we would no longer use a mixed model for passing = credentials and dedicated HTTP authentication schemes.

What do you t= hink? What do others think?

regards,
Torsten.


Am 15.01= .2011 07:53, schrieb Eran Hammer-Lahav:

OAuth 2.0 provides two methods for client authentication using password cr= edentials: request parameters and HTTP Basic authentication. I suggest we d= rop the requirement to support HTTP Basic authentication, and only mention = it as an example for alternative methods. My reasons are:

 

A few providers have expressed concerns over the need = to support Basic authentication, and some explicitly said they will not sup= port it. Parameter-based authentication, OTOH, is widely deployed in 2.0.

Due t= o the way OAuth is being implemented at the HTTP authentication layer (even= if it is wrong), can conflict within the framework as both a consumer and = provider of authentication components.

The mapping between username and client_= id, while not complicated, is still a big awkward, and can be confusing whe= n combined with the username and password grant type. On the other hand, th= e use of client_id in the end-user authorization endpoint lends itself nice= ly to the use of the same parameter elsewhere.

Some existing authentication fra= meworks will have an issue handling the mix of Basic authentication and par= ameters authentication due to how each is deployed. In cases where a front = gate handles Basic, it will be hard to let requests through for parameter p= rocessing.

 

Comments? Counter-arguments?

 

EHL

&nb=
sp;
 
___________________________=
____________________
OAuth mailing list
OAuth@ietf.org
https://www.i=
etf.org/mailman/listinfo/oauth
&n=
bsp;
= --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D891P3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jan 18 22:19:36 2011 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 D3A0D3A6DB5 for ; Tue, 18 Jan 2011 22:19:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, 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 SOipcoWvFdyW for ; Tue, 18 Jan 2011 22:19:28 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 0D3F63A6DA2 for ; Tue, 18 Jan 2011 22:19:28 -0800 (PST) Received: (qmail 3348 invoked from network); 19 Jan 2011 06:22:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 06:22:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 18 Jan 2011 23:22:06 -0700 From: Eran Hammer-Lahav To: William Mills , OAuth WG Date: Tue, 18 Jan 2011 23:22:01 -0700 Thread-Topic: Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu0eqc8OI1TGx2yS4KwfqhDmZy6TQAZBo3QALCUkWA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D892P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 06:19:36 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D892P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can you provide an example HTTP response header showing how you provide thi= s discovery information? It would be helpful to think about solutions. EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 18, 2011 8:44 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme As long as we can do the discovery in band and it doesn't require major dif= ferences in-band I'm OK. I spinning back up on the SASL mechanism (now tha= t I finally was allowed to opensource it), and my current in-band discovery= is pretty clean using WWW-Authenticate. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 14, 2011 10:32 PM To: OAuth WG Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme One of the main problems with OAuth in general has always been the unsanita= ry mix of authorization and authentication ("it's an authentication protoco= l... authorization protocol... authentication protocol" [1]). It has always= been a confusing mess. The work on 2.0 has provided a valuable abstraction= and separation of the two components, especially the recent document split= . In addition, the recent work on the bearer token document and the MAC tok= en type have raised issues about OAuth and its relationship with HTTP authe= ntication. I would like to suggest we drop the 'OAuth2' WWW-Authenticate header comple= tely from the specification for the following reasons: 1. Draft oauth-v2 is clearly not an authentication protocol. It *util= izes* client authentication. It offers one fully defined method for client = authentication (which is basically HTTP Basic+), provides a half-baked clie= nt assertion authentication hook, and leaves all end-user authentication ou= t of scope. 2. The WWW-Authenticate header has absolutely no value, interoperabil= ity-wise or otherwise. Discovery was rules to be beyond the scope of this s= pecification. Having a protected resource declare it supports authenticatio= n using some unspecified credentials obtained using some unspecified client= flow is confusing at best. In the future, an interoperable discovery mecha= nism will be needed to allow clients to interact with completely unknown pr= otected resources, but this has been consistently ruled to be premature sta= ndardization at this point. 3. OAuth is agnostic to token authentication, and we already have thr= ee discrete token type proposals - all with active deployment plans in the = coming months. Two of these methods have already defined a full HTTP authen= tication scheme (even if the bearer token specification has not yet been up= dated to change its scheme name). 4. HTTP *authentication* is not an appropriate facility to negotiate = *authorization*. OAuth authorization discovery can be added to HTTP authent= ication schemes as attributes, but makes no sense as a scheme of its own. T= he issues we are having with 'realm' is one of the examples showing that we= are abusing the header. 5. Again, as specified, it adds no value and I am not aware of any ex= isting OAuth 1.0a implementation making use of the response header for clie= nt interoperability (yes, many include it, but how many clients actually re= ly on it, and if they do, how?). For these reasons I would like to suggest we: 1. Drop the WWW-Authenticate header definition and OAuth2 scheme from= the specification, leaving it up to each token type to define its own auth= entication flow. In the future, a comprehensive discovery specification sho= uld define a new HTTP response header for providing discovery information. = I have suggested using Link: rel=3D'authorization' as a simple yet powerful= solution. 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' to m= ake it clear what this document is really about. Comments? Counter argument? EHL [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D892P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can you provide an example HTTP response header showing how y= ou provide this discovery information? It would be helpful to think about s= olutions.

 

EHL

 

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Tue= sday, January 18, 2011 8:44 AM
To: Eran Hammer-Lahav; OAuth WGSubject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

 

As long as we can do the discove= ry in band and it doesn’t require major differences in-band I’m= OK.  I spinning back up on the SASL mechanism (now that I finally was= allowed to opensource it), and my current in-band discovery is pretty clea= n using WWW-Authenticate.

 

<= p class=3DMsoNormal>From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.o= rg] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 1= 4, 2011 10:32 PM
To: OAuth WG
Subject: [OAUTH-WG] Remov= al: 'OAuth2' HTTP Authentication Scheme

 

One of the mai= n problems with OAuth in general has always been the unsanitary mix of auth= orization and authentication (“it’s an authentication protocol&= #8230; authorization protocol… authentication protocol” [1]). I= t has always been a confusing mess. The work on 2.0 has provided a valuable= abstraction and separation of the two components, especially the recent do= cument split. In addition, the recent work on the bearer token document and= the MAC token type have raised issues about OAuth and its relationship wit= h HTTP authentication.

 =

I would like to suggest we drop the ‘OAuth2&= #8217; WWW-Authenticate header completely from the specification for the fo= llowing reasons:

 

1.       Draft oauth-v2 is clearly not an authentication protocol. It= *utilizes* client authentication. It offers one fully defined metho= d for client authentication (which is basically HTTP Basic+), provides a ha= lf-baked client assertion authentication hook, and leaves all end-user auth= entication out of scope.

2. = ;      The WWW-Authenticat= e header has absolutely no value, interoperability-wise or otherwise. Disco= very was rules to be beyond the scope of this specification. Having a prote= cted resource declare it supports authentication using some unspecified cre= dentials obtained using some unspecified client flow is confusing at best. = In the future, an interoperable discovery mechanism will be needed to allow= clients to interact with completely unknown protected resources, but this = has been consistently ruled to be premature standardization at this point.<= o:p>

3.=      =   OAuth is agnostic to token authentication, a= nd we already have three discrete token type proposals – all with act= ive deployment plans in the coming months. Two of these methods have alread= y defined a full HTTP authentication scheme (even if the bearer token speci= fication has not yet been updated to change its scheme name).

4.       HTTP *authentication* is not an appropriate faci= lity to negotiate *authorization*. OAuth authorization discovery can= be added to HTTP authentication schemes as attributes, but makes no sense = as a scheme of its own. The issues we are having with ‘realm’ i= s one of the examples showing that we are abusing the header.

5.       Again, as specified, it adds no value and I am not awar= e of any existing OAuth 1.0a implementation making use of the response head= er for client interoperability (yes, many include it, but how many clients = actually rely on it, and if they do, how?).

 

For these reasons I would lik= e to suggest we:

 

1.       Drop the WWW-Authenticate header definition and OAuth2 schem= e from the specification, leaving it up to each token type to define its ow= n authentication flow. In the future, a comprehensive discovery specificati= on should define a new HTTP response header for providing discovery informa= tion. I have suggested using Link: rel=3D’authorization’ as a s= imple yet powerful solution.

2.&= nbsp;      Rename the docu= ment to ‘The OAuth 2.0 Authorization Protocol’ to make it clear= what this document is really about.

 

Comments? Counter argument?

 

EHL

 

= [1] http://www.you= tube.com/watch?v=3D0IBZocFkXGY

=  

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D892P3PW5EX1MB01E_-- From torsten@lodderstedt.net Tue Jan 18 22:33:14 2011 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 0C7C23A6C42 for ; Tue, 18 Jan 2011 22:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgScJut45k8K for ; Tue, 18 Jan 2011 22:33:12 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.18.55]) by core3.amsl.com (Postfix) with ESMTP id 899FE3A6DA2 for ; Tue, 18 Jan 2011 22:33:11 -0800 (PST) Received: from [87.142.247.58] (helo=[192.168.71.49]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PfRe1-0004bO-21; Wed, 19 Jan 2011 07:35:49 +0100 Message-ID: <4D368647.9070405@lodderstedt.net> Date: Wed, 19 Jan 2011 07:35:51 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D333EE9.1030706@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D891@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D891@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------070906080502030408000303" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters 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, 19 Jan 2011 06:33:14 -0000 This is a multi-part message in MIME format. --------------070906080502030408000303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Where do you see the conflict? In my proposal, user and client credentials are combined into one Authorization header. But the same holds for request parameters. I don't know whether combining credentials in request parameters is more or less complex/conflicting then combining them as named values within a header. regards, Torsten. Am 19.01.2011 07:20, schrieb Eran Hammer-Lahav: > > This seems to conflict with the ability to mix and match grant types > and client authentication. If you define an authentication scheme for > each grant type, how would you also include client authentication > using, say, Basic or Digest? Seems like a complex framework for > combining schemes into one header. > > EHL > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Sunday, January 16, 2011 10:55 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Removal: credential body parameters > > Hi Eran, > > you made some good points and I agree with most of your analysis. The > way we use BASIC in the current draft is not perfect, mainly because > it is a compromise. It was basically the attempt to be more HTTP > compliant while still supporting the parameter-based approach. > > I would strongly object against removing BASIC and relying on body > parameters, only. We (Deutsche Telekom) have implemented that scheme > and do not see a real problem with it. > > In order to overcome the problems you listed, I would like to propose > an alternative approach. > > I would suggest to drop support for passing any credentials to the > tokens endpoint in the body of the POST request. Instead, I would > suggest to define one HTTP authentication scheme per grant type and > send the corresponding parameters within the Authorization header. > > Conceptually, the tokens endpoint is a resource URI clients use to > obtain tokens. The expected token scope can be explicitely specified > by the corresponding URI query parameter. So the simplest, complete > request to obtain a token could look as follows: > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > scope=something > > Most authorization servers will certainly need credentials of some > kind as pre-requisite for token issuance. These credentials actually > authenticate the resource owner and the client to the authorization > server as well as prove the client's authorization to get the token. > Such credentials are usually passed using authorization headers in > HTTP requests. > > Let's take the example of the grant type "code". We could define a > scheme "CODE", which carries the parameters code, redirect_uri, > client_id and client_secret (optionally) as named values. An example > request could look as follows > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: CODE code='i1WsRn1uB1', > > redirect_uri='https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb', > client_id='s6BhdRkqt3', > client_secret='gX1fBat3bV' > > scope=something > > The following examples illustrate the approach with respect to the > grant types "password" and "refresh_token", respectively. > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: PWD username='johndoe', > password='A3ddj3w', > client_id='s6BhdRkqt3', > client_secret='gX1fBat3bV' > > scope=something > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: REFRESH token='n4E9O119d', > client_id='s6BhdRkqt3', > client_secret='gX1fBat3bV' > > scope=something > > I see the following advantages: > 1) The suggest approach is aligned with HTTP. So instead of using HTTP > as "transport protocol" only (as in the dark times of SOAP), we could > make better use of the existing framework for messaging, caching, and > security. > > 2) Since the proposed approach is alligned with HTTP authentication > and authorization in general, it would be an easy task to add support > for additional, existing authentication mechanisms, such as > Kerberos/SPNEGO, Digest or GBA to an OAuth authorization server. > > 3) WWW-Authenticate headers could be used to provide clients with > useful information about the capabilities of the authorization server. > In the following example, the server reacts to an unauthenticated > request with the following response > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: CODE uri="tokenservice.example.com/authorize" > WWW-Authenticate: PWD realm='users.example.com' > WWW-Authenticate: REFRESH > > which indicates its support for the grant types authorization_code, > username/password and refresh token. Additionally it provides the > client with the end-user endpoint URI of the authorization server and > the user realm supported for password authentication. > > 4) The proposed mechanism should work nicely with existing > authentication frameworks, since we would no longer use a mixed model > for passing credentials and dedicated HTTP authentication schemes. > > What do you think? What do others think? > > regards, > Torsten. > > > Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav: > > OAuth 2.0 provides two methods for client authentication using > password credentials: request parameters and HTTP Basic > authentication. I suggest we drop the requirement to support HTTP > Basic authentication, and only mention it as an example for > alternative methods. My reasons are: > > A few providers have expressed concerns over the need to support Basic > authentication, and some explicitly said they will not support it. > Parameter-based authentication, OTOH, is widely deployed in 2.0. > > Due to the way OAuth is being implemented at the HTTP authentication > layer (even if it is wrong), can conflict within the framework as both > a consumer and provider of authentication components. > > The mapping between username and client_id, while not complicated, is > still a big awkward, and can be confusing when combined with the > username and password grant type. On the other hand, the use of > client_id in the end-user authorization endpoint lends itself nicely > to the use of the same parameter elsewhere. > > Some existing authentication frameworks will have an issue handling > the mix of Basic authentication and parameters authentication due to > how each is deployed. In cases where a front gate handles Basic, it > will be hard to let requests through for parameter processing. > > Comments? Counter-arguments? > > EHL > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------070906080502030408000303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Where do you see the conflict? In my proposal, user and client credentials are combined into one Authorization header. But the same holds for request parameters. I don't know whether combining credentials in request parameters is more or less complex/conflicting then combining them as named values within a header.

regards,
Torsten.

Am 19.01.2011 07:20, schrieb Eran Hammer-Lahav:

This seems to conflict with the ability to mix and match grant types and client authentication. If you define an authentication scheme for each grant type, how would you also include client authentication using, say, Basic or Digest? Seems like a complex framework for combining schemes into one header.

 

EHL

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, January 16, 2011 10:55 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters

 

Hi Eran,

you made some good points and I agree with most of your analysis. The way we use BASIC in the current draft is not perfect, mainly because it is a compromise. It was basically the attempt to be more HTTP compliant while still supporting the parameter-based approach.

I would strongly object against removing BASIC and relying on body parameters, only.  We (Deutsche Telekom) have implemented that scheme and do not see a real problem with it.

In order to overcome the problems you listed, I would like to propose an alternative approach.

I would suggest to drop support for passing any credentials to the tokens endpoint in the body of the POST request. Instead, I would suggest to define one HTTP authentication scheme per grant type and send the corresponding parameters within the Authorization header.

Conceptually, the tokens endpoint is a resource URI clients use to obtain tokens. The expected token scope can be explicitely specified by the corresponding URI query parameter. So the simplest, complete request to obtain a token could look as follows:

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     scope=something

Most authorization servers will certainly need credentials of some kind as pre-requisite for token issuance. These credentials actually authenticate the resource owner and the client to the authorization server as well as prove the client's authorization to get the token. Such credentials are usually passed using authorization headers in HTTP requests.

Let's take the example of the grant type "code". We could define a scheme "CODE", which carries the parameters code, redirect_uri, client_id and client_secret (optionally) as named values. An example request could look as follows

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: CODE code='i1WsRn1uB1',
                         redirect_uri='https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb',
                         client_id='s6BhdRkqt3',
                         client_secret='gX1fBat3bV'

     scope=something

The following examples illustrate the approach with respect to the grant types "password" and "refresh_token", respectively.

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: PWD username='johndoe',
                        password='A3ddj3w',
                         client_id='s6BhdRkqt3',
                         client_secret='gX1fBat3bV'

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: REFRESH token='n4E9O119d',
                            client_id='s6BhdRkqt3',
                            client_secret='gX1fBat3bV'

     scope=something

I see the following advantages:
1) The suggest approach is aligned with HTTP. So instead of using HTTP as "transport protocol" only (as in the dark times of SOAP), we could make better use of the existing framework for messaging, caching, and security.

2) Since the proposed approach is alligned with HTTP authentication and authorization in general, it would be an easy task to add support for additional, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or GBA to an OAuth authorization server.

3) WWW-Authenticate headers could be used to provide clients with useful information about the capabilities of the authorization server. In the following example, the server reacts to an unauthenticated request with the following response

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: CODE uri="tokenservice.example.com/authorize"
     WWW-Authenticate: PWD realm='users.example.com'
     WWW-Authenticate: REFRESH

which indicates its support for the grant types authorization_code, username/password and refresh token. Additionally it provides the client with the end-user endpoint URI of the authorization server and the user realm supported for password authentication.

4) The proposed mechanism should work nicely with existing authentication frameworks, since we would no longer use a mixed model for passing credentials and dedicated HTTP authentication schemes.

What do you think? What do others think?

regards,
Torsten.


Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav:

OAuth 2.0 provides two methods for client authentication using password credentials: request parameters and HTTP Basic authentication. I suggest we drop the requirement to support HTTP Basic authentication, and only mention it as an example for alternative methods. My reasons are:

 

A few providers have expressed concerns over the need to support Basic authentication, and some explicitly said they will not support it. Parameter-based authentication, OTOH, is widely deployed in 2.0.

Due to the way OAuth is being implemented at the HTTP authentication layer (even if it is wrong), can conflict within the framework as both a consumer and provider of authentication components.

The mapping between username and client_id, while not complicated, is still a big awkward, and can be confusing when combined with the username and password grant type. On the other hand, the use of client_id in the end-user authorization endpoint lends itself nicely to the use of the same parameter elsewhere.

Some existing authentication frameworks will have an issue handling the mix of Basic authentication and parameters authentication due to how each is deployed. In cases where a front gate handles Basic, it will be hard to let requests through for parameter processing.

 

Comments? Counter-arguments?

 

EHL

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

 


--------------070906080502030408000303-- From eran@hueniverse.com Tue Jan 18 22:34:49 2011 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 C7C6C3A6EF5 for ; Tue, 18 Jan 2011 22:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 VUK+4d7tYWLs for ; Tue, 18 Jan 2011 22:34:46 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B70D53A6DA2 for ; Tue, 18 Jan 2011 22:34:45 -0800 (PST) Received: (qmail 17196 invoked from network); 19 Jan 2011 06:37:24 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 06:37:24 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 18 Jan 2011 23:37:24 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Tue, 18 Jan 2011 23:37:19 -0700 Thread-Topic: [OAUTH-WG] Removal: credential body parameters Thread-Index: Acu3ox7wivUsPk1TTT+kvFxutnBYigAABP1g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D897@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D333EE9.1030706@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D891@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D368647.9070405@lodderstedt.net> In-Reply-To: <4D368647.9070405@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D897P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters 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, 19 Jan 2011 06:34:50 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D897P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If I want to use an existing client authentication scheme such as Digest, y= our solution creates a conflict, unless we define a way to combine grant + = Digest into one header. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Tuesday, January 18, 2011 10:36 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters Where do you see the conflict? In my proposal, user and client credentials = are combined into one Authorization header. But the same holds for request = parameters. I don't know whether combining credentials in request parameter= s is more or less complex/conflicting then combining them as named values w= ithin a header. regards, Torsten. Am 19.01.2011 07:20, schrieb Eran Hammer-Lahav: This seems to conflict with the ability to mix and match grant types and cl= ient authentication. If you define an authentication scheme for each grant = type, how would you also include client authentication using, say, Basic or= Digest? Seems like a complex framework for combining schemes into one head= er. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, January 16, 2011 10:55 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters Hi Eran, you made some good points and I agree with most of your analysis. The way w= e use BASIC in the current draft is not perfect, mainly because it is a com= promise. It was basically the attempt to be more HTTP compliant while still= supporting the parameter-based approach. I would strongly object against removing BASIC and relying on body paramete= rs, only. We (Deutsche Telekom) have implemented that scheme and do not se= e a real problem with it. In order to overcome the problems you listed, I would like to propose an al= ternative approach. I would suggest to drop support for passing any credentials to the tokens e= ndpoint in the body of the POST request. Instead, I would suggest to define= one HTTP authentication scheme per grant type and send the corresponding p= arameters within the Authorization header. Conceptually, the tokens endpoint is a resource URI clients use to obtain t= okens. The expected token scope can be explicitely specified by the corresp= onding URI query parameter. So the simplest, complete request to obtain a t= oken could look as follows: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded scope=3Dsomething Most authorization servers will certainly need credentials of some kind as = pre-requisite for token issuance. These credentials actually authenticate t= he resource owner and the client to the authorization server as well as pro= ve the client's authorization to get the token. Such credentials are usuall= y passed using authorization headers in HTTP requests. Let's take the example of the grant type "code". We could define a scheme "= CODE", which carries the parameters code, redirect_uri, client_id and clien= t_secret (optionally) as named values. An example request could look as fol= lows POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: CODE code=3D'i1WsRn1uB1', redirect_uri=3D'https%3A%2F%2Fclient%2Eexample%2Ec= om%2Fcb', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething The following examples illustrate the approach with respect to the grant ty= pes "password" and "refresh_token", respectively. POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: PWD username=3D'johndoe', password=3D'A3ddj3w', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: REFRESH token=3D'n4E9O119d', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething I see the following advantages: 1) The suggest approach is aligned with HTTP. So instead of using HTTP as "= transport protocol" only (as in the dark times of SOAP), we could make bett= er use of the existing framework for messaging, caching, and security. 2) Since the proposed approach is alligned with HTTP authentication and aut= horization in general, it would be an easy task to add support for addition= al, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or = GBA to an OAuth authorization server. 3) WWW-Authenticate headers could be used to provide clients with useful in= formation about the capabilities of the authorization server. In the follow= ing example, the server reacts to an unauthenticated request with the follo= wing response HTTP/1.1 401 Unauthorized WWW-Authenticate: CODE uri=3D"tokenservice.example.com/authorize" WWW-Authenticate: PWD realm=3D'users.example.com' WWW-Authenticate: REFRESH which indicates its support for the grant types authorization_code, usernam= e/password and refresh token. Additionally it provides the client with the = end-user endpoint URI of the authorization server and the user realm suppor= ted for password authentication. 4) The proposed mechanism should work nicely with existing authentication f= rameworks, since we would no longer use a mixed model for passing credentia= ls and dedicated HTTP authentication schemes. What do you think? What do others think? regards, Torsten. Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav: OAuth 2.0 provides two methods for client authentication using password cre= dentials: request parameters and HTTP Basic authentication. I suggest we dr= op the requirement to support HTTP Basic authentication, and only mention i= t as an example for alternative methods. My reasons are: A few providers have expressed concerns over the need to support Basic auth= entication, and some explicitly said they will not support it. Parameter-ba= sed authentication, OTOH, is widely deployed in 2.0. Due to the way OAuth is being implemented at the HTTP authentication layer = (even if it is wrong), can conflict within the framework as both a consumer= and provider of authentication components. The mapping between username and client_id, while not complicated, is still= a big awkward, and can be confusing when combined with the username and pa= ssword grant type. On the other hand, the use of client_id in the end-user = authorization endpoint lends itself nicely to the use of the same parameter= elsewhere. Some existing authentication frameworks will have an issue handling the mix= of Basic authentication and parameters authentication due to how each is d= eployed. In cases where a front gate handles Basic, it will be hard to let = requests through for parameter processing. Comments? Counter-arguments? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D897P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= If I want to use an existing client authentic= ation scheme such as Digest, your solution creates a conflict, unless we de= fine a way to combine grant + Digest into one header.

=

 =

EHL

 

From:= Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
S= ent: Tuesday, January 18, 2011 10:36 PM
To: Eran Hammer-Lahav=
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credenti= al body parameters

 

Where do you see the conflict? In m= y proposal, user and client credentials are combined into one Authorization= header. But the same holds for request parameters. I don't know whether co= mbining credentials in request parameters is more or less complex/conflicti= ng then combining them as named values within a header.

regards,
= Torsten.

Am 19.01.2011 07:20, schrieb Eran Hammer-Lahav: =

This seems to confli= ct with the ability to mix and match grant types and client authentication.= If you define an authentication scheme for each grant type, how would you = also include client authentication using, say, Basic or Digest? Seems like = a complex framework for combining schemes into one header.

 <= /o:p>

EHL=

 <= o:p>

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]=
Sent: Sunday, January 16, 2011 10:55 AM
To: Eran Hamm= er-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: = credential body parameters

 

Hi Eran,

you made so= me good points and I agree with most of your analysis. The way we use BASIC= in the current draft is not perfect, mainly because it is a compromise. It= was basically the attempt to be more HTTP compliant while still supporting= the parameter-based approach.

I would strongly object against remo= ving BASIC and relying on body parameters, only.  We (Deutsche Telekom= ) have implemented that scheme and do not see a real problem with it.
<= br>In order to overcome the problems you listed, I would like to propose an= alternative approach.

I would suggest to drop support for passing = any credentials to the tokens endpoint in the body of the POST request. Ins= tead, I would suggest to define one HTTP authentication scheme per grant ty= pe and send the corresponding parameters within the Authorization header. <= br>
Conceptually, the tokens endpoint is a resource URI clients use to o= btain tokens. The expected token scope can be explicitely specified by the = corresponding URI query parameter. So the simplest, complete request to obt= ain a token could look as follows:

     POST /to= ken HTTP/1.1
     Host: server.example.com
 =     Content-Type: application/x-www-form-urlencoded

&= nbsp;    scope=3Dsomething

Most authorization servers= will certainly need credentials of some kind as pre-requisite for token is= suance. These credentials actually authenticate the resource owner and the = client to the authorization server as well as prove the client's authorizat= ion to get the token. Such credentials are usually passed using authorizati= on headers in HTTP requests.

Let's take the example of the grant typ= e "code". We could define a scheme "CODE", which carrie= s the parameters code, redirect_uri, client_id and client_secret (optionall= y) as named values. An example request could look as follows

 &= nbsp;   POST /token HTTP/1.1
     Host: se= rver.example.com
     Content-Type: application/x-ww= w-form-urlencoded
     Authorization: CODE code=3D'i= 1WsRn1uB1',
          =             &nb= sp;  redirect_uri=3D'https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb',
&n= bsp;            = ;            client_= id=3D's6BhdRkqt3',
         = ;            &n= bsp;   client_secret=3D'gX1fBat3bV'

   &nbs= p; scope=3Dsomething

The following examples illustrate the approach = with respect to the grant types "password" and "refresh_toke= n", respectively.

     POST /token HTTP/1.1=
     Host: server.example.com
   =   Content-Type: application/x-www-form-urlencoded
   = ;  Authorization: PWD username=3D'johndoe',
    = ;            &n= bsp;       password=3D'A3ddj3w',
 &nb= sp;            =            client_id=3D's= 6BhdRkqt3',
          =             &nb= sp;  client_secret=3D'gX1fBat3bV'

     scop= e=3Dsomething

     POST /token HTTP/1.1
 = ;    Host: server.example.com
     Co= ntent-Type: application/x-www-form-urlencoded
     A= uthorization: REFRESH token=3D'n4E9O119d',
     = ;            &n= bsp;          client_id=3D's6B= hdRkqt3',
          &n= bsp;            = ;     client_secret=3D'gX1fBat3bV'

  &= nbsp;  scope=3Dsomething

I see the following advantages:
1) = The suggest approach is aligned with HTTP. So instead of using HTTP as &quo= t;transport protocol" only (as in the dark times of SOAP), we could ma= ke better use of the existing framework for messaging, caching, and securit= y.

2) Since the proposed approach is alligned with HTTP authenticat= ion and authorization in general, it would be an easy task to add support f= or additional, existing authentication mechanisms, such as Kerberos/SPNEGO,= Digest or GBA to an OAuth authorization server.

3) WWW-Authenticate= headers could be used to provide clients with useful information about the= capabilities of the authorization server. In the following example, the se= rver reacts to an unauthenticated request with the following response
     HTTP/1.1 401 Unauthorized
   &= nbsp; WWW-Authenticate: CODE uri=3D"tokenservice.example.com/authorize= "
     WWW-Authenticate: PWD realm=3D'users.exa= mple.com'
     WWW-Authenticate: REFRESH

whic= h indicates its support for the grant types authorization_code, username/pa= ssword and refresh token. Additionally it provides the client with the end-= user endpoint URI of the authorization server and the user realm supported = for password authentication.

4) The proposed mechanism should work n= icely with existing authentication frameworks, since we would no longer use= a mixed model for passing credentials and dedicated HTTP authentication sc= hemes.

What do you think? What do others think?

regards,
T= orsten.


Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav:

OAuth 2.0 provides two methods for client authe= ntication using password credentials: request parameters and HTTP Basic aut= hentication. I suggest we drop the requirement to support HTTP Basic authen= tication, and only mention it as an example for alternative methods. My rea= sons are:

 

A few providers have expre= ssed concerns over the need to support Basic authentication, and some expli= citly said they will not support it. Parameter-based authentication, OTOH, = is widely deployed in 2.0.

Due to the way OAuth is being implemented at the HT= TP authentication layer (even if it is wrong), can conflict within the fram= ework as both a consumer and provider of authentication components.

The mapping= between username and client_id, while not complicated, is still a big awkw= ard, and can be confusing when combined with the username and password gran= t type. On the other hand, the use of client_id in the end-user authorizati= on endpoint lends itself nicely to the use of the same parameter elsewhere.=

Som= e existing authentication frameworks will have an issue handling the mix of= Basic authentication and parameters authentication due to how each is depl= oyed. In cases where a front gate handles Basic, it will be hard to let req= uests through for parameter processing.

=  

Comments? Counter-arguments?=

 

EH= L

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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D897P3PW5EX1MB01E_-- From phil.hunt@oracle.com Tue Jan 18 22:36:26 2011 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 0AE813A7084 for ; Tue, 18 Jan 2011 22:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 WKipUGvZFixK for ; Tue, 18 Jan 2011 22:36:22 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 636893A6EF5 for ; Tue, 18 Jan 2011 22:36:21 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0J6cs5D024708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jan 2011 06:38:57 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0J6crTs014752; Wed, 19 Jan 2011 06:38:53 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 971725721295419060; Tue, 18 Jan 2011 22:37:40 -0800 Received: from dhcp184-48-56-187.ssb.sjc.wayport.net (/12.199.6.106) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 18 Jan 2011 22:37:36 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-13--715732238 From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D88F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 18 Jan 2011 22:37:27 -0800 Message-Id: <0F9B4043-AFA5-4457-BB17-21779438DA43@oracle.com> References: <72524.62131.qm@web55804.mail.re3.yahoo.com> <3AFB9555-B33E-4534-94F0-521BE821C352@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D360C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D88F@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 19 Jan 2011 06:36:26 -0000 --Apple-Mail-13--715732238 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I can agree with this. However if you keep client password (3.1) around I would prefer another = section (3.x) that indicates "or any other client authentication method = meeting the security requirements of the authentication server" to make = it clear and easy to scan. Phil phil.hunt@oracle.com On 2011-01-18, at 10:06 PM, Eran Hammer-Lahav wrote: > Yes! This is exactly what I proposed if you combine removing Basic = together with the assertion credentials. Basically, provide the = parameter based approach as the only one specified, make it clear that = *any* suitable client authentication is allowed, and then use HTTP Basic = as an example of such other methods. I am even happy to explicitly = mention the use of assertions for client authentication in the prose. I = just don=92t think another sub-section is needed. > =20 > Would that be what you had in mind? > =20 > EHL > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, January 18, 2011 9:23 PM > To: Eran Hammer-Lahav > Cc: fcorella@pomcor.com; Mike Jones; oauth@ietf.org; Karen P. Lewison > Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion = Credentials and OAuth2 HTTP Authentication Scheme > =20 > Eran, > =20 > Yes, I agree it feels like we're going in circles. Might I point out = who it was that started this round? ;-) Still, I think the discussion = is useful and important. > =20 > 3.0 introduces the concept (that any client authentication is = acceptable) but then specifies 2 acceptable methods (3.1 and 3.2) and = leaves out other forms of client authentication. The specification can = be interpreted that the "any types" of methods supported are 3.1 and 3.2 = ONLY. It just seems that the current spec has awkward phrasing. > =20 > My suggestion was simply to drop client_assertion and replace with = some text indicating what "any client authentication" is. Assertion = based authentication would then be supported via the new paragraph 2 = which allows for any kind of client authentication (SAML, Kerberos, = STS, whatever). > =20 > Just to add another loop, what about cutting out the entire section 3 = and keep client_id as a required parameter in 4 and 5 (related to but = not directly tied to authentication) -- and getting OAuth out of = authentication methods entirely (other then to specify it as a = requirement)? > =20 > Phil > phil.hunt@oracle.com > =20 > =20 >=20 > =20 > On 2011-01-18, at 8:23 PM, Eran Hammer-Lahav wrote: >=20 >=20 > Thanks Phil. > =20 > The problem with this text is that it doesn=92t add anything new and I = am not sure what Client Web Credentials even mean. > I have argued against under-specified features and will continue to = object their inclusion. When I initially agreed to include Yaron=92s = text for client assertion it was based on the assumption that it will = provoke discussion and will mature into a fully baked feature. It has = not. Instead, it sits there without enough details to produce even a = single working implementation, not to mention any level of = interoperability what-so-ever. > =20 > The specification clearly allows any kind of client authentication. = How is that not enough? How is providing two parameters that are useless = without further profiling in any way useful? If you need stronger = alternatives to 3.1 you are very welcome to define and publish such in = companion specifications. It feels like we are going in circles where a = few people are arguing to keep a feature that does not accomplish their = reasons for its inclusion. > =20 > EHL > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Tuesday, January 18, 2011 2:45 PM > To: fcorella@pomcor.com > Cc: Eran Hammer-Lahav; Mike Jones; oauth@ietf.org; Karen P. Lewison > Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion = Credentials and OAuth2 HTTP Authentication Scheme > =20 > (apologies if this is a re-post, for some reason it was previously = bounced) > =20 > I've been arguing as well to keep client assertion or some other = stronger alternative to 3.1. Re-reading the introduction to section 3, = I see that the last paragraph says: > =20 > The authorization server MAY authenticate the client using any = appropriate set of credentials and authentication schemes. The client = MUST NOT include more than one set of credentials or authentication = mechanism with each request. > =20 > I would suggest the following. That we replace 3.2 with this = paragraph expressed as an alternative (move it from the introduction and = a little massaging). The idea would be to make it clear that using = normal web authentication methodologies is perfectly acceptable. = Further, I would also suggest that if an OOB authentication is use (and = preferred), that the client_id might still be sent. This handles case = where mapping between client_id and the client credentials is not = obvious (or easy).=20 > =20 > How about: > =20 > 3.2. Client Web (OOB) Credentials >=20 > The client MAY be authenticated using any appropriate set of = credentials and web authentication scheme supported by the authorization = server. In cases where the client_id cannot be mapped by the authorizing = server from the client credential, the client_id MUST be = provided.[should client_id always be provided?] > =20 > I would even include language that makes Client Web Credential = authentication the preferred methodology or at least list it first. > =20 > This makes the spec more consistent in that OAuth is not involved in = the authentication of the user or the client. -- it makes it more = consistent. > =20 > This approach will allow assertion based authentications (SAML, STS, = etc) or other approaches without having to get hung up on how it should = work inside of OAuth. > =20 > Phil > phil.hunt@oracle.com > =20 >=20 >=20 >=20 > =20 > On 2011-01-18, at 12:26 PM, Francisco Corella wrote: >=20 >=20 >=20 > Mike, >=20 > As assertion use is described in the spec, a client assertion does not = provide any security whatsoever. How do you handle subject confirmation = in your implementation? (See section 2.4.1.1 of the SAML = specification.) In other words, how does the authorization server know = that the client sending the assertion is actually the subject of the = assertion? >=20 > Francisco >=20 > --- On Tue, 1/18/11, Mike Jones wrote: >=20 > From: Mike Jones > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme > To: "Eran Hammer-Lahav" > Cc: "oauth@ietf.org" > Date: Tuesday, January 18, 2011, 5:35 PM >=20 > Having spoken to a number of people implementing the spec here, I=92ve = encountered strong objections to removing Client Assertion Credentials = and the OAuth2 HTTP Authentication Scheme. It=92s also not clear to me = why we would make substantial breaking changes to the specification when = it is essentially ready for approval. I=92ve summarized the reasons I = believe we should keep these two features below. >=20 > =20 > Client Assertion Credentials: Many of the scenarios we care about = require this capability. They were key motivators for the Assertion = Profile in WRAP (see =A7 5.2), have been part of OAuth 2 for quite a = while, and we have running code that requires this support. For example, = the Azure Access Control Service is a cloud Authorization server that = supports several protocols, including parts of OAuth 2.0 draft 10 = (autonomous and web server profiles). We are happy to update our = implementation to subsequent drafts & agree that the spec leaves a lot = of ambiguity. >=20 > =20 > In our implementation of the autonomous and web server profiles, ACS = allows clients to authenticate using a signed assertion as well as with = a username/password. The username/pwd option is for clients that don=92t = mind sending credentials over the wire, while the signed assertion = mechanism is for clients that are more reticent to send raw credentials = and for scenarios where it isn=92t possible. To illustrate an example = where username/pwd isn=92t viable, consider the case of a client that = needs to use an enterprise identity to gain access to a cloud service. = In many cases, corporate policy demands that a client use an identity = managed by the organization. This means that the client should obtain an = assertion from an enterprise identity provider (Active Directory, = Tivoli, etc.) and use that assertion to obtain an access token which = grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and = reverting exclusively to username/pwd isn=92t an option for us. >=20 > =20 > 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems = like a huge step away from interoperability. As one data point, = Microsoft implements this in our WIF OAuth2 protected resource code. = All up, clients need a way to authenticate to the protected resource. = Also, existing WRAP implementations need this functionality to migrate = to OAuth2. For all these reasons, we support retaining this = functionality in OAuth2. >=20 > =20 > Thanks, >=20 > -- Mike >=20 > =20 >=20 > -----Inline Attachment Follows----- >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 > =20 --Apple-Mail-13--715732238 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I can = agree with this.

However if you keep client password = (3.1) around I would prefer another section (3.x) that indicates "or any = other client authentication method meeting the security requirements of = the authentication server" to make it clear and easy to = scan.


On 2011-01-18, at 10:06 PM, Eran Hammer-Lahav = wrote:

Yes! = This is exactly what I proposed if you combine removing Basic together = with the assertion credentials. Basically, provide the parameter based = approach as the only one specified, make it clear that *any* = suitable client authentication is allowed, and then use HTTP Basic as an = example of such other methods. I am even happy to explicitly mention the = use of assertions for client authentication in the prose. I just don=92t = think another sub-section is needed.
Would = that be what you had in mind?
 Phil = Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday, January 18, 2011 = 9:23 PM
To: Eran = Hammer-Lahav
Cc: fcorella@pomcor.com; Mike Jones; oauth@ietf.org; Karen P. = Lewison
Subject: Re: [OAUTH-WG] Reasons not = to remove Client Assertion Credentials and OAuth2 HTTP Authentication = Scheme
Eran,
 
Yes, I agree = it feels like we're going in circles.  Might I point out who it was = that started this round? ;-)  Still, I think the discussion is = useful and important.
3.0 introduces the = concept (that any client authentication is acceptable) but then = specifies 2 acceptable methods (3.1 and 3.2) and leaves out other forms = of client authentication.  The specification can be interpreted = that the "any types" of methods supported are 3.1 and 3.2 ONLY.  It = just seems that the current spec has awkward = phrasing.
My suggestion was simply = to drop client_assertion and replace with some text indicating what = "any client authentication" is.  Assertion based authentication = would then be supported via the new paragraph 2 which allows for =  any kind of client authentication (SAML, Kerberos, STS, = whatever).
Just to add another loop, = what about cutting out the entire section 3 and keep client_id as a = required parameter in 4 and 5 (related to but not directly tied to = authentication) -- and getting OAuth out of authentication methods = entirely (other then to specify it as a = requirement)?
Phil

 



Phil Hunt [mailto:phil.hunt@oracle.com] 
Sent: Tuesday, January 18, 2011 = 2:45 PM
To: fcorella@pomcor.com
Cc: Eran Hammer-Lahav; Mike = Jones; oauth@ietf.org; Karen P. = Lewison
Subject: Re: [OAUTH-WG] Reasons not = to remove Client Assertion Credentials and OAuth2 HTTP Authentication = Scheme
 
(apologies if = this is a re-post, for some reason it was previously = bounced)
I've been arguing as well = to keep client assertion or some other stronger alternative to 3.1. =  Re-reading the introduction to section 3, I see that the last = paragraph says:
The = authorization server MAY authenticate the client using any appropriate = set of credentials and authentication schemes. The client MUST NOT = include more than one set of credentials or authentication mechanism = with each request.
 
I would suggest the following.  That we replace 3.2 with = this paragraph expressed as an alternative (move it from the = introduction and a little massaging).  The idea would be to make it = clear that using normal web authentication methodologies is perfectly = acceptable.  Further, I would also suggest that if an OOB = authentication is use (and preferred), that the client_id might still be = sent.  This handles case where mapping between client_id and the = client credentials is not obvious (or = easy). 
 
How about:
 
3.2. = Client Web (OOB) = Credentials
The client MAY be authenticated = using any appropriate set of credentials and web authentication scheme = supported by the authorization server. In cases where the client_id = cannot be mapped by the authorizing server from the client = credential, the client_id MUST be provided.[should client_id always be = provided?]
 
I would even include language that makes Client Web Credential = authentication the preferred methodology or at least list it = first.
This makes the = spec more consistent in that OAuth is not involved in the authentication = of the user or the client. -- it makes it more = consistent.
 
This approach will allow assertion based authentications (SAML, = STS, etc) or other approaches without having to get hung up on how it = should work inside of OAuth.
 
 SAML = specification.)  In other words, how does the authorization = server know that the client sending the assertion is actually the = subject of the assertion?

Francisco

--- On Tue, 1/18/11, Mike = Jones < wrote:
=


From: Mike Jones <eran@hueniverse.com>
Cc: "oauth@ietf.org" <

Having spoken to a number of people implementing the spec here, = I=92ve encountered strong objections to removing Client Assertion = Credentials and the OAuth2 HTTP Authentication Scheme.  It=92s also = not clear to me why we would make substantial breaking changes to the = specification when it is essentially ready for approval.  I=92ve = summarized the reasons I believe we should keep these two features = below.

Client Assertion = Credentials:  Many of the scenarios we care about require this = capability. They were key motivators for the Assertion Profile in WRAP = (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have = running code that requires this support. For example, the Azure Access = Control Service is a cloud Authorization server that supports several = protocols, including parts of OAuth 2.0 draft 10 (autonomous and web = server profiles). We are happy to update our implementation to = subsequent drafts & agree that the spec leaves a lot of = ambiguity.

In our implementation of the = autonomous and web server profiles, ACS allows clients to authenticate = using a signed assertion as well as with a username/password. The = username/pwd option is for clients that don=92t mind sending credentials = over the wire, while the signed assertion mechanism is for clients that = are more reticent to send raw credentials and for scenarios where it = isn=92t possible. To illustrate an example where username/pwd isn=92t = viable, consider the case of a client that needs to use an enterprise = identity to gain access to a cloud service. In many cases, corporate = policy demands that a client use an identity managed by the = organization. This means that the client should obtain an assertion from = an enterprise identity provider (Active Directory, Tivoli, etc.) and use = that assertion to obtain an access token which grants access to various = web service APIs. Many of our key MSFT customers and internal partner = teams rely on this mechanism and reverting exclusively to username/pwd = isn=92t an option for us.

 

'OAuth2' HTTP Authentication Scheme:  Simply put, = dropping this seems like a huge step away from interoperability.  = As one data point, Microsoft implements this in our WIF OAuth2 protected = resource code.  All up, clients need a way to authenticate to the = protected resource.  Also, existing WRAP implementations need this = functionality to migrate to OAuth2.   For all these reasons, = we support retaining this functionality in = OAuth2.

= --Apple-Mail-13--715732238-- From subbu@subbu.org Tue Jan 18 22:40:51 2011 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 DBD233A70CC for ; Tue, 18 Jan 2011 22:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3IcAws34OCG for ; Tue, 18 Jan 2011 22:40:49 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B28F63A6C42 for ; Tue, 18 Jan 2011 22:40:48 -0800 (PST) Received: by qyj19 with SMTP id 19so520719qyj.10 for ; Tue, 18 Jan 2011 22:43:27 -0800 (PST) Received: by 10.224.19.210 with SMTP id c18mr302468qab.343.1295419407693; Tue, 18 Jan 2011 22:43:27 -0800 (PST) Received: from [172.16.1.110] ([209.118.182.87]) by mx.google.com with ESMTPS id g28sm4498463qck.1.2011.01.18.22.43.25 (version=SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 22:43:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Subbu Allamaraju In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 18 Jan 2011 22:43:24 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <9530447D-0FB3-4586-AAF9-496A442F86F1@subbu.org> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 06:40:51 -0000 Could you clarify what the "confusing mess" part is? The cited reference = [1] is not useful. It is good to adhere to the challenge-response model of 2617 for wider = interoperability and discoverability (yes, WWW-Authenticate with a = well-known scheme name helps discovery and lack thereof reduces protocol = visibility). Subbu On Jan 14, 2011, at 10:32 PM, Eran Hammer-Lahav wrote: > One of the main problems with OAuth in general has always been the = unsanitary mix of authorization and authentication (=93it=92s an = authentication protocol=85 authorization protocol=85 authentication = protocol=94 [1]). It has always been a confusing mess. The work on 2.0 = has provided a valuable abstraction and separation of the two = components, especially the recent document split. In addition, the = recent work on the bearer token document and the MAC token type have = raised issues about OAuth and its relationship with HTTP authentication. > =20 > I would like to suggest we drop the =91OAuth2=92 WWW-Authenticate = header completely from the specification for the following reasons: > =20 > 1. Draft oauth-v2 is clearly not an authentication protocol. It = *utilizes* client authentication. It offers one fully defined method for = client authentication (which is basically HTTP Basic+), provides a = half-baked client assertion authentication hook, and leaves all end-user = authentication out of scope. > 2. The WWW-Authenticate header has absolutely no value, = interoperability-wise or otherwise. Discovery was rules to be beyond the = scope of this specification. Having a protected resource declare it = supports authentication using some unspecified credentials obtained = using some unspecified client flow is confusing at best. In the future, = an interoperable discovery mechanism will be needed to allow clients to = interact with completely unknown protected resources, but this has been = consistently ruled to be premature standardization at this point. > 3. OAuth is agnostic to token authentication, and we already = have three discrete token type proposals =96 all with active deployment = plans in the coming months. Two of these methods have already defined a = full HTTP authentication scheme (even if the bearer token specification = has not yet been updated to change its scheme name). > 4. HTTP *authentication* is not an appropriate facility to = negotiate *authorization*. OAuth authorization discovery can be added to = HTTP authentication schemes as attributes, but makes no sense as a = scheme of its own. The issues we are having with =91realm=92 is one of = the examples showing that we are abusing the header. > 5. Again, as specified, it adds no value and I am not aware of = any existing OAuth 1.0a implementation making use of the response header = for client interoperability (yes, many include it, but how many clients = actually rely on it, and if they do, how?). > =20 > For these reasons I would like to suggest we: > =20 > 1. Drop the WWW-Authenticate header definition and OAuth2 scheme = from the specification, leaving it up to each token type to define its = own authentication flow. In the future, a comprehensive discovery = specification should define a new HTTP response header for providing = discovery information. I have suggested using Link: rel=3D=92authorization= =92 as a simple yet powerful solution. > 2. Rename the document to =91The OAuth 2.0 Authorization = Protocol=92 to make it clear what this document is really about. > =20 > Comments? Counter argument? > =20 > EHL > =20 > [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Tue Jan 18 22:41:40 2011 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 8E2993A70E4 for ; Tue, 18 Jan 2011 22:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO8Hpv7s8JKi for ; Tue, 18 Jan 2011 22:41:37 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id 99FD53A6C42 for ; Tue, 18 Jan 2011 22:41:35 -0800 (PST) Received: from [87.142.247.58] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PfRm7-0000jy-JN; Wed, 19 Jan 2011 07:44:11 +0100 Message-ID: <4D36883E.4030903@lodderstedt.net> Date: Wed, 19 Jan 2011 07:44:14 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D333EE9.1030706@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D891@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D368647.9070405@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D897@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D897@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: multipart/alternative; boundary="------------030802020209030604020008" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters 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, 19 Jan 2011 06:41:40 -0000 This is a multi-part message in MIME format. --------------030802020209030604020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit That's true, but combining existing schemes with user credentials sent in the request body creates other problems (as you already stated). And most existing schemes are used for user authentication these days. It would be interesting to see, how many client authentication mechanisms exists that poeple want to use with OAuth in the context of a combined user/client authentication. Authentication of autonomous clients is like user authentication in my opinion, so no combination is required there. regards, Torsten. Am 19.01.2011 07:37, schrieb Eran Hammer-Lahav: > > If I want to use an existing client authentication scheme such as > Digest, your solution creates a conflict, unless we define a way to > combine grant + Digest into one header. > > EHL > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Tuesday, January 18, 2011 10:36 PM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Removal: credential body parameters > > Where do you see the conflict? In my proposal, user and client > credentials are combined into one Authorization header. But the same > holds for request parameters. I don't know whether combining > credentials in request parameters is more or less complex/conflicting > then combining them as named values within a header. > > regards, > Torsten. > > Am 19.01.2011 07:20, schrieb Eran Hammer-Lahav: > > This seems to conflict with the ability to mix and match grant types > and client authentication. If you define an authentication scheme for > each grant type, how would you also include client authentication > using, say, Basic or Digest? Seems like a complex framework for > combining schemes into one header. > > EHL > > *From:*Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > *Sent:* Sunday, January 16, 2011 10:55 AM > *To:* Eran Hammer-Lahav > *Cc:* OAuth WG > *Subject:* Re: [OAUTH-WG] Removal: credential body parameters > > Hi Eran, > > you made some good points and I agree with most of your analysis. The > way we use BASIC in the current draft is not perfect, mainly because > it is a compromise. It was basically the attempt to be more HTTP > compliant while still supporting the parameter-based approach. > > I would strongly object against removing BASIC and relying on body > parameters, only. We (Deutsche Telekom) have implemented that scheme > and do not see a real problem with it. > > In order to overcome the problems you listed, I would like to propose > an alternative approach. > > I would suggest to drop support for passing any credentials to the > tokens endpoint in the body of the POST request. Instead, I would > suggest to define one HTTP authentication scheme per grant type and > send the corresponding parameters within the Authorization header. > > Conceptually, the tokens endpoint is a resource URI clients use to > obtain tokens. The expected token scope can be explicitely specified > by the corresponding URI query parameter. So the simplest, complete > request to obtain a token could look as follows: > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > > scope=something > > Most authorization servers will certainly need credentials of some > kind as pre-requisite for token issuance. These credentials actually > authenticate the resource owner and the client to the authorization > server as well as prove the client's authorization to get the token. > Such credentials are usually passed using authorization headers in > HTTP requests. > > Let's take the example of the grant type "code". We could define a > scheme "CODE", which carries the parameters code, redirect_uri, > client_id and client_secret (optionally) as named values. An example > request could look as follows > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: CODE code='i1WsRn1uB1', > > redirect_uri='https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb', > client_id='s6BhdRkqt3', > client_secret='gX1fBat3bV' > > scope=something > > The following examples illustrate the approach with respect to the > grant types "password" and "refresh_token", respectively. > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: PWD username='johndoe', > password='A3ddj3w', > client_id='s6BhdRkqt3', > client_secret='gX1fBat3bV' > > scope=something > > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > Authorization: REFRESH token='n4E9O119d', > client_id='s6BhdRkqt3', > client_secret='gX1fBat3bV' > > scope=something > > I see the following advantages: > 1) The suggest approach is aligned with HTTP. So instead of using HTTP > as "transport protocol" only (as in the dark times of SOAP), we could > make better use of the existing framework for messaging, caching, and > security. > > 2) Since the proposed approach is alligned with HTTP authentication > and authorization in general, it would be an easy task to add support > for additional, existing authentication mechanisms, such as > Kerberos/SPNEGO, Digest or GBA to an OAuth authorization server. > > 3) WWW-Authenticate headers could be used to provide clients with > useful information about the capabilities of the authorization server. > In the following example, the server reacts to an unauthenticated > request with the following response > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: CODE uri="tokenservice.example.com/authorize" > WWW-Authenticate: PWD realm='users.example.com' > WWW-Authenticate: REFRESH > > which indicates its support for the grant types authorization_code, > username/password and refresh token. Additionally it provides the > client with the end-user endpoint URI of the authorization server and > the user realm supported for password authentication. > > 4) The proposed mechanism should work nicely with existing > authentication frameworks, since we would no longer use a mixed model > for passing credentials and dedicated HTTP authentication schemes. > > What do you think? What do others think? > > regards, > Torsten. > > > Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav: > > OAuth 2.0 provides two methods for client authentication using > password credentials: request parameters and HTTP Basic > authentication. I suggest we drop the requirement to support HTTP > Basic authentication, and only mention it as an example for > alternative methods. My reasons are: > > A few providers have expressed concerns over the need to support Basic > authentication, and some explicitly said they will not support it. > Parameter-based authentication, OTOH, is widely deployed in 2.0. > > Due to the way OAuth is being implemented at the HTTP authentication > layer (even if it is wrong), can conflict within the framework as both > a consumer and provider of authentication components. > > The mapping between username and client_id, while not complicated, is > still a big awkward, and can be confusing when combined with the > username and password grant type. On the other hand, the use of > client_id in the end-user authorization endpoint lends itself nicely > to the use of the same parameter elsewhere. > > Some existing authentication frameworks will have an issue handling > the mix of Basic authentication and parameters authentication due to > how each is deployed. In cases where a front gate handles Basic, it > will be hard to let requests through for parameter processing. > > Comments? Counter-arguments? > > EHL > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------030802020209030604020008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit That's true, but combining existing schemes with user credentials sent in the request body creates other problems (as you already stated). And most existing schemes are used for user authentication these days.

It would be interesting to see, how many client authentication mechanisms exists that poeple want to use with OAuth in the context of a combined user/client authentication.

Authentication of autonomous clients is like user authentication in my opinion, so no combination is required there.

regards,
Torsten.

Am 19.01.2011 07:37, schrieb Eran Hammer-Lahav:

If I want to use an existing client authentication scheme such as Digest, your solution creates a conflict, unless we define a way to combine grant + Digest into one header.

 

EHL

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Tuesday, January 18, 2011 10:36 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters

 

Where do you see the conflict? In my proposal, user and client credentials are combined into one Authorization header. But the same holds for request parameters. I don't know whether combining credentials in request parameters is more or less complex/conflicting then combining them as named values within a header.

regards,
Torsten.

Am 19.01.2011 07:20, schrieb Eran Hammer-Lahav:

This seems to conflict with the ability to mix and match grant types and client authentication. If you define an authentication scheme for each grant type, how would you also include client authentication using, say, Basic or Digest? Seems like a complex framework for combining schemes into one header.

 

EHL

 

From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, January 16, 2011 10:55 AM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters

 

Hi Eran,

you made some good points and I agree with most of your analysis. The way we use BASIC in the current draft is not perfect, mainly because it is a compromise. It was basically the attempt to be more HTTP compliant while still supporting the parameter-based approach.

I would strongly object against removing BASIC and relying on body parameters, only.  We (Deutsche Telekom) have implemented that scheme and do not see a real problem with it.

In order to overcome the problems you listed, I would like to propose an alternative approach.

I would suggest to drop support for passing any credentials to the tokens endpoint in the body of the POST request. Instead, I would suggest to define one HTTP authentication scheme per grant type and send the corresponding parameters within the Authorization header.

Conceptually, the tokens endpoint is a resource URI clients use to obtain tokens. The expected token scope can be explicitely specified by the corresponding URI query parameter. So the simplest, complete request to obtain a token could look as follows:

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded

     scope=something

Most authorization servers will certainly need credentials of some kind as pre-requisite for token issuance. These credentials actually authenticate the resource owner and the client to the authorization server as well as prove the client's authorization to get the token. Such credentials are usually passed using authorization headers in HTTP requests.

Let's take the example of the grant type "code". We could define a scheme "CODE", which carries the parameters code, redirect_uri, client_id and client_secret (optionally) as named values. An example request could look as follows

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: CODE code='i1WsRn1uB1',
                         redirect_uri='https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb',
                         client_id='s6BhdRkqt3',
                         client_secret='gX1fBat3bV'

     scope=something

The following examples illustrate the approach with respect to the grant types "password" and "refresh_token", respectively.

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: PWD username='johndoe',
                        password='A3ddj3w',
                         client_id='s6BhdRkqt3',
                         client_secret='gX1fBat3bV'

     scope=something

     POST /token HTTP/1.1
     Host: server.example.com
     Content-Type: application/x-www-form-urlencoded
     Authorization: REFRESH token='n4E9O119d',
                            client_id='s6BhdRkqt3',
                            client_secret='gX1fBat3bV'

     scope=something

I see the following advantages:
1) The suggest approach is aligned with HTTP. So instead of using HTTP as "transport protocol" only (as in the dark times of SOAP), we could make better use of the existing framework for messaging, caching, and security.

2) Since the proposed approach is alligned with HTTP authentication and authorization in general, it would be an easy task to add support for additional, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or GBA to an OAuth authorization server.

3) WWW-Authenticate headers could be used to provide clients with useful information about the capabilities of the authorization server. In the following example, the server reacts to an unauthenticated request with the following response

     HTTP/1.1 401 Unauthorized
     WWW-Authenticate: CODE uri="tokenservice.example.com/authorize"
     WWW-Authenticate: PWD realm='users.example.com'
     WWW-Authenticate: REFRESH

which indicates its support for the grant types authorization_code, username/password and refresh token. Additionally it provides the client with the end-user endpoint URI of the authorization server and the user realm supported for password authentication.

4) The proposed mechanism should work nicely with existing authentication frameworks, since we would no longer use a mixed model for passing credentials and dedicated HTTP authentication schemes.

What do you think? What do others think?

regards,
Torsten.


Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav:

OAuth 2.0 provides two methods for client authentication using password credentials: request parameters and HTTP Basic authentication. I suggest we drop the requirement to support HTTP Basic authentication, and only mention it as an example for alternative methods. My reasons are:

 

A few providers have expressed concerns over the need to support Basic authentication, and some explicitly said they will not support it. Parameter-based authentication, OTOH, is widely deployed in 2.0.

Due to the way OAuth is being implemented at the HTTP authentication layer (even if it is wrong), can conflict within the framework as both a consumer and provider of authentication components.

The mapping between username and client_id, while not complicated, is still a big awkward, and can be confusing when combined with the username and password grant type. On the other hand, the use of client_id in the end-user authorization endpoint lends itself nicely to the use of the same parameter elsewhere.

Some existing authentication frameworks will have an issue handling the mix of Basic authentication and parameters authentication due to how each is deployed. In cases where a front gate handles Basic, it will be hard to let requests through for parameter processing.

 

Comments? Counter-arguments?

 

EHL

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

 

 


--------------030802020209030604020008-- From eran@hueniverse.com Tue Jan 18 22:50:59 2011 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 DE3A43A6EF5 for ; Tue, 18 Jan 2011 22:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 PW5hUljmcOJc for ; Tue, 18 Jan 2011 22:50:38 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BCE8B3A6E7E for ; Tue, 18 Jan 2011 22:50:37 -0800 (PST) Received: (qmail 28697 invoked from network); 19 Jan 2011 06:53:16 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 06:53:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 18 Jan 2011 23:53:15 -0700 From: Eran Hammer-Lahav To: Phil Hunt Date: Tue, 18 Jan 2011 23:53:10 -0700 Thread-Topic: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme Thread-Index: Acu3o49Zlp81FSzLQCiz5AxL/qRikQAAfPxw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <72524.62131.qm@web55804.mail.re3.yahoo.com> <3AFB9555-B33E-4534-94F0-521BE821C352@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D360C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D88F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <0F9B4043-AFA5-4457-BB17-21779438DA43@oracle.com> In-Reply-To: <0F9B4043-AFA5-4457-BB17-21779438DA43@oracle.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_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89BP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 19 Jan 2011 06:51:00 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89BP3PW5EX1MB01E_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable WFM. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, January 18, 2011 10:37 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme I can agree with this. However if you keep client password (3.1) around I would prefer another sec= tion (3.x) that indicates "or any other client authentication method meetin= g the security requirements of the authentication server" to make it clear = and easy to scan. Phil phil.hunt@oracle.com On 2011-01-18, at 10:06 PM, Eran Hammer-Lahav wrote: Yes! This is exactly what I proposed if you combine removing Basic together= with the assertion credentials. Basically, provide the parameter based app= roach as the only one specified, make it clear that *any* suitable client a= uthentication is allowed, and then use HTTP Basic as an example of such oth= er methods. I am even happy to explicitly mention the use of assertions for= client authentication in the prose. I just don't think another sub-section= is needed. Would that be what you had in mind? EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, January 18, 2011 9:23 PM To: Eran Hammer-Lahav Cc: fcorella@pomcor.com; Mike Jones; oauth@ietf= .org; Karen P. Lewison Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme Eran, Yes, I agree it feels like we're going in circles. Might I point out who i= t was that started this round? ;-) Still, I think the discussion is useful= and important. 3.0 introduces the concept (that any client authentication is acceptable) b= ut then specifies 2 acceptable methods (3.1 and 3.2) and leaves out other f= orms of client authentication. The specification can be interpreted that t= he "any types" of methods supported are 3.1 and 3.2 ONLY. It just seems th= at the current spec has awkward phrasing. My suggestion was simply to drop client_assertion and replace with some tex= t indicating what "any client authentication" is. Assertion based authenti= cation would then be supported via the new paragraph 2 which allows for an= y kind of client authentication (SAML, Kerberos, STS, whatever). Just to add another loop, what about cutting out the entire section 3 and k= eep client_id as a required parameter in 4 and 5 (related to but not direct= ly tied to authentication) -- and getting OAuth out of authentication metho= ds entirely (other then to specify it as a requirement)? Phil phil.hunt@oracle.com On 2011-01-18, at 8:23 PM, Eran Hammer-Lahav wrote: Thanks Phil. The problem with this text is that it doesn't add anything new and I am not= sure what Client Web Credentials even mean. I have argued against under-specified features and will continue to object = their inclusion. When I initially agreed to include Yaron's text for client= assertion it was based on the assumption that it will provoke discussion a= nd will mature into a fully baked feature. It has not. Instead, it sits the= re without enough details to produce even a single working implementation, = not to mention any level of interoperability what-so-ever. The specification clearly allows any kind of client authentication. How is = that not enough? How is providing two parameters that are useless without f= urther profiling in any way useful? If you need stronger alternatives to 3.= 1 you are very welcome to define and publish such in companion specificatio= ns. It feels like we are going in circles where a few people are arguing to= keep a feature that does not accomplish their reasons for its inclusion. EHL From: Phil Hunt [mailto:phil.hunt@oracle.com] Sent: Tuesday, January 18, 2011 2:45 PM To: fcorella@pomcor.com Cc: Eran Hammer-Lahav; Mike Jones; oauth@ietf.org; K= aren P. Lewison Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme (apologies if this is a re-post, for some reason it was previously bounced) I've been arguing as well to keep client assertion or some other stronger a= lternative to 3.1. Re-reading the introduction to section 3, I see that th= e last paragraph says: The authorization server MAY authenticate the client using any appropriate = set of credentials and authentication schemes. The client MUST NOT include = more than one set of credentials or authentication mechanism with each requ= est. I would suggest the following. That we replace 3.2 with this paragraph exp= ressed as an alternative (move it from the introduction and a little massag= ing). The idea would be to make it clear that using normal web authenticat= ion methodologies is perfectly acceptable. Further, I would also suggest t= hat if an OOB authentication is use (and preferred), that the client_id mig= ht still be sent. This handles case where mapping between client_id and th= e client credentials is not obvious (or easy). How about: 3.2. Client Web (OOB) Credentials The client MAY be authenticated using any appropriate set of credentials an= d web authentication scheme supported by the authorization server. In cases= where the client_id cannot be mapped by the authorizing server from the cl= ient credential, the client_id MUST be provided.[should client_id always be= provided?] I would even include language that makes Client Web Credential authenticati= on the preferred methodology or at least list it first. This makes the spec more consistent in that OAuth is not involved in the au= thentication of the user or the client. -- it makes it more consistent. This approach will allow assertion based authentications (SAML, STS, etc) o= r other approaches without having to get hung up on how it should work insi= de of OAuth. Phil phil.hunt@oracle.com On 2011-01-18, at 12:26 PM, Francisco Corella wrote: Mike, As assertion use is described in the spec, a client assertion does not prov= ide any security whatsoever. How do you handle subject confirmation in you= r implementation? (See section 2.4.1.1 of the SAML specification.) In other word= s, how does the authorization server know that the client sending the asser= tion is actually the subject of the assertion? Francisco --- On Tue, 1/18/11, Mike Jones > wrote: From: Mike Jones > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and = OAuth2 HTTP Authentication Scheme To: "Eran Hammer-Lahav" > Cc: "oauth@ietf.org" > Date: Tuesday, January 18, 2011, 5:35 PM Having spoken to a number of people implementing the spec here, I've encoun= tered strong objections to removing Client Assertion Credentials and the OA= uth2 HTTP Authentication Scheme. It's also not clear to me why we would ma= ke substantial breaking changes to the specification when it is essentially= ready for approval. I've summarized the reasons I believe we should keep = these two features below. Client Assertion Credentials: Many of the scenarios we care about require = this capability. They were key motivators for the Assertion Profile in WRAP= (see =A7 5.2), have been part of OAuth 2 for quite a while, and we have ru= nning code that requires this support. For example, the Azure Access Contro= l Service is a cloud Authorization server that supports several protocols, = including parts of OAuth 2.0 draft 10 (autonomous and web server profiles).= We are happy to update our implementation to subsequent drafts & agree tha= t the spec leaves a lot of ambiguity. In our implementation of the autonomous and web server profiles, ACS allows= clients to authenticate using a signed assertion as well as with a usernam= e/password. The username/pwd option is for clients that don't mind sending = credentials over the wire, while the signed assertion mechanism is for clie= nts that are more reticent to send raw credentials and for scenarios where = it isn't possible. To illustrate an example where username/pwd isn't viable= , consider the case of a client that needs to use an enterprise identity to= gain access to a cloud service. In many cases, corporate policy demands th= at a client use an identity managed by the organization. This means that th= e client should obtain an assertion from an enterprise identity provider (A= ctive Directory, Tivoli, etc.) and use that assertion to obtain an access t= oken which grants access to various web service APIs. Many of our key MSFT = customers and internal partner teams rely on this mechanism and reverting e= xclusively to username/pwd isn't an option for us. 'OAuth2' HTTP Authentication Scheme: Simply put, dropping this seems like = a huge step away from interoperability. As one data point, Microsoft imple= ments this in our WIF OAuth2 protected resource code. All up, clients need= a way to authenticate to the protected resource. Also, existing WRAP impl= ementations need this functionality to migrate to OAuth2. For all these r= easons, we support retaining this functionality in OAuth2. Thanks, -- Mike -----Inline Attachment Follows----- _______________________________________________ OAuth mailing 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_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89BP3PW5EX1MB01E_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

WFM.=

 

EHL

 

<= b>From:<= /span> Phil Hunt [mailto:phil.hunt@oracle.com]
Sent: Tuesday, Januar= y 18, 2011 10:37 PM
To: Eran Hammer-Lahav
Cc: oauth@iet= f.org
Subject: Re: [OAUTH-WG] Reasons not to remove Client Assert= ion Credentials and OAuth2 HTTP Authentication Scheme

=

 

= I can agree with this.

 <= /o:p>

However if you keep client passwor= d (3.1) around I would prefer another section (3.x) that indicates "or= any other client authentication method meeting the security requirements o= f the authentication server" to make it clear and easy to scan.

 =

On 2011-01-18, at 10:06 PM, Eran H= ammer-Lahav wrote:



Yes! This is exactly what I p= roposed if you combine removing Basic together with the assertion credentia= ls. Basically, provide the parameter based approach as the only one specifi= ed, make it clear that *any* suitable client authentication is allow= ed, and then use HTTP Basic as an example of such other methods. I am even = happy to explicitly mention the use of assertions for client authentication= in the prose. I just don’t think another sub-section is needed.

 <= /o:p>

Would that be what you had = in mind?

&nbs= p;

EHL

 

From:<= /b> Phil Hunt [mailto:phil.hunt@orac= le.com] 
Sent: Tuesday, January 18, 2011 9:2= 3 PM
To: Eran Ham= mer-Lahav
Cc: fcorella@pomcor.com; Mike Jones; oauth@ietf.org; Karen P. Lewison
Subject: Re: [OAUTH-WG] Reasons not to remove Clie= nt Assertion Credentials and OAuth2 HTTP Authentication Scheme<= /o:p>

 

<= /div>

Eran,

 

Yes, I agree it feels like we're going in circles.  Might I point ou= t who it was that started this round? ;-)  Still, I think the discussi= on is useful and important.

 

3= .0 introduces the concept (that any client authentication is acceptable) bu= t then specifies 2 acceptable methods (3.1 and 3.2) and leaves out other fo= rms of client authentication.  The specification can be interpreted th= at the "any types" of methods supported are 3.1 and 3.2 ONLY. &nb= sp;It just seems that the current spec has awkward phrasing.

=

 

My suggestion was simply to drop clien= t_assertion and replace with some text indicating what "any client aut= hentication" is.  Assertion based authentication would then be su= pported via the new paragraph 2 which allows for  any kind of client a= uthentication (SAML, Kerberos, STS, whatever).

 

Just to add another loop, what about cutting out the enti= re section 3 and keep client_id as a required parameter in 4 and 5 (related= to but not directly tied to authentication) -- and getting OAuth out of au= thentication methods entirely (other then to specify it as a requirement)?<= o:p>

  <= /o:p>

 <= /p>

On 2011-01-18, at 8:23 PM, Era= n Hammer-Lahav wrote:

<= br>

= Thanks Phil.

 

The problem with this text is that it doesn’t add anythin= g new and I am not sure what Client Web Credentials even mean.<= /o:p>

I have argued against= under-specified features and will continue to object their inclusion. When= I initially agreed to include Yaron’s text for client assertion it w= as based on the assumption that it will provoke discussion and will mature = into a fully baked feature. It has not. Instead, it sits there without enou= gh details to produce even a single working implementation, not to mention = any level of interoperability what-so-ever.

 

<= /div>

The specification clearly allows= any kind of client authentication. How is that not enough? How is providin= g two parameters that are useless without further profiling in any way usef= ul? If you need stronger alternatives to 3.1 you are very welcome to define= and publish such in companion specifications. It feels like we are going i= n circles where a few people are arguing to keep a feature that does not ac= complish their reasons for its inclusion.

=

 

<= /div>

EHL

<= /div>

 

From: Phil H= unt [mailto:phil.hunt@oracle.com] =
Sent: Tue= sday, January 18, 2011 2:45 PM
To: fcorella@pomcor.co= m
Cc: Eran Ha= mmer-Lahav; Mike Jones; oauth@ietf.org; Karen P. Lewison
S= ubject: Re: [OAUTH-WG] = Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authenti= cation Scheme

 

(apologies if this is a re-post, for some reason it was previously= bounced)

 

I'= ve been arguing as well to keep client assertion or some other stronger alt= ernative to 3.1.  Re-reading the introduction to section 3, I see that= the last paragraph says:

 

The a= uthorization server MAY authenticate the client using any appropriate set o= f credentials and authentication schemes. The client MUST NOT include more = than one set of credentials or authentication mechanism with each request.<= /span>

=  

= I would suggest the following.  That we replace 3.2 with this paragrap= h expressed as an alternative (move it from the introduction and a little m= assaging).  The idea would be to make it clear that using normal web a= uthentication methodologies is perfectly acceptable.  Further, I would= also suggest that if an OOB authentication is use (and preferred), that th= e client_id might still be sent.  This handles case where mapping betw= een client_id and the client credentials is not obvious (or easy). 

 

How about= :

 = ;

= 3.2. Client Web (OOB) C= redentials


The client MAY be authenticated using any appropriate s= et of credentials and web authentication scheme supported by the authorizat= ion server. In cases where the client_id cannot be mapped by the authorizin= g server from the client credential, the client_id MUST be provided.[s= hould client_id always be provided?]

 

I would even include language t= hat makes Client Web Credential authentication the preferred methodology or= at least list it first.

 

This makes the spec more consistent in that OAuth is not = involved in the authentication of the user or the client. -- it makes it mo= re consistent.

 

This approach will allow assertion based authentications (SAML, STS= , etc) or other approaches without having to get hung up on how it should w= ork inside of OAuth.

 

Phil=

=

 

<= div>

On 2011-01-18, at 12:26 PM, Francisco Corella wrot= e:



<= br>

Mike,

As assertion use is= described in the spec, a client assertion does not provide any security wh= atsoever.  How do you handle subject confirmation in your implementati= on?  (See section 2.4.1.1 of the&n= bsp;SAML specification.)  In other words, how does the = authorization server know that the client sending the assertion is actually= the subject of the assertion?

Francisco

--- On Tue, 1/18/11, Mike Jones <Michael.Jones@microsoft.com> wrote:


From: Mike Jones <Michael.Jones@microsoft.com>= ;
Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials= and OAuth2 HTTP Authentication Scheme
To: "Eran Hammer-Lahav"= <eran@hueniverse.com>
= Cc: "oauth@ietf.org" <oauth@ietf.org>
Date: Tuesday, Ja= nuary 18, 2011, 5:35 PM

Having spoken to a number of people implementing = the spec here, I’ve encountered strong objections to removing Client = Assertion Credentials and the OAuth2 HTTP Authentication Scheme.  It&#= 8217;s also not clear to me why we would make substantial breaking changes = to the specification when it is essentially ready for approval.  IR= 17;ve summarized the reasons I believe we should keep these two features be= low.

 

Client Assertion Cr= edentials:  Many of the scenarios we care about require this capab= ility. They were key motivators for the Assertion Profile in WRAP (see =A7 = 5.2), have been part of OAuth 2 for quite a while, and we have running code= that requires this support. For example, the Azure Access Control Service = is a cloud Authorization server that supports several protocols, including = parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We are ha= ppy to update our implementation to subsequent drafts & agree that the = spec leaves a lot of ambiguity.

 

In our implementation of the autonomous and web server profiles, ACS a= llows clients to authenticate using a signed assertion as well as with a us= ername/password. The username/pwd option is for clients that don’t mi= nd sending credentials over the wire, while the signed assertion mechanism = is for clients that are more reticent to send raw credentials and for scena= rios where it isn’t possible. To illustrate an example where username= /pwd isn’t viable, consider the case of a client that needs to use an= enterprise identity to gain access to a cloud service. In many cases, corp= orate policy demands that a client use an identity managed by the organizat= ion. This means that the client should obtain an assertion from an enterpri= se identity provider (Active Directory, Tivoli, etc.) and use that assertio= n to obtain an access token which grants access to various web service APIs= . Many of our key MSFT customers and internal partner teams rely on this me= chanism and reverting exclusively to username/pwd isn’t an option for= us.

 

'OAuth2' HTTP Authe= ntication Scheme:  Simply put, dropping this seems like a huge ste= p away from interoperability.  As one data point, Microsoft implements= this in our WIF OAuth2 protected resource code.  All up, clients need= a way to authenticate to the protected resource.  Also, existing WRAP= implementations need this functionality to migrate to OAuth2.   = For all these reasons, we support retaining this functionality in OAuth2.

 

    &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Thanks,

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

 

<= br>-----Inline Attachment Follows-----

_______________________________________________
OAuth mail= ing list
OAuth@iet= f.org
https://www.ietf.org/mailman/listinfo/oauth

<= /div>

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

 

 

<= o:p> 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89BP3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jan 18 23:03:25 2011 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 A60443A70DC for ; Tue, 18 Jan 2011 23:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 UQn79ZwQo8j2 for ; Tue, 18 Jan 2011 23:03:22 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id A27563A6E7E for ; Tue, 18 Jan 2011 23:03:22 -0800 (PST) Received: (qmail 23218 invoked from network); 19 Jan 2011 07:06:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 07:06:01 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 19 Jan 2011 00:06:01 -0700 From: Eran Hammer-Lahav To: "'Michael.Jones@microsoft.com'" Date: Wed, 19 Jan 2011 00:05:56 -0700 Thread-Topic: Bear token scheme name Thread-Index: Acu3pr1t3syl2UOrRViF4qH3Mgl/vQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89CP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: [OAUTH-WG] Bear token scheme name 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, 19 Jan 2011 07:03:25 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89CP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please change the draft to use a different scheme name than 'OAuth2' for th= e bearer token authentication scheme. Given the unstable state of the heade= r (still is), it is perfectly fine to make this change. The list includes a= detailed discussion about this. I am strongly opposed to giving the bearer= token scheme a name giving it the appearance of the preferred or canonical= token authentication method. I don't care what you change it to as long as= it is not 'OAuth2' or 'OAuth'. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89CP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please change th= e draft to use a different scheme name than ‘OAuth2’ for the be= arer token authentication scheme. Given the unstable state of the header (s= till is), it is perfectly fine to make this change. The list includes a det= ailed discussion about this. I am strongly opposed to giving the bearer tok= en scheme a name giving it the appearance of the preferred or canonical tok= en authentication method. I don’t care what you change it to as long = as it is not ‘OAuth2’ or ‘OAuth’.

 

EHL<= /p>

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89CP3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jan 18 23:11:44 2011 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 DCE8D3A70D6 for ; Tue, 18 Jan 2011 23:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 7lDRwqG1tkHC for ; Tue, 18 Jan 2011 23:11:25 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 161093A6DAD for ; Tue, 18 Jan 2011 23:11:21 -0800 (PST) Received: (qmail 32349 invoked from network); 19 Jan 2011 07:14:01 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 07:14:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 19 Jan 2011 00:13:59 -0700 From: Eran Hammer-Lahav To: Subbu Allamaraju Date: Wed, 19 Jan 2011 00:13:54 -0700 Thread-Topic: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu3pC413HBMFgdUQdOA7+mlU5iTVwAAbAsg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9530447D-0FB3-4586-AAF9-496A442F86F1@subbu.org> In-Reply-To: <9530447D-0FB3-4586-AAF9-496A442F86F1@subbu.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 07:11:44 -0000 Hi Subbu, > -----Original Message----- > From: Subbu Allamaraju [mailto:subbu@subbu.org] > Sent: Tuesday, January 18, 2011 10:43 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme >=20 > Could you clarify what the "confusing mess" part is? The cited reference = [1] is > not useful. It was not meant to be useful... :-) =20 > It is good to adhere to the challenge-response model of 2617 for wider > interoperability and discoverability (yes, WWW-Authenticate with a well- > known scheme name helps discovery and lack thereof reduces protocol > visibility). There are two separate issues here. First, whether the HTTP authentication = model with its challenge response architecture is suitable for OAuth (autho= rization). Second, if the currently defined response header field provides = any level of interoperability. My answer is no to both. I'll explain. OAuth is an authorization protocol not an authentication protocol. With the= exception of the client password credentials passed in the form-encoded bo= dy, the protocol is completely authentication agnostic for both client auth= entication and end-user login. Add to that the recent separation of the tok= en authentication schemes, and you get a clean and well defined authorizati= on model. A client using a token has to answer two questions: how to obtain authoriza= tion and how to use the provided authorization to access the protected reso= urce. As currently specified, the header answers neither. In addition, for = this to be a challenge response protocol, the client response must match th= e challenge which is not possible if the response can use different schemes= based on the token type issued. That has proven very confusing to people o= n this list. The only case a client is going to encounter the WWW-Authenticate header is= when making an unauthenticated request (the three error codes provided add= little to no value on top of the existing HTTP status codes). The only tim= e that will happen is when the client is unfamiliar with the server. In suc= h a case, the protocol as specified provides no further steps. The resource= server is saying 'I support OAuth2' but implicitly saying 'and good luck f= iguring out what to do next'. For this to provide any actual interoperabili= ty at this level, the header must provide the supported profiles, endpoints= , extensions, scope, etc. None of that is currently available. This means the header is defined solely as a potential future extension poi= nt for discovery, which brings me back to the first issue. The WWW-Authenti= cate header is not the right place to provide authorization server discover= y information. I think our inability to fit 'realm' into our framework show= s how the HTTP authentication headers are not meant for this. EHL =20 > Subbu >=20 > On Jan 14, 2011, at 10:32 PM, Eran Hammer-Lahav wrote: >=20 > > One of the main problems with OAuth in general has always been the > unsanitary mix of authorization and authentication ("it's an authenticati= on > protocol... authorization protocol... authentication protocol" [1]). It h= as always > been a confusing mess. The work on 2.0 has provided a valuable abstractio= n > and separation of the two components, especially the recent document spli= t. > In addition, the recent work on the bearer token document and the MAC > token type have raised issues about OAuth and its relationship with HTTP > authentication. > > > > I would like to suggest we drop the 'OAuth2' WWW-Authenticate header > completely from the specification for the following reasons: > > > > 1. Draft oauth-v2 is clearly not an authentication protocol. It *= utilizes* > client authentication. It offers one fully defined method for client > authentication (which is basically HTTP Basic+), provides a half-baked cl= ient > assertion authentication hook, and leaves all end-user authentication out= of > scope. > > 2. The WWW-Authenticate header has absolutely no value, > interoperability-wise or otherwise. Discovery was rules to be beyond the > scope of this specification. Having a protected resource declare it suppo= rts > authentication using some unspecified credentials obtained using some > unspecified client flow is confusing at best. In the future, an interoper= able > discovery mechanism will be needed to allow clients to interact with > completely unknown protected resources, but this has been consistently > ruled to be premature standardization at this point. > > 3. OAuth is agnostic to token authentication, and we already have= three > discrete token type proposals - all with active deployment plans in the > coming months. Two of these methods have already defined a full HTTP > authentication scheme (even if the bearer token specification has not yet > been updated to change its scheme name). > > 4. HTTP *authentication* is not an appropriate facility to negoti= ate > *authorization*. OAuth authorization discovery can be added to HTTP > authentication schemes as attributes, but makes no sense as a scheme of i= ts > own. The issues we are having with 'realm' is one of the examples showing > that we are abusing the header. > > 5. Again, as specified, it adds no value and I am not aware of an= y existing > OAuth 1.0a implementation making use of the response header for client > interoperability (yes, many include it, but how many clients actually rel= y on it, > and if they do, how?). > > > > For these reasons I would like to suggest we: > > > > 1. Drop the WWW-Authenticate header definition and OAuth2 scheme > from the specification, leaving it up to each token type to define its ow= n > authentication flow. In the future, a comprehensive discovery specificati= on > should define a new HTTP response header for providing discovery > information. I have suggested using Link: rel=3D'authorization' as a simp= le yet > powerful solution. > > 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' = to > make it clear what this document is really about. > > > > Comments? Counter argument? > > > > EHL > > > > [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Tue Jan 18 23:12:54 2011 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 A7B463A70EB for ; Tue, 18 Jan 2011 23:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 7btKvbte2dgO for ; Tue, 18 Jan 2011 23:12:52 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 18FFD3A70D5 for ; Tue, 18 Jan 2011 23:12:52 -0800 (PST) Received: (qmail 1635 invoked from network); 19 Jan 2011 07:15:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 07:15:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 19 Jan 2011 00:15:30 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Wed, 19 Jan 2011 00:15:24 -0700 Thread-Topic: [OAUTH-WG] Removal: credential body parameters Thread-Index: Acu3pEo7z+kYTSBbTX6qXKVU8QHYLAABDReg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D333EE9.1030706@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D891@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D368647.9070405@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D897@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4D36883E.4030903@lodderstedt.net> In-Reply-To: <4D36883E.4030903@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89EP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters 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, 19 Jan 2011 07:12:54 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89EP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The requirement to support client credentials in the body is implicit, whic= h means providers can choose not to use it if they rather use a different m= ethod of client authentication. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Tuesday, January 18, 2011 10:44 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters That's true, but combining existing schemes with user credentials sent in t= he request body creates other problems (as you already stated). And most ex= isting schemes are used for user authentication these days. It would be interesting to see, how many client authentication mechanisms e= xists that poeple want to use with OAuth in the context of a combined user/= client authentication. Authentication of autonomous clients is like user authentication in my opin= ion, so no combination is required there. regards, Torsten. Am 19.01.2011 07:37, schrieb Eran Hammer-Lahav: If I want to use an existing client authentication scheme such as Digest, y= our solution creates a conflict, unless we define a way to combine grant + = Digest into one header. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Tuesday, January 18, 2011 10:36 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters Where do you see the conflict? In my proposal, user and client credentials = are combined into one Authorization header. But the same holds for request = parameters. I don't know whether combining credentials in request parameter= s is more or less complex/conflicting then combining them as named values w= ithin a header. regards, Torsten. Am 19.01.2011 07:20, schrieb Eran Hammer-Lahav: This seems to conflict with the ability to mix and match grant types and cl= ient authentication. If you define an authentication scheme for each grant = type, how would you also include client authentication using, say, Basic or= Digest? Seems like a complex framework for combining schemes into one head= er. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Sunday, January 16, 2011 10:55 AM To: Eran Hammer-Lahav Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: credential body parameters Hi Eran, you made some good points and I agree with most of your analysis. The way w= e use BASIC in the current draft is not perfect, mainly because it is a com= promise. It was basically the attempt to be more HTTP compliant while still= supporting the parameter-based approach. I would strongly object against removing BASIC and relying on body paramete= rs, only. We (Deutsche Telekom) have implemented that scheme and do not se= e a real problem with it. In order to overcome the problems you listed, I would like to propose an al= ternative approach. I would suggest to drop support for passing any credentials to the tokens e= ndpoint in the body of the POST request. Instead, I would suggest to define= one HTTP authentication scheme per grant type and send the corresponding p= arameters within the Authorization header. Conceptually, the tokens endpoint is a resource URI clients use to obtain t= okens. The expected token scope can be explicitely specified by the corresp= onding URI query parameter. So the simplest, complete request to obtain a t= oken could look as follows: POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded scope=3Dsomething Most authorization servers will certainly need credentials of some kind as = pre-requisite for token issuance. These credentials actually authenticate t= he resource owner and the client to the authorization server as well as pro= ve the client's authorization to get the token. Such credentials are usuall= y passed using authorization headers in HTTP requests. Let's take the example of the grant type "code". We could define a scheme "= CODE", which carries the parameters code, redirect_uri, client_id and clien= t_secret (optionally) as named values. An example request could look as fol= lows POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: CODE code=3D'i1WsRn1uB1', redirect_uri=3D'https%3A%2F%2Fclient%2Eexample%2Ec= om%2Fcb', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething The following examples illustrate the approach with respect to the grant ty= pes "password" and "refresh_token", respectively. POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: PWD username=3D'johndoe', password=3D'A3ddj3w', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething POST /token HTTP/1.1 Host: server.example.com Content-Type: application/x-www-form-urlencoded Authorization: REFRESH token=3D'n4E9O119d', client_id=3D's6BhdRkqt3', client_secret=3D'gX1fBat3bV' scope=3Dsomething I see the following advantages: 1) The suggest approach is aligned with HTTP. So instead of using HTTP as "= transport protocol" only (as in the dark times of SOAP), we could make bett= er use of the existing framework for messaging, caching, and security. 2) Since the proposed approach is alligned with HTTP authentication and aut= horization in general, it would be an easy task to add support for addition= al, existing authentication mechanisms, such as Kerberos/SPNEGO, Digest or = GBA to an OAuth authorization server. 3) WWW-Authenticate headers could be used to provide clients with useful in= formation about the capabilities of the authorization server. In the follow= ing example, the server reacts to an unauthenticated request with the follo= wing response HTTP/1.1 401 Unauthorized WWW-Authenticate: CODE uri=3D"tokenservice.example.com/authorize" WWW-Authenticate: PWD realm=3D'users.example.com' WWW-Authenticate: REFRESH which indicates its support for the grant types authorization_code, usernam= e/password and refresh token. Additionally it provides the client with the = end-user endpoint URI of the authorization server and the user realm suppor= ted for password authentication. 4) The proposed mechanism should work nicely with existing authentication f= rameworks, since we would no longer use a mixed model for passing credentia= ls and dedicated HTTP authentication schemes. What do you think? What do others think? regards, Torsten. Am 15.01.2011 07:53, schrieb Eran Hammer-Lahav: OAuth 2.0 provides two methods for client authentication using password cre= dentials: request parameters and HTTP Basic authentication. I suggest we dr= op the requirement to support HTTP Basic authentication, and only mention i= t as an example for alternative methods. My reasons are: A few providers have expressed concerns over the need to support Basic auth= entication, and some explicitly said they will not support it. Parameter-ba= sed authentication, OTOH, is widely deployed in 2.0. Due to the way OAuth is being implemented at the HTTP authentication layer = (even if it is wrong), can conflict within the framework as both a consumer= and provider of authentication components. The mapping between username and client_id, while not complicated, is still= a big awkward, and can be confusing when combined with the username and pa= ssword grant type. On the other hand, the use of client_id in the end-user = authorization endpoint lends itself nicely to the use of the same parameter= elsewhere. Some existing authentication frameworks will have an issue handling the mix= of Basic authentication and parameters authentication due to how each is d= eployed. In cases where a front gate handles Basic, it will be hard to let = requests through for parameter processing. Comments? Counter-arguments? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89EP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= The requirement to support client credentials= in the body is implicit, which means providers can choose not to use it if= they rather use a different method of client authentication.

 

EHL

 =

Fr= om: Torsten Lodderstedt [mailto:torsten@lodderstedt.net= ]
Sent: Tuesday, January 18, 2011 10:44 PM
To: Eran Ha= mmer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Removal= : credential body parameters

 

That's true, but combinin= g existing schemes with user credentials sent in the request body creates o= ther problems (as you already stated). And most existing schemes are used f= or user authentication these days.

It would be interesting to see, h= ow many client authentication mechanisms exists that poeple want to use wit= h OAuth in the context of a combined user/client authentication.

Aut= hentication of autonomous clients is like user authentication in my opinion= , so no combination is required there.

regards,
Torsten.

= Am 19.01.2011 07:37, schrieb Eran Hammer-Lahav:

If I want to use an existing client = authentication scheme such as Digest, your solution creates a conflict, unl= ess we define a way to combine grant + Digest into one header.<= /o:p>

 

EHL<= o:p>

 

 

Where do you see the= conflict? In my proposal, user and client credentials are combined into on= e Authorization header. But the same holds for request parameters. I don't = know whether combining credentials in request parameters is more or less co= mplex/conflicting then combining them as named values within a header.
<= br>regards,
Torsten.

Am 19.01.2011 07:20, schrieb Eran Hammer-Lah= av:

This = seems to conflict with the ability to mix and match grant types and client = authentication. If you define an authentication scheme for each grant type,= how would you also include client authentication using, say, Basic or Dige= st? Seems like a complex framework for combining schemes into one header.

&nbs= p;

= EHL

 

F= rom: Torsten Lodderstedt [mailto:torsten@lodderstedt.net]
Sent: Sunday, = January 16, 2011 10:55 AM
To: Eran Hammer-Lahav
Cc: OAu= th WG
Subject: Re: [OAUTH-WG] Removal: credential body parameters=

 

Hi Eran,

you made some good points and I agree= with most of your analysis. The way we use BASIC in the current draft is n= ot perfect, mainly because it is a compromise. It was basically the attempt= to be more HTTP compliant while still supporting the parameter-based appro= ach.

I would strongly object against removing BASIC and relying on = body parameters, only.  We (Deutsche Telekom) have implemented that sc= heme and do not see a real problem with it.

In order to overcome th= e problems you listed, I would like to propose an alternative approach.
I would suggest to drop support for passing any credentials to the tok= ens endpoint in the body of the POST request. Instead, I would suggest to d= efine one HTTP authentication scheme per grant type and send the correspond= ing parameters within the Authorization header.

Conceptually, the t= okens endpoint is a resource URI clients use to obtain tokens. The expected= token scope can be explicitely specified by the corresponding URI query pa= rameter. So the simplest, complete request to obtain a token could look as = follows:

     POST /token HTTP/1.1
 &nbs= p;   Host: server.example.com
     Content= -Type: application/x-www-form-urlencoded

     sc= ope=3Dsomething

Most authorization servers will certainly need crede= ntials of some kind as pre-requisite for token issuance. These credentials = actually authenticate the resource owner and the client to the authorizatio= n server as well as prove the client's authorization to get the token. Such= credentials are usually passed using authorization headers in HTTP request= s.

Let's take the example of the grant type "code". We cou= ld define a scheme "CODE", which carries the parameters code, red= irect_uri, client_id and client_secret (optionally) as named values. An exa= mple request could look as follows

     POST /to= ken HTTP/1.1
     Host: server.example.com
 =     Content-Type: application/x-www-form-urlencoded
 = ;    Authorization: CODE code=3D'i1WsRn1uB1',
  = ;            &n= bsp;          redirect_uri=3D'= https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb',
    &nbs= p;            &= nbsp;       client_id=3D's6BhdRkqt3',
&nbs= p;            &= nbsp;           client_se= cret=3D'gX1fBat3bV'

     scope=3Dsomething
The following examples illustrate the approach with respect to the grant = types "password" and "refresh_token", respectively.
=
     POST /token HTTP/1.1
   &nbs= p; Host: server.example.com
     Content-Type: appli= cation/x-www-form-urlencoded
     Authorization: PWD= username=3D'johndoe',
        &= nbsp;           &nbs= p;   password=3D'A3ddj3w',
      = ;            &n= bsp;      client_id=3D's6BhdRkqt3',
  = ;            &n= bsp;          client_secret=3D= 'gX1fBat3bV'

     scope=3Dsomething

 = ;    POST /token HTTP/1.1
     Host: = server.example.com
     Content-Type: application/x-= www-form-urlencoded
     Authorization: REFRESH toke= n=3D'n4E9O119d',
         &= nbsp;           &nbs= p;      client_id=3D's6BhdRkqt3',
  &= nbsp;           &nbs= p;             = client_secret=3D'gX1fBat3bV'

     scope=3Dsometh= ing

I see the following advantages:
1) The suggest approach is al= igned with HTTP. So instead of using HTTP as "transport protocol"= only (as in the dark times of SOAP), we could make better use of the exist= ing framework for messaging, caching, and security.

2) Since the pr= oposed approach is alligned with HTTP authentication and authorization in g= eneral, it would be an easy task to add support for additional, existing au= thentication mechanisms, such as Kerberos/SPNEGO, Digest or GBA to an OAuth= authorization server.

3) WWW-Authenticate headers could be used to = provide clients with useful information about the capabilities of the autho= rization server. In the following example, the server reacts to an unauthen= ticated request with the following response

    = HTTP/1.1 401 Unauthorized
     WWW-Authenticate: CO= DE uri=3D"tokenservice.example.com/authorize"
  &nbs= p;  WWW-Authenticate: PWD realm=3D'users.example.com'
  &= nbsp;  WWW-Authenticate: REFRESH

which indicates its support fo= r the grant types authorization_code, username/password and refresh token. = Additionally it provides the client with the end-user endpoint URI of the a= uthorization server and the user realm supported for password authenticatio= n.

4) The proposed mechanism should work nicely with existing authen= tication frameworks, since we would no longer use a mixed model for passing= credentials and dedicated HTTP authentication schemes.

What do you = think? What do others think?

regards,
Torsten.


Am 15.0= 1.2011 07:53, schrieb Eran Hammer-Lahav:

OAuth 2.0 provides two methods for client authentication using password c= redentials: request parameters and HTTP Basic authentication. I suggest we = drop the requirement to support HTTP Basic authentication, and only mention= it as an example for alternative methods. My reasons are:

 

A few providers have expressed concerns over the ne= ed to support Basic authentication, and some explicitly said they will not = support it. Parameter-based authentication, OTOH, is widely deployed in 2.0= .

Du= e to the way OAuth is being implemented at the HTTP authentication layer (e= ven if it is wrong), can conflict within the framework as both a consumer a= nd provider of authentication components.

The mapping between username and clie= nt_id, while not complicated, is still a big awkward, and can be confusing = when combined with the username and password grant type. On the other hand,= the use of client_id in the end-user authorization endpoint lends itself n= icely to the use of the same parameter elsewhere.

Some existing authentication = frameworks will have an issue handling the mix of Basic authentication and = parameters authentication due to how each is deployed. In cases where a fro= nt gate handles Basic, it will be hard to let requests through for paramete= r processing.

 

Comments? Counter-arguments?

 

EHL

 =
;
 
________________________=
_______________________
OAuth mailing list<=
/pre>
OAuth@ietf.org
https://ww=
w.ietf.org/mailman/listinfo/oauth
=
 

 

 

=
= --_000_90C41DD21FB7C64BB94121FBBC2E723445A6B9D89EP3PW5EX1MB01E_-- From hannes.tschofenig@gmx.net Tue Jan 18 23:26:11 2011 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 2667B3A6F90 for ; Tue, 18 Jan 2011 23:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, 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 6QObbuy7Uzb9 for ; Tue, 18 Jan 2011 23:26:09 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 55D393A6F25 for ; Tue, 18 Jan 2011 23:26:09 -0800 (PST) Received: (qmail invoked by alias); 19 Jan 2011 07:28:47 -0000 Received: from unknown (EHLO [10.255.139.127]) [192.100.123.77] by mail.gmx.net (mp040) with SMTP; 19 Jan 2011 08:28:47 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/F5XA0mmHFcb1f7XCZRrzqniur//sBtHiM3lh6Sz XNyWcZONQ/7zC8 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 19 Jan 2011 09:28:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <54F012B0-449B-4D66-9C18-3401E2EA7B6F@gmx.net> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) X-Y-GMX-Trusted: 0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 19 Jan 2011 07:26:11 -0000 Hi Eran,=20 Hi all,=20 I would like to start a working group last call on the base = specification soon and the writeup in Section 3.2 about the Client = Assertion Credentials is, unfortunately, not ready yet. Particularly the = missing security discussion scares me.=20 Hence, I would encourage someone to take the text from that section and = to produce a new draft that also includes a reasonable security = description. Do we have a volunteer? Ciao Hannes On Jan 15, 2011, at 8:45 AM, Eran Hammer-Lahav wrote: > I would like to suggest we drop the client assertion credentials (-11 = section 3.2) from the specification, and if needed, publish it as a = separate specification for the following reasons: > =20 > 1. The mechanism is under specified, especially in its handling = of the client_id identifier (when used to obtain end-user = authorization). It does not contain any implementation details to = accomplish any level of interoperability or functionality. This is in = contrast to the assertion grant type which has matured over a year into = a fully thought-out extension mechanism, as well as a separate SAML = assertion specification with active deployment (the two, together with = running code, show clear consensus). > 2. The section is a confused mix of security considerations = sprinkled with normative language. Instead, it should be replaced with = guidelines for extending the set of supported client credentials, but = without defining a new registry. It is clearly an area of little = deployment experience for OAuth, and that includes using HTTP Basic = authentication for client authentication (more on that to come). > 3. The section has received a little support and a little = objection. Those who still want to advocate for it need to show not only = consensus for keeping it, but also active community support for = deploying it. Deployment, of course, will also require showing progress = on public specifications profiling the mechanism into a useful = interoperable feature. > =20 > Comments? Counter-arguments? > =20 > EHL > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From subbu@subbu.org Tue Jan 18 23:34:23 2011 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 C35813A6F90 for ; Tue, 18 Jan 2011 23:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rn0oAAP83bK5 for ; Tue, 18 Jan 2011 23:34:22 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id A9CAF3A6E7E for ; Tue, 18 Jan 2011 23:34:22 -0800 (PST) Received: by ywk9 with SMTP id 9so164016ywk.31 for ; Tue, 18 Jan 2011 23:37:01 -0800 (PST) Received: by 10.151.8.16 with SMTP id l16mr478191ybi.284.1295422621644; Tue, 18 Jan 2011 23:37:01 -0800 (PST) Received: from [172.16.1.110] ([209.118.182.87]) by mx.google.com with ESMTPS id j3sm4148552ybe.23.2011.01.18.23.36.57 (version=SSLv3 cipher=RC4-MD5); Tue, 18 Jan 2011 23:37:01 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Subbu Allamaraju In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Tue, 18 Jan 2011 23:36:53 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9530447D-0FB3-4586-AAF9-496A442F86F1@subbu.org> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89D@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 07:34:23 -0000 On Jan 18, 2011, at 11:13 PM, Eran Hammer-Lahav wrote: > OAuth is an authorization protocol not an authentication protocol. = With the exception of the client password credentials passed in the = form-encoded body, the protocol is completely authentication agnostic = for both client authentication and end-user login. Add to that the = recent separation of the token authentication schemes, and you get a = clean and well defined authorization model. >=20 > A client using a token has to answer two questions: how to obtain = authorization and how to use the provided authorization to access the = protected resource. As currently specified, the header answers neither. = In addition, for this to be a challenge response protocol, the client = response must match the challenge which is not possible if the response = can use different schemes based on the token type issued. That has = proven very confusing to people on this list. I agree about the separation, but a better fix is to name the protocols = that the client can use for each step as part of this header. In any = case, 401 responses are required (a MUST in 2616) to have a = WWW-Authenticate header with a scheme. Dropping the header is not a = choice that the OAuth draft or can/should make. Leaving the scheme name = choice to each implementation would be confusing to the community. > The only case a client is going to encounter the WWW-Authenticate = header is when making an unauthenticated request (the three error codes = provided add little to no value on top of the existing HTTP status = codes). The only time that will happen is when the client is unfamiliar = with the server. In such a case, the protocol as specified provides no = further steps. The resource server is saying 'I support OAuth2' but = implicitly saying 'and good luck figuring out what to do next'. For this = to provide any actual interoperability at this level, the header must = provide the supported profiles, endpoints, extensions, scope, etc. None = of that is currently available. Actually, providing an HTML representation for 401 responses with "here = is how to can get started to supply an Authorization header to access = this resource" is a good step towards discoverability.=20 > This means the header is defined solely as a potential future = extension point for discovery, which brings me back to the first issue. = The WWW-Authenticate header is not the right place to provide = authorization server discovery information. I think our inability to fit = 'realm' into our framework shows how the HTTP authentication headers are = not meant for this. Including identifiers (like media types, encoding names, or even auth = schems) as part of the protocol gives some indirection to their = specifications elsewhere (though not perfect, such as an IANA registry). Subbu= From eran@hueniverse.com Tue Jan 18 23:58:43 2011 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 CB3753A6FB2 for ; Tue, 18 Jan 2011 23:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 1vF7uTRS+GFH for ; Tue, 18 Jan 2011 23:58:42 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A23D53A6F90 for ; Tue, 18 Jan 2011 23:58:42 -0800 (PST) Received: (qmail 11017 invoked from network); 19 Jan 2011 08:01:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 08:01:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 19 Jan 2011 01:01:20 -0700 From: Eran Hammer-Lahav To: Subbu Allamaraju Date: Wed, 19 Jan 2011 01:01:14 -0700 Thread-Topic: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu3q6m7tPqdeHDyTTq36PKBqGso4AAAralg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61814@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9530447D-0FB3-4586-AAF9-496A442F86F1@subbu.org> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 07:58:44 -0000 > -----Original Message----- > From: Subbu Allamaraju [mailto:subbu@subbu.org] > Sent: Tuesday, January 18, 2011 11:37 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme >=20 >=20 > On Jan 18, 2011, at 11:13 PM, Eran Hammer-Lahav wrote: >=20 > > OAuth is an authorization protocol not an authentication protocol. With= the > exception of the client password credentials passed in the form-encoded > body, the protocol is completely authentication agnostic for both client > authentication and end-user login. Add to that the recent separation of t= he > token authentication schemes, and you get a clean and well defined > authorization model. > > > > A client using a token has to answer two questions: how to obtain > authorization and how to use the provided authorization to access the > protected resource. As currently specified, the header answers neither. I= n > addition, for this to be a challenge response protocol, the client respon= se > must match the challenge which is not possible if the response can use > different schemes based on the token type issued. That has proven very > confusing to people on this list. >=20 > I agree about the separation, but a better fix is to name the protocols t= hat > the client can use for each step as part of this header. In any case, 401 > responses are required (a MUST in 2616) to have a WWW-Authenticate > header with a scheme. Dropping the header is not a choice that the OAuth > draft or can/should make. Leaving the scheme name choice to each > implementation would be confusing to the community. It isn't that confusing. The 401 response will include the WWW-Authenticate= header of the scheme used with the token issued for that resource. Since c= lients never even look at the header today, they will not be confused by an= ything. Server developers might be, but it should be addressed by writing q= uality token type specifications with clear examples. =20 > > The only case a client is going to encounter the WWW-Authenticate heade= r > is when making an unauthenticated request (the three error codes provided > add little to no value on top of the existing HTTP status codes). The onl= y time > that will happen is when the client is unfamiliar with the server. In suc= h a > case, the protocol as specified provides no further steps. The resource s= erver > is saying 'I support OAuth2' but implicitly saying 'and good luck figurin= g out > what to do next'. For this to provide any actual interoperability at this= level, > the header must provide the supported profiles, endpoints, extensions, > scope, etc. None of that is currently available. >=20 > Actually, providing an HTML representation for 401 responses with "here i= s > how to can get started to supply an Authorization header to access this > resource" is a good step towards discoverability. I hope you are kidding... providing discovery in human-readable format help= s the client how? > > This means the header is defined solely as a potential future extension > point for discovery, which brings me back to the first issue. The WWW- > Authenticate header is not the right place to provide authorization serve= r > discovery information. I think our inability to fit 'realm' into our fram= ework > shows how the HTTP authentication headers are not meant for this. >=20 > Including identifiers (like media types, encoding names, or even auth > schems) as part of the protocol gives some indirection to their specifica= tions > elsewhere (though not perfect, such as an IANA registry). Can you give actual examples of how such responses help an OAuth *library* = accomplish any level of interoperability? EHL From subbu@subbu.org Wed Jan 19 00:13:15 2011 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 4C4343A6E80 for ; Wed, 19 Jan 2011 00:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vbb35CNKnf7M for ; Wed, 19 Jan 2011 00:13:14 -0800 (PST) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id CE9203A6D05 for ; Wed, 19 Jan 2011 00:13:13 -0800 (PST) Received: by qyj19 with SMTP id 19so591405qyj.10 for ; Wed, 19 Jan 2011 00:15:53 -0800 (PST) Received: by 10.224.29.8 with SMTP id o8mr432216qac.129.1295424953016; Wed, 19 Jan 2011 00:15:53 -0800 (PST) Received: from [172.16.1.110] ([209.118.182.87]) by mx.google.com with ESMTPS id l12sm4542719qcu.31.2011.01.19.00.15.50 (version=SSLv3 cipher=RC4-MD5); Wed, 19 Jan 2011 00:15:52 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Subbu Allamaraju In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61814@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 19 Jan 2011 00:15:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9530447D-0FB3-4586-AAF9-496A442F86F1@subbu.org> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61814@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 08:13:15 -0000 >> On Jan 18, 2011, at 11:13 PM, Eran Hammer-Lahav wrote: >>=20 >>> OAuth is an authorization protocol not an authentication protocol. = With the >> exception of the client password credentials passed in the = form-encoded >> body, the protocol is completely authentication agnostic for both = client >> authentication and end-user login. Add to that the recent separation = of the >> token authentication schemes, and you get a clean and well defined >> authorization model. >>>=20 >>> A client using a token has to answer two questions: how to obtain >> authorization and how to use the provided authorization to access the >> protected resource. As currently specified, the header answers = neither. In >> addition, for this to be a challenge response protocol, the client = response >> must match the challenge which is not possible if the response can = use >> different schemes based on the token type issued. That has proven = very >> confusing to people on this list. >>=20 >> I agree about the separation, but a better fix is to name the = protocols that >> the client can use for each step as part of this header. In any case, = 401 >> responses are required (a MUST in 2616) to have a WWW-Authenticate >> header with a scheme. Dropping the header is not a choice that the = OAuth >> draft or can/should make. Leaving the scheme name choice to each >> implementation would be confusing to the community. >=20 > It isn't that confusing. The 401 response will include the = WWW-Authenticate header of the scheme used with the token issued for = that resource. Since clients never even look at the header today, they = will not be confused by anything. Server developers might be, but it = should be addressed by writing quality token type specifications with = clear examples. Why would the client developer/admin not look at the scheme?=20 >>> The only case a client is going to encounter the WWW-Authenticate = header >> is when making an unauthenticated request (the three error codes = provided >> add little to no value on top of the existing HTTP status codes). The = only time >> that will happen is when the client is unfamiliar with the server. In = such a >> case, the protocol as specified provides no further steps. The = resource server >> is saying 'I support OAuth2' but implicitly saying 'and good luck = figuring out >> what to do next'. For this to provide any actual interoperability at = this level, >> the header must provide the supported profiles, endpoints, = extensions, >> scope, etc. None of that is currently available. >>=20 >> Actually, providing an HTML representation for 401 responses with = "here is >> how to can get started to supply an Authorization header to access = this >> resource" is a good step towards discoverability. >=20 > I hope you are kidding... providing discovery in human-readable format = helps the client how? Nope. There is value in providing dev/debug-level discovery info. Saying = nothing is worse. >>> This means the header is defined solely as a potential future = extension >> point for discovery, which brings me back to the first issue. The = WWW- >> Authenticate header is not the right place to provide authorization = server >> discovery information. I think our inability to fit 'realm' into our = framework >> shows how the HTTP authentication headers are not meant for this. >>=20 >> Including identifiers (like media types, encoding names, or even auth >> schems) as part of the protocol gives some indirection to their = specifications >> elsewhere (though not perfect, such as an IANA registry). >=20 > Can you give actual examples of how such responses help an OAuth = *library* accomplish any level of interoperability? By not having this header or header with some impl specific scheme? I'm = not sure how to answer this question since I can't guess all the = operating conditions of libraries, tools and intermediaries. If I were = to write an OAuth-capable proxy, this header would tell it how what code = to trigger in the case of auth failures (such as refreshing an access = token). Plenty of examples exist for naming things via headers in all = MIME-based protocols. I'm not seeing the value in making the OAuth over = HTTP more opaque. In any case, 401 responses MUST accompany a = WWW-Authenticate header. Subbu= From wmills@yahoo-inc.com Wed Jan 19 09:04:31 2011 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 2D5AA28C0E7 for ; Wed, 19 Jan 2011 09:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.535 X-Spam-Level: X-Spam-Status: No, score=-17.535 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RDNS_DOTCOM_HELO=0.001, 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 Q9v+DTaOjjP5 for ; Wed, 19 Jan 2011 09:04:23 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 0960228C104 for ; Wed, 19 Jan 2011 09:03:48 -0800 (PST) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id p0JH5x2v008004; Wed, 19 Jan 2011 09:05:59 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Wed, 19 Jan 2011 09:05:59 -0800 From: William Mills To: Eran Hammer-Lahav , OAuth WG Date: Wed, 19 Jan 2011 09:05:55 -0800 Thread-Topic: Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu0eqc8OI1TGx2yS4KwfqhDmZy6TQAZBo3QALCUkWAAFmnccA== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A3156258BF2726CSP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 17:04:31 -0000 --_000_FFDFD7371D517847AD71FBB08F9A3156258BF2726CSP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My initial implementation of a SASL mechanism is now published at https://g= ithub.com/sweetums/SASL-OAuth and it conforms to the discovery mechanism in= the draft spec for the mechanism. The code is pretty rough, and there's some major portability work to do as = well as the fact that there's no automake and such. Please feel free to cr= eate issues on github if you find things. -bill From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, January 18, 2011 10:22 PM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme Can you provide an example HTTP response header showing how you provide thi= s discovery information? It would be helpful to think about solutions. EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 18, 2011 8:44 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme As long as we can do the discovery in band and it doesn't require major dif= ferences in-band I'm OK. I spinning back up on the SASL mechanism (now tha= t I finally was allowed to opensource it), and my current in-band discovery= is pretty clean using WWW-Authenticate. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 14, 2011 10:32 PM To: OAuth WG Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme One of the main problems with OAuth in general has always been the unsanita= ry mix of authorization and authentication ("it's an authentication protoco= l... authorization protocol... authentication protocol" [1]). It has always= been a confusing mess. The work on 2.0 has provided a valuable abstraction= and separation of the two components, especially the recent document split= . In addition, the recent work on the bearer token document and the MAC tok= en type have raised issues about OAuth and its relationship with HTTP authe= ntication. I would like to suggest we drop the 'OAuth2' WWW-Authenticate header comple= tely from the specification for the following reasons: 1. Draft oauth-v2 is clearly not an authentication protocol. It *util= izes* client authentication. It offers one fully defined method for client = authentication (which is basically HTTP Basic+), provides a half-baked clie= nt assertion authentication hook, and leaves all end-user authentication ou= t of scope. 2. The WWW-Authenticate header has absolutely no value, interoperabil= ity-wise or otherwise. Discovery was rules to be beyond the scope of this s= pecification. Having a protected resource declare it supports authenticatio= n using some unspecified credentials obtained using some unspecified client= flow is confusing at best. In the future, an interoperable discovery mecha= nism will be needed to allow clients to interact with completely unknown pr= otected resources, but this has been consistently ruled to be premature sta= ndardization at this point. 3. OAuth is agnostic to token authentication, and we already have thr= ee discrete token type proposals - all with active deployment plans in the = coming months. Two of these methods have already defined a full HTTP authen= tication scheme (even if the bearer token specification has not yet been up= dated to change its scheme name). 4. HTTP *authentication* is not an appropriate facility to negotiate = *authorization*. OAuth authorization discovery can be added to HTTP authent= ication schemes as attributes, but makes no sense as a scheme of its own. T= he issues we are having with 'realm' is one of the examples showing that we= are abusing the header. 5. Again, as specified, it adds no value and I am not aware of any ex= isting OAuth 1.0a implementation making use of the response header for clie= nt interoperability (yes, many include it, but how many clients actually re= ly on it, and if they do, how?). For these reasons I would like to suggest we: 1. Drop the WWW-Authenticate header definition and OAuth2 scheme from= the specification, leaving it up to each token type to define its own auth= entication flow. In the future, a comprehensive discovery specification sho= uld define a new HTTP response header for providing discovery information. = I have suggested using Link: rel=3D'authorization' as a simple yet powerful= solution. 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' to m= ake it clear what this document is really about. Comments? Counter argument? EHL [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY --_000_FFDFD7371D517847AD71FBB08F9A3156258BF2726CSP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My initial implementatio= n of a SASL mechanism is now published at https://github.com/sweetums= /SASL-OAuth and it conforms to the discovery mechanism in the draft spec for the mechanism. 

 =

The code is pretty rough= , and there’s some major portability work to do as well as the fact that th= ere’s no automake and such.  Please feel free to create issues on github if you= find things.

 =

-bill<= /p>

 =

From: Eran Hammer-L= ahav [mailto:eran@hueniverse.com]
Sent: Tuesday, January 18, 2011 10:22 PM
To: William Mills; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

Can you provide an examp= le HTTP response header showing how you provide this discovery information? It woul= d be helpful to think about solutions.

 =

EHL

 =

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Tuesday, January 18, 2011 8:44 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

As long as we can do the discovery in band and it doesn’t require major differences in-band I&= #8217;m OK.  I spinning back up on the SASL mechanism (now that I finally was allowed to opensource it), and my current in-band discovery is pretty clean using WWW-Authenticate.

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:32 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme

 

One of the main problems with OAuth in general has alw= ays been the unsanitary mix of authorization and authentication (“it̵= 7;s an authentication protocol… authorization protocol… authentication= protocol” [1]). It has always been a confusing mess. The work on 2.0 has provided a valuabl= e abstraction and separation of the two components, especially the recent document split. In addition, the recent work on the bearer token document a= nd the MAC token type have raised issues about OAuth and its relationship with HTTP authentication.

 

I would like to suggest we drop the ‘OAuth2̵= 7; WWW-Authenticate header completely from the specification for the following reasons:

 

1.&n= bsp;      Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* client authentication. It offers one fully defined method for client authentication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all end-user authentication out of scope.

2.&n= bsp;      The WWW-Authenticate header has absolutely no value= , interoperability-wise or otherwise. Discovery was rules to be beyond the sc= ope of this specification. Having a protected resource declare it supports authentication using some unspecified credentials obtained using some unspe= cified client flow is confusing at best. In the future, an interoperable discovery mechanism will be needed to allow clients to interact with completely unkno= wn protected resources, but this has been consistently ruled to be premature standardization at this point.

3.&n= bsp;      OAuth is agnostic to token authentication, and we already have three discrete token type proposals – all with active de= ployment plans in the coming months. Two of these methods have already defined a ful= l HTTP authentication scheme (even if the bearer token specification has not = yet been updated to change its scheme name).

4.&n= bsp;      HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery= can be added to HTTP authentication schemes as attributes, but makes no sense a= s a scheme of its own. The issues we are having with ‘realm’ is one= of the examples showing that we are abusing the header.

5.&n= bsp;      Again, as specified, it adds no value and I am not aware of any existing OAuth 1.0a implementation making use of the response header for client interoperability (yes, many include it, but how many clie= nts actually rely on it, and if they do, how?).

 

For these reasons I would like to suggest we:

 

1.&n= bsp;      Drop the WWW-Authenticate header definition and OAu= th2 scheme from the specification, leaving it up to each token type to define i= ts own authentication flow. In the future, a comprehensive discovery specifica= tion should define a new HTTP response header for providing discovery informatio= n. I have suggested using Link: rel=3D’authorization’ as a simple ye= t powerful solution.

2.&n= bsp;      Rename the document to ‘The OAuth 2.0 Authori= zation Protocol’ to make it clear what this document is really about.

 

Comments? Counter argument?

 

EHL

 

[1] http://www.youtube.com/watch?v=3D0IBZocFkXGY

 

--_000_FFDFD7371D517847AD71FBB08F9A3156258BF2726CSP2EX07VS06ds_-- From eran@hueniverse.com Wed Jan 19 09:13:49 2011 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 76E8B3A717D for ; Wed, 19 Jan 2011 09:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, 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 8FNT-06iFUiM for ; Wed, 19 Jan 2011 09:13:41 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 0CF843A7152 for ; Wed, 19 Jan 2011 09:13:40 -0800 (PST) Received: (qmail 30257 invoked from network); 19 Jan 2011 17:16:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 17:15:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 19 Jan 2011 10:15:45 -0700 From: Eran Hammer-Lahav To: William Mills , OAuth WG Date: Wed, 19 Jan 2011 10:15:38 -0700 Thread-Topic: Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu0eqc8OI1TGx2yS4KwfqhDmZy6TQAZBo3QALCUkWAAFmnccAAAboIQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D618FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8D618FFP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 17:13:49 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D618FFP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You're going to make me do all the work... Where's the spec? EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, January 19, 2011 9:06 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme My initial implementation of a SASL mechanism is now published at https://g= ithub.com/sweetums/SASL-OAuth and it conforms to the discovery mechanism in= the draft spec for the mechanism. The code is pretty rough, and there's some major portability work to do as = well as the fact that there's no automake and such. Please feel free to cr= eate issues on github if you find things. -bill From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, January 18, 2011 10:22 PM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme Can you provide an example HTTP response header showing how you provide thi= s discovery information? It would be helpful to think about solutions. EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 18, 2011 8:44 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme As long as we can do the discovery in band and it doesn't require major dif= ferences in-band I'm OK. I spinning back up on the SASL mechanism (now tha= t I finally was allowed to opensource it), and my current in-band discovery= is pretty clean using WWW-Authenticate. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 14, 2011 10:32 PM To: OAuth WG Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme One of the main problems with OAuth in general has always been the unsanita= ry mix of authorization and authentication ("it's an authentication protoco= l... authorization protocol... authentication protocol" [1]). It has always= been a confusing mess. The work on 2.0 has provided a valuable abstraction= and separation of the two components, especially the recent document split= . In addition, the recent work on the bearer token document and the MAC tok= en type have raised issues about OAuth and its relationship with HTTP authe= ntication. I would like to suggest we drop the 'OAuth2' WWW-Authenticate header comple= tely from the specification for the following reasons: 1. Draft oauth-v2 is clearly not an authentication protocol. It *util= izes* client authentication. It offers one fully defined method for client = authentication (which is basically HTTP Basic+), provides a half-baked clie= nt assertion authentication hook, and leaves all end-user authentication ou= t of scope. 2. The WWW-Authenticate header has absolutely no value, interoperabil= ity-wise or otherwise. Discovery was rules to be beyond the scope of this s= pecification. Having a protected resource declare it supports authenticatio= n using some unspecified credentials obtained using some unspecified client= flow is confusing at best. In the future, an interoperable discovery mecha= nism will be needed to allow clients to interact with completely unknown pr= otected resources, but this has been consistently ruled to be premature sta= ndardization at this point. 3. OAuth is agnostic to token authentication, and we already have thr= ee discrete token type proposals - all with active deployment plans in the = coming months. Two of these methods have already defined a full HTTP authen= tication scheme (even if the bearer token specification has not yet been up= dated to change its scheme name). 4. HTTP *authentication* is not an appropriate facility to negotiate = *authorization*. OAuth authorization discovery can be added to HTTP authent= ication schemes as attributes, but makes no sense as a scheme of its own. T= he issues we are having with 'realm' is one of the examples showing that we= are abusing the header. 5. Again, as specified, it adds no value and I am not aware of any ex= isting OAuth 1.0a implementation making use of the response header for clie= nt interoperability (yes, many include it, but how many clients actually re= ly on it, and if they do, how?). For these reasons I would like to suggest we: 1. Drop the WWW-Authenticate header definition and OAuth2 scheme from= the specification, leaving it up to each token type to define its own auth= entication flow. In the future, a comprehensive discovery specification sho= uld define a new HTTP response header for providing discovery information. = I have suggested using Link: rel=3D'authorization' as a simple yet powerful= solution. 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' to m= ake it clear what this document is really about. Comments? Counter argument? EHL [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D618FFP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You’re going to make me do all the work…

 =

Where&#= 8217;s the spec?

 

EHL

 

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent:= Wednesday, January 19, 2011 9:06 AM
To: Eran Hammer-Lahav; O= Auth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

My initial implementati= on of a SASL mechanism is now published at https://github.com/sweetums/SASL-OAuth and it confor= ms to the discovery mechanism in the draft spec for the mechanism. 

 

= The code is pretty rough, and there’s some major portability work to = do as well as the fact that there’s no automake and such.  Pleas= e feel free to create issues on github if you find things.

 

-bill

 <= /o:p>

From: Eran Hammer-L= ahav [mailto:eran@hueniverse.com]
Sent: Tuesday, January 18, 201= 1 10:22 PM
To: William Mills; OAuth WG
Subject: RE: Rem= oval: 'OAuth2' HTTP Authentication Scheme

=

 

Can you provide an example HTTP response header showing = how you provide this discovery information? It would be helpful to think ab= out solutions.

 

EHL

 

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent:<= /b> Tuesday, January 18, 2011 8:44 AM
To: Eran Hammer-Lahav; OAut= h WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

 

As long as we can do the d= iscovery in band and it doesn’t require major differences in-band I&#= 8217;m OK.  I spinning back up on the SASL mechanism (now that I final= ly was allowed to opensource it), and my current in-band discovery is prett= y clean using WWW-Authenticate.

<= span style=3D'color:#1F497D'> 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ie= tf.org] On Behalf Of Eran Hammer-Lahav
Sent: Friday, Janua= ry 14, 2011 10:32 PM
To: OAuth WG
Subject: [OAUTH-WG] R= emoval: 'OAuth2' HTTP Authentication Scheme

 

One of the= main problems with OAuth in general has always been the unsanitary mix of = authorization and authentication (“it’s an authentication proto= col… authorization protocol… authentication protocol” [1]= ). It has always been a confusing mess. The work on 2.0 has provided a valu= able abstraction and separation of the two components, especially the recen= t document split. In addition, the recent work on the bearer token document= and the MAC token type have raised issues about OAuth and its relationship= with HTTP authentication.

 

I would like to suggest we drop the ‘OAu= th2’ WWW-Authenticate header completely from the specification for th= e following reasons:

 

1.       Draft oauth-v2 is clearly not an authentication protoco= l. It *utilizes* client authentication. It offers one fully defined = method for client authentication (which is basically HTTP Basic+), provides= a half-baked client assertion authentication hook, and leaves all end-user= authentication out of scope.

2.=        The WWW-Authen= ticate header has absolutely no value, interoperability-wise or otherwise. = Discovery was rules to be beyond the scope of this specification. Having a = protected resource declare it supports authentication using some unspecifie= d credentials obtained using some unspecified client flow is confusing at b= est. In the future, an interoperable discovery mechanism will be needed to = allow clients to interact with completely unknown protected resources, but = this has been consistently ruled to be premature standardization at this po= int.

3.    &= nbsp;  OAuth is agnostic to token authenticati= on, and we already have three discrete token type proposals – all wit= h active deployment plans in the coming months. Two of these methods have a= lready defined a full HTTP authentication scheme (even if the bearer token = specification has not yet been updated to change its scheme name).

4.       <= /span>HTTP *authentication* is not an appropriate f= acility to negotiate *authorization*. OAuth authorization discovery = can be added to HTTP authentication schemes as attributes, but makes no sen= se as a scheme of its own. The issues we are having with ‘realm’= ; is one of the examples showing that we are abusing the header.=

5.       Again, as specified, it adds no value and I am not awa= re of any existing OAuth 1.0a implementation making use of the response hea= der for client interoperability (yes, many include it, but how many clients= actually rely on it, and if they do, how?).

 

For these reasons I would li= ke to suggest we:

 

<= p class=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l1 level1 l= fo4'>1.       <= /span>Drop the WWW-Authenticate header definition and OAuth2 sche= me from the specification, leaving it up to each token type to define its o= wn authentication flow. In the future, a comprehensive discovery specificat= ion should define a new HTTP response header for providing discovery inform= ation. I have suggested using Link: rel=3D’authorization’ as a = simple yet powerful solution.

2.=        Rename the doc= ument to ‘The OAuth 2.0 Authorization Protocol’ to make it clea= r what this document is really about.

 

Comments? Counter argument?

 

EHL

 

[1] http://www.yo= utube.com/watch?v=3D0IBZocFkXGY

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D618FFP3PW5EX1MB01E_-- From wmills@yahoo-inc.com Wed Jan 19 09:36:59 2011 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 83A9428C100 for ; Wed, 19 Jan 2011 09:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.542 X-Spam-Level: X-Spam-Status: No, score=-17.542 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RDNS_DOTCOM_HELO=0.001, 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 bNFqNK1HKDE1 for ; Wed, 19 Jan 2011 09:36:50 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 8F38328C0F9 for ; Wed, 19 Jan 2011 09:36:50 -0800 (PST) Received: from SP2-EX07CAS03.ds.corp.yahoo.com (sp2-ex07cas03.corp.sp2.yahoo.com [98.137.59.35]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0JHcr68015705; Wed, 19 Jan 2011 09:38:53 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS03.ds.corp.yahoo.com ([98.137.59.35]) with mapi; Wed, 19 Jan 2011 09:38:53 -0800 From: William Mills To: Eran Hammer-Lahav , OAuth WG Date: Wed, 19 Jan 2011 09:38:52 -0800 Thread-Topic: Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu0eqc8OI1TGx2yS4KwfqhDmZy6TQAZBo3QALCUkWAAFmnccAAAboIQAADK6RA= Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D618FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D618FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A3156258BF27285SP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 17:36:59 -0000 --_000_FFDFD7371D517847AD71FBB08F9A3156258BF27285SP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-00.txt From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, January 19, 2011 9:16 AM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme You're going to make me do all the work... Where's the spec? EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, January 19, 2011 9:06 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme My initial implementation of a SASL mechanism is now published at https://g= ithub.com/sweetums/SASL-OAuth and it conforms to the discovery mechanism in= the draft spec for the mechanism. The code is pretty rough, and there's some major portability work to do as = well as the fact that there's no automake and such. Please feel free to cr= eate issues on github if you find things. -bill From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, January 18, 2011 10:22 PM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme Can you provide an example HTTP response header showing how you provide thi= s discovery information? It would be helpful to think about solutions. EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 18, 2011 8:44 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme As long as we can do the discovery in band and it doesn't require major dif= ferences in-band I'm OK. I spinning back up on the SASL mechanism (now tha= t I finally was allowed to opensource it), and my current in-band discovery= is pretty clean using WWW-Authenticate. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 14, 2011 10:32 PM To: OAuth WG Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme One of the main problems with OAuth in general has always been the unsanita= ry mix of authorization and authentication ("it's an authentication protoco= l... authorization protocol... authentication protocol" [1]). It has always= been a confusing mess. The work on 2.0 has provided a valuable abstraction= and separation of the two components, especially the recent document split= . In addition, the recent work on the bearer token document and the MAC tok= en type have raised issues about OAuth and its relationship with HTTP authe= ntication. I would like to suggest we drop the 'OAuth2' WWW-Authenticate header comple= tely from the specification for the following reasons: 1. Draft oauth-v2 is clearly not an authentication protocol. It *util= izes* client authentication. It offers one fully defined method for client = authentication (which is basically HTTP Basic+), provides a half-baked clie= nt assertion authentication hook, and leaves all end-user authentication ou= t of scope. 2. The WWW-Authenticate header has absolutely no value, interoperabil= ity-wise or otherwise. Discovery was rules to be beyond the scope of this s= pecification. Having a protected resource declare it supports authenticatio= n using some unspecified credentials obtained using some unspecified client= flow is confusing at best. In the future, an interoperable discovery mecha= nism will be needed to allow clients to interact with completely unknown pr= otected resources, but this has been consistently ruled to be premature sta= ndardization at this point. 3. OAuth is agnostic to token authentication, and we already have thr= ee discrete token type proposals - all with active deployment plans in the = coming months. Two of these methods have already defined a full HTTP authen= tication scheme (even if the bearer token specification has not yet been up= dated to change its scheme name). 4. HTTP *authentication* is not an appropriate facility to negotiate = *authorization*. OAuth authorization discovery can be added to HTTP authent= ication schemes as attributes, but makes no sense as a scheme of its own. T= he issues we are having with 'realm' is one of the examples showing that we= are abusing the header. 5. Again, as specified, it adds no value and I am not aware of any ex= isting OAuth 1.0a implementation making use of the response header for clie= nt interoperability (yes, many include it, but how many clients actually re= ly on it, and if they do, how?). For these reasons I would like to suggest we: 1. Drop the WWW-Authenticate header definition and OAuth2 scheme from= the specification, leaving it up to each token type to define its own auth= entication flow. In the future, a comprehensive discovery specification sho= uld define a new HTTP response header for providing discovery information. = I have suggested using Link: rel=3D'authorization' as a simple yet powerful= solution. 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' to m= ake it clear what this document is really about. Comments? Counter argument? EHL [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY --_000_FFDFD7371D517847AD71FBB08F9A3156258BF27285SP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-00= .txt

 =

From: Eran Hammer-L= ahav [mailto:eran@hueniverse.com]
Sent: Wednesday, January 19, 2011 9:16 AM
To: William Mills; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

You’re going to ma= ke me do all the work…

 =

Where’s the spec?<= o:p>

 =

EHL

 =

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Wednesday, January 19, 2011 9:06 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

My initial implementatio= n of a SASL mechanism is now published at https://github.com/sweetums= /SASL-OAuth and it conforms to the discovery mechanism in the draft spec for the mechanism. 

 =

The code is pretty rough= , and there’s some major portability work to do as well as the fact that th= ere’s no automake and such.  Please feel free to create issues on github if you find things.

 =

-bill<= /p>

 =

From: Eran Hammer-L= ahav [mailto:eran@hueniverse.com]
Sent: Tuesday, January 18, 2011 10:22 PM
To: William Mills; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

Can you provide an examp= le HTTP response header showing how you provide this discovery information? It woul= d be helpful to think about solutions.

 =

EHL

 =

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Tuesday, January 18, 2011 8:44 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

As long as we can do the discovery in band and it doesn’t require major differences in-band I&= #8217;m OK.  I spinning back up on the SASL mechanism (now that I finally was allowed to opensource it), and my current in-band discovery is pretty clean using WWW-Authenticate.

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:32 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme

 

One of the main problems with OAuth in general has alw= ays been the unsanitary mix of authorization and authentication (“it̵= 7;s an authentication protocol… authorization protocol… authentication= protocol” [1]). It has always been a confusing mess. The work on 2.0 has provided a valuabl= e abstraction and separation of the two components, especially the recent document split. In addition, the recent work on the bearer token document a= nd the MAC token type have raised issues about OAuth and its relationship with= HTTP authentication.

 

I would like to suggest we drop the ‘OAuth2̵= 7; WWW-Authenticate header completely from the specification for the following reasons:

 

1.&n= bsp;      Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* client authentication. It offers one fully defined method for client authentication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all end-user authentication out of scope.

2.&n= bsp;      The WWW-Authenticate header has absolutely no value= , interoperability-wise or otherwise. Discovery was rules to be beyond the sc= ope of this specification. Having a protected resource declare it supports authentication using some unspecified credentials obtained using some unspecified client flow is confusing at best. In the future, an interoperab= le discovery mechanism will be needed to allow clients to interact with comple= tely unknown protected resources, but this has been consistently ruled to be premature standardization at this point.

3.&n= bsp;      OAuth is agnostic to token authentication, and we already have three discrete token type proposals – all with active de= ployment plans in the coming months. Two of these methods have already defined a ful= l HTTP authentication scheme (even if the bearer token specification has not = yet been updated to change its scheme name).

4.&n= bsp;      HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery= can be added to HTTP authentication schemes as attributes, but makes no sense a= s a scheme of its own. The issues we are having with ‘realm’ is one= of the examples showing that we are abusing the header.

5.&n= bsp;      Again, as specified, it adds no value and I am not aware of any existing OAuth 1.0a implementation making use of the response header for client interoperability (yes, many include it, but how many clie= nts actually rely on it, and if they do, how?).

 

For these reasons I would like to suggest we:

 

1.&n= bsp;      Drop the WWW-Authenticate header definition and OAu= th2 scheme from the specification, leaving it up to each token type to define i= ts own authentication flow. In the future, a comprehensive discovery specifica= tion should define a new HTTP response header for providing discovery informatio= n. I have suggested using Link: rel=3D’authorization’ as a simple ye= t powerful solution.

2.&n= bsp;      Rename the document to ‘The OAuth 2.0 Authori= zation Protocol’ to make it clear what this document is really about.

 

Comments? Counter argument?

 

EHL

 

[1] http://www.youtube.com/watch?v=3D0IBZocFkXGY

 

--_000_FFDFD7371D517847AD71FBB08F9A3156258BF27285SP2EX07VS06ds_-- From eran@hueniverse.com Wed Jan 19 09:44:09 2011 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 C23383A702C for ; Wed, 19 Jan 2011 09:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, 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 rhxcHlRt3KMM for ; Wed, 19 Jan 2011 09:44:01 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9B12E28C10C for ; Wed, 19 Jan 2011 09:44:00 -0800 (PST) Received: (qmail 26157 invoked from network); 19 Jan 2011 17:45:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 19 Jan 2011 17:45:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 19 Jan 2011 10:45:51 -0700 From: Eran Hammer-Lahav To: William Mills , OAuth WG Date: Wed, 19 Jan 2011 10:45:44 -0700 Thread-Topic: Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu0eqc8OI1TGx2yS4KwfqhDmZy6TQAZBo3QALCUkWAAFmnccAAAboIQAADK6RAAAD45gA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6191F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D618FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6191FP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 17:44:09 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6191FP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks. Seems like this draft is based on an old version of the v2 specification. S= tuff like signature and endpoint location is long gone... EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, January 19, 2011 9:39 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-00.txt From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, January 19, 2011 9:16 AM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme You're going to make me do all the work... Where's the spec? EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, January 19, 2011 9:06 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme My initial implementation of a SASL mechanism is now published at https://g= ithub.com/sweetums/SASL-OAuth and it conforms to the discovery mechanism in= the draft spec for the mechanism. The code is pretty rough, and there's some major portability work to do as = well as the fact that there's no automake and such. Please feel free to cr= eate issues on github if you find things. -bill From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, January 18, 2011 10:22 PM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme Can you provide an example HTTP response header showing how you provide thi= s discovery information? It would be helpful to think about solutions. EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 18, 2011 8:44 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme As long as we can do the discovery in band and it doesn't require major dif= ferences in-band I'm OK. I spinning back up on the SASL mechanism (now tha= t I finally was allowed to opensource it), and my current in-band discovery= is pretty clean using WWW-Authenticate. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 14, 2011 10:32 PM To: OAuth WG Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme One of the main problems with OAuth in general has always been the unsanita= ry mix of authorization and authentication ("it's an authentication protoco= l... authorization protocol... authentication protocol" [1]). It has always= been a confusing mess. The work on 2.0 has provided a valuable abstraction= and separation of the two components, especially the recent document split= . In addition, the recent work on the bearer token document and the MAC tok= en type have raised issues about OAuth and its relationship with HTTP authe= ntication. I would like to suggest we drop the 'OAuth2' WWW-Authenticate header comple= tely from the specification for the following reasons: 1. Draft oauth-v2 is clearly not an authentication protocol. It *util= izes* client authentication. It offers one fully defined method for client = authentication (which is basically HTTP Basic+), provides a half-baked clie= nt assertion authentication hook, and leaves all end-user authentication ou= t of scope. 2. The WWW-Authenticate header has absolutely no value, interoperabil= ity-wise or otherwise. Discovery was rules to be beyond the scope of this s= pecification. Having a protected resource declare it supports authenticatio= n using some unspecified credentials obtained using some unspecified client= flow is confusing at best. In the future, an interoperable discovery mecha= nism will be needed to allow clients to interact with completely unknown pr= otected resources, but this has been consistently ruled to be premature sta= ndardization at this point. 3. OAuth is agnostic to token authentication, and we already have thr= ee discrete token type proposals - all with active deployment plans in the = coming months. Two of these methods have already defined a full HTTP authen= tication scheme (even if the bearer token specification has not yet been up= dated to change its scheme name). 4. HTTP *authentication* is not an appropriate facility to negotiate = *authorization*. OAuth authorization discovery can be added to HTTP authent= ication schemes as attributes, but makes no sense as a scheme of its own. T= he issues we are having with 'realm' is one of the examples showing that we= are abusing the header. 5. Again, as specified, it adds no value and I am not aware of any ex= isting OAuth 1.0a implementation making use of the response header for clie= nt interoperability (yes, many include it, but how many clients actually re= ly on it, and if they do, how?). For these reasons I would like to suggest we: 1. Drop the WWW-Authenticate header definition and OAuth2 scheme from= the specification, leaving it up to each token type to define its own auth= entication flow. In the future, a comprehensive discovery specification sho= uld define a new HTTP response header for providing discovery information. = I have suggested using Link: rel=3D'authorization' as a simple yet powerful= solution. 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' to m= ake it clear what this document is really about. Comments? Counter argument? EHL [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6191FP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks.

 

Seems like this draft is based on an old version of = the v2 specification. Stuff like signature and endpoint location is long go= ne…

 

EHL

 

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Wed= nesday, January 19, 2011 9:39 AM
To: Eran Hammer-Lahav; OAuth WG<= br>Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

 

http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-0= 0.txt

 

Fro= m: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent: Wedne= sday, January 19, 2011 9:16 AM
To: William Mills; OAuth WG
= Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

 

You’re going to make me do all = the work…

 

Where’s the spec?

 

EHL

 

From: William Mills [mailto:wmills@ya= hoo-inc.com]
Sent: Wednesday, January 19, 2011 9:06 AM
To:= Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' H= TTP Authentication Scheme

 

My initial implementation of a SASL mechanism is now published at https://github.com/sweetums/SAS= L-OAuth and it conforms to the discovery mechanism in the draft spec fo= r the mechanism. 

 

The code is pretty rough, and there’s some m= ajor portability work to do as well as the fact that there’s no autom= ake and such.  Please feel free to create issues on github if you find= things.

 

-bill

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent:= Tuesday, January 18, 2011 10:22 PM
To: William Mills; OAuth WGSubject: RE: Removal: 'OAuth2' HTTP Authentication Scheme

 

Can you provide an example HTTP = response header showing how you provide this discovery information? It woul= d be helpful to think about solutions.

 

EHL

 

From: William Mills [mailto:wmills@yaho= o-inc.com]
Sent: Tuesday, January 18, 2011 8:44 AM
To:= Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP = Authentication Scheme

 

As= long as we can do the discovery in band and it doesn’t require major= differences in-band I’m OK.  I spinning back up on the SASL mec= hanism (now that I finally was allowed to opensource it), and my current in= -band discovery is pretty clean using WWW-Authenticate.

 

From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:32 PM
To: OAuth WG
S= ubject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme

 

One of the main problems with OAuth in general has always bee= n the unsanitary mix of authorization and authentication (“it’s= an authentication protocol… authorization protocol… authentica= tion protocol” [1]). It has always been a confusing mess. The work on= 2.0 has provided a valuable abstraction and separation of the two componen= ts, especially the recent document split. In addition, the recent work on t= he bearer token document and the MAC token type have raised issues about OA= uth and its relationship with HTTP authentication.

 

I would like to sugg= est we drop the ‘OAuth2’ WWW-Authenticate header completely fro= m the specification for the following reasons:

 

1.  &nbs= p;    Draft oauth-v2 is clearly not = an authentication protocol. It *utilizes* client authentication. It = offers one fully defined method for client authentication (which is basical= ly HTTP Basic+), provides a half-baked client assertion authentication hook= , and leaves all end-user authentication out of scope.

= 2.       The WWW-Authenticate header has absolutely no value, interoperab= ility-wise or otherwise. Discovery was rules to be beyond the scope of this= specification. Having a protected resource declare it supports authenticat= ion using some unspecified credentials obtained using some unspecified clie= nt flow is confusing at best. In the future, an interoperable discovery mec= hanism will be needed to allow clients to interact with completely unknown = protected resources, but this has been consistently ruled to be premature s= tandardization at this point.

3.=        OAuth is agnos= tic to token authentication, and we already have three discrete token type = proposals – all with active deployment plans in the coming months. Tw= o of these methods have already defined a full HTTP authentication scheme (= even if the bearer token specification has not yet been updated to change i= ts scheme name).

4.  &= nbsp;    HTTP *authentication= * is not an appropriate facility to negotiate *authorization*. OAuth= authorization discovery can be added to HTTP authentication schemes as att= ributes, but makes no sense as a scheme of its own. The issues we are havin= g with ‘realm’ is one of the examples showing that we are abusi= ng the header.

5.  &nb= sp;    Again, as specified, it adds = no value and I am not aware of any existing OAuth 1.0a implementation makin= g use of the response header for client interoperability (yes, many include= it, but how many clients actually rely on it, and if they do, how?).<= /o:p>

 

For= these reasons I would like to suggest we:

 

1.   &n= bsp;   Drop the WWW-Authenticate header d= efinition and OAuth2 scheme from the specification, leaving it up to each t= oken type to define its own authentication flow. In the future, a comprehen= sive discovery specification should define a new HTTP response header for p= roviding discovery information. I have suggested using Link: rel=3D’a= uthorization’ as a simple yet powerful solution.

= 2.       Rename the document to ‘The OAuth 2.0 Authorization Protoc= ol’ to make it clear what this document is really about.

 

Comments? = Counter argument?

 

<= p class=3DMsoNormal>EHL

 

[1] http://www.youtube.com/watch?v=3D0IBZocFkXGY

=

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6191FP3PW5EX1MB01E_-- From wmills@yahoo-inc.com Wed Jan 19 09:48:59 2011 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 63A103A702F for ; Wed, 19 Jan 2011 09:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.547 X-Spam-Level: X-Spam-Status: No, score=-17.547 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RDNS_DOTCOM_HELO=0.001, 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 qThmsjzc7-X4 for ; Wed, 19 Jan 2011 09:48:50 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 0538028C126 for ; Wed, 19 Jan 2011 09:48:41 -0800 (PST) Received: from SP2-EX07CAS01.ds.corp.yahoo.com (sp2-ex07cas01.corp.sp2.yahoo.com [98.137.59.37]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id p0JHoqdG022161; Wed, 19 Jan 2011 09:50:52 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS01.ds.corp.yahoo.com ([98.137.59.37]) with mapi; Wed, 19 Jan 2011 09:50:52 -0800 From: William Mills To: Eran Hammer-Lahav , OAuth WG Date: Wed, 19 Jan 2011 09:50:51 -0800 Thread-Topic: Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu0eqc8OI1TGx2yS4KwfqhDmZy6TQAZBo3QALCUkWAAFmnccAAAboIQAADK6RAAAD45gAAAHQjQ Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D618FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D6191F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6191F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A3156258BF27292SP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 17:48:59 -0000 --_000_FFDFD7371D517847AD71FBB08F9A3156258BF27292SP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes it's old, 1 week form expiring too. The specs seem to be stabilizing n= ow so it's worth updating. Has there been any other discovery proposal ye= t? From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, January 19, 2011 9:46 AM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme Thanks. Seems like this draft is based on an old version of the v2 specification. S= tuff like signature and endpoint location is long gone... EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, January 19, 2011 9:39 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-00.txt From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Wednesday, January 19, 2011 9:16 AM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme You're going to make me do all the work... Where's the spec? EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Wednesday, January 19, 2011 9:06 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme My initial implementation of a SASL mechanism is now published at https://g= ithub.com/sweetums/SASL-OAuth and it conforms to the discovery mechanism in= the draft spec for the mechanism. The code is pretty rough, and there's some major portability work to do as = well as the fact that there's no automake and such. Please feel free to cr= eate issues on github if you find things. -bill From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, January 18, 2011 10:22 PM To: William Mills; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme Can you provide an example HTTP response header showing how you provide thi= s discovery information? It would be helpful to think about solutions. EHL From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Tuesday, January 18, 2011 8:44 AM To: Eran Hammer-Lahav; OAuth WG Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme As long as we can do the discovery in band and it doesn't require major dif= ferences in-band I'm OK. I spinning back up on the SASL mechanism (now tha= t I finally was allowed to opensource it), and my current in-band discovery= is pretty clean using WWW-Authenticate. From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 14, 2011 10:32 PM To: OAuth WG Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme One of the main problems with OAuth in general has always been the unsanita= ry mix of authorization and authentication ("it's an authentication protoco= l... authorization protocol... authentication protocol" [1]). It has always= been a confusing mess. The work on 2.0 has provided a valuable abstraction= and separation of the two components, especially the recent document split= . In addition, the recent work on the bearer token document and the MAC tok= en type have raised issues about OAuth and its relationship with HTTP authe= ntication. I would like to suggest we drop the 'OAuth2' WWW-Authenticate header comple= tely from the specification for the following reasons: 1. Draft oauth-v2 is clearly not an authentication protocol. It *util= izes* client authentication. It offers one fully defined method for client = authentication (which is basically HTTP Basic+), provides a half-baked clie= nt assertion authentication hook, and leaves all end-user authentication ou= t of scope. 2. The WWW-Authenticate header has absolutely no value, interoperabil= ity-wise or otherwise. Discovery was rules to be beyond the scope of this s= pecification. Having a protected resource declare it supports authenticatio= n using some unspecified credentials obtained using some unspecified client= flow is confusing at best. In the future, an interoperable discovery mecha= nism will be needed to allow clients to interact with completely unknown pr= otected resources, but this has been consistently ruled to be premature sta= ndardization at this point. 3. OAuth is agnostic to token authentication, and we already have thr= ee discrete token type proposals - all with active deployment plans in the = coming months. Two of these methods have already defined a full HTTP authen= tication scheme (even if the bearer token specification has not yet been up= dated to change its scheme name). 4. HTTP *authentication* is not an appropriate facility to negotiate = *authorization*. OAuth authorization discovery can be added to HTTP authent= ication schemes as attributes, but makes no sense as a scheme of its own. T= he issues we are having with 'realm' is one of the examples showing that we= are abusing the header. 5. Again, as specified, it adds no value and I am not aware of any ex= isting OAuth 1.0a implementation making use of the response header for clie= nt interoperability (yes, many include it, but how many clients actually re= ly on it, and if they do, how?). For these reasons I would like to suggest we: 1. Drop the WWW-Authenticate header definition and OAuth2 scheme from= the specification, leaving it up to each token type to define its own auth= entication flow. In the future, a comprehensive discovery specification sho= uld define a new HTTP response header for providing discovery information. = I have suggested using Link: rel=3D'authorization' as a simple yet powerful= solution. 2. Rename the document to 'The OAuth 2.0 Authorization Protocol' to m= ake it clear what this document is really about. Comments? Counter argument? EHL [1] http://www.youtube.com/watch?v=3D0IBZocFkXGY --_000_FFDFD7371D517847AD71FBB08F9A3156258BF27292SP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes it’s old, 1 we= ek form expiring too.  The specs seem to be stabilizing now so it’s worth updatin= g.   Has there been any other discovery proposal yet?

 =

From: Eran Hammer-L= ahav [mailto:eran@hueniverse.com]
Sent: Wednesday, January 19, 2011 9:46 AM
To: William Mills; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

Thanks.

 =

Seems like this draft is= based on an old version of the v2 specification. Stuff like signature and endpoin= t location is long gone…

 =

EHL

 =

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Wednesday, January 19, 2011 9:39 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

http://www.ietf.org/internet-drafts/draft-mills-kitten-sasl-oauth-00= .txt

 =

From: Eran Hammer-L= ahav [mailto:eran@hueniverse.com]
Sent: Wednesday, January 19, 2011 9:16 AM
To: William Mills; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

You’re going to ma= ke me do all the work…

 =

Where’s the spec?<= o:p>

 =

EHL

 =

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Wednesday, January 19, 2011 9:06 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

My initial implementatio= n of a SASL mechanism is now published at https://github.com/sweetums= /SASL-OAuth and it conforms to the discovery mechanism in the draft spec for the mechanism. 

 =

The code is pretty rough= , and there’s some major portability work to do as well as the fact that th= ere’s no automake and such.  Please feel free to create issues on github if you find things.

 =

-bill<= /p>

 =

From: Eran Hammer-L= ahav [mailto:eran@hueniverse.com]
Sent: Tuesday, January 18, 2011 10:22 PM
To: William Mills; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

Can you provide an examp= le HTTP response header showing how you provide this discovery information? It woul= d be helpful to think about solutions.

 =

EHL

 =

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Tuesday, January 18, 2011 8:44 AM
To: Eran Hammer-Lahav; OAuth WG
Subject: RE: Removal: 'OAuth2' HTTP Authentication Scheme=

 

As long as we can do the discovery in band and it doesn’t require major differences in-band I&= #8217;m OK.  I spinning back up on the SASL mechanism (now that I finally was allowed to opensource it), and my current in-band discovery is pretty clean using WWW-Authenticate.

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:32 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme

 

One of the main problems with OAuth in general has alw= ays been the unsanitary mix of authorization and authentication (“it̵= 7;s an authentication protocol… authorization protocol… authentication= protocol” [1]). It has always been a confusing mess. The work on 2.0 has provided a valuabl= e abstraction and separation of the two components, especially the recent document split. In addition, the recent work on the bearer token document a= nd the MAC token type have raised issues about OAuth and its relationship with HTTP authentication.

 

I would like to suggest we drop the ‘OAuth2̵= 7; WWW-Authenticate header completely from the specification for the following reasons:

 

1.&n= bsp;      Draft oauth-v2 is clearly not an authentication protocol. It *utilizes* client authentication. It offers one fully defined method for client authentication (which is basically HTTP Basic+), provides a half-baked client assertion authentication hook, and leaves all end-user authentication out of scope.

2.&n= bsp;      The WWW-Authenticate header has absolutely no value= , interoperability-wise or otherwise. Discovery was rules to be beyond the sc= ope of this specification. Having a protected resource declare it supports authentication using some unspecified credentials obtained using some unspecified client flow is confusing at best. In the future, an interoperab= le discovery mechanism will be needed to allow clients to interact with comple= tely unknown protected resources, but this has been consistently ruled to be premature standardization at this point.

3.&n= bsp;      OAuth is agnostic to token authentication, and we already have three discrete token type proposals – all with active de= ployment plans in the coming months. Two of these methods have already defined a ful= l HTTP authentication scheme (even if the bearer token specification has not = yet been updated to change its scheme name).

4.&n= bsp;      HTTP *authentication* is not an appropriate facility to negotiate *authorization*. OAuth authorization discovery= can be added to HTTP authentication schemes as attributes, but makes no sense a= s a scheme of its own. The issues we are having with ‘realm’ is one= of the examples showing that we are abusing the header.

5.&n= bsp;      Again, as specified, it adds no value and I am not aware of any existing OAuth 1.0a implementation making use of the response header for client interoperability (yes, many include it, but how many clie= nts actually rely on it, and if they do, how?).

 

For these reasons I would like to suggest we:

 

1.&n= bsp;      Drop the WWW-Authenticate header definition and OAu= th2 scheme from the specification, leaving it up to each token type to define i= ts own authentication flow. In the future, a comprehensive discovery specifica= tion should define a new HTTP response header for providing discovery informatio= n. I have suggested using Link: rel=3D’authorization’ as a simple ye= t powerful solution.

2.&n= bsp;      Rename the document to ‘The OAuth 2.0 Authori= zation Protocol’ to make it clear what this document is really about.

 

Comments? Counter argument?

 

EHL

 

[1] http://www.youtube.com/watch?v=3D0IBZocFkXGY

 

--_000_FFDFD7371D517847AD71FBB08F9A3156258BF27292SP2EX07VS06ds_-- From mscurtescu@google.com Wed Jan 19 10:02:33 2011 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 56EB728C122 for ; Wed, 19 Jan 2011 10:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.741 X-Spam-Level: X-Spam-Status: No, score=-105.741 tagged_above=-999 required=5 tests=[AWL=0.236, 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 RJ0hlwDQ0iwC for ; Wed, 19 Jan 2011 10:02:32 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 70A7C28C0EB for ; Wed, 19 Jan 2011 10:02:32 -0800 (PST) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p0JI5CHk030877 for ; Wed, 19 Jan 2011 10:05:12 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295460312; bh=PYnu7bDPU/C0DjuCeS7yWTqfaFs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=KpWKC8nJE0F3L05/ialGyag+h/UQutyNi7apE8YvfI9LnlT2B2ERd/wLQ8EWRJcYm jdQzvD+ZR7BbCE6kAgq+Q== Received: from ywi6 (ywi6.prod.google.com [10.192.9.6]) by hpaq14.eem.corp.google.com with ESMTP id p0JI3tOg009838 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 19 Jan 2011 10:05:11 -0800 Received: by ywi6 with SMTP id 6so432843ywi.6 for ; Wed, 19 Jan 2011 10:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=iiJldrwii8nBk9Dp8eG7UWsFG9QbJYwc/TYC7K1meXg=; b=VYntzpp/fCvhw6p3cjt+MTn3D/LjNiyq8GisieeZsHqsYFHz18mcbqYoKRXplcwQCK 6jxgb81ufw/DaKRowX+A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=J5tDE8+d6qrAe+SWJuAFYHuY/JEfv/B++Kvf7JBZNgb4dl772aFSm+Uj9hmz2lbfrU RKS4uWF4NkLPkRJ2opTQ== Received: by 10.101.204.28 with SMTP id g28mr704498anq.217.1295459962572; Wed, 19 Jan 2011 09:59:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Wed, 19 Jan 2011 09:59:02 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D618FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D6191F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 19 Jan 2011 09:59:02 -0800 Message-ID: To: William Mills Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 19 Jan 2011 18:02:33 -0000 On Wed, Jan 19, 2011 at 9:50 AM, William Mills wrote= : > Yes it=92s old, 1 week form expiring too.=A0 The specs seem to be stabili= zing > now so it=92s worth updating.=A0 =A0Has there been any other discovery pr= oposal > yet? Nothing concrete AFAIK, but for SASL we also discussed using host-meta style discovery. Somehow this approach seemed cleaner to me, but of course it needs work (to define file location/format/content). Marius From Michael.Jones@microsoft.com Wed Jan 19 10:08:19 2011 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 8740028C127 for ; Wed, 19 Jan 2011 10:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.587 X-Spam-Level: X-Spam-Status: No, score=-10.587 tagged_above=-999 required=5 tests=[AWL=0.011, 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 enyQRQHLdLwz for ; Wed, 19 Jan 2011 10:08:16 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id DAF4528C133 for ; Wed, 19 Jan 2011 10:08:15 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 19 Jan 2011 10:10:56 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Wed, 19 Jan 2011 10:10:56 -0800 From: Mike Jones To: OAuth WG Thread-Topic: Bear token scheme name Thread-Index: Acu3pr1t3syl2UOrRViF4qH3Mgl/vQAXVc0Q Date: Wed, 19 Jan 2011 18:10:55 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246EF805TK5EX14MBXC202r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Bear token scheme name 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, 19 Jan 2011 18:08:19 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246EF805TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like a sense from the working group whether others want this change, an= d if so, what the name should be changed to. Thanks, -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Tuesday, January 18, 2011 11:06 PM To: Mike Jones Cc: OAuth WG Subject: Bear token scheme name Please change the draft to use a different scheme name than 'OAuth2' for th= e bearer token authentication scheme. Given the unstable state of the heade= r (still is), it is perfectly fine to make this change. The list includes a= detailed discussion about this. I am strongly opposed to giving the bearer= token scheme a name giving it the appearance of the preferred or canonical= token authentication method. I don't care what you change it to as long as= it is not 'OAuth2' or 'OAuth'. EHL --_000_4E1F6AAD24975D4BA5B1680429673943246EF805TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like a sense= from the working group whether others want this change, and if so, what th= e name should be changed to.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Thanks,

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Tuesday, January 18, 2011 11:06 PM
To: Mike Jones
Cc: OAuth WG
Subject: Bear token scheme name

 

Please change the draft to use a different scheme na= me than ‘OAuth2’ for the bearer token authentication scheme. Gi= ven the unstable state of the header (still is), it is perfectly fine to ma= ke this change. The list includes a detailed discussion about this. I am strongly opposed to giving the bearer token scheme a name= giving it the appearance of the preferred or canonical token authenticatio= n method. I don’t care what you change it to as long as it is not = 216;OAuth2’ or ‘OAuth’.

 

EHL

--_000_4E1F6AAD24975D4BA5B1680429673943246EF805TK5EX14MBXC202r_-- From beaton@google.com Wed Jan 19 17:47:56 2011 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 7461B28C123 for ; Wed, 19 Jan 2011 17:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro0TUpdEj5Zo for ; Wed, 19 Jan 2011 17:47:54 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 9069228C0FA for ; Wed, 19 Jan 2011 17:47:53 -0800 (PST) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p0K1oX7u009308 for ; Wed, 19 Jan 2011 17:50:34 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295488234; bh=S7weQm5wYj0uieW9T5pFXqL6jvc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=KFN1SQJ7bNM0oBqheHuuUO2NllScRqeFShKj6AmnGydcJ3y7UwzkINCu8FzhreqO5 c3BSIKLkSe1QqptXfUCmQ== Received: from pwj9 (pwj9.prod.google.com [10.241.219.73]) by kpbe17.cbf.corp.google.com with ESMTP id p0K1oTGa016562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 19 Jan 2011 17:50:32 -0800 Received: by pwj9 with SMTP id 9so20467pwj.21 for ; Wed, 19 Jan 2011 17:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i/oZeuxUzkQ4/WWkOhw1JOdSY+LP/gAErOOdqf5k/DM=; b=vQp1tE1L2n2sp0vXJLP4WmoEsXchG0ImFmnG+0CAv7reEh+fq3oQPAYP7kxcxAbYr2 dahVdPpTb0AYoaArJYKw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EBmN8h9NBfkKLMXsT+dMgonZXCswK6C0EGsLCrwhc1ERN+swaRYZpVj64Za1R5c2Aj yDPZ+SUe0bbV55Kkc++A== MIME-Version: 1.0 Received: by 10.142.155.10 with SMTP id c10mr1497451wfe.283.1295488232220; Wed, 19 Jan 2011 17:50:32 -0800 (PST) Received: by 10.142.213.7 with HTTP; Wed, 19 Jan 2011 17:50:31 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 19 Jan 2011 17:50:31 -0800 Message-ID: From: Brian Eaton 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] Proposal to drop/relocate response_type=code_and_token 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, 20 Jan 2011 01:47:56 -0000 On Tue, Jan 11, 2011 at 4:40 PM, Brian Eaton wrote: > On Tue, Jan 11, 2011 at 1:21 PM, Eran Hammer-Lahav = wrote: >> But that's just an annoying implementation detail. > > Yes. =A0The user-agent flow is a set of annoying implementation details > that are very, very useful if you want to make the protocol efficient. Update: we're not planning on doing anything with code_and_token; we think most use-cases can be met with one of three flows: - query string, with a code - fragment, with a token - HTML 5 techniques, with either. This is still a little new to standardize, but we'll have our libraries use HTML 5 where possible. Cheers, Brian From eran@hueniverse.com Wed Jan 19 18:03:19 2011 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 63DB528C117 for ; Wed, 19 Jan 2011 18:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 d8VisYqImZzz for ; Wed, 19 Jan 2011 18:03:17 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 8981F3A700F for ; Wed, 19 Jan 2011 18:03:17 -0800 (PST) Received: (qmail 1016 invoked from network); 20 Jan 2011 02:05:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jan 2011 02:05:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 19 Jan 2011 19:05:57 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 19 Jan 2011 19:05:50 -0700 Thread-Topic: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token Thread-Index: Acu4RG7HFbrRAkt0QkqYTzO8sLQLcQAAfMvQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61A53@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 20 Jan 2011 02:03:20 -0000 Can I take this as an endorsement for dropping it? It feels very experiment= al and should be easy to add as an extension. As for your plan, will this work with a single authorization generating bot= h a token and code? EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Wednesday, January 19, 2011 5:51 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=3Dcode_and_token >=20 > On Tue, Jan 11, 2011 at 4:40 PM, Brian Eaton wrote: > > On Tue, Jan 11, 2011 at 1:21 PM, Eran Hammer-Lahav > wrote: > >> But that's just an annoying implementation detail. > > > > Yes. =A0The user-agent flow is a set of annoying implementation details > > that are very, very useful if you want to make the protocol efficient. >=20 > Update: we're not planning on doing anything with code_and_token; we > think most use-cases can be met with one of three flows: >=20 > - query string, with a code > - fragment, with a token > - HTML 5 techniques, with either. This is still a little new to standard= ize, but > we'll have our libraries use HTML 5 where possible. >=20 > Cheers, > Brian From beaton@google.com Wed Jan 19 18:07:05 2011 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 9426528C0FA for ; Wed, 19 Jan 2011 18:07:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFXGGjwwBdGb for ; Wed, 19 Jan 2011 18:07:04 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 7C5223A6FAB for ; Wed, 19 Jan 2011 18:07:04 -0800 (PST) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p0K29jYe031541 for ; Wed, 19 Jan 2011 18:09:45 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295489385; bh=pToueWDRJb+3rWPEnklzJOdckXU=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=N0fuerB+bDnVYRIQ/6XCBdrggr5QH1QTZ6lzvJHIc2Qj9FCcShhMwF/zip1nK7lt4 9vYpHnm5JZPewoytEQitw== Received: from pwi10 (pwi10.prod.google.com [10.241.219.10]) by hpaq6.eem.corp.google.com with ESMTP id p0K29d3o003696 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 19 Jan 2011 18:09:44 -0800 Received: by pwi10 with SMTP id 10so27586pwi.41 for ; Wed, 19 Jan 2011 18:09:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/XZ6rZotDRIH8nZ5LhjyVsUclqjZ30tBHhx63LSaMis=; b=NwfdNY+1GBAl2JP+gyQnD1+r4NpX1S03uIXpIBEk+BUu4+ISBPqMT1o5NyTEqHsXqd dYUqrk45+yKRAOtJ2Vlw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GCbdoAE2QVa/pHElh2g2Izo7/uO/VjZiRmqK66TGtrIkYtby6f6GafTnD2W1Al3+yt oFUqq68FsppAAXVYEzKA== MIME-Version: 1.0 Received: by 10.142.192.8 with SMTP id p8mr1528078wff.112.1295489383715; Wed, 19 Jan 2011 18:09:43 -0800 (PST) Received: by 10.142.213.7 with HTTP; Wed, 19 Jan 2011 18:09:43 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61A53@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A53@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 19 Jan 2011 18:09:43 -0800 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] Proposal to drop/relocate response_type=code_and_token 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, 20 Jan 2011 02:07:05 -0000 On Wed, Jan 19, 2011 at 6:05 PM, Eran Hammer-Lahav wrote: > Can I take this as an endorsement for dropping it? It feels very experimental and should be easy to add as an extension. I defer to the several other people who were interested in this approach. From memory, that's Brian Ellin, Luke Shephard, and Chuck Mortimore. > As for your plan, will this work with a single authorization generating both a token and code? Sorry, I don't understand the question. From eran@hueniverse.com Wed Jan 19 18:08:37 2011 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 328303A70F1 for ; Wed, 19 Jan 2011 18:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 wHgxD6ET2zBP for ; Wed, 19 Jan 2011 18:08:36 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 5557A3A6FAB for ; Wed, 19 Jan 2011 18:08:36 -0800 (PST) Received: (qmail 7128 invoked from network); 20 Jan 2011 02:11:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jan 2011 02:11:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 19 Jan 2011 19:11:17 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 19 Jan 2011 19:11:10 -0700 Thread-Topic: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token Thread-Index: Acu4Rx/ZzYIEKRgAQyCjQwD/gFcxlgAABnJg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61A58@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A53@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 20 Jan 2011 02:08:37 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Wednesday, January 19, 2011 6:10 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=3Dcode_and_token >=20 > On Wed, Jan 19, 2011 at 6:05 PM, Eran Hammer-Lahav > wrote: > > Can I take this as an endorsement for dropping it? It feels very > experimental and should be easy to add as an extension. >=20 > I defer to the several other people who were interested in this approach. > From memory, that's Brian Ellin, Luke Shephard, and Chuck Mortimore. >=20 > > As for your plan, will this work with a single authorization generating= both a > token and code? >=20 > Sorry, I don't understand the question. Will this HTML5 magic involve making a single authorization request (redire= ction) or two? EHL From eran@hueniverse.com Wed Jan 19 18:11:53 2011 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 0AE2D28C0FA for ; Wed, 19 Jan 2011 18:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 g7S6AoTq47FV for ; Wed, 19 Jan 2011 18:11:52 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id ED9E53A70F1 for ; Wed, 19 Jan 2011 18:11:51 -0800 (PST) Received: (qmail 10445 invoked from network); 20 Jan 2011 02:14:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jan 2011 02:14:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 19 Jan 2011 19:14:32 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 19 Jan 2011 19:14:26 -0700 Thread-Topic: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token Thread-Index: Acu4Rx/ZzYIEKRgAQyCjQwD/gFcxlgAAHLLQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61A59@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A53@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 20 Jan 2011 02:11:53 -0000 > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Wednesday, January 19, 2011 6:10 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=3Dcode_and_token >=20 > On Wed, Jan 19, 2011 at 6:05 PM, Eran Hammer-Lahav > wrote: > > Can I take this as an endorsement for dropping it? It feels very > experimental and should be easy to add as an extension. >=20 > I defer to the several other people who were interested in this approach. > From memory, that's Brian Ellin, Luke Shephard, and Chuck Mortimore. Since no one else (other than you) showed any interest in keeping this sect= ion in for the past 9 days, I assume they don't care. I will remove this. EHL From beaton@google.com Wed Jan 19 18:12:35 2011 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 852A128C0FA for ; Wed, 19 Jan 2011 18:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwB1838qtKlK for ; Wed, 19 Jan 2011 18:12:34 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 787193A704A for ; Wed, 19 Jan 2011 18:12:34 -0800 (PST) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p0K2FFB3015199 for ; Wed, 19 Jan 2011 18:15:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295489715; bh=5wHdT33uF9N0KJ1l9AjhXDT74Cs=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=i/tyBUwYKSqYjDWms+2epu1hXBoGzd+2YXq+uev4uvF6joVj9QAD7oObex3rqNt69 128W0pFftTO6ttW8Kx90w== Received: from pxi16 (pxi16.prod.google.com [10.243.27.16]) by wpaz33.hot.corp.google.com with ESMTP id p0K2FD6o006671 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 19 Jan 2011 18:15:13 -0800 Received: by pxi16 with SMTP id 16so19039pxi.32 for ; Wed, 19 Jan 2011 18:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=+RZ6hUcUl4WWX9bwB6zuL4rlkzL+yqu7JS3SnEbhZ0I=; b=ZpeTD5/aASc90uPXVioC6MnTNX5JBQHpnuugFyVRIYCHxPouy4Dq5wiaR3SiYROVTz eWb8ODW+DRY9F4NTus9A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FG0z1Zr3GWNR/AwqRAiSMGvJnQbo60E8rsG0QUdY8s5r84Xir6/wYdFYYhINdLKrmw UVY4WCn/XMqiiiNi4YAQ== MIME-Version: 1.0 Received: by 10.142.241.18 with SMTP id o18mr1507925wfh.340.1295489711997; Wed, 19 Jan 2011 18:15:11 -0800 (PST) Received: by 10.142.213.7 with HTTP; Wed, 19 Jan 2011 18:15:10 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61A58@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A53@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A58@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 19 Jan 2011 18:15:10 -0800 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] Proposal to drop/relocate response_type=code_and_token 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, 20 Jan 2011 02:12:35 -0000 On Wed, Jan 19, 2011 at 6:11 PM, Eran Hammer-Lahav wrote: > Will this HTML5 magic involve making a single authorization request (redirection) or two? It's not magic, it's window.postMessage(). It's an authenticated low-latency channel between windows or iframes. There is more than one way to use it. Not sure what we'll do exactly yet. From beaton@google.com Wed Jan 19 18:18:13 2011 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 0DB213A7203 for ; Wed, 19 Jan 2011 18:18:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.477 X-Spam-Level: X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=1.500, 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 ZQAgu-+yswoH for ; Wed, 19 Jan 2011 18:18:12 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 1AC8F3A71FF for ; Wed, 19 Jan 2011 18:18:12 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p0K2KrSV001423 for ; Wed, 19 Jan 2011 18:20:53 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295490053; bh=4cTLO1ZpArwsEIyvEvhtC+jiO1w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=s3k/vbLTSUqFyZslL1jZlXhoaPoDrpth6uch45miaLGs6p+yetuq6cTyOAoMBNXyG hVHSWrWKJ9JSvPqrDJcaw== Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by wpaz24.hot.corp.google.com with ESMTP id p0K2KiQe019690 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 19 Jan 2011 18:20:52 -0800 Received: by pwj3 with SMTP id 3so23230pwj.19 for ; Wed, 19 Jan 2011 18:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wYg/gg1d8Z75RkHgRL0kdVWJ4D4iwKhG7nZTXfUmN44=; b=PndTnEPDGryG+TUwUTNIt9WjOPByTEkcRBr5yqqwzxCV30ejy2G8H7UnIzUsLMLDU9 Hg9TDr1urec2AQdhwbZQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QeCDlJKpP2DUl7oQbdG5uAc/YnBzaxf3VvYPN3M2FfKZ82JcZLBHNj6pa5OEzEzYim /Uckj1UzmKKw7vJF85Pg== MIME-Version: 1.0 Received: by 10.142.173.8 with SMTP id v8mr1508156wfe.397.1295490051815; Wed, 19 Jan 2011 18:20:51 -0800 (PST) Received: by 10.142.213.7 with HTTP; Wed, 19 Jan 2011 18:20:51 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61A59@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A53@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A59@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 19 Jan 2011 18:20:51 -0800 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] Proposal to drop/relocate response_type=code_and_token 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, 20 Jan 2011 02:18:13 -0000 On Wed, Jan 19, 2011 at 6:14 PM, Eran Hammer-Lahav wrote: > Since no one else (other than you) showed any interest in keeping this section in for the past 9 days, I assume they don't care. I will remove this. This is an unfortunate assumption, and I think it could do serious damage to the spec. I think before you declare consensus to have changed, it would be a good idea to reach out to the people who had the original use cases to see what they think. Very few people have the bandwidth to follow every thread on this mailing list. Furthermore, once they make sure that the spec is going to address their needs they don't read the list as carefully. From eran@hueniverse.com Wed Jan 19 18:35:56 2011 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 771723A7004 for ; Wed, 19 Jan 2011 18:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 WoAnjHZHtcrV for ; Wed, 19 Jan 2011 18:35:53 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C34623A6DA7 for ; Wed, 19 Jan 2011 18:35:53 -0800 (PST) Received: (qmail 1663 invoked from network); 20 Jan 2011 02:38:35 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 20 Jan 2011 02:38:35 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 19 Jan 2011 19:38:31 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 19 Jan 2011 19:38:24 -0700 Thread-Topic: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token Thread-Index: Acu4SKuMi8IS5+WVTUybr19JIR4DdwAAd0yg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A53@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A59@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token 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, 20 Jan 2011 02:35:56 -0000 I am not going to spend the time it will take to write it in the new organi= zation only to take it out later. I much rather take it out in -12 and put = it right back in -13 if they rejoin us and show support. As for damage, since this is a well-contained feature that is trivial to ad= d as an extension, I don't see any problem. It's ironic that you, who consistently wanted anything that is not back up = by significant deployment experience removed, is pushing for including a fe= ature that clearly belongs to that category. Even you are not going to use = it. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Wednesday, January 19, 2011 6:21 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Proposal to drop/relocate > response_type=3Dcode_and_token >=20 > On Wed, Jan 19, 2011 at 6:14 PM, Eran Hammer-Lahav > wrote: > > Since no one else (other than you) showed any interest in keeping this > section in for the past 9 days, I assume they don't care. I will remove t= his. >=20 > This is an unfortunate assumption, and I think it could do serious damage= to > the spec. I think before you declare consensus to have changed, it would= be > a good idea to reach out to the people who had the original use cases to = see > what they think. >=20 > Very few people have the bandwidth to follow every thread on this mailing > list. Furthermore, once they make sure that the spec is going to address > their needs they don't read the list as carefully. From wmills@yahoo-inc.com Thu Jan 20 08:43:49 2011 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 06FF73A7125 for ; Thu, 20 Jan 2011 08:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.389 X-Spam-Level: X-Spam-Status: No, score=-17.389 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, 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 lQ62CswyGdr3 for ; Thu, 20 Jan 2011 08:43:48 -0800 (PST) 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 2137F3A6FDE for ; Thu, 20 Jan 2011 08:43:47 -0800 (PST) Received: from SP2-EX07CAS03.ds.corp.yahoo.com (sp2-ex07cas03.corp.sp2.yahoo.com [98.137.59.35]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0KGjXeT083147; Thu, 20 Jan 2011 08:45:33 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS03.ds.corp.yahoo.com ([98.137.59.35]) with mapi; Thu, 20 Jan 2011 08:45:32 -0800 From: William Mills To: Marius Scurtescu Date: Thu, 20 Jan 2011 08:45:07 -0800 Thread-Topic: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme Thread-Index: Acu4A9gMZyKfIqZiQCCLV2bEAaPQcgAAflkw Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D618FF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D6191F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme 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, 20 Jan 2011 16:43:49 -0000 Yes, host-meta is definitely in play. I do want the SASL profile to be abl= e to specify discovery info in-band too though. So the discovery returned = in the SASL profile might be a host-meta indication or it might be the rele= vant contents if the SASL profile wants to override what might be normal fo= r the domain. -bill > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, January 19, 2011 9:59 AM > To: William Mills > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Removal: 'OAuth2' HTTP Authentication Scheme >=20 > On Wed, Jan 19, 2011 at 9:50 AM, William Mills > wrote: > > Yes it's old, 1 week form expiring too.=A0 The specs seem to be > stabilizing > > now so it's worth updating.=A0 =A0Has there been any other discovery > proposal > > yet? >=20 > Nothing concrete AFAIK, but for SASL we also discussed using host-meta > style discovery. Somehow this approach seemed cleaner to me, but of > course it needs work (to define file location/format/content). >=20 > Marius From Axel.Nennker@telekom.de Thu Jan 20 09:36:45 2011 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 BFD6E3A7133 for ; Thu, 20 Jan 2011 09:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 xjL6NYzxVJh3 for ; Thu, 20 Jan 2011 09:36:44 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 4BAE23A7016 for ; Thu, 20 Jan 2011 09:36:44 -0800 (PST) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 20 Jan 2011 18:39:22 +0100 Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Jan 2011 18:39:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 20 Jan 2011 18:39:24 +0100 Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA30599FA5F@S4DE9JSAAID.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: JSON Web Token Java implementation thread-index: Acu4A9gMZyKfIqZiQCCLV2bEAaPQcgAAflkwADCIklA= References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E723445A8D618FF@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E723445A8D6191F@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: To: X-OriginalArrivalTime: 20 Jan 2011 17:39:22.0310 (UTC) FILETIME=[F924CE60:01CBB8C8] Subject: [OAUTH-WG] JSON Web Token Java implementation 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, 20 Jan 2011 17:36:46 -0000 My java code for implementing the new JSON Web Token draft-01 http://self-issued.info/docs/draft-jones-json-web-token-01.html is ready and commited to the openinfocard source code repository. JUNIT tests are here: =20 https://code.google.com/p/openinfocard/source/browse/trunk/testsrc/org/x mldap/json/WebTokenTest.java The JUNIT test verify all examples from the draft-01. The implementation is here: =20 https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmlda p/json/WebToken.java The code supports all algorithms and all size variants. HS256, HS384, HS512 : HMAC with sha256, sha384, sha512 RS256, RS384, RS512 : RSA with sha256, sha384, sha512 ES256, ES384, ES512 : ECDSA 256, 384, 521 (sic) with sha256, sha384, sha512 Cheers Axel From beaton@google.com Thu Jan 20 09:55:34 2011 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 F16C63A7048 for ; Thu, 20 Jan 2011 09:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.977 X-Spam-Level: X-Spam-Status: No, score=-104.977 tagged_above=-999 required=5 tests=[AWL=1.000, 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 MBWGgzhQ5flh for ; Thu, 20 Jan 2011 09:55:32 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id B9BC23A7041 for ; Thu, 20 Jan 2011 09:55:32 -0800 (PST) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p0KHwFdb010760 for ; Thu, 20 Jan 2011 09:58:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295546296; bh=E2OjlJ/LyA3paNviQqTBgqG3IXM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=FIll9wzqRM1IeS5ZP9Jjx5PWD54mFWv6T1W1xJmtIpDudOd1QzDTb68DMgA+m+ni5 u1FEJHHNon7O3u9M7YU1A== Received: from pwj8 (pwj8.prod.google.com [10.241.219.72]) by hpaq7.eem.corp.google.com with ESMTP id p0KHvWbW008791 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Jan 2011 09:58:13 -0800 Received: by pwj8 with SMTP id 8so156134pwj.8 for ; Thu, 20 Jan 2011 09:58:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NYeKI0XFQAFZA+bMV9bQ8BVKRAmasmmDC8HpPPR0qJU=; b=blcom3Sdb8YerkAXenoZ/E2JSjv531sNOnaX1094l2IVkveVSKFIrRsPRtekomEXjy KxRM4tfoI52QS/9efeTw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=mYLASY+Gtot1XEztIpQljaG9xixDfgO0bOQD0weKMi3pbYjXeP+otTLonA+4cyPEkb 8ABeoeevHZ47vzRqIz6Q== MIME-Version: 1.0 Received: by 10.142.155.10 with SMTP id c10mr2414268wfe.283.1295546293448; Thu, 20 Jan 2011 09:58:13 -0800 (PST) Received: by 10.142.213.7 with HTTP; Thu, 20 Jan 2011 09:58:11 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB750C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB751E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7529@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7537@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB76E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A5AB7703@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A53@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A59@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61A5B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 20 Jan 2011 09:58:11 -0800 Message-ID: From: Brian Eaton To: Eran Hammer-Lahav , Chuck Mortimore , lshepard@fb.com, Brian Ellin 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] Proposal to drop/relocate response_type=code_and_token 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, 20 Jan 2011 17:55:34 -0000 OK, looping in Chuck, Luke, and Brian. Do you all remember the discussion we had a few months ago about having the user-agent profile return a verification code in the fragment? The middle of the discussion thread is here: http://www.ietf.org/mail-archive/web/oauth/current/msg02680.html Do any of you have deployment experience with that feature yet? There is a proposal to drop it from the spec due to lack of deployment experience. I don't think we're going to end up using it, we're going to lean more on HTML 5 instead. Cheers, Brian On Wed, Jan 19, 2011 at 6:38 PM, Eran Hammer-Lahav wr= ote: > I am not going to spend the time it will take to write it in the new orga= nization only to take it out later. I much rather take it out in -12 and pu= t it right back in -13 if they rejoin us and show support. > > As for damage, since this is a well-contained feature that is trivial to = add as an extension, I don't see any problem. > > It's ironic that you, who consistently wanted anything that is not back u= p by significant deployment experience removed, is pushing for including a = feature that clearly belongs to that category. Even you are not going to us= e it. > > EHL > >> -----Original Message----- >> From: Brian Eaton [mailto:beaton@google.com] >> Sent: Wednesday, January 19, 2011 6:21 PM >> To: Eran Hammer-Lahav >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] Proposal to drop/relocate >> response_type=3Dcode_and_token >> >> On Wed, Jan 19, 2011 at 6:14 PM, Eran Hammer-Lahav >> wrote: >> > Since no one else (other than you) showed any interest in keeping this >> section in for the past 9 days, I assume they don't care. I will remove = this. >> >> This is an unfortunate assumption, and I think it could do serious damag= e to >> the spec. =A0I think before you declare consensus to have changed, it wo= uld be >> a good idea to reach out to the people who had the original use cases to= see >> what they think. >> >> Very few people have the bandwidth to follow every thread on this mailin= g >> list. =A0Furthermore, once they make sure that the spec is going to addr= ess >> their needs they don't read the list as carefully. > From Michael.Jones@microsoft.com Thu Jan 20 09:55:55 2011 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 A75823A7162 for ; Thu, 20 Jan 2011 09:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.588 X-Spam-Level: X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 4EjcaCr4bJ8K for ; Thu, 20 Jan 2011 09:55:54 -0800 (PST) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 99F5D3A7041 for ; Thu, 20 Jan 2011 09:55:54 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Jan 2011 09:58:31 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Thu, 20 Jan 2011 09:58:31 -0800 From: Mike Jones To: "Axel.Nennker@telekom.de" , "oauth@ietf.org" Thread-Topic: JSON Web Token Java implementation Thread-Index: AQHLuMkYPxASSXeGw0auRVpbdQGAU5PaJa9w Date: Thu, 20 Jan 2011 17:58:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246F1416@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6A@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E723445A6B9D892@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E723445A8D618FF@P3PW5EX1MB01.EX1.SECURESERVER.NET><90C41DD21FB7C64BB94121FBBC2E723445A8D6191F@P3PW5EX1MB01.EX1.SECURESERVER.NET> <98B37F7D0484184B9DBDCC44B6C8EDA30599FA5F@S4DE9JSAAID.ost.t-com.de> In-Reply-To: <98B37F7D0484184B9DBDCC44B6C8EDA30599FA5F@S4DE9JSAAID.ost.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] JSON Web Token Java implementation 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, 20 Jan 2011 17:55:55 -0000 Very cool! -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of A= xel.Nennker@telekom.de Sent: Thursday, January 20, 2011 9:39 AM To: oauth@ietf.org Subject: [OAUTH-WG] JSON Web Token Java implementation My java code for implementing the new JSON Web Token draft-01 http://self-= issued.info/docs/draft-jones-json-web-token-01.html is ready and commited to the openinfocard source code repository. JUNIT tests are here: =20 https://code.google.com/p/openinfocard/source/browse/trunk/testsrc/org/x mldap/json/WebTokenTest.java The JUNIT test verify all examples from the draft-01. The implementation is here: =20 https://code.google.com/p/openinfocard/source/browse/trunk/src/org/xmlda p/json/WebToken.java The code supports all algorithms and all size variants. HS256, HS384, HS512 : HMAC with sha256, sha384, sha512 RS256, RS384, RS512 = : RSA with sha256, sha384, sha512 ES256, ES384, ES512 : ECDSA 256, 384, 52= 1 (sic) with sha256, sha384, sha512 Cheers Axel _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Thu Jan 20 13:05:38 2011 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 1FF543A6822 for ; Thu, 20 Jan 2011 13:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.587 X-Spam-Level: X-Spam-Status: No, score=-10.587 tagged_above=-999 required=5 tests=[AWL=0.011, 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 vY1Y4bb-Y28f for ; Thu, 20 Jan 2011 13:05:32 -0800 (PST) Received: from smtp.microsoft.com (maila.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 350863A6810 for ; Thu, 20 Jan 2011 13:05:32 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 20 Jan 2011 13:08:15 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Thu, 20 Jan 2011 13:08:15 -0800 From: Mike Jones To: Brian Campbell Thread-Topic: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations Thread-Index: Acu0VTXpUIsMDbsTSSysOJUnTwqrGwCPghGAAJSwdxA= Date: Thu, 20 Jan 2011 21:08:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246F1A1C@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943246E7E60@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246F1A1CTK5EX14MBXC202r_" MIME-Version: 1.0 Cc: oauth Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations 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, 20 Jan 2011 21:05:38 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246F1A1CTK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having thought about it, I'm willing to remove the text below. Are there a= ny other sections of the bearer token security considerations that you beli= eve belong in the framework spec rather than the bearer token spec, or that= don't belong at all? Thanks again, -- Mike From: Brian Campbell [mailto:bcampbell@pingidentity.com] Sent: Monday, January 17, 2011 6:10 AM To: Mike Jones Cc: oauth Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 s= ecurity considerations That text still seems more restrictive than what is in the framework specif= ication. And it's probably unnecessary - to the point James made previousl= y, any mention of the AS (beyond specifying the token_type) in a "using a t= oken" specification should probably be avoided unless there is a very speci= fic reason for including it. In general, the AS is involved when "getting = a token" and the RS is involved when "using a token." On Fri, Jan 14, 2011 at 6:40 PM, Mike Jones > wrote: Thanks for your input, Brian. I accepted these suggestions for draft -02. = The referenced text now reads: Furthermore, the authorization server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the authorization server. The authorization server MUST also obtain the consent of the resource owner prior to providing a token to the client. I'll leave it up to Eran how much of this security considerations text to i= ncorporate into the framework specification. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-b= ounces@ietf.org] On Behalf Of Brian Campbell Sent: Thursday, December 09, 2010 1:38 PM To: oauth Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 secur= ity considerations I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however= , a couple things jumped out at me in areas that hadn't received much atten= tion yet so I wanted to raise the questions on a separate thread. Near the end of section 3.2. Threat Mitigation, it says: " Furthermore, the resource server MUST ensure that it only hands out tokens to clients it has authenticated first and authorized. For this purpose, the client MUST be authenticated and authorized by the resource server. " Was the intent here to say authorization server rather than resource server= ? The resource server doesn't hand out tokens. Also, aren't there legitimat= e cases where the client isn't authenticated (anonymous or other cases wher= e the client can't keep secrets)? Then it says: "The authorization server MUST also receive a confirmation (the consent of the resource owner) prior to providing a token to the client." Does this allow for implicit consent? On my first read of it, I interpret t= his as potentially being more restrictive than what is in draft-ietf-oauth-v2-11 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_4E1F6AAD24975D4BA5B1680429673943246F1A1CTK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having thought about it, = I’m willing to remove the text below.  Are there any other secti= ons of the bearer token security considerations that you believe belong in the framework spec rather than the bearer token spec, or that don’= ;t belong at all?

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks again,

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

 <= /p>

From: Brian Ca= mpbell [mailto:bcampbell@pingidentity.com]
Sent: Monday, January 17, 2011 6:10 AM
To: Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bear= er-01 security considerations

 

That text still seems= more restrictive than what is in the framework specification.  And it= 's probably unnecessary - to the point James made previously, any mention o= f the AS (beyond specifying the token_type) in a "using a token" specification should probably be avoided un= less there is a very specific reason for including it.  In general, th= e AS is involved when "getting a token" and the RS is involved wh= en "using a token."

On Fri, Jan 14, 2011 at 6:40 PM, Mike Jones <Michael.Jones@microsoft.com&= gt; wrote:

Thanks for your input, Brian.  I accepted these= suggestions for draft -02.  The referenced text now reads:

        Furthermore, the
         authorization server MUST ensure that it = only hands out tokens to

         clients it has aut= henticated first and authorized. For this
         purpose, the client MUST be authenticated= and authorized by

         the authorization = server. The authorization server MUST also
         obtain the consent of the resource owner<= o:p>

      =    prior to providing a token to the client.

I'll leave it up to Eran how much of this security c= onsiderations text to incorporate into the framework specification.

                     = ;          -- Mike


-----Original Message-----
From: oauth-bounces@ietf.org = [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, December 09, 2010 1:38 PM
To: oauth
Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 secur= ity considerations

I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however= , a couple things jumped out at me in areas that hadn't received much atten= tion yet so I wanted to raise the questions on a separate thread.

Near the end of section 3.2. Threat Mitigation, it says:

" Furthermore, the resource server MUST ensure that it only hands out<= br>   tokens to clients it has authenticated first and authorized.  F= or
  this purpose, the client MUST be authenticated and authorized by the=
  resource server. "

Was the intent here to say authorization server rather than resource server= ? The resource server doesn't hand out tokens. Also, aren't there legitimat= e cases where the client isn't authenticated (anonymous or other cases wher= e the client can't keep secrets)?

Then it says:

"The authorization server MUST also receive a
  confirmation (the consent of the resource owner) prior to providing = a
  token to the client."

Does this allow for implicit consent? On my first read of it, I interpret t= his as potentially being more restrictive than what is in
draft-ietf-oauth-v2-11
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

 

--_000_4E1F6AAD24975D4BA5B1680429673943246F1A1CTK5EX14MBXC202r_-- From mscurtescu@google.com Thu Jan 20 13:06:03 2011 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 584233A682B for ; Thu, 20 Jan 2011 13:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.757 X-Spam-Level: X-Spam-Status: No, score=-105.757 tagged_above=-999 required=5 tests=[AWL=0.220, 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 I3RWDJGyd9CK for ; Thu, 20 Jan 2011 13:06:02 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E7DDC3A6810 for ; Thu, 20 Jan 2011 13:06:01 -0800 (PST) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p0KL8jYo030357 for ; Thu, 20 Jan 2011 13:08:45 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295557725; bh=YIdzeJUMcRsmN6NXilYkECU7wZw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ieoGmzJ6Bttekh29Ombhe1cAVRlXBh6255HjexocnRED7sPE7spiejFRmseUk2CB1 ACTrlLQ/0NjGwJuZpPmtA== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by hpaq7.eem.corp.google.com with ESMTP id p0KL8guY022819 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Jan 2011 13:08:43 -0800 Received: by gwj20 with SMTP id 20so476180gwj.22 for ; Thu, 20 Jan 2011 13:08:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Zvu2V6YzjU8TZjD9Obcys0kDHtvSt60F3U+2N9TMrm8=; b=BgehpxelkSASHB34N9GIX/nXS90VTWaU2IK+JaVZQuNmMTcZsH2CwJiBiF7HM5pd/W 96MhD83hv+cQk7/jUBOg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=EN4eBnlv4olbWqeJunEdmfbBJXvfWXpPmnLUupbhT4TaQurG5R+xugE8vgZ/b7HWGE Ii/i1Eb9ZbLgkk7+Uysw== Received: by 10.100.139.9 with SMTP id m9mr1839705and.183.1295557722586; Thu, 20 Jan 2011 13:08:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Thu, 20 Jan 2011 13:08:22 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 20 Jan 2011 13:08:22 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 21:06:03 -0000 On Tue, Jan 18, 2011 at 10:12 AM, Eran Hammer-Lahav wrote: > Client assertion credentials: > > The mechanism is under specified, especially in its handling of the > client_id identifier (when used to obtain end-user authorization). > It does not contain any implementation details to accomplish any level of > interoperability or functionality. Google has plans to use client assertions as well. We have two use cases, one indeed would require an additional extension to specify details about the content and format of the assertion. But the other would work with what currently exists in v11. In both cases the client cannot send the secret as authentication (either for technical or security reasons) and instead it sends an assertion. In the fist case the client is self issuing an assertion, and in this case we need more details. In the second case the client gets an assertion from a local IdP. In this case the local IdP and the remote OAuth 2 Authorization Server do need to agree on keys and formats, but the client does not need to understand any of that. Marius From bcampbell@pingidentity.com Thu Jan 20 13:23:22 2011 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 174793A682C for ; Thu, 20 Jan 2011 13:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wHSGo+YuXNQY for ; Thu, 20 Jan 2011 13:23:20 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with ESMTP id E32803A682A for ; Thu, 20 Jan 2011 13:23:19 -0800 (PST) Received: from source ([209.85.161.42]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTTioYc6CpskjUJiQfxPPBTETWcEEcU7x@postini.com; Thu, 20 Jan 2011 13:26:04 PST Received: by mail-fx0-f42.google.com with SMTP id 11so1415845fxm.15 for ; Thu, 20 Jan 2011 13:25:53 -0800 (PST) Received: by 10.223.86.16 with SMTP id q16mr2713916fal.58.1295558741037; Thu, 20 Jan 2011 13:25:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.55.9 with HTTP; Thu, 20 Jan 2011 13:25:09 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Thu, 20 Jan 2011 14:25:09 -0700 Message-ID: To: Marius Scurtescu Content-Type: multipart/alternative; boundary=20cf3054a6e98b9294049a4dc6bf Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 21:23:22 -0000 --20cf3054a6e98b9294049a4dc6bf Content-Type: text/plain; charset=ISO-8859-1 I'd argue that, for reliable interoperability, both of those cases would require an extension or at least some level of agreement about the format and validation rules of the assertion. On Thu, Jan 20, 2011 at 2:08 PM, Marius Scurtescu wrote: > On Tue, Jan 18, 2011 at 10:12 AM, Eran Hammer-Lahav > wrote: > > Client assertion credentials: > > > > The mechanism is under specified, especially in its handling of the > > client_id identifier (when used to obtain end-user authorization). > > It does not contain any implementation details to accomplish any level of > > interoperability or functionality. > > Google has plans to use client assertions as well. We have two use > cases, one indeed would require an additional extension to specify > details about the content and format of the assertion. But the other > would work with what currently exists in v11. > > In both cases the client cannot send the secret as authentication > (either for technical or security reasons) and instead it sends an > assertion. > > In the fist case the client is self issuing an assertion, and in this > case we need more details. > > In the second case the client gets an assertion from a local IdP. In > this case the local IdP and the remote OAuth 2 Authorization Server do > need to agree on keys and formats, but the client does not need to > understand any of that. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --20cf3054a6e98b9294049a4dc6bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd argue that, for reliable interoperability, both of those cases woul= d require an extension or at least some level of agreement about the format= and validation rules of the assertion.=A0

On Thu, Jan 20, 2011 at 2:08 PM, Marius Scurtescu <mscurtescu@google.com> = wrote:
On Tue, Jan 18, 2011 at 10:12 AM, Eran Hammer-Lahav <<= a href=3D"mailto:eran@hueniverse.com">eran@hueniverse.com> wrote: > Client assertion credentials:
>
> The mechanism is under specified, especially in its handling of the > client_id identifier (when used to obtain end-user authorization).
> It does not contain any implementation details to accomplish any level= of
> interoperability or functionality.

Google has plans to use client assertions as well. We have two use cases, one indeed would require an additional extension to specify
details about the content and format of the assertion. But the other
would work with what currently exists in v11.

In both cases the client cannot send the secret as authentication
(either for technical or security reasons) and instead it sends an
assertion.

In the fist case the client is self issuing an assertion, and in this
case we need more details.

In the second case the client gets an assertion from a local IdP. In
this case the local IdP and the remote OAuth 2 Authorization Server do
need to agree on keys and formats, but the client does not need to
understand any of that.

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

--20cf3054a6e98b9294049a4dc6bf-- From mscurtescu@google.com Thu Jan 20 13:35:47 2011 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 8827D3A6832 for ; Thu, 20 Jan 2011 13:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.771 X-Spam-Level: X-Spam-Status: No, score=-105.771 tagged_above=-999 required=5 tests=[AWL=0.206, 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 qGAyPb2FhYGM for ; Thu, 20 Jan 2011 13:35:46 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 960293A6831 for ; Thu, 20 Jan 2011 13:35:46 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p0KLcU1A012951 for ; Thu, 20 Jan 2011 13:38:30 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295559510; bh=AC940X0g2HMOhREQzQG3VZA6an8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=nJRHz58JKmerYsp4xiXh+83UxaD1c9f4k1v8FNnzR9reqc3xfzOnwMlfoSHD362/P BdPsUzOJ8zQO56gGPLsJg== Received: from yxe42 (yxe42.prod.google.com [10.190.2.42]) by wpaz37.hot.corp.google.com with ESMTP id p0KLaNRY023611 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Jan 2011 13:38:29 -0800 Received: by yxe42 with SMTP id 42so341563yxe.9 for ; Thu, 20 Jan 2011 13:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=oDwQq/yh8hxkRJ5Rhmiq5M5Xq8wEyQT6AH+O/+DMSW4=; b=Ai4NwcsSCIkuN0JsBOazc78eH6BduKEt17qObo8BloiKoiFrHg07ISwzPWpi0d9eRi VsGP8VLiwQd0ka7+wRrg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=kdmWob6twszCs6/rNJ21VqsWtFF8FjjLKxGDk55vsiqcgJlj9IXmRn+tPYIGTAr1Hi wZbKiV9OBfc6P+eZLdVw== Received: by 10.100.94.13 with SMTP id r13mr1865608anb.149.1295559508815; Thu, 20 Jan 2011 13:38:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Thu, 20 Jan 2011 13:38:08 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 20 Jan 2011 13:38:08 -0800 Message-ID: To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 21:35:47 -0000 On Thu, Jan 20, 2011 at 1:25 PM, Brian Campbell wrote: > I'd argue that, for reliable interoperability, both of those cases would > require an extension or at least some level of agreement about the format > and validation rules of the assertion. I do agree that an extension would be useful for the second case, but I don't think the client needs to know about it. I think it is somewhat similar with the situation of the scope parameter. Marius From phil.hunt@oracle.com Thu Jan 20 14:13:16 2011 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 765BB3A6852 for ; Thu, 20 Jan 2011 14:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 BsbKCkfWPP-i for ; Thu, 20 Jan 2011 14:13:15 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 9C8673A6851 for ; Thu, 20 Jan 2011 14:13:15 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0KMFt9j028753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 22:15:56 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0KEVn4j029486; Thu, 20 Jan 2011 22:15:54 GMT Received: from abhmt017.oracle.com by acsmt353.oracle.com with ESMTP id 979062331295561658; Thu, 20 Jan 2011 14:14:18 -0800 Received: from [10.151.5.137] (/148.87.13.5) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jan 2011 14:14:18 -0800 References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Type: text/plain; charset=us-ascii Message-Id: <1989C58C-5F31-4AC2-91B6-15312C3B73AE@oracle.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPhone Mail (8C148a) From: Phillip Hunt Date: Thu, 20 Jan 2011 14:14:14 -0800 To: Marius Scurtescu Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 22:13:16 -0000 The client does need to know how to authenticate. But given that it already h= as to know a lot about the service, you would think acceptable authenticatio= n types are well known to the client.=20 What is the problem with the client authenticating like any normal web servi= ce client? (IE outside of oauth)=20 Why involve oauth in any authentication for User or client? I have some thoughts but interested in yours.=20 Phil Sent from my phone.=20 On 2011-01-20, at 13:38, Marius Scurtescu wrote: > On Thu, Jan 20, 2011 at 1:25 PM, Brian Campbell > wrote: >> I'd argue that, for reliable interoperability, both of those cases would >> require an extension or at least some level of agreement about the format= >> and validation rules of the assertion. >=20 > I do agree that an extension would be useful for the second case, but > I don't think the client needs to know about it. I think it is > somewhat similar with the situation of the scope parameter. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From bcampbell@pingidentity.com Thu Jan 20 14:23:08 2011 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 5461B3A6837 for ; Thu, 20 Jan 2011 14:23:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Jamu67ITgbMR for ; Thu, 20 Jan 2011 14:23:07 -0800 (PST) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id C68233A6841 for ; Thu, 20 Jan 2011 14:23:05 -0800 (PST) Received: from source ([209.85.161.50]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTTi2bQZW7Hym8UP27Aa83No7ALdZU6Bo@postini.com; Thu, 20 Jan 2011 14:25:51 PST Received: by mail-fx0-f50.google.com with SMTP id 14so1177532fxm.23 for ; Thu, 20 Jan 2011 14:25:49 -0800 (PST) Received: by 10.223.96.195 with SMTP id i3mr2701390fan.77.1295562349464; Thu, 20 Jan 2011 14:25:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.55.9 with HTTP; Thu, 20 Jan 2011 14:25:19 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Thu, 20 Jan 2011 15:25:19 -0700 Message-ID: To: Marius Scurtescu Content-Type: multipart/alternative; boundary=20cf3054a4d79fda8e049a4e9dac Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 22:23:08 -0000 --20cf3054a4d79fda8e049a4e9dac Content-Type: text/plain; charset=ISO-8859-1 Okay, sorry, I see the distinction you were making. The client could potentially be told the client_assertion_type and given the assertion (assuming it's properly encoded for all the hops) by some IdP/STS and make use of the use of the spec, as it is written in -11. Maybe then some clients could support stronger forms of authentication for OAuth without knowing about or being coded for an extension. Maybe. But they still would need to know how to get the assertion and URI which is another animal all together. On Thu, Jan 20, 2011 at 2:38 PM, Marius Scurtescu wrote: > On Thu, Jan 20, 2011 at 1:25 PM, Brian Campbell > wrote: > > I'd argue that, for reliable interoperability, both of those cases would > > require an extension or at least some level of agreement about the format > > and validation rules of the assertion. > > I do agree that an extension would be useful for the second case, but > I don't think the client needs to know about it. I think it is > somewhat similar with the situation of the scope parameter. > > Marius > --20cf3054a4d79fda8e049a4e9dac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Okay, sorry, I see the distinction you were making.=A0 The client could pot= entially be told the client_assertion_type and given the assertion (assumin= g it's properly encoded for all the hops) by some IdP/STS and make use = of the use of the spec, as it is written in -11.=A0 Maybe then some clients= could support stronger forms of authentication for OAuth without knowing a= bout or being coded for an extension.=A0 Maybe.=A0 But they still would nee= d to know how to get the assertion and URI which is another animal all toge= ther.=A0

On Thu, Jan 20, 2011 at 2:38 PM, Marius Scur= tescu <mscurt= escu@google.com> wrote:
On Thu, Jan 20, 2011 at 1:25 PM, Brian Campbell
<bcampbell@pingidentity.co= m> wrote:
> I'd argue that, for reliable interoperability, both of those cases= would
> require an extension or at least some level of agreement about the for= mat
> and validation rules of the assertion.

I do agree that an extension would be useful for the second case, but=
I don't think the client needs to know about it. I think it is
somewhat similar with the situation of the scope parameter.

Marius

--20cf3054a4d79fda8e049a4e9dac-- From mscurtescu@google.com Thu Jan 20 14:25:44 2011 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 A9EC83A6841 for ; Thu, 20 Jan 2011 14:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.415 X-Spam-Level: X-Spam-Status: No, score=-104.415 tagged_above=-999 required=5 tests=[AWL=-1.438, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 eZgXy7om4m-Z for ; Thu, 20 Jan 2011 14:25:43 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 8B6943A6837 for ; Thu, 20 Jan 2011 14:25:43 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p0KMSQ4Q029772 for ; Thu, 20 Jan 2011 14:28:26 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295562507; bh=1avK6SB73XXGcKagTNpPRJcfJ7k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=V1AYbjNvtRwvcarn6jhQXZ3m5iFogn+2LLfhuaXHM+rCBsm1lD/IzTTHVyuYLV+tw fsVBv1ivR5XgiUlhx91EA== Received: from yie19 (yie19.prod.google.com [10.243.66.19]) by kpbe18.cbf.corp.google.com with ESMTP id p0KMQ1YT027450 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Jan 2011 14:28:25 -0800 Received: by yie19 with SMTP id 19so386337yie.3 for ; Thu, 20 Jan 2011 14:28:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=mZ/tNGOMeQwnhQQ1K0hJsmY88tut3SWX00fBrwI4UUU=; b=Xg1zjElQrW8ZmR+fGhnmW1oOxnSWV4Ee4s6lNIZJRWyAD25C2FEIkUHYju7wP/cJKE O1sgeSSleqSHvioe827Q== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=g8ZmqCZXI1qWIrz4J8i6vILwM12bM/yZVYaGKj/yH9u2J8VAXfvF2ZP2sYTd1Ybr7Q QDqIKY5DX3Zl45lcoCag== Received: by 10.101.204.28 with SMTP id g28mr1859537anq.217.1295562504768; Thu, 20 Jan 2011 14:28:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Thu, 20 Jan 2011 14:28:04 -0800 (PST) In-Reply-To: <1989C58C-5F31-4AC2-91B6-15312C3B73AE@oracle.com> References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1989C58C-5F31-4AC2-91B6-15312C3B73AE@oracle.com> From: Marius Scurtescu Date: Thu, 20 Jan 2011 14:28:04 -0800 Message-ID: To: Phillip Hunt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 22:25:44 -0000 On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt wrote: > The client does need to know how to authenticate. But given that it already has to know a lot about the service, you would think acceptable authentication types are well known to the client. Yes, true. > What is the problem with the client authenticating like any normal web service client? (IE outside of oauth) > > Why involve oauth in any authentication for User or client? What is a normal web service client? Since the client has to POST a bunch of parameters as form encoded, it is simpler to also send authentication parameters there. Providing alternate methods of authentication is just asking for trouble. Of course, the spec could require that authentication is only sent through some other method, but I think it is way too late for such a change. Marius From mscurtescu@google.com Thu Jan 20 14:27:18 2011 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 E92553A6867 for ; Thu, 20 Jan 2011 14:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.783 X-Spam-Level: X-Spam-Status: No, score=-105.783 tagged_above=-999 required=5 tests=[AWL=0.194, 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 KOb5DoFyTYHx for ; Thu, 20 Jan 2011 14:27:17 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E92FE3A685D for ; Thu, 20 Jan 2011 14:27:16 -0800 (PST) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p0KMU04L013595 for ; Thu, 20 Jan 2011 14:30:00 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295562600; bh=v/ZqWvLm4+5tv26SsGqLv8WItPg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=S8kSNrihQaXwMSX8oxc00gf/YQ0MttBaC7LU8GhEJuFPTFr2rXqN7KQmC8rhdZJy7 6tzI/b3WtB+x2FqxX4hHA== Received: from yxd5 (yxd5.prod.google.com [10.190.1.197]) by kpbe18.cbf.corp.google.com with ESMTP id p0KMTwCU031677 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 20 Jan 2011 14:29:59 -0800 Received: by yxd5 with SMTP id 5so357642yxd.34 for ; Thu, 20 Jan 2011 14:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=PheH42dpM7jQOlKpYlj17gdaH6WPrmFJD/PXiWfHpww=; b=WLwFrztYIkQvhc6SS4XwEL4gSvkqX4mMGETYM1oDML5FTInSFrpDVvUeUCOOoQkoqa YA0NXsQgA/SdSkYnD/7w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=p5yXCKMtOFHXI/zIERhSZaKFtrUZaBKqbGHejVYW+XOgJSuQ9KuXKES2RyDOThUR11 0wAz/vptnow25mLRQxuA== Received: by 10.100.106.4 with SMTP id e4mr1886939anc.81.1295562598567; Thu, 20 Jan 2011 14:29:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.242.17 with HTTP; Thu, 20 Jan 2011 14:29:37 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Thu, 20 Jan 2011 14:29:37 -0800 Message-ID: To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 22:27:19 -0000 On Thu, Jan 20, 2011 at 2:25 PM, Brian Campbell wrote: > Okay, sorry, I see the distinction you were making.=A0 The client could > potentially be told the client_assertion_type and given the assertion > (assuming it's properly encoded for all the hops) by some IdP/STS and mak= e > use of the use of the spec, as it is written in -11.=A0 Maybe then some > clients could support stronger forms of authentication for OAuth without > knowing about or being coded for an extension.=A0 Maybe.=A0 But they stil= l would > need to know how to get the assertion and URI which is another animal all > together. That's right, the client would have to know how to interact with the local IdP (and possibly how to authenticate with it). Marius From bcampbell@pingidentity.com Thu Jan 20 14:37:00 2011 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 5C8F63A6862 for ; Thu, 20 Jan 2011 14:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 bf7TUYGhLiBa for ; Thu, 20 Jan 2011 14:36:58 -0800 (PST) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by core3.amsl.com (Postfix) with ESMTP id 2759F3A682F for ; Thu, 20 Jan 2011 14:36:57 -0800 (PST) Received: from source ([209.85.161.49]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKTTi5ro6M/93fSNPaz6BVzytqg41gytiy@postini.com; Thu, 20 Jan 2011 14:39:42 PST Received: by mail-fx0-f49.google.com with SMTP id 19so1157014fxm.36 for ; Thu, 20 Jan 2011 14:39:42 -0800 (PST) Received: by 10.223.102.79 with SMTP id f15mr2688465fao.134.1295563181793; Thu, 20 Jan 2011 14:39:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.55.9 with HTTP; Thu, 20 Jan 2011 14:39:11 -0800 (PST) In-Reply-To: <72524.62131.qm@web55804.mail.re3.yahoo.com> References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <72524.62131.qm@web55804.mail.re3.yahoo.com> From: Brian Campbell Date: Thu, 20 Jan 2011 15:39:11 -0700 Message-ID: To: fcorella@pomcor.com Content-Type: multipart/alternative; boundary=90e6ba211f293c23e3049a4ecf33 Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 22:37:00 -0000 --90e6ba211f293c23e3049a4ecf33 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Francisco, While a proper profiling of subject confirmation is generally needed for a secure/interoperable SAML exchange, it's worth noting that assertions as used in OAuth (client assertions or URI/assertion grant types) are not necessarily SAML assertions. The term assertion is used more generally. T= o be honest, I think token might have been be a less confusing term to use in place of assertion in the framework spec. But token is widely used in othe= r contexts thought out the framework spec too. So I dunno, maybe that would be even more confusing. If you are interested/knowledgeable about SAML subject confirmation, please feel free to review and comment on the SAML Bearer Assertion Grant Type Profile: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00 :) -Brian On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella wro= te: > Mike, > > As assertion use is described in the spec, a client assertion does not > provide any security whatsoever. How do you handle subject confirmation = in > your implementation? (See section 2.4.1.1 of the SAML specification.) > In other words, how does the authorization server know that the client > sending the assertion is actually the subject of the assertion? > > Francisco > > --- On *Tue, 1/18/11, Mike Jones * wrote: > > > From: Mike Jones > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials an= d > OAuth2 HTTP Authentication Scheme > To: "Eran Hammer-Lahav" > Cc: "oauth@ietf.org" > Date: Tuesday, January 18, 2011, 5:35 PM > > > Having spoken to a number of people implementing the spec here, I=92ve > encountered strong objections to removing Client Assertion Credentials an= d > the OAuth2 HTTP Authentication Scheme. It=92s also not clear to me why w= e > would make substantial breaking changes to the specification when it is > essentially ready for approval. I=92ve summarized the reasons I believe = we > should keep these two features below. > > *Client Assertion Credentials:* Many of the scenarios we care about > require this capability. They were key motivators for the Assertion Profi= le > in WRAP (see =A7 5.2), have been part of OAuth 2 for quite a while, and w= e > have running code that requires this support. For example, the Azure Acce= ss > Control Service is a cloud Authorization server that supports several > protocols, including parts of OAuth 2.0 draft 10 (autonomous and web serv= er > profiles). We are happy to update our implementation to subsequent drafts= & > agree that the spec leaves a lot of ambiguity. > > In our implementation of the autonomous and web server profiles, ACS allo= ws > clients to authenticate using a signed assertion as well as with a > username/password. The username/pwd option is for clients that don=92t mi= nd > sending credentials over the wire, while the signed assertion mechanism i= s > for clients that are more reticent to send raw credentials and for scenar= ios > where it isn=92t possible. To illustrate an example where username/pwd is= n=92t > viable, consider the case of a client that needs to use an enterprise > identity to gain access to a cloud service. In many cases, corporate poli= cy > demands that a client use an identity managed by the organization. This > means that the client should obtain an assertion from an enterprise ident= ity > provider (Active Directory, Tivoli, etc.) and use that assertion to obtai= n > an access token which grants access to various web service APIs. Many of = our > key MSFT customers and internal partner teams rely on this mechanism and > reverting exclusively to username/pwd isn=92t an option for us. > > > > *'OAuth2' HTTP Authentication Scheme:* Simply put, dropping this seems > like a huge step away from interoperability. As one data point, Microsof= t > implements this in our WIF OAuth2 protected resource code. All up, clien= ts > need a way to authenticate to the protected resource. Also, existing WRA= P > implementations need this functionality to migrate to OAuth2. For all > these reasons, we support retaining this functionality in OAuth2. > > > > Thanks, > > -- Mike > > > > -----Inline Attachment Follows----- > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --90e6ba211f293c23e3049a4ecf33 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Francisco,

While a proper profiling of subject confirmation is gener= ally needed for a secure/interoperable SAML exchange, it's worth noting= that assertions as used in OAuth (client assertions or URI/assertion grant= types) are not necessarily SAML assertions.=A0 The term assertion is used = more generally.=A0 To be honest, I think token might have been be a less co= nfusing term to use in place of assertion in the framework spec.=A0 But tok= en is widely used in other contexts thought out the framework spec too.=A0 = So I dunno, maybe that would be even more confusing.

If you are interested/knowledgeable about SAML subject confirmation, pl= ease feel free to review and comment on the SAML Bearer Assertion Grant Typ= e Profile: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00=A0 = :)

-Brian

On Tue, Jan 18, 2011 at 1:26 PM, Francisco C= orella <fcorella@pomcor.com> wrote:
<= /tr>
Mike,

As assertion use is descri= bed in the spec, a client assertion does not provide any security whatsoeve= r.=A0 How do you handle subject confirmation in your implementation?=A0 (Se= e section 2.4.1.1 of the SAML specification.)=A0 = In other words, how does the authorization server know that the client send= ing the assertion is actually the subject of the assertion?

Francisco

--- On Tue, 1/18/11, Mike Jones <Michael.Jones@microsof= t.com> wrote:

From: Mike Jones <Michael.Jones@microsoft.com>
Subject: [OAUTH-WG] R= easons not to remove Client Assertion Credentials and OAuth2 HTTP Authentic= ation Scheme
To: "Eran Hammer-Lahav" <eran@hueniver= se.com>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Date: Tuesday, January 18, 2011, 5:35 PM


=20 =20

Having spoken to a number of people implementing the spec here, I=92ve e= ncountered strong objections to removing Client Assertion Credentials and t= he OAuth2 HTTP Authentication Scheme. =A0It=92s also not clear to me why we= would make substantial breaking changes to the specification when it is essentially ready for app= roval.=A0 I=92ve summarized the reasons I believe we should keep these two = features below.

=20

=20

Client Assertion Credentials:=A0 Many of the scenarios we care ab= out require this capability. They were key motivators for the Assertion Pro= file in WRAP (see =A7 5.2), have been part of OAuth 2 for quite a while, an= d we have running code that requires this support. For example, the Azure Access Control Ser= vice is a cloud Authorization server that supports several protocols, inclu= ding parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We a= re happy to update our implementation to subsequent drafts & agree that the spec leaves a lot of ambiguity.<= /p>=20

=20

In our implementation of the autonomous and web server profiles, ACS all= ows clients to authenticate using a signed assertion as well as with a user= name/password. The username/pwd option is for clients that don=92t mind sen= ding credentials over the wire, while the signed assertion mechanism is for clients that ar= e more reticent to send raw credentials and for scenarios where it isn=92t = possible. To illustrate an example where username/pwd isn=92t viable, consi= der the case of a client that needs to use an enterprise identity to gain access to a cloud service. In many c= ases, corporate policy demands that a client use an identity managed by the= organization. This means that the client should obtain an assertion from a= n enterprise identity provider (Active Directory, Tivoli, etc.) and use that assertion to obtain an access token = which grants access to various web service APIs. Many of our key MSFT custo= mers and internal partner teams rely on this mechanism and reverting exclus= ively to username/pwd isn=92t an option for us.

=20

=A0

=20

'OAuth2' HTTP Authentication Scheme:=A0 Simply put, dropp= ing this seems like a huge step away from interoperability.=A0 As one data = point, Microsoft implements this in our WIF OAuth2 protected resource code.= =A0 All up, clients need a way to authenticate to the protected resource.=A0 Also, existing WRAP implemen= tations need this functionality to migrate to OAuth2.=A0=A0 For all these r= easons, we support retaining this functionality in OAuth2.

=20

=A0

=20

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks,

=20

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

=20

=A0

=20
=20

-----Inline Attachment Follows-----

_____= __________________________________________
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


--90e6ba211f293c23e3049a4ecf33-- From phil.hunt@oracle.com Thu Jan 20 14:48:21 2011 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 DAA443A685B for ; Thu, 20 Jan 2011 14:48:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 NNhXW7ZhBb3K for ; Thu, 20 Jan 2011 14:48:20 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id B276D3A6846 for ; Thu, 20 Jan 2011 14:48:20 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0KMp04D030197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 22:51:02 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0KMG8ag014495; Thu, 20 Jan 2011 22:51:00 GMT Received: from abhmt002.oracle.com by acsmt353.oracle.com with ESMTP id 979172581295563848; Thu, 20 Jan 2011 14:50:48 -0800 Received: from dhcp-rmdc-twvpn-1-vpnpool-10-159-28-250.vpn.oracle.com (/10.159.28.250) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jan 2011 14:50:47 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Thu, 20 Jan 2011 14:50:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1989C58C-5F31-4AC2-91B6-15312C3B73AE@oracle.com> To: Marius Scurtescu X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 22:48:22 -0000 I don't think this is a case of providing alternative methods. It is = just a case of allowing ANY method that the Authentication server deems = sufficient. Kerberos, SAML, SSO token, basic auth, mutual SSL, etc. Thus you don't need to put specific authentication methods in the spec = other than to simply REQUIRE that the client be authenticated -- either = inbound with the POST as you suggest or OOB during a previous exchange. It may be a good idea to define one mandatory to implement methodology, = but to define more than one suggests limiting authentication approaches = to specific methods. I don't think this is the intent here. Phil phil.hunt@oracle.com On 2011-01-20, at 2:28 PM, Marius Scurtescu wrote: > On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt = wrote: >> The client does need to know how to authenticate. But given that it = already has to know a lot about the service, you would think acceptable = authentication types are well known to the client. >=20 > Yes, true. >=20 >=20 >> What is the problem with the client authenticating like any normal = web service client? (IE outside of oauth) >>=20 >> Why involve oauth in any authentication for User or client? >=20 > What is a normal web service client? Since the client has to POST a > bunch of parameters as form encoded, it is simpler to also send > authentication parameters there. Providing alternate methods of > authentication is just asking for trouble. Of course, the spec could > require that authentication is only sent through some other method, > but I think it is way too late for such a change. >=20 >=20 > Marius From phil.hunt@oracle.com Thu Jan 20 14:55:17 2011 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 55B5F3A686C for ; Thu, 20 Jan 2011 14:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 H1Qf+6fJFSCM for ; Thu, 20 Jan 2011 14:55:16 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 092B13A686B for ; Thu, 20 Jan 2011 14:55:15 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0KMvuYw012401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 20 Jan 2011 22:57:57 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0KMvsDH004603; Thu, 20 Jan 2011 22:57:56 GMT Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 941217881295564275; Thu, 20 Jan 2011 14:57:55 -0800 Received: from dhcp-rmdc-twvpn-1-vpnpool-10-159-28-250.vpn.oracle.com (/10.159.28.250) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Jan 2011 14:57:55 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: Date: Thu, 20 Jan 2011 14:57:56 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5CC12A20-A4ED-426A-BC4E-C36DAC8C514B@oracle.com> References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1989C58C-5F31-4AC2-91B6-15312C3B73AE@oracle.com> To: Phil Hunt X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 20 Jan 2011 22:55:17 -0000 Sorry, typo ... see clarification below.=20 Phil phil.hunt@oracle.com On 2011-01-20, at 2:50 PM, Phil Hunt wrote: > I don't think this is a case of providing alternative methods. It is = just a case of allowing ANY method that the Authentication server deems = sufficient. Kerberos, SAML, SSO token, basic auth, mutual SSL, etc. >=20 > Thus you don't need to put specific authentication methods in the spec = other than to simply REQUIRE that the client be authenticated -- either = inbound with the POST as you suggest or handled OOB (SSL mutual, SSO token etc). >=20 > It may be a good idea to define one mandatory to implement = methodology, but to define more than one suggests limiting = authentication approaches to specific methods. I don't think this is the = intent here. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-01-20, at 2:28 PM, Marius Scurtescu wrote: >=20 >> On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt = wrote: >>> The client does need to know how to authenticate. But given that it = already has to know a lot about the service, you would think acceptable = authentication types are well known to the client. >>=20 >> Yes, true. >>=20 >>=20 >>> What is the problem with the client authenticating like any normal = web service client? (IE outside of oauth) >>>=20 >>> Why involve oauth in any authentication for User or client? >>=20 >> What is a normal web service client? Since the client has to POST a >> bunch of parameters as form encoded, it is simpler to also send >> authentication parameters there. Providing alternate methods of >> authentication is just asking for trouble. Of course, the spec could >> require that authentication is only sent through some other method, >> but I think it is way too late for such a change. >>=20 >>=20 >> Marius >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jan 20 16:35:11 2011 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 4FEBC3A6884 for ; Thu, 20 Jan 2011 16:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 d5DuSSzvi4Dc for ; Thu, 20 Jan 2011 16:35:09 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 95CCA3A6878 for ; Thu, 20 Jan 2011 16:35:08 -0800 (PST) Received: (qmail 10636 invoked from network); 21 Jan 2011 00:37:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 21 Jan 2011 00:37:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 20 Jan 2011 17:37:51 -0700 From: Eran Hammer-Lahav To: "Richer, Justin P." , OAuth WG Date: Thu, 20 Jan 2011 17:37:43 -0700 Thread-Topic: OAuth MAC token type draft Thread-Index: AcuwIP0QyZaR42yQR/6NQvmBuI0wlQAFPiiFAAHUBGAAI9vpLQINqy/Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB72B1@P3PW5EX1MB01.EX1.SECURESERVER.NET> , <90C41DD21FB7C64BB94121FBBC2E723445A5AB72D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth MAC token type draft 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, 21 Jan 2011 00:35:11 -0000 Please let me know if -01 addresses your concerns. EHL > -----Original Message----- > From: Richer, Justin P. [mailto:jricher@mitre.org] > Sent: Monday, January 10, 2011 5:46 AM > To: Eran Hammer-Lahav; OAuth WG > Subject: RE: OAuth MAC token type draft >=20 > Right -- if you substitute "token" with "client id" and "token secret" wi= th > "client secret", then you've got the makings for 2-legged OAuth 2.0 right > there. I think you should call out that use case explicitly in your draft= . >=20 > -- Justin > ________________________________________ > From: Eran Hammer-Lahav [eran@hueniverse.com] > Sent: Sunday, January 09, 2011 3:39 PM > To: Richer, Justin P.; OAuth WG > Subject: RE: OAuth MAC token type draft >=20 > Well, you need the token as the identifier of the secret being used. So i= f you > think of a token as an 'id', then it works as is. >=20 > EHL >=20 > > -----Original Message----- > > From: Richer, Justin P. [mailto:jricher@mitre.org] > > Sent: Sunday, January 09, 2011 11:47 AM > > To: Eran Hammer-Lahav; OAuth WG > > Subject: RE: OAuth MAC token type draft > > > > I'd like to see a way to use this mechanism without tokens -- that is, > > the traditional two-legged signed-http-fetch approach. Maybe have the > > spec here give details of a method using pre-shared client secrets > > instead of OAuth tokens would be all it'd take. > > > > -- Justin > > > > ________________________________________ > > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of > > Eran Hammer-Lahav [eran@hueniverse.com] > > Sent: Sunday, January 09, 2011 12:18 PM > > To: OAuth WG > > Subject: [OAUTH-WG] OAuth MAC token type draft > > > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token > > > > Feedback appreciated, especially for section 3.2.1 (the new normalized > > request string) which is an attempt to take the HMAC-SHA1 flow from > > 1.0a and simplify it. > > > > No body signature support yet, but will add that in -01. > > > > EHL From Internet-Drafts@ietf.org Thu Jan 20 16:45:02 2011 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 B5FB43A6890; Thu, 20 Jan 2011 16:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, 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 cwEpCf+wCfxW; Thu, 20 Jan 2011 16:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD343A6858; Thu, 20 Jan 2011 16:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110121004501.28103.96097.idtracker@localhost> Date: Thu, 20 Jan 2011 16:45:01 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 21 Jan 2011 00:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Authorization Protocol Author(s) : E. Hammer-Lahav, et al. Filename : draft-ietf-oauth-v2-12.txt Pages : 46 Date : 2011-01-20 This specification describes the OAuth 2.0 authorization protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-20163254.I-D@ietf.org> --NextPart-- From eran@hueniverse.com Thu Jan 20 16:54:17 2011 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 7AC2A3A688C for ; Thu, 20 Jan 2011 16:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 uEVV8R8VAgqj for ; Thu, 20 Jan 2011 16:54:16 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 63D803A6858 for ; Thu, 20 Jan 2011 16:54:16 -0800 (PST) Received: (qmail 17209 invoked from network); 21 Jan 2011 00:57:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Jan 2011 00:57:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 20 Jan 2011 17:56:58 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 20 Jan 2011 17:56:50 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu5BNSqQ9Z1WAYcQz6B5nxMzQt51AAAHbFw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> In-Reply-To: <20110121004501.28103.96097.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 21 Jan 2011 00:54:17 -0000 Draft -12 is finally out. This is almost a complete rewrite of the entire document, with the primary = goal of moving it back to a similar structure used in -05. I have been thin= king about this for a few months and finally came up with a structure that = combines the two approaches. The draft includes some major cleanups, significantly simpler language, red= uces repeated prose, and tried to keep prose to the introduction and normat= ive language in the rest of the specification. I took out sections that bro= ke the flow, and did my best to give this a linear narrative that is easy t= o follow. The draft includes the following normative changes: o Clarified 'token_type' as case insensitive. o Authorization endpoint requires TLS when an access token is issued. o Removed client assertion credentials, mandatory HTTP Basic authentica= tion support for client credentials, WWW-Authenticate header, and the OAuth= 2 authentication scheme. o Changed implicit grant (aka user-agent flow) error response from quer= y to fragment. o Removed the 'redirect_uri_mismatch' error code since in such a case, = the authorization server must not send the error back to the client. o Defined access token type registry. I would like to spend the coming week receiving and applying feedback befor= e requesting a WGLC for everything but the security considerations section = (missing) 2/1. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Thursday, January 20, 2011 4:45 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Open Authentication Protocol Working Gro= up > of the IETF. >=20 >=20 > Title : The OAuth 2.0 Authorization Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-12.txt > Pages : 46 > Date : 2011-01-20 >=20 > This specification describes the OAuth 2.0 authorization protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. From fcorella@pomcor.com Thu Jan 20 21:09:13 2011 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 F28E63A68BB for ; Thu, 20 Jan 2011 21:09:12 -0800 (PST) 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 sD05gWLSePsJ for ; Thu, 20 Jan 2011 21:09:11 -0800 (PST) Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by core3.amsl.com (Postfix) with SMTP id 1BF0B3A68B7 for ; Thu, 20 Jan 2011 21:09:10 -0800 (PST) Received: from [98.139.52.191] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 21 Jan 2011 05:11:53 -0000 Received: from [98.139.52.138] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 21 Jan 2011 05:11:53 -0000 Received: from [127.0.0.1] by omp1021.mail.ac4.yahoo.com with NNFMP; 21 Jan 2011 05:11:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 39780.95447.bm@omp1021.mail.ac4.yahoo.com Received: (qmail 97584 invoked by uid 60001); 21 Jan 2011 05:11:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295586712; bh=CBO9NSdnbApXE1HDs44jqfbOxobT8I93EoEl1Qc6mVs=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=XdKrFYXbxdZhj/1C12WfcxfZWAauoddP5JUMnjS8vVKkQm2i6PGWGE70jR3zW0xkl5XlhRdK4TYffIGqyENrxU17HUfiHidmc4N0legz7p5cd/rBN9PEU3/5nFQq0VC3UT4im8MR0AHekjcI7vnbj1SVEe5z0peNST0f1ZvNHmM= Message-ID: <900056.97405.qm@web55805.mail.re3.yahoo.com> X-YMail-OSG: nYQ9658VM1kechzAAM_yZayksLuCRY.NpuzsfBMOwT7LanY VCUoky87coLpcfYoc.cSAskSNoPdjds8LdvZueFCavzstwbQG.MG6.Q_R.WE UaE7BXmc0IXCMmWY2Tjn3eKbG8TTxeyXErZ5Al1KysA9pSiBgn6PaHUzisZj EjadxEwos0Gf96l3YY3QkV4VmFRJDe9NrXfqb_Nlj91KGIl0Hg71Jwk3U6jb PK39JSTscIHryKZcNsx3k4NsF.XZz6XtNa_o62WdJsCh7HdSNZwJ08yWo_18 23ZrtiuIndGVaYvB_g1n3zkfU2ROJVqec_dvn4GxJ9BBhNsV.ghkImONRd8V QD00T Received: from [173.198.123.207] by web55805.mail.re3.yahoo.com via HTTP; Thu, 20 Jan 2011 21:11:52 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Thu, 20 Jan 2011 21:11:52 -0800 (PST) From: Francisco Corella To: Brian Campbell In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-674392381-1295586712=:97405" Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jan 2011 05:09:13 -0000 --0-674392381-1295586712=:97405 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian, Thank you for pointing me to the SAML Bearer Assertion Grant Type Profile.= =C2=A0 I understand now.=C2=A0 Maybe the spec would be clearer if it said t= hat the client assertion is a bearer assertion. Francisco --- On Thu, 1/20/11, Brian Campbell wrote: From: Brian Campbell Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme To: fcorella@pomcor.com Cc: "Eran Hammer-Lahav" , "Mike Jones" , "oauth@ietf.org" , "Karen P. Lewison" Date: Thursday, January 20, 2011, 10:39 PM Francisco, While a proper profiling of subject confirmation is generally needed for a = secure/interoperable SAML exchange, it's worth noting that assertions as us= ed in OAuth (client assertions or URI/assertion grant types) are not necess= arily SAML assertions.=C2=A0 The term assertion is used more generally.=C2= =A0 To be honest, I think token might have been be a less confusing term to= use in place of assertion in the framework spec.=C2=A0 But token is widely= used in other contexts thought out the framework spec too.=C2=A0 So I dunn= o, maybe that would be even more confusing. =0A=0A If you are interested/knowledgeable about SAML subject confirmation, please= feel free to review and comment on the SAML Bearer Assertion Grant Type Pr= ofile: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00=C2=A0 :) =0A=0A -Brian =0A On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella wr= ote: =0A=0A=0AMike, As assertion use is described in the spec, a client assertion does not prov= ide any security whatsoever.=C2=A0 How do you handle subject confirmation i= n your implementation?=C2=A0 (See section 2.4.1.1 of the SAML specification= .)=C2=A0 In other words, how does the authorization server know that the cl= ient sending the assertion is actually the subject of the assertion? =0A=0A=0A Francisco --- On Tue, 1/18/11, Mike Jones wrote: =0A=0A=0A From: Mike Jones Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and = OAuth2 HTTP Authentication Scheme =0A=0A=0ATo: "Eran Hammer-Lahav"=0A Cc: "oauth@ietf.org" =0A=0A=0ADate: Tuesday, January 18, 2011, 5:35 PM =0A=0A =0A =0A=0A=0AHaving spoken to a number of people implementing the sp= ec here, I=E2=80=99ve encountered strong objections to removing Client Asse= rtion Credentials and the OAuth2 HTTP Authentication Scheme. =C2=A0It=E2=80= =99s also not clear to me why we would make substantial=0A breaking changes= to the specification when it is essentially ready for approval.=C2=A0 I=E2= =80=99ve summarized the reasons I believe we should keep these two features= below. =0A =0AClient Assertion Credentials:=C2=A0 Many of the scenarios we= care about require this capability. They were key motivators for the Asser= tion Profile in WRAP (see =C2=A7 5.2), have been part of OAuth 2 for quite = a while, and we have running=0A code that requires this support. For exampl= e, the Azure Access Control Service is a cloud Authorization server that su= pports several protocols, including parts of OAuth 2.0 draft 10 (autonomous= and web server profiles). We are happy to update our implementation=0A to = subsequent drafts & agree that the spec leaves a lot of ambiguity. =0A =0AI= n our implementation of the autonomous and web server profiles, ACS allows = clients to authenticate using a signed assertion as well as with a username= /password. The username/pwd option is for clients that don=E2=80=99t mind s= ending credentials=0A over the wire, while the signed assertion mechanism i= s for clients that are more reticent to send raw credentials and for scenar= ios where it isn=E2=80=99t possible. To illustrate an example where usernam= e/pwd isn=E2=80=99t viable, consider the case of a client that needs=0A to = use an enterprise identity to gain access to a cloud service. In many cases= , corporate policy demands that a client use an identity managed by the org= anization. This means that the client should obtain an assertion from an en= terprise identity provider (Active=0A Directory, Tivoli, etc.) and use that= assertion to obtain an access token which grants access to various web ser= vice APIs. Many of our key MSFT customers and internal partner teams rely o= n this mechanism and reverting exclusively to username/pwd isn=E2=80=99t an= option=0A for us. =0A =C2=A0 =0A'OAuth2' HTTP Authentication Scheme:=C2=A0= Simply put, dropping this seems like a huge step away from interoperabilit= y.=C2=A0 As one data point, Microsoft implements this in our WIF OAuth2 pro= tected resource code.=C2=A0 All up, clients need a way=0A to authenticate t= o the protected resource.=C2=A0 Also, existing WRAP implementations need th= is functionality to migrate to OAuth2.=C2=A0=C2=A0 For all these reasons, w= e support retaining this functionality in OAuth2. =0A =C2=A0 =0A=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Thanks, =0A=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -- Mike =0A =C2=A0 =0A=0A =0A -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org =0A=0A=0Ahttps://www.ietf.org/mailman/listinfo/oauth _______________________________________________ =0A=0A=0A=0AOAuth mailing list =0AOAuth@ietf.org =0Ahttps://www.ietf.org/mailman/listinfo/oauth =0A =0A --0-674392381-1295586712=:97405 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <= tr>=
Brian,

Thank you for pointing me to th= e SAML Bearer Assertion Grant Type Profile.  I understand now.  M= aybe the spec would be clearer if it said that the client assertion is a be= arer assertion.

Francisco

--- On Thu, 1/20/11, Brian Campb= ell <bcampbell@pingidentity.com> wrote:

From: Brian Campbell <bcampbell@pingidentity.com>
Su= bject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials an= d OAuth2 HTTP Authentication Scheme
To: fcorella@pomcor.com
Cc: "Eran= Hammer-Lahav" <eran@hueniverse.com>, "Mike Jones" <Michael.Jones@= microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>, "Karen P. Lewis= on" <kplewison@pomcor.com>
Date: Thursday, January 20, 2011, 10:39 PM

Francisco,

While a proper profil= ing of subject confirmation is generally needed for a secure/interoperable = SAML exchange, it's worth noting that assertions as used in OAuth (client a= ssertions or URI/assertion grant types) are not necessarily SAML assertions= .  The term assertion is used more generally.  To be honest, I th= ink token might have been be a less confusing term to use in place of asser= tion in the framework spec.  But token is widely used in other context= s thought out the framework spec too.  So I dunno, maybe that would be= even more confusing.
=0A=0A
If you are interested/knowledgeable abou= t SAML subject confirmation, please feel free to review and comment on the = SAML Bearer Assertion Grant Type Profile: h= ttp://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00  :)
= =0A=0A
-Brian
=0A
On Tue, J= an 18, 2011 at 1:26 PM, Francisco Corella <fcorella@pomcor.com> wro= te:
Mike,

As assertion us= e is described in the spec, a client assertion does not provide any securit= y whatsoever.  How do you handle subject confirmation in your implemen= tation?  (See section 2.4.1.1 of the SAML specification.)  In other words, how does the authoriza= tion server know that the client sending the assertion is actually the subj= ect of the assertion?
=0A=0A=0A
Francisco

--- On Tue, 1/18/= 11, Mike Jones <Michael.Jones@microsoft.com> wrote:
=0A=0A=0A
From: Mike Jones <Michael.Jones@microsoft.com>Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials an= d OAuth2 HTTP Authentication Scheme
=0A=0A=0ATo: "Eran Hammer-Lahav"=0A = <eran@hueniverse.com= >
Cc: "oauth@ietf.org" &l= t;oauth@ietf.org>
=0A=0A=0A= Date: Tuesday, January 18, 2011, 5:35 PM


= =0A=0A =0A =0A=0A
=0A

Having spoken to a number of people implementin= g the spec here, I=E2=80=99ve encountered strong objections to removing Cli= ent Assertion Credentials and the OAuth2 HTTP Authentication Scheme.  = It=E2=80=99s also not clear to me why we would make substantial=0A breaking= changes to the specification when it is essentially ready for approval.&nb= sp; I=E2=80=99ve summarized the reasons I believe we should keep these two = features below.

=0A

=0A

Client Assertion Credentials:&n= bsp; Many of the scenarios we care about require this capability. They were= key motivators for the Assertion Profile in WRAP (see =C2=A7 5.2), have be= en part of OAuth 2 for quite a while, and we have running=0A code that requ= ires this support. For example, the Azure Access Control Service is a cloud= Authorization server that supports several protocols, including parts of O= Auth 2.0 draft 10 (autonomous and web server profiles). We are happy to upd= ate our implementation=0A to subsequent drafts & agree that the spec le= aves a lot of ambiguity.

=0A

=0A

In our implementation of the = autonomous and web server profiles, ACS allows clients to authenticate usin= g a signed assertion as well as with a username/password. The username/pwd = option is for clients that don=E2=80=99t mind sending credentials=0A over t= he wire, while the signed assertion mechanism is for clients that are more = reticent to send raw credentials and for scenarios where it isn=E2=80=99t p= ossible. To illustrate an example where username/pwd isn=E2=80=99t viable, = consider the case of a client that needs=0A to use an enterprise identity t= o gain access to a cloud service. In many cases, corporate policy demands t= hat a client use an identity managed by the organization. This means that t= he client should obtain an assertion from an enterprise identity provider (= Active=0A Directory, Tivoli, etc.) and use that assertion to obtain an acce= ss token which grants access to various web service APIs. Many of our key M= SFT customers and internal partner teams rely on this mechanism and reverti= ng exclusively to username/pwd isn=E2=80=99t an option=0A for us.

=0A  

=0A

'OAuth2' HTTP Authentication Scheme:  Simply= put, dropping this seems like a huge step away from interoperability. = ; As one data point, Microsoft implements this in our WIF OAuth2 protected = resource code.  All up, clients need a way=0A to authenticate to the p= rotected resource.  Also, existing WRAP implementations need this func= tionality to migrate to OAuth2.   For all these reasons, we suppo= rt retaining this functionality in OAuth2.

=0A

 

=0A

&nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;         Thanks,

=0A

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

=0A

 <= /p> =0A

=0A =0A

-----Inline Attachment Follows---= --

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

_______________________________________________
=0A= =0A=0A=0AOAuth mailing list
=0AOAu= th@ietf.org
=0Ahttps://www.ietf.org/mailman/listinfo= /oauth
=0A

=0A
--0-674392381-1295586712=:97405-- From eran@hueniverse.com Thu Jan 20 21:35:56 2011 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 9FB723A68B3 for ; Thu, 20 Jan 2011 21:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 OfJ5x1lNHqNc for ; Thu, 20 Jan 2011 21:35:54 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E91633A68B0 for ; Thu, 20 Jan 2011 21:35:53 -0800 (PST) Received: (qmail 28965 invoked from network); 21 Jan 2011 05:38:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Jan 2011 05:38:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 20 Jan 2011 22:38:37 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 20 Jan 2011 22:38:24 -0700 Thread-Topic: [OAUTH-WG] redirect URI matching in section 3 Thread-Index: AcsgxIDHUqmnd6gLSpGN7WcOW8wZsyYaNyeQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] redirect URI matching in section 3 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, 21 Jan 2011 05:35:56 -0000 Whoever is working on the security considerations section, please add this = to your list. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Brian Eaton > Sent: Saturday, July 10, 2010 11:44 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] redirect URI matching in section 3 >=20 > Section 3 says [[ provide guidance on how to perform matching ]]. >=20 > I can write the guidance on performing redirect URI matching, but it vari= es > per profile. >=20 > User-Agent profile with registered client: matching is critical, MUST ver= ify is > appropriate >=20 > Web server profile with client secret you trust: matching is not critical= . > Matching provides some extra security. MAY is appropriate. > MUST is really bad, since it prevents clients from moving redirect URIs. >=20 > Any profile where you don't trust the client secret (e.g. installed > apps): Redirect URI matching is useless. SHOULD NOT is appropriate. >=20 > So this is another case where the client needs to pass some indicator to = the > server (either via type=3D parameter, or as policy associated with client= _id) of > the environment in which it is running. The type parameter needs to sign= al: > - how the authorization server passes data (fragment or query string) > - what data is passed (access token, or just verification code) >=20 > Here's some proposed language on redirect URI matching. >=20 > New Section 3.1: Overview of Callback URL Authentication >=20 > The OAuth 2 protocol distributes authorization credentials to web-based > applications by redirecting the user-agent to the client with some form o= f > authorization credential on the URL. The authorization credential is eit= her an > access token, or a authorization code. In either case, authenticating th= e URL > to which the credential is returned is critical to the security of the pr= otocol. >=20 > Credentials returned on redirect URLs may leak in several ways: > - Referer headers sent by the browser to untrusted third-party web sites > - open redirectors > - web server log files > - browser history >=20 > Authorization servers have several techniques available for authenticatin= g > callback URLs and defending against those leaks: > - using client authentication credentials to authenticate callback URLs > - callback URL white-listing > - passing authorization credentials on URI fragments > - issuing short-lived credentials to ease recovery in the event of compro= mise >=20 > 3.1.1 Authorization Policy >=20 > In certain circumstances the Authorization Server is not able to perfectl= y > authenticate the callback URL. For example, multiple installed applicati= ons > may use the same callback URL, and there is no way for the Authorization > Server to reliably distinguish among them. > Authorization Servers deal with this ambiguity by choosing different poli= cies > on when to issue authorization credentials. >=20 > If the authorization server is able to authenticate the callback URL with= a high > degree of confidence > - the authorization server MAY decline to prompt the user to grant > authorization, immediately rejecting the authorization request. > - the authorization server MAY issue an authorization credential after > prompting the user. > - the authorization server MAY issue a new authorization credential witho= ut > prompting the user, if the authorization server knows that the user has > previously approved this client. >=20 > If the authorization server is not able to authenticate the callback URL: > - the authorization server MAY decline to prompt the user to grant > authorization, immediately rejecting the authorization request. > - the authorization server MAY issue an authorization credential after > prompting the user. > - the authorization server MUST NOT issue an authorization credential > without prompting the user. >=20 > 3.1.2 Callback URL Authentication Techniques >=20 > Client Credentials MAY be used to authenticate callback URLs. If an > Authorization Server wishes to authenticate callback URLs with client > credentials, all of the following conditions MUST be met: >=20 > - the client credentials MUST have been issued to a web application with = a > server-side component. > - the Authorization Server MUST believe that the client credentials are s= tored > securely. > - the Authorization Server MUST return only an authorization code to the > callback URL. An access token MUST NOT be returned. >=20 > In all other circumstances, the Authorization Server MUST use callback UR= L > white-listing to authenticate callback URLs. However, appropriate callba= ck > URL white-listing varies for different client environments. >=20 > There are various techniques for callback URL white-listing. The list in= this > document is not exhaustive, and Authorization Servers MAY implement > other techniques at their discretion. This document will consider the > following approaches: >=20 > - domain white-listing > Authorization Servers white-list entire domains, e.g. > '*.example.com'. Authorization servers may include the protocol in this > white-list, e.g. 'all https web sites on *.example.com'. Any page on any= host > in that domain is accepted. >=20 > - host white-listing > Authorization Servers white-list entire hosts, e.g. > 'www.example.com'. Authorization servers may include the protocol in the > white-list, e.g. 'https://www.example.com'. Any page on that host is > accepted. >=20 > - path white-listing > Authorization Servers white-list specific paths on a particular host, = e.g. > 'https://www.example.com/path'. Any page beneath that path is accepted. >=20 > - page white-listing > Authorization Servers white-list a specific page on a particular host,= e.g. > 'https://www.example.com/path/page'. The query string and URI fragment > may vary, but all other components of the URL are fixed and must match th= at > page. >=20 > - full URL white-listing > Authorization Servers white-list a specific URL, e.g. > 'https://www.example.com/path/page?query'. Any callback URL that does > not completely match that URL is rejected. >=20 >=20 > The following sections offer guidance to Authorization Servers and Client > developers on how to handle callback URL authentication. For better > security, Authorization Servers and Clients should rely on a combination = of > client credentials and callback URL white-listing to authenticate callbac= k URLs. >=20 >=20 > Section 3.1.3 Secure Callback URLs for the Web Server Profile >=20 > Client application developers using the web server profile should take ca= re > that their callback URLs preserve the security of the profile. >=20 > Callback URL pages MUST NOT link or or redirect to untrusted content from > those pages, since the authorization code may leak in the referer header. >=20 > Callback URL pages MUST NOT forward the authorization code to an > untrusted page. >=20 > Callback URL pages SHOULD redirect to a trusted page immediately after > receiving the authorization code in the URL. This prevents the authoriza= tion > code from remaining in the browser history, or from inadvertently leaking= in > a referer header. >=20 > Callback URL pages SHOULD NOT log the authorization code. >=20 > Callback URL pages SHOULD be CSRF protected. (TODO: dig up the language > in OAuth 1.0a, it was pretty good, I think...) >=20 >=20 >=20 > Section 3.1.4 Callback URL Authentication for the Web Server Profile >=20 > The web server profile returns an authorization code on the callback URL. > Authorization codes returned on callback URLs are very prone to leaking i= n > referer headers, open redirectors, web server log files, and browser hist= ory. >=20 > Authorization Servers MAY omit callback URL white-listing, but only if th= ey > are using client credentials to authenticate callback URLs. If client cr= edentials > are being used, any type of callback URL white-listing will improve secur= ity. >=20 > Different types of white-listing provide different levels of security. >=20 > - domain- and host- whitelisting > Domain and host white-listing rules are very broad, and so are very > vulnerable to the leaks discussed in section 3.1. Domain- and host- whit= e- > listing MUST NOT be used alone. Domain and host white-listing MAY be use= d > in combination with using client credentials to authenticate callback URL= s. >=20 > - path white-listing > Path white-listing is somewhat broad, and may be vulnerable to the lea= ks > discussed in section 3.1. Path white-listing MUST NOT be used alone. Pa= th > white-listing MAY be used in combination with using client credentials to > authenticate callback URLs. > When using path white-listing, Authorization servers MUST defend agai= nst > directory traversal attacks by canonicalizing the path. > Appropriate path canonicalization algorithms vary for different types of = web- > servers, e.g. "\..\" may represent a parent directory in some web servers= , > and not in others. >=20 > - page and URL white-listing > Page and URL white-listing are very specific, but may still be vulnera= ble to > some of the leaks discussed in section 3.1 if the callback URL page does = not > follow the security recommendations in section 3.1.3. These types of whi= te- > listing MAY be used alone, or in combination with client credentials to > authenticate callback URLs. >=20 > When full URL white-listing is used, Authorization Servers MUST allow = the > "state" query parameter to vary. >=20 >=20 > Section 3.1.4 Secure Callback URLs for the User-Agent Profile >=20 > Client application developers using the user-agent profile should take ca= re > that their callback URLs preserve the security of the profile. > Because the user-agent profile returns an access token on the URI fragmen= t, > many types of leaks are less likely. However, incorrect code can still l= eak the > authorization credentials. >=20 > Callback URL pages MUST NOT forward the access token or authorization > code to an untrusted page. >=20 > Callback URLs rendered in a top-level browser window cannot prevent the > access token from remaining in the browser history. Whenever possible, > client applications SHOULD use an iframe to receive callbacks so that the > access token does not appear in the browser history. [[Note that > Authorization Servers SHOULD NOT allow their approval pages to be iframed > due to the risk of click-jacking attacks, > so this only works for immediate mode. Browser security gets > complicated.]] >=20 > If callback URLs must be rendered in a top-level browser window, client > applications SHOULD redirect immediately after receiving the > callback URL to remove the access token from the URL bar. This > prevents the user from inadvertently copying their access token. >=20 > Callback URL pages SHOULD be CSRF protected. (TODO: dig up the language > in OAuth 1.0a, it was pretty good, I think...) >=20 >=20 > Section 3.1.4 Callback URL Authentication for the User-Agent profile >=20 > Because the user-agent profile returns an access token on the callback UR= L, > client credentials cannot be used to authenticate the callback URL. Call= back > URL white-listing is the only possible way to authenticate the callback U= RL. > However, because the authorization credentials are always returned on the > URL fragment, the opportunity for leaking credentials via referer headers > and open redirectors is reduced. >=20 > Different types of white-listing provide different levels of security. >=20 > - domain- white-listing > Domain white-listing is very broad. Domain white-listing MUST NOT be > used, because of the risk of malicious code running under some host in th= e > domain. >=20 > - host- white-listing > Host white-listing is very broad. Authorization servers should be > conservative in choosing which hosts they trust, but host white-listing M= AY > be used. >=20 > - path white-listing > Path white-listing is somewhat broad. Path white-listing MAY be used. > When using path white-listing, Authorization servers MUST defend agai= nst > directory traversal attacks by canonicalizing the path. > Appropriate path canonicalization algorithms vary for different types of = web- > servers, e.g. "\..\" may represent a parent directory in some web servers= , > and not in others. >=20 > - page and URL white-listing > Page and URL white-listing are very specific. These types of white-lis= ting > MAY be used >=20 > When full URL white-listing is used, Authorization Servers MUST allow t= he > "state" query parameter to vary. >=20 > Cheers, > Brian > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Thu Jan 20 21:39:13 2011 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 13D523A68B3 for ; Thu, 20 Jan 2011 21:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 yhWQhOX30XsH for ; Thu, 20 Jan 2011 21:39:12 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id F0CAC3A68BA for ; Thu, 20 Jan 2011 21:39:11 -0800 (PST) Received: (qmail 600 invoked from network); 21 Jan 2011 05:41:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Jan 2011 05:41:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 20 Jan 2011 22:41:56 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Thu, 20 Jan 2011 22:41:48 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu5BNSqQ9Z1WAYcQz6B5nxMzQt51AAAHbFwAAobE7A= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 21 Jan 2011 05:39:13 -0000 Forgot to mention that I don't have any outstanding comments in my queue so= if your feedback was not incorporated into -12, and you feel strongly abou= t it, bring it up again. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Thursday, January 20, 2011 4:57 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > Draft -12 is finally out. >=20 > This is almost a complete rewrite of the entire document, with the primar= y > goal of moving it back to a similar structure used in -05. I have been th= inking > about this for a few months and finally came up with a structure that > combines the two approaches. >=20 > The draft includes some major cleanups, significantly simpler language, > reduces repeated prose, and tried to keep prose to the introduction and > normative language in the rest of the specification. I took out sections = that > broke the flow, and did my best to give this a linear narrative that is e= asy to > follow. >=20 > The draft includes the following normative changes: >=20 > o Clarified 'token_type' as case insensitive. > o Authorization endpoint requires TLS when an access token is issued. > o Removed client assertion credentials, mandatory HTTP Basic > authentication support for client credentials, WWW-Authenticate header, > and the OAuth2 authentication scheme. > o Changed implicit grant (aka user-agent flow) error response from qu= ery > to fragment. > o Removed the 'redirect_uri_mismatch' error code since in such a case= , the > authorization server must not send the error back to the client. > o Defined access token type registry. >=20 > I would like to spend the coming week receiving and applying feedback > before requesting a WGLC for everything but the security considerations > section (missing) 2/1. >=20 > EHL >=20 >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Internet-Drafts@ietf.org > > Sent: Thursday, January 20, 2011 4:45 PM > > To: i-d-announce@ietf.org > > Cc: oauth@ietf.org > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Open Authentication Protocol Working > > Group of the IETF. > > > > > > Title : The OAuth 2.0 Authorization Protocol > > Author(s) : E. Hammer-Lahav, et al. > > Filename : draft-ietf-oauth-v2-12.txt > > Pages : 46 > > Date : 2011-01-20 > > > > This specification describes the OAuth 2.0 authorization protocol. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet- Draft. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From pflam@cs.stanford.edu Fri Jan 21 00:27:53 2011 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 91FBA3A68F0 for ; Fri, 21 Jan 2011 00:27:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.867 X-Spam-Level: X-Spam-Status: No, score=-5.867 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, 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 4dv9ouzwWoEb for ; Fri, 21 Jan 2011 00:27:51 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id B298A3A68E4 for ; Fri, 21 Jan 2011 00:27:51 -0800 (PST) Received: from secllab.stanford.edu ([171.64.65.88] helo=css-macbook-pro-9.local) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1PgCOB-00073u-Re; Fri, 21 Jan 2011 00:30:36 -0800 Message-ID: <4D39442B.2090408@cs.stanford.edu> Date: Fri, 21 Jan 2011 00:30:35 -0800 From: Eric User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav , "oauth@ietf.org" Content-Type: multipart/alternative; boundary="------------070800090208060203040002" X-Scan-Signature: fa98ac227168b5e907bebab69d011ac6 Subject: Re: [OAUTH-WG] validate authorization code in draft 12 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, 21 Jan 2011 08:27:53 -0000 This is a multi-part message in MIME format. --------------070800090208060203040002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eran, and others, A few of us had some discussions on the authorization code flow, as depicted in Fig. 3 of the current (12th) draft. We think that it is probably worthwhile to suggest in the specification that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the Authorization Server (AS). From what we have heard, this has been done in some of the current OAuth deployments. There are other people who do not think this is such a big security risk, although so far no one has objected that there is some risk here. The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise : 1. Cost magnification: the attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the AS; and he can co-ordinate the timing of such HTTPS connections across multiple clients relatively easily, if these clients blindly connect to the AS without first validating the authorization codes received. Although the attacker could achieve something similar, say by including an iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure web users to visit that page, timing attacks using such a scheme is (say for the purpose of DDoS) more difficult . 2. Connection laundering: if the AS realizes it is flooded by HTTPS connections with illegitimate codes, it collects no useful information about the attacker, since the clients act as relays. 3. CSRF defense/the 'state' parameter don't completely address this problem. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/ state parameter. This does cut down the effectiveness of the attack by a factor of 2, which is good. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency.html), the attacker still achieves a cost magnification. Our proposal is that the OAuth specification suggests that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the Authorization Server (AS). The specifics of how to validate the authorization code may not need to be part of the core specification. We sketch a design below for consideration for future implementation. It might be reasonable to assume that OAuth implementations provide some API for the client to call to validate and send the authorization code to the AS. There are two possible schemes for implementation: a) if the client and the AS already share a symmetric secret, an HMAC key can be created from the shared secret, and the authorization code will be HMAC'ed and standard techniques can be employed in the client-side API implementation to detect replay and forgery attempts on the code; b) an alternative is for the AS to sign the code using the private key from its SSL certificate, and for the client API to validate the signature using the public key. On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahavwrote: Draft -12 is finally out. This is almost a complete rewrite of the entire document, with the primary goal of moving it back to a similar structure used in -05. I have been thinking about this for a few months and finally came up with a structure that combines the two approaches. The draft includes some major cleanups, significantly simpler language, reduces repeated prose, and tried to keep prose to the introduction and normative language in the rest of the specification. I took out sections that broke the flow, and did my best to give this a linear narrative that is easy to follow. The draft includes the following normative changes: o Clarified 'token_type' as case insensitive. o Authorization endpoint requires TLS when an access token is issued. o Removed client assertion credentials, mandatory HTTP Basic authentication support for client credentials, WWW-Authenticate header, and the OAuth2 authentication scheme. o Changed implicit grant (aka user-agent flow) error response from query to fragment. o Removed the 'redirect_uri_mismatch' error code since in such a case, the authorization server must not send the error back to the client. o Defined access token type registry. I would like to spend the coming week receiving and applying feedback before requesting a WGLC for everything but the security considerations section (missing) 2/1. EHL > -----Original Message----- > From:oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org ] On Behalf > OfInternet-Drafts@ietf.org > Sent: Thursday, January 20, 2011 4:45 PM > To:i-d-announce@ietf.org > Cc:oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Open Authentication Protocol Working Group > of the IETF. > > > Title : The OAuth 2.0 Authorization Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-12.txt > Pages : 46 > Date : 2011-01-20 > > This specification describes the OAuth 2.0 authorization protocol. > > A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Internet- > Draft. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --------------070800090208060203040002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eran, and others,

A few of us had some discussions on the authorization code flow, as depicted in Fig. 3 of the current (12th) draft. We think that it is probably worthwhile to suggest in the specification that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). From what we have heard, this has been done in some of the current OAuth deployments. There are other people who do not think this is such a big security risk, although so far no one has objected that there is some risk here.

The issue is that according to the current draft, someone who owns a botnet can locate the redirect URIs of clients that listen on HTTP, and access them with random authorization codes, and cause HTTPS connections to be made on the Authorization Server (AS). There are a few things that the attacker can achieve with this OAuth flow that he cannot easily achieve otherwise :

1. Cost magnification: the attacker incurs the cost of an HTTP connection and causes an HTTPS connection to be made on the AS; and he can co-ordinate the timing of such HTTPS connections across multiple clients relatively easily, if these clients blindly connect to the AS without first validating the authorization codes received.

Although the attacker could achieve something similar, say by including an iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure web  users to visit that page, timing attacks using such a scheme is (say for the purpose of DDoS) more difficult .

2. Connection laundering: if the AS realizes it is flooded by HTTPS connections with illegitimate codes, it collects no useful information about the attacker, since the clients act as relays. 

3. CSRF defense/the 'state' parameter don't completely address this problem. With such a defense, the attacker might need to incur an additional HTTP request to obtain a valid CSRF code/ state parameter. This does cut down the effectiveness of the attack by a factor of 2, which is good. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency.html), the attacker still achieves a cost magnification.

Our proposal is that the OAuth specification suggests that an OAuth implementation SHOULD provide a way for the client to validate the authorization code before sending it to the  Authorization Server (AS). The specifics of how to validate the authorization code may not need to be part of the core specification. We sketch a design below for consideration for future implementation. It might be reasonable to assume that OAuth implementations provide some API for the client to call to validate and send the authorization code to the AS. There are two possible schemes for implementation: a) if the client and the AS already share a symmetric secret, an HMAC key can be created from the shared secret, and the authorization code will be HMAC'ed and standard techniques can be employed in the client-side API implementation to detect replay and forgery attempts on the code; b) an alternative is for the AS to sign the code using the private key from its SSL certificate, and for the client API to validate the signature using the public key.

 

On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
Draft -12 is finally out.

This is almost a complete rewrite of the entire document, with the primary goal of moving it back to a similar structure used in -05. I have been thinking about this for a few months and finally came up with a structure that combines the two approaches.

The draft includes some major cleanups, significantly simpler language, reduces repeated prose, and tried to keep prose to the introduction and normative language in the rest of the specification. I took out sections that broke the flow, and did my best to give this a linear narrative that is easy to follow.

The draft includes the following normative changes:

  o  Clarified 'token_type' as case insensitive.
  o  Authorization endpoint requires TLS when an access token is issued.
  o  Removed client assertion credentials, mandatory HTTP Basic authentication support for client credentials, WWW-Authenticate header, and the OAuth2 authentication scheme.
  o  Changed implicit grant (aka user-agent flow) error response from query to fragment.
  o  Removed the 'redirect_uri_mismatch' error code since in such a case, the authorization server must not send the error back to the client.
  o  Defined access token type registry.

I would like to spend the coming week receiving and applying feedback before requesting a WGLC for everything but the security considerations section (missing) 2/1.

EHL



> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Internet-Drafts@ietf.org
> Sent: Thursday, January 20, 2011 4:45 PM
> To: i-d-announce@ietf.org
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Open Authentication Protocol Working Group
> of the IETF.
>
>
>       Title           : The OAuth 2.0 Authorization Protocol
>       Author(s)       : E. Hammer-Lahav, et al.
>       Filename        : draft-ietf-oauth-v2-12.txt
>       Pages           : 46
>       Date            : 2011-01-20
>
> This specification describes the OAuth 2.0 authorization protocol.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the Internet-
> Draft.
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--------------070800090208060203040002-- From gabriel.klein@nuage.ch Sat Jan 15 04:28:07 2011 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 CD1063A6B6C for ; Sat, 15 Jan 2011 04:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mio2-9lLo9XU for ; Sat, 15 Jan 2011 04:28:06 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 65D663A6B67 for ; Sat, 15 Jan 2011 04:28:06 -0800 (PST) Received: by wwa36 with SMTP id 36so3651990wwa.13 for ; Sat, 15 Jan 2011 04:30:33 -0800 (PST) Received: by 10.216.159.69 with SMTP id r47mr501004wek.105.1295094633058; Sat, 15 Jan 2011 04:30:33 -0800 (PST) Received: from [10.10.1.200] (62-2-189-3.static.cablecom.ch [62.2.189.3]) by mx.google.com with ESMTPS id m6sm1216680wej.10.2011.01.15.04.30.30 (version=SSLv3 cipher=RC4-MD5); Sat, 15 Jan 2011 04:30:31 -0800 (PST) From: Gabriel Klein To: oauth@ietf.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Sat, 15 Jan 2011 13:30:30 +0100 Message-ID: <1295094630.2540.71.camel@GabLap> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 21 Jan 2011 08:16:00 -0800 Subject: Re: [OAUTH-WG] OAuth Digest, Vol 27, Issue 36 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: Sat, 15 Jan 2011 12:28:59 -0000 Dear oAuth Team and Fans, I'm currently evaluating how oAuth2 standards can be our own standards. I'm currently trying to understand all the details of the draft, so I'm sorry if these points are already in the specification, of if you already talk about these points. oAuth1 ------ We have implemented oAuth1. For our external partners, it was really hard to implement. Just to explain the flow in the internal team was quite complicated. So most of these users have ended by using basic authentication. 1. "oAuth2 Delegation" / chain authentication --------------------------------------------- Here is our need People need to login or register on our system using a user/password or Facebook account. We "delegate" our authentication to an external partner. (First it will be Facebook.) This authentication can be done on a phone or on a web application. What we will basically do: We get an access_token or code from Facebook using either a mobile application, either a web application. Exchange the access_token of facebook for an access token on our platform. We verify the user on facebook on our API. If we make it oAuth2 generic, we basically have a "chain authentication". We give an access if we have an access on another site. 2. Removal: HTTP Basic Authentication for Client Credentials (Eran Hammer-Lahav) ------------------------ If I have understood the flow correctly. I basically agree that the flow is not really good, but I don't think all servers are forced to implement all the flow of oAuth2. (could be marked as optional.) HTTP Basic is really an easy way to "test how it works". So a good first step for people to understand "how an api works" without caring about how oAuth works. We have this flow with our oAuth1 authentication, because we had a need of this flow to make things easier. What we do now is to add to all requests &applicationId=[custId]&applicationSecret=[custPassword] That allow to authenticate with the application and the user at the same time. It's not for the end user, but really for people that integrate our API, to make their life easier. --------------- Avec mes salutations, Best regards, Gabriel Klein (Poken.com) From bcampbell@pingidentity.com Fri Jan 21 08:24:56 2011 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 857773A6A3C for ; Fri, 21 Jan 2011 08:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.794 X-Spam-Level: X-Spam-Status: No, score=-3.794 tagged_above=-999 required=5 tests=[AWL=-1.818, 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 WyKV-jkI8nqA for ; Fri, 21 Jan 2011 08:24:55 -0800 (PST) Received: from na3sys009aog116.obsmtp.com (na3sys009aog116.obsmtp.com [74.125.149.240]) by core3.amsl.com (Postfix) with ESMTP id C3C2B3A6A41 for ; Fri, 21 Jan 2011 08:24:54 -0800 (PST) Received: from source ([209.85.215.176]) (using TLSv1) by na3sys009aob116.postini.com ([74.125.148.12]) with SMTP ID DSNKTTmz/BDA2ATuaIk4h+Y9BXXEEGBtpeNH@postini.com; Fri, 21 Jan 2011 08:27:41 PST Received: by mail-ey0-f176.google.com with SMTP id 10so957228eyz.35 for ; Fri, 21 Jan 2011 08:27:40 -0800 (PST) Received: by 10.213.14.148 with SMTP id g20mr1167700eba.43.1295627259625; Fri, 21 Jan 2011 08:27:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.17.65 with HTTP; Fri, 21 Jan 2011 08:27:09 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246F1A1C@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943246E7E60@TK5EX14MBXC202.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943246F1A1C@TK5EX14MBXC202.redmond.corp.microsoft.com> From: Brian Campbell Date: Fri, 21 Jan 2011 09:27:09 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=0015174c118c924184049a5dba0e Cc: oauth Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 security considerations 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, 21 Jan 2011 16:24:56 -0000 --0015174c118c924184049a5dba0e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Mike, Those were the things that jumped out at me from bearer-01 but I'll certainly review future drafts and provide feedback. -Brian On Thu, Jan 20, 2011 at 2:08 PM, Mike Jones wr= ote: > Having thought about it, I=92m willing to remove the text below. Are th= ere > any other sections of the bearer token security considerations that you > believe belong in the framework spec rather than the bearer token spec, o= r > that don=92t belong at all? > > > > Thanks again, > > -- Mike > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Monday, January 17, 2011 6:10 AM > *To:* Mike Jones > *Cc:* oauth > *Subject:* Re: [OAUTH-WG] Couple questions on > draft-ietf-oauth-v2-bearer-01 security considerations > > > > That text still seems more restrictive than what is in the framework > specification. And it's probably unnecessary - to the point James made > previously, any mention of the AS (beyond specifying the token_type) in a > "using a token" specification should probably be avoided unless there is = a > very specific reason for including it. In general, the AS is involved wh= en > "getting a token" and the RS is involved when "using a token." > > On Fri, Jan 14, 2011 at 6:40 PM, Mike Jones > wrote: > > Thanks for your input, Brian. I accepted these suggestions for draft -02= . > The referenced text now reads: > > Furthermore, the > authorization server MUST ensure that it only hands out tokens t= o > > clients it has authenticated first and authorized. For this > purpose, the client MUST be authenticated and authorized by > > the authorization server. The authorization server MUST also > obtain the consent of the resource owner > > prior to providing a token to the client. > > I'll leave it up to Eran how much of this security considerations text to > incorporate into the framework specification. > > -- Mike > > > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of > Brian Campbell > Sent: Thursday, December 09, 2010 1:38 PM > To: oauth > Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 > security considerations > > I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, > however, a couple things jumped out at me in areas that hadn't received m= uch > attention yet so I wanted to raise the questions on a separate thread. > > Near the end of section 3.2. Threat Mitigation, it says: > > " Furthermore, the resource server MUST ensure that it only hands out > tokens to clients it has authenticated first and authorized. For > this purpose, the client MUST be authenticated and authorized by the > resource server. " > > Was the intent here to say authorization server rather than resource > server? The resource server doesn't hand out tokens. Also, aren't there > legitimate cases where the client isn't authenticated (anonymous or other > cases where the client can't keep secrets)? > > Then it says: > > "The authorization server MUST also receive a > confirmation (the consent of the resource owner) prior to providing a > token to the client." > > Does this allow for implicit consent? On my first read of it, I interpret > this as potentially being more restrictive than what is in > draft-ietf-oauth-v2-11 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --0015174c118c924184049a5dba0e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Mike,

Those were the things that jumped out at me from bearer-01 but I'll certainly review f= uture drafts and provide feedback.

-Brian

On Thu, Jan 20, 2011 at 2:08 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:

Having thought about it, I=92m willing to remove the text below.=A0 Are= there any other sections of the bearer token security considerations that = you believe belong in the framework spec rather than the bearer token spec, or that don=92t b= elong at all?

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks again,

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

=A0

From:= Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Monday, January 17, 2011 6:10 AM
To: Mike Jones
Cc: oauth
Subject: Re: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bear= er-01 security considerations

=A0

That text still seems= more restrictive than what is in the framework specification.=A0 And it= 9;s probably unnecessary - to the point James made previously, any mention = of the AS (beyond specifying the token_type) in a "using a token" specification should probably be avoided un= less there is a very specific reason for including it.=A0 In general, the A= S is involved when "getting a token" and the RS is involved when = "using a token."

On Fri, Jan 14, 2011 at 6:40 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Thanks for your input, Brian. =A0I accepted these su= ggestions for draft -02. =A0The referenced text now reads:

=A0 =A0 =A0 =A0 Furthermore, the
=A0 =A0 =A0 =A0 =A0authorization server MUST ensure that it only hands out = tokens to

=A0 =A0 =A0 =A0 =A0clients it has authenticated firs= t and authorized. For this
=A0 =A0 =A0 =A0 =A0purpose, the client MUST be authenticated and authorized= by

=A0 =A0 =A0 =A0 =A0the authorization server. The aut= horization server MUST also
=A0 =A0 =A0 =A0 =A0obtain the consent of the resource owner

=A0 =A0 =A0 =A0 =A0pr= ior to providing a token to the client.

I'll leave it up to Eran how much of this securi= ty considerations text to incorporate into the framework specification.

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


-----Original Message-----
From: oauth-bou= nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Thursday, December 09, 2010 1:38 PM
To: oauth
Subject: [OAUTH-WG] Couple questions on draft-ietf-oauth-v2-bearer-01 secur= ity considerations

I know draft-ietf-oauth-v2-bearer-01 has been discussed a fair bit, however= , a couple things jumped out at me in areas that hadn't received much a= ttention yet so I wanted to raise the questions on a separate thread.

Near the end of section 3.2. Threat Mitigation, it says:

" Furthermore, the resource server MUST ensure that it only hands out<= br> =A0 tokens to clients it has authenticated first and authorized. =A0For
=A0 this purpose, the client MUST be authenticated and authorized by the =A0 resource server. "

Was the intent here to say authorization server rather than resource server= ? The resource server doesn't hand out tokens. Also, aren't there l= egitimate cases where the client isn't authenticated (anonymous or othe= r cases where the client can't keep secrets)?

Then it says:

"The authorization server MUST also receive a
=A0 confirmation (the consent of the resource owner) prior to providing a =A0 token to the client."

Does this allow for implicit consent? On my first read of it, I interpret t= his as potentially being more restrictive than what is in
draft-ietf-oauth-v2-11
_______________________________________________
OAuth mailing list
OAuth@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/oauth

=A0


--0015174c118c924184049a5dba0e-- From bcampbell@pingidentity.com Fri Jan 21 08:42:54 2011 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 515313A6A48 for ; Fri, 21 Jan 2011 08:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.643 X-Spam-Level: X-Spam-Status: No, score=-5.643 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 sKZH-2dpD0xE for ; Fri, 21 Jan 2011 08:42:53 -0800 (PST) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with ESMTP id DD6E13A6A47 for ; Fri, 21 Jan 2011 08:42:52 -0800 (PST) Received: from source ([209.85.215.175]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTTm4MqUEGOANxceRsmjbJHV3MGvfwbJR@postini.com; Fri, 21 Jan 2011 08:45:39 PST Received: by mail-ey0-f175.google.com with SMTP id 28so951808eya.34 for ; Fri, 21 Jan 2011 08:45:38 -0800 (PST) Received: by 10.213.27.78 with SMTP id h14mr1227419ebc.17.1295628338423; Fri, 21 Jan 2011 08:45:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.17.65 with HTTP; Fri, 21 Jan 2011 08:45:08 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1989C58C-5F31-4AC2-91B6-15312C3B73AE@oracle.com> From: Brian Campbell Date: Fri, 21 Jan 2011 09:45:08 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=000e0cd1e07adf6dca049a5dfa0c Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 21 Jan 2011 16:42:54 -0000 --000e0cd1e07adf6dca049a5dfa0c Content-Type: text/plain; charset=ISO-8859-1 I think we are generally in agreement on this Phil although there are legitimate cases where the client doesn't need to authenticate so having the spec require it is too restrictive. On Thu, Jan 20, 2011 at 3:50 PM, Phil Hunt wrote: > I don't think this is a case of providing alternative methods. It is just > a case of allowing ANY method that the Authentication server deems > sufficient. Kerberos, SAML, SSO token, basic auth, mutual SSL, etc. > > Thus you don't need to put specific authentication methods in the spec > other than to simply REQUIRE that the client be authenticated -- either > inbound with the POST as you suggest or OOB during a previous exchange. > > It may be a good idea to define one mandatory to implement methodology, but > to define more than one suggests limiting authentication approaches to > specific methods. I don't think this is the intent here. > > Phil > phil.hunt@oracle.com > > > > > On 2011-01-20, at 2:28 PM, Marius Scurtescu wrote: > > > On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt > wrote: > >> The client does need to know how to authenticate. But given that it > already has to know a lot about the service, you would think acceptable > authentication types are well known to the client. > > > > Yes, true. > > > > > >> What is the problem with the client authenticating like any normal web > service client? (IE outside of oauth) > >> > >> Why involve oauth in any authentication for User or client? > > > > What is a normal web service client? Since the client has to POST a > > bunch of parameters as form encoded, it is simpler to also send > > authentication parameters there. Providing alternate methods of > > authentication is just asking for trouble. Of course, the spec could > > require that authentication is only sent through some other method, > > but I think it is way too late for such a change. > > > > > > Marius > > --000e0cd1e07adf6dca049a5dfa0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we are generally in agreement on this Phil although there are legit= imate cases where the client doesn't need to authenticate so having the= spec require it is too restrictive.=A0

= On Thu, Jan 20, 2011 at 3:50 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
I don't think= this is a case of providing alternative methods. =A0It is just a case of a= llowing ANY method that the Authentication server deems sufficient. Kerbero= s, SAML, SSO token, basic auth, mutual SSL, etc.

Thus you don't need to put specific authentication methods in the spec = other than to simply REQUIRE that the client be authenticated -- either inb= ound with the POST as you suggest or OOB during a previous exchange.

It may be a good idea to define one mandatory to implement methodology, but= to define more than one suggests limiting authentication approaches to spe= cific methods. I don't think this is the intent here.

Phil
phil.hunt@oracle.com




On 2011-01-20, at 2:28 PM, Marius S= curtescu wrote:

> On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt <phil.hunt@oracle.com> wrote:
>> The client does need to know how to authenticate. But given that i= t already has to know a lot about the service, you would think acceptable a= uthentication types are well known to the client.
>
> Yes, true.
>
>
>> What is the problem with the client authenticating like any normal= web service client? (IE outside of oauth)
>>
>> Why involve oauth in any authentication for User or client?
>
> What is a normal web service client? Since the client has to POST a > bunch of parameters as form encoded, it is simpler to also send
> authentication parameters there. Providing alternate methods of
> authentication is just asking for trouble. Of course, the spec could > require that authentication is only sent through some other method, > but I think it is way too late for such a change.
>
>
> Marius


--000e0cd1e07adf6dca049a5dfa0c-- From bcampbell@pingidentity.com Fri Jan 21 08:43:21 2011 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 390AB28C0E1 for ; Fri, 21 Jan 2011 08:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 zAkrylu4+4Iy for ; Fri, 21 Jan 2011 08:43:20 -0800 (PST) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by core3.amsl.com (Postfix) with ESMTP id 9740428C0E5 for ; Fri, 21 Jan 2011 08:43:19 -0800 (PST) Received: from source ([209.85.215.49]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKTTm4TaE58Je8WcHSGVzjvT2EzAxwwc6m@postini.com; Fri, 21 Jan 2011 08:46:06 PST Received: by mail-ew0-f49.google.com with SMTP id 20so1111108ewy.22 for ; Fri, 21 Jan 2011 08:46:05 -0800 (PST) Received: by 10.213.16.79 with SMTP id n15mr1184867eba.69.1295628365305; Fri, 21 Jan 2011 08:46:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.17.65 with HTTP; Fri, 21 Jan 2011 08:45:35 -0800 (PST) In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943246EDAA6@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A5D35F61@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1989C58C-5F31-4AC2-91B6-15312C3B73AE@oracle.com> From: Brian Campbell Date: Fri, 21 Jan 2011 09:45:35 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=0015174c166e799754049a5dfcd7 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 21 Jan 2011 16:43:21 -0000 --0015174c166e799754049a5dfcd7 Content-Type: text/plain; charset=ISO-8859-1 BTW EHL, I haven't read all of -12 yet but I did read section 2 and, even though I was among those that originally pushed for the client assertion stuff, I think that where you've taken it is pretty good. On Fri, Jan 21, 2011 at 9:45 AM, Brian Campbell wrote: > I think we are generally in agreement on this Phil although there are > legitimate cases where the client doesn't need to authenticate so having the > spec require it is too restrictive. > > On Thu, Jan 20, 2011 at 3:50 PM, Phil Hunt wrote: > >> I don't think this is a case of providing alternative methods. It is just >> a case of allowing ANY method that the Authentication server deems >> sufficient. Kerberos, SAML, SSO token, basic auth, mutual SSL, etc. >> >> Thus you don't need to put specific authentication methods in the spec >> other than to simply REQUIRE that the client be authenticated -- either >> inbound with the POST as you suggest or OOB during a previous exchange. >> >> It may be a good idea to define one mandatory to implement methodology, >> but to define more than one suggests limiting authentication approaches to >> specific methods. I don't think this is the intent here. >> >> Phil >> phil.hunt@oracle.com >> >> >> >> >> On 2011-01-20, at 2:28 PM, Marius Scurtescu wrote: >> >> > On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt >> wrote: >> >> The client does need to know how to authenticate. But given that it >> already has to know a lot about the service, you would think acceptable >> authentication types are well known to the client. >> > >> > Yes, true. >> > >> > >> >> What is the problem with the client authenticating like any normal web >> service client? (IE outside of oauth) >> >> >> >> Why involve oauth in any authentication for User or client? >> > >> > What is a normal web service client? Since the client has to POST a >> > bunch of parameters as form encoded, it is simpler to also send >> > authentication parameters there. Providing alternate methods of >> > authentication is just asking for trouble. Of course, the spec could >> > require that authentication is only sent through some other method, >> > but I think it is way too late for such a change. >> > >> > >> > Marius >> >> > --0015174c166e799754049a5dfcd7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable BTW EHL, I haven't read all of -12 yet but I did read section 2 and,=20 even though I was among those that originally pushed for the client=20 assertion stuff, I think that where you've taken it is pretty good.
=
On Fri, Jan 21, 2011 at 9:45 AM, Brian Campb= ell <bca= mpbell@pingidentity.com> wrote:
I think we are ge= nerally in agreement on this Phil although there are legitimate cases where= the client doesn't need to authenticate so having the spec require it = is too restrictive.=A0

On Thu, Ja= n 20, 2011 at 3:50 PM, Phil Hunt <phil.hunt@oracle.com> w= rote:
I don't think= this is a case of providing alternative methods. =A0It is just a case of a= llowing ANY method that the Authentication server deems sufficient. Kerbero= s, SAML, SSO token, basic auth, mutual SSL, etc.

Thus you don't need to put specific authentication methods in the spec = other than to simply REQUIRE that the client be authenticated -- either inb= ound with the POST as you suggest or OOB during a previous exchange.

It may be a good idea to define one mandatory to implement methodology, but= to define more than one suggests limiting authentication approaches to spe= cific methods. I don't think this is the intent here.
On 2011-01-20, at 2:28 PM, Marius Scurtescu wrot= e:

> On Thu, Jan 20, 2011 at 2:14 PM, Phillip Hunt <phil.hunt@oracle.com> wrote: >> The client does need to know how to authenticate. But given that i= t already has to know a lot about the service, you would think acceptable a= uthentication types are well known to the client.
>
> Yes, true.
>
>
>> What is the problem with the client authenticating like any normal= web service client? (IE outside of oauth)
>>
>> Why involve oauth in any authentication for User or client?
>
> What is a normal web service client? Since the client has to POST a > bunch of parameters as form encoded, it is simpler to also send
> authentication parameters there. Providing alternate methods of
> authentication is just asking for trouble. Of course, the spec could > require that authentication is only sent through some other method, > but I think it is way too late for such a change.
>
>
> Marius



--0015174c166e799754049a5dfcd7-- From bcampbell@pingidentity.com Fri Jan 21 09:03:49 2011 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 054B53A6A63 for ; Fri, 21 Jan 2011 09:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.691 X-Spam-Level: X-Spam-Status: No, score=-5.691 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hG6hesDXcQnc for ; Fri, 21 Jan 2011 09:03:47 -0800 (PST) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by core3.amsl.com (Postfix) with ESMTP id 8AD3E28C0E3 for ; Fri, 21 Jan 2011 09:03:46 -0800 (PST) Received: from source ([209.85.215.174]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTTm9GNOfuZYqpuT7LZQoNXHqATrpKVsD@postini.com; Fri, 21 Jan 2011 09:06:33 PST Received: by mail-ey0-f174.google.com with SMTP id 27so1131677eye.5 for ; Fri, 21 Jan 2011 09:06:32 -0800 (PST) Received: by 10.213.33.143 with SMTP id h15mr1207484ebd.95.1295629591912; Fri, 21 Jan 2011 09:06:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.17.65 with HTTP; Fri, 21 Jan 2011 09:06:01 -0800 (PST) In-Reply-To: <900056.97405.qm@web55805.mail.re3.yahoo.com> References: <900056.97405.qm@web55805.mail.re3.yahoo.com> From: Brian Campbell Date: Fri, 21 Jan 2011 10:06:01 -0700 Message-ID: To: fcorella@pomcor.com Content-Type: multipart/alternative; boundary=0015174c104e962158049a5e45fc Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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, 21 Jan 2011 17:03:49 -0000 --0015174c104e962158049a5e45fc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess it's somewhat moot now because client assertions have been removed from the latest draft. However, I don't believe there anything saying that client assertions had to be bearer assertions. Nor would that really have been appropriate for the framework spec. The same is true for extension/URI grant types (formerly known as assertion grant types). There is nothing in the core OAuth framework spec saying tha= t it is, or has to be, a bearer assertion. The SAML Bearer Assertion Grant Type Profile is an extension spec that constrains/defines the specific use of bearer SAML assertion. To me and some others, that seemed like a useful enough use-case to write an I-D for, however, the main OAuth spec allows fo= r other extensions. A holder of key SAML Assertion, for example, might be profiled as a grant type. Or something completely non SAML based. On Thu, Jan 20, 2011 at 10:11 PM, Francisco Corella wr= ote: > Brian, > > Thank you for pointing me to the SAML Bearer Assertion Grant Type Profile= . > I understand now. Maybe the spec would be clearer if it said that the > client assertion is a bearer assertion. > > Francisco > > --- On *Thu, 1/20/11, Brian Campbell * wrote: > > > From: Brian Campbell > Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credential= s > and OAuth2 HTTP Authentication Scheme > To: fcorella@pomcor.com > Cc: "Eran Hammer-Lahav" , "Mike Jones" < > Michael.Jones@microsoft.com>, "oauth@ietf.org" , "Karen P= . > Lewison" > Date: Thursday, January 20, 2011, 10:39 PM > > > Francisco, > > While a proper profiling of subject confirmation is generally needed for = a > secure/interoperable SAML exchange, it's worth noting that assertions as > used in OAuth (client assertions or URI/assertion grant types) are not > necessarily SAML assertions. The term assertion is used more generally. = To > be honest, I think token might have been be a less confusing term to use = in > place of assertion in the framework spec. But token is widely used in ot= her > contexts thought out the framework spec too. So I dunno, maybe that woul= d > be even more confusing. > > If you are interested/knowledgeable about SAML subject confirmation, plea= se > feel free to review and comment on the SAML Bearer Assertion Grant Type > Profile: http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-00 :) > > -Brian > > On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella > > wrote: > > Mike, > > As assertion use is described in the spec, a client assertion does not > provide any security whatsoever. How do you handle subject confirmation = in > your implementation? (See section 2.4.1.1 of the SAML specification.) > In other words, how does the authorization server know that the client > sending the assertion is actually the subject of the assertion? > > Francisco > > --- On *Tue, 1/18/11, Mike Jones > >* wrote: > > > From: Mike Jones > > > Subject: [OAUTH-WG] Reasons not to remove Client Assertion Credentials an= d > OAuth2 HTTP Authentication Scheme > To: "Eran Hammer-Lahav" > > > Cc: "oauth@ietf.org " > > > Date: Tuesday, January 18, 2011, 5:35 PM > > > Having spoken to a number of people implementing the spec here, I=92ve > encountered strong objections to removing Client Assertion Credentials an= d > the OAuth2 HTTP Authentication Scheme. It=92s also not clear to me why w= e > would make substantial breaking changes to the specification when it is > essentially ready for approval. I=92ve summarized the reasons I believe = we > should keep these two features below. > > *Client Assertion Credentials:* Many of the scenarios we care about > require this capability. They were key motivators for the Assertion Profi= le > in WRAP (see =A7 5.2), have been part of OAuth 2 for quite a while, and w= e > have running code that requires this support. For example, the Azure Acce= ss > Control Service is a cloud Authorization server that supports several > protocols, including parts of OAuth 2.0 draft 10 (autonomous and web serv= er > profiles). We are happy to update our implementation to subsequent drafts= & > agree that the spec leaves a lot of ambiguity. > > In our implementation of the autonomous and web server profiles, ACS allo= ws > clients to authenticate using a signed assertion as well as with a > username/password. The username/pwd option is for clients that don=92t mi= nd > sending credentials over the wire, while the signed assertion mechanism i= s > for clients that are more reticent to send raw credentials and for scenar= ios > where it isn=92t possible. To illustrate an example where username/pwd is= n=92t > viable, consider the case of a client that needs to use an enterprise > identity to gain access to a cloud service. In many cases, corporate poli= cy > demands that a client use an identity managed by the organization. This > means that the client should obtain an assertion from an enterprise ident= ity > provider (Active Directory, Tivoli, etc.) and use that assertion to obtai= n > an access token which grants access to various web service APIs. Many of = our > key MSFT customers and internal partner teams rely on this mechanism and > reverting exclusively to username/pwd isn=92t an option for us. > > > > *'OAuth2' HTTP Authentication Scheme:* Simply put, dropping this seems > like a huge step away from interoperability. As one data point, Microsof= t > implements this in our WIF OAuth2 protected resource code. All up, clien= ts > need a way to authenticate to the protected resource. Also, existing WRA= P > implementations need this functionality to migrate to OAuth2. For all > these reasons, we support retaining this functionality in OAuth2. > > > > Thanks, > > -- Mike > > > > -----Inline Attachment Follows----- > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > --0015174c104e962158049a5e45fc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess it's somewhat moot now because client assertions have been remo= ved from the latest draft.=A0 However, I don't believe there anything s= aying that client assertions had to be bearer assertions.=A0 Nor would that= really have been appropriate for the framework spec.

The same is true for extension/URI grant types (formerly known as asser= tion grant types).=A0 There is nothing in the core OAuth framework spec say= ing that it is, or has to be, a bearer assertion.=A0 The SAML Bearer Assert= ion Grant Type Profile is an extension spec that constrains/defines the spe= cific use of bearer SAML assertion.=A0 To me and some others, that seemed l= ike a useful enough use-case to write an I-D for, however, the main OAuth s= pec allows for other extensions.=A0 A holder of key SAML Assertion, for exa= mple, might be profiled as a grant type.=A0 Or something completely non SAM= L based.=A0

On Thu, Jan 20, 2011 at 10:11 PM, Francisco = Corella <fcorel= la@pomcor.com> wrote:
Brian,

Thank you for pointing me= to the SAML Bearer Assertion Grant Type Profile.=A0 I understand now.=A0 M= aybe the spec would be clearer if it said that the client assertion is a be= arer assertion.

Francisco

--- On Thu, 1/20/11, Brian Campbell <bcampbell@pingiden= tity.com> wrote:

From: Brian Campbell <bcampbell@pingidentity.com>
Subject: Re: [OAUTH= -WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Aut= hentication Scheme
To: fcorella@pomco= r.com
Cc: "Eran Hammer-Lahav" <eran@hueniverse.com>, "Mike Jo= nes" <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>, "Karen P. Lewiso= n" <kplew= ison@pomcor.com>
Date: Thursday, January 20, 2011, 10:39 PM


Francisco,

While a= proper profiling of subject confirmation is generally needed for a secure/= interoperable SAML exchange, it's worth noting that assertions as used = in OAuth (client assertions or URI/assertion grant types) are not necessari= ly SAML assertions.=A0 The term assertion is used more generally.=A0 To be = honest, I think token might have been be a less confusing term to use in pl= ace of assertion in the framework spec.=A0 But token is widely used in othe= r contexts thought out the framework spec too.=A0 So I dunno, maybe that wo= uld be even more confusing.

If you are interested/knowledgeable about SAML subject confirmation, pl= ease feel free to review and comment on the SAML Bearer Assertion Grant Typ= e Profile: http://tools.ietf.org/html/draft= -ietf-oauth-saml2-bearer-00=A0 :)

-Brian

On Tue, Jan 18, 2011 at 1:26 PM, Francisco Corella <fcorella@pomcor.com> wrote:
Mike,

As assertion use is descri= bed in the spec, a client assertion does not provide any security whatsoeve= r.=A0 How do you handle subject confirmation in your implementation?=A0 (Se= e section 2.4.1.1 of the SAML specif= ication.)=A0 In other words, how does the authorization server know tha= t the client sending the assertion is actually the subject of the assertion= ?

Francisco

--- On Tue, 1/18/11, Mike Jones <Michael.Jones@microsoft.com> wrote:

From: Mike Jones <Michael.Jones@microsoft.c= om>
Subject: [OAUTH-WG] Reasons not to remove Client Assertion Cr= edentials and OAuth2 HTTP Authentication Scheme
To: "Eran Hammer-Lahav" <eran@hueniverse.com>
Cc: "oaut= h@ietf.org" <oauth@ietf.org>
Date: Tuesday, January 18, 2011, 5:35 PM


=20 =20

Having spoken to a number of people implementing the spec here, I=92ve e= ncountered strong objections to removing Client Assertion Credentials and t= he OAuth2 HTTP Authentication Scheme. =A0It=92s also not clear to me why we= would make substantial breaking changes to the specification when it is essentially ready for app= roval.=A0 I=92ve summarized the reasons I believe we should keep these two = features below.

=20

=20

Client Assertion Credentials:=A0 Many of the scenarios we care ab= out require this capability. They were key motivators for the Assertion Pro= file in WRAP (see =A7 5.2), have been part of OAuth 2 for quite a while, an= d we have running code that requires this support. For example, the Azure Access Control Ser= vice is a cloud Authorization server that supports several protocols, inclu= ding parts of OAuth 2.0 draft 10 (autonomous and web server profiles). We a= re happy to update our implementation to subsequent drafts & agree that the spec leaves a lot of ambiguity.<= /p>=20

=20

In our implementation of the autonomous and web server profiles, ACS all= ows clients to authenticate using a signed assertion as well as with a user= name/password. The username/pwd option is for clients that don=92t mind sen= ding credentials over the wire, while the signed assertion mechanism is for clients that ar= e more reticent to send raw credentials and for scenarios where it isn=92t = possible. To illustrate an example where username/pwd isn=92t viable, consi= der the case of a client that needs to use an enterprise identity to gain access to a cloud service. In many c= ases, corporate policy demands that a client use an identity managed by the= organization. This means that the client should obtain an assertion from a= n enterprise identity provider (Active Directory, Tivoli, etc.) and use that assertion to obtain an access token = which grants access to various web service APIs. Many of our key MSFT custo= mers and internal partner teams rely on this mechanism and reverting exclus= ively to username/pwd isn=92t an option for us.

=20

=A0

=20

'OAuth2' HTTP Authentication Scheme:=A0 Simply put, dropp= ing this seems like a huge step away from interoperability.=A0 As one data = point, Microsoft implements this in our WIF OAuth2 protected resource code.= =A0 All up, clients need a way to authenticate to the protected resource.=A0 Also, existing WRAP implemen= tations need this functionality to migrate to OAuth2.=A0=A0 For all these r= easons, we support retaining this functionality in OAuth2.

=20

=A0

=20

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Thanks,

=20

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

=20

=A0

=20
=20

-----Inline Attachment Follows-----

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

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



--0015174c104e962158049a5e45fc-- From bcampbell@pingidentity.com Fri Jan 21 09:52:58 2011 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 0AB3D3A6A66 for ; Fri, 21 Jan 2011 09:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.71 X-Spam-Level: X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 SZCX9ASa33as for ; Fri, 21 Jan 2011 09:52:56 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with ESMTP id 077433A6A69 for ; Fri, 21 Jan 2011 09:52:55 -0800 (PST) Received: from source ([209.85.215.182]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTTnInZ9BTkIGOfRm41SAnErNnIZ61WRx@postini.com; Fri, 21 Jan 2011 09:55:43 PST Received: by mail-ey0-f182.google.com with SMTP id 6so1053966eyf.13 for ; Fri, 21 Jan 2011 09:55:41 -0800 (PST) Received: by 10.213.14.81 with SMTP id f17mr1018530eba.30.1295632539961; Fri, 21 Jan 2011 09:55:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.213.17.65 with HTTP; Fri, 21 Jan 2011 09:55:09 -0800 (PST) In-Reply-To: <1295379852.16479.60.camel@GabLap> References: <1295379852.16479.60.camel@GabLap> From: Brian Campbell Date: Fri, 21 Jan 2011 10:55:09 -0700 Message-ID: To: Gabriel Klein Content-Type: text/plain; charset=ISO-8859-1 Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2 chain 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: Fri, 21 Jan 2011 17:52:58 -0000 On Tue, Jan 18, 2011 at 12:44 PM, Gabriel Klein wrote: > > I think it's a quite interesting flow, because it's more and more > frequent to delegate the authentication to another website/service. > (Even more when you are not part of the biggest sites.) Perhaps I don't understand all the details of your flow here but, more generally, when resource owner authentication is delegated/federated to another website/service, wouldn't it make sense to just allow the authorization endpoint to authenticate via OpenID, SAML, FB, MS, Twitter, whatever and keep OAuth agnostic to the means of authentication? Per http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-3.1, "The way in which the authorization server authenticates the resource owner (e.g. username and password login, session cookies) is beyond the scope of this specification." I believe that resource owner authentication was left out of scope intentionally to allow for such a separation of concerns. From Michael.Jones@microsoft.com Fri Jan 21 10:35:42 2011 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 D74F528C0FF for ; Fri, 21 Jan 2011 10:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.588 X-Spam-Level: X-Spam-Status: No, score=-10.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, 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 8TcLh4CSaPkA for ; Fri, 21 Jan 2011 10:35:41 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id BA3C328C0F5 for ; Fri, 21 Jan 2011 10:35:41 -0800 (PST) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Jan 2011 10:38:28 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0255.003; Fri, 21 Jan 2011 10:38:06 -0800 From: Mike Jones To: Eran Hammer-Lahav , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: AQHLuQTwEa54sDCM70WJZqHfEo5bZpPbID4AgABPngCAAC/w4A== Date: Fri, 21 Jan 2011 18:38:06 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246F2B23@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 21 Jan 2011 18:35:42 -0000 Please (re-)add my comments into your queue that the client assertion crede= ntials and WWW-Authenticate header should be retained. Also, per Marius' n= ote of January 20th, Google has plans to use the client assertion credentia= ls as well. You argue that interop is not hindered by removing features that could be d= efined as extensions. And that since additional knowledge is required to u= se these features that is outside the scope of the specification, that ther= e is no value in retaining them. The problem with those lines of reasoning is that the same arguments could = be applied to the whole specification. People *could* implement OAuth flow= s with no OAuth specification at all. So why not get rid of all of it? Si= mply, that interop is enhanced by having common ways to do common things --= even if some additional knowledge is required to do them. Please retain these features. -- Mike -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Thursday, January 20, 2011 9:42 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Forgot to mention that I don't have any outstanding comments in my queue so= if your feedback was not incorporated into -12, and you feel strongly abou= t it, bring it up again. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Eran Hammer-Lahav > Sent: Thursday, January 20, 2011 4:57 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > Draft -12 is finally out. >=20 > This is almost a complete rewrite of the entire document, with the=20 > primary goal of moving it back to a similar structure used in -05. I=20 > have been thinking about this for a few months and finally came up=20 > with a structure that combines the two approaches. >=20 > The draft includes some major cleanups, significantly simpler=20 > language, reduces repeated prose, and tried to keep prose to the=20 > introduction and normative language in the rest of the specification.=20 > I took out sections that broke the flow, and did my best to give this=20 > a linear narrative that is easy to follow. >=20 > The draft includes the following normative changes: >=20 > o Clarified 'token_type' as case insensitive. > o Authorization endpoint requires TLS when an access token is issued. > o Removed client assertion credentials, mandatory HTTP Basic=20 > authentication support for client credentials, WWW-Authenticate=20 > header, and the OAuth2 authentication scheme. > o Changed implicit grant (aka user-agent flow) error response from=20 > query to fragment. > o Removed the 'redirect_uri_mismatch' error code since in such a=20 > case, the authorization server must not send the error back to the client= . > o Defined access token type registry. >=20 > I would like to spend the coming week receiving and applying feedback=20 > before requesting a WGLC for everything but the security=20 > considerations section (missing) 2/1. >=20 > EHL >=20 >=20 >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > Behalf Of Internet-Drafts@ietf.org > > Sent: Thursday, January 20, 2011 4:45 PM > > To: i-d-announce@ietf.org > > Cc: oauth@ietf.org > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Open Authentication Protocol=20 > > Working Group of the IETF. > > > > > > Title : The OAuth 2.0 Authorization Protocol > > Author(s) : E. Hammer-Lahav, et al. > > Filename : draft-ietf-oauth-v2-12.txt > > Pages : 46 > > Date : 2011-01-20 > > > > This specification describes the OAuth 2.0 authorization protocol. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader=20 > > implementation to automatically retrieve the ASCII version of the > > Internet- Draft. > _______________________________________________ > OAuth mailing 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 Fri Jan 21 11:08:55 2011 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 81F7A3A6A8D for ; Fri, 21 Jan 2011 11:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 KGb2dE1wfY+g for ; Fri, 21 Jan 2011 11:08:54 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2B4A53A6A16 for ; Fri, 21 Jan 2011 11:08:54 -0800 (PST) Received: (qmail 18052 invoked from network); 21 Jan 2011 19:11:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 21 Jan 2011 19:11:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 21 Jan 2011 12:11:39 -0700 From: Eran Hammer-Lahav To: Mike Jones , "oauth@ietf.org" Date: Fri, 21 Jan 2011 12:11:29 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: AQHLuQTwEa54sDCM70WJZqHfEo5bZpPbID4AgABPngCAAC/w4IAAJ9/g Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61DEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246F2B23@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246F2B23@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 21 Jan 2011 19:08:55 -0000 Re: client assertion credentials The actual decision to move the section out and call for someone to edit a= new document was made by the chair. I will not put it back unless instruct= ed by the chair based on working group consensus and a revised language tha= t addresses my concerns. And you are still ignoring all the issues I raised= ... Re: WWW-Authenticate header You have made no arguments to retain this header or scheme. As -12 clearly = shows, it has no place in the document since at no point is it necessary to= return an OAuth2 authentication challenge (and what does it even mean?). A= s currently defined, each token type uses its own authentication scheme whi= ch comes with its own WWW-Authenticate header. The bearer token specificati= on should define its own challenge and as I commented earlier, should not u= se 'OAuth2' as its scheme because it is confusing and prejudicial. I will n= ot put it back unless instructed by the chair based on working group consen= sus on a new proposed language that fits the new organization of -12. EHL > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, January 21, 2011 10:38 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > Please (re-)add my comments into your queue that the client assertion > credentials and WWW-Authenticate header should be retained. Also, per > Marius' note of January 20th, Google has plans to use the client assertio= n > credentials as well. >=20 > You argue that interop is not hindered by removing features that could be > defined as extensions. And that since additional knowledge is required t= o > use these features that is outside the scope of the specification, that t= here is > no value in retaining them. >=20 > The problem with those lines of reasoning is that the same arguments coul= d > be applied to the whole specification. People *could* implement OAuth > flows with no OAuth specification at all. So why not get rid of all of i= t? > Simply, that interop is enhanced by having common ways to do common > things -- even if some additional knowledge is required to do them. >=20 > Please retain these features. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Thursday, January 20, 2011 9:42 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > Forgot to mention that I don't have any outstanding comments in my queue > so if your feedback was not incorporated into -12, and you feel strongly > about it, bring it up again. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Thursday, January 20, 2011 4:57 PM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > Draft -12 is finally out. > > > > This is almost a complete rewrite of the entire document, with the > > primary goal of moving it back to a similar structure used in -05. I > > have been thinking about this for a few months and finally came up > > with a structure that combines the two approaches. > > > > The draft includes some major cleanups, significantly simpler > > language, reduces repeated prose, and tried to keep prose to the > > introduction and normative language in the rest of the specification. > > I took out sections that broke the flow, and did my best to give this > > a linear narrative that is easy to follow. > > > > The draft includes the following normative changes: > > > > o Clarified 'token_type' as case insensitive. > > o Authorization endpoint requires TLS when an access token is issue= d. > > o Removed client assertion credentials, mandatory HTTP Basic > > authentication support for client credentials, WWW-Authenticate > > header, and the OAuth2 authentication scheme. > > o Changed implicit grant (aka user-agent flow) error response from > > query to fragment. > > o Removed the 'redirect_uri_mismatch' error code since in such a > > case, the authorization server must not send the error back to the clie= nt. > > o Defined access token type registry. > > > > I would like to spend the coming week receiving and applying feedback > > before requesting a WGLC for everything but the security > > considerations section (missing) 2/1. > > > > EHL > > > > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf Of Internet-Drafts@ietf.org > > > Sent: Thursday, January 20, 2011 4:45 PM > > > To: i-d-announce@ietf.org > > > Cc: oauth@ietf.org > > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Open Authentication Protocol > > > Working Group of the IETF. > > > > > > > > > Title : The OAuth 2.0 Authorization Protocol > > > Author(s) : E. Hammer-Lahav, et al. > > > Filename : draft-ietf-oauth-v2-12.txt > > > Pages : 46 > > > Date : 2011-01-20 > > > > > > This specification describes the OAuth 2.0 authorization protocol. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet- Draft. > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Fri Jan 21 14:14:32 2011 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 98B243A6822 for ; Fri, 21 Jan 2011 14:14:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.589 X-Spam-Level: X-Spam-Status: No, score=-10.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, 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 2GHnTzEA1nsr for ; Fri, 21 Jan 2011 14:14:31 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 866E73A67EC for ; Fri, 21 Jan 2011 14:14:29 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Jan 2011 14:17:16 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0255.003; Fri, 21 Jan 2011 14:17:16 -0800 From: Mike Jones To: Eran Hammer-Lahav , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: AQHLuQTwEa54sDCM70WJZqHfEo5bZpPbID4AgABPngCAAC/w4IAAJ9/ggAA1SwA= Date: Fri, 21 Jan 2011 22:17:15 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246F30E9@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246F2B23@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D61DEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61DEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 21 Jan 2011 22:14:32 -0000 I understand that despite me providing answers to the issues you raised, su= ch as those below and those in previous exchanges, that it's your desire to= portray things as me ignoring your issues, even though it's not true. So = be it. I'll let others be the judge of that. I will also add that you appear to have dismissed many of the issues I and = others raised out of hand without seriously considering them, such as those= about specification stability, compatibility, and providing a migration pa= th forward for existing implementations both of OAuth 2.0 drafts and WRAP. = You may not like those issues, but they are substantive and pertinent to t= he acceptance of OAuth 2.0, or its lack of acceptance, in the marketplace. Sincerely, -- Mike -----Original Message----- From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 Sent: Friday, January 21, 2011 11:11 AM To: Mike Jones; oauth@ietf.org Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Re: client assertion credentials The actual decision to move the section out and call for someone to edit a= new document was made by the chair. I will not put it back unless instruct= ed by the chair based on working group consensus and a revised language tha= t addresses my concerns. And you are still ignoring all the issues I raised= ... Re: WWW-Authenticate header You have made no arguments to retain this header or scheme. As -12 clearly = shows, it has no place in the document since at no point is it necessary to= return an OAuth2 authentication challenge (and what does it even mean?). A= s currently defined, each token type uses its own authentication scheme whi= ch comes with its own WWW-Authenticate header. The bearer token specificati= on should define its own challenge and as I commented earlier, should not u= se 'OAuth2' as its scheme because it is confusing and prejudicial. I will n= ot put it back unless instructed by the chair based on working group consen= sus on a new proposed language that fits the new organization of -12. EHL > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, January 21, 2011 10:38 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > Please (re-)add my comments into your queue that the client assertion=20 > credentials and WWW-Authenticate header should be retained. Also, per=20 > Marius' note of January 20th, Google has plans to use the client=20 > assertion credentials as well. >=20 > You argue that interop is not hindered by removing features that could=20 > be defined as extensions. And that since additional knowledge is=20 > required to use these features that is outside the scope of the=20 > specification, that there is no value in retaining them. >=20 > The problem with those lines of reasoning is that the same arguments=20 > could be applied to the whole specification. People *could* implement=20 > OAuth flows with no OAuth specification at all. So why not get rid of al= l of it? > Simply, that interop is enhanced by having common ways to do common=20 > things -- even if some additional knowledge is required to do them. >=20 > Please retain these features. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Eran Hammer-Lahav > Sent: Thursday, January 20, 2011 9:42 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > Forgot to mention that I don't have any outstanding comments in my=20 > queue so if your feedback was not incorporated into -12, and you feel=20 > strongly about it, bring it up again. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > Behalf Of Eran Hammer-Lahav > > Sent: Thursday, January 20, 2011 4:57 PM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > Draft -12 is finally out. > > > > This is almost a complete rewrite of the entire document, with the=20 > > primary goal of moving it back to a similar structure used in -05. I=20 > > have been thinking about this for a few months and finally came up=20 > > with a structure that combines the two approaches. > > > > The draft includes some major cleanups, significantly simpler=20 > > language, reduces repeated prose, and tried to keep prose to the=20 > > introduction and normative language in the rest of the specification. > > I took out sections that broke the flow, and did my best to give=20 > > this a linear narrative that is easy to follow. > > > > The draft includes the following normative changes: > > > > o Clarified 'token_type' as case insensitive. > > o Authorization endpoint requires TLS when an access token is issue= d. > > o Removed client assertion credentials, mandatory HTTP Basic=20 > > authentication support for client credentials, WWW-Authenticate=20 > > header, and the OAuth2 authentication scheme. > > o Changed implicit grant (aka user-agent flow) error response=20 > > from query to fragment. > > o Removed the 'redirect_uri_mismatch' error code since in such a=20 > > case, the authorization server must not send the error back to the clie= nt. > > o Defined access token type registry. > > > > I would like to spend the coming week receiving and applying=20 > > feedback before requesting a WGLC for everything but the security=20 > > considerations section (missing) 2/1. > > > > EHL > > > > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > > Behalf Of Internet-Drafts@ietf.org > > > Sent: Thursday, January 20, 2011 4:45 PM > > > To: i-d-announce@ietf.org > > > Cc: oauth@ietf.org > > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Open Authentication Protocol=20 > > > Working Group of the IETF. > > > > > > > > > Title : The OAuth 2.0 Authorization Protocol > > > Author(s) : E. Hammer-Lahav, et al. > > > Filename : draft-ietf-oauth-v2-12.txt > > > Pages : 46 > > > Date : 2011-01-20 > > > > > > This specification describes the OAuth 2.0 authorization protocol. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader=20 > > > implementation to automatically retrieve the ASCII version of the > > > Internet- Draft. > > _______________________________________________ > > OAuth mailing 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 Fri Jan 21 17:06:55 2011 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 437783A6878 for ; Fri, 21 Jan 2011 17:06:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.034, 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 90wHFaZstbxZ for ; Fri, 21 Jan 2011 17:06:54 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 75F513A685D for ; Fri, 21 Jan 2011 17:06:54 -0800 (PST) Received: (qmail 3757 invoked from network); 22 Jan 2011 01:09:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Jan 2011 01:09:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 21 Jan 2011 18:09:40 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Fri, 21 Jan 2011 18:09:30 -0700 Thread-Topic: draft-hammer-oauth-v2-mac-token-02 Thread-Index: Acu50HMZE3ElIG/6SjSQTXJNzEiUCw== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8D61EBFP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 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: Sat, 22 Jan 2011 01:06:55 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D61EBFP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 New version includes the following changes: o Added body-hash support. o Updated OAuth 2.0 reference to -12 and added token type registration = template. o Removed error and error URI attributes (codes were just a duplication= of the HTTP status codes). Feedback would be greatly appreciated. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D61EBFP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

http://tools.ietf= .org/html/draft-hammer-oauth-v2-mac-token-02

 

New version includes the= following changes:

 

   o  Added body-hash support.=

   o  Upd= ated OAuth 2.0 reference to -12 and added token type registration template.=

   o  Rem= oved error and error URI attributes (codes were just a duplication of the H= TTP status codes).

&= nbsp;

Feedback would be greatl= y appreciated.

 = ;

EHL

 

=  

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D61EBFP3PW5EX1MB01E_-- From tonynad@microsoft.com Fri Jan 21 17:16:49 2011 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 8B3BD3A6892 for ; Fri, 21 Jan 2011 17:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 aHpWCreHbRaH for ; Fri, 21 Jan 2011 17:16:48 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 654603A688E for ; Fri, 21 Jan 2011 17:16:48 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Jan 2011 17:19:35 -0800 Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.87]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Fri, 21 Jan 2011 17:19:34 -0800 From: Anthony Nadalin To: Eran Hammer-Lahav , Mike Jones , "oauth@ietf.org" Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: AQHLuQTwAUiCshRoZk+11o+AxvAWWpPbID4AgABPngCAANjmAIAACVOA///gfYA= Date: Sat, 22 Jan 2011 01:19:34 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F0338C8C5@TK5EX14MBXC113.redmond.corp.microsoft.com> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246F2B23@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D61DEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61DEA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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: Sat, 22 Jan 2011 01:16:49 -0000 We should then have a consensus call to remove items like this -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Friday, January 21, 2011 11:11 AM To: Mike Jones; oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Re: client assertion credentials The actual decision to move the section out and call for someone to edit a= new document was made by the chair. I will not put it back unless instruct= ed by the chair based on working group consensus and a revised language tha= t addresses my concerns. And you are still ignoring all the issues I raised= ... Re: WWW-Authenticate header You have made no arguments to retain this header or scheme. As -12 clearly = shows, it has no place in the document since at no point is it necessary to= return an OAuth2 authentication challenge (and what does it even mean?). A= s currently defined, each token type uses its own authentication scheme whi= ch comes with its own WWW-Authenticate header. The bearer token specificati= on should define its own challenge and as I commented earlier, should not u= se 'OAuth2' as its scheme because it is confusing and prejudicial. I will n= ot put it back unless instructed by the chair based on working group consen= sus on a new proposed language that fits the new organization of -12. EHL > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Friday, January 21, 2011 10:38 AM > To: Eran Hammer-Lahav; oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > Please (re-)add my comments into your queue that the client assertion=20 > credentials and WWW-Authenticate header should be retained. Also, per=20 > Marius' note of January 20th, Google has plans to use the client=20 > assertion credentials as well. >=20 > You argue that interop is not hindered by removing features that could=20 > be defined as extensions. And that since additional knowledge is=20 > required to use these features that is outside the scope of the=20 > specification, that there is no value in retaining them. >=20 > The problem with those lines of reasoning is that the same arguments=20 > could be applied to the whole specification. People *could* implement=20 > OAuth flows with no OAuth specification at all. So why not get rid of al= l of it? > Simply, that interop is enhanced by having common ways to do common=20 > things -- even if some additional knowledge is required to do them. >=20 > Please retain these features. >=20 > -- Mike >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Eran Hammer-Lahav > Sent: Thursday, January 20, 2011 9:42 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > Forgot to mention that I don't have any outstanding comments in my=20 > queue so if your feedback was not incorporated into -12, and you feel=20 > strongly about it, bring it up again. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > Behalf Of Eran Hammer-Lahav > > Sent: Thursday, January 20, 2011 4:57 PM > > To: oauth@ietf.org > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > Draft -12 is finally out. > > > > This is almost a complete rewrite of the entire document, with the=20 > > primary goal of moving it back to a similar structure used in -05. I=20 > > have been thinking about this for a few months and finally came up=20 > > with a structure that combines the two approaches. > > > > The draft includes some major cleanups, significantly simpler=20 > > language, reduces repeated prose, and tried to keep prose to the=20 > > introduction and normative language in the rest of the specification. > > I took out sections that broke the flow, and did my best to give=20 > > this a linear narrative that is easy to follow. > > > > The draft includes the following normative changes: > > > > o Clarified 'token_type' as case insensitive. > > o Authorization endpoint requires TLS when an access token is issue= d. > > o Removed client assertion credentials, mandatory HTTP Basic=20 > > authentication support for client credentials, WWW-Authenticate=20 > > header, and the OAuth2 authentication scheme. > > o Changed implicit grant (aka user-agent flow) error response=20 > > from query to fragment. > > o Removed the 'redirect_uri_mismatch' error code since in such a=20 > > case, the authorization server must not send the error back to the clie= nt. > > o Defined access token type registry. > > > > I would like to spend the coming week receiving and applying=20 > > feedback before requesting a WGLC for everything but the security=20 > > considerations section (missing) 2/1. > > > > EHL > > > > > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On=20 > > > Behalf Of Internet-Drafts@ietf.org > > > Sent: Thursday, January 20, 2011 4:45 PM > > > To: i-d-announce@ietf.org > > > Cc: oauth@ietf.org > > > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Open Authentication Protocol=20 > > > Working Group of the IETF. > > > > > > > > > Title : The OAuth 2.0 Authorization Protocol > > > Author(s) : E. Hammer-Lahav, et al. > > > Filename : draft-ietf-oauth-v2-12.txt > > > Pages : 46 > > > Date : 2011-01-20 > > > > > > This specification describes the OAuth 2.0 authorization protocol. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > Below is the data which will enable a MIME compliant mail reader=20 > > > implementation to automatically retrieve the ASCII version of the > > > Internet- Draft. > > _______________________________________________ > > OAuth mailing 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 michael.d.adams@gmail.com Fri Jan 21 17:33:33 2011 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 348A23A688E for ; Fri, 21 Jan 2011 17:33:33 -0800 (PST) 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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3, 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 1HmiAgY4Fbyf for ; Fri, 21 Jan 2011 17:33:32 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 484793A688B for ; Fri, 21 Jan 2011 17:33:32 -0800 (PST) Received: by fxm9 with SMTP id 9so2585651fxm.31 for ; Fri, 21 Jan 2011 17:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=HSCLMPf6GDfryXve0gu575cvq9l6bl7Y1YiBMRYnuJ0=; b=CSjjQqj/nUFXIhR27P6ixqNBTZ/8xtvNxLnniNAkiU7oVfERmUEgtbXqan24NKkh2X gnudRPKRqA4O/8NfW0FfI/wBXrWsZonVwN+yjBV/iDkupLg9VJ1wsk/bGadoDGzE6GW7 PlzX90mfNiVo+E5G5yfmx3TFl3r8dsHp/GNaU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=pTRuAOelyUtQdyuSIyeSyBUJrBQO06Xc0mokKBPJQlND7ckXrVIYlnfSq9pvSDNrQF PyniGDxwECNRa42UAe1ZGHcA/1wFeQRGCRkJIIE5QAQZ/Rv3+4AFe2to1C7sLyvXocZQ ztVIa1iQUDV7+3i+WiLJ4NNZig+/Zs4gzU4gg= Received: by 10.223.101.135 with SMTP id c7mr1407249fao.76.1295660179078; Fri, 21 Jan 2011 17:36:19 -0800 (PST) MIME-Version: 1.0 Sender: michael.d.adams@gmail.com Received: by 10.223.100.2 with HTTP; Fri, 21 Jan 2011 17:35:58 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Michael D Adams Date: Fri, 21 Jan 2011 17:35:58 -0800 X-Google-Sender-Auth: YUR_DuJEYXJxRfzZf-U6Sqv6byU Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 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: Sat, 22 Jan 2011 01:33:33 -0000 On Fri, Jan 21, 2011 at 5:09 PM, Eran Hammer-Lahav wrote: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 That link redirects me to -01 $ curl -I 'http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02' HTTP/1.1 302 Found Date: Sat, 22 Jan 2011 01:35:45 GMT Server: Apache/2.2.16 (Debian) Location: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-01 Content-Type: text/html; charset=US-ASCII From eran@hueniverse.com Fri Jan 21 17:54:12 2011 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 C35073A6889 for ; Fri, 21 Jan 2011 17:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.415 X-Spam-Level: X-Spam-Status: No, score=-1.415 tagged_above=-999 required=5 tests=[AWL=-1.116, BAYES_00=-2.599, MANGLED_TOOL=2.3] 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 w3uxqbHjQCst for ; Fri, 21 Jan 2011 17:54:11 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 6C39B3A6857 for ; Fri, 21 Jan 2011 17:54:11 -0800 (PST) Received: (qmail 10809 invoked from network); 22 Jan 2011 01:56:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 22 Jan 2011 01:56:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 21 Jan 2011 18:56:51 -0700 From: Eran Hammer-Lahav To: Michael D Adams Date: Fri, 21 Jan 2011 18:56:43 -0700 Thread-Topic: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 Thread-Index: Acu51MfSLrUf/Z23S0OBGj8EaMta8wAAs3FA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D61ECA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 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: Sat, 22 Jan 2011 01:54:13 -0000 The tools are slow. Just try again. EHL > -----Original Message----- > From: michael.d.adams@gmail.com [mailto:michael.d.adams@gmail.com] > On Behalf Of Michael D Adams > Sent: Friday, January 21, 2011 5:36 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 >=20 > On Fri, Jan 21, 2011 at 5:09 PM, Eran Hammer-Lahav > wrote: > > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 >=20 > That link redirects me to -01 >=20 > $ curl -I 'http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02' > HTTP/1.1 302 Found > Date: Sat, 22 Jan 2011 01:35:45 GMT > Server: Apache/2.2.16 (Debian) > Location: http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-01 > Content-Type: text/html; charset=3DUS-ASCII From fcorella@pomcor.com Fri Jan 21 22:26:09 2011 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 4DF743A68CC for ; Fri, 21 Jan 2011 22:26:09 -0800 (PST) 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 U3S4vT8cjYUj for ; Fri, 21 Jan 2011 22:26:06 -0800 (PST) Received: from nm16-vm0.bullet.mail.ac4.yahoo.com (nm16-vm0.bullet.mail.ac4.yahoo.com [98.139.52.238]) by core3.amsl.com (Postfix) with SMTP id 342E53A68BA for ; Fri, 21 Jan 2011 22:26:04 -0800 (PST) Received: from [98.139.52.191] by nm16.bullet.mail.ac4.yahoo.com with NNFMP; 22 Jan 2011 06:28:49 -0000 Received: from [98.139.52.170] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 22 Jan 2011 06:28:48 -0000 Received: from [127.0.0.1] by omp1053.mail.ac4.yahoo.com with NNFMP; 22 Jan 2011 06:28:48 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 873027.49553.bm@omp1053.mail.ac4.yahoo.com Received: (qmail 5657 invoked by uid 60001); 22 Jan 2011 06:28:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295677728; bh=RLz5deBwEv8Khxcn+SVe8d1y/s7w+ppWZ2osxmy+KAA=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=RHKZv9fmxvYiQXN4s7J84XWhNmQkKyq8o9CCb31Xpv4DrPZzMQaXpu+E8J/NSfYLSRy//hLpIuYDvA8evmr0PT6NMKszN0/ulTJThusGrVMMG7bozlXozVmV2peyHUV6PGWph70JeemYY18PN2KG3Ys5nhvXluFrrATBdsZspoc= Message-ID: <645956.90531.qm@web55803.mail.re3.yahoo.com> X-YMail-OSG: uPAitK0VM1nNdlrgFU9cTBDpuXslo8ZhN7CQYRbPSr4dl3H DLtY_71wwCvFsnAOKWM0gtSyngKlvNS105nVI1CUg8_.BhozwXS2MSzNjPQ0 8Lks.CA6b2RuBJd_8d1Sum20FqACbkg2l5JF4Tabojofh7i9cDVH78vKkMqW 6BUC9__9G9Vef.ozVqhUWY8U6OjwV6jU_P4Ak8AnvuISD2sgOcC.zP93hekj eOgdwDLG0X4hMWI0C7spoBWq0dO91.rusVncA41hzSYtEtXJWbV3aL2EPBEE JwDMTj0c1aqBGtv2wjaTJ1jbGXNz2TYUpCqmfjiPBXAq45ZnnanuOFLmd_YY gde.4YRCl5vIlxapPGnLrnO9TTax5bue_Ub1KpXggK201x6sjMRM76CP3nFO YFdo- Received: from [173.198.123.207] by web55803.mail.re3.yahoo.com via HTTP; Fri, 21 Jan 2011 22:28:48 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Fri, 21 Jan 2011 22:28:48 -0800 (PST) From: Francisco Corella To: oauth@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1075842813-1295677728=:90531" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 06:26:09 -0000 --0-1075842813-1295677728=:90531 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Brian, > I guess it's somewhat moot now because client assertions > have been removed from the latest draft.=A0 However, I don't > believe there anything saying that client assertions had to > be bearer assertions.=A0 Nor would that really have been > appropriate for the framework spec. Ah, so I was right in thinking there was something wrong :-) You can only use a bearer assertion (or "could" since assertions are no longer in the spec).=A0=20 If a subject (here, the client) authenticates itself by sending a single message that contains an assertion, the assertion cannot be a holder-of-key assertion.=A0 A holder-of-key assertion is an assertion about the holder of a private key whose corresponding public key or certificate is contained in the assertion.=A0 The subject must confirm that it has the private key.=A0 The subject typically does that by signing a nonce supplied by the relying party (here, the authorization server).=A0 That party must send the nonce in an earlier protocol message. Actually, an assertion that authenticates the subject by the mere fact of being presented by the subject is, by definition, a bearer assertion.=A0 That's what "bearer" means.=A0 It means "this assertion is about whoever bears it (carries it, produces it); the bearer does not have to present any other proof if its identity". > The same is true for extension/URI grant types (formerly > known as assertion grant types).=A0 There is nothing in the > core OAuth framework spec saying that it is, or has to be, a > bearer assertion.=A0 The SAML Bearer Assertion Grant Type > Profile is an extension spec that constrains/defines the > specific use of bearer SAML assertion.=A0 To me and some > others, that seemed like a useful enough use-case to write > an I-D for, however, the main OAuth spec allows for other > extensions.=A0 A holder of key SAML Assertion, for example, > might be profiled as a grant type.=A0 Or something completely > non SAML based. The same would be true for obtaining an access token by presenting a SAML assertion as an access grant.=A0 It would have to be a bearer assertion, not a holder-of-key assertion. As for a non-SAML token, it would have to be a bearer token, by definition of the word "bearer".=A0 But it's not just a matter of definition.=A0 There is a security requirement for any token to be usable as a bearer token: it must only become known to the subject and the verifier.=A0 So it must be sent by the asserting party to the subject, and then from the subject to the relying party, through channels that provide confidentiality and authentication of the destination (such as ordinary TLS connections).=A0 And all three parties must keep the bearer token secret. By the way, I saw in the discussion that some existing implementations are using assertions.=A0 Hopefully they are using bearer assertions. Francisco --0-1075842813-1295677728=:90531 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =
Brian,

> I guess it's somewhat moot= now because client assertions
> have been removed from the latest dr= aft.  However, I don't
> believe there anything saying that clie= nt assertions had to
> be bearer assertions.  Nor would that rea= lly have been
> appropriate for the framework spec.

Ah, so I w= as right in thinking there was something wrong :-)

You can only use = a bearer assertion (or "could" since
assertions are no longer in the spe= c). 

If a subject (here, the client) authenticates itself bysending a single message that contains an assertion, the
assertion can= not be a holder-of-key assertion.  A
holder-of-key assertion is an = assertion about the holder of
a private key whose corresponding public k= ey or certificate
is contained in the assertion.  The subject must confirm
that it has the private key.  The subject typically doesthat by signing a nonce supplied by the relying party (here,
the autho= rization server).  That party must send the nonce
in an earlier pro= tocol message.

Actually, an assertion that authenticates the subject= by the
mere fact of being presented by the subject is, by
definition= , a bearer assertion.  That's what "bearer"
means.  It means "= this assertion is about whoever bears
it (carries it, produces it); the = bearer does not have to
present any other proof if its identity".
> The same is true for extension/URI grant types (formerly
> know= n as assertion grant types).  There is nothing in the
> core OAu= th framework spec saying that it is, or has to be, a
> bearer asserti= on.  The SAML Bearer Assertion Grant Type
> Profile is an extens= ion spec that constrains/defines the
> specific use of bearer SAML assertion.  To me and some
> others, that seemed like a us= eful enough use-case to write
> an I-D for, however, the main OAuth s= pec allows for other
> extensions.  A holder of key SAML Asserti= on, for example,
> might be profiled as a grant type.  Or someth= ing completely
> non SAML based.

The same would be true for ob= taining an access token by
presenting a SAML assertion as an access gran= t.  It would
have to be a bearer assertion, not a holder-of-key
= assertion.

As for a non-SAML token, it would have to be a bearer tok= en,
by definition of the word "bearer".  But it's not just a
mat= ter of definition.  There is a security requirement for
any token t= o be usable as a bearer token: it must only
become known to the subject = and the verifier.  So it must be
sent by the asserting party to the= subject, and then from
the subject to the relying party, through channels that
provide confidentiality and authentication of the
dest= ination (such as ordinary TLS connections).  And all
three parties = must keep the bearer token secret.

By the way, I saw in the discussi= on that some existing
implementations are using assertions.  Hopefu= lly they are
using bearer assertions.

Francisco

--0-1075842813-1295677728=:90531-- From phil.hunt@oracle.com Sat Jan 22 08:20:27 2011 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 8C88F3A6974 for ; Sat, 22 Jan 2011 08:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.773 X-Spam-Level: X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 b7Qy2bWTUpGu for ; Sat, 22 Jan 2011 08:20:26 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2F4953A6965 for ; Sat, 22 Jan 2011 08:20:26 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0MGNDX8015702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Jan 2011 16:23:15 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0MFLGZc015741; Sat, 22 Jan 2011 16:23:11 GMT Received: from abhmt010.oracle.com by acsmt355.oracle.com with ESMTP id 945373091295713389; Sat, 22 Jan 2011 08:23:09 -0800 Received: from [192.168.1.12] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 22 Jan 2011 08:23:08 -0800 References: <645956.90531.qm@web55803.mail.re3.yahoo.com> In-Reply-To: <645956.90531.qm@web55803.mail.re3.yahoo.com> Mime-Version: 1.0 (iPhone Mail 8C148a) Content-Type: multipart/alternative; boundary=Apple-Mail-2--421392957 Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (8C148a) From: Phillip Hunt Date: Sat, 22 Jan 2011 08:23:03 -0800 To: "fcorella@pomcor.com" Cc: "oauth@ietf.org" , "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme 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: Sat, 22 Jan 2011 16:20:27 -0000 --Apple-Mail-2--421392957 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My understanding is you can still do it. It is covered by the new other auth= mechanism paragraph.=20 The real question is do we need it for interop purposes or not? We had other methods that didn't fit draft 11 either. So do u spec them all o= r just one mandatory to implement? Phil Sent from my phone.=20 On 2011-01-21, at 22:28, Francisco Corella wrote: > Brian, >=20 > > I guess it's somewhat moot now because client assertions > > have been removed from the latest draft. However, I don't > > believe there anything saying that client assertions had to > > be bearer assertions. Nor would that really have been > > appropriate for the framework spec. >=20 > Ah, so I was right in thinking there was something wrong :-) >=20 > You can only use a bearer assertion (or "could" since > assertions are no longer in the spec). =20 >=20 > If a subject (here, the client) authenticates itself by > sending a single message that contains an assertion, the > assertion cannot be a holder-of-key assertion. A > holder-of-key assertion is an assertion about the holder of > a private key whose corresponding public key or certificate > is contained in the assertion. The subject must confirm > that it has the private key. The subject typically does > that by signing a nonce supplied by the relying party (here, > the authorization server). That party must send the nonce > in an earlier protocol message. >=20 > Actually, an assertion that authenticates the subject by the > mere fact of being presented by the subject is, by > definition, a bearer assertion. That's what "bearer" > means. It means "this assertion is about whoever bears > it (carries it, produces it); the bearer does not have to > present any other proof if its identity". >=20 > > The same is true for extension/URI grant types (formerly > > known as assertion grant types). There is nothing in the > > core OAuth framework spec saying that it is, or has to be, a > > bearer assertion. The SAML Bearer Assertion Grant Type > > Profile is an extension spec that constrains/defines the > > specific use of bearer SAML assertion. To me and some > > others, that seemed like a useful enough use-case to write > > an I-D for, however, the main OAuth spec allows for other > > extensions. A holder of key SAML Assertion, for example, > > might be profiled as a grant type. Or something completely > > non SAML based. >=20 > The same would be true for obtaining an access token by > presenting a SAML assertion as an access grant. It would > have to be a bearer assertion, not a holder-of-key > assertion. >=20 > As for a non-SAML token, it would have to be a bearer token, > by definition of the word "bearer". But it's not just a > matter of definition. There is a security requirement for > any token to be usable as a bearer token: it must only > become known to the subject and the verifier. So it must be > sent by the asserting party to the subject, and then from > the subject to the relying party, through channels that > provide confidentiality and authentication of the > destination (such as ordinary TLS connections). And all > three parties must keep the bearer token secret. >=20 > By the way, I saw in the discussion that some existing > implementations are using assertions. Hopefully they are > using bearer assertions. >=20 > Francisco >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-2--421392957 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
My understanding is you can still do it= . It is covered by the new other auth mechanism paragraph. 
<= br>
The real question is do we need it for interop purposes or not= ?

We had other methods that didn't fit draft 11 either. So= do u spec them all or just one mandatory to implement?

=
Phil

Sent from my phone. 

O= n 2011-01-21, at 22:28, Francisco Corella <fcorella@pomcor.com> wrote:

Brian,

>= I guess it's somewhat moot now because client assertions
> have been r= emoved from the latest draft.  However, I don't
> believe there a= nything saying that client assertions had to
> be bearer assertions.&n= bsp; Nor would that really have been
> appropriate for the framework s= pec.

Ah, so I was right in thinking there was something wrong :-)
=
You can only use a bearer assertion (or "could" since
assertions are n= o longer in the spec). 

If a subject (here, the client) authent= icates itself by
sending a single message that contains an assertion, the=
assertion cannot be a holder-of-key assertion.  A
holder-of-key a= ssertion is an assertion about the holder of
a private key whose correspo= nding public key or certificate
is contained in the assertion.  The s= ubject must confirm
that it has the private key.  The subject typically doesthat by signing a nonce supplied by the relying party (here,
the authori= zation server).  That party must send the nonce
in an earlier protoc= ol message.

Actually, an assertion that authenticates the subject by t= he
mere fact of being presented by the subject is, by
definition, a be= arer assertion.  That's what "bearer"
means.  It means "this as= sertion is about whoever bears
it (carries it, produces it); the bearer d= oes not have to
present any other proof if its identity".

> The= same is true for extension/URI grant types (formerly
> known as asser= tion grant types).  There is nothing in the
> core OAuth framewor= k spec saying that it is, or has to be, a
> bearer assertion.  Th= e SAML Bearer Assertion Grant Type
> Profile is an extension spec that= constrains/defines the
> specific use of bearer SAML assertion.  To me and some
> others, that seemed like a use= ful enough use-case to write
> an I-D for, however, the main OAuth spe= c allows for other
> extensions.  A holder of key SAML Assertion,= for example,
> might be profiled as a grant type.  Or something c= ompletely
> non SAML based.

The same would be true for obtainin= g an access token by
presenting a SAML assertion as an access grant. = ; It would
have to be a bearer assertion, not a holder-of-key
assertio= n.

As for a non-SAML token, it would have to be a bearer token,
by= definition of the word "bearer".  But it's not just a
matter of def= inition.  There is a security requirement for
any token to be usable= as a bearer token: it must only
become known to the subject and the veri= fier.  So it must be
sent by the asserting party to the subject, and= then from
the subject to the relying party, through channels that
provide confidentiality and authentication of the
desti= nation (such as ordinary TLS connections).  And all
three parties mu= st keep the bearer token secret.

By the way, I saw in the discussion t= hat some existing
implementations are using assertions.  Hopefully t= hey are
using bearer assertions.

Francisco

__________= _____________________________________
OAuth mailing list
OAuth@ietf.org
= https://www.ie= tf.org/mailman/listinfo/oauth
= --Apple-Mail-2--421392957-- From fcorella@pomcor.com Sat Jan 22 08:56:58 2011 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 774493A697D for ; Sat, 22 Jan 2011 08:56:58 -0800 (PST) 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 23cAOlPWN1ZQ for ; Sat, 22 Jan 2011 08:56:56 -0800 (PST) Received: from nm8-vm0.bullet.mail.ac4.yahoo.com (nm8-vm0.bullet.mail.ac4.yahoo.com [98.139.52.230]) by core3.amsl.com (Postfix) with SMTP id 9B6E33A6965 for ; Sat, 22 Jan 2011 08:56:56 -0800 (PST) Received: from [98.139.52.191] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 22 Jan 2011 16:59:42 -0000 Received: from [98.139.52.181] by tm4.bullet.mail.ac4.yahoo.com with NNFMP; 22 Jan 2011 16:59:42 -0000 Received: from [127.0.0.1] by omp1064.mail.ac4.yahoo.com with NNFMP; 22 Jan 2011 16:59:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 784196.79279.bm@omp1064.mail.ac4.yahoo.com Received: (qmail 13192 invoked by uid 60001); 22 Jan 2011 16:59:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1295715582; bh=XWpSxguCptfM0W+UyH/VtGDFgZXZL66B/qmg9UcpizM=; h=Message-ID:X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=GU1gfVqG3JkY225DUU8kgk7e/yn3MZPUPyExopK7V3wm89I1Yv4/648EFHJYFAT6O2hQRGpuEG3YvoWeSsTQDKA2Wji7IgHco9Vwp3NbJIzNbOERl3Kz/784oNd33gcIz3spC1spwLkCJ4QruHwM1m1OcYrIFz7VN9zLVQgTF9U= Message-ID: <662062.12932.qm@web55808.mail.re3.yahoo.com> X-YMail-OSG: SRs1xnEVM1mpgVyB7V2pim_6Yqj2SuTgHhpFDwqsIXTCH_z XGhXpUPH84mbdKljM0Rj6cEFEglrNZRviqaICUhQM5DfWs6QPh036ia8m3z5 GobS8qbkYiNQmvY8WWIACYd56zVNMPl_2Or9BMGXCqzKhwtWPkdxHJEzIVsl Auhxb2pDuK9d6NHLTM4XPMBD_Q5Cs4WrdsevCu5gL__7naGiIkdY31rtYJLl 3UWK2TCGK36E3dcNLV6901TuXLjzUR2eV7gJt6w97kH_AktppauXLhL0drQk xwkxWG7Dyu3ferycgN2PkMWy5Pajj4PNJ7Oh7I4rQOovjn8LEI6F0jKPOxWa gSwN0RU2iUUbkpvIU2K._mIg0iFhIgcRliHVUwxw74v4WTMDJT2HzLYDmc_3 SUZ0RD1lfmg-- Received: from [173.198.123.207] by web55808.mail.re3.yahoo.com via HTTP; Sat, 22 Jan 2011 08:59:42 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailClassic/11.4.20 YahooMailWebService/0.8.107.285259 Date: Sat, 22 Jan 2011 08:59:42 -0800 (PST) From: Francisco Corella To: oauth@ietf.org In-Reply-To: <645956.90531.qm@web55803.mail.re3.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1852071281-1295715582=:12932" Cc: "Karen P. Lewison" Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 HTTP Authentication Scheme X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: fcorella@pomcor.com List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jan 2011 16:56:58 -0000 --0-1852071281-1295715582=:12932 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable A correction to my previous message below: a holder-of-key assertion can be= sent in what seems to be a single message if the message is sent over a TL= S connection and the assertion is about the key pair used in the connection= .=A0 Of course that's not really a single message, because there are multip= le messages involved in the TLS handshake, and it's precisely the TLS hands= hake that shows that the subject it is the holder of the private key. Specifically, an assertion sent in the body of an HTTP POST request over a = TLS connection can be used to bind a certificate used as TLS client certifi= cate to additional data about the subject of the certificate.=A0 And an ass= ertion sent in the body of a response to an HTTP request over a TLS connect= ion can be used to bind the certificate used as TLS server certificate to a= dditional data about the subject of the certificate. Francisco --- On Sat, 1/22/11, Francisco Corella wrote: From: Francisco Corella Subject: Re: [OAUTH-WG] Reasons not to remove Client Assertion Credentials = and OAuth2 HTTP Authentication Scheme To: oauth@ietf.org Cc: "Karen P. Lewison" Date: Saturday, January 22, 2011, 6:28 AM Brian, > I guess it's somewhat moot now because client assertions > have been removed from the latest draft.=A0 However, I don't > believe there anything saying that client assertions had to > be bearer assertions.=A0 Nor would that really have been > appropriate for the framework spec. Ah, so I was right in thinking there was something wrong :-) You can only use a bearer assertion (or "could" since assertions are no longer in the spec).=A0=20 If a subject (here, the client) authenticates itself by sending a single message that contains an assertion, the assertion cannot be a holder-of-key assertion.=A0 A holder-of-key assertion is an assertion about the holder of a private key whose corresponding public key or certificate is contained in the assertion.=A0 The subject must=0A confirm that it has the private key.=A0 The subject typically does that by signing a nonce supplied by the relying party (here, the authorization server).=A0 That party must send the nonce in an earlier protocol message. Actually, an assertion that authenticates the subject by the mere fact of being presented by the subject is, by definition, a bearer assertion.=A0 That's what "bearer" means.=A0 It means "this assertion is about whoever bears it (carries it, produces it); the bearer does not have to present any other proof if its identity". > The same is true for extension/URI grant types (formerly > known as assertion grant types).=A0 There is nothing in the > core OAuth framework spec saying that it is, or has to be, a > bearer assertion.=A0 The SAML Bearer Assertion Grant Type > Profile is an extension spec that constrains/defines the > specific use of bearer=0A SAML assertion.=A0 To me and some > others, that seemed like a useful enough use-case to write > an I-D for, however, the main OAuth spec allows for other > extensions.=A0 A holder of key SAML Assertion, for example, > might be profiled as a grant type.=A0 Or something completely > non SAML based. The same would be true for obtaining an access token by presenting a SAML assertion as an access grant.=A0 It would have to be a bearer assertion, not a holder-of-key assertion. As for a non-SAML token, it would have to be a bearer token, by definition of the word "bearer".=A0 But it's not just a matter of definition.=A0 There is a security requirement for any token to be usable as a bearer token: it must only become known to the subject and the verifier.=A0 So it must be sent by the asserting party to the subject, and then from the subject to the relying party, through=0A channels that provide confidentiality and authentication of the destination (such as ordinary TLS connections).=A0 And all three parties must keep the bearer token secret. By the way, I saw in the discussion that some existing implementations are using assertions.=A0 Hopefully they are using bearer assertions. Francisco -----Inline Attachment Follows----- _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --0-1852071281-1295715582=:12932 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --0-1852071281-1295715582=:12932-- From phil.hunt@oracle.com Sun Jan 23 08:43:05 2011 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 33AD73A6912 for ; Sun, 23 Jan 2011 08:43:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, 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 kiQ-VaDt71cM for ; Sun, 23 Jan 2011 08:43:04 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 427973A690B for ; Sun, 23 Jan 2011 08:43:04 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0NGjsQ1029284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 23 Jan 2011 16:45:55 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0NGjoiD027334 for ; Sun, 23 Jan 2011 16:45:54 GMT Received: from abhmt009.oracle.com by acsmt353.oracle.com with ESMTP id 946354211295801102; Sun, 23 Jan 2011 08:45:02 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 Jan 2011 08:45:02 -0800 From: Phil Hunt Content-Type: multipart/alternative; boundary=Apple-Mail-1--333679170 Date: Sun, 23 Jan 2011 08:45:00 -0800 Message-Id: To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [OAUTH-WG] Draft 12 - redirection URI 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: Sun, 23 Jan 2011 16:43:05 -0000 --Apple-Mail-1--333679170 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom section 3.1.1 ... The authorization server SHOULD require the client to pre-register their = redirection URI or at least certain components such as the scheme, host, = port and path. If a redirection URI was registered, the authorization = server MUST compare any redirection URI received at the authorization = endpoint with the registered URI. Why compare? If the first part is correct, then the pre-registered = value SHOULD always be taken. It sounds like the redirection URI is = being used like another secret, which it shouldn't be. Also, if redirect_uri is to be accepted at all (not pre-registered), its = transmission/use spec'd in a secure way so this paragraph isn't needed. Phil phil.hunt@oracle.com --Apple-Mail-1--333679170 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii The authorization server SHOULD = require the client to pre-register their redirection URI or at least = certain components such as the scheme, host, port and path. If a = redirection URI was registered, the authorization server MUST compare = any redirection URI received at the authorization endpoint with the = registered URI.

Why compare?  If the = first part is correct, then the pre-registered value SHOULD always be = taken. It sounds like the redirection URI is being used like = another secret, which it shouldn't be.

Also, if = redirect_uri is to be accepted at all (not pre-registered), its = transmission/use spec'd in a secure way so this paragraph isn't = needed.


= --Apple-Mail-1--333679170-- From torsten@lodderstedt.net Sun Jan 23 10:21:06 2011 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 D961F3A6935 for ; Sun, 23 Jan 2011 10:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2284MbQ9XOpi for ; Sun, 23 Jan 2011 10:21:05 -0800 (PST) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by core3.amsl.com (Postfix) with ESMTP id A78FA3A6932 for ; Sun, 23 Jan 2011 10:21:04 -0800 (PST) Received: from [87.142.248.68] (helo=[192.168.71.49]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Ph4bT-0003ks-9I; Sun, 23 Jan 2011 19:23:55 +0100 Message-ID: <4D3C723A.8020004@lodderstedt.net> Date: Sun, 23 Jan 2011 19:23:54 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Eran Hammer-Lahav References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61CB9@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] redirect URI matching in section 3 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: Sun, 23 Jan 2011 18:21:07 -0000 done Am 21.01.2011 06:38, schrieb Eran Hammer-Lahav: > Whoever is working on the security considerations section, please add this to your list. > > EHL > >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> Of Brian Eaton >> Sent: Saturday, July 10, 2010 11:44 PM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] redirect URI matching in section 3 >> >> Section 3 says [[ provide guidance on how to perform matching ]]. >> >> I can write the guidance on performing redirect URI matching, but it varies >> per profile. >> >> User-Agent profile with registered client: matching is critical, MUST verify is >> appropriate >> >> Web server profile with client secret you trust: matching is not critical. >> Matching provides some extra security. MAY is appropriate. >> MUST is really bad, since it prevents clients from moving redirect URIs. >> >> Any profile where you don't trust the client secret (e.g. installed >> apps): Redirect URI matching is useless. SHOULD NOT is appropriate. >> >> So this is another case where the client needs to pass some indicator to the >> server (either via type= parameter, or as policy associated with client_id) of >> the environment in which it is running. The type parameter needs to signal: >> - how the authorization server passes data (fragment or query string) >> - what data is passed (access token, or just verification code) >> >> Here's some proposed language on redirect URI matching. >> >> New Section 3.1: Overview of Callback URL Authentication >> >> The OAuth 2 protocol distributes authorization credentials to web-based >> applications by redirecting the user-agent to the client with some form of >> authorization credential on the URL. The authorization credential is either an >> access token, or a authorization code. In either case, authenticating the URL >> to which the credential is returned is critical to the security of the protocol. >> >> Credentials returned on redirect URLs may leak in several ways: >> - Referer headers sent by the browser to untrusted third-party web sites >> - open redirectors >> - web server log files >> - browser history >> >> Authorization servers have several techniques available for authenticating >> callback URLs and defending against those leaks: >> - using client authentication credentials to authenticate callback URLs >> - callback URL white-listing >> - passing authorization credentials on URI fragments >> - issuing short-lived credentials to ease recovery in the event of compromise >> >> 3.1.1 Authorization Policy >> >> In certain circumstances the Authorization Server is not able to perfectly >> authenticate the callback URL. For example, multiple installed applications >> may use the same callback URL, and there is no way for the Authorization >> Server to reliably distinguish among them. >> Authorization Servers deal with this ambiguity by choosing different policies >> on when to issue authorization credentials. >> >> If the authorization server is able to authenticate the callback URL with a high >> degree of confidence >> - the authorization server MAY decline to prompt the user to grant >> authorization, immediately rejecting the authorization request. >> - the authorization server MAY issue an authorization credential after >> prompting the user. >> - the authorization server MAY issue a new authorization credential without >> prompting the user, if the authorization server knows that the user has >> previously approved this client. >> >> If the authorization server is not able to authenticate the callback URL: >> - the authorization server MAY decline to prompt the user to grant >> authorization, immediately rejecting the authorization request. >> - the authorization server MAY issue an authorization credential after >> prompting the user. >> - the authorization server MUST NOT issue an authorization credential >> without prompting the user. >> >> 3.1.2 Callback URL Authentication Techniques >> >> Client Credentials MAY be used to authenticate callback URLs. If an >> Authorization Server wishes to authenticate callback URLs with client >> credentials, all of the following conditions MUST be met: >> >> - the client credentials MUST have been issued to a web application with a >> server-side component. >> - the Authorization Server MUST believe that the client credentials are stored >> securely. >> - the Authorization Server MUST return only an authorization code to the >> callback URL. An access token MUST NOT be returned. >> >> In all other circumstances, the Authorization Server MUST use callback URL >> white-listing to authenticate callback URLs. However, appropriate callback >> URL white-listing varies for different client environments. >> >> There are various techniques for callback URL white-listing. The list in this >> document is not exhaustive, and Authorization Servers MAY implement >> other techniques at their discretion. This document will consider the >> following approaches: >> >> - domain white-listing >> Authorization Servers white-list entire domains, e.g. >> '*.example.com'. Authorization servers may include the protocol in this >> white-list, e.g. 'all https web sites on *.example.com'. Any page on any host >> in that domain is accepted. >> >> - host white-listing >> Authorization Servers white-list entire hosts, e.g. >> 'www.example.com'. Authorization servers may include the protocol in the >> white-list, e.g. 'https://www.example.com'. Any page on that host is >> accepted. >> >> - path white-listing >> Authorization Servers white-list specific paths on a particular host, e.g. >> 'https://www.example.com/path'. Any page beneath that path is accepted. >> >> - page white-listing >> Authorization Servers white-list a specific page on a particular host, e.g. >> 'https://www.example.com/path/page'. The query string and URI fragment >> may vary, but all other components of the URL are fixed and must match that >> page. >> >> - full URL white-listing >> Authorization Servers white-list a specific URL, e.g. >> 'https://www.example.com/path/page?query'. Any callback URL that does >> not completely match that URL is rejected. >> >> >> The following sections offer guidance to Authorization Servers and Client >> developers on how to handle callback URL authentication. For better >> security, Authorization Servers and Clients should rely on a combination of >> client credentials and callback URL white-listing to authenticate callback URLs. >> >> >> Section 3.1.3 Secure Callback URLs for the Web Server Profile >> >> Client application developers using the web server profile should take care >> that their callback URLs preserve the security of the profile. >> >> Callback URL pages MUST NOT link or or redirect to untrusted content from >> those pages, since the authorization code may leak in the referer header. >> >> Callback URL pages MUST NOT forward the authorization code to an >> untrusted page. >> >> Callback URL pages SHOULD redirect to a trusted page immediately after >> receiving the authorization code in the URL. This prevents the authorization >> code from remaining in the browser history, or from inadvertently leaking in >> a referer header. >> >> Callback URL pages SHOULD NOT log the authorization code. >> >> Callback URL pages SHOULD be CSRF protected. (TODO: dig up the language >> in OAuth 1.0a, it was pretty good, I think...) >> >> >> >> Section 3.1.4 Callback URL Authentication for the Web Server Profile >> >> The web server profile returns an authorization code on the callback URL. >> Authorization codes returned on callback URLs are very prone to leaking in >> referer headers, open redirectors, web server log files, and browser history. >> >> Authorization Servers MAY omit callback URL white-listing, but only if they >> are using client credentials to authenticate callback URLs. If client credentials >> are being used, any type of callback URL white-listing will improve security. >> >> Different types of white-listing provide different levels of security. >> >> - domain- and host- whitelisting >> Domain and host white-listing rules are very broad, and so are very >> vulnerable to the leaks discussed in section 3.1. Domain- and host- white- >> listing MUST NOT be used alone. Domain and host white-listing MAY be used >> in combination with using client credentials to authenticate callback URLs. >> >> - path white-listing >> Path white-listing is somewhat broad, and may be vulnerable to the leaks >> discussed in section 3.1. Path white-listing MUST NOT be used alone. Path >> white-listing MAY be used in combination with using client credentials to >> authenticate callback URLs. >> When using path white-listing, Authorization servers MUST defend against >> directory traversal attacks by canonicalizing the path. >> Appropriate path canonicalization algorithms vary for different types of web- >> servers, e.g. "\..\" may represent a parent directory in some web servers, >> and not in others. >> >> - page and URL white-listing >> Page and URL white-listing are very specific, but may still be vulnerable to >> some of the leaks discussed in section 3.1 if the callback URL page does not >> follow the security recommendations in section 3.1.3. These types of white- >> listing MAY be used alone, or in combination with client credentials to >> authenticate callback URLs. >> >> When full URL white-listing is used, Authorization Servers MUST allow the >> "state" query parameter to vary. >> >> >> Section 3.1.4 Secure Callback URLs for the User-Agent Profile >> >> Client application developers using the user-agent profile should take care >> that their callback URLs preserve the security of the profile. >> Because the user-agent profile returns an access token on the URI fragment, >> many types of leaks are less likely. However, incorrect code can still leak the >> authorization credentials. >> >> Callback URL pages MUST NOT forward the access token or authorization >> code to an untrusted page. >> >> Callback URLs rendered in a top-level browser window cannot prevent the >> access token from remaining in the browser history. Whenever possible, >> client applications SHOULD use an iframe to receive callbacks so that the >> access token does not appear in the browser history. [[Note that >> Authorization Servers SHOULD NOT allow their approval pages to be iframed >> due to the risk of click-jacking attacks, >> so this only works for immediate mode. Browser security gets >> complicated.]] >> >> If callback URLs must be rendered in a top-level browser window, client >> applications SHOULD redirect immediately after receiving the >> callback URL to remove the access token from the URL bar. This >> prevents the user from inadvertently copying their access token. >> >> Callback URL pages SHOULD be CSRF protected. (TODO: dig up the language >> in OAuth 1.0a, it was pretty good, I think...) >> >> >> Section 3.1.4 Callback URL Authentication for the User-Agent profile >> >> Because the user-agent profile returns an access token on the callback URL, >> client credentials cannot be used to authenticate the callback URL. Callback >> URL white-listing is the only possible way to authenticate the callback URL. >> However, because the authorization credentials are always returned on the >> URL fragment, the opportunity for leaking credentials via referer headers >> and open redirectors is reduced. >> >> Different types of white-listing provide different levels of security. >> >> - domain- white-listing >> Domain white-listing is very broad. Domain white-listing MUST NOT be >> used, because of the risk of malicious code running under some host in the >> domain. >> >> - host- white-listing >> Host white-listing is very broad. Authorization servers should be >> conservative in choosing which hosts they trust, but host white-listing MAY >> be used. >> >> - path white-listing >> Path white-listing is somewhat broad. Path white-listing MAY be used. >> When using path white-listing, Authorization servers MUST defend against >> directory traversal attacks by canonicalizing the path. >> Appropriate path canonicalization algorithms vary for different types of web- >> servers, e.g. "\..\" may represent a parent directory in some web servers, >> and not in others. >> >> - page and URL white-listing >> Page and URL white-listing are very specific. These types of white-listing >> MAY be used >> >> When full URL white-listing is used, Authorization Servers MUST allow the >> "state" query parameter to vary. >> >> Cheers, >> Brian >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Sun Jan 23 12:20:38 2011 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 CCBA03A697A for ; Sun, 23 Jan 2011 12:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, 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 y7AXevBOYFRm for ; Sun, 23 Jan 2011 12:20:37 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id C9C233A6971 for ; Sun, 23 Jan 2011 12:20:37 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0NKNSwJ009519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 23 Jan 2011 20:23:30 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0NINCla031565 for ; Sun, 23 Jan 2011 20:23:28 GMT Received: from abhmt002.oracle.com by acsmt355.oracle.com with ESMTP id 946508591295814206; Sun, 23 Jan 2011 12:23:26 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 23 Jan 2011 12:23:25 -0800 From: Phil Hunt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 23 Jan 2011 12:23:22 -0800 Message-Id: <5A4B067E-683C-4FA0-BC9C-26BF2E1F5512@oracle.com> To: "oauth@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [OAUTH-WG] Draft 12 - Protocol flow not clear yet 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: Sun, 23 Jan 2011 20:20:38 -0000 Section 4 seems to inter-mixes obtaining authorization grant with = obtaining tokens. Yes it is called "Request an Access Token". This = seems particularly confusing after reading section 3 that separates = requesting authorization from token end-points. My first reaction was, = is there a section missing? After I began reading section 4 it starts talking about obtaining = authorization. Should section 4 be "protocol flow"? I think it can work with an intro explaining the protocol at a high = level. E.g. 3 steps: 1. Obtain authorization from Authorization Endpoint 2. Obtain access token from Token Endpoint 3. Access resource Then for each flow pattern, show how steps 1, 2, and 3 are completed. = For 2-legged cases, indicate how step 1 is completed implicitly (e.g. by = policy, previous arrangement, or OOB). It might also be better if section 5 became a sub-section within 4.0. I = see why it is separate, since the last step is always the same. But = still it added to my initial confusion. =20 The general impression I have is draft 12, is half way to a flow = orientation as suggested by Eran.=20 ps. I still remain neutral on structure (end-point vs. flow) as long as = it is clear. Regards, =20 Phil phil.hunt@oracle.com From torsten@lodderstedt.net Mon Jan 24 13:07:10 2011 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 00B873A696D for ; Mon, 24 Jan 2011 13:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.013, 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 9GiyYbzGwfzW for ; Mon, 24 Jan 2011 13:07:09 -0800 (PST) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by core3.amsl.com (Postfix) with ESMTP id 2BF253A696B for ; Mon, 24 Jan 2011 13:07:08 -0800 (PST) Received: from [79.253.32.4] (helo=[192.168.71.49]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PhTfn-0007Bf-BA for oauth@ietf.org; Mon, 24 Jan 2011 22:10:03 +0100 Message-ID: <4D3DEAAA.6070201@lodderstedt.net> Date: Mon, 24 Jan 2011 22:10:02 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: OAuth WG Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint? 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: Mon, 24 Jan 2011 21:07:10 -0000 Hi all, I'm currently thinking about the integration of existing HTTP authentication schemes with OAuth 2.0 for the purpose of end-user authentication on the tokens endpoint. Possible candidates are "Digest" for challenge-response-based username/password authentication and "Spnego" for Kerberos-based authentication. Direct support for both could be beneficially in enterprise and other security sensitive deployments. An direct integration with the tokens endpoint would allow to leverage existing implementations and infrastructure for OAuth/HTTP-based architectures. For example, HTTPClient has direct support for Spnego-Authentication. Both HTTP authentication schemes use dedicated WWW-Authenticate and Authorization headers for passing credential and other data between client and server. OAuth in contrast uses grant types to indicate the authentication method, credentials are passed as URI query parameters and it lacks any discovery of available authentication methods/ grant types. How could one integrate existing schemes into that design? What is our story? Do we need to define a special grant type "HTTP authorization"? Shall Authorization headers overrule URI parameters? Any ideas of the WG are higly appreciated. regards, Torsten. From eran@hueniverse.com Mon Jan 24 14:23:03 2011 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 471E53A6994 for ; Mon, 24 Jan 2011 14:23:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 eWBfxU9ujSBs for ; Mon, 24 Jan 2011 14:23:01 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9EA503A682C for ; Mon, 24 Jan 2011 14:23:01 -0800 (PST) Received: (qmail 12450 invoked from network); 24 Jan 2011 22:25:56 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Jan 2011 22:25:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 24 Jan 2011 15:25:53 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt , OAuth WG Date: Mon, 24 Jan 2011 15:25:38 -0700 Thread-Topic: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint? Thread-Index: Acu8CxUPxrEadCthSF2MIabOKoDtHAACgeWQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> In-Reply-To: <4D3DEAAA.6070201@lodderstedt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint? 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: Mon, 24 Jan 2011 22:23:03 -0000 This is pretty straight-forward. There are no special parameters to indicat= ed which client authentication is being used. It's either there or not, usi= ng whatever the server supports. Simply have the token endpoint return a 401 with these WWW-Authenticate hea= ders. As long as you make it clear how to make between the client identifie= r and the credentials used, you are set. For example, a token response can return: 401 Unauthorized WWW-Authenticate: Basic realm=3D"example" WWW-Authenticate: Digest realm=3D"example" There is no discovery for support for the client_id and client_secret param= eters. The client can simply try it or hardcode it based on the server's do= cumentation. Does this help? EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Monday, January 24, 2011 1:10 PM > To: OAuth WG > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > endpoint? >=20 > Hi all, >=20 > I'm currently thinking about the integration of existing HTTP authenticat= ion > schemes with OAuth 2.0 for the purpose of end-user authentication on the > tokens endpoint. Possible candidates are "Digest" > for challenge-response-based username/password authentication and > "Spnego" for Kerberos-based authentication. Direct support for both could > be beneficially in enterprise and other security sensitive deployments. >=20 > An direct integration with the tokens endpoint would allow to leverage > existing implementations and infrastructure for OAuth/HTTP-based > architectures. For example, HTTPClient has direct support for Spnego- > Authentication. >=20 > Both HTTP authentication schemes use dedicated WWW-Authenticate and > Authorization headers for passing credential and other data between clien= t > and server. OAuth in contrast uses grant types to indicate the authentica= tion > method, credentials are passed as URI query parameters and it lacks any > discovery of available authentication methods/ grant types. >=20 > How could one integrate existing schemes into that design? What is our > story? Do we need to define a special grant type "HTTP authorization"? > Shall Authorization headers overrule URI parameters? >=20 > Any ideas of the WG are higly appreciated. >=20 > regards, > Torsten. >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From phil.hunt@oracle.com Mon Jan 24 14:54:11 2011 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 25B453A69B4 for ; Mon, 24 Jan 2011 14:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 oXcy2o--j5Wd for ; Mon, 24 Jan 2011 14:54:10 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 125BA3A697B for ; Mon, 24 Jan 2011 14:54:10 -0800 (PST) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0OMv3N9015806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Jan 2011 22:57:04 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0OGAGCj013554; Mon, 24 Jan 2011 22:57:02 GMT Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 988078821295909769; Mon, 24 Jan 2011 14:56:09 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Jan 2011 14:56:09 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 24 Jan 2011 14:56:07 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <57B41F1A-F0C9-4E85-BB18-8D0BA35041D9@oracle.com> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint? 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: Mon, 24 Jan 2011 22:54:11 -0000 Why not have the token server specify a form based authentication for = OAuth token requests?=20 WWW-Authenticate: Form url=3D"/tokenrequest.jsp" Thus, a server could respond: 401 Unauthorized WWW-Authenticate: Basic realm=3D"example" WWW-Authenticate: Digest realm=3D"example" WWW-Authenticate: Form url=3D"/tokenrequest.jsp",realm=3D"example" Normally, a form would have caused a redirect, but in this case we = aren't talking about browser based clients so the redirect doesn't make = sense. This gives the clients a choice and a way to discover parameters = (if really needed). By parsing the form, it could discover what form = parameters are required. I suspect as Eran indicates below, this = wouldn't happen to often as site server documentation would already make = this clear. Phil phil.hunt@oracle.com On 2011-01-24, at 2:25 PM, Eran Hammer-Lahav wrote: > This is pretty straight-forward. There are no special parameters to = indicated which client authentication is being used. It's either there = or not, using whatever the server supports. >=20 > Simply have the token endpoint return a 401 with these = WWW-Authenticate headers. As long as you make it clear how to make = between the client identifier and the credentials used, you are set. >=20 > For example, a token response can return: >=20 > 401 Unauthorized > WWW-Authenticate: Basic realm=3D"example" > WWW-Authenticate: Digest realm=3D"example" >=20 > There is no discovery for support for the client_id and client_secret = parameters. The client can simply try it or hardcode it based on the = server's documentation. >=20 > Does this help? >=20 > EHL >=20 >> -----Original Message----- >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On = Behalf >> Of Torsten Lodderstedt >> Sent: Monday, January 24, 2011 1:10 PM >> To: OAuth WG >> Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >> endpoint? >>=20 >> Hi all, >>=20 >> I'm currently thinking about the integration of existing HTTP = authentication >> schemes with OAuth 2.0 for the purpose of end-user authentication on = the >> tokens endpoint. Possible candidates are "Digest" >> for challenge-response-based username/password authentication and >> "Spnego" for Kerberos-based authentication. Direct support for both = could >> be beneficially in enterprise and other security sensitive = deployments. >>=20 >> An direct integration with the tokens endpoint would allow to = leverage >> existing implementations and infrastructure for OAuth/HTTP-based >> architectures. For example, HTTPClient has direct support for Spnego- >> Authentication. >>=20 >> Both HTTP authentication schemes use dedicated WWW-Authenticate and >> Authorization headers for passing credential and other data between = client >> and server. OAuth in contrast uses grant types to indicate the = authentication >> method, credentials are passed as URI query parameters and it lacks = any >> discovery of available authentication methods/ grant types. >>=20 >> How could one integrate existing schemes into that design? What is = our >> story? Do we need to define a special grant type "HTTP = authorization"? >> Shall Authorization headers overrule URI parameters? >>=20 >> Any ideas of the WG are higly appreciated. >>=20 >> regards, >> Torsten. >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Mon Jan 24 15:09:17 2011 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 5C2483A6995 for ; Mon, 24 Jan 2011 15:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 J30daddgr7zy for ; Mon, 24 Jan 2011 15:09:15 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 913B53A697B for ; Mon, 24 Jan 2011 15:09:15 -0800 (PST) Received: (qmail 5368 invoked from network); 24 Jan 2011 23:12:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Jan 2011 23:12:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 24 Jan 2011 16:12:03 -0700 From: Eran Hammer-Lahav To: Phil Hunt Date: Mon, 24 Jan 2011 16:11:47 -0700 Thread-Topic: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint? Thread-Index: Acu8GgbdFPCqHmk5Q9m8WuZ6QIIkpAAAFfHg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6222F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <57B41F1A-F0C9-4E85-BB18-8D0BA35041D9@oracle.com> In-Reply-To: <57B41F1A-F0C9-4E85-BB18-8D0BA35041D9@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint? 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: Mon, 24 Jan 2011 23:09:17 -0000 I am not sure I understand this exactly, but I don't see the need. Basicall= y, the token endpoint requires client authentication (yeah, with exceptions= ). The spec provides one super-simple way to accomplish that using form-enc= oded parameters, but that's really focused on the hardcoded clients - those= pointed at known services. While libraries will support the two parameters= , it is unlikely that clients will use it to obtain a token from an unfamil= iar server (since they are not registered). IOW, the client password credential authentication described in the spec is= a useful hack for the common needs most API developers today have, based o= n existing API keys used. I would hate see this expanded to more hack-ish c= lient authentication schemes using parameters. In general, alternative clie= nt authentication methods (which have nothing to do directly with the two p= arameters), should be defined or adopted for client authentication using no= rmal HTTP authentication headers. The way to think about this is to remove client authentication from the tok= en endpoint and just assume the server doesn't care about client identity. = You give it a grant and get back an access token. Now, since we do care abo= ut client identity, we add client authentication *on-top* of the endpoint. = The two parameters are therefore a hack which adds authentication into the = endpoint. New schemes should work outside the request. EHL > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Monday, January 24, 2011 2:56 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > endpoint? >=20 > Why not have the token server specify a form based authentication for > OAuth token requests? >=20 > WWW-Authenticate: Form url=3D"/tokenrequest.jsp" >=20 > Thus, a server could respond: > 401 Unauthorized > WWW-Authenticate: Basic realm=3D"example" > WWW-Authenticate: Digest realm=3D"example" > WWW-Authenticate: Form url=3D"/tokenrequest.jsp",realm=3D"example" >=20 > Normally, a form would have caused a redirect, but in this case we aren't > talking about browser based clients so the redirect doesn't make sense. = This > gives the clients a choice and a way to discover parameters (if really ne= eded). > By parsing the form, it could discover what form parameters are required.= I > suspect as Eran indicates below, this wouldn't happen to often as site se= rver > documentation would already make this clear. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-01-24, at 2:25 PM, Eran Hammer-Lahav wrote: >=20 > > This is pretty straight-forward. There are no special parameters to ind= icated > which client authentication is being used. It's either there or not, usin= g > whatever the server supports. > > > > Simply have the token endpoint return a 401 with these WWW- > Authenticate headers. As long as you make it clear how to make between > the client identifier and the credentials used, you are set. > > > > For example, a token response can return: > > > > 401 Unauthorized > > WWW-Authenticate: Basic realm=3D"example" > > WWW-Authenticate: Digest realm=3D"example" > > > > There is no discovery for support for the client_id and client_secret > parameters. The client can simply try it or hardcode it based on the serv= er's > documentation. > > > > Does this help? > > > > EHL > > > >> -----Original Message----- > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >> Behalf Of Torsten Lodderstedt > >> Sent: Monday, January 24, 2011 1:10 PM > >> To: OAuth WG > >> Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > >> endpoint? > >> > >> Hi all, > >> > >> I'm currently thinking about the integration of existing HTTP > >> authentication schemes with OAuth 2.0 for the purpose of end-user > >> authentication on the tokens endpoint. Possible candidates are "Digest= " > >> for challenge-response-based username/password authentication and > >> "Spnego" for Kerberos-based authentication. Direct support for both > >> could be beneficially in enterprise and other security sensitive > deployments. > >> > >> An direct integration with the tokens endpoint would allow to > >> leverage existing implementations and infrastructure for > >> OAuth/HTTP-based architectures. For example, HTTPClient has direct > >> support for Spnego- Authentication. > >> > >> Both HTTP authentication schemes use dedicated WWW-Authenticate > and > >> Authorization headers for passing credential and other data between > >> client and server. OAuth in contrast uses grant types to indicate the > >> authentication method, credentials are passed as URI query parameters > >> and it lacks any discovery of available authentication methods/ grant > types. > >> > >> How could one integrate existing schemes into that design? What is > >> our story? Do we need to define a special grant type "HTTP > authorization"? > >> Shall Authorization headers overrule URI parameters? > >> > >> Any ideas of the WG are higly appreciated. > >> > >> regards, > >> Torsten. > >> > >> > >> _______________________________________________ > >> OAuth mailing 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 Mon Jan 24 15:14:58 2011 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 A8E5D3A699F for ; Mon, 24 Jan 2011 15:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.044, 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 4IN28NDyKxRM for ; Mon, 24 Jan 2011 15:14:57 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id AC9A03A697B for ; Mon, 24 Jan 2011 15:14:57 -0800 (PST) Received: (qmail 16208 invoked from network); 24 Jan 2011 23:17:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Jan 2011 23:17:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 24 Jan 2011 16:17:51 -0700 From: Eran Hammer-Lahav To: Phil Hunt , "oauth@ietf.org WG" Date: Mon, 24 Jan 2011 16:17:35 -0700 Thread-Topic: [OAUTH-WG] Draft 12 - redirection URI Thread-Index: Acu7HQUrVWOQTmuSS9KEAEfInq5UBwA/9MJg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62231@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62231P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft 12 - redirection URI 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: Mon, 24 Jan 2011 23:14:58 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62231P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The way this is usually implemented is that everything but the query is fix= ed. EHL From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of P= hil Hunt Sent: Sunday, January 23, 2011 8:45 AM To: oauth@ietf.org WG Subject: [OAUTH-WG] Draft 12 - redirection URI >From section 3.1.1 ... The authorization server SHOULD require the client to pre-register their re= direction URI or at least certain components such as the scheme, host, port= and path. If a redirection URI was registered, the authorization server MU= ST compare any redirection URI received at the authorization endpoint with = the registered URI. Why compare? If the first part is correct, then the pre-registered value S= HOULD always be taken. It sounds like the redirection URI is being used lik= e another secret, which it shouldn't be. Also, if redirect_uri is to be accepted at all (not pre-registered), its tr= ansmission/use spec'd in a secure way so this paragraph isn't needed. Phil phil.hunt@oracle.com --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62231P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The way t= his is usually implemented is that everything but the query is fixed.<= /o:p>

 

EHL

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
Sent: Sunday, January 23, 2011 8:45 AM
To: = oauth@ietf.org WG
Subject: [OAUTH-WG] Draft 12 - redirection URI<= o:p>

 

=

From section 3.1.1 ...

<= div>

The authorization server SHOULD require the client to pre-register their = redirection URI or at least certain components such as the scheme, host, po= rt and path. If a redirection URI was registered, the authorization server = MUST compare any redirection URI received at the authorization endpoint wit= h the registered URI.

 

Why compare? &nb= sp;If the first part is correct, then the pre-registered value SHOULD alway= s be taken. It sounds like the redirection URI is being used like anot= her secret, which it shouldn't be.

 

Also, if redirec= t_uri is to be accepted at all (not pre-registered), its transmission/use s= pec'd in a secure way so this paragraph isn't needed.

<= div>

 

 

 = --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62231P3PW5EX1MB01E_-- From phil.hunt@oracle.com Mon Jan 24 15:37:14 2011 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 B0C9F3A69B5 for ; Mon, 24 Jan 2011 15:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, 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 aYLNwHfnavkB for ; Mon, 24 Jan 2011 15:37:13 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 2ED453A6995 for ; Mon, 24 Jan 2011 15:37:13 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0ONe5oY009182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 24 Jan 2011 23:40:07 GMT Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0OL8cIJ002423; Mon, 24 Jan 2011 23:40:04 GMT Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 950104811295912369; Mon, 24 Jan 2011 15:39:29 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Jan 2011 15:39:28 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Phil Hunt In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6222F@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Mon, 24 Jan 2011 15:39:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <57B41F1A-F0C9-4E85-BB18-8D0BA35041D9@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6222F@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint? 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: Mon, 24 Jan 2011 23:37:14 -0000 I think the problem comes up if you want to authenticate using some = other means (e.g. client_assertion) using form based authentication. At = that point separation between the token end-point and platform security = is not clear. The client_id and client_secret approach also has the = same issue of not separating client authentication from the token = request. One possible flow might be: Step 1: client: request token (no client credential supplied) Step 2: server responds with authentication required, returns HTTP 401 = as below 401 Unauthorized WWW-Authenticate: Basic realm=3D"tokenSvc" WWW-Authenticate: Digest realm=3D"tokenSvc" WWW-Authenticate: Form url=3D"/clientAuthenticate.jsp",realm=3D"tokenSvc" Step 3: client elects form based authentication by responding to the = form returned from clientAuthenticate.jsp. For example, the form might = require client_assertion, or other form based authentication approaches. Step 4: server authenticates and returns a "client" token used token = requests. Step 5: client goes to original token endpoint and by client = authorization token (in Authorization header) and original request. Sure the spec says client_id and secret, but doesn't allow for the form = to specify other required elements the site wants to impose. =20 By actually asking for the form, the client can discover what is needed. = Also, steps 1-4 might only have to be done relatively infrequently. = Once a client is authenticated, it could make multiple OAuth token = requests for multiple grant codes. Another variation (combined token and client auth) is a case where = authentication field and token request are combined in one form. Not = sure if WWW-Authenticate should indicate that variation.=20 Phil phil.hunt@oracle.com On 2011-01-24, at 3:11 PM, Eran Hammer-Lahav wrote: > I am not sure I understand this exactly, but I don't see the need. = Basically, the token endpoint requires client authentication (yeah, with = exceptions). The spec provides one super-simple way to accomplish that = using form-encoded parameters, but that's really focused on the = hardcoded clients - those pointed at known services. While libraries = will support the two parameters, it is unlikely that clients will use it = to obtain a token from an unfamiliar server (since they are not = registered). >=20 > IOW, the client password credential authentication described in the = spec is a useful hack for the common needs most API developers today = have, based on existing API keys used. I would hate see this expanded to = more hack-ish client authentication schemes using parameters. In = general, alternative client authentication methods (which have nothing = to do directly with the two parameters), should be defined or adopted = for client authentication using normal HTTP authentication headers. >=20 > The way to think about this is to remove client authentication from = the token endpoint and just assume the server doesn't care about client = identity. You give it a grant and get back an access token. Now, since = we do care about client identity, we add client authentication *on-top* = of the endpoint. The two parameters are therefore a hack which adds = authentication into the endpoint. New schemes should work outside the = request. >=20 > EHL >=20 >=20 >> -----Original Message----- >> From: Phil Hunt [mailto:phil.hunt@oracle.com] >> Sent: Monday, January 24, 2011 2:56 PM >> To: Eran Hammer-Lahav >> Cc: Torsten Lodderstedt; OAuth WG >> Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with = tokens >> endpoint? >>=20 >> Why not have the token server specify a form based authentication for >> OAuth token requests? >>=20 >> WWW-Authenticate: Form url=3D"/tokenrequest.jsp" >>=20 >> Thus, a server could respond: >> 401 Unauthorized >> WWW-Authenticate: Basic realm=3D"example" >> WWW-Authenticate: Digest realm=3D"example" >> WWW-Authenticate: Form url=3D"/tokenrequest.jsp",realm=3D"example" >>=20 >> Normally, a form would have caused a redirect, but in this case we = aren't >> talking about browser based clients so the redirect doesn't make = sense. This >> gives the clients a choice and a way to discover parameters (if = really needed). >> By parsing the form, it could discover what form parameters are = required. I >> suspect as Eran indicates below, this wouldn't happen to often as = site server >> documentation would already make this clear. >>=20 >> Phil >> phil.hunt@oracle.com >>=20 >>=20 >>=20 >>=20 >> On 2011-01-24, at 2:25 PM, Eran Hammer-Lahav wrote: >>=20 >>> This is pretty straight-forward. There are no special parameters to = indicated >> which client authentication is being used. It's either there or not, = using >> whatever the server supports. >>>=20 >>> Simply have the token endpoint return a 401 with these WWW- >> Authenticate headers. As long as you make it clear how to make = between >> the client identifier and the credentials used, you are set. >>>=20 >>> For example, a token response can return: >>>=20 >>> 401 Unauthorized >>> WWW-Authenticate: Basic realm=3D"example" >>> WWW-Authenticate: Digest realm=3D"example" >>>=20 >>> There is no discovery for support for the client_id and = client_secret >> parameters. The client can simply try it or hardcode it based on the = server's >> documentation. >>>=20 >>> Does this help? >>>=20 >>> EHL >>>=20 >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Torsten Lodderstedt >>>> Sent: Monday, January 24, 2011 1:10 PM >>>> To: OAuth WG >>>> Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >>>> endpoint? >>>>=20 >>>> Hi all, >>>>=20 >>>> I'm currently thinking about the integration of existing HTTP >>>> authentication schemes with OAuth 2.0 for the purpose of end-user >>>> authentication on the tokens endpoint. Possible candidates are = "Digest" >>>> for challenge-response-based username/password authentication and >>>> "Spnego" for Kerberos-based authentication. Direct support for both >>>> could be beneficially in enterprise and other security sensitive >> deployments. >>>>=20 >>>> An direct integration with the tokens endpoint would allow to >>>> leverage existing implementations and infrastructure for >>>> OAuth/HTTP-based architectures. For example, HTTPClient has direct >>>> support for Spnego- Authentication. >>>>=20 >>>> Both HTTP authentication schemes use dedicated WWW-Authenticate >> and >>>> Authorization headers for passing credential and other data between >>>> client and server. OAuth in contrast uses grant types to indicate = the >>>> authentication method, credentials are passed as URI query = parameters >>>> and it lacks any discovery of available authentication methods/ = grant >> types. >>>>=20 >>>> How could one integrate existing schemes into that design? What is >>>> our story? Do we need to define a special grant type "HTTP >> authorization"? >>>> Shall Authorization headers overrule URI parameters? >>>>=20 >>>> Any ideas of the WG are higly appreciated. >>>>=20 >>>> regards, >>>> Torsten. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >=20 From eran@hueniverse.com Mon Jan 24 15:39:43 2011 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 DACF93A69B5 for ; Mon, 24 Jan 2011 15:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 fz2TCkaYKYCO for ; Mon, 24 Jan 2011 15:39:42 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 7A92C3A6995 for ; Mon, 24 Jan 2011 15:39:42 -0800 (PST) Received: (qmail 24104 invoked from network); 24 Jan 2011 23:42:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 24 Jan 2011 23:42:36 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Mon, 24 Jan 2011 16:42:36 -0700 From: Eran Hammer-Lahav To: Phil Hunt Date: Mon, 24 Jan 2011 16:42:20 -0700 Thread-Topic: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint? Thread-Index: Acu8IAkf+15yOI6wRzi3XUoV/BPqGgAACCSA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62247@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <57B41F1A-F0C9-4E85-BB18-8D0BA35041D9@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6222F@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens endpoint? 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: Mon, 24 Jan 2011 23:39:43 -0000 My point is that for client_id/client_secret this is not needed because cli= ents are only likely to use it when dealing with a known server with well-k= nown characteristics. Those defining other schemes, including client_assert= ion will need to figure out their client profile and how to address its nee= ds. EHL > -----Original Message----- > From: Phil Hunt [mailto:phil.hunt@oracle.com] > Sent: Monday, January 24, 2011 3:39 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > endpoint? >=20 > I think the problem comes up if you want to authenticate using some other > means (e.g. client_assertion) using form based authentication. At that p= oint > separation between the token end-point and platform security is not clear= . > The client_id and client_secret approach also has the same issue of not > separating client authentication from the token request. >=20 > One possible flow might be: >=20 > Step 1: client: request token (no client credential supplied) Step 2: ser= ver > responds with authentication required, returns HTTP 401 as below > 401 Unauthorized > WWW-Authenticate: Basic realm=3D"tokenSvc" > WWW-Authenticate: Digest realm=3D"tokenSvc" > WWW-Authenticate: Form url=3D"/clientAuthenticate.jsp",realm=3D"tokenSvc" >=20 > Step 3: client elects form based authentication by responding to the form > returned from clientAuthenticate.jsp. For example, the form might require > client_assertion, or other form based authentication approaches. >=20 > Step 4: server authenticates and returns a "client" token used token > requests. > Step 5: client goes to original token endpoint and by client authorizatio= n > token (in Authorization header) and original request. >=20 > Sure the spec says client_id and secret, but doesn't allow for the form t= o > specify other required elements the site wants to impose. >=20 > By actually asking for the form, the client can discover what is needed. = Also, > steps 1-4 might only have to be done relatively infrequently. Once a clie= nt is > authenticated, it could make multiple OAuth token requests for multiple > grant codes. >=20 > Another variation (combined token and client auth) is a case where > authentication field and token request are combined in one form. Not sure= if > WWW-Authenticate should indicate that variation. >=20 > Phil > phil.hunt@oracle.com >=20 >=20 >=20 >=20 > On 2011-01-24, at 3:11 PM, Eran Hammer-Lahav wrote: >=20 > > I am not sure I understand this exactly, but I don't see the need. Basi= cally, > the token endpoint requires client authentication (yeah, with exceptions)= . > The spec provides one super-simple way to accomplish that using form- > encoded parameters, but that's really focused on the hardcoded clients - > those pointed at known services. While libraries will support the two > parameters, it is unlikely that clients will use it to obtain a token fro= m an > unfamiliar server (since they are not registered). > > > > IOW, the client password credential authentication described in the spe= c is > a useful hack for the common needs most API developers today have, based > on existing API keys used. I would hate see this expanded to more hack-is= h > client authentication schemes using parameters. In general, alternative c= lient > authentication methods (which have nothing to do directly with the two > parameters), should be defined or adopted for client authentication using > normal HTTP authentication headers. > > > > The way to think about this is to remove client authentication from the > token endpoint and just assume the server doesn't care about client ident= ity. > You give it a grant and get back an access token. Now, since we do care a= bout > client identity, we add client authentication *on-top* of the endpoint. T= he > two parameters are therefore a hack which adds authentication into the > endpoint. New schemes should work outside the request. > > > > EHL > > > > > >> -----Original Message----- > >> From: Phil Hunt [mailto:phil.hunt@oracle.com] > >> Sent: Monday, January 24, 2011 2:56 PM > >> To: Eran Hammer-Lahav > >> Cc: Torsten Lodderstedt; OAuth WG > >> Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > >> tokens endpoint? > >> > >> Why not have the token server specify a form based authentication for > >> OAuth token requests? > >> > >> WWW-Authenticate: Form url=3D"/tokenrequest.jsp" > >> > >> Thus, a server could respond: > >> 401 Unauthorized > >> WWW-Authenticate: Basic realm=3D"example" > >> WWW-Authenticate: Digest realm=3D"example" > >> WWW-Authenticate: Form url=3D"/tokenrequest.jsp",realm=3D"example" > >> > >> Normally, a form would have caused a redirect, but in this case we > >> aren't talking about browser based clients so the redirect doesn't > >> make sense. This gives the clients a choice and a way to discover > parameters (if really needed). > >> By parsing the form, it could discover what form parameters are > >> required. I suspect as Eran indicates below, this wouldn't happen to > >> often as site server documentation would already make this clear. > >> > >> Phil > >> phil.hunt@oracle.com > >> > >> > >> > >> > >> On 2011-01-24, at 2:25 PM, Eran Hammer-Lahav wrote: > >> > >>> This is pretty straight-forward. There are no special parameters to > >>> indicated > >> which client authentication is being used. It's either there or not, > >> using whatever the server supports. > >>> > >>> Simply have the token endpoint return a 401 with these WWW- > >> Authenticate headers. As long as you make it clear how to make > >> between the client identifier and the credentials used, you are set. > >>> > >>> For example, a token response can return: > >>> > >>> 401 Unauthorized > >>> WWW-Authenticate: Basic realm=3D"example" > >>> WWW-Authenticate: Digest realm=3D"example" > >>> > >>> There is no discovery for support for the client_id and > >>> client_secret > >> parameters. The client can simply try it or hardcode it based on the > >> server's documentation. > >>> > >>> Does this help? > >>> > >>> EHL > >>> > >>>> -----Original Message----- > >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > >>>> Behalf Of Torsten Lodderstedt > >>>> Sent: Monday, January 24, 2011 1:10 PM > >>>> To: OAuth WG > >>>> Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokens > >>>> endpoint? > >>>> > >>>> Hi all, > >>>> > >>>> I'm currently thinking about the integration of existing HTTP > >>>> authentication schemes with OAuth 2.0 for the purpose of end-user > >>>> authentication on the tokens endpoint. Possible candidates are > "Digest" > >>>> for challenge-response-based username/password authentication and > >>>> "Spnego" for Kerberos-based authentication. Direct support for both > >>>> could be beneficially in enterprise and other security sensitive > >> deployments. > >>>> > >>>> An direct integration with the tokens endpoint would allow to > >>>> leverage existing implementations and infrastructure for > >>>> OAuth/HTTP-based architectures. For example, HTTPClient has direct > >>>> support for Spnego- Authentication. > >>>> > >>>> Both HTTP authentication schemes use dedicated WWW-Authenticate > >> and > >>>> Authorization headers for passing credential and other data between > >>>> client and server. OAuth in contrast uses grant types to indicate > >>>> the authentication method, credentials are passed as URI query > >>>> parameters and it lacks any discovery of available authentication > >>>> methods/ grant > >> types. > >>>> > >>>> How could one integrate existing schemes into that design? What is > >>>> our story? Do we need to define a special grant type "HTTP > >> authorization"? > >>>> Shall Authorization headers overrule URI parameters? > >>>> > >>>> Any ideas of the WG are higly appreciated. > >>>> > >>>> regards, > >>>> Torsten. > >>>> > >>>> > >>>> _______________________________________________ > >>>> OAuth mailing 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 SRS0=zJbJIQ=UX=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Mon Jan 24 22:32:41 2011 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 6535F3A6A5D for ; Mon, 24 Jan 2011 22:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.103 X-Spam-Level: X-Spam-Status: No, score=-3.103 tagged_above=-999 required=5 tests=[AWL=1.743, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 zxAZpsy6Kp1m for ; Mon, 24 Jan 2011 22:32:39 -0800 (PST) Received: from smtp06.bis7.eu.blackberry.com (smtp06.bis7.eu.blackberry.com [178.239.85.11]) by core3.amsl.com (Postfix) with ESMTP id E60883A6A5C for ; Mon, 24 Jan 2011 22:32:38 -0800 (PST) Received: from b1.c11.bise7.blackberry ([192.168.0.101]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p0P6ZXm9031830; Tue, 25 Jan 2011 06:35:33 GMT Received: from ups31.c11.bise7.blackberry (cmp31.c11.bise7.blackberry [172.18.204.201]) by b1.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p0P6ZVMY005982; Tue, 25 Jan 2011 06:35:31 GMT X-rim-org-msg-ref-id: 1304418451 Message-ID: <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <4D3DEAAA.6070201@lodderstedt.net><90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> Sensitivity: Normal Importance: Normal To: "Eran Hammer-Lahav" , "OAuth WG" From: torsten@lodderstedt.net Date: Tue, 25 Jan 2011 06:35:20 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 06:35:35 -0000 SGkgRXJhbiwNCg0KdGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBNeSBpbnF1aXJ5IHdhcyBhYm91 dCBlbmQtdXNlciBhdXRoZW50aWNhdGlvbiBhbmQgbm90IGFib3V0IGNsaWVudCBhdXRoZW50aWNh dGlvbi4gQWxsIGh0dHAgc2NoZW1lcyBJJ20gYXdhcmUgb2YgYXV0aGVudGljYXRlIHVzZXJzIGFu ZCBJIHdhbnQgdG8gZmluZCBhIHdheSB0byBsZXZlcmFnZSB0aGVtIHdpdGggT0F1dGggdG8gZGV0 ZXJtaW5lIHRoZSB0b2tlbidzIGlkZW50aXR5Lg0KDQpSZWdhcmRzLA0KVG9yc3Rlbi4NCkdlc2Vu ZGV0IG1pdCBCbGFja0JlcnJ5riBXZWJtYWlsIHZvbiBUZWxla29tIERldXRzY2hsYW5kICANCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVyYW4gSGFtbWVyLUxhaGF2IDxlcmFu QGh1ZW5pdmVyc2UuY29tPg0KRGF0ZTogTW9uLCAyNCBKYW4gMjAxMSAxNToyNTozOCANClRvOiBU b3JzdGVuIExvZGRlcnN0ZWR0PHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PjsgT0F1dGggV0c8b2F1 dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBIb3cgdG8gaW50ZWdyYXRlZCBE SUdFU1Qgb3IgU1BORUdPIHdpdGggdG9rZW5zDQogZW5kcG9pbnQ/DQoNClRoaXMgaXMgcHJldHR5 IHN0cmFpZ2h0LWZvcndhcmQuIFRoZXJlIGFyZSBubyBzcGVjaWFsIHBhcmFtZXRlcnMgdG8gaW5k aWNhdGVkIHdoaWNoIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBiZWluZyB1c2VkLiBJdCdzIGVp dGhlciB0aGVyZSBvciBub3QsIHVzaW5nIHdoYXRldmVyIHRoZSBzZXJ2ZXIgc3VwcG9ydHMuDQoN ClNpbXBseSBoYXZlIHRoZSB0b2tlbiBlbmRwb2ludCByZXR1cm4gYSA0MDEgd2l0aCB0aGVzZSBX V1ctQXV0aGVudGljYXRlIGhlYWRlcnMuIEFzIGxvbmcgYXMgeW91IG1ha2UgaXQgY2xlYXIgaG93 IHRvIG1ha2UgYmV0d2VlbiB0aGUgY2xpZW50IGlkZW50aWZpZXIgYW5kIHRoZSBjcmVkZW50aWFs cyB1c2VkLCB5b3UgYXJlIHNldC4NCg0KRm9yIGV4YW1wbGUsIGEgdG9rZW4gcmVzcG9uc2UgY2Fu IHJldHVybjoNCg0KNDAxIFVuYXV0aG9yaXplZA0KV1dXLUF1dGhlbnRpY2F0ZTogQmFzaWMgcmVh bG09ImV4YW1wbGUiDQpXV1ctQXV0aGVudGljYXRlOiBEaWdlc3QgcmVhbG09ImV4YW1wbGUiDQoN ClRoZXJlIGlzIG5vIGRpc2NvdmVyeSBmb3Igc3VwcG9ydCBmb3IgdGhlIGNsaWVudF9pZCBhbmQg Y2xpZW50X3NlY3JldCBwYXJhbWV0ZXJzLiBUaGUgY2xpZW50IGNhbiBzaW1wbHkgdHJ5IGl0IG9y IGhhcmRjb2RlIGl0IGJhc2VkIG9uIHRoZSBzZXJ2ZXIncyBkb2N1bWVudGF0aW9uLg0KDQpEb2Vz IHRoaXMgaGVscD8NCg0KRUhMDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPiBPZiBUb3JzdGVuIExvZGRlcnN0ZWR0DQo+IFNlbnQ6IE1vbmRheSwgSmFu dWFyeSAyNCwgMjAxMSAxOjEwIFBNDQo+IFRvOiBPQXV0aCBXRw0KPiBTdWJqZWN0OiBbT0FVVEgt V0ddIEhvdyB0byBpbnRlZ3JhdGVkIERJR0VTVCBvciBTUE5FR08gd2l0aCB0b2tlbnMNCj4gZW5k cG9pbnQ/DQo+IA0KPiBIaSBhbGwsDQo+IA0KPiBJJ20gY3VycmVudGx5IHRoaW5raW5nIGFib3V0 IHRoZSBpbnRlZ3JhdGlvbiBvZiBleGlzdGluZyBIVFRQIGF1dGhlbnRpY2F0aW9uDQo+IHNjaGVt ZXMgd2l0aCBPQXV0aCAyLjAgZm9yIHRoZSBwdXJwb3NlIG9mIGVuZC11c2VyIGF1dGhlbnRpY2F0 aW9uIG9uIHRoZQ0KPiB0b2tlbnMgZW5kcG9pbnQuIFBvc3NpYmxlIGNhbmRpZGF0ZXMgYXJlICJE aWdlc3QiDQo+IGZvciBjaGFsbGVuZ2UtcmVzcG9uc2UtYmFzZWQgdXNlcm5hbWUvcGFzc3dvcmQg YXV0aGVudGljYXRpb24gYW5kDQo+ICJTcG5lZ28iIGZvciBLZXJiZXJvcy1iYXNlZCBhdXRoZW50 aWNhdGlvbi4gRGlyZWN0IHN1cHBvcnQgZm9yIGJvdGggY291bGQNCj4gYmUgYmVuZWZpY2lhbGx5 IGluIGVudGVycHJpc2UgYW5kIG90aGVyIHNlY3VyaXR5IHNlbnNpdGl2ZSBkZXBsb3ltZW50cy4N Cj4gDQo+IEFuIGRpcmVjdCBpbnRlZ3JhdGlvbiB3aXRoIHRoZSB0b2tlbnMgZW5kcG9pbnQgd291 bGQgYWxsb3cgdG8gbGV2ZXJhZ2UNCj4gZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIGFuZCBpbmZy YXN0cnVjdHVyZSBmb3IgT0F1dGgvSFRUUC1iYXNlZA0KPiBhcmNoaXRlY3R1cmVzLiBGb3IgZXhh bXBsZSwgSFRUUENsaWVudCBoYXMgZGlyZWN0IHN1cHBvcnQgZm9yIFNwbmVnby0NCj4gQXV0aGVu dGljYXRpb24uDQo+IA0KPiBCb3RoIEhUVFAgYXV0aGVudGljYXRpb24gc2NoZW1lcyB1c2UgZGVk aWNhdGVkIFdXVy1BdXRoZW50aWNhdGUgYW5kDQo+IEF1dGhvcml6YXRpb24gaGVhZGVycyBmb3Ig cGFzc2luZyBjcmVkZW50aWFsIGFuZCBvdGhlciBkYXRhIGJldHdlZW4gY2xpZW50DQo+IGFuZCBz ZXJ2ZXIuIE9BdXRoIGluIGNvbnRyYXN0IHVzZXMgZ3JhbnQgdHlwZXMgdG8gaW5kaWNhdGUgdGhl IGF1dGhlbnRpY2F0aW9uDQo+IG1ldGhvZCwgY3JlZGVudGlhbHMgYXJlIHBhc3NlZCBhcyBVUkkg cXVlcnkgcGFyYW1ldGVycyBhbmQgaXQgbGFja3MgYW55DQo+IGRpc2NvdmVyeSBvZiBhdmFpbGFi bGUgYXV0aGVudGljYXRpb24gbWV0aG9kcy8gZ3JhbnQgdHlwZXMuDQo+IA0KPiBIb3cgY291bGQg b25lIGludGVncmF0ZSBleGlzdGluZyBzY2hlbWVzIGludG8gdGhhdCBkZXNpZ24/IFdoYXQgaXMg b3VyDQo+IHN0b3J5PyBEbyB3ZSBuZWVkIHRvIGRlZmluZSBhIHNwZWNpYWwgZ3JhbnQgdHlwZSAi SFRUUCBhdXRob3JpemF0aW9uIj8NCj4gU2hhbGwgQXV0aG9yaXphdGlvbiBoZWFkZXJzIG92ZXJy dWxlIFVSSSBwYXJhbWV0ZXJzPw0KPiANCj4gQW55IGlkZWFzIG9mIHRoZSBXRyBhcmUgaGlnbHkg YXBwcmVjaWF0ZWQuDQo+IA0KPiByZWdhcmRzLA0KPiBUb3JzdGVuLg0KPiANCj4gDQo+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGlu ZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vb2F1dGgNCg== From eran@hueniverse.com Mon Jan 24 23:49:00 2011 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 C16F03A6A73 for ; Mon, 24 Jan 2011 23:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 EfQLuyBIkbXt for ; Mon, 24 Jan 2011 23:48:59 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id E4D7E3A6A60 for ; Mon, 24 Jan 2011 23:48:58 -0800 (PST) Received: (qmail 14462 invoked from network); 25 Jan 2011 07:51:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jan 2011 07:51:54 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 25 Jan 2011 00:51:54 -0700 From: Eran Hammer-Lahav To: "torsten@lodderstedt.net" , OAuth WG Date: Tue, 25 Jan 2011 00:51:37 -0700 Thread-Topic: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? Thread-Index: Acu8WhRCPWb99jHKSsSy0gYwJ/sVkgACd8cQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net><90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> In-Reply-To: <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 25 Jan 2011 07:49:00 -0000 There is no clean way to do with without defining new HTTP authentication s= chemes. The token endpoints takes: 1. Client authentication 2. Authorization grant There is no user authentication. Even the resource owner password credentia= ls is not user authentication but only validation of "some grant values". What you can do is define an authentication scheme which will authenticate = the client and provide the grant in one header, or define a new grant type = for such credentials. But you can't use something like Basic or Digest to p= rovide the resource owner's credentials. That's against the endpoint design= . EHL > -----Original Message----- > From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net] > Sent: Monday, January 24, 2011 10:35 PM > To: Eran Hammer-Lahav; OAuth WG > Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokensendpoint? >=20 > Hi Eran, >=20 > thanks for your response. My inquiry was about end-user authentication an= d > not about client authentication. All http schemes I'm aware of authentica= te > users and I want to find a way to leverage them with OAuth to determine t= he > token's identity. >=20 > Regards, > Torsten. > Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland >=20 > -----Original Message----- > From: Eran Hammer-Lahav > Date: Mon, 24 Jan 2011 15:25:38 > To: Torsten Lodderstedt; OAuth > WG > Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > endpoint? >=20 > This is pretty straight-forward. There are no special parameters to indic= ated > which client authentication is being used. It's either there or not, usin= g > whatever the server supports. >=20 > Simply have the token endpoint return a 401 with these WWW-Authenticate > headers. As long as you make it clear how to make between the client > identifier and the credentials used, you are set. >=20 > For example, a token response can return: >=20 > 401 Unauthorized > WWW-Authenticate: Basic realm=3D"example" > WWW-Authenticate: Digest realm=3D"example" >=20 > There is no discovery for support for the client_id and client_secret > parameters. The client can simply try it or hardcode it based on the serv= er's > documentation. >=20 > Does this help? >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Torsten Lodderstedt > > Sent: Monday, January 24, 2011 1:10 PM > > To: OAuth WG > > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > > endpoint? > > > > Hi all, > > > > I'm currently thinking about the integration of existing HTTP > > authentication schemes with OAuth 2.0 for the purpose of end-user > > authentication on the tokens endpoint. Possible candidates are "Digest" > > for challenge-response-based username/password authentication and > > "Spnego" for Kerberos-based authentication. Direct support for both > > could be beneficially in enterprise and other security sensitive > deployments. > > > > An direct integration with the tokens endpoint would allow to leverage > > existing implementations and infrastructure for OAuth/HTTP-based > > architectures. For example, HTTPClient has direct support for Spnego- > > Authentication. > > > > Both HTTP authentication schemes use dedicated WWW-Authenticate and > > Authorization headers for passing credential and other data between > > client and server. OAuth in contrast uses grant types to indicate the > > authentication method, credentials are passed as URI query parameters > > and it lacks any discovery of available authentication methods/ grant t= ypes. > > > > How could one integrate existing schemes into that design? What is our > > story? Do we need to define a special grant type "HTTP authorization"? > > Shall Authorization headers overrule URI parameters? > > > > Any ideas of the WG are higly appreciated. > > > > regards, > > Torsten. > > > > > >_______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From torsten@lodderstedt.net Tue Jan 25 00:19:36 2011 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 BC6A03A6A30 for ; Tue, 25 Jan 2011 00:19:36 -0800 (PST) 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 D4Wx34BwF1Cu for ; Tue, 25 Jan 2011 00:19:35 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by core3.amsl.com (Postfix) with ESMTP id 720623A6B87 for ; Tue, 25 Jan 2011 00:19:34 -0800 (PST) Received: from [80.67.16.111] (helo=webmailfront01.ispgateway.de) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PheAY-00063z-HN; Tue, 25 Jan 2011 09:22:30 +0100 Received: from ( [195.243.113.251]) by webmail.df.eu (Horde Framework) with HTTP; Tue, 25 Jan 2011 09:22:30 +0100 Message-ID: <20110125092230.15123t1lj1ap0twk@webmail.df.eu> Date: Tue, 25 Jan 2011 09:22:30 +0100 From: Torsten Lodderstedt To: Eran Hammer-Lahav References: <4D3DEAAA.6070201@lodderstedt.net><90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> 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.251 X-Df-Sender: 141509 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 25 Jan 2011 08:19:36 -0000 Zitat von Eran Hammer-Lahav : > There is no clean way to do with without defining new HTTP > authentication schemes. The token endpoints takes: > > 1. Client authentication > 2. Authorization grant > > There is no user authentication. Even the resource owner password > credentials is not user authentication but only validation of "some > grant values". What's the difference from a conceptual point of view? In my opinion, the resource owners password is used for both, authenticating the resource owner and authorizing the token issuance. > > What you can do is define an authentication scheme which will > authenticate the client and provide the grant in one header, or the spec makes the grant type a required parameter, so a lonely authorization header won't be suffiencent. > define a new grant type for such credentials. But you can't use That brings us back to the mix between POST parameters and authz headers for credential transmission. Something you critized for good reasons. > something like Basic or Digest to provide the resource owner's > credentials. That's against the endpoint design. It's good to know that restriction, but I'm not happy :-( So based on that information I would say, the only proper way to integrate standard HTTP schemes would be to invent another endpoint for that purpose. Comments? regards, Torsten. > > EHL > > >> -----Original Message----- >> From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net] >> Sent: Monday, January 24, 2011 10:35 PM >> To: Eran Hammer-Lahav; OAuth WG >> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with >> tokensendpoint? >> >> Hi Eran, >> >> thanks for your response. My inquiry was about end-user authentication and >> not about client authentication. All http schemes I'm aware of authenticate >> users and I want to find a way to leverage them with OAuth to determine the >> token's identity. >> >> Regards, >> Torsten. >> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland >> >> -----Original Message----- >> From: Eran Hammer-Lahav >> Date: Mon, 24 Jan 2011 15:25:38 >> To: Torsten Lodderstedt; OAuth >> WG >> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >> endpoint? >> >> This is pretty straight-forward. There are no special parameters to >> indicated >> which client authentication is being used. It's either there or not, using >> whatever the server supports. >> >> Simply have the token endpoint return a 401 with these WWW-Authenticate >> headers. As long as you make it clear how to make between the client >> identifier and the credentials used, you are set. >> >> For example, a token response can return: >> >> 401 Unauthorized >> WWW-Authenticate: Basic realm="example" >> WWW-Authenticate: Digest realm="example" >> >> There is no discovery for support for the client_id and client_secret >> parameters. The client can simply try it or hardcode it based on >> the server's >> documentation. >> >> Does this help? >> >> EHL >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >> > Of Torsten Lodderstedt >> > Sent: Monday, January 24, 2011 1:10 PM >> > To: OAuth WG >> > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >> > endpoint? >> > >> > Hi all, >> > >> > I'm currently thinking about the integration of existing HTTP >> > authentication schemes with OAuth 2.0 for the purpose of end-user >> > authentication on the tokens endpoint. Possible candidates are "Digest" >> > for challenge-response-based username/password authentication and >> > "Spnego" for Kerberos-based authentication. Direct support for both >> > could be beneficially in enterprise and other security sensitive >> deployments. >> > >> > An direct integration with the tokens endpoint would allow to leverage >> > existing implementations and infrastructure for OAuth/HTTP-based >> > architectures. For example, HTTPClient has direct support for Spnego- >> > Authentication. >> > >> > Both HTTP authentication schemes use dedicated WWW-Authenticate and >> > Authorization headers for passing credential and other data between >> > client and server. OAuth in contrast uses grant types to indicate the >> > authentication method, credentials are passed as URI query parameters >> > and it lacks any discovery of available authentication methods/ >> grant types. >> > >> > How could one integrate existing schemes into that design? What is our >> > story? Do we need to define a special grant type "HTTP authorization"? >> > Shall Authorization headers overrule URI parameters? >> > >> > Any ideas of the WG are higly appreciated. >> > >> > regards, >> > Torsten. >> > >> > >> >_______________________________________________ >> > OAuth mailing list >> > OAuth@ietf.org >> > https://www.ietf.org/mailman/listinfo/oauth > From pathogenix@gmail.com Tue Jan 25 01:22:33 2011 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 6D0F13A6A7A for ; Tue, 25 Jan 2011 01:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1i9Kfr3KYmP for ; Tue, 25 Jan 2011 01:22:31 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 9963D3A63CB for ; Tue, 25 Jan 2011 01:22:31 -0800 (PST) Received: by qyk34 with SMTP id 34so3911248qyk.10 for ; Tue, 25 Jan 2011 01:25:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ywz+/VsNrjcHJffAxbi9+zXEHoBZRU06TaTHwQCA0MU=; b=xw2uhSS1esxRc94b4jS3rar9Nsa+Gd3GV6BVLKyERqsgnZs9xtYSDdW/bbHy1JhNCr P9GVz0e53MIYP8UD4Sc6/hWnTOOwMeOROhrPlwJsTQtqykTLXaPGHohv/biovujBHrfk XIwPE5XocNtMSNc2agANbMg61Z13iaBmSm5po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=BExLfhoFX74T1nKCSE0HipvJYajohXTjDCqy+q6iM2QZ4dyyqoeTIr1FTJVbCgK6Ra MbWENrHP6dtsW7zPAShmzisI3P3kgT+wBlJeMfqzhEbkisn8VLCqvk2a6i3oG2naKcQr ZwZEaLTAqWs4oaGBc0tBB71N2QTaQtCqBw5tY= MIME-Version: 1.0 Received: by 10.229.83.198 with SMTP id g6mr4674394qcl.157.1295947527625; Tue, 25 Jan 2011 01:25:27 -0800 (PST) Sender: pathogenix@gmail.com Received: by 10.229.217.82 with HTTP; Tue, 25 Jan 2011 01:25:27 -0800 (PST) In-Reply-To: <20110125092230.15123t1lj1ap0twk@webmail.df.eu> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> Date: Tue, 25 Jan 2011 09:25:27 +0000 X-Google-Sender-Auth: DSBi-qijgFXpj05eGopt6CDu-3k Message-ID: From: Bob Gregory To: Torsten Lodderstedt Content-Type: multipart/alternative; boundary=00163642748d081b08049aa84c57 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 25 Jan 2011 09:22:33 -0000 --00163642748d081b08049aa84c57 Content-Type: text/plain; charset=ISO-8859-1 Perhaps I'm missing something here, but once a client has requested an access grant, the auth server is free to authenticate the end-user in whatever way it chooses, and it would seem sensible to signal authn requirements with standard HTTP headers. Why, then, would you want to integrate existing HTTP schemes at the token endpoint instead of at the authorization endpoint? -- Bob Gregory On Tue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt < torsten@lodderstedt.net> wrote: > Zitat von Eran Hammer-Lahav : > > > There is no clean way to do with without defining new HTTP > > authentication schemes. The token endpoints takes: > > > > 1. Client authentication > > 2. Authorization grant > > > > There is no user authentication. Even the resource owner password > > credentials is not user authentication but only validation of "some > > grant values". > > What's the difference from a conceptual point of view? In my opinion, > the resource owners password is used for both, authenticating the > resource owner and authorizing the token issuance. > > > > > What you can do is define an authentication scheme which will > > authenticate the client and provide the grant in one header, or > > the spec makes the grant type a required parameter, so a lonely > authorization header won't be suffiencent. > > > define a new grant type for such credentials. But you can't use > > That brings us back to the mix between POST parameters and authz > headers for credential transmission. Something you critized for good > reasons. > > > something like Basic or Digest to provide the resource owner's > > credentials. That's against the endpoint design. > > It's good to know that restriction, but I'm not happy :-( So based on > that information I would say, the only proper way to integrate > standard HTTP schemes would be to invent another endpoint for that > purpose. > > Comments? > > regards, > Torsten. > > > > > EHL > > > > > >> -----Original Message----- > >> From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net] > >> Sent: Monday, January 24, 2011 10:35 PM > >> To: Eran Hammer-Lahav; OAuth WG > >> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > >> tokensendpoint? > >> > >> Hi Eran, > >> > >> thanks for your response. My inquiry was about end-user authentication > and > >> not about client authentication. All http schemes I'm aware of > authenticate > >> users and I want to find a way to leverage them with OAuth to determine > the > >> token's identity. > >> > >> Regards, > >> Torsten. > >> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland > >> > >> -----Original Message----- > >> From: Eran Hammer-Lahav > >> Date: Mon, 24 Jan 2011 15:25:38 > >> To: Torsten Lodderstedt; OAuth > >> WG > >> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > >> endpoint? > >> > >> This is pretty straight-forward. There are no special parameters to > >> indicated > >> which client authentication is being used. It's either there or not, > using > >> whatever the server supports. > >> > >> Simply have the token endpoint return a 401 with these WWW-Authenticate > >> headers. As long as you make it clear how to make between the client > >> identifier and the credentials used, you are set. > >> > >> For example, a token response can return: > >> > >> 401 Unauthorized > >> WWW-Authenticate: Basic realm="example" > >> WWW-Authenticate: Digest realm="example" > >> > >> There is no discovery for support for the client_id and client_secret > >> parameters. The client can simply try it or hardcode it based on > >> the server's > >> documentation. > >> > >> Does this help? > >> > >> EHL > >> > >> > -----Original Message----- > >> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > >> > Of Torsten Lodderstedt > >> > Sent: Monday, January 24, 2011 1:10 PM > >> > To: OAuth WG > >> > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens > >> > endpoint? > >> > > >> > Hi all, > >> > > >> > I'm currently thinking about the integration of existing HTTP > >> > authentication schemes with OAuth 2.0 for the purpose of end-user > >> > authentication on the tokens endpoint. Possible candidates are > "Digest" > >> > for challenge-response-based username/password authentication and > >> > "Spnego" for Kerberos-based authentication. Direct support for both > >> > could be beneficially in enterprise and other security sensitive > >> deployments. > >> > > >> > An direct integration with the tokens endpoint would allow to leverage > >> > existing implementations and infrastructure for OAuth/HTTP-based > >> > architectures. For example, HTTPClient has direct support for Spnego- > >> > Authentication. > >> > > >> > Both HTTP authentication schemes use dedicated WWW-Authenticate and > >> > Authorization headers for passing credential and other data between > >> > client and server. OAuth in contrast uses grant types to indicate the > >> > authentication method, credentials are passed as URI query parameters > >> > and it lacks any discovery of available authentication methods/ > >> grant types. > >> > > >> > How could one integrate existing schemes into that design? What is our > >> > story? Do we need to define a special grant type "HTTP authorization"? > >> > Shall Authorization headers overrule URI parameters? > >> > > >> > Any ideas of the WG are higly appreciated. > >> > > >> > regards, > >> > Torsten. > >> > > >> > > >> >_______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --00163642748d081b08049aa84c57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps I'm missing something here, but once a client has requested an = access grant, the auth server is free to authenticate the end-user in whate= ver way it chooses, and it would seem sensible to signal authn requirements= with standard HTTP headers.


Why, then, would you want to integrate existing HTTP schemes= at the token endpoint instead of at the authorization endpoint?
=
-- Bob Gregory

On T= ue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Zitat von Eran Hammer-Lahav <eran@hueniverse.com>:

> There is no clean way to do with without defining new HTTP
> authentication schemes. The token endpoints takes:
>
> 1. Client authentication
> 2. Authorization grant
>
> There is no user authentication. Even the resource owner password
> credentials is not user authentication but only validation of "so= me
> grant values".

What's the difference from a conceptual point of view? In my opin= ion,
the resource owners password is used for both, authenticating the
resource owner and authorizing the token issuance.

>
> What you can do is define an authentication scheme which will
> authenticate the client and provide the grant in one header, or

the spec makes the grant type a required parameter, so a lonely
authorization header won't be suffiencent.

> define a new grant type for such credentials. But you can't use
That brings us back to the mix between POST parameters and authz
headers for credential transmission. Something you critized for good
reasons.

> something like Basic or Digest to provide the resource owner's
> credentials. That's against the endpoint design.

It's good to know that restriction, but I'm not happy :-( So = based on
that information I would say, the only proper way to integrate
standard HTTP schemes would be to invent another endpoint for that
purpose.

Comments?

regards,
Torsten.

>
> EHL
>
>
>> -----Original Message-----
>> From: torsten@lodderste= dt.net [mailto:torsten@lodde= rstedt.net]
>> Sent: Monday, January 24, 2011 10:35 PM
>> To: Eran Hammer-Lahav; OAuth WG
>> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO wit= h
>> tokensendpoint?
>>
>> Hi Eran,
>>
>> thanks for your response. My inquiry was about end-user authentica= tion and
>> not about client authentication. All http schemes I'm aware of= authenticate
>> users and I want to find a way to leverage them with OAuth to dete= rmine the
>> token's identity.
>>
>> Regards,
>> Torsten.
>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
>>
>> -----Original Message-----
>> From: Eran Hammer-Lahav <eran@hueniverse.com>
>> Date: Mon, 24 Jan 2011 15:25:38
>> To: Torsten Lodderstedt<torsten@lodderstedt.net>; OAuth
>> WG<oauth@ietf.org>
>> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with to= kens
>> endpoint?
>>
>> This is pretty straight-forward. There are no special parameters t= o
>> indicated
>> which client authentication is being used. It's either there o= r not, using
>> whatever the server supports.
>>
>> Simply have the token endpoint return a 401 with these WWW-Authent= icate
>> headers. As long as you make it clear how to make between the clie= nt
>> identifier and the credentials used, you are set.
>>
>> For example, a token response can return:
>>
>> 401 Unauthorized
>> WWW-Authenticate: Basic realm=3D"example"
>> WWW-Authenticate: Digest realm=3D"example"
>>
>> There is no discovery for support for the client_id and client_sec= ret
>> parameters. The client can simply try it or hardcode it based on >> the server's
>> documentation.
>>
>> Does this help?
>>
>> EHL
>>
>> > -----Original Message-----
>> > From: oauth-bounces= @ietf.org [mailto:oauth-bounc= es@ietf.org] On Behalf
>> > Of Torsten Lodderstedt
>> > Sent: Monday, January 24, 2011 1:10 PM
>> > To: OAuth WG
>> > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with t= okens
>> > endpoint?
>> >
>> > Hi all,
>> >
>> > I'm currently thinking about the integration of existing = HTTP
>> > authentication schemes with OAuth 2.0 for the purpose of end-= user
>> > authentication on the tokens endpoint. Possible candidates ar= e "Digest"
>> > for challenge-response-based username/password authentication= and
>> > "Spnego" for Kerberos-based authentication. Direct = support for both
>> > could be beneficially in enterprise and other security sensit= ive
>> deployments.
>> >
>> > An direct integration with the tokens endpoint would allow to= leverage
>> > existing implementations and infrastructure for OAuth/HTTP-ba= sed
>> > architectures. For example, HTTPClient has direct support for= Spnego-
>> > Authentication.
>> >
>> > Both HTTP authentication schemes use dedicated WWW-Authentica= te and
>> > Authorization headers for passing credential and other data b= etween
>> > client and server. OAuth in contrast uses grant types to indi= cate the
>> > authentication method, credentials are passed as URI query pa= rameters
>> > and it lacks any discovery of available authentication method= s/
>> grant types.
>> >
>> > How could one integrate existing schemes into that design? Wh= at is our
>> > story? Do we need to define a special grant type "HTTP a= uthorization"?
>> > Shall Authorization headers overrule URI parameters?
>> >
>> > Any ideas of the WG are higly appreciated.
>> >
>> > regards,
>> > Torsten.
>> >
>> >
>> >_______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>




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

--00163642748d081b08049aa84c57-- From eran@hueniverse.com Tue Jan 25 08:39:00 2011 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 015293A682B for ; Tue, 25 Jan 2011 08:39:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 jh4XPvRnJ626 for ; Tue, 25 Jan 2011 08:38:58 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 604A93A6817 for ; Tue, 25 Jan 2011 08:38:57 -0800 (PST) Received: (qmail 9842 invoked from network); 25 Jan 2011 16:41:55 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jan 2011 16:41:55 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 25 Jan 2011 09:41:45 -0700 From: Eran Hammer-Lahav To: Bob Gregory , Torsten Lodderstedt Date: Tue, 25 Jan 2011 09:41:29 -0700 Thread-Topic: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? Thread-Index: Acu8cc9T8I0n6MsfRHyqVXa8Iwl6fwAPMQKA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62350@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> 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_90C41DD21FB7C64BB94121FBBC2E723445A8D62350P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 25 Jan 2011 16:39:00 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62350P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Torsten is looking to supplement/replace the Resource Owner Password Creden= tials grant with similar constructs but using existing user password framew= orks. This has nothing to do with actual user interactions and the authoriz= ation endpoint. EHL From: pathogenix@gmail.com [mailto:pathogenix@gmail.com] On Behalf Of Bob G= regory Sent: Tuesday, January 25, 2011 1:25 AM To: Torsten Lodderstedt Cc: Eran Hammer-Lahav; OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpo= int? Perhaps I'm missing something here, but once a client has requested an acce= ss grant, the auth server is free to authenticate the end-user in whatever = way it chooses, and it would seem sensible to signal authn requirements wit= h standard HTTP headers. Why, then, would you want to integrate existing HTTP schemes at the token e= ndpoint instead of at the authorization endpoint? -- Bob Gregory On Tue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt > wrote: Zitat von Eran Hammer-Lahav >: > There is no clean way to do with without defining new HTTP > authentication schemes. The token endpoints takes: > > 1. Client authentication > 2. Authorization grant > > There is no user authentication. Even the resource owner password > credentials is not user authentication but only validation of "some > grant values". What's the difference from a conceptual point of view? In my opinion, the resource owners password is used for both, authenticating the resource owner and authorizing the token issuance. > > What you can do is define an authentication scheme which will > authenticate the client and provide the grant in one header, or the spec makes the grant type a required parameter, so a lonely authorization header won't be suffiencent. > define a new grant type for such credentials. But you can't use That brings us back to the mix between POST parameters and authz headers for credential transmission. Something you critized for good reasons. > something like Basic or Digest to provide the resource owner's > credentials. That's against the endpoint design. It's good to know that restriction, but I'm not happy :-( So based on that information I would say, the only proper way to integrate standard HTTP schemes would be to invent another endpoint for that purpose. Comments? regards, Torsten. > > EHL > > >> -----Original Message----- >> From: torsten@lodderstedt.net [mailto:to= rsten@lodderstedt.net] >> Sent: Monday, January 24, 2011 10:35 PM >> To: Eran Hammer-Lahav; OAuth WG >> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with >> tokensendpoint? >> >> Hi Eran, >> >> thanks for your response. My inquiry was about end-user authentication a= nd >> not about client authentication. All http schemes I'm aware of authentic= ate >> users and I want to find a way to leverage them with OAuth to determine = the >> token's identity. >> >> Regards, >> Torsten. >> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland >> >> -----Original Message----- >> From: Eran Hammer-Lahav = > >> Date: Mon, 24 Jan 2011 15:25:38 >> To: Torsten Lodderstedt>; OAuth >> WG> >> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >> endpoint? >> >> This is pretty straight-forward. There are no special parameters to >> indicated >> which client authentication is being used. It's either there or not, usi= ng >> whatever the server supports. >> >> Simply have the token endpoint return a 401 with these WWW-Authenticate >> headers. As long as you make it clear how to make between the client >> identifier and the credentials used, you are set. >> >> For example, a token response can return: >> >> 401 Unauthorized >> WWW-Authenticate: Basic realm=3D"example" >> WWW-Authenticate: Digest realm=3D"example" >> >> There is no discovery for support for the client_id and client_secret >> parameters. The client can simply try it or hardcode it based on >> the server's >> documentation. >> >> Does this help? >> >> EHL >> >> > -----Original Message----- >> > From: oauth-bounces@ietf.org [mailto:oa= uth-bounces@ietf.org] On Behalf >> > Of Torsten Lodderstedt >> > Sent: Monday, January 24, 2011 1:10 PM >> > To: OAuth WG >> > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >> > endpoint? >> > >> > Hi all, >> > >> > I'm currently thinking about the integration of existing HTTP >> > authentication schemes with OAuth 2.0 for the purpose of end-user >> > authentication on the tokens endpoint. Possible candidates are "Digest= " >> > for challenge-response-based username/password authentication and >> > "Spnego" for Kerberos-based authentication. Direct support for both >> > could be beneficially in enterprise and other security sensitive >> deployments. >> > >> > An direct integration with the tokens endpoint would allow to leverage >> > existing implementations and infrastructure for OAuth/HTTP-based >> > architectures. For example, HTTPClient has direct support for Spnego- >> > Authentication. >> > >> > Both HTTP authentication schemes use dedicated WWW-Authenticate and >> > Authorization headers for passing credential and other data between >> > client and server. OAuth in contrast uses grant types to indicate the >> > authentication method, credentials are passed as URI query parameters >> > and it lacks any discovery of available authentication methods/ >> grant types. >> > >> > How could one integrate existing schemes into that design? What is our >> > story? Do we need to define a special grant type "HTTP authorization"? >> > Shall Authorization headers overrule URI parameters? >> > >> > Any ideas of the WG are higly appreciated. >> > >> > regards, >> > Torsten. >> > >> > >> >_______________________________________________ >> > OAuth mailing 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_90C41DD21FB7C64BB94121FBBC2E723445A8D62350P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Torsten i= s looking to supplement/replace the Resource Owner Password Credentials gra= nt with similar constructs but using existing user password frameworks. Thi= s has nothing to do with actual user interactions and the authorization end= point.

 

EHL

 

From: pathogenix@gmail.com [mailto:pathogenix@gmail.com] On Beha= lf Of Bob Gregory
Sent: Tuesday, January 25, 2011 1:25 AM
= To: Torsten Lodderstedt
Cc: Eran Hammer-Lahav; OAuth WGSubject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tok= ensendpoint?

&nb= sp;

Perhaps I'm missing something here, but o= nce a client has requested an access grant, the auth server is free to auth= enticate the end-user in whatever way it chooses, and it would seem sensibl= e to signal authn requirements with standard HTTP headers.

 

Why, then, would you want to integrate existing HTTP schemes at the token= endpoint instead of at the authorization endpoint?

 

-- Bob Gregory

 

On Tue, Jan 25, 2011 at 8:22 AM, Torsten = Lodderstedt <torsten@lodderst= edt.net> wrote:

Zitat von Eran Ha= mmer-Lahav <eran@hueniverse.com>:

What's the diff= erence from a conceptual point of view? In my opinion,
the resource owne= rs password is used for both, authenticating the
resource owner and auth= orizing the token issuance.

the spe= c makes the grant type a required parameter, so a lonely
authorization h= eader won't be suffiencent.

That bring= s us back to the mix between POST parameters and authz
headers for crede= ntial transmission. Something you critized for good
reasons.<= /p>

It's good to know that restriction, but I'm not happy :-( So based on<= br>that information I would say, the only proper way to integrate
standa= rd HTTP schemes would be to invent another endpoint for that
purpose.
Comments?

regards,
Torsten.


>
> EHL
&= gt;
>
>> -----Original Message-----
>> From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net]
&g= t;> Sent: Monday, January 24, 2011 10:35 PM
>> To: Eran Hammer-= Lahav; OAuth WG
>> Subject: AW: RE: [OAUTH-WG] How to integrated D= IGEST or SPNEGO with
>> tokensendpoint?
>>
>> Hi= Eran,
>>
>> thanks for your response. My inquiry was abo= ut end-user authentication and
>> not about client authentication.= All http schemes I'm aware of authenticate
>> users and I want to= find a way to leverage them with OAuth to determine the
>> token'= s identity.
>>
>> Regards,
>> Torsten.
>&g= t; Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
>>>> -----Original Message-----
>> From: Eran Hammer-Lahav &= lt;eran@hueniverse.com>
&g= t;> Date: Mon, 24 Jan 2011 15:25:38
>> To: Torsten Lodderstedt&= lt;torsten@lodderstedt.net&g= t;; OAuth
>> WG<oauth@ietf.or= g>
>> Subject: RE: [OAUTH-WG] How to integrated DIGEST or S= PNEGO with tokens
>> endpoint?
>>
>> This is pre= tty straight-forward. There are no special parameters to
>> indica= ted
>> which client authentication is being used. It's either ther= e or not, using
>> whatever the server supports.
>>
&g= t;> Simply have the token endpoint return a 401 with these WWW-Authentic= ate
>> headers. As long as you make it clear how to make between t= he client
>> identifier and the credentials used, you are set.
= >>
>> For example, a token response can return:
>><= br>>> 401 Unauthorized
>> WWW-Authenticate: Basic realm=3D&q= uot;example"
>> WWW-Authenticate: Digest realm=3D"exampl= e"
>>
>> There is no discovery for support for the c= lient_id and client_secret
>> parameters. The client can simply tr= y it or hardcode it based on
>> the server's
>> documenta= tion.
>>
>> Does this help?
>>
>> EHL>>
>> > -----Original Message-----
>> > Fro= m: oauth-bounces@ietf.org [ma= ilto:oauth-bounces@ietf.org] = On Behalf
>> > Of Torsten Lodderstedt
>> > Sent: Mo= nday, January 24, 2011 1:10 PM
>> > To: OAuth WG
>> &g= t; Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
&g= t;> > endpoint?
>> >
>> > Hi all,
>>= >
>> > I'm currently thinking about the integration of exis= ting HTTP
>> > authentication schemes with OAuth 2.0 for the pu= rpose of end-user
>> > authentication on the tokens endpoint. P= ossible candidates are "Digest"
>> > for challenge-re= sponse-based username/password authentication and
>> > "Sp= nego" for Kerberos-based authentication. Direct support for both
&g= t;> > could be beneficially in enterprise and other security sensitiv= e
>> deployments.
>> >
>> > An direct inte= gration with the tokens endpoint would allow to leverage
>> > e= xisting implementations and infrastructure for OAuth/HTTP-based
>>= > architectures. For example, HTTPClient has direct support for Spnego-=
>> > Authentication.
>> >
>> > Both HT= TP authentication schemes use dedicated WWW-Authenticate and
>> &g= t; Authorization headers for passing credential and other data between
&= gt;> > client and server. OAuth in contrast uses grant types to indic= ate the
>> > authentication method, credentials are passed as U= RI query parameters
>> > and it lacks any discovery of availabl= e authentication methods/
>> grant types.
>> >
>= > > How could one integrate existing schemes into that design? What i= s our
>> > story? Do we need to define a special grant type &qu= ot;HTTP authorization"?
>> > Shall Authorization headers o= verrule URI parameters?
>> >
>> > Any ideas of the = WG are higly appreciated.
>> >
>> > regards,
>= ;> > Torsten.
>> >
>> >
>> >_____= __________________________________________
>> > OAuth mailing l= ist
>> > OAuth@ietf.org>> > https://www.ietf.org/mailman/listinfo/oauth
>
<= br>


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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62350P3PW5EX1MB01E_-- From beaton@google.com Tue Jan 25 09:50:28 2011 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 847713A6875 for ; Tue, 25 Jan 2011 09:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRgPr9mm7vVE for ; Tue, 25 Jan 2011 09:50:27 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id DB67E3A685B for ; Tue, 25 Jan 2011 09:50:26 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p0PHrNPS011410 for ; Tue, 25 Jan 2011 09:53:23 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1295978004; bh=P120HLOg25czRdi6YqlZaHyl36w=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=GOKNWqoC3KAD170SDUNv9IP6GLVHgSoH8Lw2Phx6NJOtppuauXYdqdAzHla5IzfSR iIpi6AflMn6GGCOLXtJSA== Received: from pxi12 (pxi12.prod.google.com [10.243.27.12]) by wpaz17.hot.corp.google.com with ESMTP id p0PHrKkG012087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 25 Jan 2011 09:53:21 -0800 Received: by pxi12 with SMTP id 12so1491038pxi.0 for ; Tue, 25 Jan 2011 09:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=M6ldnWydomOIh5StGhXe6CZ0+rma6tRLYSpInFpm5q0=; b=gEJBy78qWDagNsui2r6Z0dDKVgt/1MCMaXMZfnaRgAszNJeAbhdQmwSmKwYFqAhaqt XndAV40v+S36wf5zo17g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qLJB+G3LkmrJIIRmUs4rfML/eb2oLNfwytjANSKlidK6wV/H2WZFMFlRQoCbg1RqXz UrP6yFJHHE2K5DxkkxmQ== MIME-Version: 1.0 Received: by 10.142.155.10 with SMTP id c10mr5490211wfe.283.1295978000593; Tue, 25 Jan 2011 09:53:20 -0800 (PST) Received: by 10.142.213.7 with HTTP; Tue, 25 Jan 2011 09:53:20 -0800 (PST) In-Reply-To: <20110125092230.15123t1lj1ap0twk@webmail.df.eu> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> Date: Tue, 25 Jan 2011 09:53:20 -0800 Message-ID: From: Brian Eaton To: Torsten Lodderstedt Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 25 Jan 2011 17:50:28 -0000 Hey Torsten - I'm trying to parse through these messages to figure out the flows you're interested in. I think you're aiming for rules like this one, right? kerberos authentication -> access token or digest authentication -> access token And furthermore your intended use cases are applications installed on an end-users machine, where the end-users machine participates in some kind of authentication service. For example, maybe the machine is joined to some kerberos realm, or maybe the user has a smart card. Have I identified the use cases properly? Or are you dealing with three-legged OAuth situations, where you actually want user consent on a web page? Cheers, Brian On Tue, Jan 25, 2011 at 12:22 AM, Torsten Lodderstedt wrote: > Zitat von Eran Hammer-Lahav : > >> There is no clean way to do with without defining new HTTP authentication >> schemes. The token endpoints takes: >> >> 1. Client authentication >> 2. Authorization grant >> >> There is no user authentication. Even the resource owner password >> credentials is not user authentication but only validation of "some grant >> values". > > What's the difference from a conceptual point of view? In my opinion, the > resource owners password is used for both, authenticating the resource owner > and authorizing the token issuance. > >> >> What you can do is define an authentication scheme which will authenticate >> the client and provide the grant in one header, or > > the spec makes the grant type a required parameter, so a lonely > authorization header won't be suffiencent. > >> define a new grant type for such credentials. But you can't use > > That brings us back to the mix between POST parameters and authz headers for > credential transmission. Something you critized for good reasons. > >> something like Basic or Digest to provide the resource owner's >> credentials. That's against the endpoint design. > > It's good to know that restriction, but I'm not happy :-( So based on that > information I would say, the only proper way to integrate standard HTTP > schemes would be to invent another endpoint for that purpose. > > Comments? > > regards, > Torsten. > >> >> EHL >> >> >>> -----Original Message----- >>> From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net] >>> Sent: Monday, January 24, 2011 10:35 PM >>> To: Eran Hammer-Lahav; OAuth WG >>> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with >>> tokensendpoint? >>> >>> Hi Eran, >>> >>> thanks for your response. My inquiry was about end-user authentication >>> and >>> not about client authentication. All http schemes I'm aware of >>> authenticate >>> users and I want to find a way to leverage them with OAuth to determine >>> the >>> token's identity. >>> >>> Regards, >>> Torsten. >>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland >>> >>> -----Original Message----- >>> From: Eran Hammer-Lahav >>> Date: Mon, 24 Jan 2011 15:25:38 >>> To: Torsten Lodderstedt; OAuth >>> WG >>> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >>> endpoint? >>> >>> This is pretty straight-forward. There are no special parameters to >>> indicated >>> which client authentication is being used. It's either there or not, >>> using >>> whatever the server supports. >>> >>> Simply have the token endpoint return a 401 with these WWW-Authenticate >>> headers. As long as you make it clear how to make between the client >>> identifier and the credentials used, you are set. >>> >>> For example, a token response can return: >>> >>> 401 Unauthorized >>> WWW-Authenticate: Basic realm="example" >>> WWW-Authenticate: Digest realm="example" >>> >>> There is no discovery for support for the client_id and client_secret >>> parameters. The client can simply try it or hardcode it based on the >>> server's >>> documentation. >>> >>> Does this help? >>> >>> EHL >>> >>> > -----Original Message----- >>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf >>> > Of Torsten Lodderstedt >>> > Sent: Monday, January 24, 2011 1:10 PM >>> > To: OAuth WG >>> > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >>> > endpoint? >>> > >>> > Hi all, >>> > >>> > I'm currently thinking about the integration of existing HTTP >>> > authentication schemes with OAuth 2.0 for the purpose of end-user >>> > authentication on the tokens endpoint. Possible candidates are "Digest" >>> > for challenge-response-based username/password authentication and >>> > "Spnego" for Kerberos-based authentication. Direct support for both >>> > could be beneficially in enterprise and other security sensitive >>> deployments. >>> > >>> > An direct integration with the tokens endpoint would allow to leverage >>> > existing implementations and infrastructure for OAuth/HTTP-based >>> > architectures. For example, HTTPClient has direct support for Spnego- >>> > Authentication. >>> > >>> > Both HTTP authentication schemes use dedicated WWW-Authenticate and >>> > Authorization headers for passing credential and other data between >>> > client and server. OAuth in contrast uses grant types to indicate the >>> > authentication method, credentials are passed as URI query parameters >>> > and it lacks any discovery of available authentication methods/ grant >>> > types. >>> > >>> > How could one integrate existing schemes into that design? What is our >>> > story? Do we need to define a special grant type "HTTP authorization"? >>> > Shall Authorization headers overrule URI parameters? >>> > >>> > Any ideas of the WG are higly appreciated. >>> > >>> > regards, >>> > Torsten. >>> > >>> > >>> >_______________________________________________ >>> > OAuth mailing 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 Jan 25 15:55:15 2011 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 A6CB03A68EF for ; Tue, 25 Jan 2011 15:55:15 -0800 (PST) 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=[AWL=-0.000, 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 Xgbyhbawczx8 for ; Tue, 25 Jan 2011 15:55:12 -0800 (PST) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 855C83A68E7 for ; Tue, 25 Jan 2011 15:55:12 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Jan 2011 15:58:11 -0800 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.185]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0255.003; Tue, 25 Jan 2011 15:58:11 -0800 From: Anthony Nadalin To: Eran Hammer-Lahav , OAuth WG , "Hannes.Tschofenig@gmx.net" , Blaine Cook Thread-Topic: Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQIaL9Mw Date: Tue, 25 Jan 2011 23:58:10 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18F033A7539TK5EX14MBXC111r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 25 Jan 2011 23:55:15 -0000 --_000_180155C5EA10854997314CA5E063D18F033A7539TK5EX14MBXC111r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb24ndCB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9yIHJlbW92aW5nIHRoZSBjbGllbnQg YXNzZXJ0aW9uIGNyZWRlbnRpYWxzLCBhcyBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24g aXMgbGVmdCBpbi4gQ2xpZW50IFBhc3N3b3JkIEF1dGhlbnRpY2F0aW9uIGlzIGFsc28gdW5kZXJz cGVjaWZpZWQgYXMgY2xpZW50X3NlY3JldCBjb3VsZCBiZSBhbnl0aGluZyB0aGF0IHRoZSBhdXRo ZW50aWNhdGlvbiBzZXJ2ZXIgc2VlbXMgZml0IChyYXcgY2xlYXIgdGV4dCBwYXNzd29yZCwgIGhh c2gsIGRpZ2VzdCwgZXRjLikgYW5kIG5vIHdheSB0byBkZXRlcm1pbmUgdGhlIGNvbnRlbnQuIGNs aWVudF9zZWNyZXQgaXMgYWxzbyBhIHZlcnkgd2VhayBtZWNoYW5pc20sIHNpbmNlIHRoaXMgaXMg bGVmdCBpbiB0aGUgY29yZSB0aGlzIGxlYWRzIG1lIHRvIGJlbGlldmUgdGhhdCB0aGVyZSBpcyBz dXBwb3J0IGZvciBoYXZpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIE9hdXRoLiBJIGRvbid0 IHNlZSBob3cgaGF2aW5nIGNsaWVudF9hc3NlcnRpb24gYW5kIGNsaWVudF9hc3NlcnRpb25fdHlw ZSB3b3VsZCBiZSBzb21ldGhpbmcgdGhhdCBpcyB1bmRlcnNwZWNpZmllZCBhcyBiZWluZyBhIG1l Y2hhbmlzbSBpbiB3aGljaCBhc3NlcnRpb25zIGNhbiBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlv bi4gQWdyZWUgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyIGhhcyB0byBtYWtlIHJpZ2h0 IGFuZCBkZWNsYXJlIHdoYXQgaXMgYmVpbmcgdXNlZCBidXQgdGhhdCBpcyB0aGUgc2FtZSBmb3Ig Y2xpZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGF1dGhlbnRpY2F0aW9u IGFzc2VydGlvbnMgYXJlIHNvbWV0aGluZyB0aGF0IE1pY3Jvc29mdCBhbmQgR29vZ2xlIGZpbmQg dXNlZnVsIGFuZCBwbGFuIG9uIGltcGxlbWVudGluZyBhbmQgdXNpbmcgYXMgYSBtZWFucyBmb3Ig c3Ryb25nZXIgYXV0aGVudGljYXRpb24gdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGlz IGV4dGVuc2liaWxpdHkgYmVsb25ncyBpbiB0aGUgY29yZSwgdGhlcmUgaXMgbm8gb3RoZXIgcGxh Y2UgdG8gcHV0IHRoaXMgZnVuY3Rpb25hbGl0eS4gSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhlIHJl bW92YWwgKGVpdGhlciBieSBlZGl0b3Igb3IgZGlyZWN0aW9uIGJ5IGNvLWNoYWlyKSBpcyBzb21l dGhpbmcgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIGRvbmUgdy9vIGEgY29uc2Vuc3VzIHZvdGUgc2lu Y2UgdGhpcyBoYXMgYmVlbiBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3Igc29tZSB0aW1lIHdpdGhv dXQgaXNzdWUgYW5kIHRoZSByZW1vdmFsIGNvbWVzIGFzIGNvbXBsZXRlIHVud2VsY29tZSBzdXJw cmlzZS4gR2V0dGluZyBhbG1vc3QgdG90YWwgcmV3cml0ZXMgb2YgdGhlIHNwZWNpZmljYXRpb24g dGhpcyBsYXRlIGluIHRoZSByZXZpZXcgY3ljbGUgaXMgYWxzbyB2ZXJ5IGRpc3R1cmJpbmcuDQoN Cg0KDQpBIHByb3Bvc2FsIGZvciBrZWVwaW5nIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gYXNz ZXJ0aW9uIHdvdWxkIGJlIHRvIHNpbXBsaWZ5IHRvIHRoZSBmb2xsb3dpbmc7DQoNClRoZSBjbGll bnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGFyZSB1c2VkIGluIGNhc2VzIHdoZXJlIGEgcGFzc3dv cmQgKGNsZWFyLXRleHQgc2hhcmVkIHN5bW1ldHJpYyBzZWNyZXQpIGlzIHVuc3VpdGFibGUgb3Ig ZG9lcyBub3QgcHJvdmlkZSBzdWZmaWNpZW50IHNlY3VyaXR5IGZvciBjbGllbnQgYXV0aGVudGlj YXRpb24uIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIHByb3ZpZGUgYW4gZXh0ZW5z aWJsZSBtZWNoYW5pc20gdG8gdXNlIGFuIGFzc2VydGlvbiBmb3JtYXQgc3VwcG9ydGVkIGJ5IHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciBmb3IgYXV0aGVudGljYXRpb24gb2YgdGhlIGNsaWVudC4N Cg0KVXNpbmcgYXNzZXJ0aW9ucyByZXF1aXJlcyB0aGUgY2xpZW50IHRvIG9idGFpbiBhbiBhc3Nl cnRpb24gKHN1Y2ggYXMgYSBTQU1MIChDYW50b3IsIFMuLCBLZW1wLCBKLiwgUGhpbHBvdHQsIFIu LCBhbmQgRS4gTWFsZXIsIOKAnEFzc2VydGlvbnMgYW5kIFByb3RvY29sIGZvciB0aGUgT0FTSVMg U2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAoU0FNTCkgVjIuMCzigJ0gTWFyY2gg MjAwNS4pIFtPQVNJUy5zYW1s4oCRY29yZeKAkTIuMOKAkW9zXSBhc3NlcnRpb24pIGZyb20gYW4g YXNzZXJ0aW9uIGlzc3VlciBvciB0byBzZWxmLWlzc3VlIGFuIGFzc2VydGlvbi4gVGhlIGFzc2Vy dGlvbiBmb3JtYXQsIHRoZSBwcm9jZXNzIGJ5IHdoaWNoIHRoZSBhc3NlcnRpb24gaXMgb2J0YWlu ZWQsIGFuZCB0aGUgbWV0aG9kIG9mIHZhbGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmUgZGVmaW5l ZCBieSB0aGUgYXNzZXJ0aW9uIGlzc3VlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBh bmQgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpXaGVuIHVz aW5nIGEgY2xpZW50IGFzc2VydGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgZm9sbG93aW5n IHBhcmFtZXRlcnM6DQpjbGllbnRfYXNzZXJ0aW9uX3R5cGUgLSBSRVFVSVJFRC4gVGhlIGZvcm1h dCBvZiB0aGUgYXNzZXJ0aW9uIGFzIGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy LiBUaGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0ZSBVUkkuDQpjbGllbnRfYXNzZXJ0aW9uIC0g UkVRVUlSRUQuIFRoZSBjbGllbnQgYXNzZXJ0aW9uLg0KDQpGb3IgZXhhbXBsZSwgdGhlIGNsaWVu dCBzZW5kcyB0aGUgZm9sbG93aW5nIGFjY2VzcyB0b2tlbiByZXF1ZXN0IHVzaW5nIGEgU0FNTCAy LjAgYXNzZXJ0aW9uIHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYgKGxpbmUgYnJlYWtzIGFyZSBmb3Ig ZGlzcGxheSBwdXJwb3NlcyBvbmx5KToNCg0KDQoNCg0KDQogIFBPU1QgL3Rva2VuIEhUVFAvMS4x DQoNCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tDQoNCiAgQ29udGVudC1UeXBlOiBhcHBsaWNh dGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQNCg0KDQoNCiAgZ3JhbnRfdHlwZT1hdXRob3JpemF0 aW9uX2NvZGUmY29kZT1pMVdzUm4xdUIxJg0KDQogIGNsaWVudF9hc3NlcnRpb249UEhOaGJXeHdP bFsuLi5vbWl0dGVkIGZvciBicmV2aXR5Li4uXVpUNCUzRCYNCg0KICBjbGllbnRfYXNzZXJ0aW9u X3R5cGU9ICB1cm4lM0FvYXNpcyUzQW5hbWVzJXNBdGMlM0FTQU1MJTNBMi4wJTNBYXNzZXJ0aW9u JnJlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYg0K DQoNCg0KDQoNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmFuIEhhbW1lci1MYWhhdg0KU2VudDogRnJp ZGF5LCBKYW51YXJ5IDE0LCAyMDExIDEwOjQ1IFBNDQpUbzogT0F1dGggV0cNClN1YmplY3Q6IFtP QVVUSC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFscw0KDQpJIHdvdWxk IGxpa2UgdG8gc3VnZ2VzdCB3ZSBkcm9wIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxz ICgtMTEgc2VjdGlvbiAzLjIpIGZyb20gdGhlIHNwZWNpZmljYXRpb24sIGFuZCBpZiBuZWVkZWQs IHB1Ymxpc2ggaXQgYXMgYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgZm9sbG93aW5n IHJlYXNvbnM6DQoNCg0KMS4gICAgICAgVGhlIG1lY2hhbmlzbSBpcyB1bmRlciBzcGVjaWZpZWQs IGVzcGVjaWFsbHkgaW4gaXRzIGhhbmRsaW5nIG9mIHRoZSBjbGllbnRfaWQgaWRlbnRpZmllciAo d2hlbiB1c2VkIHRvIG9idGFpbiBlbmQtdXNlciBhdXRob3JpemF0aW9uKS4gSXQgZG9lcyBub3Qg Y29udGFpbiBhbnkgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byBhY2NvbXBsaXNoIGFueSBsZXZl bCBvZiBpbnRlcm9wZXJhYmlsaXR5IG9yIGZ1bmN0aW9uYWxpdHkuIFRoaXMgaXMgaW4gY29udHJh c3QgdG8gdGhlIGFzc2VydGlvbiBncmFudCB0eXBlIHdoaWNoIGhhcyBtYXR1cmVkIG92ZXIgYSB5 ZWFyIGludG8gYSBmdWxseSB0aG91Z2h0LW91dCBleHRlbnNpb24gbWVjaGFuaXNtLCBhcyB3ZWxs IGFzIGEgc2VwYXJhdGUgU0FNTCBhc3NlcnRpb24gc3BlY2lmaWNhdGlvbiB3aXRoIGFjdGl2ZSBk ZXBsb3ltZW50ICh0aGUgdHdvLCB0b2dldGhlciB3aXRoIHJ1bm5pbmcgY29kZSwgc2hvdyBjbGVh ciBjb25zZW5zdXMpLg0KDQoyLiAgICAgICBUaGUgc2VjdGlvbiBpcyBhIGNvbmZ1c2VkIG1peCBv ZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzcHJpbmtsZWQgd2l0aCBub3JtYXRpdmUgbGFuZ3Vh Z2UuIEluc3RlYWQsIGl0IHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIGd1aWRlbGluZXMgZm9yIGV4 dGVuZGluZyB0aGUgc2V0IG9mIHN1cHBvcnRlZCBjbGllbnQgY3JlZGVudGlhbHMsIGJ1dCB3aXRo b3V0IGRlZmluaW5nIGEgbmV3IHJlZ2lzdHJ5LiBJdCBpcyBjbGVhcmx5IGFuIGFyZWEgb2YgbGl0 dGxlIGRlcGxveW1lbnQgZXhwZXJpZW5jZSBmb3IgT0F1dGgsIGFuZCB0aGF0IGluY2x1ZGVzIHVz aW5nIEhUVFAgQmFzaWMgYXV0aGVudGljYXRpb24gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAo bW9yZSBvbiB0aGF0IHRvIGNvbWUpLg0KDQozLiAgICAgICBUaGUgc2VjdGlvbiBoYXMgcmVjZWl2 ZWQgYSBsaXR0bGUgc3VwcG9ydCBhbmQgYSBsaXR0bGUgb2JqZWN0aW9uLiBUaG9zZSB3aG8gc3Rp bGwgd2FudCB0byBhZHZvY2F0ZSBmb3IgaXQgbmVlZCB0byBzaG93IG5vdCBvbmx5IGNvbnNlbnN1 cyBmb3Iga2VlcGluZyBpdCwgYnV0IGFsc28gYWN0aXZlIGNvbW11bml0eSBzdXBwb3J0IGZvciBk ZXBsb3lpbmcgaXQuIERlcGxveW1lbnQsIG9mIGNvdXJzZSwgd2lsbCBhbHNvIHJlcXVpcmUgc2hv d2luZyBwcm9ncmVzcyBvbiBwdWJsaWMgc3BlY2lmaWNhdGlvbnMgcHJvZmlsaW5nIHRoZSBtZWNo YW5pc20gaW50byBhIHVzZWZ1bCBpbnRlcm9wZXJhYmxlIGZlYXR1cmUuDQoNCkNvbW1lbnRzPyBD b3VudGVyLWFyZ3VtZW50cz8NCg0KRUhMDQoNCg0K --_000_180155C5EA10854997314CA5E063D18F033A7539TK5EX14MBXC111r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0 LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MjQuMHB0Ow0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjI0LjBwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJYmFja2dyb3Vu ZDojQ0NDQ0NDOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn aW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1h cmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28t c3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjpibGFjazsNCgliYWNrZ3JvdW5kOiNDQ0NDQ0M7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTExMzc4NjUw MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMyMTg2 OTg4OCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcx NSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SSBkb24ndCB1bmRlcnN0 YW5kIHRoZSByYXRpb25hbGUgZm9yIHJlbW92aW5nIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRl bnRpYWxzLCBhcyBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gaXMgbGVmdCBpbi4gQ2xp ZW50IFBhc3N3b3JkIEF1dGhlbnRpY2F0aW9uIGlzIGFsc28gdW5kZXJzcGVjaWZpZWQgYXMgY2xp ZW50X3NlY3JldCBjb3VsZCBiZSBhbnl0aGluZyB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbg0KIHNl cnZlciBzZWVtcyBmaXQgKHJhdyBjbGVhciB0ZXh0IHBhc3N3b3JkLCZuYnNwOyBoYXNoLCBkaWdl c3QsIGV0Yy4pIGFuZCBubyB3YXkgdG8gZGV0ZXJtaW5lIHRoZSBjb250ZW50LiBjbGllbnRfc2Vj cmV0IGlzIGFsc28gYSB2ZXJ5IHdlYWsgbWVjaGFuaXNtLCBzaW5jZSB0aGlzIGlzIGxlZnQgaW4g dGhlIGNvcmUgdGhpcyBsZWFkcyBtZSB0byBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgc3VwcG9ydCBm b3IgaGF2aW5nIGNsaWVudCBhdXRoZW50aWNhdGlvbg0KIGluIE9hdXRoLiBJIGRvbid0IHNlZSBo b3cgaGF2aW5nIGNsaWVudF9hc3NlcnRpb24gYW5kIGNsaWVudF9hc3NlcnRpb25fdHlwZSB3b3Vs ZCBiZSBzb21ldGhpbmcgdGhhdCBpcyB1bmRlcnNwZWNpZmllZCBhcyBiZWluZyBhIG1lY2hhbmlz bSBpbiB3aGljaCBhc3NlcnRpb25zIGNhbiBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbi4gQWdy ZWUgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyIGhhcyB0byBtYWtlIHJpZ2h0IGFuZCBk ZWNsYXJlDQogd2hhdCBpcyBiZWluZyB1c2VkIGJ1dCB0aGF0IGlzIHRoZSBzYW1lIGZvciBjbGll bnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gYXNz ZXJ0aW9ucyBhcmUgc29tZXRoaW5nIHRoYXQgTWljcm9zb2Z0IGFuZCBHb29nbGUgZmluZCB1c2Vm dWwgYW5kIHBsYW4gb24gaW1wbGVtZW50aW5nIGFuZCB1c2luZyBhcyBhIG1lYW5zIGZvciBzdHJv bmdlciBhdXRoZW50aWNhdGlvbiB0byB0aGUgYXV0aG9yaXphdGlvbg0KIHNlcnZlci4gVGhpcyBl eHRlbnNpYmlsaXR5IGJlbG9uZ3MgaW4gdGhlIGNvcmUsIHRoZXJlIGlzIG5vIG90aGVyIHBsYWNl IHRvIHB1dCB0aGlzIGZ1bmN0aW9uYWxpdHkuIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoZSByZW1v dmFsIChlaXRoZXIgYnkgZWRpdG9yIG9yIGRpcmVjdGlvbiBieSBjby1jaGFpcikgaXMgc29tZXRo aW5nIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiBkb25lIHcvbyBhIGNvbnNlbnN1cyB2b3RlIHNpbmNl IHRoaXMgaGFzIGJlZW4NCiBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3Igc29tZSB0aW1lIHdpdGhv dXQgaXNzdWUgYW5kIHRoZSByZW1vdmFsIGNvbWVzIGFzIGNvbXBsZXRlIHVud2VsY29tZSBzdXJw cmlzZS4gR2V0dGluZyBhbG1vc3QgdG90YWwgcmV3cml0ZXMgb2YgdGhlIHNwZWNpZmljYXRpb24g dGhpcyBsYXRlIGluIHRoZSByZXZpZXcgY3ljbGUgaXMgYWxzbyB2ZXJ5IGRpc3R1cmJpbmcuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkEgcHJvcG9zYWwgZm9yIGtlZXBpbmcgdGhlIGNs aWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gd291bGQgYmUgdG8gc2ltcGxpZnkgdG8gdGhl IGZvbGxvd2luZzs8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj5UaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhcmUgdXNlZCBpbiBjYXNl cyB3aGVyZSBhIHBhc3N3b3JkIChjbGVhci10ZXh0IHNoYXJlZCBzeW1tZXRyaWMgc2VjcmV0KSBp cyB1bnN1aXRhYmxlIG9yIGRvZXMgbm90IHByb3ZpZGUgc3VmZmljaWVudCBzZWN1cml0eSBmb3Ig Y2xpZW50IGF1dGhlbnRpY2F0aW9uLg0KIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxz IHByb3ZpZGUgYW4gZXh0ZW5zaWJsZSBtZWNoYW5pc20gdG8gdXNlIGFuIGFzc2VydGlvbiBmb3Jt YXQgc3VwcG9ydGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBmb3IgYXV0aGVudGljYXRp b24gb2YgdGhlIGNsaWVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Vc2luZyBhc3NlcnRpb25zIHJlcXVpcmVzIHRoZSBjbGll bnQgdG8gb2J0YWluIGFuIGFzc2VydGlvbiAoc3VjaCBhcyBhDQo8L3NwYW4+PGEgaHJlZj0iI09B U0lTLnNhbWwtY29yZS0yLjAtb3MiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O3RleHQtZGVjb3JhdGlv bjpub25lIj5TQU1MIChDYW50b3IsIFMuLCBLZW1wLCBKLiwgUGhpbHBvdHQsIFIuLCBhbmQgRS4g TWFsZXIsIOKAnEFzc2VydGlvbnMgYW5kIFByb3RvY29sIGZvciB0aGUgT0FTSVMgU2VjdXJpdHkg QXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAoU0FNTCkNCiBWMi4wLOKAnSBNYXJjaCZuYnNwOzIw MDUuKTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtW ZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBbT0FTSVMu c2FtbOKAkWNvcmXigJEyLjDigJFvc10gYXNzZXJ0aW9uKSBmcm9tIGFuIGFzc2VydGlvbiBpc3N1 ZXIgb3IgdG8gc2VsZi1pc3N1ZSBhbiBhc3NlcnRpb24uIFRoZSBhc3NlcnRpb24gZm9ybWF0LCB0 aGUgcHJvY2VzcyBieSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlzIG9idGFpbmVkLA0KIGFuZCB0aGUg bWV0aG9kIG9mIHZhbGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmUgZGVmaW5lZCBieSB0aGUgYXNz ZXJ0aW9uIGlzc3VlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBhbmQgYXJlIGJleW9u ZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldoZW4gdXNpbmcgYSBjbGll bnQgYXNzZXJ0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVy czoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTow aW47bWFyZ2luLWxlZnQ6NjAuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Y2xpZW50Xzwvc3Bhbj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+YXNzZXJ0aW9uX3R5cGUgLSBSRVFVSVJFRC4gVGhlDQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmZvcm1hdCBvZiB0aGUgYXNzZXJ0aW9uIGFz IGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgdmFsdWUgTVVTVCBiZSBh biBhYnNvbHV0ZSBVUkkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjQuMHB0O3RleHQtaW5kZW50Oi41aW4iPjxzcGFuIGxh bmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5jbGllbnRfYXNzZXJ0aW9uIC0gUkVRVUlSRUQuIFRo ZSBjbGllbnQgYXNzZXJ0aW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZvciBleGFtcGxlLCB0aGUgY2xpZW50IHNlbmRzIHRo ZSBmb2xsb3dpbmcgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXNpbmcgYSBTQU1MIDIuMCBhc3NlcnRp b24gdG8gYXV0aGVudGljYXRlIGl0c2VsZiAobGluZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1 cnBvc2VzIG9ubHkpOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1ib3R0b206MGluO21h cmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDowaW47bWFyZ2luLXJpZ2h0OjI0LjBwdDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVm dDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsgUE9TVCAv dG9rZW4gSFRUUC8xLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjI0LjBwdDttYXJnaW4tYm90dG9tOjBpbjtt YXJnaW4tbGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTiI+ Jm5ic3A7IEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13 d3ctZm9ybS11cmxlbmNvZGVkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RU4iPiZuYnNwOyBncmFudF90eXBlPWF1dGhvcml6YXRpb25fY29kZSZhbXA7Y29kZT1pMVdzUm4x dUIxJmFtcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4iPiZu YnNwOyBjbGllbnRfYXNzZXJ0aW9uPVBITmhiV3h3T2xbLi4ub21pdHRlZCBmb3IgYnJldml0eS4u Ll1aVDQlM0QmYW1wOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF TiI+Jm5ic3A7IGNsaWVudF9hc3NlcnRpb25fdHlwZT0gJm5ic3A7dXJuJTNBb2FzaXMlM0FuYW1l cyVzQXRjJTNBU0FNTCUzQTIuMCUzQWFzc2VydGlvbiZhbXA7cmVkaXJlY3RfdXJpPWh0dHBzJTNB JTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDoyNC4wcHQ7 bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6NjAuMHB0O21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gbGFuZz0iRU4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gb2F1dGgtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkVyYW4gSGFtbWVyLUxhaGF2PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSmFudWFy eSAxNCwgMjAxMSAxMDo0NSBQTTxicj4NCjxiPlRvOjwvYj4gT0F1dGggV0c8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBs aWtlIHRvIHN1Z2dlc3Qgd2UgZHJvcCB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyAo LTExIHNlY3Rpb24gMy4yKSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uLCBhbmQgaWYgbmVlZGVkLCBw dWJsaXNoIGl0IGFzIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIGZvbGxvd2luZyBy ZWFzb25zOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIG1lY2hhbmlzbSBpcyB1bmRlciBzcGVj aWZpZWQsIGVzcGVjaWFsbHkgaW4gaXRzIGhhbmRsaW5nIG9mIHRoZSBjbGllbnRfaWQgaWRlbnRp ZmllciAod2hlbiB1c2VkIHRvIG9idGFpbiBlbmQtdXNlciBhdXRob3JpemF0aW9uKS4gSXQgZG9l cyBub3QgY29udGFpbiBhbnkgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byBhY2NvbXBsaXNoIGFu eSBsZXZlbCBvZiBpbnRlcm9wZXJhYmlsaXR5IG9yIGZ1bmN0aW9uYWxpdHkuDQogVGhpcyBpcyBp biBjb250cmFzdCB0byB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUgd2hpY2ggaGFzIG1hdHVyZWQg b3ZlciBhIHllYXIgaW50byBhIGZ1bGx5IHRob3VnaHQtb3V0IGV4dGVuc2lvbiBtZWNoYW5pc20s IGFzIHdlbGwgYXMgYSBzZXBhcmF0ZSBTQU1MIGFzc2VydGlvbiBzcGVjaWZpY2F0aW9uIHdpdGgg YWN0aXZlIGRlcGxveW1lbnQgKHRoZSB0d28sIHRvZ2V0aGVyIHdpdGggcnVubmluZyBjb2RlLCBz aG93IGNsZWFyIGNvbnNlbnN1cykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ VGhlIHNlY3Rpb24gaXMgYSBjb25mdXNlZCBtaXggb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c3ByaW5rbGVkIHdpdGggbm9ybWF0aXZlIGxhbmd1YWdlLiBJbnN0ZWFkLCBpdCBzaG91bGQgYmUg cmVwbGFjZWQgd2l0aCBndWlkZWxpbmVzIGZvciBleHRlbmRpbmcgdGhlIHNldCBvZiBzdXBwb3J0 ZWQgY2xpZW50IGNyZWRlbnRpYWxzLCBidXQgd2l0aG91dCBkZWZpbmluZyBhIG5ldyByZWdpc3Ry eS4gSXQNCiBpcyBjbGVhcmx5IGFuIGFyZWEgb2YgbGl0dGxlIGRlcGxveW1lbnQgZXhwZXJpZW5j ZSBmb3IgT0F1dGgsIGFuZCB0aGF0IGluY2x1ZGVzIHVzaW5nIEhUVFAgQmFzaWMgYXV0aGVudGlj YXRpb24gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAobW9yZSBvbiB0aGF0IHRvIGNvbWUpLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBzZWN0aW9uIGhhcyByZWNlaXZl ZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3NlIHdobyBzdGls bCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkgY29uc2Vuc3Vz IGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBvcnQgZm9yIGRl cGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsDQogYWxzbyByZXF1aXJlIHNo b3dpbmcgcHJvZ3Jlc3Mgb24gcHVibGljIHNwZWNpZmljYXRpb25zIHByb2ZpbGluZyB0aGUgbWVj aGFuaXNtIGludG8gYSB1c2VmdWwgaW50ZXJvcGVyYWJsZSBmZWF0dXJlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Db21tZW50cz8gQ291bnRlci1hcmd1bWVudHM/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkVITDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_180155C5EA10854997314CA5E063D18F033A7539TK5EX14MBXC111r_-- From mscurtescu@google.com Tue Jan 25 16:59:30 2011 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 12D093A68EF for ; Tue, 25 Jan 2011 16:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.325 X-Spam-Level: X-Spam-Status: No, score=-104.325 tagged_above=-999 required=5 tests=[AWL=-1.348, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 gN2ORjdLinxW for ; Tue, 25 Jan 2011 16:59:29 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id C84EF3A68E8 for ; Tue, 25 Jan 2011 16:59:28 -0800 (PST) Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p0Q12Qhd015235 for ; Tue, 25 Jan 2011 17:02:26 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296003747; bh=6F990LQYo/jrfU7MeBjsQrF38Bg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=W3tC9I36Kl97rpdv/lDMECxbGcaRT8tgBegMxf5GEAGtMAXEbt4WlAqRAg9z9M2sa fXmnqA09SvXwkUmB39SfA== Received: from yxd30 (yxd30.prod.google.com [10.190.1.222]) by kpbe16.cbf.corp.google.com with ESMTP id p0Q11Zet013939 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 25 Jan 2011 17:02:25 -0800 Received: by yxd30 with SMTP id 30so3221243yxd.25 for ; Tue, 25 Jan 2011 17:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=5wGXngwcbbl1Itojq9R0qSY6+BTN/QTD1UqR3uL4BtU=; b=JLExjNa7crBJ7Y9UmA80+Wzo3AafcRFnZgdGuDz6dI40VrBBOUOLDi8nnnBmxHzRAu kjECW6K6vEKbLjRDXs0A== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=CwZoeh6knHg+iR5PQRZ20kgz9U6o3mr48o9fRBv90ObDJIsJfmd9hsSfj7qIs6W1Xj CmiEGszgQYWnlseQHTcw== Received: by 10.100.137.7 with SMTP id k7mr4399033and.248.1296003744687; Tue, 25 Jan 2011 17:02:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Tue, 25 Jan 2011 17:02:04 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Tue, 25 Jan 2011 17:02:04 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 00:59:30 -0000 On Thu, Jan 20, 2011 at 9:41 PM, Eran Hammer-Lahav wrote: > Forgot to mention that I don't have any outstanding comments in my queue so if your feedback was not incorporated into -12, and you feel strongly about it, bring it up again. >From an older email, adapted to v12: 1. The token_type parameter is required in responses from the server. If the server supports multiple formats, which one will be used? In this case, would it make sense to allow the client to request a specific format? For example, if the authorization server supports both MAC and BEARER, which one will the server issue? 2. Section 8.2. What about applications using legacy parameters? Does not make much sense to register them, and they cannot be changed to x_. Broken record: using a prefix for all registered parameters is much cleaner (as opposed to requiring that all no-registered parameters use a prefix). For Google it is impossible to comply with this requirement. Marius From recordond@gmail.com Tue Jan 25 17:08:17 2011 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 9F0943A68B8 for ; Tue, 25 Jan 2011 17:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=0.715, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cWGO2hMdkh+B for ; Tue, 25 Jan 2011 17:08:09 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8DF6C3A68EF for ; Tue, 25 Jan 2011 17:08:09 -0800 (PST) Received: by iwn40 with SMTP id 40so425853iwn.31 for ; Tue, 25 Jan 2011 17:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6bNBtzVuu3Ap7VPJRswrQbL1sLEHTvnIvnBc8g4/HSE=; b=V1sMdthr3kDOrU7dUELLpLYg9fWQr1yoIP68lfV1lHa3EhMliIQZtEGB8KCOIlfF++ mQ4JZSHqtx1UvZY+YRETzWON/F555B7Tu4mFTAczN3Rh6SlCfCVAnqFxN0+FPQEAuxAA OwfuOGn3jIKkj+U4DWiA0Dnva5H7f1SlCm66c= 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=dgQ60PMn8VXH9Q+0Awdojq6x2iTSbm/c67+6pdL64k8dJBhYBPVuK+tX7tqCLJiSMw BSpBfni+3qH7TqjBwJNsEdF9iqIFnm2wYUP3IKzQZhbGtrjtKOelWkI3klLYSF53VIXX pyxdwA3hxKs4A2n9Ilse5h50vHx5J/Y9IdFcs= MIME-Version: 1.0 Received: by 10.231.208.17 with SMTP id ga17mr7509049ibb.121.1296004268427; Tue, 25 Jan 2011 17:11:08 -0800 (PST) Received: by 10.231.160.21 with HTTP; Tue, 25 Jan 2011 17:11:08 -0800 (PST) In-Reply-To: <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> Date: Tue, 25 Jan 2011 17:11:08 -0800 Message-ID: From: David Recordon To: Anthony Nadalin , "Hannes.Tschofenig@gmx.net" , Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=90e6ba5bc9230c08da049ab58223 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 26 Jan 2011 01:08:17 -0000 --90e6ba5bc9230c08da049ab58223 Content-Type: text/plain; charset=ISO-8859-1 Explicitly saying, "The assertion format, the process by which the assertion is obtained, and the method of validating the assertion are defined by the assertion issuer and the authorization server, and are beyond the scope of this specification" seems to reinforce the point about this being underspecified. This would still require a second document which describes the data within the SAML assertion as well as how it maps back to a client_id. On the process side, IIRC this was added to the spec without any consensus and over some reservations by Eran...which was a broken process to begin with and a poor decision on his part. I share Hannes' desire to move this base spec to last call. Worried that leaving this text in is going to delay that whereas moving it to a separate document published by the OAuth WG will still lead toward market adoption of a more fully specified feature. --David On Tue, Jan 25, 2011 at 3:58 PM, Anthony Nadalin wrote: > I don't understand the rationale for removing the client assertion > credentials, as client password authentication is left in. Client Password > Authentication is also underspecified as client_secret could be anything > that the authentication server seems fit (raw clear text password, hash, > digest, etc.) and no way to determine the content. client_secret is also a > very weak mechanism, since this is left in the core this leads me to believe > that there is support for having client authentication in Oauth. I don't see > how having client_assertion and client_assertion_type would be something > that is underspecified as being a mechanism in which assertions can be used > for authentication. Agree that the authentication server has to make right > and declare what is being used but that is the same for client password > authentication. The client authentication assertions are something that > Microsoft and Google find useful and plan on implementing and using as a > means for stronger authentication to the authorization server. This > extensibility belongs in the core, there is no other place to put this > functionality. I don't believe that the removal (either by editor or > direction by co-chair) is something that should have been done w/o a > consensus vote since this has been in the specification for some time > without issue and the removal comes as complete unwelcome surprise. Getting > almost total rewrites of the specification this late in the review cycle is > also very disturbing. > > > > A proposal for keeping the client authentication assertion would be to > simplify to the following; > > The client assertion credentials are used in cases where a password > (clear-text shared symmetric secret) is unsuitable or does not provide > sufficient security for client authentication. The client assertion > credentials provide an extensible mechanism to use an assertion format > supported by the authorization server for authentication of the client. > > Using assertions requires the client to obtain an assertion (such as a SAML > (Cantor, S., Kemp, J., Philpott, R., and E. Maler, "Assertions and Protocol > for the OASIS Security Assertion Markup Language (SAML) V2.0," March 2005.)<#12dbf9d29a2ee7cd_OASIS.saml-core-2.0-os>[OASIS.saml-core-2.0-os] assertion) from an assertion issuer or to > self-issue an assertion. The assertion format, the process by which the > assertion is obtained, and the method of validating the assertion are > defined by the assertion issuer and the authorization server, and are beyond > the scope of this specification. > > When using a client assertion, the client includes the following > parameters: > > client_assertion_type - REQUIRED. The format of the assertion as defined > by the authorization server. The value MUST be an absolute URI. > > client_assertion - REQUIRED. The client assertion. > > For example, the client sends the following access token request using a > SAML 2.0 assertion to authenticate itself (line breaks are for display > purposes only): > > > > > > POST /token HTTP/1.1 > > Host: server.example.com > > Content-Type: application/x-www-form-urlencoded > > > > grant_type=authorization_code&code=i1WsRn1uB1& > > client_assertion=PHNhbWxwOl[...omitted for brevity...]ZT4%3D& > > client_assertion_type= urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb > > > > > > > > > > *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf > Of *Eran Hammer-Lahav > *Sent:* Friday, January 14, 2011 10:45 PM > *To:* OAuth WG > *Subject:* [OAUTH-WG] Removal: Client Assertion Credentials > > > > I would like to suggest we drop the client assertion credentials (-11 > section 3.2) from the specification, and if needed, publish it as a separate > specification for the following reasons: > > > > 1. The mechanism is under specified, especially in its handling of > the client_id identifier (when used to obtain end-user authorization). It > does not contain any implementation details to accomplish any level of > interoperability or functionality. This is in contrast to the assertion > grant type which has matured over a year into a fully thought-out extension > mechanism, as well as a separate SAML assertion specification with active > deployment (the two, together with running code, show clear consensus). > > 2. The section is a confused mix of security considerations > sprinkled with normative language. Instead, it should be replaced with > guidelines for extending the set of supported client credentials, but > without defining a new registry. It is clearly an area of little deployment > experience for OAuth, and that includes using HTTP Basic authentication for > client authentication (more on that to come). > > 3. The section has received a little support and a little objection. > Those who still want to advocate for it need to show not only consensus for > keeping it, but also active community support for deploying it. Deployment, > of course, will also require showing progress on public specifications > profiling the mechanism into a useful interoperable feature. > > > > Comments? Counter-arguments? > > > > EHL > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --90e6ba5bc9230c08da049ab58223 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Explicitly saying, "The assertion format, the process by which the assertion= is obtained, and the method of validating the assertion are defined by the= assertion issuer and the authorization server, and are beyond the scope of= this specification" seems to reinforce the point about this being und= erspecified. This would still require a second document which describes the= data within the SAML assertion as well as how it maps back to a client_id.=

On the proc= ess side, IIRC this was added to the spec without any consensus and over so= me reservations by Eran...which was a broken process to begin with and a po= or decision on his part. I share Hannes' desire to move this base spec = to last call. Worried that leaving this text in is going to delay that wher= eas moving it to a separate document published by the OAuth WG will still l= ead toward market adoption of a more fully specified feature.=

<= span class=3D"Apple-style-span" style=3D"border-collapse: collapse;">--Davi= d


On Tue, Jan 25, 2011 at 3:58 PM, Anthony = Nadalin <tony= nad@microsoft.com> wrote:

I don't understand the rationale for removing the client assertion c= redentials, as client password authentication is left in. Client Password A= uthentication is also underspecified as client_secret could be anything tha= t the authentication server seems fit (raw clear text password,  hash, digest, etc.) and n= o way to determine the content. client_secret is also a very weak mechanism= , since this is left in the core this leads me to believe that there is sup= port for having client authentication in Oauth. I don't see how having client_assertion and client_assertion= _type would be something that is underspecified as being a mechanism in whi= ch assertions can be used for authentication. Agree that the authentication= server has to make right and declare what is being used but that is the same for client password authentication= . The client authentication assertions are something that Microsoft and Goo= gle find useful and plan on implementing and using as a means for stronger = authentication to the authorization server. This extensibility belongs in the core, there is no other place to= put this functionality. I don't believe that the removal (either by ed= itor or direction by co-chair) is something that should have been done w/o = a consensus vote since this has been in the specification for some time without issue and the removal comes as = complete unwelcome surprise. Getting almost total rewrites of the specifica= tion this late in the review cycle is also very disturbing.

 

A proposal for keeping the client authentication assertion would be to s= implify to the following;

The client assertion credentials= are used in cases where a password (clear-text shared symmetric secret) is= unsuitable or does not provide sufficient security for client authenticati= on. The client assertion credentials provide an extensible mechanism to use an= assertion format supported by the authorization server for authentication = of the client.

Using assertions requires the cl= ient to obtain an assertion (such as a SAML (Cantor, S., Kemp, J., Philpott, R.,= and E. Maler, “Assertions and Protocol for the OASIS Security Assert= ion Markup Language (SAML) V2.0,” March 2005.) [OASIS.saml‑core‑2.0‑os] assertion) from an asser= tion issuer or to self-issue an assertion. The assertion format, the proces= s by which the assertion is obtained, and the method of validating the assertion are defined by the assertion is= suer and the authorization server, and are beyond the scope of this specifi= cation.

When using a client assertion, t= he client includes the following parameters:

client_assertion_type - REQUIRED. The format of the assertion as d= efined by the authorization server. The value MUST be an absolute URI.

client_assertion - REQUIRED. The client a= ssertion.

For example, the client sends th= e following access token request using a SAML 2.0 assertion to authenticate= itself (line breaks are for display purposes only): 

 
 
  POST /token HTTP/1.1
  Host: server.example.com
  Content-Type: application/x-www-form-urlencod=
ed
 
  grant_type=3Dauthorization_code&code=3Di1=
WsRn1uB1&
  client_assertion=3DPHNhbWxwOl[...omitted for =
brevity...]ZT4%3D&
  client_assertion_type=3D  urn%3Aoasis%3A=
names%sAtc%3ASAML%3A2.0%3Aassertion&redirect_uri=3Dhttps%3A%2F%2Fclient=
%2Eexample%2Ecom%2Fcb
 

 

 

 

From:= oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav
Sent: Friday, January 14, 2011 10:45 PM
To: OAuth WG
Subject: [OAUTH-WG] Removal: Client Assertion Credentials

 

I would like to suggest we drop the client assertion= credentials (-11 section 3.2) from the specification, and if needed, publi= sh it as a separate specification for the following reasons:

 

1. &nb= sp;     The mechanism is under specified, especially in its handling = of the client_id identifier (when used to obtain end-user authorization). I= t does not contain any implementation details to accomplish any level of in= teroperability or functionality. This is in contrast to the assertion grant type which has matured over a y= ear into a fully thought-out extension mechanism, as well as a separate SAM= L assertion specification with active deployment (the two, together with ru= nning code, show clear consensus).

2. &nb= sp;     The section is a confused mix of security considerations spri= nkled with normative language. Instead, it should be replaced with guidelin= es for extending the set of supported client credentials, but without defin= ing a new registry. It is clearly an area of little deployment experience for OAuth, and that inc= ludes using HTTP Basic authentication for client authentication (more on th= at to come).

3. &nb= sp;     The section has received a little support and a little object= ion. Those who still want to advocate for it need to show not only consensu= s for keeping it, but also active community support for deploying it. Deplo= yment, of course, will also require showing progress on public specifications profiling the mecha= nism into a useful interoperable feature.

 

Comments? Counter-arguments?

 

EHL

 

 


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


--90e6ba5bc9230c08da049ab58223-- From tonynad@microsoft.com Tue Jan 25 17:28:45 2011 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 ACFAD3A68B0 for ; Tue, 25 Jan 2011 17:28:45 -0800 (PST) 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=[AWL=-0.000, 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 ODVW4UWiQQum for ; Tue, 25 Jan 2011 17:28:43 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 91CC33A68AC for ; Tue, 25 Jan 2011 17:28:43 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Jan 2011 17:31:36 -0800 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.185]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0255.003; Tue, 25 Jan 2011 17:31:35 -0800 From: Anthony Nadalin To: David Recordon , "Hannes.Tschofenig@gmx.net" , Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQIaL9MwABSNlwAAEKmTQA== Date: Wed, 26 Jan 2011 01:31:35 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F033A7757@TK5EX14MBXC111.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18F033A7757TK5EX14MBXC111r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 26 Jan 2011 01:28:45 -0000 --_000_180155C5EA10854997314CA5E063D18F033A7757TK5EX14MBXC111r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmFzZWQgb24geW91ciBsb2dpYyB0aGVuIFNjb3BlLCBDbGllbnQgUGFzc3dvcmQgQXV0aGVudGlj YXRpb24sIGV0Yywgc2hvdWxkIGJlIHJlbW92ZWQuIE5vdCBzdXJlIGhvdyBsZWF2aW5nIHRoZSBw cm9wb3NlZCB0ZXh0IGluIHdvdWxkIGRlbGF5IHRoaW5ncw0KDQpGcm9tOiBEYXZpZCBSZWNvcmRv biBbbWFpbHRvOnJlY29yZG9uZEBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI1 LCAyMDExIDU6MTEgUE0NClRvOiBBbnRob255IE5hZGFsaW47IEhhbm5lcy5Uc2Nob2ZlbmlnQGdt eC5uZXQ7IEVyYW4gSGFtbWVyLUxhaGF2DQpDYzogT0F1dGggV0c7IEJsYWluZSBDb29rDQpTdWJq ZWN0OiBSZTogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxz DQoNCkV4cGxpY2l0bHkgc2F5aW5nLCAiVGhlIGFzc2VydGlvbiBmb3JtYXQsIHRoZSBwcm9jZXNz IGJ5IHdoaWNoIHRoZSBhc3NlcnRpb24gaXMgb2J0YWluZWQsIGFuZCB0aGUgbWV0aG9kIG9mIHZh bGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmUgZGVmaW5lZCBieSB0aGUgYXNzZXJ0aW9uIGlzc3Vl ciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBhbmQgYXJlIGJleW9uZCB0aGUgc2NvcGUg b2YgdGhpcyBzcGVjaWZpY2F0aW9uIiBzZWVtcyB0byByZWluZm9yY2UgdGhlIHBvaW50IGFib3V0 IHRoaXMgYmVpbmcgdW5kZXJzcGVjaWZpZWQuIFRoaXMgd291bGQgc3RpbGwgcmVxdWlyZSBhIHNl Y29uZCBkb2N1bWVudCB3aGljaCBkZXNjcmliZXMgdGhlIGRhdGEgd2l0aGluIHRoZSBTQU1MIGFz c2VydGlvbiBhcyB3ZWxsIGFzIGhvdyBpdCBtYXBzIGJhY2sgdG8gYSBjbGllbnRfaWQuDQoNCk9u IHRoZSBwcm9jZXNzIHNpZGUsIElJUkMgdGhpcyB3YXMgYWRkZWQgdG8gdGhlIHNwZWMgd2l0aG91 dCBhbnkgY29uc2Vuc3VzIGFuZCBvdmVyIHNvbWUgcmVzZXJ2YXRpb25zIGJ5IEVyYW4uLi53aGlj aCB3YXMgYSBicm9rZW4gcHJvY2VzcyB0byBiZWdpbiB3aXRoIGFuZCBhIHBvb3IgZGVjaXNpb24g b24gaGlzIHBhcnQuIEkgc2hhcmUgSGFubmVzJyBkZXNpcmUgdG8gbW92ZSB0aGlzIGJhc2Ugc3Bl YyB0byBsYXN0IGNhbGwuIFdvcnJpZWQgdGhhdCBsZWF2aW5nIHRoaXMgdGV4dCBpbiBpcyBnb2lu ZyB0byBkZWxheSB0aGF0IHdoZXJlYXMgbW92aW5nIGl0IHRvIGEgc2VwYXJhdGUgZG9jdW1lbnQg cHVibGlzaGVkIGJ5IHRoZSBPQXV0aCBXRyB3aWxsIHN0aWxsIGxlYWQgdG93YXJkIG1hcmtldCBh ZG9wdGlvbiBvZiBhIG1vcmUgZnVsbHkgc3BlY2lmaWVkIGZlYXR1cmUuDQoNCi0tRGF2aWQNCg0K T24gVHVlLCBKYW4gMjUsIDIwMTEgYXQgMzo1OCBQTSwgQW50aG9ueSBOYWRhbGluIDx0b255bmFk QG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpJ IGRvbid0IHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBmb3IgcmVtb3ZpbmcgdGhlIGNsaWVudCBh c3NlcnRpb24gY3JlZGVudGlhbHMsIGFzIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiBp cyBsZWZ0IGluLiBDbGllbnQgUGFzc3dvcmQgQXV0aGVudGljYXRpb24gaXMgYWxzbyB1bmRlcnNw ZWNpZmllZCBhcyBjbGllbnRfc2VjcmV0IGNvdWxkIGJlIGFueXRoaW5nIHRoYXQgdGhlIGF1dGhl bnRpY2F0aW9uIHNlcnZlciBzZWVtcyBmaXQgKHJhdyBjbGVhciB0ZXh0IHBhc3N3b3JkLCAgaGFz aCwgZGlnZXN0LCBldGMuKSBhbmQgbm8gd2F5IHRvIGRldGVybWluZSB0aGUgY29udGVudC4gY2xp ZW50X3NlY3JldCBpcyBhbHNvIGEgdmVyeSB3ZWFrIG1lY2hhbmlzbSwgc2luY2UgdGhpcyBpcyBs ZWZ0IGluIHRoZSBjb3JlIHRoaXMgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIHN1 cHBvcnQgZm9yIGhhdmluZyBjbGllbnQgYXV0aGVudGljYXRpb24gaW4gT2F1dGguIEkgZG9uJ3Qg c2VlIGhvdyBoYXZpbmcgY2xpZW50X2Fzc2VydGlvbiBhbmQgY2xpZW50X2Fzc2VydGlvbl90eXBl IHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGlzIHVuZGVyc3BlY2lmaWVkIGFzIGJlaW5nIGEgbWVj aGFuaXNtIGluIHdoaWNoIGFzc2VydGlvbnMgY2FuIGJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9u LiBBZ3JlZSB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgaGFzIHRvIG1ha2UgcmlnaHQg YW5kIGRlY2xhcmUgd2hhdCBpcyBiZWluZyB1c2VkIGJ1dCB0aGF0IGlzIHRoZSBzYW1lIGZvciBj bGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXV0aGVudGljYXRpb24g YXNzZXJ0aW9ucyBhcmUgc29tZXRoaW5nIHRoYXQgTWljcm9zb2Z0IGFuZCBHb29nbGUgZmluZCB1 c2VmdWwgYW5kIHBsYW4gb24gaW1wbGVtZW50aW5nIGFuZCB1c2luZyBhcyBhIG1lYW5zIGZvciBz dHJvbmdlciBhdXRoZW50aWNhdGlvbiB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoaXMg ZXh0ZW5zaWJpbGl0eSBiZWxvbmdzIGluIHRoZSBjb3JlLCB0aGVyZSBpcyBubyBvdGhlciBwbGFj ZSB0byBwdXQgdGhpcyBmdW5jdGlvbmFsaXR5LiBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGUgcmVt b3ZhbCAoZWl0aGVyIGJ5IGVkaXRvciBvciBkaXJlY3Rpb24gYnkgY28tY2hhaXIpIGlzIHNvbWV0 aGluZyB0aGF0IHNob3VsZCBoYXZlIGJlZW4gZG9uZSB3L28gYSBjb25zZW5zdXMgdm90ZSBzaW5j ZSB0aGlzIGhhcyBiZWVuIGluIHRoZSBzcGVjaWZpY2F0aW9uIGZvciBzb21lIHRpbWUgd2l0aG91 dCBpc3N1ZSBhbmQgdGhlIHJlbW92YWwgY29tZXMgYXMgY29tcGxldGUgdW53ZWxjb21lIHN1cnBy aXNlLiBHZXR0aW5nIGFsbW9zdCB0b3RhbCByZXdyaXRlcyBvZiB0aGUgc3BlY2lmaWNhdGlvbiB0 aGlzIGxhdGUgaW4gdGhlIHJldmlldyBjeWNsZSBpcyBhbHNvIHZlcnkgZGlzdHVyYmluZy4NCg0K DQoNCkEgcHJvcG9zYWwgZm9yIGtlZXBpbmcgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3Nl cnRpb24gd291bGQgYmUgdG8gc2ltcGxpZnkgdG8gdGhlIGZvbGxvd2luZzsNCg0KVGhlIGNsaWVu dCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYXJlIHVzZWQgaW4gY2FzZXMgd2hlcmUgYSBwYXNzd29y ZCAoY2xlYXItdGV4dCBzaGFyZWQgc3ltbWV0cmljIHNlY3JldCkgaXMgdW5zdWl0YWJsZSBvciBk b2VzIG5vdCBwcm92aWRlIHN1ZmZpY2llbnQgc2VjdXJpdHkgZm9yIGNsaWVudCBhdXRoZW50aWNh dGlvbi4gVGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgcHJvdmlkZSBhbiBleHRlbnNp YmxlIG1lY2hhbmlzbSB0byB1c2UgYW4gYXNzZXJ0aW9uIGZvcm1hdCBzdXBwb3J0ZWQgYnkgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGZvciBhdXRoZW50aWNhdGlvbiBvZiB0aGUgY2xpZW50Lg0K DQpVc2luZyBhc3NlcnRpb25zIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFzc2Vy dGlvbiAoc3VjaCBhcyBhIFNBTUwgKENhbnRvciwgUy4sIEtlbXAsIEouLCBQaGlscG90dCwgUi4s IGFuZCBFLiBNYWxlciwg4oCcQXNzZXJ0aW9ucyBhbmQgUHJvdG9jb2wgZm9yIHRoZSBPQVNJUyBT ZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdlIChTQU1MKSBWMi4wLOKAnSBNYXJjaCAy MDA1LikgW09BU0lTLnNhbWzigJFjb3Jl4oCRMi4w4oCRb3NdIGFzc2VydGlvbikgZnJvbSBhbiBh c3NlcnRpb24gaXNzdWVyIG9yIHRvIHNlbGYtaXNzdWUgYW4gYXNzZXJ0aW9uLiBUaGUgYXNzZXJ0 aW9uIGZvcm1hdCwgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhlIGFzc2VydGlvbiBpcyBvYnRhaW5l ZCwgYW5kIHRoZSBtZXRob2Qgb2YgdmFsaWRhdGluZyB0aGUgYXNzZXJ0aW9uIGFyZSBkZWZpbmVk IGJ5IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGFu ZCBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNCldoZW4gdXNp bmcgYSBjbGllbnQgYXNzZXJ0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcg cGFyYW1ldGVyczoNCmNsaWVudF9hc3NlcnRpb25fdHlwZSAtIFJFUVVJUkVELiBUaGUgZm9ybWF0 IG9mIHRoZSBhc3NlcnRpb24gYXMgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu IFRoZSB2YWx1ZSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSS4NCmNsaWVudF9hc3NlcnRpb24gLSBS RVFVSVJFRC4gVGhlIGNsaWVudCBhc3NlcnRpb24uDQoNCkZvciBleGFtcGxlLCB0aGUgY2xpZW50 IHNlbmRzIHRoZSBmb2xsb3dpbmcgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXNpbmcgYSBTQU1MIDIu MCBhc3NlcnRpb24gdG8gYXV0aGVudGljYXRlIGl0c2VsZiAobGluZSBicmVha3MgYXJlIGZvciBk aXNwbGF5IHB1cnBvc2VzIG9ubHkpOg0KDQoNCg0KDQoNCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjEN Cg0KICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb208aHR0cDovL3NlcnZlci5leGFtcGxlLmNvbT4N Cg0KICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZA0KDQoN Cg0KICBncmFudF90eXBlPWF1dGhvcml6YXRpb25fY29kZSZjb2RlPWkxV3NSbjF1QjEmDQoNCiAg Y2xpZW50X2Fzc2VydGlvbj1QSE5oYld4d09sWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHkuLi5dWlQ0 JTNEJg0KDQogIGNsaWVudF9hc3NlcnRpb25fdHlwZT0gIHVybiUzQW9hc2lzJTNBbmFtZXMlc0F0 YyUzQVNBTUwlM0EyLjAlM0Fhc3NlcnRpb24mcmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xp ZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiDQoNCg0KDQoNCg0KDQpGcm9tOiBvYXV0aC1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2YgRXJhbiBIYW1tZXItTGFoYXYNClNlbnQ6IEZyaWRheSwgSmFudWFyeSAxNCwgMjAxMSAxMDo0 NSBQTQ0KVG86IE9BdXRoIFdHDQpTdWJqZWN0OiBbT0FVVEgtV0ddIFJlbW92YWw6IENsaWVudCBB c3NlcnRpb24gQ3JlZGVudGlhbHMNCg0KSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3Qgd2UgZHJvcCB0 aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyAoLTExIHNlY3Rpb24gMy4yKSBmcm9tIHRo ZSBzcGVjaWZpY2F0aW9uLCBhbmQgaWYgbmVlZGVkLCBwdWJsaXNoIGl0IGFzIGEgc2VwYXJhdGUg c3BlY2lmaWNhdGlvbiBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOg0KDQoNCjEuICAgICAgIFRo ZSBtZWNoYW5pc20gaXMgdW5kZXIgc3BlY2lmaWVkLCBlc3BlY2lhbGx5IGluIGl0cyBoYW5kbGlu ZyBvZiB0aGUgY2xpZW50X2lkIGlkZW50aWZpZXIgKHdoZW4gdXNlZCB0byBvYnRhaW4gZW5kLXVz ZXIgYXV0aG9yaXphdGlvbikuIEl0IGRvZXMgbm90IGNvbnRhaW4gYW55IGltcGxlbWVudGF0aW9u IGRldGFpbHMgdG8gYWNjb21wbGlzaCBhbnkgbGV2ZWwgb2YgaW50ZXJvcGVyYWJpbGl0eSBvciBm dW5jdGlvbmFsaXR5LiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvIHRoZSBhc3NlcnRpb24gZ3JhbnQg dHlwZSB3aGljaCBoYXMgbWF0dXJlZCBvdmVyIGEgeWVhciBpbnRvIGEgZnVsbHkgdGhvdWdodC1v dXQgZXh0ZW5zaW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBhIHNlcGFyYXRlIFNBTUwgYXNzZXJ0 aW9uIHNwZWNpZmljYXRpb24gd2l0aCBhY3RpdmUgZGVwbG95bWVudCAodGhlIHR3bywgdG9nZXRo ZXIgd2l0aCBydW5uaW5nIGNvZGUsIHNob3cgY2xlYXIgY29uc2Vuc3VzKS4NCg0KMi4gICAgICAg VGhlIHNlY3Rpb24gaXMgYSBjb25mdXNlZCBtaXggb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg c3ByaW5rbGVkIHdpdGggbm9ybWF0aXZlIGxhbmd1YWdlLiBJbnN0ZWFkLCBpdCBzaG91bGQgYmUg cmVwbGFjZWQgd2l0aCBndWlkZWxpbmVzIGZvciBleHRlbmRpbmcgdGhlIHNldCBvZiBzdXBwb3J0 ZWQgY2xpZW50IGNyZWRlbnRpYWxzLCBidXQgd2l0aG91dCBkZWZpbmluZyBhIG5ldyByZWdpc3Ry eS4gSXQgaXMgY2xlYXJseSBhbiBhcmVhIG9mIGxpdHRsZSBkZXBsb3ltZW50IGV4cGVyaWVuY2Ug Zm9yIE9BdXRoLCBhbmQgdGhhdCBpbmNsdWRlcyB1c2luZyBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0 aW9uIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gKG1vcmUgb24gdGhhdCB0byBjb21lKS4NCg0K My4gICAgICAgVGhlIHNlY3Rpb24gaGFzIHJlY2VpdmVkIGEgbGl0dGxlIHN1cHBvcnQgYW5kIGEg bGl0dGxlIG9iamVjdGlvbi4gVGhvc2Ugd2hvIHN0aWxsIHdhbnQgdG8gYWR2b2NhdGUgZm9yIGl0 IG5lZWQgdG8gc2hvdyBub3Qgb25seSBjb25zZW5zdXMgZm9yIGtlZXBpbmcgaXQsIGJ1dCBhbHNv IGFjdGl2ZSBjb21tdW5pdHkgc3VwcG9ydCBmb3IgZGVwbG95aW5nIGl0LiBEZXBsb3ltZW50LCBv ZiBjb3Vyc2UsIHdpbGwgYWxzbyByZXF1aXJlIHNob3dpbmcgcHJvZ3Jlc3Mgb24gcHVibGljIHNw ZWNpZmljYXRpb25zIHByb2ZpbGluZyB0aGUgbWVjaGFuaXNtIGludG8gYSB1c2VmdWwgaW50ZXJv cGVyYWJsZSBmZWF0dXJlLg0KDQpDb21tZW50cz8gQ291bnRlci1hcmd1bWVudHM/DQoNCkVITA0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo= --_000_180155C5EA10854997314CA5E063D18F033A7757TK5EX14MBXC111r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRD aGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglm b250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+QmFzZWQgb24geW91ciBsb2dpYyB0aGVuIFNjb3BlLCBDbGllbnQg UGFzc3dvcmQgQXV0aGVudGljYXRpb24sIGV0Yywgc2hvdWxkIGJlIHJlbW92ZWQuIE5vdCBzdXJl IGhvdyBsZWF2aW5nIHRoZSBwcm9wb3NlZCB0ZXh0IGluIHdvdWxkIGRlbGF5IHRoaW5nczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRGF2aWQgUmVjb3Jkb24gW21h aWx0bzpyZWNvcmRvbmRAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEph bnVhcnkgMjUsIDIwMTEgNToxMSBQTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluOyBI YW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0OyBFcmFuIEhhbW1lci1MYWhhdjxicj4NCjxiPkNjOjwv Yj4gT0F1dGggV0c7IEJsYWluZSBDb29rPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgt V0ddIFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkV4cGxpY2l0bHkgc2F5aW5nLCAmcXVvdDs8c3BhbiBjbGFzcz0iYXBw bGUtc3R5bGUtc3BhbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIGFzc2VydGlvbiBm b3JtYXQsIHRoZSBwcm9jZXNzIGJ5IHdoaWNoIHRoZSBhc3NlcnRpb24gaXMgb2J0YWluZWQsIGFu ZCB0aGUgbWV0aG9kIG9mIHZhbGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmUgZGVmaW5lZA0KIGJ5 IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGFuZCBh cmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24mcXVvdDsgc2VlbXMgdG8g cmVpbmZvcmNlIHRoZSBwb2ludCBhYm91dCB0aGlzIGJlaW5nIHVuZGVyc3BlY2lmaWVkLiBUaGlz IHdvdWxkIHN0aWxsIHJlcXVpcmUgYSBzZWNvbmQgZG9jdW1lbnQgd2hpY2ggZGVzY3JpYmVzIHRo ZSBkYXRhIHdpdGhpbiB0aGUgU0FNTCBhc3NlcnRpb24NCiBhcyB3ZWxsIGFzIGhvdyBpdCBtYXBz IGJhY2sgdG8gYSBjbGllbnRfaWQuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+T24gdGhlIHByb2Nlc3Mgc2lkZSwgSUlSQyB0aGlzIHdhcyBhZGRlZCB0byB0aGUg c3BlYyB3aXRob3V0IGFueSBjb25zZW5zdXMgYW5kIG92ZXIgc29tZSByZXNlcnZhdGlvbnMgYnkg RXJhbi4uLndoaWNoIHdhcyBhIGJyb2tlbiBwcm9jZXNzIHRvIGJlZ2luIHdpdGggYW5kIGENCiBw b29yIGRlY2lzaW9uIG9uIGhpcyBwYXJ0LiBJIHNoYXJlIEhhbm5lcycgZGVzaXJlIHRvIG1vdmUg dGhpcyBiYXNlIHNwZWMgdG8gbGFzdCBjYWxsLiBXb3JyaWVkIHRoYXQgbGVhdmluZyB0aGlzIHRl eHQgaW4gaXMgZ29pbmcgdG8gZGVsYXkgdGhhdCB3aGVyZWFzIG1vdmluZyBpdCB0byBhIHNlcGFy YXRlIGRvY3VtZW50IHB1Ymxpc2hlZCBieSB0aGUgT0F1dGggV0cgd2lsbCBzdGlsbCBsZWFkIHRv d2FyZCBtYXJrZXQgYWRvcHRpb24gb2YgYSBtb3JlDQogZnVsbHkgc3BlY2lmaWVkIGZlYXR1cmUu PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLURh dmlkPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBKYW4gMjUsIDIwMTEg YXQgMzo1OCBQTSwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBt aWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHA+SSBkb24ndCB1bmRlcnN0YW5kIHRoZSByYXRpb25h bGUgZm9yIHJlbW92aW5nIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzLCBhcyBjbGll bnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gaXMgbGVmdCBpbi4gQ2xpZW50IFBhc3N3b3JkIEF1 dGhlbnRpY2F0aW9uIGlzIGFsc28gdW5kZXJzcGVjaWZpZWQgYXMgY2xpZW50X3NlY3JldCBjb3Vs ZCBiZSBhbnl0aGluZyB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgc2VlbXMgZml0DQog KHJhdyBjbGVhciB0ZXh0IHBhc3N3b3JkLCZuYnNwOyBoYXNoLCBkaWdlc3QsIGV0Yy4pIGFuZCBu byB3YXkgdG8gZGV0ZXJtaW5lIHRoZSBjb250ZW50LiBjbGllbnRfc2VjcmV0IGlzIGFsc28gYSB2 ZXJ5IHdlYWsgbWVjaGFuaXNtLCBzaW5jZSB0aGlzIGlzIGxlZnQgaW4gdGhlIGNvcmUgdGhpcyBs ZWFkcyBtZSB0byBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgc3VwcG9ydCBmb3IgaGF2aW5nIGNsaWVu dCBhdXRoZW50aWNhdGlvbiBpbiBPYXV0aC4gSSBkb24ndA0KIHNlZSBob3cgaGF2aW5nIGNsaWVu dF9hc3NlcnRpb24gYW5kIGNsaWVudF9hc3NlcnRpb25fdHlwZSB3b3VsZCBiZSBzb21ldGhpbmcg dGhhdCBpcyB1bmRlcnNwZWNpZmllZCBhcyBiZWluZyBhIG1lY2hhbmlzbSBpbiB3aGljaCBhc3Nl cnRpb25zIGNhbiBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbi4gQWdyZWUgdGhhdCB0aGUgYXV0 aGVudGljYXRpb24gc2VydmVyIGhhcyB0byBtYWtlIHJpZ2h0IGFuZCBkZWNsYXJlIHdoYXQgaXMg YmVpbmcgdXNlZA0KIGJ1dCB0aGF0IGlzIHRoZSBzYW1lIGZvciBjbGllbnQgcGFzc3dvcmQgYXV0 aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gYXNzZXJ0aW9ucyBhcmUgc29t ZXRoaW5nIHRoYXQgTWljcm9zb2Z0IGFuZCBHb29nbGUgZmluZCB1c2VmdWwgYW5kIHBsYW4gb24g aW1wbGVtZW50aW5nIGFuZCB1c2luZyBhcyBhIG1lYW5zIGZvciBzdHJvbmdlciBhdXRoZW50aWNh dGlvbiB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoaXMgZXh0ZW5zaWJpbGl0eQ0KIGJl bG9uZ3MgaW4gdGhlIGNvcmUsIHRoZXJlIGlzIG5vIG90aGVyIHBsYWNlIHRvIHB1dCB0aGlzIGZ1 bmN0aW9uYWxpdHkuIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoZSByZW1vdmFsIChlaXRoZXIgYnkg ZWRpdG9yIG9yIGRpcmVjdGlvbiBieSBjby1jaGFpcikgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxk IGhhdmUgYmVlbiBkb25lIHcvbyBhIGNvbnNlbnN1cyB2b3RlIHNpbmNlIHRoaXMgaGFzIGJlZW4g aW4gdGhlIHNwZWNpZmljYXRpb24gZm9yIHNvbWUNCiB0aW1lIHdpdGhvdXQgaXNzdWUgYW5kIHRo ZSByZW1vdmFsIGNvbWVzIGFzIGNvbXBsZXRlIHVud2VsY29tZSBzdXJwcmlzZS4gR2V0dGluZyBh bG1vc3QgdG90YWwgcmV3cml0ZXMgb2YgdGhlIHNwZWNpZmljYXRpb24gdGhpcyBsYXRlIGluIHRo ZSByZXZpZXcgY3ljbGUgaXMgYWxzbyB2ZXJ5IGRpc3R1cmJpbmcuPG86cD48L286cD48L3A+DQo8 cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkEgcHJvcG9zYWwgZm9yIGtlZXBpbmcgdGhlIGNs aWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gd291bGQgYmUgdG8gc2ltcGxpZnkgdG8gdGhl IGZvbGxvd2luZzs8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iY29s b3I6YmxhY2siPlRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGFyZSB1c2VkIGluIGNh c2VzIHdoZXJlIGEgcGFzc3dvcmQgKGNsZWFyLXRleHQgc2hhcmVkIHN5bW1ldHJpYyBzZWNyZXQp IGlzIHVuc3VpdGFibGUgb3IgZG9lcyBub3QgcHJvdmlkZSBzdWZmaWNpZW50IHNlY3VyaXR5IGZv ciBjbGllbnQgYXV0aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxz DQogcHJvdmlkZSBhbiBleHRlbnNpYmxlIG1lY2hhbmlzbSB0byB1c2UgYW4gYXNzZXJ0aW9uIGZv cm1hdCBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGZvciBhdXRoZW50aWNh dGlvbiBvZiB0aGUgY2xpZW50Lg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJjb2xvcjpibGFjayI+VXNpbmcgYXNzZXJ0aW9ucyByZXF1aXJlcyB0aGUg Y2xpZW50IHRvIG9idGFpbiBhbiBhc3NlcnRpb24gKHN1Y2ggYXMgYQ0KPC9zcGFuPjxhIGhyZWY9 IiMxMmRiZjlkMjlhMmVlN2NkX09BU0lTLnNhbWwtY29yZS0yLjAtb3MiPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0idGV4dC1kZWNvcmF0aW9uOm5vbmUiPlNBTUwgKENhbnRvciwgUy4sIEtlbXAsIEou LCBQaGlscG90dCwgUi4sIGFuZCBFLiBNYWxlciwg4oCcQXNzZXJ0aW9ucyBhbmQgUHJvdG9jb2wg Zm9yIHRoZSBPQVNJUyBTZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdlIChTQU1MKSBW Mi4wLOKAnSBNYXJjaCZuYnNwOzIwMDUuKTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJjb2xvcjpibGFjayI+DQogW09BU0lTLnNhbWzigJFjb3Jl4oCRMi4w4oCRb3NdIGFzc2VydGlv bikgZnJvbSBhbiBhc3NlcnRpb24gaXNzdWVyIG9yIHRvIHNlbGYtaXNzdWUgYW4gYXNzZXJ0aW9u LiBUaGUgYXNzZXJ0aW9uIGZvcm1hdCwgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhlIGFzc2VydGlv biBpcyBvYnRhaW5lZCwgYW5kIHRoZSBtZXRob2Qgb2YgdmFsaWRhdGluZyB0aGUgYXNzZXJ0aW9u IGFyZSBkZWZpbmVkIGJ5IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlv bg0KIHNlcnZlciwgYW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlv bi4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJjb2xv cjpibGFjayI+V2hlbiB1c2luZyBhIGNsaWVudCBhc3NlcnRpb24sIHRoZSBjbGllbnQgaW5jbHVk ZXMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1y aWdodDo2MC4wcHQ7bWFyZ2luLWxlZnQ6NjAuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Y29sb3I6YmxhY2siPmNsaWVudF9hc3NlcnRpb25fdHlwZSAtIFJFUVVJUkVELiBUaGUgZm9ybWF0 IG9mIHRoZSBhc3NlcnRpb24gYXMgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu IFRoZSB2YWx1ZSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoyNC4wcHQ7dGV4dC1pbmRlbnQ6 LjVpbiI+DQo8c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5jbGllbnRfYXNzZXJ0 aW9uIC0gUkVRVUlSRUQuIFRoZSBjbGllbnQgYXNzZXJ0aW9uLg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJjb2xvcjpibGFjayI+Rm9yIGV4YW1wbGUs IHRoZSBjbGllbnQgc2VuZHMgdGhlIGZvbGxvd2luZyBhY2Nlc3MgdG9rZW4gcmVxdWVzdCB1c2lu ZyBhIFNBTUwgMi4wIGFzc2VydGlvbiB0byBhdXRoZW50aWNhdGUgaXRzZWxmIChsaW5lIGJyZWFr cyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDoyNC4wcHQ7 bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6NjAuMHB0O21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1i b3R0b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IGxhbmc9IkVOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRU4iPiZuYnNwOyBQT1NUIC90b2tlbiBIVFRQLzEuMTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MjQuMHB0 O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsgSG9zdDogPGEgaHJlZj0iaHR0cDovL3NlcnZlci5l eGFtcGxlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNlcnZlci5leGFtcGxlLmNvbTwvYT48L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyBDb250ZW50LVR5 cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsgZ3JhbnRfdHlwZT1hdXRob3JpemF0aW9uX2Nv ZGUmYW1wO2NvZGU9aTFXc1JuMXVCMSZhbXA7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsgY2xpZW50X2Fzc2VydGlvbj1QSE5oYld4d09sWy4uLm9t aXR0ZWQgZm9yIGJyZXZpdHkuLi5dWlQ0JTNEJmFtcDs8L3NwYW4+PG86cD48L286cD48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyBjbGllbnRfYXNzZXJ0aW9uX3R5cGU9ICZuYnNw O3VybiUzQW9hc2lzJTNBbmFtZXMlc0F0YyUzQVNBTUwlM0EyLjAlM0Fhc3NlcnRpb24mYW1wO3Jl ZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYjwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjtt YXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+DQo8 YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9h Pl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RXJhbiBIYW1tZXItTGFoYXY8YnI+DQo8Yj5TZW50Ojwv Yj4gRnJpZGF5LCBKYW51YXJ5IDE0LCAyMDExIDEwOjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBPQXV0 aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIFJlbW92YWw6IENsaWVudCBBc3Nl cnRpb24gQ3JlZGVudGlhbHM8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB3ZSBkcm9w IHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzICgtMTEgc2VjdGlvbiAzLjIpIGZyb20g dGhlIHNwZWNpZmljYXRpb24sIGFuZCBpZiBuZWVkZWQsIHB1Ymxpc2ggaXQgYXMgYSBzZXBhcmF0 ZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgZm9sbG93aW5nDQogcmVhc29uczo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4xLjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+VGhlIG1lY2hhbmlzbSBpcyB1bmRlciBzcGVjaWZpZWQsIGVzcGVjaWFs bHkgaW4gaXRzIGhhbmRsaW5nIG9mIHRoZSBjbGllbnRfaWQgaWRlbnRpZmllciAod2hlbiB1c2Vk IHRvIG9idGFpbiBlbmQtdXNlciBhdXRob3JpemF0aW9uKS4gSXQgZG9lcyBub3QgY29udGFpbiBh bnkgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byBhY2NvbXBsaXNoIGFueSBsZXZlbCBvZg0KIGlu dGVyb3BlcmFiaWxpdHkgb3IgZnVuY3Rpb25hbGl0eS4gVGhpcyBpcyBpbiBjb250cmFzdCB0byB0 aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUgd2hpY2ggaGFzIG1hdHVyZWQgb3ZlciBhIHllYXIgaW50 byBhIGZ1bGx5IHRob3VnaHQtb3V0IGV4dGVuc2lvbiBtZWNoYW5pc20sIGFzIHdlbGwgYXMgYSBz ZXBhcmF0ZSBTQU1MIGFzc2VydGlvbiBzcGVjaWZpY2F0aW9uIHdpdGggYWN0aXZlIGRlcGxveW1l bnQgKHRoZSB0d28sIHRvZ2V0aGVyIHdpdGgNCiBydW5uaW5nIGNvZGUsIHNob3cgY2xlYXIgY29u c2Vuc3VzKS48bzpwPjwvbzpwPjwvcD4NCjxwPjIuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5UaGUgc2VjdGlv biBpcyBhIGNvbmZ1c2VkIG1peCBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzcHJpbmtsZWQg d2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UuIEluc3RlYWQsIGl0IHNob3VsZCBiZSByZXBsYWNlZCB3 aXRoIGd1aWRlbGluZXMgZm9yIGV4dGVuZGluZyB0aGUgc2V0IG9mIHN1cHBvcnRlZCBjbGllbnQg Y3JlZGVudGlhbHMsIGJ1dCB3aXRob3V0IGRlZmluaW5nDQogYSBuZXcgcmVnaXN0cnkuIEl0IGlz IGNsZWFybHkgYW4gYXJlYSBvZiBsaXR0bGUgZGVwbG95bWVudCBleHBlcmllbmNlIGZvciBPQXV0 aCwgYW5kIHRoYXQgaW5jbHVkZXMgdXNpbmcgSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiBmb3Ig Y2xpZW50IGF1dGhlbnRpY2F0aW9uIChtb3JlIG9uIHRoYXQgdG8gY29tZSkuPG86cD48L286cD48 L3A+DQo8cD4zLjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+VGhlIHNlY3Rpb24gaGFzIHJlY2VpdmVkIGEgbGl0 dGxlIHN1cHBvcnQgYW5kIGEgbGl0dGxlIG9iamVjdGlvbi4gVGhvc2Ugd2hvIHN0aWxsIHdhbnQg dG8gYWR2b2NhdGUgZm9yIGl0IG5lZWQgdG8gc2hvdyBub3Qgb25seSBjb25zZW5zdXMgZm9yIGtl ZXBpbmcgaXQsIGJ1dCBhbHNvIGFjdGl2ZSBjb21tdW5pdHkgc3VwcG9ydCBmb3IgZGVwbG95aW5n IGl0LiBEZXBsb3ltZW50LA0KIG9mIGNvdXJzZSwgd2lsbCBhbHNvIHJlcXVpcmUgc2hvd2luZyBw cm9ncmVzcyBvbiBwdWJsaWMgc3BlY2lmaWNhdGlvbnMgcHJvZmlsaW5nIHRoZSBtZWNoYW5pc20g aW50byBhIHVzZWZ1bCBpbnRlcm9wZXJhYmxlIGZlYXR1cmUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Db21tZW50cz8gQ291bnRlci1hcmd1bWVudHM/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5FSEw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_180155C5EA10854997314CA5E063D18F033A7757TK5EX14MBXC111r_-- From eran@hueniverse.com Tue Jan 25 17:34:57 2011 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 332B03A68FD for ; Tue, 25 Jan 2011 17:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 mJCWpOBY6zeo for ; Tue, 25 Jan 2011 17:34:55 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 873D53A68AC for ; Tue, 25 Jan 2011 17:34:55 -0800 (PST) Received: (qmail 6563 invoked from network); 26 Jan 2011 01:37:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 01:37:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 25 Jan 2011 18:37:49 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin Date: Tue, 25 Jan 2011 18:37:31 -0700 Thread-Topic: Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQIaL9MwAAPpZeA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6250D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> In-Reply-To: <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6250DP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 26 Jan 2011 01:34:57 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6250DP3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIHlvdSBzaGFyZSB3aXRoIHRoZSBsaXN0IGhvdyB5b3UgcGxhbiB0byB1c2UgdGhpcyBjbGll bnQgYXNzZXJ0aW9uIGF1dGhlbnRpY2F0aW9uIHNjaGVtZT8NCldoaWNoIG9mIHRoZSBhdXRob3Jp emF0aW9uIGdyYW50IHR5cGVzIHlvdSB3aWxsIHVzZSBpdCB3aXRoPw0KV2lsbCB5b3UgdXNlIGl0 IHdpdGggdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIGFuZCBpZiBzbywgaG93IHdpbGwgeW91 IGJpbmQgdGhlIGFzc2VydGlvbiB0byB0aGUgY2xpZW50X2lkPw0KQ2FuIHlvdSBwcm92aWRlIGZ1 bGwgZXhhbXBsZXMgb2YgYXNzZXJ0aW9ucyBhbmQgSFRUUCByZXF1ZXN0cz8NCg0KSXQgd291bGQg YmUgaGVscGZ1bCB0byBzZWUgaG93IGZhciBhcGFydCB0aGUgcHJvcG9zZWQgdGV4dCBiZWxvdyBp cyBmcm9tIGFuIGFjdHVhbCBpbXBsZW1lbnRhdGlvbiBtYWtpbmcgdXNlIG9mIGl0LiBJIGV4Y2Vw dCB0byBzZWUgdGhlc2UgYW5zd2VycyBpbiBhbnkgcXVhbGl0eSBkb2N1bWVudCBkZWZpbmluZyBh IG5ldyBjbGllbnQgYXV0aGVudGljYXRpb24gc2NoZW1lICh3aGljaCBpcyB0cnVlIGZvciB0aGUg Y2xpZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50KS4N Cg0KRUhMDQoNCg0KRnJvbTogQW50aG9ueSBOYWRhbGluIFttYWlsdG86dG9ueW5hZEBtaWNyb3Nv ZnQuY29tXQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNSwgMjAxMSAzOjU4IFBNDQpUbzogRXJh biBIYW1tZXItTGFoYXY7IE9BdXRoIFdHOyBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0OyBCbGFp bmUgQ29vaw0KU3ViamVjdDogUkU6IFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlh bHMNCg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBmb3IgcmVtb3ZpbmcgdGhl IGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMsIGFzIGNsaWVudCBwYXNzd29yZCBhdXRoZW50 aWNhdGlvbiBpcyBsZWZ0IGluLiBDbGllbnQgUGFzc3dvcmQgQXV0aGVudGljYXRpb24gaXMgYWxz byB1bmRlcnNwZWNpZmllZCBhcyBjbGllbnRfc2VjcmV0IGNvdWxkIGJlIGFueXRoaW5nIHRoYXQg dGhlIGF1dGhlbnRpY2F0aW9uIHNlcnZlciBzZWVtcyBmaXQgKHJhdyBjbGVhciB0ZXh0IHBhc3N3 b3JkLCAgaGFzaCwgZGlnZXN0LCBldGMuKSBhbmQgbm8gd2F5IHRvIGRldGVybWluZSB0aGUgY29u dGVudC4gY2xpZW50X3NlY3JldCBpcyBhbHNvIGEgdmVyeSB3ZWFrIG1lY2hhbmlzbSwgc2luY2Ug dGhpcyBpcyBsZWZ0IGluIHRoZSBjb3JlIHRoaXMgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0IHRo ZXJlIGlzIHN1cHBvcnQgZm9yIGhhdmluZyBjbGllbnQgYXV0aGVudGljYXRpb24gaW4gT2F1dGgu IEkgZG9uJ3Qgc2VlIGhvdyBoYXZpbmcgY2xpZW50X2Fzc2VydGlvbiBhbmQgY2xpZW50X2Fzc2Vy dGlvbl90eXBlIHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGlzIHVuZGVyc3BlY2lmaWVkIGFzIGJl aW5nIGEgbWVjaGFuaXNtIGluIHdoaWNoIGFzc2VydGlvbnMgY2FuIGJlIHVzZWQgZm9yIGF1dGhl bnRpY2F0aW9uLiBBZ3JlZSB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgaGFzIHRvIG1h a2UgcmlnaHQgYW5kIGRlY2xhcmUgd2hhdCBpcyBiZWluZyB1c2VkIGJ1dCB0aGF0IGlzIHRoZSBz YW1lIGZvciBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXV0aGVu dGljYXRpb24gYXNzZXJ0aW9ucyBhcmUgc29tZXRoaW5nIHRoYXQgTWljcm9zb2Z0IGFuZCBHb29n bGUgZmluZCB1c2VmdWwgYW5kIHBsYW4gb24gaW1wbGVtZW50aW5nIGFuZCB1c2luZyBhcyBhIG1l YW5zIGZvciBzdHJvbmdlciBhdXRoZW50aWNhdGlvbiB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2 ZXIuIFRoaXMgZXh0ZW5zaWJpbGl0eSBiZWxvbmdzIGluIHRoZSBjb3JlLCB0aGVyZSBpcyBubyBv dGhlciBwbGFjZSB0byBwdXQgdGhpcyBmdW5jdGlvbmFsaXR5LiBJIGRvbid0IGJlbGlldmUgdGhh dCB0aGUgcmVtb3ZhbCAoZWl0aGVyIGJ5IGVkaXRvciBvciBkaXJlY3Rpb24gYnkgY28tY2hhaXIp IGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBoYXZlIGJlZW4gZG9uZSB3L28gYSBjb25zZW5zdXMg dm90ZSBzaW5jZSB0aGlzIGhhcyBiZWVuIGluIHRoZSBzcGVjaWZpY2F0aW9uIGZvciBzb21lIHRp bWUgd2l0aG91dCBpc3N1ZSBhbmQgdGhlIHJlbW92YWwgY29tZXMgYXMgY29tcGxldGUgdW53ZWxj b21lIHN1cnByaXNlLiBHZXR0aW5nIGFsbW9zdCB0b3RhbCByZXdyaXRlcyBvZiB0aGUgc3BlY2lm aWNhdGlvbiB0aGlzIGxhdGUgaW4gdGhlIHJldmlldyBjeWNsZSBpcyBhbHNvIHZlcnkgZGlzdHVy YmluZy4NCg0KDQoNCkEgcHJvcG9zYWwgZm9yIGtlZXBpbmcgdGhlIGNsaWVudCBhdXRoZW50aWNh dGlvbiBhc3NlcnRpb24gd291bGQgYmUgdG8gc2ltcGxpZnkgdG8gdGhlIGZvbGxvd2luZzsNCg0K VGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYXJlIHVzZWQgaW4gY2FzZXMgd2hlcmUg YSBwYXNzd29yZCAoY2xlYXItdGV4dCBzaGFyZWQgc3ltbWV0cmljIHNlY3JldCkgaXMgdW5zdWl0 YWJsZSBvciBkb2VzIG5vdCBwcm92aWRlIHN1ZmZpY2llbnQgc2VjdXJpdHkgZm9yIGNsaWVudCBh dXRoZW50aWNhdGlvbi4gVGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgcHJvdmlkZSBh biBleHRlbnNpYmxlIG1lY2hhbmlzbSB0byB1c2UgYW4gYXNzZXJ0aW9uIGZvcm1hdCBzdXBwb3J0 ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGZvciBhdXRoZW50aWNhdGlvbiBvZiB0aGUg Y2xpZW50Lg0KDQpVc2luZyBhc3NlcnRpb25zIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8gb2J0YWlu IGFuIGFzc2VydGlvbiAoc3VjaCBhcyBhIFNBTUwgKENhbnRvciwgUy4sIEtlbXAsIEouLCBQaGls cG90dCwgUi4sIGFuZCBFLiBNYWxlciwg4oCcQXNzZXJ0aW9ucyBhbmQgUHJvdG9jb2wgZm9yIHRo ZSBPQVNJUyBTZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdlIChTQU1MKSBWMi4wLOKA nSBNYXJjaCAyMDA1LikgW09BU0lTLnNhbWzigJFjb3Jl4oCRMi4w4oCRb3NdIGFzc2VydGlvbikg ZnJvbSBhbiBhc3NlcnRpb24gaXNzdWVyIG9yIHRvIHNlbGYtaXNzdWUgYW4gYXNzZXJ0aW9uLiBU aGUgYXNzZXJ0aW9uIGZvcm1hdCwgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhlIGFzc2VydGlvbiBp cyBvYnRhaW5lZCwgYW5kIHRoZSBtZXRob2Qgb2YgdmFsaWRhdGluZyB0aGUgYXNzZXJ0aW9uIGFy ZSBkZWZpbmVkIGJ5IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIsIGFuZCBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoN CldoZW4gdXNpbmcgYSBjbGllbnQgYXNzZXJ0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIHRoZSBm b2xsb3dpbmcgcGFyYW1ldGVyczoNCmNsaWVudF9hc3NlcnRpb25fdHlwZSAtIFJFUVVJUkVELiBU aGUgZm9ybWF0IG9mIHRoZSBhc3NlcnRpb24gYXMgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIuIFRoZSB2YWx1ZSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSS4NCmNsaWVudF9hc3Nl cnRpb24gLSBSRVFVSVJFRC4gVGhlIGNsaWVudCBhc3NlcnRpb24uDQoNCkZvciBleGFtcGxlLCB0 aGUgY2xpZW50IHNlbmRzIHRoZSBmb2xsb3dpbmcgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXNpbmcg YSBTQU1MIDIuMCBhc3NlcnRpb24gdG8gYXV0aGVudGljYXRlIGl0c2VsZiAobGluZSBicmVha3Mg YXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOg0KDQoNCg0KDQoNCiAgUE9TVCAvdG9rZW4g SFRUUC8xLjENCg0KICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20NCg0KICBDb250ZW50LVR5cGU6 IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZA0KDQoNCg0KICBncmFudF90eXBlPWF1 dGhvcml6YXRpb25fY29kZSZjb2RlPWkxV3NSbjF1QjEmDQoNCiAgY2xpZW50X2Fzc2VydGlvbj1Q SE5oYld4d09sWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHkuLi5dWlQ0JTNEJg0KDQogIGNsaWVudF9h c3NlcnRpb25fdHlwZT0gIHVybiUzQW9hc2lzJTNBbmFtZXMlc0F0YyUzQVNBTUwlM0EyLjAlM0Fh c3NlcnRpb24mcmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNv bSUyRmNiDQoNCg0KDQoNCg0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyYW4gSGFtbWVyLUxhaGF2DQpT ZW50OiBGcmlkYXksIEphbnVhcnkgMTQsIDIwMTEgMTA6NDUgUE0NClRvOiBPQXV0aCBXRw0KU3Vi amVjdDogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoN Ckkgd291bGQgbGlrZSB0byBzdWdnZXN0IHdlIGRyb3AgdGhlIGNsaWVudCBhc3NlcnRpb24gY3Jl ZGVudGlhbHMgKC0xMSBzZWN0aW9uIDMuMikgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbiwgYW5kIGlm IG5lZWRlZCwgcHVibGlzaCBpdCBhcyBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBm b2xsb3dpbmcgcmVhc29uczoNCg0KDQoxLiAgICAgICBUaGUgbWVjaGFuaXNtIGlzIHVuZGVyIHNw ZWNpZmllZCwgZXNwZWNpYWxseSBpbiBpdHMgaGFuZGxpbmcgb2YgdGhlIGNsaWVudF9pZCBpZGVu dGlmaWVyICh3aGVuIHVzZWQgdG8gb2J0YWluIGVuZC11c2VyIGF1dGhvcml6YXRpb24pLiBJdCBk b2VzIG5vdCBjb250YWluIGFueSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRvIGFjY29tcGxpc2gg YW55IGxldmVsIG9mIGludGVyb3BlcmFiaWxpdHkgb3IgZnVuY3Rpb25hbGl0eS4gVGhpcyBpcyBp biBjb250cmFzdCB0byB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUgd2hpY2ggaGFzIG1hdHVyZWQg b3ZlciBhIHllYXIgaW50byBhIGZ1bGx5IHRob3VnaHQtb3V0IGV4dGVuc2lvbiBtZWNoYW5pc20s IGFzIHdlbGwgYXMgYSBzZXBhcmF0ZSBTQU1MIGFzc2VydGlvbiBzcGVjaWZpY2F0aW9uIHdpdGgg YWN0aXZlIGRlcGxveW1lbnQgKHRoZSB0d28sIHRvZ2V0aGVyIHdpdGggcnVubmluZyBjb2RlLCBz aG93IGNsZWFyIGNvbnNlbnN1cykuDQoNCjIuICAgICAgIFRoZSBzZWN0aW9uIGlzIGEgY29uZnVz ZWQgbWl4IG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNwcmlua2xlZCB3aXRoIG5vcm1hdGl2 ZSBsYW5ndWFnZS4gSW5zdGVhZCwgaXQgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggZ3VpZGVsaW5l cyBmb3IgZXh0ZW5kaW5nIHRoZSBzZXQgb2Ygc3VwcG9ydGVkIGNsaWVudCBjcmVkZW50aWFscywg YnV0IHdpdGhvdXQgZGVmaW5pbmcgYSBuZXcgcmVnaXN0cnkuIEl0IGlzIGNsZWFybHkgYW4gYXJl YSBvZiBsaXR0bGUgZGVwbG95bWVudCBleHBlcmllbmNlIGZvciBPQXV0aCwgYW5kIHRoYXQgaW5j bHVkZXMgdXNpbmcgSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiBmb3IgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIChtb3JlIG9uIHRoYXQgdG8gY29tZSkuDQoNCjMuICAgICAgIFRoZSBzZWN0aW9uIGhh cyByZWNlaXZlZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3Nl IHdobyBzdGlsbCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkg Y29uc2Vuc3VzIGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBv cnQgZm9yIGRlcGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsIGFsc28gcmVx dWlyZSBzaG93aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9maWxpbmcg dGhlIG1lY2hhbmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS4NCg0KQ29t bWVudHM/IENvdW50ZXItYXJndW1lbnRzPw0KDQpFSEwNCg0KDQo= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6250DP3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFp blRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MjQuMHB0Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjI0LjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJYmFja2dyb3VuZDojQ0NDQ0NDOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt YXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCgliYWNrZ3JvdW5kOiNDQ0NDQ0M7fQ0Kc3Bhbi5QbGFpblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTExMzc4NjUwMDsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMyMTg2OTg4 OCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxh bmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkNhbiB5b3Ugc2hh cmUgd2l0aCB0aGUgbGlzdCBob3cgeW91IHBsYW4gdG8gdXNlIHRoaXMgY2xpZW50IGFzc2VydGlv biBhdXRoZW50aWNhdGlvbiBzY2hlbWU/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2hpY2ggb2YgdGhlIGF1dGhvcml6 YXRpb24gZ3JhbnQgdHlwZXMgeW91IHdpbGwgdXNlIGl0IHdpdGg/PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2lsbCB5 b3UgdXNlIGl0IHdpdGggdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIGFuZCBpZiBzbywgaG93 IHdpbGwgeW91IGJpbmQgdGhlIGFzc2VydGlvbiB0byB0aGUgY2xpZW50X2lkPzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PkNhbiB5b3UgcHJvdmlkZSBmdWxsIGV4YW1wbGVzIG9mIGFzc2VydGlvbnMgYW5kIEhUVFAgcmVx dWVzdHM/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+SXQgd291bGQgYmUgaGVscGZ1bCB0 byBzZWUgaG93IGZhciBhcGFydCB0aGUgcHJvcG9zZWQgdGV4dCBiZWxvdyBpcyBmcm9tIGFuIGFj dHVhbCBpbXBsZW1lbnRhdGlvbiBtYWtpbmcgdXNlIG9mIGl0LiBJIGV4Y2VwdCB0byBzZWUgdGhl c2UgYW5zd2VycyBpbiBhbnkgcXVhbGl0eSBkb2N1bWVudCBkZWZpbmluZyBhIG5ldyBjbGllbnQg YXV0aGVudGljYXRpb24gc2NoZW1lICh3aGljaCBpcyB0cnVlIGZvciB0aGUgY2xpZW50IHBhc3N3 b3JkIGF1dGhlbnRpY2F0aW9uIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50KS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz5FSEw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz4gQW50aG9ueSBOYWRhbGluIFttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQu Y29tXSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgMzo1OCBQTTxi cj48Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRzsgSGFubmVzLlRzY2hvZmVu aWdAZ214Lm5ldDsgQmxhaW5lIENvb2s8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBSZW1vdmFsOiBD bGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Q bGFpblRleHQ+SSBkb24ndCB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9yIHJlbW92aW5nIHRo ZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzLCBhcyBjbGllbnQgcGFzc3dvcmQgYXV0aGVu dGljYXRpb24gaXMgbGVmdCBpbi4gQ2xpZW50IFBhc3N3b3JkIEF1dGhlbnRpY2F0aW9uIGlzIGFs c28gdW5kZXJzcGVjaWZpZWQgYXMgY2xpZW50X3NlY3JldCBjb3VsZCBiZSBhbnl0aGluZyB0aGF0 IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgc2VlbXMgZml0IChyYXcgY2xlYXIgdGV4dCBwYXNz d29yZCwmbmJzcDsgaGFzaCwgZGlnZXN0LCBldGMuKSBhbmQgbm8gd2F5IHRvIGRldGVybWluZSB0 aGUgY29udGVudC4gY2xpZW50X3NlY3JldCBpcyBhbHNvIGEgdmVyeSB3ZWFrIG1lY2hhbmlzbSwg c2luY2UgdGhpcyBpcyBsZWZ0IGluIHRoZSBjb3JlIHRoaXMgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0 aGF0IHRoZXJlIGlzIHN1cHBvcnQgZm9yIGhhdmluZyBjbGllbnQgYXV0aGVudGljYXRpb24gaW4g T2F1dGguIEkgZG9uJ3Qgc2VlIGhvdyBoYXZpbmcgY2xpZW50X2Fzc2VydGlvbiBhbmQgY2xpZW50 X2Fzc2VydGlvbl90eXBlIHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGlzIHVuZGVyc3BlY2lmaWVk IGFzIGJlaW5nIGEgbWVjaGFuaXNtIGluIHdoaWNoIGFzc2VydGlvbnMgY2FuIGJlIHVzZWQgZm9y IGF1dGhlbnRpY2F0aW9uLiBBZ3JlZSB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgaGFz IHRvIG1ha2UgcmlnaHQgYW5kIGRlY2xhcmUgd2hhdCBpcyBiZWluZyB1c2VkIGJ1dCB0aGF0IGlz IHRoZSBzYW1lIGZvciBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24uIFRoZSBjbGllbnQg YXV0aGVudGljYXRpb24gYXNzZXJ0aW9ucyBhcmUgc29tZXRoaW5nIHRoYXQgTWljcm9zb2Z0IGFu ZCBHb29nbGUgZmluZCB1c2VmdWwgYW5kIHBsYW4gb24gaW1wbGVtZW50aW5nIGFuZCB1c2luZyBh cyBhIG1lYW5zIGZvciBzdHJvbmdlciBhdXRoZW50aWNhdGlvbiB0byB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIuIFRoaXMgZXh0ZW5zaWJpbGl0eSBiZWxvbmdzIGluIHRoZSBjb3JlLCB0aGVyZSBp cyBubyBvdGhlciBwbGFjZSB0byBwdXQgdGhpcyBmdW5jdGlvbmFsaXR5LiBJIGRvbid0IGJlbGll dmUgdGhhdCB0aGUgcmVtb3ZhbCAoZWl0aGVyIGJ5IGVkaXRvciBvciBkaXJlY3Rpb24gYnkgY28t Y2hhaXIpIGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBoYXZlIGJlZW4gZG9uZSB3L28gYSBjb25z ZW5zdXMgdm90ZSBzaW5jZSB0aGlzIGhhcyBiZWVuIGluIHRoZSBzcGVjaWZpY2F0aW9uIGZvciBz b21lIHRpbWUgd2l0aG91dCBpc3N1ZSBhbmQgdGhlIHJlbW92YWwgY29tZXMgYXMgY29tcGxldGUg dW53ZWxjb21lIHN1cnByaXNlLiBHZXR0aW5nIGFsbW9zdCB0b3RhbCByZXdyaXRlcyBvZiB0aGUg c3BlY2lmaWNhdGlvbiB0aGlzIGxhdGUgaW4gdGhlIHJldmlldyBjeWNsZSBpcyBhbHNvIHZlcnkg ZGlzdHVyYmluZy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRleHQ+PG86cD4mbmJz cDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkEgcHJvcG9zYWwgZm9yIGtlZXBpbmcg dGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gd291bGQgYmUgdG8gc2ltcGxpZnkg dG8gdGhlIGZvbGxvd2luZzs8bzpwPjwvbzpwPjwvcD48cD48c3BhbiBsYW5nPUVOIHN0eWxlPSdm b250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5UaGUgY2xpZW50 IGFzc2VydGlvbiBjcmVkZW50aWFscyBhcmUgdXNlZCBpbiBjYXNlcyB3aGVyZSBhIHBhc3N3b3Jk IChjbGVhci10ZXh0IHNoYXJlZCBzeW1tZXRyaWMgc2VjcmV0KSBpcyB1bnN1aXRhYmxlIG9yIGRv ZXMgbm90IHByb3ZpZGUgc3VmZmljaWVudCBzZWN1cml0eSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0 aW9uLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBwcm92aWRlIGFuIGV4dGVuc2li bGUgbWVjaGFuaXNtIHRvIHVzZSBhbiBhc3NlcnRpb24gZm9ybWF0IHN1cHBvcnRlZCBieSB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBjbGllbnQuIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LWZhbWlseToi VmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Vc2luZyBhc3NlcnRpb25zIHJlcXVp cmVzIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFzc2VydGlvbiAoc3VjaCBhcyBhIDwvc3Bhbj48 YSBocmVmPSIjT0FTSVMuc2FtbC1jb3JlLTIuMC1vcyI+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9u dC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjt0ZXh0LWRlY29yYXRpb246bm9uZSc+U0FN TCAoQ2FudG9yLCBTLiwgS2VtcCwgSi4sIFBoaWxwb3R0LCBSLiwgYW5kIEUuIE1hbGVyLCDigJxB c3NlcnRpb25zIGFuZCBQcm90b2NvbCBmb3IgdGhlIE9BU0lTIFNlY3VyaXR5IEFzc2VydGlvbiBN YXJrdXAgTGFuZ3VhZ2UgKFNBTUwpIFYyLjAs4oCdIE1hcmNoJm5ic3A7MjAwNS4pPC9zcGFuPjwv YT48c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYi O2NvbG9yOmJsYWNrJz4gW09BU0lTLnNhbWzigJFjb3Jl4oCRMi4w4oCRb3NdIGFzc2VydGlvbikg ZnJvbSBhbiBhc3NlcnRpb24gaXNzdWVyIG9yIHRvIHNlbGYtaXNzdWUgYW4gYXNzZXJ0aW9uLiBU aGUgYXNzZXJ0aW9uIGZvcm1hdCwgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhlIGFzc2VydGlvbiBp cyBvYnRhaW5lZCwgYW5kIHRoZSBtZXRob2Qgb2YgdmFsaWRhdGluZyB0aGUgYXNzZXJ0aW9uIGFy ZSBkZWZpbmVkIGJ5IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIsIGFuZCBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LWZhbWlseToi VmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5XaGVuIHVzaW5nIGEgY2xpZW50IGFz c2VydGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjYwLjBwdDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4t bGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOIHN0eWxlPSdm b250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5jbGllbnRfYXNz ZXJ0aW9uX3R5cGUgLSBSRVFVSVJFRC4gVGhlIGZvcm1hdCBvZiB0aGUgYXNzZXJ0aW9uIGFzIGRl ZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgdmFsdWUgTVVTVCBiZSBhbiBh YnNvbHV0ZSBVUkkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1sZWZ0OjI0LjBwdDt0ZXh0LWluZGVudDouNWluJz48c3BhbiBsYW5nPUVOIHN0 eWxlPSdmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5jbGll bnRfYXNzZXJ0aW9uIC0gUkVRVUlSRUQuIFRoZSBjbGllbnQgYXNzZXJ0aW9uLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHA+PHNwYW4gbGFuZz1FTiBzdHlsZT0nZm9udC1mYW1pbHk6IlZlcmRhbmEi LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Rm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgc2VuZHMg dGhlIGZvbGxvd2luZyBhY2Nlc3MgdG9rZW4gcmVxdWVzdCB1c2luZyBhIFNBTUwgMi4wIGFzc2Vy dGlvbiB0byBhdXRoZW50aWNhdGUgaXRzZWxmIChsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkg cHVycG9zZXMgb25seSk6IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTowaW47bWFy Z2luLWxlZnQ6NjAuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 MGluO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6NjAu MHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4gbGFuZz1FTj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9RU4+Jm5ic3A7IFBPU1QgL3Rva2VuIEhUVFAv MS4xPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0 OjBpbjttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjYw LjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9RU4+Jm5ic3A7IEhvc3Q6IHNl cnZlci5leGFtcGxlLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1F Tj4mbmJzcDsgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9RU4+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOPiZuYnNwOyBncmFudF90eXBlPWF1dGhv cml6YXRpb25fY29kZSZhbXA7Y29kZT1pMVdzUm4xdUIxJmFtcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT48cHJlPjxzcGFuIGxhbmc9RU4+Jm5ic3A7IGNsaWVudF9hc3NlcnRpb249UEhOaGJXeHdP bFsuLi5vbWl0dGVkIGZvciBicmV2aXR5Li4uXVpUNCUzRCZhbXA7PG86cD48L286cD48L3NwYW4+ PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOPiZuYnNwOyBjbGllbnRfYXNzZXJ0aW9uX3R5cGU9ICZu YnNwO3VybiUzQW9hc2lzJTNBbmFtZXMlc0F0YyUzQVNBTUwlM0EyLjAlM0Fhc3NlcnRpb24mYW1w O3JlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDowaW47 bWFyZ2luLXJpZ2h0OjI0LjBwdDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDo2MC4wcHQ7 bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBsYW5nPUVOPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPjxwIGNsYXNzPU1zb1BsYWluVGV4dD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmdd IDxiPk9uIEJlaGFsZiBPZiA8L2I+RXJhbiBIYW1tZXItTGFoYXY8YnI+PGI+U2VudDo8L2I+IEZy aWRheSwgSmFudWFyeSAxNCwgMjAxMSAxMDo0NSBQTTxicj48Yj5Ubzo8L2I+IE9BdXRoIFdHPGJy PjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3Jl ZGVudGlhbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5JIHdvdWxkIGxpa2Ug dG8gc3VnZ2VzdCB3ZSBkcm9wIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzICgtMTEg c2VjdGlvbiAzLjIpIGZyb20gdGhlIHNwZWNpZmljYXRpb24sIGFuZCBpZiBuZWVkZWQsIHB1Ymxp c2ggaXQgYXMgYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgZm9sbG93aW5nIHJlYXNv bnM6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21z by1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFu Iic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPlRoZSBtZWNoYW5pc20gaXMgdW5kZXIgc3BlY2lmaWVkLCBlc3BlY2lhbGx5IGluIGl0 cyBoYW5kbGluZyBvZiB0aGUgY2xpZW50X2lkIGlkZW50aWZpZXIgKHdoZW4gdXNlZCB0byBvYnRh aW4gZW5kLXVzZXIgYXV0aG9yaXphdGlvbikuIEl0IGRvZXMgbm90IGNvbnRhaW4gYW55IGltcGxl bWVudGF0aW9uIGRldGFpbHMgdG8gYWNjb21wbGlzaCBhbnkgbGV2ZWwgb2YgaW50ZXJvcGVyYWJp bGl0eSBvciBmdW5jdGlvbmFsaXR5LiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvIHRoZSBhc3NlcnRp b24gZ3JhbnQgdHlwZSB3aGljaCBoYXMgbWF0dXJlZCBvdmVyIGEgeWVhciBpbnRvIGEgZnVsbHkg dGhvdWdodC1vdXQgZXh0ZW5zaW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBhIHNlcGFyYXRlIFNB TUwgYXNzZXJ0aW9uIHNwZWNpZmljYXRpb24gd2l0aCBhY3RpdmUgZGVwbG95bWVudCAodGhlIHR3 bywgdG9nZXRoZXIgd2l0aCBydW5uaW5nIGNvZGUsIHNob3cgY2xlYXIgY29uc2Vuc3VzKS48bzpw PjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVz IE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT5UaGUgc2VjdGlvbiBpcyBhIGNvbmZ1c2VkIG1peCBvZiBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBzcHJpbmtsZWQgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UuIEluc3Rl YWQsIGl0IHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIGd1aWRlbGluZXMgZm9yIGV4dGVuZGluZyB0 aGUgc2V0IG9mIHN1cHBvcnRlZCBjbGllbnQgY3JlZGVudGlhbHMsIGJ1dCB3aXRob3V0IGRlZmlu aW5nIGEgbmV3IHJlZ2lzdHJ5LiBJdCBpcyBjbGVhcmx5IGFuIGFyZWEgb2YgbGl0dGxlIGRlcGxv eW1lbnQgZXhwZXJpZW5jZSBmb3IgT0F1dGgsIGFuZCB0aGF0IGluY2x1ZGVzIHVzaW5nIEhUVFAg QmFzaWMgYXV0aGVudGljYXRpb24gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAobW9yZSBvbiB0 aGF0IHRvIGNvbWUpLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5 bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+My48c3BhbiBzdHlsZT0n Zm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBzZWN0aW9uIGhhcyByZWNlaXZl ZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3NlIHdobyBzdGls bCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkgY29uc2Vuc3Vz IGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBvcnQgZm9yIGRl cGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsIGFsc28gcmVxdWlyZSBzaG93 aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9maWxpbmcgdGhlIG1lY2hh bmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PkNvbW1lbnRzPyBDb3VudGVyLWFyZ3VtZW50cz88bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkVITDxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6250DP3PW5EX1MB01E_-- From eran@hueniverse.com Tue Jan 25 18:08:31 2011 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 4C3593A6902 for ; Tue, 25 Jan 2011 18:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 qXchuxvRuNGP for ; Tue, 25 Jan 2011 18:08:24 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 901273A68FD for ; Tue, 25 Jan 2011 18:08:24 -0800 (PST) Received: (qmail 5729 invoked from network); 26 Jan 2011 02:11:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 02:11:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 25 Jan 2011 19:11:23 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin Date: Tue, 25 Jan 2011 19:11:06 -0700 Thread-Topic: [OAUTH-WG] Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQIaL9MwABSNlwAAEKmTQAAgBu8w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62513@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> <180155C5EA10854997314CA5E063D18F033A7757@TK5EX14MBXC111.redmond.corp.microsoft.com> In-Reply-To: <180155C5EA10854997314CA5E063D18F033A7757@TK5EX14MBXC111.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62513P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 26 Jan 2011 02:08:31 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62513P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2NvcGUgd2FzIGRpc2N1c3NlZCBpbiBkZXRhaWwsIGluY2x1ZGluZyB1c2UgY2FzZXMgYW5kIGlt cGxlbWVudGF0aW9uIGV4cGVyaWVuY2UgYW5kIHRoZSBjdXJyZW50IGxhbmd1YWdlIHdhcyAocGFp bmZ1bGx5KSBuZWdvdGlhdGVkIHRvIHJlYWNoIGEgYmFsYW5jZSBiZXR3ZWVuIGZsZXhpYmlsaXR5 IGFuZCBsaWJyYXJ5IGludGVyb3BlcmFiaWxpdHkuIENsaWVudCBwYXNzd29yZCBhdXRoZW50aWNh dGlvbiBpcyB3ZWxsIHVuZGVyc3Rvb2QsIGlzIHRoZSBwcmltYXJ5IHdheSBBUEkgY2FsbHMgYXJl IGF1dGhlbnRpY2F0ZWQgb24gdGhlIHdlYiB0b2RheSAoQVBJIGtleSBhbmQgc2VjcmV0KSwgaXQg aXMgaG93IE9BdXRoIDEuMCBkZWZpbmVkIGNsaWVudCBhdXRoZW50aWNhdGlvbiwgYW5kIGVuam95 cyBudW1lcm91cyBleGFtcGxlcyB0aHJvdWdob3V0IHRoZSBzcGVjaWZpY2F0aW9uIGZvciBlYWNo IGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZS4gR290IG90aGVyIGV4YW1wbGVzPw0KDQpBZGRpbmcg dGhlIHByb3Bvc2VkIHRleHQgaW4gaXMgbm90IGFuIG9wdGlvbiBnaXZlbiB0aGUgb2JqZWN0aW9u cyByYWlzZWQuIFRoaXMgcHJvY2VzcyBhcmd1bWVudCBpcyBtb290IGJlY2F1c2Ugd2hldGhlciB3 ZSBwdXQgaXQgYmFjayBpbiBvciBub3QgYmVmb3JlIHdlIHJlYWNoIGNvbnNlbnN1cyBvbiB0aGUg bGFuZ3VhZ2UsIGl0IHdpbGwgdGFrZSB0aGUgc2FtZSBhbW91bnQgb2YgdGltZSB0byBkbyBqdXN0 IHRoYXQg4oCTIHJlYWNoIGNvbnNlbnN1cy4gRHJhZnRpbmcgYW5vdGhlciBzcGVjIHdpbGwgZ2l2 ZSB1cyB0aGUgdGltZSB0byBwcm9wZXJseSBkaXNjdXNzIGl0IGFuZCByZWFjaCBhIHVzZWZ1bCwg ZnVsbHkgc3BlY2lmaWVkIGRvY3VtZW50IHdpdGggZXhhbXBsZXMgYW5kIG90aGVyIGRldGFpbHMg dGhhdCBvdGhlcndpc2Ugd2lsbCBkZWxheSB0aGlzIGRvY3VtZW50LiBXZSBmb2xsb3dlZCB0aGlz IGV4YWN0IHByb2Nlc3MgZm9yIHRoZSBTQU1MIGFzc2VydGlvbnMgc3BlY2lmaWNhdGlvbi4NCg0K SW4gYWRkaXRpb24sIGV2ZXJ5dGhpbmcgaW4gdGhlIHNwZWMgcmlnaHQgbm93IGlzIHNwZWNpZmll ZCBpbiBlbm91Z2ggZGV0YWlsIHRvIHdyaXRlIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNl Y3Rpb24uIEkgaGF2ZSBubyBjbHVlIGhvdyBhbnlvbmUgY2FuIGRlc2NyaWJlIHRoZSBzZWN1cml0 eSBjaGFyYWN0ZXJpc3RpY3Mgb2YgdGhpcyBwcm9wb3NlZCB0ZXh0IGdpdmVuIHRoYXQgaXQgaGFz IGFic29sdXRlbHkgbm8gZGV0YWlscyBoZWxwZnVsIHRvIGV2YWx1YXRlIGl0cyBzZWN1cml0eSBw cm9wZXJ0aWVzLiBUaGlzIG1ha2VzIHlvdXIgb3BlbmluZyBwYXJhZ3JhcGggaW4gdGhlIHByb3Bv c2VkIHRleHQgc29tZW9uZSBvZiBhIHRvbmd1ZSBpbiBjaGVlay4g4oCcV2hlbiBwYXNzd29yZHMg YXJlIG5vdCBlbm91Z2gsIHVzZSB0aGlzIHN0cm9uZyBhbmQgY29tcGxldGVseSB1bmRlZmluZWQg bWV0aG9k4oCdLg0KDQpXZSB3aWxsIG9ubHkgbWFrZSBwcm9ncmVzcyBvbiB0aGlzIGlmIHlvdSBz dG9wIHRyeWluZyB0byB1c2UgcHJvY2VzcyBhcmd1bWVudHMgKHNpbmNlIGFzIERhdmlkIHBvaW50 ZWQgb3V0LCB0aGlzIHdhcyBwdXQgaW50byB0aGUgc3BlYyBpbiB2aW9sYXRpb24gb2Ygb3VyIHBy b2Nlc3MgYW5kIEkgYXBvbG9naXplIGZvciB0aGF0KSwgYW5kIHN0YXJ0IHdvcmtpbmcgdG93YXJk cyBhIGxhbmd1YWdlIHRoZSBXRyBjYW4gYWdyZWUgb24uDQoNCkVITA0KDQpGcm9tOiBBbnRob255 IE5hZGFsaW4gW21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dDQpTZW50OiBUdWVzZGF5LCBK YW51YXJ5IDI1LCAyMDExIDU6MzIgUE0NClRvOiBEYXZpZCBSZWNvcmRvbjsgSGFubmVzLlRzY2hv ZmVuaWdAZ214Lm5ldDsgRXJhbiBIYW1tZXItTGFoYXYNCkNjOiBPQXV0aCBXRzsgQmxhaW5lIENv b2sNClN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3Jl ZGVudGlhbHMNCg0KQmFzZWQgb24geW91ciBsb2dpYyB0aGVuIFNjb3BlLCBDbGllbnQgUGFzc3dv cmQgQXV0aGVudGljYXRpb24sIGV0Yywgc2hvdWxkIGJlIHJlbW92ZWQuIE5vdCBzdXJlIGhvdyBs ZWF2aW5nIHRoZSBwcm9wb3NlZCB0ZXh0IGluIHdvdWxkIGRlbGF5IHRoaW5ncw0KDQpGcm9tOiBE YXZpZCBSZWNvcmRvbiBbbWFpbHRvOnJlY29yZG9uZEBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5 LCBKYW51YXJ5IDI1LCAyMDExIDU6MTEgUE0NClRvOiBBbnRob255IE5hZGFsaW47IEhhbm5lcy5U c2Nob2ZlbmlnQGdteC5uZXQ7IEVyYW4gSGFtbWVyLUxhaGF2DQpDYzogT0F1dGggV0c7IEJsYWlu ZSBDb29rDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9u IENyZWRlbnRpYWxzDQoNCkV4cGxpY2l0bHkgc2F5aW5nLCAiVGhlIGFzc2VydGlvbiBmb3JtYXQs IHRoZSBwcm9jZXNzIGJ5IHdoaWNoIHRoZSBhc3NlcnRpb24gaXMgb2J0YWluZWQsIGFuZCB0aGUg bWV0aG9kIG9mIHZhbGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmUgZGVmaW5lZCBieSB0aGUgYXNz ZXJ0aW9uIGlzc3VlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBhbmQgYXJlIGJleW9u ZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIiBzZWVtcyB0byByZWluZm9yY2UgdGhl IHBvaW50IGFib3V0IHRoaXMgYmVpbmcgdW5kZXJzcGVjaWZpZWQuIFRoaXMgd291bGQgc3RpbGwg cmVxdWlyZSBhIHNlY29uZCBkb2N1bWVudCB3aGljaCBkZXNjcmliZXMgdGhlIGRhdGEgd2l0aGlu IHRoZSBTQU1MIGFzc2VydGlvbiBhcyB3ZWxsIGFzIGhvdyBpdCBtYXBzIGJhY2sgdG8gYSBjbGll bnRfaWQuDQoNCk9uIHRoZSBwcm9jZXNzIHNpZGUsIElJUkMgdGhpcyB3YXMgYWRkZWQgdG8gdGhl IHNwZWMgd2l0aG91dCBhbnkgY29uc2Vuc3VzIGFuZCBvdmVyIHNvbWUgcmVzZXJ2YXRpb25zIGJ5 IEVyYW4uLi53aGljaCB3YXMgYSBicm9rZW4gcHJvY2VzcyB0byBiZWdpbiB3aXRoIGFuZCBhIHBv b3IgZGVjaXNpb24gb24gaGlzIHBhcnQuIEkgc2hhcmUgSGFubmVzJyBkZXNpcmUgdG8gbW92ZSB0 aGlzIGJhc2Ugc3BlYyB0byBsYXN0IGNhbGwuIFdvcnJpZWQgdGhhdCBsZWF2aW5nIHRoaXMgdGV4 dCBpbiBpcyBnb2luZyB0byBkZWxheSB0aGF0IHdoZXJlYXMgbW92aW5nIGl0IHRvIGEgc2VwYXJh dGUgZG9jdW1lbnQgcHVibGlzaGVkIGJ5IHRoZSBPQXV0aCBXRyB3aWxsIHN0aWxsIGxlYWQgdG93 YXJkIG1hcmtldCBhZG9wdGlvbiBvZiBhIG1vcmUgZnVsbHkgc3BlY2lmaWVkIGZlYXR1cmUuDQoN Ci0tRGF2aWQNCg0KT24gVHVlLCBKYW4gMjUsIDIwMTEgYXQgMzo1OCBQTSwgQW50aG9ueSBOYWRh bGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+ IHdyb3RlOg0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBmb3IgcmVtb3Zpbmcg dGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMsIGFzIGNsaWVudCBwYXNzd29yZCBhdXRo ZW50aWNhdGlvbiBpcyBsZWZ0IGluLiBDbGllbnQgUGFzc3dvcmQgQXV0aGVudGljYXRpb24gaXMg YWxzbyB1bmRlcnNwZWNpZmllZCBhcyBjbGllbnRfc2VjcmV0IGNvdWxkIGJlIGFueXRoaW5nIHRo YXQgdGhlIGF1dGhlbnRpY2F0aW9uIHNlcnZlciBzZWVtcyBmaXQgKHJhdyBjbGVhciB0ZXh0IHBh c3N3b3JkLCAgaGFzaCwgZGlnZXN0LCBldGMuKSBhbmQgbm8gd2F5IHRvIGRldGVybWluZSB0aGUg Y29udGVudC4gY2xpZW50X3NlY3JldCBpcyBhbHNvIGEgdmVyeSB3ZWFrIG1lY2hhbmlzbSwgc2lu Y2UgdGhpcyBpcyBsZWZ0IGluIHRoZSBjb3JlIHRoaXMgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0 IHRoZXJlIGlzIHN1cHBvcnQgZm9yIGhhdmluZyBjbGllbnQgYXV0aGVudGljYXRpb24gaW4gT2F1 dGguIEkgZG9uJ3Qgc2VlIGhvdyBoYXZpbmcgY2xpZW50X2Fzc2VydGlvbiBhbmQgY2xpZW50X2Fz c2VydGlvbl90eXBlIHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGlzIHVuZGVyc3BlY2lmaWVkIGFz IGJlaW5nIGEgbWVjaGFuaXNtIGluIHdoaWNoIGFzc2VydGlvbnMgY2FuIGJlIHVzZWQgZm9yIGF1 dGhlbnRpY2F0aW9uLiBBZ3JlZSB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgaGFzIHRv IG1ha2UgcmlnaHQgYW5kIGRlY2xhcmUgd2hhdCBpcyBiZWluZyB1c2VkIGJ1dCB0aGF0IGlzIHRo ZSBzYW1lIGZvciBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXV0 aGVudGljYXRpb24gYXNzZXJ0aW9ucyBhcmUgc29tZXRoaW5nIHRoYXQgTWljcm9zb2Z0IGFuZCBH b29nbGUgZmluZCB1c2VmdWwgYW5kIHBsYW4gb24gaW1wbGVtZW50aW5nIGFuZCB1c2luZyBhcyBh IG1lYW5zIGZvciBzdHJvbmdlciBhdXRoZW50aWNhdGlvbiB0byB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIuIFRoaXMgZXh0ZW5zaWJpbGl0eSBiZWxvbmdzIGluIHRoZSBjb3JlLCB0aGVyZSBpcyBu byBvdGhlciBwbGFjZSB0byBwdXQgdGhpcyBmdW5jdGlvbmFsaXR5LiBJIGRvbid0IGJlbGlldmUg dGhhdCB0aGUgcmVtb3ZhbCAoZWl0aGVyIGJ5IGVkaXRvciBvciBkaXJlY3Rpb24gYnkgY28tY2hh aXIpIGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBoYXZlIGJlZW4gZG9uZSB3L28gYSBjb25zZW5z dXMgdm90ZSBzaW5jZSB0aGlzIGhhcyBiZWVuIGluIHRoZSBzcGVjaWZpY2F0aW9uIGZvciBzb21l IHRpbWUgd2l0aG91dCBpc3N1ZSBhbmQgdGhlIHJlbW92YWwgY29tZXMgYXMgY29tcGxldGUgdW53 ZWxjb21lIHN1cnByaXNlLiBHZXR0aW5nIGFsbW9zdCB0b3RhbCByZXdyaXRlcyBvZiB0aGUgc3Bl Y2lmaWNhdGlvbiB0aGlzIGxhdGUgaW4gdGhlIHJldmlldyBjeWNsZSBpcyBhbHNvIHZlcnkgZGlz dHVyYmluZy4NCg0KDQoNCkEgcHJvcG9zYWwgZm9yIGtlZXBpbmcgdGhlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBhc3NlcnRpb24gd291bGQgYmUgdG8gc2ltcGxpZnkgdG8gdGhlIGZvbGxvd2luZzsN Cg0KVGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYXJlIHVzZWQgaW4gY2FzZXMgd2hl cmUgYSBwYXNzd29yZCAoY2xlYXItdGV4dCBzaGFyZWQgc3ltbWV0cmljIHNlY3JldCkgaXMgdW5z dWl0YWJsZSBvciBkb2VzIG5vdCBwcm92aWRlIHN1ZmZpY2llbnQgc2VjdXJpdHkgZm9yIGNsaWVu dCBhdXRoZW50aWNhdGlvbi4gVGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgcHJvdmlk ZSBhbiBleHRlbnNpYmxlIG1lY2hhbmlzbSB0byB1c2UgYW4gYXNzZXJ0aW9uIGZvcm1hdCBzdXBw b3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGZvciBhdXRoZW50aWNhdGlvbiBvZiB0 aGUgY2xpZW50Lg0KDQpVc2luZyBhc3NlcnRpb25zIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8gb2J0 YWluIGFuIGFzc2VydGlvbiAoc3VjaCBhcyBhIFNBTUwgKENhbnRvciwgUy4sIEtlbXAsIEouLCBQ aGlscG90dCwgUi4sIGFuZCBFLiBNYWxlciwg4oCcQXNzZXJ0aW9ucyBhbmQgUHJvdG9jb2wgZm9y IHRoZSBPQVNJUyBTZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdlIChTQU1MKSBWMi4w LOKAnSBNYXJjaCAyMDA1LikgW09BU0lTLnNhbWzigJFjb3Jl4oCRMi4w4oCRb3NdIGFzc2VydGlv bikgZnJvbSBhbiBhc3NlcnRpb24gaXNzdWVyIG9yIHRvIHNlbGYtaXNzdWUgYW4gYXNzZXJ0aW9u LiBUaGUgYXNzZXJ0aW9uIGZvcm1hdCwgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhlIGFzc2VydGlv biBpcyBvYnRhaW5lZCwgYW5kIHRoZSBtZXRob2Qgb2YgdmFsaWRhdGluZyB0aGUgYXNzZXJ0aW9u IGFyZSBkZWZpbmVkIGJ5IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIsIGFuZCBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24u DQoNCldoZW4gdXNpbmcgYSBjbGllbnQgYXNzZXJ0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIHRo ZSBmb2xsb3dpbmcgcGFyYW1ldGVyczoNCmNsaWVudF9hc3NlcnRpb25fdHlwZSAtIFJFUVVJUkVE LiBUaGUgZm9ybWF0IG9mIHRoZSBhc3NlcnRpb24gYXMgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIuIFRoZSB2YWx1ZSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSS4NCmNsaWVudF9h c3NlcnRpb24gLSBSRVFVSVJFRC4gVGhlIGNsaWVudCBhc3NlcnRpb24uDQoNCkZvciBleGFtcGxl LCB0aGUgY2xpZW50IHNlbmRzIHRoZSBmb2xsb3dpbmcgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXNp bmcgYSBTQU1MIDIuMCBhc3NlcnRpb24gdG8gYXV0aGVudGljYXRlIGl0c2VsZiAobGluZSBicmVh a3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOg0KDQoNCg0KDQoNCiAgUE9TVCAvdG9r ZW4gSFRUUC8xLjENCg0KICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb208aHR0cDovL3NlcnZlci5l eGFtcGxlLmNvbT4NCg0KICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJs ZW5jb2RlZA0KDQoNCg0KICBncmFudF90eXBlPWF1dGhvcml6YXRpb25fY29kZSZjb2RlPWkxV3NS bjF1QjEmDQoNCiAgY2xpZW50X2Fzc2VydGlvbj1QSE5oYld4d09sWy4uLm9taXR0ZWQgZm9yIGJy ZXZpdHkuLi5dWlQ0JTNEJg0KDQogIGNsaWVudF9hc3NlcnRpb25fdHlwZT0gIHVybiUzQW9hc2lz JTNBbmFtZXMlc0F0YyUzQVNBTUwlM0EyLjAlM0Fhc3NlcnRpb24mcmVkaXJlY3RfdXJpPWh0dHBz JTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiDQoNCg0KDQoNCg0KDQpGcm9tOiBv YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFp bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+ XSBPbiBCZWhhbGYgT2YgRXJhbiBIYW1tZXItTGFoYXYNClNlbnQ6IEZyaWRheSwgSmFudWFyeSAx NCwgMjAxMSAxMDo0NSBQTQ0KVG86IE9BdXRoIFdHDQpTdWJqZWN0OiBbT0FVVEgtV0ddIFJlbW92 YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMNCg0KSSB3b3VsZCBsaWtlIHRvIHN1Z2dl c3Qgd2UgZHJvcCB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyAoLTExIHNlY3Rpb24g My4yKSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uLCBhbmQgaWYgbmVlZGVkLCBwdWJsaXNoIGl0IGFz IGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOg0KDQoN CjEuICAgICAgIFRoZSBtZWNoYW5pc20gaXMgdW5kZXIgc3BlY2lmaWVkLCBlc3BlY2lhbGx5IGlu IGl0cyBoYW5kbGluZyBvZiB0aGUgY2xpZW50X2lkIGlkZW50aWZpZXIgKHdoZW4gdXNlZCB0byBv YnRhaW4gZW5kLXVzZXIgYXV0aG9yaXphdGlvbikuIEl0IGRvZXMgbm90IGNvbnRhaW4gYW55IGlt cGxlbWVudGF0aW9uIGRldGFpbHMgdG8gYWNjb21wbGlzaCBhbnkgbGV2ZWwgb2YgaW50ZXJvcGVy YWJpbGl0eSBvciBmdW5jdGlvbmFsaXR5LiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvIHRoZSBhc3Nl cnRpb24gZ3JhbnQgdHlwZSB3aGljaCBoYXMgbWF0dXJlZCBvdmVyIGEgeWVhciBpbnRvIGEgZnVs bHkgdGhvdWdodC1vdXQgZXh0ZW5zaW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBhIHNlcGFyYXRl IFNBTUwgYXNzZXJ0aW9uIHNwZWNpZmljYXRpb24gd2l0aCBhY3RpdmUgZGVwbG95bWVudCAodGhl IHR3bywgdG9nZXRoZXIgd2l0aCBydW5uaW5nIGNvZGUsIHNob3cgY2xlYXIgY29uc2Vuc3VzKS4N Cg0KMi4gICAgICAgVGhlIHNlY3Rpb24gaXMgYSBjb25mdXNlZCBtaXggb2Ygc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc3ByaW5rbGVkIHdpdGggbm9ybWF0aXZlIGxhbmd1YWdlLiBJbnN0ZWFkLCBp dCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBndWlkZWxpbmVzIGZvciBleHRlbmRpbmcgdGhlIHNl dCBvZiBzdXBwb3J0ZWQgY2xpZW50IGNyZWRlbnRpYWxzLCBidXQgd2l0aG91dCBkZWZpbmluZyBh IG5ldyByZWdpc3RyeS4gSXQgaXMgY2xlYXJseSBhbiBhcmVhIG9mIGxpdHRsZSBkZXBsb3ltZW50 IGV4cGVyaWVuY2UgZm9yIE9BdXRoLCBhbmQgdGhhdCBpbmNsdWRlcyB1c2luZyBIVFRQIEJhc2lj IGF1dGhlbnRpY2F0aW9uIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gKG1vcmUgb24gdGhhdCB0 byBjb21lKS4NCg0KMy4gICAgICAgVGhlIHNlY3Rpb24gaGFzIHJlY2VpdmVkIGEgbGl0dGxlIHN1 cHBvcnQgYW5kIGEgbGl0dGxlIG9iamVjdGlvbi4gVGhvc2Ugd2hvIHN0aWxsIHdhbnQgdG8gYWR2 b2NhdGUgZm9yIGl0IG5lZWQgdG8gc2hvdyBub3Qgb25seSBjb25zZW5zdXMgZm9yIGtlZXBpbmcg aXQsIGJ1dCBhbHNvIGFjdGl2ZSBjb21tdW5pdHkgc3VwcG9ydCBmb3IgZGVwbG95aW5nIGl0LiBE ZXBsb3ltZW50LCBvZiBjb3Vyc2UsIHdpbGwgYWxzbyByZXF1aXJlIHNob3dpbmcgcHJvZ3Jlc3Mg b24gcHVibGljIHNwZWNpZmljYXRpb25zIHByb2ZpbGluZyB0aGUgbWVjaGFuaXNtIGludG8gYSB1 c2VmdWwgaW50ZXJvcGVyYWJsZSBmZWF0dXJlLg0KDQpDb21tZW50cz8gQ291bnRlci1hcmd1bWVu dHM/DQoNCkVITA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRo QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K DQo= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62513P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0 ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25z b2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFs bG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5h cHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bh bi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9o ZWFkPjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdv cmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5TY29w ZSB3YXMgZGlzY3Vzc2VkIGluIGRldGFpbCwgaW5jbHVkaW5nIHVzZSBjYXNlcyBhbmQgaW1wbGVt ZW50YXRpb24gZXhwZXJpZW5jZSBhbmQgdGhlIGN1cnJlbnQgbGFuZ3VhZ2Ugd2FzIChwYWluZnVs bHkpIG5lZ290aWF0ZWQgdG8gcmVhY2ggYSBiYWxhbmNlIGJldHdlZW4gZmxleGliaWxpdHkgYW5k IGxpYnJhcnkgaW50ZXJvcGVyYWJpbGl0eS4gQ2xpZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9u IGlzIHdlbGwgdW5kZXJzdG9vZCwgaXMgdGhlIHByaW1hcnkgd2F5IEFQSSBjYWxscyBhcmUgYXV0 aGVudGljYXRlZCBvbiB0aGUgd2ViIHRvZGF5IChBUEkga2V5IGFuZCBzZWNyZXQpLCBpdCBpcyBo b3cgT0F1dGggMS4wIGRlZmluZWQgY2xpZW50IGF1dGhlbnRpY2F0aW9uLCBhbmQgZW5qb3lzIG51 bWVyb3VzIGV4YW1wbGVzIHRocm91Z2hvdXQgdGhlIHNwZWNpZmljYXRpb24gZm9yIGVhY2ggYXV0 aG9yaXphdGlvbiBncmFudCB0eXBlLiBHb3Qgb3RoZXIgZXhhbXBsZXM/PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5BZGRpbmcgdGhlIHByb3Bvc2VkIHRleHQgaW4gaXMgbm90IGFuIG9wdGlvbiBnaXZlbiB0 aGUgb2JqZWN0aW9ucyByYWlzZWQuIFRoaXMgcHJvY2VzcyBhcmd1bWVudCBpcyBtb290IGJlY2F1 c2Ugd2hldGhlciB3ZSBwdXQgaXQgYmFjayBpbiBvciBub3QgYmVmb3JlIHdlIHJlYWNoIGNvbnNl bnN1cyBvbiB0aGUgbGFuZ3VhZ2UsIGl0IHdpbGwgdGFrZSB0aGUgc2FtZSBhbW91bnQgb2YgdGlt ZSB0byBkbyBqdXN0IHRoYXQg4oCTIHJlYWNoIGNvbnNlbnN1cy4gRHJhZnRpbmcgYW5vdGhlciBz cGVjIHdpbGwgZ2l2ZSB1cyB0aGUgdGltZSB0byBwcm9wZXJseSBkaXNjdXNzIGl0IGFuZCByZWFj aCBhIHVzZWZ1bCwgZnVsbHkgc3BlY2lmaWVkIGRvY3VtZW50IHdpdGggZXhhbXBsZXMgYW5kIG90 aGVyIGRldGFpbHMgdGhhdCBvdGhlcndpc2Ugd2lsbCBkZWxheSB0aGlzIGRvY3VtZW50LiBXZSBm b2xsb3dlZCB0aGlzIGV4YWN0IHByb2Nlc3MgZm9yIHRoZSBTQU1MIGFzc2VydGlvbnMgc3BlY2lm aWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkluIGFkZGl0aW9uLCBldmVyeXRoaW5nIGluIHRo ZSBzcGVjIHJpZ2h0IG5vdyBpcyBzcGVjaWZpZWQgaW4gZW5vdWdoIGRldGFpbCB0byB3cml0ZSB0 aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uLiBJIGhhdmUgbm8gY2x1ZSBob3cgYW55 b25lIGNhbiBkZXNjcmliZSB0aGUgc2VjdXJpdHkgY2hhcmFjdGVyaXN0aWNzIG9mIHRoaXMgcHJv cG9zZWQgdGV4dCBnaXZlbiB0aGF0IGl0IGhhcyBhYnNvbHV0ZWx5IG5vIGRldGFpbHMgaGVscGZ1 bCB0byBldmFsdWF0ZSBpdHMgc2VjdXJpdHkgcHJvcGVydGllcy4gVGhpcyBtYWtlcyB5b3VyIG9w ZW5pbmcgcGFyYWdyYXBoIGluIHRoZSBwcm9wb3NlZCB0ZXh0IHNvbWVvbmUgb2YgYSB0b25ndWUg aW4gY2hlZWsuIOKAnFdoZW4gcGFzc3dvcmRzIGFyZSBub3QgZW5vdWdoLCB1c2UgdGhpcyBzdHJv bmcgYW5kIGNvbXBsZXRlbHkgdW5kZWZpbmVkIG1ldGhvZOKAnS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PldlIHdpbGwgb25seSBtYWtlIHByb2dyZXNzIG9uIHRoaXMgaWYgeW91IHN0b3AgdHJ5aW5nIHRv IHVzZSBwcm9jZXNzIGFyZ3VtZW50cyAoc2luY2UgYXMgRGF2aWQgcG9pbnRlZCBvdXQsIHRoaXMg d2FzIHB1dCBpbnRvIHRoZSBzcGVjIGluIHZpb2xhdGlvbiBvZiBvdXIgcHJvY2VzcyBhbmQgSSBh cG9sb2dpemUgZm9yIHRoYXQpLCBhbmQgc3RhcnQgd29ya2luZyB0b3dhcmRzIGEgbGFuZ3VhZ2Ug dGhlIFdHIGNhbiBhZ3JlZSBvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5 bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiJz4gQW50aG9ueSBOYWRhbGluIFttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQu Y29tXSA8YnI+PGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgNTozMiBQTTxi cj48Yj5Ubzo8L2I+IERhdmlkIFJlY29yZG9uOyBIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0OyBF cmFuIEhhbW1lci1MYWhhdjxicj48Yj5DYzo8L2I+IE9BdXRoIFdHOyBCbGFpbmUgQ29vazxicj48 Yj5TdWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBD cmVkZW50aWFsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+QmFzZWQgb24geW91ciBsb2dpYyB0aGVuIFNjb3BlLCBDbGllbnQgUGFzc3dv cmQgQXV0aGVudGljYXRpb24sIGV0Yywgc2hvdWxkIGJlIHJlbW92ZWQuIE5vdCBzdXJlIGhvdyBs ZWF2aW5nIHRoZSBwcm9wb3NlZCB0ZXh0IGluIHdvdWxkIGRlbGF5IHRoaW5nczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIic+IERhdmlkIFJlY29yZG9uIFttYWlsdG86cmVjb3Jkb25kQGdt YWlsLmNvbV0gPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDI1LCAyMDExIDU6MTEg UE08YnI+PGI+VG86PC9iPiBBbnRob255IE5hZGFsaW47IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5u ZXQ7IEVyYW4gSGFtbWVyLUxhaGF2PGJyPjxiPkNjOjwvYj4gT0F1dGggV0c7IEJsYWluZSBDb29r PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0 aW9uIENyZWRlbnRpYWxzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+RXhwbGljaXRseSBzYXlpbmcs ICZxdW90OzxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPlRoZSBhc3NlcnRpb24g Zm9ybWF0LCB0aGUgcHJvY2VzcyBieSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlzIG9idGFpbmVkLCBh bmQgdGhlIG1ldGhvZCBvZiB2YWxpZGF0aW5nIHRoZSBhc3NlcnRpb24gYXJlIGRlZmluZWQgYnkg dGhlIGFzc2VydGlvbiBpc3N1ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIGFy ZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbiZxdW90OyBzZWVtcyB0byBy ZWluZm9yY2UgdGhlIHBvaW50IGFib3V0IHRoaXMgYmVpbmcgdW5kZXJzcGVjaWZpZWQuIFRoaXMg d291bGQgc3RpbGwgcmVxdWlyZSBhIHNlY29uZCBkb2N1bWVudCB3aGljaCBkZXNjcmliZXMgdGhl IGRhdGEgd2l0aGluIHRoZSBTQU1MIGFzc2VydGlvbiBhcyB3ZWxsIGFzIGhvdyBpdCBtYXBzIGJh Y2sgdG8gYSBjbGllbnRfaWQuPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBjbGFzcz1hcHBsZS1zdHlsZS1zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+T24gdGhlIHByb2Nlc3Mgc2lkZSwgSUlSQyB0aGlz IHdhcyBhZGRlZCB0byB0aGUgc3BlYyB3aXRob3V0IGFueSBjb25zZW5zdXMgYW5kIG92ZXIgc29t ZSByZXNlcnZhdGlvbnMgYnkgRXJhbi4uLndoaWNoIHdhcyBhIGJyb2tlbiBwcm9jZXNzIHRvIGJl Z2luIHdpdGggYW5kIGEgcG9vciBkZWNpc2lvbiBvbiBoaXMgcGFydC4gSSBzaGFyZSBIYW5uZXMn IGRlc2lyZSB0byBtb3ZlIHRoaXMgYmFzZSBzcGVjIHRvIGxhc3QgY2FsbC4gV29ycmllZCB0aGF0 IGxlYXZpbmcgdGhpcyB0ZXh0IGluIGlzIGdvaW5nIHRvIGRlbGF5IHRoYXQgd2hlcmVhcyBtb3Zp bmcgaXQgdG8gYSBzZXBhcmF0ZSBkb2N1bWVudCBwdWJsaXNoZWQgYnkgdGhlIE9BdXRoIFdHIHdp bGwgc3RpbGwgbGVhZCB0b3dhcmQgbWFya2V0IGFkb3B0aW9uIG9mIGEgbW9yZSBmdWxseSBzcGVj aWZpZWQgZmVhdHVyZS48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4tLURhdmlkPC9zcGFuPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRv bToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9u IFR1ZSwgSmFuIDI1LCAyMDExIGF0IDM6NTggUE0sIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRpdj48ZGl2PjxwPkkgZG9uJ3QgdW5kZXJzdGFu ZCB0aGUgcmF0aW9uYWxlIGZvciByZW1vdmluZyB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50 aWFscywgYXMgY2xpZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIGlzIGxlZnQgaW4uIENsaWVu dCBQYXNzd29yZCBBdXRoZW50aWNhdGlvbiBpcyBhbHNvIHVuZGVyc3BlY2lmaWVkIGFzIGNsaWVu dF9zZWNyZXQgY291bGQgYmUgYW55dGhpbmcgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVy IHNlZW1zIGZpdCAocmF3IGNsZWFyIHRleHQgcGFzc3dvcmQsJm5ic3A7IGhhc2gsIGRpZ2VzdCwg ZXRjLikgYW5kIG5vIHdheSB0byBkZXRlcm1pbmUgdGhlIGNvbnRlbnQuIGNsaWVudF9zZWNyZXQg aXMgYWxzbyBhIHZlcnkgd2VhayBtZWNoYW5pc20sIHNpbmNlIHRoaXMgaXMgbGVmdCBpbiB0aGUg Y29yZSB0aGlzIGxlYWRzIG1lIHRvIGJlbGlldmUgdGhhdCB0aGVyZSBpcyBzdXBwb3J0IGZvciBo YXZpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIE9hdXRoLiBJIGRvbid0IHNlZSBob3cgaGF2 aW5nIGNsaWVudF9hc3NlcnRpb24gYW5kIGNsaWVudF9hc3NlcnRpb25fdHlwZSB3b3VsZCBiZSBz b21ldGhpbmcgdGhhdCBpcyB1bmRlcnNwZWNpZmllZCBhcyBiZWluZyBhIG1lY2hhbmlzbSBpbiB3 aGljaCBhc3NlcnRpb25zIGNhbiBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbi4gQWdyZWUgdGhh dCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyIGhhcyB0byBtYWtlIHJpZ2h0IGFuZCBkZWNsYXJl IHdoYXQgaXMgYmVpbmcgdXNlZCBidXQgdGhhdCBpcyB0aGUgc2FtZSBmb3IgY2xpZW50IHBhc3N3 b3JkIGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbnMg YXJlIHNvbWV0aGluZyB0aGF0IE1pY3Jvc29mdCBhbmQgR29vZ2xlIGZpbmQgdXNlZnVsIGFuZCBw bGFuIG9uIGltcGxlbWVudGluZyBhbmQgdXNpbmcgYXMgYSBtZWFucyBmb3Igc3Ryb25nZXIgYXV0 aGVudGljYXRpb24gdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGlzIGV4dGVuc2liaWxp dHkgYmVsb25ncyBpbiB0aGUgY29yZSwgdGhlcmUgaXMgbm8gb3RoZXIgcGxhY2UgdG8gcHV0IHRo aXMgZnVuY3Rpb25hbGl0eS4gSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhlIHJlbW92YWwgKGVpdGhl ciBieSBlZGl0b3Igb3IgZGlyZWN0aW9uIGJ5IGNvLWNoYWlyKSBpcyBzb21ldGhpbmcgdGhhdCBz aG91bGQgaGF2ZSBiZWVuIGRvbmUgdy9vIGEgY29uc2Vuc3VzIHZvdGUgc2luY2UgdGhpcyBoYXMg YmVlbiBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3Igc29tZSB0aW1lIHdpdGhvdXQgaXNzdWUgYW5k IHRoZSByZW1vdmFsIGNvbWVzIGFzIGNvbXBsZXRlIHVud2VsY29tZSBzdXJwcmlzZS4gR2V0dGlu ZyBhbG1vc3QgdG90YWwgcmV3cml0ZXMgb2YgdGhlIHNwZWNpZmljYXRpb24gdGhpcyBsYXRlIGlu IHRoZSByZXZpZXcgY3ljbGUgaXMgYWxzbyB2ZXJ5IGRpc3R1cmJpbmcuPG86cD48L286cD48L3A+ PHA+Jm5ic3A7PG86cD48L286cD48L3A+PHA+QSBwcm9wb3NhbCBmb3Iga2VlcGluZyB0aGUgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiB3b3VsZCBiZSB0byBzaW1wbGlmeSB0byB0aGUg Zm9sbG93aW5nOzxvOnA+PC9vOnA+PC9wPjxwPjxzcGFuIGxhbmc9RU4gc3R5bGU9J2NvbG9yOmJs YWNrJz5UaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhcmUgdXNlZCBpbiBjYXNlcyB3 aGVyZSBhIHBhc3N3b3JkIChjbGVhci10ZXh0IHNoYXJlZCBzeW1tZXRyaWMgc2VjcmV0KSBpcyB1 bnN1aXRhYmxlIG9yIGRvZXMgbm90IHByb3ZpZGUgc3VmZmljaWVudCBzZWN1cml0eSBmb3IgY2xp ZW50IGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBwcm92 aWRlIGFuIGV4dGVuc2libGUgbWVjaGFuaXNtIHRvIHVzZSBhbiBhc3NlcnRpb24gZm9ybWF0IHN1 cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0aW9uIG9m IHRoZSBjbGllbnQuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBsYW5nPUVOIHN0eWxl PSdjb2xvcjpibGFjayc+VXNpbmcgYXNzZXJ0aW9ucyByZXF1aXJlcyB0aGUgY2xpZW50IHRvIG9i dGFpbiBhbiBhc3NlcnRpb24gKHN1Y2ggYXMgYSA8L3NwYW4+PGEgaHJlZj0iIzEyZGJmOWQyOWEy ZWU3Y2RfT0FTSVMuc2FtbC1jb3JlLTIuMC1vcyI+PHNwYW4gbGFuZz1FTiBzdHlsZT0ndGV4dC1k ZWNvcmF0aW9uOm5vbmUnPlNBTUwgKENhbnRvciwgUy4sIEtlbXAsIEouLCBQaGlscG90dCwgUi4s IGFuZCBFLiBNYWxlciwg4oCcQXNzZXJ0aW9ucyBhbmQgUHJvdG9jb2wgZm9yIHRoZSBPQVNJUyBT ZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdlIChTQU1MKSBWMi4wLOKAnSBNYXJjaCZu YnNwOzIwMDUuKTwvc3Bhbj48L2E+PHNwYW4gbGFuZz1FTiBzdHlsZT0nY29sb3I6YmxhY2snPiBb T0FTSVMuc2FtbOKAkWNvcmXigJEyLjDigJFvc10gYXNzZXJ0aW9uKSBmcm9tIGFuIGFzc2VydGlv biBpc3N1ZXIgb3IgdG8gc2VsZi1pc3N1ZSBhbiBhc3NlcnRpb24uIFRoZSBhc3NlcnRpb24gZm9y bWF0LCB0aGUgcHJvY2VzcyBieSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlzIG9idGFpbmVkLCBhbmQg dGhlIG1ldGhvZCBvZiB2YWxpZGF0aW5nIHRoZSBhc3NlcnRpb24gYXJlIGRlZmluZWQgYnkgdGhl IGFzc2VydGlvbiBpc3N1ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIGFyZSBi ZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4gPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPjxwPjxzcGFuIGxhbmc9RU4gc3R5bGU9J2NvbG9yOmJsYWNrJz5XaGVuIHVzaW5nIGEgY2xp ZW50IGFzc2VydGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFtZXRl cnM6IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDo2MC4wcHQ7bWFyZ2luLWxlZnQ6NjAuMHB0 Jz48c3BhbiBsYW5nPUVOIHN0eWxlPSdjb2xvcjpibGFjayc+Y2xpZW50X2Fzc2VydGlvbl90eXBl IC0gUkVRVUlSRUQuIFRoZSBmb3JtYXQgb2YgdGhlIGFzc2VydGlvbiBhcyBkZWZpbmVkIGJ5IHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlIHZhbHVlIE1VU1QgYmUgYW4gYWJzb2x1dGUgVVJJ LiA8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoy NC4wcHQ7dGV4dC1pbmRlbnQ6LjVpbic+PHNwYW4gbGFuZz1FTiBzdHlsZT0nY29sb3I6YmxhY2sn PmNsaWVudF9hc3NlcnRpb24gLSBSRVFVSVJFRC4gVGhlIGNsaWVudCBhc3NlcnRpb24uIDwvc3Bh bj48bzpwPjwvbzpwPjwvcD48cD48c3BhbiBsYW5nPUVOIHN0eWxlPSdjb2xvcjpibGFjayc+Rm9y IGV4YW1wbGUsIHRoZSBjbGllbnQgc2VuZHMgdGhlIGZvbGxvd2luZyBhY2Nlc3MgdG9rZW4gcmVx dWVzdCB1c2luZyBhIFNBTUwgMi4wIGFzc2VydGlvbiB0byBhdXRoZW50aWNhdGUgaXRzZWxmIChs aW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6IDwvc3Bhbj48bzpwPjwv bzpwPjwvcD48cHJlIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDoy NC4wcHQ7bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6NjAuMHB0O21hcmdpbi1ib3R0b206 LjAwMDFwdCc+PHNwYW4gbGFuZz1FTj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJl IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2lu LWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6NjAuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNw YW4gbGFuZz1FTj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlPjxzcGFuIGxhbmc9 RU4+Jm5ic3A7IFBPU1QgL3Rva2VuIEhUVFAvMS4xPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHBy ZSBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdp bi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxz cGFuIGxhbmc9RU4+Jm5ic3A7IEhvc3Q6IDxhIGhyZWY9Imh0dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5j b20iIHRhcmdldD0iX2JsYW5rIj5zZXJ2ZXIuZXhhbXBsZS5jb208L2E+PC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOPiZuYnNwOyBDb250ZW50LVR5cGU6IGFwcGxpY2F0 aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PHNw YW4gbGFuZz1FTj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlPjxzcGFuIGxhbmc9 RU4+Jm5ic3A7IGdyYW50X3R5cGU9YXV0aG9yaXphdGlvbl9jb2RlJmFtcDtjb2RlPWkxV3NSbjF1 QjEmYW1wOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTj4mbmJzcDsg Y2xpZW50X2Fzc2VydGlvbj1QSE5oYld4d09sWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHkuLi5dWlQ0 JTNEJmFtcDs8L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlPjxzcGFuIGxhbmc9RU4+Jm5ic3A7 IGNsaWVudF9hc3NlcnRpb25fdHlwZT0gJm5ic3A7dXJuJTNBb2FzaXMlM0FuYW1lcyVzQXRjJTNB U0FNTCUzQTIuMCUzQWFzc2VydGlvbiZhbXA7cmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xp ZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHByZSBzdHls ZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1ib3R0 b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxh bmc9RU4+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+PHA+Jm5ic3A7PG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBzdHlsZT0n Y29sb3I6IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxiPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5vYXV0aC1ib3VuY2VzQGlldGYu b3JnPC9hPl0gPGI+T24gQmVoYWxmIE9mIDwvYj5FcmFuIEhhbW1lci1MYWhhdjxicj48Yj5TZW50 OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDE0LCAyMDExIDEwOjQ1IFBNPGJyPjxiPlRvOjwvYj4gT0F1 dGggV0c8YnI+PGI+U3ViamVjdDo8L2I+IFtPQVVUSC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2Vy dGlvbiBDcmVkZW50aWFsczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byc+SSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3Qgd2UgZHJvcCB0aGUgY2xpZW50IGFzc2Vy dGlvbiBjcmVkZW50aWFscyAoLTExIHNlY3Rpb24gMy4yKSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9u LCBhbmQgaWYgbmVlZGVkLCBwdWJsaXNoIGl0IGFzIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiBm b3IgdGhlIGZvbGxvd2luZyByZWFzb25zOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8nPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwPjEuPHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo3LjBw dCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5UaGUgbWVjaGFu aXNtIGlzIHVuZGVyIHNwZWNpZmllZCwgZXNwZWNpYWxseSBpbiBpdHMgaGFuZGxpbmcgb2YgdGhl IGNsaWVudF9pZCBpZGVudGlmaWVyICh3aGVuIHVzZWQgdG8gb2J0YWluIGVuZC11c2VyIGF1dGhv cml6YXRpb24pLiBJdCBkb2VzIG5vdCBjb250YWluIGFueSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxz IHRvIGFjY29tcGxpc2ggYW55IGxldmVsIG9mIGludGVyb3BlcmFiaWxpdHkgb3IgZnVuY3Rpb25h bGl0eS4gVGhpcyBpcyBpbiBjb250cmFzdCB0byB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUgd2hp Y2ggaGFzIG1hdHVyZWQgb3ZlciBhIHllYXIgaW50byBhIGZ1bGx5IHRob3VnaHQtb3V0IGV4dGVu c2lvbiBtZWNoYW5pc20sIGFzIHdlbGwgYXMgYSBzZXBhcmF0ZSBTQU1MIGFzc2VydGlvbiBzcGVj aWZpY2F0aW9uIHdpdGggYWN0aXZlIGRlcGxveW1lbnQgKHRoZSB0d28sIHRvZ2V0aGVyIHdpdGgg cnVubmluZyBjb2RlLCBzaG93IGNsZWFyIGNvbnNlbnN1cykuPG86cD48L286cD48L3A+PHA+Mi48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjcuMHB0Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPlRoZSBzZWN0aW9uIGlzIGEgY29uZnVzZWQgbWl4IG9mIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNwcmlua2xlZCB3aXRoIG5vcm1hdGl2ZSBsYW5ndWFnZS4gSW5zdGVh ZCwgaXQgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggZ3VpZGVsaW5lcyBmb3IgZXh0ZW5kaW5nIHRo ZSBzZXQgb2Ygc3VwcG9ydGVkIGNsaWVudCBjcmVkZW50aWFscywgYnV0IHdpdGhvdXQgZGVmaW5p bmcgYSBuZXcgcmVnaXN0cnkuIEl0IGlzIGNsZWFybHkgYW4gYXJlYSBvZiBsaXR0bGUgZGVwbG95 bWVudCBleHBlcmllbmNlIGZvciBPQXV0aCwgYW5kIHRoYXQgaW5jbHVkZXMgdXNpbmcgSFRUUCBC YXNpYyBhdXRoZW50aWNhdGlvbiBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIChtb3JlIG9uIHRo YXQgdG8gY29tZSkuPG86cD48L286cD48L3A+PHA+My48c3BhbiBzdHlsZT0nZm9udC1zaXplOjcu MHB0Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPlRoZSBzZWN0 aW9uIGhhcyByZWNlaXZlZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24u IFRob3NlIHdobyBzdGlsbCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90 IG9ubHkgY29uc2Vuc3VzIGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5 IHN1cHBvcnQgZm9yIGRlcGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsIGFs c28gcmVxdWlyZSBzaG93aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9m aWxpbmcgdGhlIG1lY2hhbmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS48 bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz5Db21tZW50cz8gQ291bnRlci1hcmd1bWVudHM/PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+RUhMPG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7 PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+Jm5ic3A7PG86cD48L286cD48L3A+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjEyLjBwdCc+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPk9BdXRoIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86T0F1dGhA aWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PC9ib2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62513P3PW5EX1MB01E_-- From mscurtescu@google.com Tue Jan 25 18:23:44 2011 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 E391A3A6900 for ; Tue, 25 Jan 2011 18:23:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.794 X-Spam-Level: X-Spam-Status: No, score=-105.794 tagged_above=-999 required=5 tests=[AWL=0.183, 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 9mXRyaKLDKmP for ; Tue, 25 Jan 2011 18:23:44 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id DCC1F3A68FD for ; Tue, 25 Jan 2011 18:23:43 -0800 (PST) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p0Q2QgpV002267 for ; Tue, 25 Jan 2011 18:26:42 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296008802; bh=BWaR7KDS9adXW6c5Of77pPlE8tk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=cS6YhRQ07vMpl6YPtIGolbC0m7qWRAwt10hVy7QpU6GcrMgp7509mg5Zcja3Wogdq XdFoVioOc1azifJw5Wakg== Received: from yws5 (yws5.prod.google.com [10.192.19.5]) by hpaq1.eem.corp.google.com with ESMTP id p0Q2QO9m020008 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 25 Jan 2011 18:26:40 -0800 Received: by yws5 with SMTP id 5so3271310yws.15 for ; Tue, 25 Jan 2011 18:26:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=dQfugHRwMk4+hsdv8OivpfzRJsBpY4Zf/iJEmSkaR0Q=; b=ZAzMQFZozo3RrM+SoWK0x7IyKCdLJ/yUwCM3FIuuYJPQ57Bks4pcYNYqM6321dD/Zm l009EHuAPjzigoDYzt0w== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=rpsofXJRafFbzcenHhxhP02DrK5mwk4w5dRX2CTW/BjUW3EqZBcsSqbLIMjGVOgxcE O2KjR9eur2Lk+8b0g+Pw== Received: by 10.100.163.6 with SMTP id l6mr4619252ane.10.1296008800519; Tue, 25 Jan 2011 18:26:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Tue, 25 Jan 2011 18:26:20 -0800 (PST) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Tue, 25 Jan 2011 18:26:20 -0800 Message-ID: To: Mike Jones Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 02:23:45 -0000 On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones wrote: > I=92d like a sense from the working group whether others want this change= , and > if so, what the name should be changed to. Probably this was debated, but I will ask again. Why can't we use "OAuth2" as the scheme in all cases and require a token_type name/value pair? Is it wise to dump lots of new schemes in a name space we do not control? Marius From wmills@yahoo-inc.com Tue Jan 25 18:33:27 2011 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 27EB43A6917 for ; Tue, 25 Jan 2011 18:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.379 X-Spam-Level: X-Spam-Status: No, score=-17.379 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, 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 KVQoSDeLTfYv for ; Tue, 25 Jan 2011 18:33:25 -0800 (PST) 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 D8B923A6916 for ; Tue, 25 Jan 2011 18:33:25 -0800 (PST) Received: from SP2-EX07CAS03.ds.corp.yahoo.com (sp2-ex07cas03.corp.sp2.yahoo.com [98.137.59.35]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0Q2YopP063495; Tue, 25 Jan 2011 18:34:50 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS03.ds.corp.yahoo.com ([98.137.59.35]) with mapi; Tue, 25 Jan 2011 18:34:50 -0800 From: William Mills To: Marius Scurtescu , Mike Jones Date: Tue, 25 Jan 2011 18:34:48 -0800 Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu9AJ0Wrym68pXZSxejyZFTGj8XXQAADr0w Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 02:33:27 -0000 As I remember there was serious objection by a few to putting versioning in= the scheme name. OAuth, OAuth2, and soon we're on OAuthN+1 seemed to be t= he objection. Some are passionate about it and no one was sufficiently pas= sionate about going with OAuth2 and some kind of token_type. Logically token_type doesn't actually fully describe the possibilities, sin= ce we can extend to signed requests etc that don't include a token per se. So... since the extensions were going to be broken out into their own spec= s, I believe the thought was to have those specs define their own namespace= s. There is certainly a land grab problem there on the scheme namespace. I personally don't have a preference, but it does seem cleaner to me to hav= e an IANA style registry for the OAuth2 auth_subtype=3D or some such. -bill > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Tuesday, January 25, 2011 6:26 PM > To: Mike Jones > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bear token scheme name >=20 > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones > wrote: > > I'd like a sense from the working group whether others want this > change, and > > if so, what the name should be changed to. >=20 > Probably this was debated, but I will ask again. >=20 > Why can't we use "OAuth2" as the scheme in all cases and require a > token_type name/value pair? >=20 > Is it wise to dump lots of new schemes in a name space we do not > control? >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Tue Jan 25 18:37:37 2011 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 9B8453A6847 for ; Tue, 25 Jan 2011 18:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.538 X-Spam-Level: X-Spam-Status: No, score=-17.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, 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 rOmIiumlbqHd for ; Tue, 25 Jan 2011 18:37:36 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id E7E5B3A6900 for ; Tue, 25 Jan 2011 18:37:36 -0800 (PST) Received: from SP2-EX07CAS01.ds.corp.yahoo.com (sp2-ex07cas01.corp.sp2.yahoo.com [98.137.59.37]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0Q2eLHj098514; Tue, 25 Jan 2011 18:40:21 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS01.ds.corp.yahoo.com ([98.137.59.37]) with mapi; Tue, 25 Jan 2011 18:40:21 -0800 From: William Mills To: William Mills , Marius Scurtescu , Mike Jones Date: Tue, 25 Jan 2011 18:40:20 -0800 Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu9AJ0Wrym68pXZSxejyZFTGj8XXQAADr0wAABZQ8A= Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 02:37:37 -0000 Also it's possible that extensions will define an authentication scheme whi= ch is available through Oauth2 and also through other pathways. It might b= e you can obtain a MAC token through a flow other than OAuth. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of William Mills > Sent: Tuesday, January 25, 2011 6:35 PM > To: Marius Scurtescu; Mike Jones > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bear token scheme name >=20 > As I remember there was serious objection by a few to putting > versioning in the scheme name. OAuth, OAuth2, and soon we're on > OAuthN+1 seemed to be the objection. Some are passionate about it and > no one was sufficiently passionate about going with OAuth2 and some > kind of token_type. >=20 > Logically token_type doesn't actually fully describe the possibilities, > since we can extend to signed requests etc that don't include a token > per se. >=20 > So... since the extensions were going to be broken out into their own > specs, I believe the thought was to have those specs define their own > namespaces. There is certainly a land grab problem there on the scheme > namespace. >=20 > I personally don't have a preference, but it does seem cleaner to me to > have an IANA style registry for the OAuth2 auth_subtype=3D or some such. >=20 > -bill >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > Of Marius Scurtescu > > Sent: Tuesday, January 25, 2011 6:26 PM > > To: Mike Jones > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] Bear token scheme name > > > > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones > > wrote: > > > I'd like a sense from the working group whether others want this > > change, and > > > if so, what the name should be changed to. > > > > Probably this was debated, but I will ask again. > > > > Why can't we use "OAuth2" as the scheme in all cases and require a > > token_type name/value pair? > > > > Is it wise to dump lots of new schemes in a name space we do not > > control? > > > > Marius > > _______________________________________________ > > OAuth mailing 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 Jan 25 21:57:06 2011 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 DF65D3A6935 for ; Tue, 25 Jan 2011 21:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 OH0Jm106oHL7 for ; Tue, 25 Jan 2011 21:57:06 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EB97C3A6843 for ; Tue, 25 Jan 2011 21:57:05 -0800 (PST) Received: (qmail 8074 invoked from network); 26 Jan 2011 06:00:04 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 06:00:04 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 25 Jan 2011 22:59:25 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Tue, 25 Jan 2011 22:59:08 -0700 Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu9AHz9w4u+KsqVRLasjjuxUxlIPQAHMvNQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 05:57:07 -0000 Simply because authentication is not what OAuth is about. OAuth is an authorization protocol for issuing access tokens. Access tokens= can have different properties and therefore need different schemes. I was = the first to suggest a scheme with sub-schemes but that idea was strongly r= ejected (over a year ago). Since then I came to the same conclusion that th= e proper way is to define separate authentication schemes. It is also how m= ost HTTP authentication framework operate. One benefit to this approach is that HTTP authentication already covers the= discovery of which schemes are supported by the resource server, as well a= s token schemes can be used independently from OAuth, something the 2-legge= d OAuth 1.0 has shown has great value. Also, it keeps the protocol modular = which enable providers to tailor it to their security needs. OAuth 2.0 is authentication agnostic and must remain so. It is an authoriza= tion protocol and as such has no business defining authentication mechanism= s. For this reason, I object to using the OAuth2 scheme name with the bearer t= oken scheme. It's a "trademark" issue. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Tuesday, January 25, 2011 6:26 PM > To: Mike Jones > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bear token scheme name >=20 > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones > wrote: > > I'd like a sense from the working group whether others want this > > change, and if so, what the name should be changed to. >=20 > Probably this was debated, but I will ask again. >=20 > Why can't we use "OAuth2" as the scheme in all cases and require a > token_type name/value pair? >=20 > Is it wise to dump lots of new schemes in a name space we do not control? >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Michael.Jones@microsoft.com Tue Jan 25 22:04:28 2011 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 0E3A33A6843 for ; Tue, 25 Jan 2011 22:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.589 X-Spam-Level: X-Spam-Status: No, score=-10.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, 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 HZwiOLx51he1 for ; Tue, 25 Jan 2011 22:04:27 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 1BEA33A691C for ; Tue, 25 Jan 2011 22:04:27 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 25 Jan 2011 22:07:26 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0255.003; Tue, 25 Jan 2011 22:07:26 -0800 From: Mike Jones To: Eran Hammer-Lahav , Marius Scurtescu Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu3pr1t3syl2UOrRViF4qH3Mgl/vQAXVc0QAU/ZFQAAB26UAAAQlxCw Date: Wed, 26 Jan 2011 06:07:26 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246F7987@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.123.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 06:04:28 -0000 To the extent that the OAuth2 protocols are intended to provide an end-to-e= nd solution, the more consistency the better, hence the "OAuth2" name. Sin= ce the same feature used the "OAuth" name in draft 10 (which you authored),= I find it hard to take seriously your objections to the "OAuth2" name in t= he bearer token spec, when the description of the feature is exactly the sa= me (and which you actually wrote).=20 -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of E= ran Hammer-Lahav Sent: Tuesday, January 25, 2011 9:59 PM To: Marius Scurtescu Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name Simply because authentication is not what OAuth is about. OAuth is an authorization protocol for issuing access tokens. Access tokens= can have different properties and therefore need different schemes. I was = the first to suggest a scheme with sub-schemes but that idea was strongly r= ejected (over a year ago). Since then I came to the same conclusion that th= e proper way is to define separate authentication schemes. It is also how m= ost HTTP authentication framework operate. One benefit to this approach is that HTTP authentication already covers the= discovery of which schemes are supported by the resource server, as well a= s token schemes can be used independently from OAuth, something the 2-legge= d OAuth 1.0 has shown has great value. Also, it keeps the protocol modular = which enable providers to tailor it to their security needs. OAuth 2.0 is authentication agnostic and must remain so. It is an authoriza= tion protocol and as such has no business defining authentication mechanism= s. For this reason, I object to using the OAuth2 scheme name with the bearer t= oken scheme. It's a "trademark" issue. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20 > Of Marius Scurtescu > Sent: Tuesday, January 25, 2011 6:26 PM > To: Mike Jones > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bear token scheme name >=20 > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones=20 > wrote: > > I'd like a sense from the working group whether others want this=20 > > change, and if so, what the name should be changed to. >=20 > Probably this was debated, but I will ask again. >=20 > Why can't we use "OAuth2" as the scheme in all cases and require a=20 > token_type name/value pair? >=20 > Is it wise to dump lots of new schemes in a name space we do not control? >=20 > Marius > _______________________________________________ > OAuth mailing 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 Jan 25 22:06:56 2011 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 956C43A691C for ; Tue, 25 Jan 2011 22:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 WUn8fenQSQP5 for ; Tue, 25 Jan 2011 22:06:54 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7FCF13A6843 for ; Tue, 25 Jan 2011 22:06:54 -0800 (PST) Received: (qmail 15380 invoked from network); 26 Jan 2011 06:09:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 06:09:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Tue, 25 Jan 2011 23:09:52 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Tue, 25 Jan 2011 23:09:34 -0700 Thread-Topic: [OAUTH-WG] Why give the redirect URI when trading an [authorization] code for an access token? Thread-Index: ActRh3OATlTUyqLqQImrl3NtjQIBSAAOjOOQAHYMshAaYWTaAA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62540@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <59DD1BA8FD3C0F4C90771C18F2B5B53A6532547F10@GVW0432EXB.americas.hpqcorp.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F3F0703@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C8B3721.7000208@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F3F0A42@P3PW5EX1MB01.EX1.SECURESERVER.NET> <59DD1BA8FD3C0F4C90771C18F2B5B53A6532D8358E@GVW0432EXB.americas.hpqcorp.net> In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A6532D8358E@GVW0432EXB.americas.hpqcorp.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Why give the redirect URI when trading an [authorization] code for an access token? 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, 26 Jan 2011 06:06:56 -0000 I found this in my archives as an open question. Can someone please review = Tim's note and address the security considerations it contains? EHL > -----Original Message----- > From: Freeman, Tim [mailto:tim.freeman@hp.com] > Sent: Tuesday, September 14, 2010 11:03 AM > To: Eran Hammer-Lahav; Torsten Lodderstedt > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] Why give the redirect URI when trading an > [authorization] code for an access token? >=20 > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > 1. Evil user starts the OAuth flow on the client using the web-server f= low. > > 2. Client redirects the evil user to the authorization server, > > including state information about the evil user account on the client. > > 3. Evil user takes the authorization endpoint URI and changes the > > redirection to its own site. > > 4. Evil user tricks victim user to click on the link and authorize > > access (phishing or other social engineering attack). > > 5. Victim user thinking this is a valid authorization request, > > authorizes access. > > 6. Authorization server sends victim user back to the client, but > > since the redirection URI was changed, back to the evil user site. >=20 > and the rest of the steps were revised to: >=20 > > 7. Evil user takes the code and gives it back to the client by > > constructing the original correct redirection URI. > > 8. Client exchanges the code for access token, attaching it to the evil= user's > account. > > 9. Evil user can now access victim user data on his client account. >=20 > Step 6 requires the authorization server to redirect the victim user's br= owser > to the evil user's site, which will only happen if the authorization serv= er does > not check the redirect URI when returning an authorization code. That ch= eck > is required by OAuth 2, and isn't the check that I'm questioning. >=20 > In contrast, I was proposing that the authorization server not check the > redirect URI when it returns an access token. Since, in the absence of s= uch a > check, the redirect URI is neither checked nor used to compute the result= of > the query, I was proposing that we drop the redirect URL from that step o= f > the protocol altogether. >=20 > I misspoke in the subject line of the email that started this thread, so = I just > now changed "access code" there to "authorization code". We have access > tokens and authorization codes, but not authorization tokens or access > codes. >=20 > After some thought, I think I see the real problem with omitting the chec= k on > redirect_uri. Without the check, the following can happen: >=20 > 1. Evil user starts OAuth flow on the client using the web-server flow, u= sing a > hacked web browser. > 2. The hacked web browser does the normal thing in the flow, requesting t= he > evil user's username and password, and at the end the hacked browser is > given a redirect like: >=20 > https://www.goodclient.com/oauth/evilUserAcct?code=3DevilAuthCode >=20 > The hacked browser saves evilAuthCode and does not perform the redirect. > 3. Suppose the evil user's web site can persuade a known victim user with= a > normal browser to visit goodclient's web site and do OAuth. The victim's= user > id on the client is public knowledge, and the evil user's web site persua= ded > the victim to start OAuth at a known time, so it can guess when the victi= m will > complete the OAuth exchange. Before then, the evil web site can visit >=20 > https://www.goodclient.com/oauth/victimUserAcct?code=3DevilAuthCode >=20 > which is likely to leave the client associating the victim's user id with= an access > token that accesses resources controlled by the evil user. >=20 > Checking the redirect URI doesn't solve the problem in the case where the > user id on the client is encoded in the "state" opaque value instead of t= he > redirect URI. >=20 > Saying "The authorization server SHOULD require the client to pre-registe= r > their redirection URI" (page 17 of http://tools.ietf.org/html/draft-ietf-= oauth- > v2-10) should have MUST instead of SHOULD, since it is important that we'= re > really redirecting to the client when we're distributing the authorizatio= n code > by redirecting. >=20 > Writing the spec required thinking through these cases. It would be help= ful if > the use cases were added to the spec, so people don't have to rediscover > them, and errors in the use cases can be discovered and fixed rather than > being made repeatedly by each person rediscovering the use case. >=20 > Tim Freeman > Email: tim.freeman@hp.com > Desk in Palo Alto: (650) 857-2581 > Home: (408) 774-1298 > Cell: (408) 348-7536 >=20 >=20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Saturday, September 11, 2010 7:59 AM > To: Torsten Lodderstedt > Cc: Freeman, Tim; oauth@ietf.org > Subject: RE: [OAUTH-WG] Why give the redirect URI when trading an access > code for an access token? >=20 > Sorry. >=20 > 7. Evil user takes the code and gives it back to the client by constructi= ng the > original correct redirection URI. > 8. Client exchanges the code for access token, attaching it to the evil u= ser's > account. > 9. Evil user can now access victim user data on his client account. >=20 > This is basically a session fixation attack. >=20 > EHL >=20 > > -----Original Message----- > > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > > Sent: Saturday, September 11, 2010 1:01 AM > > To: Eran Hammer-Lahav > > Cc: Freeman, Tim; oauth@ietf.org > > Subject: Re: [OAUTH-WG] Why give the redirect URI when trading an > > access code for an access token? > > > > Doesn't step 7 require the evil user to know the client's secret? > > > > Am 10.09.2010 17:06, schrieb Eran Hammer-Lahav: > > > 1. Evil user starts the OAuth flow on the client using the web-server= flow. > > > 2. Client redirects the evil user to the authorization server, > > > including state > > information about the evil user account on the client. > > > 3. Evil user takes the authorization endpoint URI and changes the > > redirection to its own site. > > > 4. Evil user tricks victim user to click on the link and authorize > > > access > > (phishing or other social engineering attack). > > > 5. Victim user thinking this is a valid authorization request, > > > authorizes > > access. > > > 6. Authorization server sends victim user back to the client, but > > > since the > > redirection URI was changed, back to the evil user site. > > > 7. Evil user grabs the code and exchanges it for an access token. > > > > > > By checking that the callback URI used to deliver the code is the > > > same as > > the one used to initiate the flow, the authorization server can verify > > that the user who initiated the flow is the same one to authorize > > access and finish the flow. > > > > > > EHL > > > > > >> -----Original Message----- > > >> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > >> Behalf Of Freeman, Tim > > >> Sent: Wednesday, September 08, 2010 8:05 PM > > >> To: oauth@ietf.org > > >> Subject: [OAUTH-WG] Why give the redirect URI when trading an > > >> access code for an access token? > > >> > > >> Hi. I'm new here. I searched the archives a bit and didn't > > >> immediately find an answer to my question below. My apologies if > > >> there was some previous discussion of this that I missed. > > >> > > >> Looking at the draft spec at > > >> http://tools.ietf.org/html/draft-ietf-oauth-v2-10, > > >> I see in section 4.1.1 "Authorization code" on page 22 that it is > > >> required to give the redirect_uri of the original request when > > >> exchanging an authorization code for an access token, and the > > >> authorization server must verify that the redirection URI is > > >> correct as well > > as the authorization code. > > >> Based on section 4.2 "Access Token Response" on page 25, it seems > > >> that the redirect_uri is not used when constructing the response > > >> from the authorization server. > > >> > > >> So far as I can tell, the redirect_uri is useless in this request. > > >> It does not contain any secrets. The authorization code is > > >> verified and is meant to be an arbitrary unguessable identifier, so > > >> little is gained by verifying the redirect_uri also. It is not > > >> used to construct the > > reply. Why is it required? > > >> > > >> Tim Freeman > > >> Email: tim.freeman@hp.com > > >> Desk in Palo Alto: (650) 857-2581 > > >> Home: (408) 774-1298 > > >> Cell: (408) 348-7536 > > >> > > >> > > >> _______________________________________________ > > >> OAuth mailing 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 Jan 25 22:25:04 2011 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 DEE6F3A6932 for ; Tue, 25 Jan 2011 22:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 vEFGMtybYL11 for ; Tue, 25 Jan 2011 22:25:00 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E6CE03A6843 for ; Tue, 25 Jan 2011 22:24:59 -0800 (PST) Received: (qmail 7760 invoked from network); 26 Jan 2011 06:27:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 06:27:59 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 25 Jan 2011 23:27:29 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Tue, 25 Jan 2011 23:27:12 -0700 Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu3pr1t3syl2UOrRViF4qH3Mgl/vQAXVc0QAU/ZFQAAB26UAAAQlxCwACD5gsA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62541@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246F7987@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246F7987@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 06:25:04 -0000 Since you are a recent addition to the working group, you probably don't kn= ow that I objected to using both the OAuth and OAuth2 scheme names and want= ed to call the scheme name Token. Producing a generally applicable HTTP aut= hentication scheme is actually in our original charter and was one of the g= oals. Calling it OAuth2 is not generally applicable. As for the end-to-end solution, it was never intended to be (nor can it), w= ith or without the bearer token addition. OAuth is a single (authorization)= protocol. The bearer token is a separate protocol with an OAuth2 binding, = as is the MAC authentication scheme. For 10 drafts, the bearer token language was part of the document I edited.= I don't think anyone has any doubts regarding my disagreement with it thro= ughout the process. I am pretty sure I also made it clear when I spent an h= our on the phone helping get started on the draft, including explicitly tel= ling you that the scheme name is an open issue you need to approach the wor= king group about. And speaking of being taken seriously, you can't be serious suggesting that= my editorial role obliges me to subscribe to any views expressed in a work= ing group document. EHL > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Tuesday, January 25, 2011 10:07 PM > To: Eran Hammer-Lahav; Marius Scurtescu > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Bear token scheme name >=20 > To the extent that the OAuth2 protocols are intended to provide an end-to= - > end solution, the more consistency the better, hence the "OAuth2" name. > Since the same feature used the "OAuth" name in draft 10 (which you > authored), I find it hard to take seriously your objections to the "OAuth= 2" > name in the bearer token spec, when the description of the feature is > exactly the same (and which you actually wrote). >=20 > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Tuesday, January 25, 2011 9:59 PM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bear token scheme name >=20 > Simply because authentication is not what OAuth is about. >=20 > OAuth is an authorization protocol for issuing access tokens. Access toke= ns > can have different properties and therefore need different schemes. I was > the first to suggest a scheme with sub-schemes but that idea was strongly > rejected (over a year ago). Since then I came to the same conclusion that= the > proper way is to define separate authentication schemes. It is also how m= ost > HTTP authentication framework operate. >=20 > One benefit to this approach is that HTTP authentication already covers t= he > discovery of which schemes are supported by the resource server, as well = as > token schemes can be used independently from OAuth, something the 2- > legged OAuth 1.0 has shown has great value. Also, it keeps the protocol > modular which enable providers to tailor it to their security needs. >=20 > OAuth 2.0 is authentication agnostic and must remain so. It is an > authorization protocol and as such has no business defining authenticatio= n > mechanisms. >=20 > For this reason, I object to using the OAuth2 scheme name with the bearer > token scheme. It's a "trademark" issue. >=20 > EHL >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Marius Scurtescu > > Sent: Tuesday, January 25, 2011 6:26 PM > > To: Mike Jones > > Cc: OAuth WG > > Subject: Re: [OAUTH-WG] Bear token scheme name > > > > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones > > wrote: > > > I'd like a sense from the working group whether others want this > > > change, and if so, what the name should be changed to. > > > > Probably this was debated, but I will ask again. > > > > Why can't we use "OAuth2" as the scheme in all cases and require a > > token_type name/value pair? > > > > Is it wise to dump lots of new schemes in a name space we do not contro= l? > > > > Marius > > _______________________________________________ > > OAuth mailing 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 Jan 25 22:39:21 2011 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 D0FA83A6932 for ; Tue, 25 Jan 2011 22:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 X9zsY3K0FAA5 for ; Tue, 25 Jan 2011 22:39:20 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B89B23A6937 for ; Tue, 25 Jan 2011 22:39:20 -0800 (PST) Received: (qmail 7663 invoked from network); 26 Jan 2011 06:42:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 06:42:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 25 Jan 2011 23:42:19 -0700 From: Eran Hammer-Lahav To: Phil Hunt , "oauth@ietf.org WG" Date: Tue, 25 Jan 2011 23:42:02 -0700 Thread-Topic: [OAUTH-WG] Draft 12 - Protocol flow not clear yet Thread-Index: Acu7O2k6wxTc8qCiRzeV4tB8ZRFcNQB582aA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62543@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <5A4B067E-683C-4FA0-BC9C-26BF2E1F5512@oracle.com> In-Reply-To: <5A4B067E-683C-4FA0-BC9C-26BF2E1F5512@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft 12 - Protocol flow not clear yet 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, 26 Jan 2011 06:39:21 -0000 Thanks Phil. > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Phil Hunt > Sent: Sunday, January 23, 2011 12:23 PM > To: oauth@ietf.org WG > Subject: [OAUTH-WG] Draft 12 - Protocol flow not clear yet >=20 > Section 4 seems to inter-mixes obtaining authorization grant with obtaini= ng > tokens. Yes it is called "Request an Access Token". This seems particula= rly > confusing after reading section 3 that separates requesting authorization > from token end-points. My first reaction was, is there a section missing? Section 4 describes how to ask for an access token using different grant ty= pes. Some of these grant types require an explicit authorization step. > After I began reading section 4 it starts talking about obtaining authori= zation. > Should section 4 be "protocol flow"? I don't have a strong view on the section title, but I do have a strong vie= w on its structure. > I think it can work with an intro explaining the protocol at a high level= . E.g. 3 > steps: > 1. Obtain authorization from Authorization Endpoint 2. Obtain access toke= n > from Token Endpoint 3. Access resource You mean section 1.1? I will break it into two, one for roles and the other= for protocol flow. I want to keep all the prose in the introduction and le= ave the rest only to implementation specific details. =20 > Then for each flow pattern, show how steps 1, 2, and 3 are completed. Fo= r 2- > legged cases, indicate how step 1 is completed implicitly (e.g. by policy= , > previous arrangement, or OOB). I don't think this is necessary. If the introduction isn't detailed enough,= we need to fix that. > It might also be better if section 5 became a sub-section within 4.0. I s= ee why > it is separate, since the last step is always the same. But still it adde= d to my > initial confusion. All the section 4 subsections are grant types and moving 5 there will be mo= re confusing. I will add a document overview in the introduction to cover t= his. =20 EHL From eran@hueniverse.com Tue Jan 25 22:55:34 2011 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 E51D93A68DF for ; Tue, 25 Jan 2011 22:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 vfalbeygWq2N for ; Tue, 25 Jan 2011 22:55:32 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7FF7A3A684D for ; Tue, 25 Jan 2011 22:55:32 -0800 (PST) Received: (qmail 20097 invoked from network); 26 Jan 2011 06:58:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 06:58:32 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Tue, 25 Jan 2011 23:58:32 -0700 From: Eran Hammer-Lahav To: Torsten Lodderstedt Date: Tue, 25 Jan 2011 23:58:14 -0700 Thread-Topic: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? Thread-Index: Acu8aQgAt7wjpzQ9Sqy8ZEfQ6Ugl3gAuyq5w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62544@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net><90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> In-Reply-To: <20110125092230.15123t1lj1ap0twk@webmail.df.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 26 Jan 2011 06:55:34 -0000 > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Tuesday, January 25, 2011 12:23 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokensendpoint? >=20 > Zitat von Eran Hammer-Lahav : >=20 > > There is no clean way to do with without defining new HTTP > > authentication schemes. The token endpoints takes: > > > > 1. Client authentication > > 2. Authorization grant > > > > There is no user authentication. Even the resource owner password > > credentials is not user authentication but only validation of "some > > grant values". >=20 > What's the difference from a conceptual point of view? In my opinion, the > resource owners password is used for both, authenticating the resource > owner and authorizing the token issuance. The resource owner is not present and therefore not being authenticated. Th= e grant is being validated (and it happens to be a username and password). = The client is being authenticated. IOW, the server is authenticating the pa= rty making the request. In normal client-server flow, the client is or pret= ending to be the resource owner by presenting the resource owner's credenti= als. > > > > What you can do is define an authentication scheme which will > > authenticate the client and provide the grant in one header, or >=20 > the spec makes the grant type a required parameter, so a lonely > authorization header won't be suffiencent. > > > define a new grant type for such credentials. But you can't use >=20 > That brings us back to the mix between POST parameters and authz headers > for credential transmission. Something you critized for good reasons. >=20 > > something like Basic or Digest to provide the resource owner's > > credentials. That's against the endpoint design. >=20 > It's good to know that restriction, but I'm not happy :-( So based on tha= t > information I would say, the only proper way to integrate standard HTTP > schemes would be to invent another endpoint for that purpose. The basic design is that the endpoint takes: 1. client authentication 2. authorization grant In a perfect world, #1 will always be in the Authorization header as the pr= oper HTTP method for authenticating the requestor, and #2 will always be in= the body or in another, non HTTP authentication header, as the payload of = the request. Another idea I have been toying with is to define a new HTTP request header= field which has the same exact format of the Authorization header, but jus= t with another name such as 'Delegation'. In that case, a request using HTT= P Basic for *both* client authentication and resource owner password creden= tials will look like this: GET /resource HTTP/1.1 Authorization: Basic [base64-of-client-password-credentials] Delegation: Basic [base64-of-resource-owner-password-credentials] This makes the delegation header syntax reuse everything from the Authoriza= tion header, allowing you to easily use any existing scheme you want, but c= learly identifies the role of those credentials in the request. As for comp= lying with the token endpoint required fields, that's just formality. We ca= n simply define a grant type that means "grant is provided in the delegatio= n header". EHL From eran@hueniverse.com Tue Jan 25 23:06:09 2011 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 4086B3A684D for ; Tue, 25 Jan 2011 23:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 zKdNhFtxGgEo for ; Tue, 25 Jan 2011 23:06:07 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 687943A6837 for ; Tue, 25 Jan 2011 23:06:07 -0800 (PST) Received: (qmail 24701 invoked from network); 26 Jan 2011 07:09:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 07:09:06 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 26 Jan 2011 00:08:38 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 26 Jan 2011 00:08:20 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu89LN66p08z4dDQteVDaHi1DDgdQAMeu1A Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62545@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 07:06:09 -0000 Thanks Marius. > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Tuesday, January 25, 2011 5:02 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > On Thu, Jan 20, 2011 at 9:41 PM, Eran Hammer-Lahav > wrote: > > Forgot to mention that I don't have any outstanding comments in my > queue so if your feedback was not incorporated into -12, and you feel > strongly about it, bring it up again. >=20 > From an older email, adapted to v12: >=20 >=20 > 1. The token_type parameter is required in responses from the server. > If the server supports multiple formats, which one will be used? In this = case, > would it make sense to allow the client to request a specific format? >=20 > For example, if the authorization server supports both MAC and BEARER, > which one will the server issue? It might in some cases, but I suspect most providers are going to decide wh= ich scheme provides the right level of security for them and just use that.= If you are going to allow both MAC and BEARER, you are basically letting c= lients decide which level to operate at. Do you have a need or plan to supp= ort multiple token types? =20 > 2. Section 8.2. What about applications using legacy parameters? Does not > make much sense to register them, and they cannot be changed to x_. > Broken record: using a prefix for all registered parameters is much clean= er (as > opposed to requiring that all no-registered parameters use a prefix). >=20 > For Google it is impossible to comply with this requirement. What legacy parameters do you have? Since OAuth 2.0 endpoints are brand new= , this is probably about extension parameters in the authorization endpoint= from OAuth 1.0 or AuthSub? I think the legacy parameters problem is pretty= small, given the number of existing *token* and *authorization* endpoints = with custom parameters (that were not pulled into the specification such as= scope), but it would be good to know what we are dealing with. Overall, this is a pretty minor issue. I assume you don't have any conflict= s today with the v2 specification. Any conflicts you might have in the futu= re (for which this x_ prefix is meant for) with new extensions is probably = going to be minor. And Google can always join the work to make sure they pi= ck a less conflicting name... this is where the registration process really= helps to avoid clashes. EHL From wmills@yahoo-inc.com Tue Jan 25 23:21:04 2011 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 DD8D43A693F for ; Tue, 25 Jan 2011 23:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.375 X-Spam-Level: X-Spam-Status: No, score=-17.375 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, 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 riqtknTkVTxq for ; Tue, 25 Jan 2011 23:20:59 -0800 (PST) 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 3F4453A693A for ; Tue, 25 Jan 2011 23:20:59 -0800 (PST) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0Q7N8lB003699; Tue, 25 Jan 2011 23:23:08 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Tue, 25 Jan 2011 23:23:08 -0800 From: William Mills To: Eran Hammer-Lahav , Mike Jones Date: Tue, 25 Jan 2011 23:23:06 -0800 Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu3pr1t3syl2UOrRViF4qH3Mgl/vQAXVc0QAU/ZFQAAB26UAAAQlxCwACD5gsAAQTh0YA== Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246F7987@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62541@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62541@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 07:21:04 -0000 Back to Marius' question though, which is about how we determine how to tre= at the Authenticate header when you see it. I, for one, was not happy with= the way that Wrap added on to the OAuth scheme. There are at least 3 poss= ibilities that it seems to be worth discussing: 1) a fixed scheme name with a variable indicating flavor, i.e. Oauth2 autht= ype=3Dbearer, but we could go more agnostic like "Authz type=3Dbearer" if O= Auth2 really chafes. PRO: simple namespace 2) a scheme per auth type extension: i.e. bearer, MAC, SAML, etc. \ PRO: easy to extend, in no way semantically bound to OAuth CON: namespace pollution and a proliferation of auth types 3) as yet un-discussed, we could reserve a namespace like oauth2_ and use t= hings like oauth2_bearer. 2 and 3 are not exclusive. Are there more? =20 There's also discussion that this is authorization, not authentication, and= if we really want to go there then the source of the problem might be that= we're choosing to overload the Authenticate header. Even more muddy, it's= entirely possible that a bearer token might contain a user credential. > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > > Of Marius Scurtescu > > > Sent: Tuesday, January 25, 2011 6:26 PM > > > To: Mike Jones > > > Cc: OAuth WG > > > Subject: Re: [OAUTH-WG] Bear token scheme name > > > > > > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones > > > wrote: > > > > I'd like a sense from the working group whether others want this > > > > change, and if so, what the name should be changed to. > > > > > > Probably this was debated, but I will ask again. > > > > > > Why can't we use "OAuth2" as the scheme in all cases and require a > > > token_type name/value pair? > > > > > > Is it wise to dump lots of new schemes in a name space we do not > control? > > > > > > Marius > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Jan 26 00:45:51 2011 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 696A628C0CF for ; Wed, 26 Jan 2011 00:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 sHKMrZ3kcNtS for ; Wed, 26 Jan 2011 00:45:50 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 565B83A6958 for ; Wed, 26 Jan 2011 00:45:50 -0800 (PST) Received: (qmail 10281 invoked from network); 26 Jan 2011 08:48:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 08:48:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Wed, 26 Jan 2011 01:48:49 -0700 From: Eran Hammer-Lahav To: William Mills Date: Wed, 26 Jan 2011 01:48:31 -0700 Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu3pr1t3syl2UOrRViF4qH3Mgl/vQAXVc0QAU/ZFQAAB26UAAAQlxCwACD5gsAAQTh0YAB98x9Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246F7987@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62541@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 08:45:51 -0000 Thanks William. It is important to differentiate between style and substance (both of which= are very important to people). Style-wise, we can use either of the three options below, but they are esse= ntially the same. You take the string and put it through a parser and end u= p with the actual scheme name and some attributes. I don't really buy the a= rguments about namespaces and pollution. Creating a super scheme that then has to be extended for sub-schemes is act= ually a lot more complex. AFAIK, all the existing HTTP authentication schem= es are not extensible (or at least have not been extended). There is someth= ing very helpful in moving extensibility out of the scheme so that a client= that can speak it today can also speak it 10 years from now. If you need n= ew options, create a new scheme. I like the scheme-per-type approach because it is modular and does not requ= ire much coordination. The lack of consensus we've seen between bearer toke= ns and mac tokens is an example. I don't want to have to negotiate paramete= r names and other formats when such collaboration will just slow both effor= ts and lead to no meaningful interoperability (given that the two token typ= es are completely incompatible). The HTTP authentication headers are named poorly. The WWW-Authenticate mean= s 'you need to authenticate' and the Authorization header means 'here is my= authentication credentials'. There is no actual authorization as implement= ed by OAuth (in terms of third party and grants). When talking about using = a token to access a protected resource, we are dealing exclusively with aut= hentication and should use the right HTTP vehicle for that. EHL > -----Original Message----- > From: William Mills [mailto:wmills@yahoo-inc.com] > Sent: Tuesday, January 25, 2011 11:23 PM > To: Eran Hammer-Lahav; Mike Jones > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Bear token scheme name >=20 > Back to Marius' question though, which is about how we determine how to > treat the Authenticate header when you see it. I, for one, was not happy > with the way that Wrap added on to the OAuth scheme. There are at least = 3 > possibilities that it seems to be worth discussing: >=20 > 1) a fixed scheme name with a variable indicating flavor, i.e. Oauth2 > authtype=3Dbearer, but we could go more agnostic like "Authz type=3Dbeare= r" if > OAuth2 really chafes. >=20 > PRO: simple namespace >=20 > 2) a scheme per auth type extension: i.e. bearer, MAC, SAML, etc. \ >=20 > PRO: easy to extend, in no way semantically bound to OAuth > CON: namespace pollution and a proliferation of auth types >=20 > 3) as yet un-discussed, we could reserve a namespace like oauth2_ and use > things like oauth2_bearer. >=20 > 2 and 3 are not exclusive. Are there more? >=20 > There's also discussion that this is authorization, not authentication, a= nd if we > really want to go there then the source of the problem might be that we'r= e > choosing to overload the Authenticate header. Even more muddy, it's > entirely possible that a bearer token might contain a user credential. >=20 >=20 > > > > -----Original Message----- > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > Behalf > > > > Of Marius Scurtescu > > > > Sent: Tuesday, January 25, 2011 6:26 PM > > > > To: Mike Jones > > > > Cc: OAuth WG > > > > Subject: Re: [OAUTH-WG] Bear token scheme name > > > > > > > > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones > > > > wrote: > > > > > I'd like a sense from the working group whether others want this > > > > > change, and if so, what the name should be changed to. > > > > > > > > Probably this was debated, but I will ask again. > > > > > > > > Why can't we use "OAuth2" as the scheme in all cases and require a > > > > token_type name/value pair? > > > > > > > > Is it wise to dump lots of new schemes in a name space we do not > > control? > > > > > > > > Marius > > > > _______________________________________________ > > > > OAuth mailing list > > > > OAuth@ietf.org > > > > https://www.ietf.org/mailman/listinfo/oauth From SRS0=gERVnA=UY=lodderstedt.net=torsten@srs.bis7.eu.blackberry.com Wed Jan 26 00:42:09 2011 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 46C0D3A697A for ; Wed, 26 Jan 2011 00:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.35 X-Spam-Level: X-Spam-Status: No, score=-3.35 tagged_above=-999 required=5 tests=[AWL=1.496, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 FGqW2Tlq0iq3 for ; Wed, 26 Jan 2011 00:42:08 -0800 (PST) Received: from smtp01.bis7.eu.blackberry.com (smtp01.bis7.eu.blackberry.com [178.239.85.6]) by core3.amsl.com (Postfix) with ESMTP id 720F43A6958 for ; Wed, 26 Jan 2011 00:42:06 -0800 (PST) Received: from b1.c11.bise7.blackberry ([192.168.0.101]) by srs.bis7.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id p0Q8j5r2003205; Wed, 26 Jan 2011 08:45:05 GMT Received: from ups31.c11.bise7.blackberry (cmp31.c11.bise7.blackberry [172.18.204.201]) by b1.c11.bise7.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id p0Q8j2Ru011363; Wed, 26 Jan 2011 08:45:02 GMT X-rim-org-msg-ref-id: 1094924962 Message-ID: <1094924962-1296031502-cardhu_decombobulator_blackberry.rim.net-1267267110-@b1.c11.bise7.blackberry> Content-Transfer-Encoding: base64 X-Priority: Normal References: <4D3DEAAA.6070201@lodderstedt.net><90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET><1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry><90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET><20110125092230.15123t1lj1ap0twk@webmail.df.eu> In-Reply-To: Sensitivity: Normal Importance: Normal To: "Brian Eaton" From: torsten@lodderstedt.net Date: Wed, 26 Jan 2011 08:45:02 +0000 Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: torsten@lodderstedt.net List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jan 2011 08:46:38 -0000 SGkgQnJpYW4sDQoNCnlvdSBpZGVudGlmaWVkIHRoZSB1c2UgY2FzZXMgY29ycmVjdGx5LiBObyBp bnRlcmFjdGl2ZSB1c2VyLWNvbnNlbnQgd291bGQgYmUgcmVxdWlyZWQuDQoNClJlZ2FyZHMsDQpU b3JzdGVuLg0KR2VzZW5kZXQgbWl0IEJsYWNrQmVycnmuIFdlYm1haWwgdm9uIFRlbGVrb20gRGV1 dHNjaGxhbmQgIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRWF0 b24gPGJlYXRvbkBnb29nbGUuY29tPg0KRGF0ZTogVHVlLCAyNSBKYW4gMjAxMSAwOTo1MzoyMCAN ClRvOiBUb3JzdGVuIExvZGRlcnN0ZWR0PHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0Pg0KQ2M6IEVy YW4gSGFtbWVyLUxhaGF2PGVyYW5AaHVlbml2ZXJzZS5jb20+OyBPQXV0aCBXRzxvYXV0aEBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEhvdyB0byBpbnRlZ3JhdGVkIERJR0VTVCBv ciBTUE5FR08gd2l0aCB0b2tlbnNlbmRwb2ludD8NCg0KSGV5IFRvcnN0ZW4gLQ0KDQpJJ20gdHJ5 aW5nIHRvIHBhcnNlIHRocm91Z2ggdGhlc2UgbWVzc2FnZXMgdG8gZmlndXJlIG91dCB0aGUgZmxv d3MNCnlvdSdyZSBpbnRlcmVzdGVkIGluLg0KDQpJIHRoaW5rIHlvdSdyZSBhaW1pbmcgZm9yIHJ1 bGVzIGxpa2UgdGhpcyBvbmUsIHJpZ2h0Pw0KDQprZXJiZXJvcyBhdXRoZW50aWNhdGlvbiAtPiBh Y2Nlc3MgdG9rZW4NCg0KICAgIG9yDQoNCmRpZ2VzdCBhdXRoZW50aWNhdGlvbiAtPiBhY2Nlc3Mg dG9rZW4NCg0KQW5kIGZ1cnRoZXJtb3JlIHlvdXIgaW50ZW5kZWQgdXNlIGNhc2VzIGFyZSBhcHBs aWNhdGlvbnMgaW5zdGFsbGVkIG9uDQphbiBlbmQtdXNlcnMgbWFjaGluZSwgd2hlcmUgdGhlIGVu ZC11c2VycyBtYWNoaW5lIHBhcnRpY2lwYXRlcyBpbiBzb21lDQpraW5kIG9mIGF1dGhlbnRpY2F0 aW9uIHNlcnZpY2UuICBGb3IgZXhhbXBsZSwgbWF5YmUgdGhlIG1hY2hpbmUgaXMNCmpvaW5lZCB0 byBzb21lIGtlcmJlcm9zIHJlYWxtLCBvciBtYXliZSB0aGUgdXNlciBoYXMgYSBzbWFydCBjYXJk Lg0KDQpIYXZlIEkgaWRlbnRpZmllZCB0aGUgdXNlIGNhc2VzIHByb3Blcmx5PyAgT3IgYXJlIHlv dSBkZWFsaW5nIHdpdGgNCnRocmVlLWxlZ2dlZCBPQXV0aCBzaXR1YXRpb25zLCB3aGVyZSB5b3Ug YWN0dWFsbHkgd2FudCB1c2VyIGNvbnNlbnQgb24NCmEgd2ViIHBhZ2U/DQoNCkNoZWVycywNCkJy aWFuDQoNCk9uIFR1ZSwgSmFuIDI1LCAyMDExIGF0IDEyOjIyIEFNLCBUb3JzdGVuIExvZGRlcnN0 ZWR0DQo8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+IHdyb3RlOg0KPiBaaXRhdCB2b24gRXJhbiBI YW1tZXItTGFoYXYgPGVyYW5AaHVlbml2ZXJzZS5jb20+Og0KPg0KPj4gVGhlcmUgaXMgbm8gY2xl YW4gd2F5IHRvIGRvIHdpdGggd2l0aG91dCBkZWZpbmluZyBuZXcgSFRUUCBhdXRoZW50aWNhdGlv bg0KPj4gc2NoZW1lcy4gVGhlIHRva2VuIGVuZHBvaW50cyB0YWtlczoNCj4+DQo+PiAxLiBDbGll bnQgYXV0aGVudGljYXRpb24NCj4+IDIuIEF1dGhvcml6YXRpb24gZ3JhbnQNCj4+DQo+PiBUaGVy ZSBpcyBubyB1c2VyIGF1dGhlbnRpY2F0aW9uLiBFdmVuIHRoZSByZXNvdXJjZSBvd25lciBwYXNz d29yZA0KPj4gY3JlZGVudGlhbHMgaXMgbm90IHVzZXIgYXV0aGVudGljYXRpb24gYnV0IG9ubHkg dmFsaWRhdGlvbiBvZiAic29tZSBncmFudA0KPj4gdmFsdWVzIi4NCj4NCj4gV2hhdCdzIHRoZSBk aWZmZXJlbmNlIGZyb20gYSBjb25jZXB0dWFsIHBvaW50IG9mIHZpZXc/IEluIG15IG9waW5pb24s IHRoZQ0KPiByZXNvdXJjZSBvd25lcnMgcGFzc3dvcmQgaXMgdXNlZCBmb3IgYm90aCwgYXV0aGVu dGljYXRpbmcgdGhlIHJlc291cmNlIG93bmVyDQo+IGFuZCBhdXRob3JpemluZyB0aGUgdG9rZW4g aXNzdWFuY2UuDQo+DQo+Pg0KPj4gV2hhdCB5b3UgY2FuIGRvIGlzIGRlZmluZSBhbiBhdXRoZW50 aWNhdGlvbiBzY2hlbWUgd2hpY2ggd2lsbCBhdXRoZW50aWNhdGUNCj4+IHRoZSBjbGllbnQgYW5k IHByb3ZpZGUgdGhlIGdyYW50IGluIG9uZSBoZWFkZXIsIG9yDQo+DQo+IHRoZSBzcGVjIG1ha2Vz IHRoZSBncmFudCB0eXBlIGEgcmVxdWlyZWQgcGFyYW1ldGVyLCBzbyBhIGxvbmVseQ0KPiBhdXRo b3JpemF0aW9uIGhlYWRlciB3b24ndCBiZSBzdWZmaWVuY2VudC4NCj4NCj4+IGRlZmluZSBhIG5l dyBncmFudCB0eXBlIGZvciBzdWNoIGNyZWRlbnRpYWxzLiBCdXQgeW91IGNhbid0IHVzZQ0KPg0K PiBUaGF0IGJyaW5ncyB1cyBiYWNrIHRvIHRoZSBtaXggYmV0d2VlbiBQT1NUIHBhcmFtZXRlcnMg YW5kIGF1dGh6IGhlYWRlcnMgZm9yDQo+IGNyZWRlbnRpYWwgdHJhbnNtaXNzaW9uLiBTb21ldGhp bmcgeW91IGNyaXRpemVkIGZvciBnb29kIHJlYXNvbnMuDQo+DQo+PiBzb21ldGhpbmcgbGlrZSBC YXNpYyBvciBEaWdlc3QgdG8gcHJvdmlkZSB0aGUgcmVzb3VyY2Ugb3duZXIncw0KPj4gY3JlZGVu dGlhbHMuIFRoYXQncyBhZ2FpbnN0IHRoZSBlbmRwb2ludCBkZXNpZ24uDQo+DQo+IEl0J3MgZ29v ZCB0byBrbm93IHRoYXQgcmVzdHJpY3Rpb24sIGJ1dCBJJ20gbm90IGhhcHB5IDotKCBTbyBiYXNl ZCBvbiB0aGF0DQo+IGluZm9ybWF0aW9uIEkgd291bGQgc2F5LCB0aGUgb25seSBwcm9wZXIgd2F5 IHRvIGludGVncmF0ZSBzdGFuZGFyZCBIVFRQDQo+IHNjaGVtZXMgd291bGQgYmUgdG8gaW52ZW50 IGFub3RoZXIgZW5kcG9pbnQgZm9yIHRoYXQgcHVycG9zZS4NCj4NCj4gQ29tbWVudHM/DQo+DQo+ IHJlZ2FyZHMsDQo+IFRvcnN0ZW4uDQo+DQo+Pg0KPj4gRUhMDQo+Pg0KPj4NCj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0IFtt YWlsdG86dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXRdDQo+Pj4gU2VudDogTW9uZGF5LCBKYW51YXJ5 IDI0LCAyMDExIDEwOjM1IFBNDQo+Pj4gVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRw0K Pj4+IFN1YmplY3Q6IEFXOiBSRTogW09BVVRILVdHXSBIb3cgdG8gaW50ZWdyYXRlZCBESUdFU1Qg b3IgU1BORUdPIHdpdGgNCj4+PiB0b2tlbnNlbmRwb2ludD8NCj4+Pg0KPj4+IEhpIEVyYW4sDQo+ Pj4NCj4+PiB0aGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuIE15IGlucXVpcnkgd2FzIGFib3V0IGVu ZC11c2VyIGF1dGhlbnRpY2F0aW9uDQo+Pj4gYW5kDQo+Pj4gbm90IGFib3V0IGNsaWVudCBhdXRo ZW50aWNhdGlvbi4gQWxsIGh0dHAgc2NoZW1lcyBJJ20gYXdhcmUgb2YNCj4+PiBhdXRoZW50aWNh dGUNCj4+PiB1c2VycyBhbmQgSSB3YW50IHRvIGZpbmQgYSB3YXkgdG8gbGV2ZXJhZ2UgdGhlbSB3 aXRoIE9BdXRoIHRvIGRldGVybWluZQ0KPj4+IHRoZQ0KPj4+IHRva2VuJ3MgaWRlbnRpdHkuDQo+ Pj4NCj4+PiBSZWdhcmRzLA0KPj4+IFRvcnN0ZW4uDQo+Pj4gR2VzZW5kZXQgbWl0IEJsYWNrQmVy cnkocikgV2VibWFpbCB2b24gVGVsZWtvbSBEZXV0c2NobGFuZA0KPj4+DQo+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiA8ZXJhbkBodWVu aXZlcnNlLmNvbT4NCj4+PiBEYXRlOiBNb24sIDI0IEphbiAyMDExIDE1OjI1OjM4DQo+Pj4gVG86 IFRvcnN0ZW4gTG9kZGVyc3RlZHQ8dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ+OyBPQXV0aA0KPj4+ IFdHPG9hdXRoQGlldGYub3JnPg0KPj4+IFN1YmplY3Q6IFJFOiBbT0FVVEgtV0ddIEhvdyB0byBp bnRlZ3JhdGVkIERJR0VTVCBvciBTUE5FR08gd2l0aCB0b2tlbnMNCj4+PiBlbmRwb2ludD8NCj4+ Pg0KPj4+IFRoaXMgaXMgcHJldHR5IHN0cmFpZ2h0LWZvcndhcmQuIFRoZXJlIGFyZSBubyBzcGVj aWFsIHBhcmFtZXRlcnMgdG8NCj4+PiBpbmRpY2F0ZWQNCj4+PiB3aGljaCBjbGllbnQgYXV0aGVu dGljYXRpb24gaXMgYmVpbmcgdXNlZC4gSXQncyBlaXRoZXIgdGhlcmUgb3Igbm90LA0KPj4+IHVz aW5nDQo+Pj4gd2hhdGV2ZXIgdGhlIHNlcnZlciBzdXBwb3J0cy4NCj4+Pg0KPj4+IFNpbXBseSBo YXZlIHRoZSB0b2tlbiBlbmRwb2ludCByZXR1cm4gYSA0MDEgd2l0aCB0aGVzZSBXV1ctQXV0aGVu dGljYXRlDQo+Pj4gaGVhZGVycy4gQXMgbG9uZyBhcyB5b3UgbWFrZSBpdCBjbGVhciBob3cgdG8g bWFrZSBiZXR3ZWVuIHRoZSBjbGllbnQNCj4+PiBpZGVudGlmaWVyIGFuZCB0aGUgY3JlZGVudGlh bHMgdXNlZCwgeW91IGFyZSBzZXQuDQo+Pj4NCj4+PiBGb3IgZXhhbXBsZSwgYSB0b2tlbiByZXNw b25zZSBjYW4gcmV0dXJuOg0KPj4+DQo+Pj4gNDAxIFVuYXV0aG9yaXplZA0KPj4+IFdXVy1BdXRo ZW50aWNhdGU6IEJhc2ljIHJlYWxtPSJleGFtcGxlIg0KPj4+IFdXVy1BdXRoZW50aWNhdGU6IERp Z2VzdCByZWFsbT0iZXhhbXBsZSINCj4+Pg0KPj4+IFRoZXJlIGlzIG5vIGRpc2NvdmVyeSBmb3Ig c3VwcG9ydCBmb3IgdGhlIGNsaWVudF9pZCBhbmQgY2xpZW50X3NlY3JldA0KPj4+IHBhcmFtZXRl cnMuIFRoZSBjbGllbnQgY2FuIHNpbXBseSB0cnkgaXQgb3IgaGFyZGNvZGUgaXQgYmFzZWQgb24g dGhlDQo+Pj4gc2VydmVyJ3MNCj4+PiBkb2N1bWVudGF0aW9uLg0KPj4+DQo+Pj4gRG9lcyB0aGlz IGhlbHA/DQo+Pj4NCj4+PiBFSEwNCj4+Pg0KPj4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+PiA+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+PiA+IE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQNCj4+ PiA+IFNlbnQ6IE1vbmRheSwgSmFudWFyeSAyNCwgMjAxMSAxOjEwIFBNDQo+Pj4gPiBUbzogT0F1 dGggV0cNCj4+PiA+IFN1YmplY3Q6IFtPQVVUSC1XR10gSG93IHRvIGludGVncmF0ZWQgRElHRVNU IG9yIFNQTkVHTyB3aXRoIHRva2Vucw0KPj4+ID4gZW5kcG9pbnQ/DQo+Pj4gPg0KPj4+ID4gSGkg YWxsLA0KPj4+ID4NCj4+PiA+IEknbSBjdXJyZW50bHkgdGhpbmtpbmcgYWJvdXQgdGhlIGludGVn cmF0aW9uIG9mIGV4aXN0aW5nIEhUVFANCj4+PiA+IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgd2l0 aCBPQXV0aCAyLjAgZm9yIHRoZSBwdXJwb3NlIG9mIGVuZC11c2VyDQo+Pj4gPiBhdXRoZW50aWNh dGlvbiBvbiB0aGUgdG9rZW5zIGVuZHBvaW50LiBQb3NzaWJsZSBjYW5kaWRhdGVzIGFyZSAiRGln ZXN0Ig0KPj4+ID4gZm9yIGNoYWxsZW5nZS1yZXNwb25zZS1iYXNlZCB1c2VybmFtZS9wYXNzd29y ZCBhdXRoZW50aWNhdGlvbiBhbmQNCj4+PiA+ICJTcG5lZ28iIGZvciBLZXJiZXJvcy1iYXNlZCBh dXRoZW50aWNhdGlvbi4gRGlyZWN0IHN1cHBvcnQgZm9yIGJvdGgNCj4+PiA+IGNvdWxkIGJlIGJl bmVmaWNpYWxseSBpbiBlbnRlcnByaXNlIGFuZCBvdGhlciBzZWN1cml0eSBzZW5zaXRpdmUNCj4+ PiBkZXBsb3ltZW50cy4NCj4+PiA+DQo+Pj4gPiBBbiBkaXJlY3QgaW50ZWdyYXRpb24gd2l0aCB0 aGUgdG9rZW5zIGVuZHBvaW50IHdvdWxkIGFsbG93IHRvIGxldmVyYWdlDQo+Pj4gPiBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgYW5kIGluZnJhc3RydWN0dXJlIGZvciBPQXV0aC9IVFRQLWJhc2Vk DQo+Pj4gPiBhcmNoaXRlY3R1cmVzLiBGb3IgZXhhbXBsZSwgSFRUUENsaWVudCBoYXMgZGlyZWN0 IHN1cHBvcnQgZm9yIFNwbmVnby0NCj4+PiA+IEF1dGhlbnRpY2F0aW9uLg0KPj4+ID4NCj4+PiA+ IEJvdGggSFRUUCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIHVzZSBkZWRpY2F0ZWQgV1dXLUF1dGhl bnRpY2F0ZSBhbmQNCj4+PiA+IEF1dGhvcml6YXRpb24gaGVhZGVycyBmb3IgcGFzc2luZyBjcmVk ZW50aWFsIGFuZCBvdGhlciBkYXRhIGJldHdlZW4NCj4+PiA+IGNsaWVudCBhbmQgc2VydmVyLiBP QXV0aCBpbiBjb250cmFzdCB1c2VzIGdyYW50IHR5cGVzIHRvIGluZGljYXRlIHRoZQ0KPj4+ID4g YXV0aGVudGljYXRpb24gbWV0aG9kLCBjcmVkZW50aWFscyBhcmUgcGFzc2VkIGFzIFVSSSBxdWVy eSBwYXJhbWV0ZXJzDQo+Pj4gPiBhbmQgaXQgbGFja3MgYW55IGRpc2NvdmVyeSBvZiBhdmFpbGFi bGUgYXV0aGVudGljYXRpb24gbWV0aG9kcy8gZ3JhbnQNCj4+PiA+IHR5cGVzLg0KPj4+ID4NCj4+ PiA+IEhvdyBjb3VsZCBvbmUgaW50ZWdyYXRlIGV4aXN0aW5nIHNjaGVtZXMgaW50byB0aGF0IGRl c2lnbj8gV2hhdCBpcyBvdXINCj4+PiA+IHN0b3J5PyBEbyB3ZSBuZWVkIHRvIGRlZmluZSBhIHNw ZWNpYWwgZ3JhbnQgdHlwZSAiSFRUUCBhdXRob3JpemF0aW9uIj8NCj4+PiA+IFNoYWxsIEF1dGhv cml6YXRpb24gaGVhZGVycyBvdmVycnVsZSBVUkkgcGFyYW1ldGVycz8NCj4+PiA+DQo+Pj4gPiBB bnkgaWRlYXMgb2YgdGhlIFdHIGFyZSBoaWdseSBhcHByZWNpYXRlZC4NCj4+PiA+DQo+Pj4gPiBy ZWdhcmRzLA0KPj4+ID4gVG9yc3Rlbi4NCj4+PiA+DQo+Pj4gPg0KPj4+ID5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ID4gT0F1dGggbWFpbGluZyBs aXN0DQo+Pj4gPiBPQXV0aEBpZXRmLm9yZw0KPj4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vYXV0aA0KPj4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9B dXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1 dGgNCj4NCg== From eran@hueniverse.com Wed Jan 26 01:00:45 2011 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 F29483A695B for ; Wed, 26 Jan 2011 01:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, 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 2-zHv1gbFBvn for ; Wed, 26 Jan 2011 01:00:44 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 394B43A6958 for ; Wed, 26 Jan 2011 01:00:44 -0800 (PST) Received: (qmail 27771 invoked from network); 26 Jan 2011 09:03:44 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 09:03:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 26 Jan 2011 01:59:48 -0700 From: Eran Hammer-Lahav To: OAuth WG Date: Wed, 26 Jan 2011 01:59:31 -0700 Thread-Topic: Draft -12 feedback deadline Thread-Index: Acu9NwZ/fRxo5C3AS8e9gi46OujABg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6254DP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: [OAUTH-WG] Draft -12 feedback deadline 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, 26 Jan 2011 09:00:45 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6254DP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I plan to publish a quick fix to editorial issues raised in a -13 on Monday= 1/31. If you have editorial feedback, please post it to the list by Friday= 1/28 so that I can respond and incorporate if needed. This is not a deadli= ne for normative issues, only editorial, but you can post feedback on both.= I plan to request an official WG review of -13 to begin next week. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6254DP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I plan to publis= h a quick fix to editorial issues raised in a -13 on Monday 1/31. If you ha= ve editorial feedback, please post it to the list by Friday 1/28 so that I = can respond and incorporate if needed. This is not a deadline for normative= issues, only editorial, but you can post feedback on both. I plan to reque= st an official WG review of -13 to begin next week.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D6254DP3PW5EX1MB01E_-- From jricher@mitre.org Wed Jan 26 06:10:08 2011 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 657AB3A69C7 for ; Wed, 26 Jan 2011 06:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.488 X-Spam-Level: X-Spam-Status: No, score=-3.488 tagged_above=-999 required=5 tests=[AWL=-0.889, 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 bBDK6Sx77rqM for ; Wed, 26 Jan 2011 06:10:04 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 3C5103A69C3 for ; Wed, 26 Jan 2011 06:10:04 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9252E21B0AF5; Wed, 26 Jan 2011 09:13:04 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8BE7D21B0AF3; Wed, 26 Jan 2011 09:13:04 -0500 (EST) Received: from [129.83.50.65] (129.83.50.65) by imchub2.MITRE.ORG (129.83.29.74) with Microsoft SMTP Server id 8.2.254.0; Wed, 26 Jan 2011 09:13:04 -0500 From: Justin Richer To: Marius Scurtescu In-Reply-To: References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Jan 2011 09:13:03 -0500 Message-ID: <1296051184.9984.5.camel@pulse> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 14:10:08 -0000 > 2. Section 8.2. What about applications using legacy parameters? Does > not make much sense to register them, and they cannot be changed to > x_. I *guarantee* that there will be many noncompliant implementations of this, built on server frameworks with required parameters on all endpoints. Not everyone is a Facebook or Google who can just define a new top-level endpoint with clean parameter space. OAuth2 is going to be integrated into *existing* systems that already have their allowable extra parameters carved out, and these systems are not going to change their parameters just to support OAuth. Once again, I'll say that if the choice comes down to changing around existing parameters or not supporting OAuth, most people are going to just not support OAuth. > Broken record: using a prefix for all registered parameters is > much cleaner (as opposed to requiring that all no-registered > parameters use a prefix). And once again, a strong +1 to this, even though I know it's far too late to make such a breaking change to the spec. I really think this was a bad decision and is going to come back and bite us in the future. -- Justin From eran@hueniverse.com Wed Jan 26 08:02:43 2011 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 C9D0F3A676A for ; Wed, 26 Jan 2011 08:02:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 1xXfqVgQwkwH for ; Wed, 26 Jan 2011 08:02:43 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E21B83A6359 for ; Wed, 26 Jan 2011 08:02:42 -0800 (PST) Received: (qmail 27557 invoked from network); 26 Jan 2011 16:05:42 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 16:05:42 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 26 Jan 2011 09:05:41 -0700 From: Eran Hammer-Lahav To: Justin Richer , Marius Scurtescu Date: Wed, 26 Jan 2011 09:05:23 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu9Yyam/U6JQtu2Ri6m5nPxXY4v1gAD3j6Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D625D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1296051184.9984.5.camel@pulse> In-Reply-To: <1296051184.9984.5.camel@pulse> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 16:02:43 -0000 SXQncyBiZWVuIGNsb3NlIHRvIGEgeWVhciBhbmQgbm8gYml0ZSBtYXJrcy4NCg0KRUhMDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSnVzdGluIFJpY2hlciBbbWFpbHRv OmpyaWNoZXJAbWl0cmUub3JnXQ0KPiBTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjYsIDIwMTEg NjoxMyBBTQ0KPiBUbzogTWFyaXVzIFNjdXJ0ZXNjdQ0KPiBDYzogRXJhbiBIYW1tZXItTGFoYXY7 IG9hdXRoQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIEktRCBBY3Rpb246ZHJh ZnQtaWV0Zi1vYXV0aC12Mi0xMi50eHQNCj4gDQo+ID4gMi4gU2VjdGlvbiA4LjIuIFdoYXQgYWJv dXQgYXBwbGljYXRpb25zIHVzaW5nIGxlZ2FjeSBwYXJhbWV0ZXJzPyBEb2VzDQo+ID4gbm90IG1h a2UgbXVjaCBzZW5zZSB0byByZWdpc3RlciB0aGVtLCBhbmQgdGhleSBjYW5ub3QgYmUgY2hhbmdl ZCB0bw0KPiA+IHhfLg0KPiANCj4gSSAqZ3VhcmFudGVlKiB0aGF0IHRoZXJlIHdpbGwgYmUgbWFu eSBub25jb21wbGlhbnQgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMsDQo+IGJ1aWx0IG9uIHNlcnZl ciBmcmFtZXdvcmtzIHdpdGggcmVxdWlyZWQgcGFyYW1ldGVycyBvbiBhbGwgZW5kcG9pbnRzLiBO b3QNCj4gZXZlcnlvbmUgaXMgYSBGYWNlYm9vayBvciBHb29nbGUgd2hvIGNhbiBqdXN0IGRlZmlu ZSBhIG5ldyB0b3AtbGV2ZWwNCj4gZW5kcG9pbnQgd2l0aCBjbGVhbiBwYXJhbWV0ZXIgc3BhY2Uu IE9BdXRoMiBpcyBnb2luZyB0byBiZSBpbnRlZ3JhdGVkIGludG8NCj4gKmV4aXN0aW5nKiBzeXN0 ZW1zIHRoYXQgYWxyZWFkeSBoYXZlIHRoZWlyIGFsbG93YWJsZSBleHRyYSBwYXJhbWV0ZXJzDQo+ IGNhcnZlZCBvdXQsIGFuZCB0aGVzZSBzeXN0ZW1zIGFyZSBub3QgZ29pbmcgdG8gY2hhbmdlIHRo ZWlyIHBhcmFtZXRlcnMganVzdA0KPiB0byBzdXBwb3J0IE9BdXRoLiBPbmNlIGFnYWluLCBJJ2xs IHNheSB0aGF0IGlmIHRoZSBjaG9pY2UgY29tZXMgZG93biB0bw0KPiBjaGFuZ2luZyBhcm91bmQg ZXhpc3RpbmcgcGFyYW1ldGVycyBvciBub3Qgc3VwcG9ydGluZyBPQXV0aCwgbW9zdCBwZW9wbGUN Cj4gYXJlIGdvaW5nIHRvIGp1c3Qgbm90IHN1cHBvcnQgT0F1dGguDQo+IA0KPiA+IEJyb2tlbiBy ZWNvcmQ6IHVzaW5nIGEgcHJlZml4IGZvciBhbGwgcmVnaXN0ZXJlZCBwYXJhbWV0ZXJzIGlzIG11 Y2gNCj4gPiBjbGVhbmVyIChhcyBvcHBvc2VkIHRvIHJlcXVpcmluZyB0aGF0IGFsbCBuby1yZWdp c3RlcmVkIHBhcmFtZXRlcnMgdXNlDQo+ID4gYSBwcmVmaXgpLg0KPiANCj4gQW5kIG9uY2UgYWdh aW4sIGEgc3Ryb25nICsxIHRvIHRoaXMsIGV2ZW4gdGhvdWdoIEkga25vdyBpdCdzIGZhciB0b28g bGF0ZSB0bw0KPiBtYWtlIHN1Y2ggYSBicmVha2luZyBjaGFuZ2UgdG8gdGhlIHNwZWMuIEkgcmVh bGx5IHRoaW5rIHRoaXMgd2FzIGEgYmFkDQo+IGRlY2lzaW9uIGFuZCBpcyBnb2luZyB0byBjb21l IGJhY2sgYW5kIGJpdGUgdXMgaW4gdGhlIGZ1dHVyZS4NCj4gDQo+ICAtLSBKdXN0aW4NCg0K From jricher@mitre.org Wed Jan 26 08:14:09 2011 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 17A603A67DF for ; Wed, 26 Jan 2011 08:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-0.842, 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 Pkzw5mHp3XgX for ; Wed, 26 Jan 2011 08:14:08 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 0E24C3A67DB for ; Wed, 26 Jan 2011 08:14:07 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA41221B0B36; Wed, 26 Jan 2011 11:17:08 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A397D21B0B24; Wed, 26 Jan 2011 11:17:08 -0500 (EST) Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Wed, 26 Jan 2011 11:17:08 -0500 From: Justin Richer To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D625D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1296051184.9984.5.camel@pulse> <90C41DD21FB7C64BB94121FBBC2E723445A8D625D3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset="UTF-8" Date: Wed, 26 Jan 2011 11:17:08 -0500 Message-ID: <1296058628.9984.27.camel@pulse> MIME-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 16:14:09 -0000 And also not much adoption into older (established) systems, yet. That's where I see the trouble really happening. Most of the deployments we've seen with OAuth2 have been with new systems or custom-built websites where the devs had full control over API parameters. -- Justin On Wed, 2011-01-26 at 11:05 -0500, Eran Hammer-Lahav wrote: > It's been close to a year and no bite marks. > > EHL > > > -----Original Message----- > > From: Justin Richer [mailto:jricher@mitre.org] > > Sent: Wednesday, January 26, 2011 6:13 AM > > To: Marius Scurtescu > > Cc: Eran Hammer-Lahav; oauth@ietf.org > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > > 2. Section 8.2. What about applications using legacy parameters? Does > > > not make much sense to register them, and they cannot be changed to > > > x_. > > > > I *guarantee* that there will be many noncompliant implementations of this, > > built on server frameworks with required parameters on all endpoints. Not > > everyone is a Facebook or Google who can just define a new top-level > > endpoint with clean parameter space. OAuth2 is going to be integrated into > > *existing* systems that already have their allowable extra parameters > > carved out, and these systems are not going to change their parameters just > > to support OAuth. Once again, I'll say that if the choice comes down to > > changing around existing parameters or not supporting OAuth, most people > > are going to just not support OAuth. > > > > > Broken record: using a prefix for all registered parameters is much > > > cleaner (as opposed to requiring that all no-registered parameters use > > > a prefix). > > > > And once again, a strong +1 to this, even though I know it's far too late to > > make such a breaking change to the spec. I really think this was a bad > > decision and is going to come back and bite us in the future. > > > > -- Justin > From eran@hueniverse.com Wed Jan 26 08:25:06 2011 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 9F8F93A6808 for ; Wed, 26 Jan 2011 08:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.259 X-Spam-Level: X-Spam-Status: No, score=-2.259 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=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 zVrObdBOpSjo for ; Wed, 26 Jan 2011 08:24:56 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id A06373A6805 for ; Wed, 26 Jan 2011 08:24:56 -0800 (PST) Received: (qmail 31682 invoked from network); 26 Jan 2011 16:27:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 16:27:56 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 26 Jan 2011 09:27:53 -0700 From: Eran Hammer-Lahav To: Eric , "oauth@ietf.org" Date: Wed, 26 Jan 2011 09:27:35 -0700 Thread-Topic: [OAUTH-WG] validate authorization code in draft 12 Thread-Index: Acu5RXtgJQrYrJGgS/u6ka+UhQ4KKAEMGFsw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D625E6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D39442B.2090408@cs.stanford.edu> In-Reply-To: <4D39442B.2090408@cs.stanford.edu> 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_90C41DD21FB7C64BB94121FBBC2E723445A8D625E6P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] validate authorization code in draft 12 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, 26 Jan 2011 16:25:06 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D625E6P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This belongs in the security consideration section. Torsten - can you add it to your list? EHL From: Eric [mailto:pflam@cs.stanford.edu] Sent: Friday, January 21, 2011 12:31 AM To: Eran Hammer-Lahav; oauth@ietf.org Subject: Re: [OAUTH-WG] validate authorization code in draft 12 Eran, and others, A few of us had some discussions on the authorization code flow, as depicte= d in Fig. 3 of the current (12th) draft. We think that it is probably worth= while to suggest in the specification that an OAuth implementation SHOULD p= rovide a way for the client to validate the authorization code before sendi= ng it to the Authorization Server (AS). From what we have heard, this has = been done in some of the current OAuth deployments. There are other people = who do not think this is such a big security risk, although so far no one h= as objected that there is some risk here. The issue is that according to the current draft, someone who owns a botnet= can locate the redirect URIs of clients that listen on HTTP, and access th= em with random authorization codes, and cause HTTPS connections to be made = on the Authorization Server (AS). There are a few things that the attacker = can achieve with this OAuth flow that he cannot easily achieve otherwise : 1. Cost magnification: the attacker incurs the cost of an HTTP connection a= nd causes an HTTPS connection to be made on the AS; and he can co-ordinate = the timing of such HTTPS connections across multiple clients relatively eas= ily, if these clients blindly connect to the AS without first validating th= e authorization codes received. Although the attacker could achieve something similar, say by including an = iframe pointing to the HTTPS URL of the AS in an HTTP web page and lure web= users to visit that page, timing attacks using such a scheme is (say for = the purpose of DDoS) more difficult . 2. Connection laundering: if the AS realizes it is flooded by HTTPS connect= ions with illegitimate codes, it collects no useful information about the a= ttacker, since the clients act as relays. 3. CSRF defense/the 'state' parameter don't completely address this problem= . With such a defense, the attacker might need to incur an additional HTTP = request to obtain a valid CSRF code/ state parameter. This does cut down th= e effectiveness of the attack by a factor of 2, which is good. However, if = the HTTPS/HTTP cost ratio is higher than 2 (the cost factor is estimated to= be around 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency.htm= l), the attacker still achieves a cost magnification. Our proposal is that the OAuth specification suggests that an OAuth impleme= ntation SHOULD provide a way for the client to validate the authorization c= ode before sending it to the Authorization Server (AS). The specifics of h= ow to validate the authorization code may not need to be part of the core s= pecification. We sketch a design below for consideration for future impleme= ntation. It might be reasonable to assume that OAuth implementations provid= e some API for the client to call to validate and send the authorization co= de to the AS. There are two possible schemes for implementation: a) if the = client and the AS already share a symmetric secret, an HMAC key can be crea= ted from the shared secret, and the authorization code will be HMAC'ed and = standard techniques can be employed in the client-side API implementation t= o detect replay and forgery attempts on the code; b) an alternative is for = the AS to sign the code using the private key from its SSL certificate, and= for the client API to validate the signature using the public key. On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav wrote: Draft -12 is finally out. This is almost a complete rewrite of the entire document, with the primary = goal of moving it back to a similar structure used in -05. I have been thin= king about this for a few months and finally came up with a structure that = combines the two approaches. The draft includes some major cleanups, significantly simpler language, red= uces repeated prose, and tried to keep prose to the introduction and normat= ive language in the rest of the specification. I took out sections that bro= ke the flow, and did my best to give this a linear narrative that is easy t= o follow. The draft includes the following normative changes: o Clarified 'token_type' as case insensitive. o Authorization endpoint requires TLS when an access token is issued. o Removed client assertion credentials, mandatory HTTP Basic authenticat= ion support for client credentials, WWW-Authenticate header, and the OAuth2= authentication scheme. o Changed implicit grant (aka user-agent flow) error response from query= to fragment. o Removed the 'redirect_uri_mismatch' error code since in such a case, t= he authorization server must not send the error back to the client. o Defined access token type registry. I would like to spend the coming week receiving and applying feedback befor= e requesting a WGLC for everything but the security considerations section = (missing) 2/1. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth= -bounces@ietf.org] On Behalf > Of Internet-Drafts@ietf.org > Sent: Thursday, January 20, 2011 4:45 PM > To: i-d-announce@ietf.org > Cc: oauth@ietf.org > Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Open Authentication Protocol Working Gro= up > of the IETF. > > > Title : The OAuth 2.0 Authorization Protocol > Author(s) : E. Hammer-Lahav, et al. > Filename : draft-ietf-oauth-v2-12.txt > Pages : 46 > Date : 2011-01-20 > > This specification describes the OAuth 2.0 authorization protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the Interne= t- > Draft. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D625E6P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= This belongs in the security consideration section.

 

Torsten – can you add it to your list?

 

EHL

&nb= sp;

F= rom: Eric [mailto:pflam@cs.stanford.edu]
Sent: Friday, January 21, 2011 12:31 AM
To: Eran Hammer-Lahav; oauth= @ietf.org
Subject: Re: [OAUTH-WG] validate authorization code in = draft 12

 <= /o:p>

Eran, and othe= rs,

A few of us had some discussions on the authorization code flow,= as depicted in Fig. 3 of the current (12th) draft. We think that it is pro= bably worthwhile to suggest in the specification that an OAuth implementati= on SHOULD provide a way for the client to validate the authorization code b= efore sending it to the  Authorization Server (AS). From what we have = heard, this has been done in some of the current OAuth deployments. There a= re other people who do not think this is such a big security risk, although= so far no one has objected that there is some risk here.

The issue = is that according to the current draft, someone who owns a botnet can locat= e the redirect URIs of clients that listen on HTTP, and access them with ra= ndom authorization codes, and cause HTTPS connections to be made on the Aut= horization Server (AS). There are a few things that the attacker can achiev= e with this OAuth flow that he cannot easily achieve otherwise :

1.= Cost magnification: the attacker incurs the cost of an HTTP connection and= causes an HTTPS connection to be made on the AS; and he can co-ordinate th= e timing of such HTTPS connections across multiple clients relatively easil= y, if these clients blindly connect to the AS without first validating the = authorization codes received.

Although the attacker could achieve so= mething similar, say by including an iframe pointing to the HTTPS URL of th= e AS in an HTTP web page and lure web  users to visit that page, timin= g attacks using such a scheme is (say for the purpose of DDoS) more difficu= lt .

2. Connection laundering: if the AS realizes it is flooded by H= TTPS connections with illegitimate codes, it collects no useful information= about the attacker, since the clients act as relays. 

3. CSRF= defense/the 'state' parameter don't completely address this problem. With = such a defense, the attacker might need to incur an additional HTTP request= to obtain a valid CSRF code/ state parameter. This does cut down the effec= tiveness of the attack by a factor of 2, which is good. However, if the HTT= PS/HTTP cost ratio is higher than 2 (the cost factor is estimated to be aro= und 3.5x at http://www.semicomplete.com/blog/geekery/ssl-latency.html), the = attacker still achieves a cost magnification.

Our proposal is that t= he OAuth specification suggests that an OAuth implementation SHOULD provide= a way for the client to validate the authorization code before sending it = to the  Authorization Server (AS). The specifics of how to validate th= e authorization code may not need to be part of the core specification. We = sketch a design below for consideration for future implementation. It might= be reasonable to assume that OAuth implementations provide some API for th= e client to call to validate and send the authorization code to the AS. The= re are two possible schemes for implementation: a) if the client and the AS= already share a symmetric secret, an HMAC key can be created from the shar= ed secret, and the authorization code will be HMAC'ed and standard techniqu= es can be employed in the client-side API implementation to detect replay a= nd forgery attempts on the code; b) an alternative is for the AS to sign th= e code using the private key from its SSL certificate, and for the client A= PI to validate the signature using the public key.

 <= /o:p>

On Thu, Jan 20, 2011 at 4:56 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

Draft -12 is finally out.

Thi= s is almost a complete rewrite of the entire document, with the primary goa= l of moving it back to a similar structure used in -05. I have been thinkin= g about this for a few months and finally came up with a structure that com= bines the two approaches.

The draft includes some major cleanups, si= gnificantly simpler language, reduces repeated prose, and tried to keep pro= se to the introduction and normative language in the rest of the specificat= ion. I took out sections that broke the flow, and did my best to give this = a linear narrative that is easy to follow.

The draft includes the fo= llowing normative changes:

  o  Clarified 'token_type' as = case insensitive.
  o  Authorization endpoint requires TLS whe= n an access token is issued.
  o  Removed client assertion cre= dentials, mandatory HTTP Basic authentication support for client credential= s, WWW-Authenticate header, and the OAuth2 authentication scheme.
 = o  Changed implicit grant (aka user-agent flow) error response from q= uery to fragment.
  o  Removed the 'redirect_uri_mismatch' err= or code since in such a case, the authorization server must not send the er= ror back to the client.
  o  Defined access token type registr= y.

I would like to spend the coming week receiving and applying feed= back before requesting a WGLC for everything but the security consideration= s section (missing) 2/1.

EHL




&= gt; -----Original Message-----
> From: oauth-bounces@i= etf.org [mailto:oauth-bounces@ietf.org] On Behalf> Of Internet-Drafts@ietf.org
> Sent: Thursd= ay, January 20, 2011 4:45 PM
> To: i-d-announce@ietf.or= g
> Cc: oauth@ietf.org
> Subject: [OAUTH-WG] I= -D Action:draft-ietf-oauth-v2-12.txt
>
> A New Internet-Draft i= s available from the on-line Internet-Drafts directories.
> This draf= t is a work item of the Open Authentication Protocol Working Group
> = of the IETF.
>
>
>       Title   &nbs= p;       : The OAuth 2.0 Authorization Protocol
> &nbs= p;     Author(s)       : E. Hammer-Lahav, et al.>       Filename        : draft-iet= f-oauth-v2-12.txt
>       Pages       &= nbsp;   : 46
>       Date       &n= bsp;    : 2011-01-20
>
> This specification describes= the OAuth 2.0 authorization protocol.
>
> A URL for this Inter= net-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-12.txt=
>
> Internet-Drafts are also available by anonymous FTP at= :
> ftp://ftp.ietf.org/interne= t-drafts/
>
> Below is the data which will enable a MIME co= mpliant mail reader
> implementation to automatically retrieve the AS= CII version of the Internet-
> Draft.

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

 

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D625E6P3PW5EX1MB01E_-- From wmills@yahoo-inc.com Wed Jan 26 08:40:59 2011 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 654B43A67F3 for ; Wed, 26 Jan 2011 08:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.535 X-Spam-Level: X-Spam-Status: No, score=-17.535 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, 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 9km8ITRPdR4k for ; Wed, 26 Jan 2011 08:40:58 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 77CBF3A63D3 for ; Wed, 26 Jan 2011 08:40:58 -0800 (PST) Received: from SP2-EX07CAS03.ds.corp.yahoo.com (sp2-ex07cas03.corp.sp2.yahoo.com [98.137.59.35]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0QGheCG009989; Wed, 26 Jan 2011 08:43:40 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS03.ds.corp.yahoo.com ([98.137.59.35]) with mapi; Wed, 26 Jan 2011 08:43:40 -0800 From: William Mills To: Eran Hammer-Lahav Date: Wed, 26 Jan 2011 08:43:35 -0800 Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu3pr1t3syl2UOrRViF4qH3Mgl/vQAXVc0QAU/ZFQAAB26UAAAQlxCwACD5gsAAQTh0YAB98x9QAOsVL5A= Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246F7987@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62541@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D6254C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 16:40:59 -0000 I question how much name space pollution is a problem, how many auth scheme= s are we really going to have? =20 > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Wednesday, January 26, 2011 12:49 AM > To: William Mills > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Bear token scheme name >=20 > Thanks William. >=20 > It is important to differentiate between style and substance (both of > which are very important to people). >=20 > Style-wise, we can use either of the three options below, but they are > essentially the same. You take the string and put it through a parser > and end up with the actual scheme name and some attributes. I don't > really buy the arguments about namespaces and pollution. >=20 > Creating a super scheme that then has to be extended for sub-schemes is > actually a lot more complex. AFAIK, all the existing HTTP > authentication schemes are not extensible (or at least have not been > extended). There is something very helpful in moving extensibility out > of the scheme so that a client that can speak it today can also speak > it 10 years from now. If you need new options, create a new scheme. >=20 > I like the scheme-per-type approach because it is modular and does not > require much coordination. The lack of consensus we've seen between > bearer tokens and mac tokens is an example. I don't want to have to > negotiate parameter names and other formats when such collaboration > will just slow both efforts and lead to no meaningful interoperability > (given that the two token types are completely incompatible). >=20 > The HTTP authentication headers are named poorly. The WWW-Authenticate > means 'you need to authenticate' and the Authorization header means > 'here is my authentication credentials'. There is no actual > authorization as implemented by OAuth (in terms of third party and > grants). When talking about using a token to access a protected > resource, we are dealing exclusively with authentication and should use > the right HTTP vehicle for that. >=20 > EHL >=20 > > -----Original Message----- > > From: William Mills [mailto:wmills@yahoo-inc.com] > > Sent: Tuesday, January 25, 2011 11:23 PM > > To: Eran Hammer-Lahav; Mike Jones > > Cc: OAuth WG > > Subject: RE: [OAUTH-WG] Bear token scheme name > > > > Back to Marius' question though, which is about how we determine how > to > > treat the Authenticate header when you see it. I, for one, was not > happy > > with the way that Wrap added on to the OAuth scheme. There are at > least 3 > > possibilities that it seems to be worth discussing: > > > > 1) a fixed scheme name with a variable indicating flavor, i.e. Oauth2 > > authtype=3Dbearer, but we could go more agnostic like "Authz > type=3Dbearer" if > > OAuth2 really chafes. > > > > PRO: simple namespace > > > > 2) a scheme per auth type extension: i.e. bearer, MAC, SAML, etc. \ > > > > PRO: easy to extend, in no way semantically bound to OAuth > > CON: namespace pollution and a proliferation of auth types > > > > 3) as yet un-discussed, we could reserve a namespace like oauth2_ and > use > > things like oauth2_bearer. > > > > 2 and 3 are not exclusive. Are there more? > > > > There's also discussion that this is authorization, not > authentication, and if we > > really want to go there then the source of the problem might be that > we're > > choosing to overload the Authenticate header. Even more muddy, it's > > entirely possible that a bearer token might contain a user > credential. > > > > > > > > > -----Original Message----- > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > > > Behalf > > > > > Of Marius Scurtescu > > > > > Sent: Tuesday, January 25, 2011 6:26 PM > > > > > To: Mike Jones > > > > > Cc: OAuth WG > > > > > Subject: Re: [OAUTH-WG] Bear token scheme name > > > > > > > > > > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones > > > > > wrote: > > > > > > I'd like a sense from the working group whether others want > this > > > > > > change, and if so, what the name should be changed to. > > > > > > > > > > Probably this was debated, but I will ask again. > > > > > > > > > > Why can't we use "OAuth2" as the scheme in all cases and > require a > > > > > token_type name/value pair? > > > > > > > > > > Is it wise to dump lots of new schemes in a name space we do > not > > > control? > > > > > > > > > > Marius > > > > > _______________________________________________ > > > > > OAuth mailing list > > > > > OAuth@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Jan 26 08:45:14 2011 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 489FF3A6805 for ; Wed, 26 Jan 2011 08:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 Jz377CWjOvtc for ; Wed, 26 Jan 2011 08:45:13 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 19EA83A67FD for ; Wed, 26 Jan 2011 08:45:13 -0800 (PST) Received: (qmail 7587 invoked from network); 26 Jan 2011 16:48:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 16:48:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 26 Jan 2011 09:48:01 -0700 From: Eran Hammer-Lahav To: William Mills Date: Wed, 26 Jan 2011 09:47:42 -0700 Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu3pr1t3syl2UOrRViF4qH3Mgl/vQAXVc0QAU/ZFQAAB26UAAAQlxCwACD5gsAAQTh0YAB98x9QAOsVL5AB1fuuQA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D625F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246F7987@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62541@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D6254C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 16:45:14 -0000 No clue, but what difference does it make? Either you "pollute" the OAuth h= eader namespace or the HTTP Authentication scheme name namespace. What's th= e difference? Either way, I would be surprised if we see more than 10 token= types over the next 5 years. EHL > -----Original Message----- > From: William Mills [mailto:wmills@yahoo-inc.com] > Sent: Wednesday, January 26, 2011 8:44 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: [OAUTH-WG] Bear token scheme name >=20 > I question how much name space pollution is a problem, how many auth > schemes are we really going to have? >=20 > > -----Original Message----- > > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > > Sent: Wednesday, January 26, 2011 12:49 AM > > To: William Mills > > Cc: OAuth WG > > Subject: RE: [OAUTH-WG] Bear token scheme name > > > > Thanks William. > > > > It is important to differentiate between style and substance (both of > > which are very important to people). > > > > Style-wise, we can use either of the three options below, but they are > > essentially the same. You take the string and put it through a parser > > and end up with the actual scheme name and some attributes. I don't > > really buy the arguments about namespaces and pollution. > > > > Creating a super scheme that then has to be extended for sub-schemes > > is actually a lot more complex. AFAIK, all the existing HTTP > > authentication schemes are not extensible (or at least have not been > > extended). There is something very helpful in moving extensibility out > > of the scheme so that a client that can speak it today can also speak > > it 10 years from now. If you need new options, create a new scheme. > > > > I like the scheme-per-type approach because it is modular and does not > > require much coordination. The lack of consensus we've seen between > > bearer tokens and mac tokens is an example. I don't want to have to > > negotiate parameter names and other formats when such collaboration > > will just slow both efforts and lead to no meaningful interoperability > > (given that the two token types are completely incompatible). > > > > The HTTP authentication headers are named poorly. The WWW- > Authenticate > > means 'you need to authenticate' and the Authorization header means > > 'here is my authentication credentials'. There is no actual > > authorization as implemented by OAuth (in terms of third party and > > grants). When talking about using a token to access a protected > > resource, we are dealing exclusively with authentication and should > > use the right HTTP vehicle for that. > > > > EHL > > > > > -----Original Message----- > > > From: William Mills [mailto:wmills@yahoo-inc.com] > > > Sent: Tuesday, January 25, 2011 11:23 PM > > > To: Eran Hammer-Lahav; Mike Jones > > > Cc: OAuth WG > > > Subject: RE: [OAUTH-WG] Bear token scheme name > > > > > > Back to Marius' question though, which is about how we determine how > > to > > > treat the Authenticate header when you see it. I, for one, was not > > happy > > > with the way that Wrap added on to the OAuth scheme. There are at > > least 3 > > > possibilities that it seems to be worth discussing: > > > > > > 1) a fixed scheme name with a variable indicating flavor, i.e. > > > Oauth2 authtype=3Dbearer, but we could go more agnostic like "Authz > > type=3Dbearer" if > > > OAuth2 really chafes. > > > > > > PRO: simple namespace > > > > > > 2) a scheme per auth type extension: i.e. bearer, MAC, SAML, etc. \ > > > > > > PRO: easy to extend, in no way semantically bound to OAuth > > > CON: namespace pollution and a proliferation of auth types > > > > > > 3) as yet un-discussed, we could reserve a namespace like oauth2_ > > > and > > use > > > things like oauth2_bearer. > > > > > > 2 and 3 are not exclusive. Are there more? > > > > > > There's also discussion that this is authorization, not > > authentication, and if we > > > really want to go there then the source of the problem might be that > > we're > > > choosing to overload the Authenticate header. Even more muddy, it's > > > entirely possible that a bearer token might contain a user > > credential. > > > > > > > > > > > > -----Original Message----- > > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] > > > > > > On > > > > Behalf > > > > > > Of Marius Scurtescu > > > > > > Sent: Tuesday, January 25, 2011 6:26 PM > > > > > > To: Mike Jones > > > > > > Cc: OAuth WG > > > > > > Subject: Re: [OAUTH-WG] Bear token scheme name > > > > > > > > > > > > On Wed, Jan 19, 2011 at 10:10 AM, Mike Jones > > > > > > wrote: > > > > > > > I'd like a sense from the working group whether others want > > this > > > > > > > change, and if so, what the name should be changed to. > > > > > > > > > > > > Probably this was debated, but I will ask again. > > > > > > > > > > > > Why can't we use "OAuth2" as the scheme in all cases and > > require a > > > > > > token_type name/value pair? > > > > > > > > > > > > Is it wise to dump lots of new schemes in a name space we do > > not > > > > control? > > > > > > > > > > > > Marius > > > > > > _______________________________________________ > > > > > > OAuth mailing list > > > > > > OAuth@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Wed Jan 26 08:57:17 2011 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 A22B13A6826 for ; Wed, 26 Jan 2011 08:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7QhUTqi3eIg for ; Wed, 26 Jan 2011 08:57:16 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id C9C4E3A6814 for ; Wed, 26 Jan 2011 08:57:15 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p0QH0Fvg028874 for ; Wed, 26 Jan 2011 09:00:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296061216; bh=ehJly9IwSIxUVFsexd2RdCj66BY=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=V8h6K63rNVGDuTJQ1MokCB5Uhm0O88XO/NK8WXe6BmeTuj8PrX443yAjuTFCGdFWx 84T6FksJRVsCVwskqcPoA== Received: from pvg6 (pvg6.prod.google.com [10.241.210.134]) by wpaz24.hot.corp.google.com with ESMTP id p0QH0D5G017913 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 09:00:14 -0800 Received: by pvg6 with SMTP id 6so117634pvg.23 for ; Wed, 26 Jan 2011 09:00:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FzJzrke4iyzN/GWJBH5PipWAHhP8k3K3Uv0vKbR/ngY=; b=C66UE7zU3DKgJKbTXISgVQo91QumaDgxUVvICo2u63VBP5NgHj6r7Mq20stxR5BijH fLikSG7OFYxmbav9alPQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ABfXnhW/rf/ID3gnyU0A/zo6ZvgogzHRRrhw0cR4bI5Eoe+BLeJQ70J+FDt3lz9QX1 DbM4wUu83x8gAJlUosmw== MIME-Version: 1.0 Received: by 10.142.224.4 with SMTP id w4mr582181wfg.304.1296061212636; Wed, 26 Jan 2011 09:00:12 -0800 (PST) Received: by 10.142.213.7 with HTTP; Wed, 26 Jan 2011 09:00:12 -0800 (PST) In-Reply-To: <1094924962-1296031502-cardhu_decombobulator_blackberry.rim.net-1267267110-@b1.c11.bise7.blackberry> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> <1094924962-1296031502-cardhu_decombobulator_blackberry.rim.net-1267267110-@b1.c11.bise7.blackberry> Date: Wed, 26 Jan 2011 09:00:12 -0800 Message-ID: From: Brian Eaton To: torsten@lodderstedt.net 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] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 26 Jan 2011 16:57:17 -0000 OK, thanks for clarifying. Back to your original questions. We've been handling this mostly in a single shared token endpoint. In a few cases we've gone with separate end-points because it made things easier. We've kept parameters such as scope consistent, since they are properties of the output token rather than the input authentication. Precedent of authentication methods hasn't been an issue - the client only sends one. We haven't done any work on discovery, because the client wouldn't be sending the authentication credentials if it didn't know what it was doing already. We've also done some work on authentication plug-ins that find the credentials on the machine and use them, without telling the calling application exactly where they came from. We've talked about SASL/GSSAPI/PAM/SSPI style integration, but so far that hasn't seemed like a high-value proposition. On Wed, Jan 26, 2011 at 12:45 AM, wrote: > Hi Brian, > > you identified the use cases correctly. No interactive user-consent would= be required. > > Regards, > Torsten. > Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland > > -----Original Message----- > From: Brian Eaton > Date: Tue, 25 Jan 2011 09:53:20 > To: Torsten Lodderstedt > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensend= point? > > Hey Torsten - > > I'm trying to parse through these messages to figure out the flows > you're interested in. > > I think you're aiming for rules like this one, right? > > kerberos authentication -> access token > > =A0 =A0or > > digest authentication -> access token > > And furthermore your intended use cases are applications installed on > an end-users machine, where the end-users machine participates in some > kind of authentication service. =A0For example, maybe the machine is > joined to some kerberos realm, or maybe the user has a smart card. > > Have I identified the use cases properly? =A0Or are you dealing with > three-legged OAuth situations, where you actually want user consent on > a web page? > > Cheers, > Brian > > On Tue, Jan 25, 2011 at 12:22 AM, Torsten Lodderstedt > wrote: >> Zitat von Eran Hammer-Lahav : >> >>> There is no clean way to do with without defining new HTTP authenticati= on >>> schemes. The token endpoints takes: >>> >>> 1. Client authentication >>> 2. Authorization grant >>> >>> There is no user authentication. Even the resource owner password >>> credentials is not user authentication but only validation of "some gra= nt >>> values". >> >> What's the difference from a conceptual point of view? In my opinion, th= e >> resource owners password is used for both, authenticating the resource o= wner >> and authorizing the token issuance. >> >>> >>> What you can do is define an authentication scheme which will authentic= ate >>> the client and provide the grant in one header, or >> >> the spec makes the grant type a required parameter, so a lonely >> authorization header won't be suffiencent. >> >>> define a new grant type for such credentials. But you can't use >> >> That brings us back to the mix between POST parameters and authz headers= for >> credential transmission. Something you critized for good reasons. >> >>> something like Basic or Digest to provide the resource owner's >>> credentials. That's against the endpoint design. >> >> It's good to know that restriction, but I'm not happy :-( So based on th= at >> information I would say, the only proper way to integrate standard HTTP >> schemes would be to invent another endpoint for that purpose. >> >> Comments? >> >> regards, >> Torsten. >> >>> >>> EHL >>> >>> >>>> -----Original Message----- >>>> From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net] >>>> Sent: Monday, January 24, 2011 10:35 PM >>>> To: Eran Hammer-Lahav; OAuth WG >>>> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with >>>> tokensendpoint? >>>> >>>> Hi Eran, >>>> >>>> thanks for your response. My inquiry was about end-user authentication >>>> and >>>> not about client authentication. All http schemes I'm aware of >>>> authenticate >>>> users and I want to find a way to leverage them with OAuth to determin= e >>>> the >>>> token's identity. >>>> >>>> Regards, >>>> Torsten. >>>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland >>>> >>>> -----Original Message----- >>>> From: Eran Hammer-Lahav >>>> Date: Mon, 24 Jan 2011 15:25:38 >>>> To: Torsten Lodderstedt; OAuth >>>> WG >>>> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >>>> endpoint? >>>> >>>> This is pretty straight-forward. There are no special parameters to >>>> indicated >>>> which client authentication is being used. It's either there or not, >>>> using >>>> whatever the server supports. >>>> >>>> Simply have the token endpoint return a 401 with these WWW-Authenticat= e >>>> headers. As long as you make it clear how to make between the client >>>> identifier and the credentials used, you are set. >>>> >>>> For example, a token response can return: >>>> >>>> 401 Unauthorized >>>> WWW-Authenticate: Basic realm=3D"example" >>>> WWW-Authenticate: Digest realm=3D"example" >>>> >>>> There is no discovery for support for the client_id and client_secret >>>> parameters. The client can simply try it or hardcode it based on the >>>> server's >>>> documentation. >>>> >>>> Does this help? >>>> >>>> EHL >>>> >>>> > -----Original Message----- >>>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Beha= lf >>>> > Of Torsten Lodderstedt >>>> > Sent: Monday, January 24, 2011 1:10 PM >>>> > To: OAuth WG >>>> > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens >>>> > endpoint? >>>> > >>>> > Hi all, >>>> > >>>> > I'm currently thinking about the integration of existing HTTP >>>> > authentication schemes with OAuth 2.0 for the purpose of end-user >>>> > authentication on the tokens endpoint. Possible candidates are "Dige= st" >>>> > for challenge-response-based username/password authentication and >>>> > "Spnego" for Kerberos-based authentication. Direct support for both >>>> > could be beneficially in enterprise and other security sensitive >>>> deployments. >>>> > >>>> > An direct integration with the tokens endpoint would allow to levera= ge >>>> > existing implementations and infrastructure for OAuth/HTTP-based >>>> > architectures. For example, HTTPClient has direct support for Spnego= - >>>> > Authentication. >>>> > >>>> > Both HTTP authentication schemes use dedicated WWW-Authenticate and >>>> > Authorization headers for passing credential and other data between >>>> > client and server. OAuth in contrast uses grant types to indicate th= e >>>> > authentication method, credentials are passed as URI query parameter= s >>>> > and it lacks any discovery of available authentication methods/ gran= t >>>> > types. >>>> > >>>> > How could one integrate existing schemes into that design? What is o= ur >>>> > story? Do we need to define a special grant type "HTTP authorization= "? >>>> > Shall Authorization headers overrule URI parameters? >>>> > >>>> > Any ideas of the WG are higly appreciated. >>>> > >>>> > regards, >>>> > Torsten. >>>> > >>>> > >>>> >_______________________________________________ >>>> > OAuth mailing 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 Wed Jan 26 08:58:24 2011 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 B8DA23A6814 for ; Wed, 26 Jan 2011 08:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.227 X-Spam-Level: X-Spam-Status: No, score=-105.227 tagged_above=-999 required=5 tests=[AWL=0.750, 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 WzoavPHbPOMN for ; Wed, 26 Jan 2011 08:58:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E64173A6804 for ; Wed, 26 Jan 2011 08:58:23 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p0QH1On5030926 for ; Wed, 26 Jan 2011 09:01:24 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296061284; bh=9ejyBjCNKE0E+SIwOEtl8EUdlB8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=JSwddXlYZOz9ESUqFIpXtmhkeKWX32GIjjoKfJruLMfHP0jKkRM46+jaKNjTXvKEx L3eS/KyeWGCuh+YhihxKA== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by wpaz1.hot.corp.google.com with ESMTP id p0QH1MCi015433 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 09:01:23 -0800 Received: by pzk28 with SMTP id 28so118288pzk.35 for ; Wed, 26 Jan 2011 09:01:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DfuYQ8OBMbWdq2+cU3McKYjccFWP5EVkCAfx0COc3fg=; b=iEKYkedQ+agib8cClJIXSY1DrWoS31PnQOZbeOPxdTd+B+lkUGhJTKlqfy70GOwQmM zmhouGW92jtE10CBf4Lg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EHf6eMHev0Pj3gJiPVKEouYQmDe+O5MCc8hWOnEH1S4NiGMpuNOb6RUlIjRd4JVMNb tJbITtCtTKrvbva30RjQ== MIME-Version: 1.0 Received: by 10.142.241.18 with SMTP id o18mr581224wfh.340.1296061282530; Wed, 26 Jan 2011 09:01:22 -0800 (PST) Received: by 10.142.213.7 with HTTP; Wed, 26 Jan 2011 09:01:22 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62544@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723445A8D62544@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 26 Jan 2011 09:01:22 -0800 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] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 26 Jan 2011 16:58:24 -0000 On Tue, Jan 25, 2011 at 10:58 PM, Eran Hammer-Lahav wrote: >> What's the difference from a conceptual point of view? In my opinion, the >> resource owners password is used for both, authenticating the resource >> owner and authorizing the token issuance. > > The resource owner is not present and therefore not being authenticated. OK, so it turns out that in this use case the resource owner is present, and is being authenticated. They happen to be using a client other than a web browser. From eran@hueniverse.com Wed Jan 26 09:04:51 2011 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 AC51F3A6801 for ; Wed, 26 Jan 2011 09:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 c4y4c+-SPM9h for ; Wed, 26 Jan 2011 09:04:51 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id DB3093A67DF for ; Wed, 26 Jan 2011 09:04:50 -0800 (PST) Received: (qmail 3652 invoked from network); 26 Jan 2011 17:07:51 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 17:07:51 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 26 Jan 2011 10:07:47 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 26 Jan 2011 10:07:28 -0700 Thread-Topic: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? Thread-Index: Acu9erQrBcKhkzAkRlyYPjCEDBYKZwAAJ+lg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62609@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723445A8D62544@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 26 Jan 2011 17:04:51 -0000 Can you share an actual example of how you are authenticating *both* the re= source owner and client in a single request? EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Wednesday, January 26, 2011 9:01 AM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokensendpoint? >=20 > On Tue, Jan 25, 2011 at 10:58 PM, Eran Hammer-Lahav > wrote: > >> What's the difference from a conceptual point of view? In my opinion, > >> the resource owners password is used for both, authenticating the > >> resource owner and authorizing the token issuance. > > > > The resource owner is not present and therefore not being authenticated= . >=20 > OK, so it turns out that in this use case the resource owner is present, = and is > being authenticated. They happen to be using a client other than a web > browser. From wmills@yahoo-inc.com Wed Jan 26 09:11:59 2011 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 4E07C3A6889 for ; Wed, 26 Jan 2011 09:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.372 X-Spam-Level: X-Spam-Status: No, score=-17.372 tagged_above=-999 required=5 tests=[AWL=-0.108, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, 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 n7FM1iBuQJN8 for ; Wed, 26 Jan 2011 09:11:58 -0800 (PST) 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 7FA643A6824 for ; Wed, 26 Jan 2011 09:11:58 -0800 (PST) Received: from SP2-EX07CAS03.ds.corp.yahoo.com (sp2-ex07cas03.corp.sp2.yahoo.com [98.137.59.35]) by mrout1-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0QHECRu057703; Wed, 26 Jan 2011 09:14:12 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS03.ds.corp.yahoo.com ([98.137.59.35]) with mapi; Wed, 26 Jan 2011 09:14:12 -0800 From: William Mills To: Justin Richer , Marius Scurtescu Date: Wed, 26 Jan 2011 09:14:04 -0800 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu9Y0OcpdGZeFrcSBiVBmfcS3QDNAAGRwCw Message-ID: References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1296051184.9984.5.camel@pulse> In-Reply-To: <1296051184.9984.5.camel@pulse> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 17:11:59 -0000 > > Broken record: using a prefix for all registered parameters is > > much cleaner (as opposed to requiring that all no-registered > > parameters use a prefix). >=20 > And once again, a strong +1 to this, even though I know it's far too > late to make such a breaking change to the spec. I really think this > was > a bad decision and is going to come back and bite us in the future. >=20 > -- Justin Yep. From skylar@kiva.org Wed Jan 26 09:29:44 2011 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 6D2BD3A69AB for ; Wed, 26 Jan 2011 09:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 V7+yQbPvz-6p for ; Wed, 26 Jan 2011 09:29:43 -0800 (PST) Received: from na3sys010aog102.obsmtp.com (na3sys010aog102.obsmtp.com [74.125.245.72]) by core3.amsl.com (Postfix) with SMTP id 54FE83A68D7 for ; Wed, 26 Jan 2011 09:29:43 -0800 (PST) Received: from source ([74.125.82.43]) (using TLSv1) by na3sys010aob102.postini.com ([74.125.244.12]) with SMTP ID DSNKTUBavEn/Zu9U1UDViRqX8qxArlfb3bt0@postini.com; Wed, 26 Jan 2011 09:32:44 PST Received: by wwi17 with SMTP id 17so1112688wwi.24 for ; Wed, 26 Jan 2011 09:32:43 -0800 (PST) Received: by 10.216.7.205 with SMTP id 55mr5120268wep.96.1296063162845; Wed, 26 Jan 2011 09:32:42 -0800 (PST) Received: from larwmobile.lacantine.lan (LPuteaux-156-16-100-112.w80-12.abo.wanadoo.fr [80.12.80.112]) by mx.google.com with ESMTPS id m6sm7898462wej.34.2011.01.26.09.32.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 26 Jan 2011 09:32:41 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Wed, 26 Jan 2011 18:32:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <155BD4E7-F8B3-4B4A-B02D-EAE2048A2F51@kiva.org> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1296051184.9984.5.camel@pulse> To: William Mills X-Mailer: Apple Mail (2.1082) Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 17:29:44 -0000 +1 More feedback on the token specs (and v12) is in my queue for tonight, = but this has also been a concern of mine and this seems to be a more = elegant protection against conflicts than adding a "version" parameter. On Jan 26, 2011, at 6:14 PM, William Mills wrote: >>> Broken record: using a prefix for all registered parameters is >>> much cleaner (as opposed to requiring that all no-registered >>> parameters use a prefix). >>=20 >> And once again, a strong +1 to this, even though I know it's far too >> late to make such a breaking change to the spec. I really think this >> was >> a bad decision and is going to come back and bite us in the future. >>=20 >> -- Justin >=20 > Yep. > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Wed Jan 26 09:47:46 2011 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 BD6B93A68D7 for ; Wed, 26 Jan 2011 09:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 7Kt7xJh43Xmq for ; Wed, 26 Jan 2011 09:47:46 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id D02D63A686A for ; Wed, 26 Jan 2011 09:47:45 -0800 (PST) Received: (qmail 16341 invoked from network); 26 Jan 2011 17:49:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 17:49:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 26 Jan 2011 10:49:15 -0700 From: Eran Hammer-Lahav To: "oauth@ietf.org" Date: Wed, 26 Jan 2011 10:48:56 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu9fw2TAoi7PCNRQJGvOTGSqyQnmgAAB9hw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6262E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1296051184.9984.5.camel@pulse> <155BD4E7-F8B3-4B4A-B02D-EAE2048A2F51@kiva.org> In-Reply-To: <155BD4E7-F8B3-4B4A-B02D-EAE2048A2F51@kiva.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 17:47:46 -0000 This is not aimed at anyone in particular. Replying +1 is not justification for a major breaking change. This was rais= ed in the past and consensus was that this is not a major concern. Over the= past 10 months not a single actual issue was raised about conflicts in leg= acy platforms. If you have an *actual* issue with a platform, please provid= e the full details, including why known mechanisms such as Apache rewrite r= ules can't solve the it. We're must be done discussing hypotheticals and theorizing about how this p= rotocol will get adopted by those not represented here. That was fine a yea= r ago, but at this point, whoever is in this group gets to make the decisio= n based on our collective deployment experience. I honestly can't be bother= ed to care about deployment issues in some undeclared legacy platforms no o= ne here is struggling with. I've been doing this work continuously for over three and a half years and = have learned that trying to optimize for the 'adoptions by others not prese= nt' is a complete waste of time. Suggesting that adoption will be significa= ntly affected because of lack of parameter prefix or the inclusion of half-= baked client assertion mechanism is just silly. =20 EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Skylar Woodward > Sent: Wednesday, January 26, 2011 9:33 AM > To: William Mills > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > +1 >=20 > More feedback on the token specs (and v12) is in my queue for tonight, bu= t > this has also been a concern of mine and this seems to be a more elegant > protection against conflicts than adding a "version" parameter. >=20 > On Jan 26, 2011, at 6:14 PM, William Mills wrote: >=20 > >>> Broken record: using a prefix for all registered parameters is much > >>> cleaner (as opposed to requiring that all no-registered parameters > >>> use a prefix). > >> > >> And once again, a strong +1 to this, even though I know it's far too > >> late to make such a breaking change to the spec. I really think this > >> was a bad decision and is going to come back and bite us in the > >> future. > >> > >> -- Justin > > > > Yep. > > _______________________________________________ > > 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 mscurtescu@google.com Wed Jan 26 12:06:46 2011 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 C49153A695D for ; Wed, 26 Jan 2011 12:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.246 X-Spam-Level: X-Spam-Status: No, score=-104.246 tagged_above=-999 required=5 tests=[AWL=-1.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 56JJEv3W8NOB for ; Wed, 26 Jan 2011 12:06:46 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id A5BB63A692D for ; Wed, 26 Jan 2011 12:06:45 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p0QK9jBn010144 for ; Wed, 26 Jan 2011 12:09:46 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296072586; bh=PDZEn3iQT/HeQPm4OfgKv4gAUK8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ORgpwvWvrv9dVtl7cZClw9Ptt9yNItAFZn9ll1Nt8q7z5ly9N7mgT3j7Q0uzB30MC MoaiDiRlBuhoyH38jr3pg== Received: from gxk19 (gxk19.prod.google.com [10.202.11.19]) by wpaz9.hot.corp.google.com with ESMTP id p0QK9IEE022286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 12:09:44 -0800 Received: by gxk19 with SMTP id 19so586247gxk.25 for ; Wed, 26 Jan 2011 12:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yCTxZzMUIyOqfr2xXmE/gq4XK7Zfr3eTctQY0+ATn9Q=; b=kX8dqWOfhJ1LFgtJgUAHip4BroKZkw/irhyygWmmvedCOZ6XUy46nzO2rDkr9orLNS 5kC0PtJcw5ryJejcEJFQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=m/DgfjaZno+DRscDZC0TXuT8n3A86ikN8J8KcfQVt4cPmxRboziYDIRgwsUgfy4ni1 4/nV8Ndka8IA7xsQt3uA== Received: by 10.100.196.1 with SMTP id t1mr5379182anf.44.1296072584457; Wed, 26 Jan 2011 12:09:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Wed, 26 Jan 2011 12:09:24 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 26 Jan 2011 12:09:24 -0800 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 -12 feedback deadline 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, 26 Jan 2011 20:06:46 -0000 - 4.1. Authorization Code. It is stated that authorization code is suitable for clients that can hold a secret. Not necessarily true, it is the best flow for native apps, for example. - 4.1.2 Authorization Response. Minor typo in last sentence on page 16: "size of any value is issues" => "size of any value it issues"? - 4.1.3. Access Token Request. redirect_uri is required, and must match the one in the original request. But the one in the original request is sort of optional (if registration provides one). - 4.3. Resource Owner Password Credentials. The 3rd paragraph states that the client MUST discard the credentials once it obtains an access token. I think it SHOULD discard once it obtains a *refresh* token. - 4.5. Extensions. For new grant types, we are not using a registry. Is that OK? - 5.2. Error Response. The fist part of the first paragraph talks about 401 and client credentials in the Authorization header. Since this was dropped from core, this looks strange. And there are the other two issues I raised in a separate thread. Thanks, Marius On Wed, Jan 26, 2011 at 12:59 AM, Eran Hammer-Lahav wrote: > I plan to publish a quick fix to editorial issues raised in a -13 on Monday > 1/31. If you have editorial feedback, please post it to the list by Friday > 1/28 so that I can respond and incorporate if needed. This is not a deadline > for normative issues, only editorial, but you can post feedback on both. I > plan to request an official WG review of -13 to begin next week. > > > > EHL > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > From mscurtescu@google.com Wed Jan 26 13:11:54 2011 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 6C2D33A69D2 for ; Wed, 26 Jan 2011 13:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.175 X-Spam-Level: X-Spam-Status: No, score=-104.175 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 wBMhlqX-+gU6 for ; Wed, 26 Jan 2011 13:11:53 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id CB7873A68E6 for ; Wed, 26 Jan 2011 13:11:50 -0800 (PST) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p0QLEo2G001503 for ; Wed, 26 Jan 2011 13:14:51 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296076491; bh=/KtIPiKBSIYlbIWDdAMfc2P/BIo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=C4LeVf3hUYCmjrDZZ6zIxXjHmMKNwkZDo1glCngEgBGKGix46b+s6IIKKlSA6jZDj nyqaVZ7T5vluV30T4mX7w== Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by wpaz5.hot.corp.google.com with ESMTP id p0QLEcks021392 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 13:14:49 -0800 Received: by yxt33 with SMTP id 33so284379yxt.1 for ; Wed, 26 Jan 2011 13:14:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=hrdM1dMEPWkYmeOhha9QfbdzyJN3qNO+noaL0rHfbYI=; b=UqK2RddH7rwxsKZAKiiIuEHX0wcAR0/4j7V2yATCxwjkQk/nY6gGkCgKLa8zt8ElSk 4GnkFL+htIfYiapmXDOQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=Pph9CyOcMUJHReeviEUgXugxFngzAooSzxFgFGDKJhEAHfdQcR0joloRiIatMFnpIh aTNLhdZrubPm4tW/LQ9w== Received: by 10.100.227.17 with SMTP id z17mr159469ang.214.1296076489194; Wed, 26 Jan 2011 13:14:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Wed, 26 Jan 2011 13:14:29 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> From: Marius Scurtescu Date: Wed, 26 Jan 2011 13:14:29 -0800 Message-ID: To: William Mills 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] Bear token scheme name 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, 26 Jan 2011 21:11:54 -0000 On Tue, Jan 25, 2011 at 6:34 PM, William Mills wrote= : > As I remember there was serious objection by a few to putting versioning = in the scheme name. =A0OAuth, OAuth2, and soon we're on OAuthN+1 seemed to = be the objection. =A0Some are passionate about it and no one was sufficient= ly passionate about going with OAuth2 and some kind of token_type. Sure, then we can use something version agnostic like "OAuth". And maybe add a version name/value pair if needed (OAuth 1 has one). > Logically token_type doesn't actually fully describe the possibilities, s= ince we can extend to signed requests etc that don't include a token per se= . Can you give an example that make sense with OAuth? If there is no token then that's not OAuth IMO. > So... =A0since the extensions were going to be broken out into their own = specs, I believe the thought was to have those specs define their own names= paces. =A0There is certainly a land grab problem there on the scheme namesp= ace. > > I personally don't have a preference, but it does seem cleaner to me to h= ave an IANA style registry for the OAuth2 auth_subtype=3D or some such. Yes, I think that's much cleaner. Marius From torsten@lodderstedt.net Wed Jan 26 13:19:27 2011 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 42EDA3A69DF for ; Wed, 26 Jan 2011 13:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.013, 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 nAjJFwT+A4Gs for ; Wed, 26 Jan 2011 13:19:25 -0800 (PST) Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.93]) by core3.amsl.com (Postfix) with ESMTP id 2405A3A69DA for ; Wed, 26 Jan 2011 13:19:24 -0800 (PST) Received: from [79.253.24.159] (helo=[192.168.71.49]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PiCoq-0001UN-BC; Wed, 26 Jan 2011 22:22:24 +0100 Message-ID: <4D409092.80106@lodderstedt.net> Date: Wed, 26 Jan 2011 22:22:26 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Freeman, Tim" References: <59DD1BA8FD3C0F4C90771C18F2B5B53A6532547F10@GVW0432EXB.americas.hpqcorp.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F3F0703@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4C8B3721.7000208@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3F3F0A42@P3PW5EX1MB01.EX1.SECURESERVER.NET> <59DD1BA8FD3C0F4C90771C18F2B5B53A6532D8358E@GVW0432EXB.americas.hpqcorp.net> In-Reply-To: <59DD1BA8FD3C0F4C90771C18F2B5B53A6532D8358E@GVW0432EXB.americas.hpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Df-Sender: torsten@lodderstedt-online.de Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] Why give the redirect URI when trading an [authorization] code for an access token? 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, 26 Jan 2011 21:19:27 -0000 Hi Tim, > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] >> 1. Evil user starts the OAuth flow on the client using the web-server flow. >> 2. Client redirects the evil user to the authorization server, including state >> information about the evil user account on the client. >> 3. Evil user takes the authorization endpoint URI and changes the >> redirection to its own site. >> 4. Evil user tricks victim user to click on the link and authorize access >> (phishing or other social engineering attack). >> 5. Victim user thinking this is a valid authorization request, authorizes >> access. >> 6. Authorization server sends victim user back to the client, but since the >> redirection URI was changed, back to the evil user site. > and the rest of the steps were revised to: > >> 7. Evil user takes the code and gives it back to the client by >> constructing the original correct redirection URI. >> 8. Client exchanges the code for access token, attaching it to the evil user's account. >> 9. Evil user can now access victim user data on his client account. > Step 6 requires the authorization server to redirect the victim user's browser to the evil user's site, which will only happen if the authorization server does not check the redirect URI when returning an authorization code. That check is required by OAuth 2, and isn't the check that I'm questioning. The authorization server either checks the actual redirect_uri against a pre-configured uri (step 4) and it checks the actual redirect_uri in step 8. The first check immediately detects attempts to acquire end-user authorization under the identity of a legimitate client. That's fine as long as the authorization server really forces all clients to pre-register redirect_uri's. That approach might not scale in some deployments (manual process) or require dynamic client registration (not specified yet). With the lack of dynamic client registration, it only works for clients bound to certain deployments at development/configuration time. As soon as dynamic resource server discovery gets involved, that's no longer feasable. The later check detects different uri's used for the end-user authorization process and the token issuance. That's the characteristics of a session fixation attack since the attacker MUST use another redirect_uri in steps 2 and 4. Otherwise it does not get access to the authorization code of the victim. This approach has the drawback that the redirect_uri must be associated with the authorization code but it works for all kinds of deployments and anonymous clients. > In contrast, I was proposing that the authorization server not check the redirect URI when it returns an access token. Since, in the absence of such a check, the redirect URI is neither checked nor used to compute the result of the query, I was proposing that we drop the redirect URL from that step of the protocol altogether. > > I misspoke in the subject line of the email that started this thread, so I just now changed "access code" there to "authorization code". We have access tokens and authorization codes, but not authorization tokens or access codes. > > After some thought, I think I see the real problem with omitting the check on redirect_uri. Without the check, the following can happen: > > 1. Evil user starts OAuth flow on the client using the web-server flow, using a hacked web browser. > 2. The hacked web browser does the normal thing in the flow, requesting the evil user's username and password, and at the end the hacked browser is given a redirect like: > > https://www.goodclient.com/oauth/evilUserAcct?code=evilAuthCode > > The hacked browser saves evilAuthCode and does not perform the redirect. > 3. Suppose the evil user's web site can persuade a known victim user with a normal browser to visit goodclient's web site and do OAuth. The victim's user id on the client is public knowledge, and the evil user's web site persuaded the victim to start OAuth at a known time, so it can guess when the victim will complete the OAuth exchange. Before then, the evil web site can visit > > https://www.goodclient.com/oauth/victimUserAcct?code=evilAuthCode > > which is likely to leave the client associating the victim's user id with an access token that accesses resources controlled by the evil user. Your assumptions is the attacker is able to predict the way the victim's session with the client is represented. I would consider that as a security vulnerability of the client since this would also allow the attacker to take over the session on his own device. > Checking the redirect URI doesn't solve the problem in the case where the user id on the client is encoded in the "state" opaque value instead of the redirect URI. > > Saying "The authorization server SHOULD require the client to pre-register their redirection URI" (page 17 of http://tools.ietf.org/html/draft-ietf-oauth-v2-10) should have MUST instead of SHOULD, since it is important that we're really redirecting to the client when we're distributing the authorization code by redirecting. See above. From a security perspective this is clearly a good option. From an architectural and operational point of view, I would consider this to restrictive. regards, Torsten. > > Writing the spec required thinking through these cases. It would be helpful if the use cases were added to the spec, so people don't have to rediscover them, and errors in the use cases can be discovered and fixed rather than being made repeatedly by each person rediscovering the use case. > > Tim Freeman > Email: tim.freeman@hp.com > Desk in Palo Alto: (650) 857-2581 > Home: (408) 774-1298 > Cell: (408) 348-7536 > > > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Saturday, September 11, 2010 7:59 AM > To: Torsten Lodderstedt > Cc: Freeman, Tim; oauth@ietf.org > Subject: RE: [OAUTH-WG] Why give the redirect URI when trading an access code for an access token? > > Sorry. > > 7. Evil user takes the code and gives it back to the client by constructing the original correct redirection URI. > 8. Client exchanges the code for access token, attaching it to the evil user's account. > 9. Evil user can now access victim user data on his client account. > > This is basically a session fixation attack. > > EHL > >> -----Original Message----- >> From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] >> Sent: Saturday, September 11, 2010 1:01 AM >> To: Eran Hammer-Lahav >> Cc: Freeman, Tim; oauth@ietf.org >> Subject: Re: [OAUTH-WG] Why give the redirect URI when trading an access >> code for an access token? >> >> Doesn't step 7 require the evil user to know the client's secret? >> >> Am 10.09.2010 17:06, schrieb Eran Hammer-Lahav: >>> 1. Evil user starts the OAuth flow on the client using the web-server flow. >>> 2. Client redirects the evil user to the authorization server, including state >> information about the evil user account on the client. >>> 3. Evil user takes the authorization endpoint URI and changes the >> redirection to its own site. >>> 4. Evil user tricks victim user to click on the link and authorize access >> (phishing or other social engineering attack). >>> 5. Victim user thinking this is a valid authorization request, authorizes >> access. >>> 6. Authorization server sends victim user back to the client, but since the >> redirection URI was changed, back to the evil user site. >>> 7. Evil user grabs the code and exchanges it for an access token. >>> >>> By checking that the callback URI used to deliver the code is the same as >> the one used to initiate the flow, the authorization server can verify that the >> user who initiated the flow is the same one to authorize access and finish the >> flow. >>> EHL >>> >>>> -----Original Message----- >>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On >>>> Behalf Of Freeman, Tim >>>> Sent: Wednesday, September 08, 2010 8:05 PM >>>> To: oauth@ietf.org >>>> Subject: [OAUTH-WG] Why give the redirect URI when trading an access >>>> code for an access token? >>>> >>>> Hi. I'm new here. I searched the archives a bit and didn't >>>> immediately find an answer to my question below. My apologies if >>>> there was some previous discussion of this that I missed. >>>> >>>> Looking at the draft spec at >>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-10, >>>> I see in section 4.1.1 "Authorization code" on page 22 that it is >>>> required to give the redirect_uri of the original request when >>>> exchanging an authorization code for an access token, and the >>>> authorization server must verify that the redirection URI is correct as well >> as the authorization code. >>>> Based on section 4.2 "Access Token Response" on page 25, it seems >>>> that the redirect_uri is not used when constructing the response from >>>> the authorization server. >>>> >>>> So far as I can tell, the redirect_uri is useless in this request. >>>> It does not contain any secrets. The authorization code is verified >>>> and is meant to be an arbitrary unguessable identifier, so little is >>>> gained by verifying the redirect_uri also. It is not used to construct the >> reply. Why is it required? >>>> Tim Freeman >>>> Email: tim.freeman@hp.com >>>> Desk in Palo Alto: (650) 857-2581 >>>> Home: (408) 774-1298 >>>> Cell: (408) 348-7536 >>>> >>>> >>>> _______________________________________________ >>>> OAuth mailing 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 Wed Jan 26 13:20:21 2011 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 F1FE83A69DF for ; Wed, 26 Jan 2011 13:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.112 X-Spam-Level: X-Spam-Status: No, score=-104.112 tagged_above=-999 required=5 tests=[AWL=-1.135, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 vcYgUYahirQi for ; Wed, 26 Jan 2011 13:20:14 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 6B6963A69E5 for ; Wed, 26 Jan 2011 13:20:12 -0800 (PST) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p0QLNCdG014169 for ; Wed, 26 Jan 2011 13:23:13 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296076993; bh=T7Mcy7wHJKGffpp4CIbs6986PvM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=mcYYsc5JW7TIzJ09IHlZCMqNbCIDimJIajCgjHf8W95qbPCi9NCry3kqJi3G6DwtY JQR53eY7KDtiD/fLeYB4Q== Received: from yic1 (yic1.prod.google.com [10.243.65.129]) by wpaz24.hot.corp.google.com with ESMTP id p0QLN7Au009135 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 13:23:10 -0800 Received: by yic1 with SMTP id 1so302676yic.39 for ; Wed, 26 Jan 2011 13:23:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Dv5BNyAF+o3KB7ht3rFjj5z84NnI6EQ3eIwyp3oN9Ss=; b=wc+v+tXjqHXwGNfTfabTK38P9w41IA7wCVHovGFW9bHhDignYA3krhs0/MYvOkxtPe ISUZXLy6VzxnQT6rv5GQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=fvO+XdNk1oc/AUS+zNI9juyUR23KzbOU1scI0gFuPBQQImG3To0A8fjBOqsGPJ59c2 U2HvWCXJZxCL+BZrHf2w== Received: by 10.100.164.2 with SMTP id m2mr5354034ane.146.1296076987058; Wed, 26 Jan 2011 13:23:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Wed, 26 Jan 2011 13:22:46 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 26 Jan 2011 13:22:46 -0800 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] Bear token scheme name 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, 26 Jan 2011 21:20:21 -0000 On Tue, Jan 25, 2011 at 9:59 PM, Eran Hammer-Lahav wr= ote: > Simply because authentication is not what OAuth is about. > > OAuth is an authorization protocol for issuing access tokens. Access toke= ns can have different properties and therefore need different schemes. I wa= s the first to suggest a scheme with sub-schemes but that idea was strongly= rejected (over a year ago). Since then I came to the same conclusion that = the proper way is to define separate authentication schemes. It is also how= most HTTP authentication framework operate. > > One benefit to this approach is that HTTP authentication already covers t= he discovery of which schemes are supported by the resource server, as well= as token schemes can be used independently from OAuth, something the 2-leg= ged OAuth 1.0 has shown has great value. Also, it keeps the protocol modula= r which enable providers to tailor it to their security needs. > > OAuth 2.0 is authentication agnostic and must remain so. It is an authori= zation protocol and as such has no business defining authentication mechani= sms. > > For this reason, I object to using the OAuth2 scheme name with the bearer= token scheme. It's a "trademark" issue. I can definitely see your point, but look at the end result. OAuth is useless with an authentication mechanism so now a bunch of similar authentication mechanisms are reinvented in related specifications. All geared to work with OAuth 2, none of them really trying to define something generic. Marius From mscurtescu@google.com Wed Jan 26 13:29:33 2011 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 1BC383A68B1 for ; Wed, 26 Jan 2011 13:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.803 X-Spam-Level: X-Spam-Status: No, score=-105.803 tagged_above=-999 required=5 tests=[AWL=0.174, 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 XWj2tG6gmCvO for ; Wed, 26 Jan 2011 13:29:32 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 362773A6893 for ; Wed, 26 Jan 2011 13:29:32 -0800 (PST) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p0QLWWCF006792 for ; Wed, 26 Jan 2011 13:32:33 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296077553; bh=0P4q5Ey5tDlUHNYquWZPThNIedw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ROp/sG8n0tHWCzMpsFTSsIRgwdreMkFxtVxCpBGUs2csYZQNVX8LJGCXoPC7/uk0K Vb6Te09Y6Flp2/d9QMdMQ== Received: from yws5 (yws5.prod.google.com [10.192.19.5]) by hpaq14.eem.corp.google.com with ESMTP id p0QLWUAS012738 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 13:32:31 -0800 Received: by yws5 with SMTP id 5so348179yws.29 for ; Wed, 26 Jan 2011 13:32:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=Fe6Irj3AOU/TIyDL0R87sW7CiIkA7kRjp4jzhB8REXc=; b=uc1lGspLpMbx3Xnw+jSZnmyy2AvjK5q+RI05rARobLlWXKh5/CdS+ilQVtr3QcaAp9 gu/JPVrVIPGU8izpik8g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=fssKd6Jsv4VQ0AerrvMhFGNmYKSE1UmmbVAF4FMcqttLlVBJdVihDkbGFRftjJ+vy8 rV0dy6YYS9qU1dKMTf6Q== Received: by 10.100.163.6 with SMTP id l6mr5443613ane.10.1296077550434; Wed, 26 Jan 2011 13:32:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Wed, 26 Jan 2011 13:32:10 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6262E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1296051184.9984.5.camel@pulse> <155BD4E7-F8B3-4B4A-B02D-EAE2048A2F51@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8D6262E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 26 Jan 2011 13:32:10 -0800 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@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 21:29:33 -0000 On Wed, Jan 26, 2011 at 9:48 AM, Eran Hammer-Lahav wr= ote: > This is not aimed at anyone in particular. > > Replying +1 is not justification for a major breaking change. This was ra= ised in the past and consensus was that this is not a major concern. Over t= he past 10 months not a single actual issue was raised about conflicts in l= egacy platforms. If you have an *actual* issue with a platform, please prov= ide the full details, including why known mechanisms such as Apache rewrite= rules can't solve the it. I just raised an actual issue. Because OAuth 2 parameters are not prefixed, starting with v11 the spec requires all other parameters to use the "x_" prefix. Google cannot comply with that. Dropping the x_ requirement is good enough IMO. If you are worried about that, then you are probably afraid of an actual issue as well. Marius From mscurtescu@google.com Wed Jan 26 13:40:08 2011 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 A30EA3A68A0 for ; Wed, 26 Jan 2011 13:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.812 X-Spam-Level: X-Spam-Status: No, score=-105.812 tagged_above=-999 required=5 tests=[AWL=0.165, 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 5La8OexxFX-5 for ; Wed, 26 Jan 2011 13:40:07 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 9C53E3A6893 for ; Wed, 26 Jan 2011 13:40:07 -0800 (PST) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p0QLh88i020898 for ; Wed, 26 Jan 2011 13:43:09 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296078189; bh=gDyI41W6/94zaAk79jMQlPhtjBA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=lH+5JshWq6bqimHU9MQ2vRlM9Vd+hj+1/c/pWmdKRfxbIXWqkGb+xnUm+Z3oqrXmi OMvYWq1TgVSVclFZXLRtg== Received: from ywi6 (ywi6.prod.google.com [10.192.9.6]) by kpbe19.cbf.corp.google.com with ESMTP id p0QLgrcv008647 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 13:43:07 -0800 Received: by ywi6 with SMTP id 6so321935ywi.6 for ; Wed, 26 Jan 2011 13:43:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=yQrzEoe2PVpHCQAdAF92g5hS3xANBIvza+4Wb6H0gzE=; b=XzZGzpAxz8meoT3x/eazaPPPk4fTqEQMJZH7UkERujsmmTE+Pu8RLe8jmkua+vT20z VBujAJKxVEB5oNh8D7Dw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=QdTosmZ9kEd0+45dPE88R6GW6wKN8xQEs7zLz9jehXyTWYtSDGuU0IylWEdZm0lNqL xTiWsyzrhXucoD4Aswwg== Received: by 10.100.227.17 with SMTP id z17mr178433ang.214.1296078187329; Wed, 26 Jan 2011 13:43:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Wed, 26 Jan 2011 13:42:47 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62545@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62545@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 26 Jan 2011 13:42:47 -0800 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@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 21:40:08 -0000 On Tue, Jan 25, 2011 at 11:08 PM, Eran Hammer-Lahav w= rote: > Thanks Marius. > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurtescu@google.com] >> Sent: Tuesday, January 25, 2011 5:02 PM >> To: Eran Hammer-Lahav >> Cc: oauth@ietf.org >> Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >> >> On Thu, Jan 20, 2011 at 9:41 PM, Eran Hammer-Lahav >> wrote: >> > Forgot to mention that I don't have any outstanding comments in my >> queue so if your feedback was not incorporated into -12, and you feel >> strongly about it, bring it up again. >> >> From an older email, adapted to v12: >> >> >> 1. The token_type parameter is required in responses from the server. >> If the server supports multiple formats, which one will be used? In this= case, >> would it make sense to allow the client to request a specific format? >> >> For example, if the authorization server supports both MAC and BEARER, >> which one will the server issue? > > It might in some cases, but I suspect most providers are going to decide = which scheme provides the right level of security for them and just use tha= t. If you are going to allow both MAC and BEARER, you are basically letting= clients decide which level to operate at. Do you have a need or plan to su= pport multiple token types? For now we are planning to support only bearer, but I am sure some form of signed tokens will follow sooner than later. At which point we would have to support both. In most cases I think it is up to the client to decide. >> 2. Section 8.2. What about applications using legacy parameters? Does no= t >> make much sense to register them, and they cannot be changed to x_. >> Broken record: using a prefix for all registered parameters is much clea= ner (as >> opposed to requiring that all no-registered parameters use a prefix). >> >> For Google it is impossible to comply with this requirement. > > What legacy parameters do you have? Since OAuth 2.0 endpoints are brand n= ew, this is probably about extension parameters in the authorization endpoi= nt from OAuth 1.0 or AuthSub? I think the legacy parameters problem is pret= ty small, given the number of existing *token* and *authorization* endpoint= s with custom parameters (that were not pulled into the specification such = as scope), but it would be good to know what we are dealing with. It is about parameters used by the authentication endpoints (aka login page). The new OAuth 2 endpoints have no control over that. > Overall, this is a pretty minor issue. I assume you don't have any confli= cts today with the v2 specification. Any conflicts you might have in the fu= ture (for which this x_ prefix is meant for) with new extensions is probabl= y going to be minor. And Google can always join the work to make sure they = pick a less conflicting name... this is where the registration process real= ly helps to avoid clashes. I don't think it makes much sense to register these existing parameters, and they cannot be changed either. I guess that other authorization servers will have similar issues. Here are some examples from the top of my head: - hd - domain hint, for hosted domain - hl - language selecter - authuser - multiple session user selector Marius From torsten@lodderstedt.net Wed Jan 26 13:40:24 2011 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 DE59C3A68A0 for ; Wed, 26 Jan 2011 13:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.012, 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 lt+cbZCbiSx3 for ; Wed, 26 Jan 2011 13:40:23 -0800 (PST) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by core3.amsl.com (Postfix) with ESMTP id B5EEE3A6893 for ; Wed, 26 Jan 2011 13:40:22 -0800 (PST) Received: from [79.253.24.159] (helo=[192.168.71.49]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1PiD98-0004A1-Aj; Wed, 26 Jan 2011 22:43:22 +0100 Message-ID: <4D40957C.901@lodderstedt.net> Date: Wed, 26 Jan 2011 22:43:24 +0100 From: Torsten Lodderstedt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bob Gregory References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090201090406020207020406" X-Df-Sender: torsten@lodderstedt-online.de Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 26 Jan 2011 21:40:25 -0000 This is a multi-part message in MIME format. --------------090201090406020207020406 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Am 25.01.2011 10:25, schrieb Bob Gregory: > Perhaps I'm missing something here, but once a client has requested an > access grant, the auth server is free to authenticate the end-user in > whatever way it chooses, and it would seem sensible to signal authn > requirements with standard HTTP headers. > > Why, then, would you want to integrate existing HTTP schemes at the > token endpoint instead of at the authorization endpoint? You certainly can integrate HTTP authentication schemes into the end-user authorization endpoint. But this endpoint is intended to be used for direct interaction between end-user and authorization server and requires to open a web browser. That's something one probably does not want for on certain devices (handsets, gaming devices) or if no user consent is required (enterprise). So I'm looking into cases, where the client wants to directly exchange credentials, such as password or ticket for an access token. I mean the resource owner password flow is already an example of such a flow. regards, Torsten. > > -- Bob Gregory > > On Tue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt > > wrote: > > Zitat von Eran Hammer-Lahav >: > > > There is no clean way to do with without defining new HTTP > > authentication schemes. The token endpoints takes: > > > > 1. Client authentication > > 2. Authorization grant > > > > There is no user authentication. Even the resource owner password > > credentials is not user authentication but only validation of "some > > grant values". > > What's the difference from a conceptual point of view? In my opinion, > the resource owners password is used for both, authenticating the > resource owner and authorizing the token issuance. > > > > > What you can do is define an authentication scheme which will > > authenticate the client and provide the grant in one header, or > > the spec makes the grant type a required parameter, so a lonely > authorization header won't be suffiencent. > > > define a new grant type for such credentials. But you can't use > > That brings us back to the mix between POST parameters and authz > headers for credential transmission. Something you critized for good > reasons. > > > something like Basic or Digest to provide the resource owner's > > credentials. That's against the endpoint design. > > It's good to know that restriction, but I'm not happy :-( So based on > that information I would say, the only proper way to integrate > standard HTTP schemes would be to invent another endpoint for that > purpose. > > Comments? > > regards, > Torsten. > > > > > EHL > > > > > >> -----Original Message----- > >> From: torsten@lodderstedt.net > [mailto:torsten@lodderstedt.net ] > >> Sent: Monday, January 24, 2011 10:35 PM > >> To: Eran Hammer-Lahav; OAuth WG > >> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > >> tokensendpoint? > >> > >> Hi Eran, > >> > >> thanks for your response. My inquiry was about end-user > authentication and > >> not about client authentication. All http schemes I'm aware of > authenticate > >> users and I want to find a way to leverage them with OAuth to > determine the > >> token's identity. > >> > >> Regards, > >> Torsten. > >> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland > >> > >> -----Original Message----- > >> From: Eran Hammer-Lahav > > >> Date: Mon, 24 Jan 2011 15:25:38 > >> To: Torsten Lodderstedt >; OAuth > >> WG> > >> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokens > >> endpoint? > >> > >> This is pretty straight-forward. There are no special parameters to > >> indicated > >> which client authentication is being used. It's either there or > not, using > >> whatever the server supports. > >> > >> Simply have the token endpoint return a 401 with these > WWW-Authenticate > >> headers. As long as you make it clear how to make between the > client > >> identifier and the credentials used, you are set. > >> > >> For example, a token response can return: > >> > >> 401 Unauthorized > >> WWW-Authenticate: Basic realm="example" > >> WWW-Authenticate: Digest realm="example" > >> > >> There is no discovery for support for the client_id and > client_secret > >> parameters. The client can simply try it or hardcode it based on > >> the server's > >> documentation. > >> > >> Does this help? > >> > >> EHL > >> > >> > -----Original Message----- > >> > From: oauth-bounces@ietf.org > [mailto:oauth-bounces@ietf.org ] On > Behalf > >> > Of Torsten Lodderstedt > >> > Sent: Monday, January 24, 2011 1:10 PM > >> > To: OAuth WG > >> > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokens > >> > endpoint? > >> > > >> > Hi all, > >> > > >> > I'm currently thinking about the integration of existing HTTP > >> > authentication schemes with OAuth 2.0 for the purpose of end-user > >> > authentication on the tokens endpoint. Possible candidates > are "Digest" > >> > for challenge-response-based username/password authentication and > >> > "Spnego" for Kerberos-based authentication. Direct support > for both > >> > could be beneficially in enterprise and other security sensitive > >> deployments. > >> > > >> > An direct integration with the tokens endpoint would allow to > leverage > >> > existing implementations and infrastructure for OAuth/HTTP-based > >> > architectures. For example, HTTPClient has direct support for > Spnego- > >> > Authentication. > >> > > >> > Both HTTP authentication schemes use dedicated > WWW-Authenticate and > >> > Authorization headers for passing credential and other data > between > >> > client and server. OAuth in contrast uses grant types to > indicate the > >> > authentication method, credentials are passed as URI query > parameters > >> > and it lacks any discovery of available authentication methods/ > >> grant types. > >> > > >> > How could one integrate existing schemes into that design? > What is our > >> > story? Do we need to define a special grant type "HTTP > authorization"? > >> > Shall Authorization headers overrule URI parameters? > >> > > >> > Any ideas of the WG are higly appreciated. > >> > > >> > regards, > >> > Torsten. > >> > > >> > > >> >_______________________________________________ > >> > OAuth mailing list > >> > OAuth@ietf.org > >> > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > --------------090201090406020207020406 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Am 25.01.2011 10:25, schrieb Bob Gregory:
Perhaps I'm missing something here, but once a client has requested an access grant, the auth server is free to authenticate the end-user in whatever way it chooses, and it would seem sensible to signal authn requirements with standard HTTP headers.

Why, then, would you want to integrate existing HTTP schemes at the token endpoint instead of at the authorization endpoint?

You certainly can integrate HTTP authentication schemes into the end-user authorization endpoint. But this endpoint is intended to be used for direct interaction between end-user and authorization server and requires to open a web browser. That's something one probably does not want for on certain devices (handsets, gaming devices) or if no user consent is required (enterprise). So I'm looking into cases, where the client wants to directly exchange credentials, such as password or ticket for an access token. I mean the resource owner password flow is already an example of such a flow.

regards,
Torsten. 


-- Bob Gregory

On Tue, Jan 25, 2011 at 8:22 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:
Zitat von Eran Hammer-Lahav <eran@hueniverse.com>:

> There is no clean way to do with without defining new HTTP
> authentication schemes. The token endpoints takes:
>
> 1. Client authentication
> 2. Authorization grant
>
> There is no user authentication. Even the resource owner password
> credentials is not user authentication but only validation of "some
> grant values".

What's the difference from a conceptual point of view? In my opinion,
the resource owners password is used for both, authenticating the
resource owner and authorizing the token issuance.

>
> What you can do is define an authentication scheme which will
> authenticate the client and provide the grant in one header, or

the spec makes the grant type a required parameter, so a lonely
authorization header won't be suffiencent.

> define a new grant type for such credentials. But you can't use

That brings us back to the mix between POST parameters and authz
headers for credential transmission. Something you critized for good
reasons.

> something like Basic or Digest to provide the resource owner's
> credentials. That's against the endpoint design.

It's good to know that restriction, but I'm not happy :-( So based on
that information I would say, the only proper way to integrate
standard HTTP schemes would be to invent another endpoint for that
purpose.

Comments?

regards,
Torsten.

>
> EHL
>
>
>> -----Original Message-----
>> From: torsten@lodderstedt.net [mailto:torsten@lodderstedt.net]
>> Sent: Monday, January 24, 2011 10:35 PM
>> To: Eran Hammer-Lahav; OAuth WG
>> Subject: AW: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with
>> tokensendpoint?
>>
>> Hi Eran,
>>
>> thanks for your response. My inquiry was about end-user authentication and
>> not about client authentication. All http schemes I'm aware of authenticate
>> users and I want to find a way to leverage them with OAuth to determine the
>> token's identity.
>>
>> Regards,
>> Torsten.
>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
>>
>> -----Original Message-----
>> From: Eran Hammer-Lahav <eran@hueniverse.com>
>> Date: Mon, 24 Jan 2011 15:25:38
>> To: Torsten Lodderstedt<torsten@lodderstedt.net>; OAuth
>> WG<oauth@ietf.org>
>> Subject: RE: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
>> endpoint?
>>
>> This is pretty straight-forward. There are no special parameters to
>> indicated
>> which client authentication is being used. It's either there or not, using
>> whatever the server supports.
>>
>> Simply have the token endpoint return a 401 with these WWW-Authenticate
>> headers. As long as you make it clear how to make between the client
>> identifier and the credentials used, you are set.
>>
>> For example, a token response can return:
>>
>> 401 Unauthorized
>> WWW-Authenticate: Basic realm="example"
>> WWW-Authenticate: Digest realm="example"
>>
>> There is no discovery for support for the client_id and client_secret
>> parameters. The client can simply try it or hardcode it based on
>> the server's
>> documentation.
>>
>> Does this help?
>>
>> EHL
>>
>> > -----Original Message-----
>> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> > Of Torsten Lodderstedt
>> > Sent: Monday, January 24, 2011 1:10 PM
>> > To: OAuth WG
>> > Subject: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokens
>> > endpoint?
>> >
>> > Hi all,
>> >
>> > I'm currently thinking about the integration of existing HTTP
>> > authentication schemes with OAuth 2.0 for the purpose of end-user
>> > authentication on the tokens endpoint. Possible candidates are "Digest"
>> > for challenge-response-based username/password authentication and
>> > "Spnego" for Kerberos-based authentication. Direct support for both
>> > could be beneficially in enterprise and other security sensitive
>> deployments.
>> >
>> > An direct integration with the tokens endpoint would allow to leverage
>> > existing implementations and infrastructure for OAuth/HTTP-based
>> > architectures. For example, HTTPClient has direct support for Spnego-
>> > Authentication.
>> >
>> > Both HTTP authentication schemes use dedicated WWW-Authenticate and
>> > Authorization headers for passing credential and other data between
>> > client and server. OAuth in contrast uses grant types to indicate the
>> > authentication method, credentials are passed as URI query parameters
>> > and it lacks any discovery of available authentication methods/
>> grant types.
>> >
>> > How could one integrate existing schemes into that design? What is our
>> > story? Do we need to define a special grant type "HTTP authorization"?
>> > Shall Authorization headers overrule URI parameters?
>> >
>> > Any ideas of the WG are higly appreciated.
>> >
>> > regards,
>> > Torsten.
>> >
>> >
>> >_______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>




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

--------------090201090406020207020406-- From tonynad@microsoft.com Wed Jan 26 13:49:17 2011 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 676133A69E2 for ; Wed, 26 Jan 2011 13:49:17 -0800 (PST) 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=[AWL=-0.000, 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 0E-jI7dbGu9O for ; Wed, 26 Jan 2011 13:49:15 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id ECBD33A6893 for ; Wed, 26 Jan 2011 13:49:14 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 26 Jan 2011 13:52:08 -0800 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.185]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0255.003; Wed, 26 Jan 2011 13:52:09 -0800 From: Anthony Nadalin To: Eran Hammer-Lahav Thread-Topic: Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQIaL9MwAAPpZeAAKfLFMA== Date: Wed, 26 Jan 2011 21:52:06 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F033B0798@TK5EX14MBXC111.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6250D@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6250D@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18F033B0798TK5EX14MBXC111r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 26 Jan 2011 21:49:17 -0000 --_000_180155C5EA10854997314CA5E063D18F033B0798TK5EX14MBXC111r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWF5YmUgdGhpcyB3YXMgdGhlIHBsYW4gYWxsIGFsb25nIGJ1dCBzcGVjaWZpY2F0aW9uIGlzIGJl Y29taW5nIHVzZWxlc3MgZm9yIG91ciBzY2VuYXJpb3MgYW5kIHdpbGwgcmVxdWlyZSB0aGF0IHdl IGhhdmUgdG8gZ28gd2VsbCBiZXlvbmQgdGhlIGNvcmUgc3BlY2lmaWNhdGlvbiB0byBtYWtlIHRo aW5ncyB3b3JrLCB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBiZWluZyBhIHByaW1l IGV4YW1wbGUuIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGhhcyBiZWVuIGFyb3Vu ZCBmb3IgYSB3aGlsZSBhcyBpdCB3YXMgYSByZXF1aXJlbWVudCBmb3IgV1JBUCwgdGhlbiBkcm9w cGVkIHdoZW4gdGhlIHZhcmlvdXMgc3BlY3MgZ290IG1lcmdlZCB0byBmb3JtIE9BVVRIIDIuMCBh bmQgdGhlbiBjYW1lIGJhY2sgaW50byB0aGUgT0FVVEggMi4wIGFuZCB0aGVuIGhhcyBnb25lIHRo cm91Z2ggdmFyaW91cyBjaGFuZ2VzIHNpbmNlIHZlcnNpb24gNiBmb3IgdGhlIHdvcnNlLiBUaGVy ZSBoYXMgYmVlbiBtdWNoIGRpc2N1c3Npb24gaW4gSnVseS9BdWd1c3Qgb3ZlciB0aGlzIGFuZCBu ZXcgdGV4dCB3YXMgcHJvcG9zZWQsIGJ1dCB0aGF0IHNlZW1zIHRvIG5vdCBiZSBmdWxseSBhY2Nl cHRlZCwgYnV0IEkgdGhpbmsgdGhhdCBmb2xsb3dzIHRoZSBwYXRoIHdoZW4geW91IHdhbnQgdG8g cmVtb3ZlIHNvbWV0aGluZy4NCg0KT3VyIHVzYWdlIHdpbGwgYmUgdmlhIGJlYXJlciB0b2tlbiBh c3NlcnRpb25zIG9ubHkgKGF0IHRoaXMgdGltZSkNClRoZSBncmFudF90eXBlIHdvdWxkIGJlIHRo ZSBVUkkgb2YgdGhlIGFzc2VydGlvbiB0eXBlIGJlaW5nIHVzZWQNClRoZSBhdXRob3JpemF0aW9u IGVuZHBvaW50IGNhbiB1c2Ugd2hhdCBpdCB3YW50cyB0byBiaW5kIHRoZSBhc3NlcnRpb24gdG8g dGhlIGNsaWVudF9pZCwgbXVjaCBsaWtlIGl0IGhhcyB0byB0b2RheSBmb3IgdGhlIHBhc3N3b3Jk IGF1dGhlbnRpY2F0aW9uLCBhcyB3ZSBoYXZlIHNjZW5hcmlvcyB3ZXJlIGNsaWVudF9pZCBoYXZl IG11bHRpcGxlIHBhc3N3b3Jkcw0KV2UgdXNlIGd1aWRhbmNlIGZyb20gc2VjdXJpdHkgY29uc2lk ZXJhdGlvbiBzZWN0aW9uIG9mIHRoZSBhc3NlcnRpb24gdHlwZSBiZWluZyB1c2VkIGFsb25nIHdp dGggdGhlIGd1aWRhbmNlIGZyb20gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uDQpJZiBu ZWVkZWQgSSBjYW4gY2FwdHVyZSB0aGUgYXNzZXJ0aW9ucyBhbmQgcmVxdWVzdHMsIGJ1dCBub3Qg c3VyZSB3aGF0IHRoZSBwb2ludCBvZiB0aGlzIGlzIGF0IHRoaXMgdGltZSBzaW5jZSB0aGlzIGlz IG5vdCByZXF1aXJlZCBmb3IgdGhlIHBhc3N3b3JkIGNyZWRlbnRpYWxzDQoNClN1cmUgd2UgY2Fu IGFkZCB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiB0byB0aGUgYmVhcmVyIHRv a2VuIHNwZWNpZmljYXRpb24gYnV0IEkgZG9u4oCZdCB0aGluayB0aGF0IGlzIHRoZSBwcm9wZXIg cGxhY2UgdG8gZG8gdGh1cyBidXQgc2luY2UgaXTigJlzIGdvbmUgZnJvbSB0aGUgY29yZSB3ZSB3 aWxsIGhhdmUgdG8gZG8ganVzdCB0aGF0LiBUaGUgc2FtZSBzZWVtcyB0byBoYXBwZW4gd2l0aCB0 aGUgSFRUUCBBdXRoZW50aWNhdGlvbiBTY2hlbWUgYXMgaXQgc2VlbXMgdG8gYmUgcmVwZWF0ZWQg aW4gZm9sbG93LW9uIGNvbXBhbmlvbiBzcGVjaWZpY2F0aW9ucy4gV2hpbGUgb2F1dGgtdjIgaXMg bm90IGFuIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgZm9y IGF1dGhlbnRpY2F0aW9uIHRvIGFkZHJlc3Mgc2VjdXJpdHkgY29uY2VybnMuIFRoZXJlIGlzIGNs ZWFyIHNlcGFyYXRpb24gYmV0d2VlbiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbjsg d2UgYXJlIG5vdCBzdWdnZXN0aW5nIHRoYXQgYXV0aGVudGljYXRpb24gaXMgYXBwcm9wcmlhdGUg ZmFjaWxpdHkgdG8gbmVnb3RpYXRlIGF1dGhvcml6YXRpb24uIEkgdGhpbmsgdGhhdCBpdCBtYWtl cyBzZW5zZSB0byBpbmNsdWRlIGEgc2NoZW1lIGluIHRoZSBjb3JlIGFuZCBoYXZlIHRoZSBwYXJ0 aWN1bGFyIGZvbGxvdy1vbiBjb21wYW5pb24gc3BlY2lmaWNhdGlvbnMgKHRoZSB2YXJpb3VzIHRv a2VuIHNwZWNpZmljYXRpb25zKSBzdGF0ZS9kZWZpbmUgdGhlIHBhcmFtZXRlcnMgYW5kIGlmIHRo ZXkgZG9u4oCZdCBsaWtlIHRoZSBkZWZhdWx0IHNjaGVtZSBsZXQgdGhlbSBkZWZpbmUgYSBuZXcg c2NoZW1lIGJ1dCB0aGlzIHB1dHMgYSBzdGFrZSBpbiB0aGUgZ3JvdW5kIGZvciBhbiBIVFRQIEF1 dGhlbnRpY2F0aW9uIFNjaGVtZS4NCg0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRv OmVyYW5AaHVlbml2ZXJzZS5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI1LCAyMDExIDU6 MzggUE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogUkU6IFJl bW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMNCg0KQ2FuIHlvdSBzaGFyZSB3aXRo IHRoZSBsaXN0IGhvdyB5b3UgcGxhbiB0byB1c2UgdGhpcyBjbGllbnQgYXNzZXJ0aW9uIGF1dGhl bnRpY2F0aW9uIHNjaGVtZT8NCldoaWNoIG9mIHRoZSBhdXRob3JpemF0aW9uIGdyYW50IHR5cGVz IHlvdSB3aWxsIHVzZSBpdCB3aXRoPw0KV2lsbCB5b3UgdXNlIGl0IHdpdGggdGhlIGF1dGhvcml6 YXRpb24gZW5kcG9pbnQsIGFuZCBpZiBzbywgaG93IHdpbGwgeW91IGJpbmQgdGhlIGFzc2VydGlv biB0byB0aGUgY2xpZW50X2lkPw0KQ2FuIHlvdSBwcm92aWRlIGZ1bGwgZXhhbXBsZXMgb2YgYXNz ZXJ0aW9ucyBhbmQgSFRUUCByZXF1ZXN0cz8NCg0KSXQgd291bGQgYmUgaGVscGZ1bCB0byBzZWUg aG93IGZhciBhcGFydCB0aGUgcHJvcG9zZWQgdGV4dCBiZWxvdyBpcyBmcm9tIGFuIGFjdHVhbCBp bXBsZW1lbnRhdGlvbiBtYWtpbmcgdXNlIG9mIGl0LiBJIGV4Y2VwdCB0byBzZWUgdGhlc2UgYW5z d2VycyBpbiBhbnkgcXVhbGl0eSBkb2N1bWVudCBkZWZpbmluZyBhIG5ldyBjbGllbnQgYXV0aGVu dGljYXRpb24gc2NoZW1lICh3aGljaCBpcyB0cnVlIGZvciB0aGUgY2xpZW50IHBhc3N3b3JkIGF1 dGhlbnRpY2F0aW9uIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50KS4NCg0KRUhMDQoNCg0KRnJvbTog QW50aG9ueSBOYWRhbGluIFttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXTxtYWlsdG86W21h aWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dPg0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNSwg MjAxMSAzOjU4IFBNDQpUbzogRXJhbiBIYW1tZXItTGFoYXY7IE9BdXRoIFdHOyBIYW5uZXMuVHNj aG9mZW5pZ0BnbXgubmV0PG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0PjsgQmxhaW5l IENvb2sNClN1YmplY3Q6IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxz DQoNCg0KSSBkb24ndCB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9yIHJlbW92aW5nIHRoZSBj bGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzLCBhcyBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGlj YXRpb24gaXMgbGVmdCBpbi4gQ2xpZW50IFBhc3N3b3JkIEF1dGhlbnRpY2F0aW9uIGlzIGFsc28g dW5kZXJzcGVjaWZpZWQgYXMgY2xpZW50X3NlY3JldCBjb3VsZCBiZSBhbnl0aGluZyB0aGF0IHRo ZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgc2VlbXMgZml0IChyYXcgY2xlYXIgdGV4dCBwYXNzd29y ZCwgIGhhc2gsIGRpZ2VzdCwgZXRjLikgYW5kIG5vIHdheSB0byBkZXRlcm1pbmUgdGhlIGNvbnRl bnQuIGNsaWVudF9zZWNyZXQgaXMgYWxzbyBhIHZlcnkgd2VhayBtZWNoYW5pc20sIHNpbmNlIHRo aXMgaXMgbGVmdCBpbiB0aGUgY29yZSB0aGlzIGxlYWRzIG1lIHRvIGJlbGlldmUgdGhhdCB0aGVy ZSBpcyBzdXBwb3J0IGZvciBoYXZpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIE9hdXRoLiBJ IGRvbid0IHNlZSBob3cgaGF2aW5nIGNsaWVudF9hc3NlcnRpb24gYW5kIGNsaWVudF9hc3NlcnRp b25fdHlwZSB3b3VsZCBiZSBzb21ldGhpbmcgdGhhdCBpcyB1bmRlcnNwZWNpZmllZCBhcyBiZWlu ZyBhIG1lY2hhbmlzbSBpbiB3aGljaCBhc3NlcnRpb25zIGNhbiBiZSB1c2VkIGZvciBhdXRoZW50 aWNhdGlvbi4gQWdyZWUgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyIGhhcyB0byBtYWtl IHJpZ2h0IGFuZCBkZWNsYXJlIHdoYXQgaXMgYmVpbmcgdXNlZCBidXQgdGhhdCBpcyB0aGUgc2Ft ZSBmb3IgY2xpZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGF1dGhlbnRp Y2F0aW9uIGFzc2VydGlvbnMgYXJlIHNvbWV0aGluZyB0aGF0IE1pY3Jvc29mdCBhbmQgR29vZ2xl IGZpbmQgdXNlZnVsIGFuZCBwbGFuIG9uIGltcGxlbWVudGluZyBhbmQgdXNpbmcgYXMgYSBtZWFu cyBmb3Igc3Ryb25nZXIgYXV0aGVudGljYXRpb24gdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVy LiBUaGlzIGV4dGVuc2liaWxpdHkgYmVsb25ncyBpbiB0aGUgY29yZSwgdGhlcmUgaXMgbm8gb3Ro ZXIgcGxhY2UgdG8gcHV0IHRoaXMgZnVuY3Rpb25hbGl0eS4gSSBkb24ndCBiZWxpZXZlIHRoYXQg dGhlIHJlbW92YWwgKGVpdGhlciBieSBlZGl0b3Igb3IgZGlyZWN0aW9uIGJ5IGNvLWNoYWlyKSBp cyBzb21ldGhpbmcgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIGRvbmUgdy9vIGEgY29uc2Vuc3VzIHZv dGUgc2luY2UgdGhpcyBoYXMgYmVlbiBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3Igc29tZSB0aW1l IHdpdGhvdXQgaXNzdWUgYW5kIHRoZSByZW1vdmFsIGNvbWVzIGFzIGNvbXBsZXRlIHVud2VsY29t ZSBzdXJwcmlzZS4gR2V0dGluZyBhbG1vc3QgdG90YWwgcmV3cml0ZXMgb2YgdGhlIHNwZWNpZmlj YXRpb24gdGhpcyBsYXRlIGluIHRoZSByZXZpZXcgY3ljbGUgaXMgYWxzbyB2ZXJ5IGRpc3R1cmJp bmcuDQoNCg0KDQpBIHByb3Bvc2FsIGZvciBrZWVwaW5nIHRoZSBjbGllbnQgYXV0aGVudGljYXRp b24gYXNzZXJ0aW9uIHdvdWxkIGJlIHRvIHNpbXBsaWZ5IHRvIHRoZSBmb2xsb3dpbmc7DQoNClRo ZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGFyZSB1c2VkIGluIGNhc2VzIHdoZXJlIGEg cGFzc3dvcmQgKGNsZWFyLXRleHQgc2hhcmVkIHN5bW1ldHJpYyBzZWNyZXQpIGlzIHVuc3VpdGFi bGUgb3IgZG9lcyBub3QgcHJvdmlkZSBzdWZmaWNpZW50IHNlY3VyaXR5IGZvciBjbGllbnQgYXV0 aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIHByb3ZpZGUgYW4g ZXh0ZW5zaWJsZSBtZWNoYW5pc20gdG8gdXNlIGFuIGFzc2VydGlvbiBmb3JtYXQgc3VwcG9ydGVk IGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBmb3IgYXV0aGVudGljYXRpb24gb2YgdGhlIGNs aWVudC4NCg0KVXNpbmcgYXNzZXJ0aW9ucyByZXF1aXJlcyB0aGUgY2xpZW50IHRvIG9idGFpbiBh biBhc3NlcnRpb24gKHN1Y2ggYXMgYSBTQU1MIChDYW50b3IsIFMuLCBLZW1wLCBKLiwgUGhpbHBv dHQsIFIuLCBhbmQgRS4gTWFsZXIsIOKAnEFzc2VydGlvbnMgYW5kIFByb3RvY29sIGZvciB0aGUg T0FTSVMgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAoU0FNTCkgVjIuMCzigJ0g TWFyY2ggMjAwNS4pIFtPQVNJUy5zYW1s4oCRY29yZeKAkTIuMOKAkW9zXSBhc3NlcnRpb24pIGZy b20gYW4gYXNzZXJ0aW9uIGlzc3VlciBvciB0byBzZWxmLWlzc3VlIGFuIGFzc2VydGlvbi4gVGhl IGFzc2VydGlvbiBmb3JtYXQsIHRoZSBwcm9jZXNzIGJ5IHdoaWNoIHRoZSBhc3NlcnRpb24gaXMg b2J0YWluZWQsIGFuZCB0aGUgbWV0aG9kIG9mIHZhbGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmUg ZGVmaW5lZCBieSB0aGUgYXNzZXJ0aW9uIGlzc3VlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2Vy dmVyLCBhbmQgYXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpX aGVuIHVzaW5nIGEgY2xpZW50IGFzc2VydGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgZm9s bG93aW5nIHBhcmFtZXRlcnM6DQpjbGllbnRfYXNzZXJ0aW9uX3R5cGUgLSBSRVFVSVJFRC4gVGhl IGZvcm1hdCBvZiB0aGUgYXNzZXJ0aW9uIGFzIGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24g c2VydmVyLiBUaGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0ZSBVUkkuDQpjbGllbnRfYXNzZXJ0 aW9uIC0gUkVRVUlSRUQuIFRoZSBjbGllbnQgYXNzZXJ0aW9uLg0KDQpGb3IgZXhhbXBsZSwgdGhl IGNsaWVudCBzZW5kcyB0aGUgZm9sbG93aW5nIGFjY2VzcyB0b2tlbiByZXF1ZXN0IHVzaW5nIGEg U0FNTCAyLjAgYXNzZXJ0aW9uIHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYgKGxpbmUgYnJlYWtzIGFy ZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KToNCg0KDQoNCg0KDQogIFBPU1QgL3Rva2VuIEhU VFAvMS4xDQoNCiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tDQoNCiAgQ29udGVudC1UeXBlOiBh cHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQNCg0KDQoNCiAgZ3JhbnRfdHlwZT1hdXRo b3JpemF0aW9uX2NvZGUmY29kZT1pMVdzUm4xdUIxJg0KDQogIGNsaWVudF9hc3NlcnRpb249UEhO aGJXeHdPbFsuLi5vbWl0dGVkIGZvciBicmV2aXR5Li4uXVpUNCUzRCYNCg0KICBjbGllbnRfYXNz ZXJ0aW9uX3R5cGU9ICB1cm4lM0FvYXNpcyUzQW5hbWVzJXNBdGMlM0FTQU1MJTNBMi4wJTNBYXNz ZXJ0aW9uJnJlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20l MkZjYg0KDQoNCg0KDQoNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXTxtYWls dG86W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXT4gT24gQmVoYWxmIE9mIEVyYW4gSGFt bWVyLUxhaGF2DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTQsIDIwMTEgMTA6NDUgUE0NClRvOiBP QXV0aCBXRw0KU3ViamVjdDogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENy ZWRlbnRpYWxzDQoNCkkgd291bGQgbGlrZSB0byBzdWdnZXN0IHdlIGRyb3AgdGhlIGNsaWVudCBh c3NlcnRpb24gY3JlZGVudGlhbHMgKC0xMSBzZWN0aW9uIDMuMikgZnJvbSB0aGUgc3BlY2lmaWNh dGlvbiwgYW5kIGlmIG5lZWRlZCwgcHVibGlzaCBpdCBhcyBhIHNlcGFyYXRlIHNwZWNpZmljYXRp b24gZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCg0KDQoxLiAgICAgICBUaGUgbWVjaGFuaXNt IGlzIHVuZGVyIHNwZWNpZmllZCwgZXNwZWNpYWxseSBpbiBpdHMgaGFuZGxpbmcgb2YgdGhlIGNs aWVudF9pZCBpZGVudGlmaWVyICh3aGVuIHVzZWQgdG8gb2J0YWluIGVuZC11c2VyIGF1dGhvcml6 YXRpb24pLiBJdCBkb2VzIG5vdCBjb250YWluIGFueSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRv IGFjY29tcGxpc2ggYW55IGxldmVsIG9mIGludGVyb3BlcmFiaWxpdHkgb3IgZnVuY3Rpb25hbGl0 eS4gVGhpcyBpcyBpbiBjb250cmFzdCB0byB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUgd2hpY2gg aGFzIG1hdHVyZWQgb3ZlciBhIHllYXIgaW50byBhIGZ1bGx5IHRob3VnaHQtb3V0IGV4dGVuc2lv biBtZWNoYW5pc20sIGFzIHdlbGwgYXMgYSBzZXBhcmF0ZSBTQU1MIGFzc2VydGlvbiBzcGVjaWZp Y2F0aW9uIHdpdGggYWN0aXZlIGRlcGxveW1lbnQgKHRoZSB0d28sIHRvZ2V0aGVyIHdpdGggcnVu bmluZyBjb2RlLCBzaG93IGNsZWFyIGNvbnNlbnN1cykuDQoNCjIuICAgICAgIFRoZSBzZWN0aW9u IGlzIGEgY29uZnVzZWQgbWl4IG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNwcmlua2xlZCB3 aXRoIG5vcm1hdGl2ZSBsYW5ndWFnZS4gSW5zdGVhZCwgaXQgc2hvdWxkIGJlIHJlcGxhY2VkIHdp dGggZ3VpZGVsaW5lcyBmb3IgZXh0ZW5kaW5nIHRoZSBzZXQgb2Ygc3VwcG9ydGVkIGNsaWVudCBj cmVkZW50aWFscywgYnV0IHdpdGhvdXQgZGVmaW5pbmcgYSBuZXcgcmVnaXN0cnkuIEl0IGlzIGNs ZWFybHkgYW4gYXJlYSBvZiBsaXR0bGUgZGVwbG95bWVudCBleHBlcmllbmNlIGZvciBPQXV0aCwg YW5kIHRoYXQgaW5jbHVkZXMgdXNpbmcgSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiBmb3IgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIChtb3JlIG9uIHRoYXQgdG8gY29tZSkuDQoNCjMuICAgICAgIFRo ZSBzZWN0aW9uIGhhcyByZWNlaXZlZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmpl Y3Rpb24uIFRob3NlIHdobyBzdGlsbCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNo b3cgbm90IG9ubHkgY29uc2Vuc3VzIGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29t bXVuaXR5IHN1cHBvcnQgZm9yIGRlcGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3 aWxsIGFsc28gcmVxdWlyZSBzaG93aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9u cyBwcm9maWxpbmcgdGhlIG1lY2hhbmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVh dHVyZS4NCg0KQ29tbWVudHM/IENvdW50ZXItYXJndW1lbnRzPw0KDQpFSEwNCg0KDQo= --_000_180155C5EA10854997314CA5E063D18F033B0798TK5EX14MBXC111r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0 LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MjQuMHB0Ow0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjI0LjBwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJYmFja2dyb3Vu ZDojQ0NDQ0NDOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCgliYWNrZ3JvdW5kOiNDQ0NDQ0M7fQ0Kc3Bhbi5Q bGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExMTM3ODY1MDA7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMjE4Njk4 ODggNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5NYXliZSB0aGlzIHdhcyB0aGUgcGxhbiBhbGwgYWxvbmcgYnV0IHNwZWNpZmljYXRp b24gaXMgYmVjb21pbmcgdXNlbGVzcyBmb3Igb3VyIHNjZW5hcmlvcyBhbmQgd2lsbCByZXF1aXJl IHRoYXQgd2UgaGF2ZSB0byBnbyB3ZWxsIGJleW9uZCB0aGUgY29yZSBzcGVjaWZpY2F0aW9uIHRv IG1ha2UgdGhpbmdzIHdvcmssIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzDQogYmVp bmcgYSBwcmltZSBleGFtcGxlLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBoYXMg YmVlbiBhcm91bmQgZm9yIGEgd2hpbGUgYXMgaXQgd2FzIGEgcmVxdWlyZW1lbnQgZm9yIFdSQVAs IHRoZW4gZHJvcHBlZCB3aGVuIHRoZSB2YXJpb3VzIHNwZWNzIGdvdCBtZXJnZWQgdG8gZm9ybSBP QVVUSCAyLjAgYW5kIHRoZW4gY2FtZSBiYWNrIGludG8gdGhlIE9BVVRIIDIuMCBhbmQgdGhlbiBo YXMgZ29uZSB0aHJvdWdoIHZhcmlvdXMgY2hhbmdlcw0KIHNpbmNlIHZlcnNpb24gNiBmb3IgdGhl IHdvcnNlLiBUaGVyZSBoYXMgYmVlbiBtdWNoIGRpc2N1c3Npb24gaW4gSnVseS9BdWd1c3Qgb3Zl ciB0aGlzIGFuZCBuZXcgdGV4dCB3YXMgcHJvcG9zZWQsIGJ1dCB0aGF0IHNlZW1zIHRvIG5vdCBi ZSBmdWxseSBhY2NlcHRlZCwgYnV0IEkgdGhpbmsgdGhhdCBmb2xsb3dzIHRoZSBwYXRoIHdoZW4g eW91IHdhbnQgdG8gcmVtb3ZlIHNvbWV0aGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPk91ciB1c2FnZSB3aWxsIGJlIHZpYSBiZWFyZXIgdG9rZW4gYXNzZXJ0aW9ucyBv bmx5IChhdCB0aGlzIHRpbWUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBncmFudF90eXBlIHdvdWxkIGJl IHRoZSBVUkkgb2YgdGhlIGFzc2VydGlvbiB0eXBlIGJlaW5nIHVzZWQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ VGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgY2FuIHVzZSB3aGF0IGl0IHdhbnRzIHRvIGJpbmQg dGhlIGFzc2VydGlvbiB0byB0aGUgY2xpZW50X2lkLCBtdWNoIGxpa2UgaXQgaGFzIHRvIHRvZGF5 IGZvciB0aGUgcGFzc3dvcmQgYXV0aGVudGljYXRpb24sIGFzIHdlIGhhdmUgc2NlbmFyaW9zIHdl cmUgY2xpZW50X2lkIGhhdmUgbXVsdGlwbGUgcGFzc3dvcmRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldlIHVz ZSBndWlkYW5jZSBmcm9tIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBvZiB0aGUgYXNz ZXJ0aW9uIHR5cGUgYmVpbmcgdXNlZCBhbG9uZyB3aXRoIHRoZSBndWlkYW5jZSBmcm9tIHRoZSBi ZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JZiBuZWVkZWQgSSBjYW4g Y2FwdHVyZSB0aGUgYXNzZXJ0aW9ucyBhbmQgcmVxdWVzdHMsIGJ1dCBub3Qgc3VyZSB3aGF0IHRo ZSBwb2ludCBvZiB0aGlzIGlzIGF0IHRoaXMgdGltZSBzaW5jZSB0aGlzIGlzIG5vdCByZXF1aXJl ZCBmb3IgdGhlIHBhc3N3b3JkIGNyZWRlbnRpYWxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5TdXJlIHdlIGNhbiBhZGQgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3Nl cnRpb24gdG8gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uIGJ1dCBJIGRvbuKAmXQgdGhp bmsgdGhhdCBpcyB0aGUgcHJvcGVyIHBsYWNlIHRvIGRvIHRodXMgYnV0IHNpbmNlIGl04oCZcyBn b25lIGZyb20gdGhlIGNvcmUgd2Ugd2lsbCBoYXZlIHRvIGRvIGp1c3QgdGhhdC4gVGhlDQogc2Ft ZSBzZWVtcyB0byBoYXBwZW4gd2l0aCB0aGUgSFRUUCBBdXRoZW50aWNhdGlvbiBTY2hlbWUgYXMg aXQgc2VlbXMgdG8gYmUgcmVwZWF0ZWQgaW4gZm9sbG93LW9uIGNvbXBhbmlvbiBzcGVjaWZpY2F0 aW9ucy4gV2hpbGUgb2F1dGgtdjIgaXMgbm90IGFuIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIHRo ZXJlIGlzIGEgcmVxdWlyZW1lbnQgZm9yIGF1dGhlbnRpY2F0aW9uIHRvIGFkZHJlc3Mgc2VjdXJp dHkgY29uY2VybnMuIFRoZXJlIGlzIGNsZWFyDQogc2VwYXJhdGlvbiBiZXR3ZWVuIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uOyB3ZSBhcmUgbm90IHN1Z2dlc3RpbmcgdGhhdCBhdXRo ZW50aWNhdGlvbiBpcyBhcHByb3ByaWF0ZSBmYWNpbGl0eSB0byBuZWdvdGlhdGUgYXV0aG9yaXph dGlvbi4gSSB0aGluayB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIGluY2x1ZGUgYSBzY2hlbWUgaW4g dGhlIGNvcmUgYW5kIGhhdmUgdGhlIHBhcnRpY3VsYXIgZm9sbG93LW9uIGNvbXBhbmlvbiBzcGVj aWZpY2F0aW9ucw0KICh0aGUgdmFyaW91cyB0b2tlbiBzcGVjaWZpY2F0aW9ucykgc3RhdGUvZGVm aW5lIHRoZSBwYXJhbWV0ZXJzIGFuZCBpZiB0aGV5IGRvbuKAmXQgbGlrZSB0aGUgZGVmYXVsdCBz Y2hlbWUgbGV0IHRoZW0gZGVmaW5lIGEgbmV3IHNjaGVtZSBidXQgdGhpcyBwdXRzIGEgc3Rha2Ug aW4gdGhlIGdyb3VuZCBmb3IgYW4gSFRUUCBBdXRoZW50aWNhdGlvbiBTY2hlbWUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZl cnNlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDI1LCAyMDExIDU6 MzggUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbjxicj4NCjxiPkNjOjwvYj4gT0F1 dGggV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24g Q3JlZGVudGlhbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2FuIHlvdSBzaGFyZSB3aXRoIHRoZSBsaXN0 IGhvdyB5b3UgcGxhbiB0byB1c2UgdGhpcyBjbGllbnQgYXNzZXJ0aW9uIGF1dGhlbnRpY2F0aW9u IHNjaGVtZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hpY2ggb2YgdGhlIGF1dGhvcml6YXRpb24gZ3JhbnQg dHlwZXMgeW91IHdpbGwgdXNlIGl0IHdpdGg/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldpbGwgeW91IHVzZSBp dCB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBhbmQgaWYgc28sIGhvdyB3aWxsIHlv dSBiaW5kIHRoZSBhc3NlcnRpb24gdG8gdGhlIGNsaWVudF9pZD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2Fu IHlvdSBwcm92aWRlIGZ1bGwgZXhhbXBsZXMgb2YgYXNzZXJ0aW9ucyBhbmQgSFRUUCByZXF1ZXN0 cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IHdvdWxkIGJlIGhlbHBm dWwgdG8gc2VlIGhvdyBmYXIgYXBhcnQgdGhlIHByb3Bvc2VkIHRleHQgYmVsb3cgaXMgZnJvbSBh biBhY3R1YWwgaW1wbGVtZW50YXRpb24gbWFraW5nIHVzZSBvZiBpdC4gSSBleGNlcHQgdG8gc2Vl IHRoZXNlIGFuc3dlcnMgaW4gYW55IHF1YWxpdHkgZG9jdW1lbnQgZGVmaW5pbmcgYSBuZXcgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIHNjaGVtZQ0KICh3aGljaCBpcyB0cnVlIGZvciB0aGUgY2xpZW50 IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50KS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW50aG9ueSBOYWRhbGluDQo8YSBocmVmPSJt YWlsdG86W21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dIj5bbWFpbHRvOnRvbnluYWRAbWlj cm9zb2Z0LmNvbV08L2E+DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAyNSwg MjAxMSAzOjU4IFBNPGJyPg0KPGI+VG86PC9iPiBFcmFuIEhhbW1lci1MYWhhdjsgT0F1dGggV0c7 IDxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0Ij4NCkhhbm5lcy5Uc2No b2ZlbmlnQGdteC5uZXQ8L2E+OyBCbGFpbmUgQ29vazxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog UmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFsczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcmF0 aW9uYWxlIGZvciByZW1vdmluZyB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscywgYXMg Y2xpZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIGlzIGxlZnQgaW4uIENsaWVudCBQYXNzd29y ZCBBdXRoZW50aWNhdGlvbiBpcyBhbHNvIHVuZGVyc3BlY2lmaWVkIGFzIGNsaWVudF9zZWNyZXQg Y291bGQgYmUgYW55dGhpbmcgdGhhdCB0aGUgYXV0aGVudGljYXRpb24NCiBzZXJ2ZXIgc2VlbXMg Zml0IChyYXcgY2xlYXIgdGV4dCBwYXNzd29yZCwmbmJzcDsgaGFzaCwgZGlnZXN0LCBldGMuKSBh bmQgbm8gd2F5IHRvIGRldGVybWluZSB0aGUgY29udGVudC4gY2xpZW50X3NlY3JldCBpcyBhbHNv IGEgdmVyeSB3ZWFrIG1lY2hhbmlzbSwgc2luY2UgdGhpcyBpcyBsZWZ0IGluIHRoZSBjb3JlIHRo aXMgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIHN1cHBvcnQgZm9yIGhhdmluZyBj bGllbnQgYXV0aGVudGljYXRpb24NCiBpbiBPYXV0aC4gSSBkb24ndCBzZWUgaG93IGhhdmluZyBj bGllbnRfYXNzZXJ0aW9uIGFuZCBjbGllbnRfYXNzZXJ0aW9uX3R5cGUgd291bGQgYmUgc29tZXRo aW5nIHRoYXQgaXMgdW5kZXJzcGVjaWZpZWQgYXMgYmVpbmcgYSBtZWNoYW5pc20gaW4gd2hpY2gg YXNzZXJ0aW9ucyBjYW4gYmUgdXNlZCBmb3IgYXV0aGVudGljYXRpb24uIEFncmVlIHRoYXQgdGhl IGF1dGhlbnRpY2F0aW9uIHNlcnZlciBoYXMgdG8gbWFrZSByaWdodCBhbmQgZGVjbGFyZQ0KIHdo YXQgaXMgYmVpbmcgdXNlZCBidXQgdGhhdCBpcyB0aGUgc2FtZSBmb3IgY2xpZW50IHBhc3N3b3Jk IGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbnMgYXJl IHNvbWV0aGluZyB0aGF0IE1pY3Jvc29mdCBhbmQgR29vZ2xlIGZpbmQgdXNlZnVsIGFuZCBwbGFu IG9uIGltcGxlbWVudGluZyBhbmQgdXNpbmcgYXMgYSBtZWFucyBmb3Igc3Ryb25nZXIgYXV0aGVu dGljYXRpb24gdG8gdGhlIGF1dGhvcml6YXRpb24NCiBzZXJ2ZXIuIFRoaXMgZXh0ZW5zaWJpbGl0 eSBiZWxvbmdzIGluIHRoZSBjb3JlLCB0aGVyZSBpcyBubyBvdGhlciBwbGFjZSB0byBwdXQgdGhp cyBmdW5jdGlvbmFsaXR5LiBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGUgcmVtb3ZhbCAoZWl0aGVy IGJ5IGVkaXRvciBvciBkaXJlY3Rpb24gYnkgY28tY2hhaXIpIGlzIHNvbWV0aGluZyB0aGF0IHNo b3VsZCBoYXZlIGJlZW4gZG9uZSB3L28gYSBjb25zZW5zdXMgdm90ZSBzaW5jZSB0aGlzIGhhcyBi ZWVuDQogaW4gdGhlIHNwZWNpZmljYXRpb24gZm9yIHNvbWUgdGltZSB3aXRob3V0IGlzc3VlIGFu ZCB0aGUgcmVtb3ZhbCBjb21lcyBhcyBjb21wbGV0ZSB1bndlbGNvbWUgc3VycHJpc2UuIEdldHRp bmcgYWxtb3N0IHRvdGFsIHJld3JpdGVzIG9mIHRoZSBzcGVjaWZpY2F0aW9uIHRoaXMgbGF0ZSBp biB0aGUgcmV2aWV3IGN5Y2xlIGlzIGFsc28gdmVyeSBkaXN0dXJiaW5nLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij5BIHByb3Bvc2FsIGZvciBrZWVwaW5nIHRoZSBjbGllbnQgYXV0aGVu dGljYXRpb24gYXNzZXJ0aW9uIHdvdWxkIGJlIHRvIHNpbXBsaWZ5IHRvIHRoZSBmb2xsb3dpbmc7 PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhl IGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYXJlIHVzZWQgaW4gY2FzZXMgd2hlcmUgYSBw YXNzd29yZCAoY2xlYXItdGV4dCBzaGFyZWQgc3ltbWV0cmljIHNlY3JldCkgaXMgdW5zdWl0YWJs ZSBvciBkb2VzIG5vdCBwcm92aWRlIHN1ZmZpY2llbnQgc2VjdXJpdHkgZm9yIGNsaWVudCBhdXRo ZW50aWNhdGlvbi4NCiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBwcm92aWRlIGFu IGV4dGVuc2libGUgbWVjaGFuaXNtIHRvIHVzZSBhbiBhc3NlcnRpb24gZm9ybWF0IHN1cHBvcnRl ZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBj bGllbnQuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+VXNpbmcgYXNzZXJ0aW9ucyByZXF1aXJlcyB0aGUgY2xpZW50IHRvIG9idGFp biBhbiBhc3NlcnRpb24gKHN1Y2ggYXMgYQ0KPC9zcGFuPjxhIGhyZWY9IiNPQVNJUy5zYW1sLWNv cmUtMi4wLW9zIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozt0ZXh0LWRlY29yYXRpb246bm9uZSI+U0FN TCAoQ2FudG9yLCBTLiwgS2VtcCwgSi4sIFBoaWxwb3R0LCBSLiwgYW5kIEUuIE1hbGVyLCDigJxB c3NlcnRpb25zIGFuZCBQcm90b2NvbCBmb3IgdGhlIE9BU0lTIFNlY3VyaXR5IEFzc2VydGlvbiBN YXJrdXAgTGFuZ3VhZ2UgKFNBTUwpDQogVjIuMCzigJ0gTWFyY2gmbmJzcDsyMDA1Lik8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPg0KPHNwYW4gbGFuZz0iRU4iPltPQVNJUy5zYW1s 4oCRY29yZeKAkTIuMOKAkW9zXSBhc3NlcnRpb24pIGZyb20gYW4gYXNzZXJ0aW9uIGlzc3VlciBv ciB0byBzZWxmLWlzc3VlIGFuIGFzc2VydGlvbi4gVGhlIGFzc2VydGlvbiBmb3JtYXQsIHRoZSBw cm9jZXNzIGJ5IHdoaWNoIHRoZSBhc3NlcnRpb24gaXMgb2J0YWluZWQsIGFuZCB0aGUgbWV0aG9k IG9mIHZhbGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmUgZGVmaW5lZCBieSB0aGUgYXNzZXJ0aW9u IGlzc3Vlcg0KIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGFuZCBhcmUgYmV5b25kIHRo ZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uIDxvOnA+DQo8L286cD48L3NwYW4+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5XaGVuIHVzaW5nIGEg Y2xpZW50IGFzc2VydGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFt ZXRlcnM6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6NjAuMHB0O21hcmdpbi1ib3R0 b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmNsaWVudF9hc3NlcnRpb25fdHlwZSAtIFJFUVVJ UkVELiBUaGUgZm9ybWF0IG9mIHRoZSBhc3NlcnRpb24gYXMgZGVmaW5lZCBieSB0aGUgYXV0aG9y aXphdGlvbiBzZXJ2ZXIuIFRoZSB2YWx1ZSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSS4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoyNC4wcHQ7dGV4dC1pbmRlbnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPmNsaWVudF9hc3NlcnRpb24gLSBSRVFVSVJFRC4gVGhlIGNsaWVudCBhc3NlcnRpb24uDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+Rm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgc2VuZHMgdGhlIGZvbGxvd2luZyBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCB1c2luZyBhIFNBTUwgMi4wIGFzc2VydGlvbiB0byBhdXRoZW50aWNhdGUgaXRz ZWxmIChsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdp bi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6NjAuMHB0O21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6 MjQuMHB0O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyBQT1NUIC90b2tlbiBIVFRQLzEuMTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJn aW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJn aW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsgSG9zdDogc2VydmVyLmV4 YW1wbGUuY29tPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIj4m bmJzcDsgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7IGdyYW50X3R5cGU9 YXV0aG9yaXphdGlvbl9jb2RlJmFtcDtjb2RlPWkxV3NSbjF1QjEmYW1wOzxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7IGNsaWVudF9hc3NlcnRpb249 UEhOaGJXeHdPbFsuLi5vbWl0dGVkIGZvciBicmV2aXR5Li4uXVpUNCUzRCZhbXA7PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsgY2xpZW50X2Fzc2Vy dGlvbl90eXBlPSAmbmJzcDt1cm4lM0FvYXNpcyUzQW5hbWVzJXNBdGMlM0FTQU1MJTNBMi4wJTNB YXNzZXJ0aW9uJmFtcDtyZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZjbGllbnQlMkVleGFtcGxl JTJFY29tJTJGY2I8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjI0LjBwdDttYXJnaW4tYm90dG9tOjBpbjttYXJn aW4tbGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0 Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IDxhIGhyZWY9Im1haWx0bzpbbWFpbHRv Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIj4NClttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+RXJhbiBIYW1tZXItTGFoYXY8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDE0LCAyMDExIDEwOjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBP QXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIFJlbW92YWw6IENsaWVudCBB c3NlcnRpb24gQ3JlZGVudGlhbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB3ZSBkcm9wIHRoZSBjbGllbnQgYXNz ZXJ0aW9uIGNyZWRlbnRpYWxzICgtMTEgc2VjdGlvbiAzLjIpIGZyb20gdGhlIHNwZWNpZmljYXRp b24sIGFuZCBpZiBuZWVkZWQsIHB1Ymxpc2ggaXQgYXMgYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9u IGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgbWVj aGFuaXNtIGlzIHVuZGVyIHNwZWNpZmllZCwgZXNwZWNpYWxseSBpbiBpdHMgaGFuZGxpbmcgb2Yg dGhlIGNsaWVudF9pZCBpZGVudGlmaWVyICh3aGVuIHVzZWQgdG8gb2J0YWluIGVuZC11c2VyIGF1 dGhvcml6YXRpb24pLiBJdCBkb2VzIG5vdCBjb250YWluIGFueSBpbXBsZW1lbnRhdGlvbiBkZXRh aWxzIHRvIGFjY29tcGxpc2ggYW55IGxldmVsIG9mIGludGVyb3BlcmFiaWxpdHkgb3IgZnVuY3Rp b25hbGl0eS4NCiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvIHRoZSBhc3NlcnRpb24gZ3JhbnQgdHlw ZSB3aGljaCBoYXMgbWF0dXJlZCBvdmVyIGEgeWVhciBpbnRvIGEgZnVsbHkgdGhvdWdodC1vdXQg ZXh0ZW5zaW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBhIHNlcGFyYXRlIFNBTUwgYXNzZXJ0aW9u IHNwZWNpZmljYXRpb24gd2l0aCBhY3RpdmUgZGVwbG95bWVudCAodGhlIHR3bywgdG9nZXRoZXIg d2l0aCBydW5uaW5nIGNvZGUsIHNob3cgY2xlYXIgY29uc2Vuc3VzKS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgc2VjdGlvbiBpcyBhIGNvbmZ1c2VkIG1peCBvZiBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzcHJpbmtsZWQgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UuIElu c3RlYWQsIGl0IHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIGd1aWRlbGluZXMgZm9yIGV4dGVuZGlu ZyB0aGUgc2V0IG9mIHN1cHBvcnRlZCBjbGllbnQgY3JlZGVudGlhbHMsIGJ1dCB3aXRob3V0IGRl ZmluaW5nIGEgbmV3IHJlZ2lzdHJ5LiBJdA0KIGlzIGNsZWFybHkgYW4gYXJlYSBvZiBsaXR0bGUg ZGVwbG95bWVudCBleHBlcmllbmNlIGZvciBPQXV0aCwgYW5kIHRoYXQgaW5jbHVkZXMgdXNpbmcg SFRUUCBCYXNpYyBhdXRoZW50aWNhdGlvbiBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIChtb3Jl IG9uIHRoYXQgdG8gY29tZSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhl IHNlY3Rpb24gaGFzIHJlY2VpdmVkIGEgbGl0dGxlIHN1cHBvcnQgYW5kIGEgbGl0dGxlIG9iamVj dGlvbi4gVGhvc2Ugd2hvIHN0aWxsIHdhbnQgdG8gYWR2b2NhdGUgZm9yIGl0IG5lZWQgdG8gc2hv dyBub3Qgb25seSBjb25zZW5zdXMgZm9yIGtlZXBpbmcgaXQsIGJ1dCBhbHNvIGFjdGl2ZSBjb21t dW5pdHkgc3VwcG9ydCBmb3IgZGVwbG95aW5nIGl0LiBEZXBsb3ltZW50LCBvZiBjb3Vyc2UsIHdp bGwNCiBhbHNvIHJlcXVpcmUgc2hvd2luZyBwcm9ncmVzcyBvbiBwdWJsaWMgc3BlY2lmaWNhdGlv bnMgcHJvZmlsaW5nIHRoZSBtZWNoYW5pc20gaW50byBhIHVzZWZ1bCBpbnRlcm9wZXJhYmxlIGZl YXR1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzPyBDb3VudGVyLWFyZ3VtZW50 cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RUhMPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_180155C5EA10854997314CA5E063D18F033B0798TK5EX14MBXC111r_-- From tonynad@microsoft.com Wed Jan 26 13:53:09 2011 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 036EE3A69E8 for ; Wed, 26 Jan 2011 13:53:09 -0800 (PST) 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=[AWL=-0.000, 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 tQx-D3uTXXOj for ; Wed, 26 Jan 2011 13:53:07 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id ADB773A69E7 for ; Wed, 26 Jan 2011 13:53:06 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 26 Jan 2011 13:56:07 -0800 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.185]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0255.003; Wed, 26 Jan 2011 13:56:07 -0800 From: Anthony Nadalin To: Eran Hammer-Lahav Thread-Topic: [OAUTH-WG] Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQIaL9MwABSNlwAAEKmTQAAgBu8wABYaO7A= Date: Wed, 26 Jan 2011 21:56:07 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F033B07B0@TK5EX14MBXC111.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> <180155C5EA10854997314CA5E063D18F033A7757@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62513@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62513@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18F033B07B0TK5EX14MBXC111r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 26 Jan 2011 21:53:09 -0000 --_000_180155C5EA10854997314CA5E063D18F033B07B0TK5EX14MBXC111r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNsaWVudCBhdXQ2aGV0aWNhdGlvbiBhc3NlcnRpb24gd2FzIGFsc28gZGlzY3Vzc2VkIG1h bnkgdGltZXMgYW5kIGEgbG90IGluIHRoZSBKdWx5L0F1Z3VzdCB0aW1lIGZyYW1lLiBJIGRvbuKA mXQgYmVsaWV2ZSB0aGF0IHRoZSBpbnRyb2R1Y3Rpb24gb2YgY2xpZW50IGFzc2VydGlvbiB3YXMg YSB2aW9sYXRpb24gYXMgdGhpcyBjYW1lIGZyb20gdGhlIG1lcmdlIG9mIFdSQVAgaW50byBPQVVU SCAyLjAgYW5kIGhhcyBiZWVuIHRoZXJlIGZvciBtYW55IGRyYWZ0cyBhbmQgdGhlbiBhbGwgb2Yg YSBzdWRkZW4gdG8gZHJvcCBpdCBpcyBqdXN0IHBvb3IgcHJhY3RpY2UuDQoNCkZyb206IEVyYW4g SGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NClNlbnQ6IFR1ZXNkYXks IEphbnVhcnkgMjUsIDIwMTEgNjoxMSBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbg0KQ2M6IE9BdXRo IFdHDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENy ZWRlbnRpYWxzDQoNClNjb3BlIHdhcyBkaXNjdXNzZWQgaW4gZGV0YWlsLCBpbmNsdWRpbmcgdXNl IGNhc2VzIGFuZCBpbXBsZW1lbnRhdGlvbiBleHBlcmllbmNlIGFuZCB0aGUgY3VycmVudCBsYW5n dWFnZSB3YXMgKHBhaW5mdWxseSkgbmVnb3RpYXRlZCB0byByZWFjaCBhIGJhbGFuY2UgYmV0d2Vl biBmbGV4aWJpbGl0eSBhbmQgbGlicmFyeSBpbnRlcm9wZXJhYmlsaXR5LiBDbGllbnQgcGFzc3dv cmQgYXV0aGVudGljYXRpb24gaXMgd2VsbCB1bmRlcnN0b29kLCBpcyB0aGUgcHJpbWFyeSB3YXkg QVBJIGNhbGxzIGFyZSBhdXRoZW50aWNhdGVkIG9uIHRoZSB3ZWIgdG9kYXkgKEFQSSBrZXkgYW5k IHNlY3JldCksIGl0IGlzIGhvdyBPQXV0aCAxLjAgZGVmaW5lZCBjbGllbnQgYXV0aGVudGljYXRp b24sIGFuZCBlbmpveXMgbnVtZXJvdXMgZXhhbXBsZXMgdGhyb3VnaG91dCB0aGUgc3BlY2lmaWNh dGlvbiBmb3IgZWFjaCBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUuIEdvdCBvdGhlciBleGFtcGxl cz8NCg0KQWRkaW5nIHRoZSBwcm9wb3NlZCB0ZXh0IGluIGlzIG5vdCBhbiBvcHRpb24gZ2l2ZW4g dGhlIG9iamVjdGlvbnMgcmFpc2VkLiBUaGlzIHByb2Nlc3MgYXJndW1lbnQgaXMgbW9vdCBiZWNh dXNlIHdoZXRoZXIgd2UgcHV0IGl0IGJhY2sgaW4gb3Igbm90IGJlZm9yZSB3ZSByZWFjaCBjb25z ZW5zdXMgb24gdGhlIGxhbmd1YWdlLCBpdCB3aWxsIHRha2UgdGhlIHNhbWUgYW1vdW50IG9mIHRp bWUgdG8gZG8ganVzdCB0aGF0IOKAkyByZWFjaCBjb25zZW5zdXMuIERyYWZ0aW5nIGFub3RoZXIg c3BlYyB3aWxsIGdpdmUgdXMgdGhlIHRpbWUgdG8gcHJvcGVybHkgZGlzY3VzcyBpdCBhbmQgcmVh Y2ggYSB1c2VmdWwsIGZ1bGx5IHNwZWNpZmllZCBkb2N1bWVudCB3aXRoIGV4YW1wbGVzIGFuZCBv dGhlciBkZXRhaWxzIHRoYXQgb3RoZXJ3aXNlIHdpbGwgZGVsYXkgdGhpcyBkb2N1bWVudC4gV2Ug Zm9sbG93ZWQgdGhpcyBleGFjdCBwcm9jZXNzIGZvciB0aGUgU0FNTCBhc3NlcnRpb25zIHNwZWNp ZmljYXRpb24uDQoNCkluIGFkZGl0aW9uLCBldmVyeXRoaW5nIGluIHRoZSBzcGVjIHJpZ2h0IG5v dyBpcyBzcGVjaWZpZWQgaW4gZW5vdWdoIGRldGFpbCB0byB3cml0ZSB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbiBzZWN0aW9uLiBJIGhhdmUgbm8gY2x1ZSBob3cgYW55b25lIGNhbiBkZXNjcmli ZSB0aGUgc2VjdXJpdHkgY2hhcmFjdGVyaXN0aWNzIG9mIHRoaXMgcHJvcG9zZWQgdGV4dCBnaXZl biB0aGF0IGl0IGhhcyBhYnNvbHV0ZWx5IG5vIGRldGFpbHMgaGVscGZ1bCB0byBldmFsdWF0ZSBp dHMgc2VjdXJpdHkgcHJvcGVydGllcy4gVGhpcyBtYWtlcyB5b3VyIG9wZW5pbmcgcGFyYWdyYXBo IGluIHRoZSBwcm9wb3NlZCB0ZXh0IHNvbWVvbmUgb2YgYSB0b25ndWUgaW4gY2hlZWsuIOKAnFdo ZW4gcGFzc3dvcmRzIGFyZSBub3QgZW5vdWdoLCB1c2UgdGhpcyBzdHJvbmcgYW5kIGNvbXBsZXRl bHkgdW5kZWZpbmVkIG1ldGhvZOKAnS4NCg0KV2Ugd2lsbCBvbmx5IG1ha2UgcHJvZ3Jlc3Mgb24g dGhpcyBpZiB5b3Ugc3RvcCB0cnlpbmcgdG8gdXNlIHByb2Nlc3MgYXJndW1lbnRzIChzaW5jZSBh cyBEYXZpZCBwb2ludGVkIG91dCwgdGhpcyB3YXMgcHV0IGludG8gdGhlIHNwZWMgaW4gdmlvbGF0 aW9uIG9mIG91ciBwcm9jZXNzIGFuZCBJIGFwb2xvZ2l6ZSBmb3IgdGhhdCksIGFuZCBzdGFydCB3 b3JraW5nIHRvd2FyZHMgYSBsYW5ndWFnZSB0aGUgV0cgY2FuIGFncmVlIG9uLg0KDQpFSEwNCg0K RnJvbTogQW50aG9ueSBOYWRhbGluIFttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXTxtYWls dG86W21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dPg0KU2VudDogVHVlc2RheSwgSmFudWFy eSAyNSwgMjAxMSA1OjMyIFBNDQpUbzogRGF2aWQgUmVjb3Jkb247IEhhbm5lcy5Uc2Nob2Zlbmln QGdteC5uZXQ8bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ+OyBFcmFuIEhhbW1lci1M YWhhdg0KQ2M6IE9BdXRoIFdHOyBCbGFpbmUgQ29vaw0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10g UmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFscw0KDQpCYXNlZCBvbiB5b3VyIGxv Z2ljIHRoZW4gU2NvcGUsIENsaWVudCBQYXNzd29yZCBBdXRoZW50aWNhdGlvbiwgZXRjLCBzaG91 bGQgYmUgcmVtb3ZlZC4gTm90IHN1cmUgaG93IGxlYXZpbmcgdGhlIHByb3Bvc2VkIHRleHQgaW4g d291bGQgZGVsYXkgdGhpbmdzDQoNCkZyb206IERhdmlkIFJlY29yZG9uIFttYWlsdG86cmVjb3Jk b25kQGdtYWlsLmNvbV08bWFpbHRvOlttYWlsdG86cmVjb3Jkb25kQGdtYWlsLmNvbV0+DQpTZW50 OiBUdWVzZGF5LCBKYW51YXJ5IDI1LCAyMDExIDU6MTEgUE0NClRvOiBBbnRob255IE5hZGFsaW47 IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOkhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5u ZXQ+OyBFcmFuIEhhbW1lci1MYWhhdg0KQ2M6IE9BdXRoIFdHOyBCbGFpbmUgQ29vaw0KU3ViamVj dDogUmU6IFtPQVVUSC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFscw0K DQpFeHBsaWNpdGx5IHNheWluZywgIlRoZSBhc3NlcnRpb24gZm9ybWF0LCB0aGUgcHJvY2VzcyBi eSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlzIG9idGFpbmVkLCBhbmQgdGhlIG1ldGhvZCBvZiB2YWxp ZGF0aW5nIHRoZSBhc3NlcnRpb24gYXJlIGRlZmluZWQgYnkgdGhlIGFzc2VydGlvbiBpc3N1ZXIg YW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9m IHRoaXMgc3BlY2lmaWNhdGlvbiIgc2VlbXMgdG8gcmVpbmZvcmNlIHRoZSBwb2ludCBhYm91dCB0 aGlzIGJlaW5nIHVuZGVyc3BlY2lmaWVkLiBUaGlzIHdvdWxkIHN0aWxsIHJlcXVpcmUgYSBzZWNv bmQgZG9jdW1lbnQgd2hpY2ggZGVzY3JpYmVzIHRoZSBkYXRhIHdpdGhpbiB0aGUgU0FNTCBhc3Nl cnRpb24gYXMgd2VsbCBhcyBob3cgaXQgbWFwcyBiYWNrIHRvIGEgY2xpZW50X2lkLg0KDQpPbiB0 aGUgcHJvY2VzcyBzaWRlLCBJSVJDIHRoaXMgd2FzIGFkZGVkIHRvIHRoZSBzcGVjIHdpdGhvdXQg YW55IGNvbnNlbnN1cyBhbmQgb3ZlciBzb21lIHJlc2VydmF0aW9ucyBieSBFcmFuLi4ud2hpY2gg d2FzIGEgYnJva2VuIHByb2Nlc3MgdG8gYmVnaW4gd2l0aCBhbmQgYSBwb29yIGRlY2lzaW9uIG9u IGhpcyBwYXJ0LiBJIHNoYXJlIEhhbm5lcycgZGVzaXJlIHRvIG1vdmUgdGhpcyBiYXNlIHNwZWMg dG8gbGFzdCBjYWxsLiBXb3JyaWVkIHRoYXQgbGVhdmluZyB0aGlzIHRleHQgaW4gaXMgZ29pbmcg dG8gZGVsYXkgdGhhdCB3aGVyZWFzIG1vdmluZyBpdCB0byBhIHNlcGFyYXRlIGRvY3VtZW50IHB1 Ymxpc2hlZCBieSB0aGUgT0F1dGggV0cgd2lsbCBzdGlsbCBsZWFkIHRvd2FyZCBtYXJrZXQgYWRv cHRpb24gb2YgYSBtb3JlIGZ1bGx5IHNwZWNpZmllZCBmZWF0dXJlLg0KDQotLURhdmlkDQoNCk9u IFR1ZSwgSmFuIDI1LCAyMDExIGF0IDM6NTggUE0sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBt aWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSSBk b24ndCB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9yIHJlbW92aW5nIHRoZSBjbGllbnQgYXNz ZXJ0aW9uIGNyZWRlbnRpYWxzLCBhcyBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gaXMg bGVmdCBpbi4gQ2xpZW50IFBhc3N3b3JkIEF1dGhlbnRpY2F0aW9uIGlzIGFsc28gdW5kZXJzcGVj aWZpZWQgYXMgY2xpZW50X3NlY3JldCBjb3VsZCBiZSBhbnl0aGluZyB0aGF0IHRoZSBhdXRoZW50 aWNhdGlvbiBzZXJ2ZXIgc2VlbXMgZml0IChyYXcgY2xlYXIgdGV4dCBwYXNzd29yZCwgIGhhc2gs IGRpZ2VzdCwgZXRjLikgYW5kIG5vIHdheSB0byBkZXRlcm1pbmUgdGhlIGNvbnRlbnQuIGNsaWVu dF9zZWNyZXQgaXMgYWxzbyBhIHZlcnkgd2VhayBtZWNoYW5pc20sIHNpbmNlIHRoaXMgaXMgbGVm dCBpbiB0aGUgY29yZSB0aGlzIGxlYWRzIG1lIHRvIGJlbGlldmUgdGhhdCB0aGVyZSBpcyBzdXBw b3J0IGZvciBoYXZpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIE9hdXRoLiBJIGRvbid0IHNl ZSBob3cgaGF2aW5nIGNsaWVudF9hc3NlcnRpb24gYW5kIGNsaWVudF9hc3NlcnRpb25fdHlwZSB3 b3VsZCBiZSBzb21ldGhpbmcgdGhhdCBpcyB1bmRlcnNwZWNpZmllZCBhcyBiZWluZyBhIG1lY2hh bmlzbSBpbiB3aGljaCBhc3NlcnRpb25zIGNhbiBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbi4g QWdyZWUgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyIGhhcyB0byBtYWtlIHJpZ2h0IGFu ZCBkZWNsYXJlIHdoYXQgaXMgYmVpbmcgdXNlZCBidXQgdGhhdCBpcyB0aGUgc2FtZSBmb3IgY2xp ZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFz c2VydGlvbnMgYXJlIHNvbWV0aGluZyB0aGF0IE1pY3Jvc29mdCBhbmQgR29vZ2xlIGZpbmQgdXNl ZnVsIGFuZCBwbGFuIG9uIGltcGxlbWVudGluZyBhbmQgdXNpbmcgYXMgYSBtZWFucyBmb3Igc3Ry b25nZXIgYXV0aGVudGljYXRpb24gdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGlzIGV4 dGVuc2liaWxpdHkgYmVsb25ncyBpbiB0aGUgY29yZSwgdGhlcmUgaXMgbm8gb3RoZXIgcGxhY2Ug dG8gcHV0IHRoaXMgZnVuY3Rpb25hbGl0eS4gSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhlIHJlbW92 YWwgKGVpdGhlciBieSBlZGl0b3Igb3IgZGlyZWN0aW9uIGJ5IGNvLWNoYWlyKSBpcyBzb21ldGhp bmcgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIGRvbmUgdy9vIGEgY29uc2Vuc3VzIHZvdGUgc2luY2Ug dGhpcyBoYXMgYmVlbiBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3Igc29tZSB0aW1lIHdpdGhvdXQg aXNzdWUgYW5kIHRoZSByZW1vdmFsIGNvbWVzIGFzIGNvbXBsZXRlIHVud2VsY29tZSBzdXJwcmlz ZS4gR2V0dGluZyBhbG1vc3QgdG90YWwgcmV3cml0ZXMgb2YgdGhlIHNwZWNpZmljYXRpb24gdGhp cyBsYXRlIGluIHRoZSByZXZpZXcgY3ljbGUgaXMgYWxzbyB2ZXJ5IGRpc3R1cmJpbmcuDQoNCg0K DQpBIHByb3Bvc2FsIGZvciBrZWVwaW5nIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gYXNzZXJ0 aW9uIHdvdWxkIGJlIHRvIHNpbXBsaWZ5IHRvIHRoZSBmb2xsb3dpbmc7DQoNClRoZSBjbGllbnQg YXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGFyZSB1c2VkIGluIGNhc2VzIHdoZXJlIGEgcGFzc3dvcmQg KGNsZWFyLXRleHQgc2hhcmVkIHN5bW1ldHJpYyBzZWNyZXQpIGlzIHVuc3VpdGFibGUgb3IgZG9l cyBub3QgcHJvdmlkZSBzdWZmaWNpZW50IHNlY3VyaXR5IGZvciBjbGllbnQgYXV0aGVudGljYXRp b24uIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIHByb3ZpZGUgYW4gZXh0ZW5zaWJs ZSBtZWNoYW5pc20gdG8gdXNlIGFuIGFzc2VydGlvbiBmb3JtYXQgc3VwcG9ydGVkIGJ5IHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciBmb3IgYXV0aGVudGljYXRpb24gb2YgdGhlIGNsaWVudC4NCg0K VXNpbmcgYXNzZXJ0aW9ucyByZXF1aXJlcyB0aGUgY2xpZW50IHRvIG9idGFpbiBhbiBhc3NlcnRp b24gKHN1Y2ggYXMgYSBTQU1MIChDYW50b3IsIFMuLCBLZW1wLCBKLiwgUGhpbHBvdHQsIFIuLCBh bmQgRS4gTWFsZXIsIOKAnEFzc2VydGlvbnMgYW5kIFByb3RvY29sIGZvciB0aGUgT0FTSVMgU2Vj dXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAoU0FNTCkgVjIuMCzigJ0gTWFyY2ggMjAw NS4pIFtPQVNJUy5zYW1s4oCRY29yZeKAkTIuMOKAkW9zXSBhc3NlcnRpb24pIGZyb20gYW4gYXNz ZXJ0aW9uIGlzc3VlciBvciB0byBzZWxmLWlzc3VlIGFuIGFzc2VydGlvbi4gVGhlIGFzc2VydGlv biBmb3JtYXQsIHRoZSBwcm9jZXNzIGJ5IHdoaWNoIHRoZSBhc3NlcnRpb24gaXMgb2J0YWluZWQs IGFuZCB0aGUgbWV0aG9kIG9mIHZhbGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmUgZGVmaW5lZCBi eSB0aGUgYXNzZXJ0aW9uIGlzc3VlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBhbmQg YXJlIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpXaGVuIHVzaW5n IGEgY2xpZW50IGFzc2VydGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBh cmFtZXRlcnM6DQpjbGllbnRfYXNzZXJ0aW9uX3R5cGUgLSBSRVFVSVJFRC4gVGhlIGZvcm1hdCBv ZiB0aGUgYXNzZXJ0aW9uIGFzIGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBU aGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0ZSBVUkkuDQpjbGllbnRfYXNzZXJ0aW9uIC0gUkVR VUlSRUQuIFRoZSBjbGllbnQgYXNzZXJ0aW9uLg0KDQpGb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBz ZW5kcyB0aGUgZm9sbG93aW5nIGFjY2VzcyB0b2tlbiByZXF1ZXN0IHVzaW5nIGEgU0FNTCAyLjAg YXNzZXJ0aW9uIHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYgKGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlz cGxheSBwdXJwb3NlcyBvbmx5KToNCg0KDQoNCg0KDQogIFBPU1QgL3Rva2VuIEhUVFAvMS4xDQoN CiAgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tPGh0dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20+DQoN CiAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQNCg0KDQoN CiAgZ3JhbnRfdHlwZT1hdXRob3JpemF0aW9uX2NvZGUmY29kZT1pMVdzUm4xdUIxJg0KDQogIGNs aWVudF9hc3NlcnRpb249UEhOaGJXeHdPbFsuLi5vbWl0dGVkIGZvciBicmV2aXR5Li4uXVpUNCUz RCYNCg0KICBjbGllbnRfYXNzZXJ0aW9uX3R5cGU9ICB1cm4lM0FvYXNpcyUzQW5hbWVzJXNBdGMl M0FTQU1MJTNBMi4wJTNBYXNzZXJ0aW9uJnJlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVu dCUyRWV4YW1wbGUlMkVjb20lMkZjYg0KDQoNCg0KDQoNCg0KRnJvbTogb2F1dGgtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m IEVyYW4gSGFtbWVyLUxhaGF2DQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTQsIDIwMTEgMTA6NDUg UE0NClRvOiBPQXV0aCBXRw0KU3ViamVjdDogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNz ZXJ0aW9uIENyZWRlbnRpYWxzDQoNCkkgd291bGQgbGlrZSB0byBzdWdnZXN0IHdlIGRyb3AgdGhl IGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgKC0xMSBzZWN0aW9uIDMuMikgZnJvbSB0aGUg c3BlY2lmaWNhdGlvbiwgYW5kIGlmIG5lZWRlZCwgcHVibGlzaCBpdCBhcyBhIHNlcGFyYXRlIHNw ZWNpZmljYXRpb24gZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoNCg0KDQoxLiAgICAgICBUaGUg bWVjaGFuaXNtIGlzIHVuZGVyIHNwZWNpZmllZCwgZXNwZWNpYWxseSBpbiBpdHMgaGFuZGxpbmcg b2YgdGhlIGNsaWVudF9pZCBpZGVudGlmaWVyICh3aGVuIHVzZWQgdG8gb2J0YWluIGVuZC11c2Vy IGF1dGhvcml6YXRpb24pLiBJdCBkb2VzIG5vdCBjb250YWluIGFueSBpbXBsZW1lbnRhdGlvbiBk ZXRhaWxzIHRvIGFjY29tcGxpc2ggYW55IGxldmVsIG9mIGludGVyb3BlcmFiaWxpdHkgb3IgZnVu Y3Rpb25hbGl0eS4gVGhpcyBpcyBpbiBjb250cmFzdCB0byB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5 cGUgd2hpY2ggaGFzIG1hdHVyZWQgb3ZlciBhIHllYXIgaW50byBhIGZ1bGx5IHRob3VnaHQtb3V0 IGV4dGVuc2lvbiBtZWNoYW5pc20sIGFzIHdlbGwgYXMgYSBzZXBhcmF0ZSBTQU1MIGFzc2VydGlv biBzcGVjaWZpY2F0aW9uIHdpdGggYWN0aXZlIGRlcGxveW1lbnQgKHRoZSB0d28sIHRvZ2V0aGVy IHdpdGggcnVubmluZyBjb2RlLCBzaG93IGNsZWFyIGNvbnNlbnN1cykuDQoNCjIuICAgICAgIFRo ZSBzZWN0aW9uIGlzIGEgY29uZnVzZWQgbWl4IG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNw cmlua2xlZCB3aXRoIG5vcm1hdGl2ZSBsYW5ndWFnZS4gSW5zdGVhZCwgaXQgc2hvdWxkIGJlIHJl cGxhY2VkIHdpdGggZ3VpZGVsaW5lcyBmb3IgZXh0ZW5kaW5nIHRoZSBzZXQgb2Ygc3VwcG9ydGVk IGNsaWVudCBjcmVkZW50aWFscywgYnV0IHdpdGhvdXQgZGVmaW5pbmcgYSBuZXcgcmVnaXN0cnku IEl0IGlzIGNsZWFybHkgYW4gYXJlYSBvZiBsaXR0bGUgZGVwbG95bWVudCBleHBlcmllbmNlIGZv ciBPQXV0aCwgYW5kIHRoYXQgaW5jbHVkZXMgdXNpbmcgSFRUUCBCYXNpYyBhdXRoZW50aWNhdGlv biBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uIChtb3JlIG9uIHRoYXQgdG8gY29tZSkuDQoNCjMu ICAgICAgIFRoZSBzZWN0aW9uIGhhcyByZWNlaXZlZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxp dHRsZSBvYmplY3Rpb24uIFRob3NlIHdobyBzdGlsbCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBu ZWVkIHRvIHNob3cgbm90IG9ubHkgY29uc2Vuc3VzIGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBh Y3RpdmUgY29tbXVuaXR5IHN1cHBvcnQgZm9yIGRlcGxveWluZyBpdC4gRGVwbG95bWVudCwgb2Yg Y291cnNlLCB3aWxsIGFsc28gcmVxdWlyZSBzaG93aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVj aWZpY2F0aW9ucyBwcm9maWxpbmcgdGhlIG1lY2hhbmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3Bl cmFibGUgZmVhdHVyZS4NCg0KQ29tbWVudHM/IENvdW50ZXItYXJndW1lbnRzPw0KDQpFSEwNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0 aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K --_000_180155C5EA10854997314CA5E063D18F033B07B0TK5EX14MBXC111r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250 LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxl LXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw YW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGUgY2xpZW50IGF1dDZoZXRpY2F0 aW9uIGFzc2VydGlvbiB3YXMgYWxzbyBkaXNjdXNzZWQgbWFueSB0aW1lcyBhbmQgYSBsb3QgaW4g dGhlIEp1bHkvQXVndXN0IHRpbWUgZnJhbWUuIEkgZG9u4oCZdCBiZWxpZXZlIHRoYXQgdGhlIGlu dHJvZHVjdGlvbiBvZiBjbGllbnQgYXNzZXJ0aW9uDQogd2FzIGEgdmlvbGF0aW9uIGFzIHRoaXMg Y2FtZSBmcm9tIHRoZSBtZXJnZSBvZiBXUkFQIGludG8gT0FVVEggMi4wIGFuZCBoYXMgYmVlbiB0 aGVyZSBmb3IgbWFueSBkcmFmdHMgYW5kIHRoZW4gYWxsIG9mIGEgc3VkZGVuIHRvIGRyb3AgaXQg aXMganVzdCBwb29yIHByYWN0aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyYW4gSGFtbWVyLUxh aGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBKYW51YXJ5IDI1LCAyMDExIDY6MTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFk YWxpbjxicj4NCjxiPkNjOjwvYj4gT0F1dGggV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtP QVVUSC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFsczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TY29wZSB3YXMgZGlzY3Vzc2VkIGluIGRldGFpbCwgaW5j bHVkaW5nIHVzZSBjYXNlcyBhbmQgaW1wbGVtZW50YXRpb24gZXhwZXJpZW5jZSBhbmQgdGhlIGN1 cnJlbnQgbGFuZ3VhZ2Ugd2FzIChwYWluZnVsbHkpIG5lZ290aWF0ZWQgdG8gcmVhY2ggYSBiYWxh bmNlIGJldHdlZW4NCiBmbGV4aWJpbGl0eSBhbmQgbGlicmFyeSBpbnRlcm9wZXJhYmlsaXR5LiBD bGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gaXMgd2VsbCB1bmRlcnN0b29kLCBpcyB0aGUg cHJpbWFyeSB3YXkgQVBJIGNhbGxzIGFyZSBhdXRoZW50aWNhdGVkIG9uIHRoZSB3ZWIgdG9kYXkg KEFQSSBrZXkgYW5kIHNlY3JldCksIGl0IGlzIGhvdyBPQXV0aCAxLjAgZGVmaW5lZCBjbGllbnQg YXV0aGVudGljYXRpb24sIGFuZCBlbmpveXMgbnVtZXJvdXMgZXhhbXBsZXMNCiB0aHJvdWdob3V0 IHRoZSBzcGVjaWZpY2F0aW9uIGZvciBlYWNoIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZS4gR290 IG90aGVyIGV4YW1wbGVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWRkaW5nIHRoZSBwcm9wb3NlZCB0ZXh0IGluIGlz IG5vdCBhbiBvcHRpb24gZ2l2ZW4gdGhlIG9iamVjdGlvbnMgcmFpc2VkLiBUaGlzIHByb2Nlc3Mg YXJndW1lbnQgaXMgbW9vdCBiZWNhdXNlIHdoZXRoZXIgd2UgcHV0IGl0IGJhY2sgaW4gb3Igbm90 IGJlZm9yZSB3ZSByZWFjaA0KIGNvbnNlbnN1cyBvbiB0aGUgbGFuZ3VhZ2UsIGl0IHdpbGwgdGFr ZSB0aGUgc2FtZSBhbW91bnQgb2YgdGltZSB0byBkbyBqdXN0IHRoYXQg4oCTIHJlYWNoIGNvbnNl bnN1cy4gRHJhZnRpbmcgYW5vdGhlciBzcGVjIHdpbGwgZ2l2ZSB1cyB0aGUgdGltZSB0byBwcm9w ZXJseSBkaXNjdXNzIGl0IGFuZCByZWFjaCBhIHVzZWZ1bCwgZnVsbHkgc3BlY2lmaWVkIGRvY3Vt ZW50IHdpdGggZXhhbXBsZXMgYW5kIG90aGVyIGRldGFpbHMgdGhhdCBvdGhlcndpc2UNCiB3aWxs IGRlbGF5IHRoaXMgZG9jdW1lbnQuIFdlIGZvbGxvd2VkIHRoaXMgZXhhY3QgcHJvY2VzcyBmb3Ig dGhlIFNBTUwgYXNzZXJ0aW9ucyBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gYWRkaXRpb24s IGV2ZXJ5dGhpbmcgaW4gdGhlIHNwZWMgcmlnaHQgbm93IGlzIHNwZWNpZmllZCBpbiBlbm91Z2gg ZGV0YWlsIHRvIHdyaXRlIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24uIEkgaGF2 ZSBubyBjbHVlIGhvdyBhbnlvbmUgY2FuIGRlc2NyaWJlDQogdGhlIHNlY3VyaXR5IGNoYXJhY3Rl cmlzdGljcyBvZiB0aGlzIHByb3Bvc2VkIHRleHQgZ2l2ZW4gdGhhdCBpdCBoYXMgYWJzb2x1dGVs eSBubyBkZXRhaWxzIGhlbHBmdWwgdG8gZXZhbHVhdGUgaXRzIHNlY3VyaXR5IHByb3BlcnRpZXMu IFRoaXMgbWFrZXMgeW91ciBvcGVuaW5nIHBhcmFncmFwaCBpbiB0aGUgcHJvcG9zZWQgdGV4dCBz b21lb25lIG9mIGEgdG9uZ3VlIGluIGNoZWVrLiDigJxXaGVuIHBhc3N3b3JkcyBhcmUgbm90IGVu b3VnaCwgdXNlDQogdGhpcyBzdHJvbmcgYW5kIGNvbXBsZXRlbHkgdW5kZWZpbmVkIG1ldGhvZOKA nS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPldlIHdpbGwgb25seSBtYWtlIHByb2dyZXNzIG9uIHRoaXMgaWYgeW91IHN0 b3AgdHJ5aW5nIHRvIHVzZSBwcm9jZXNzIGFyZ3VtZW50cyAoc2luY2UgYXMgRGF2aWQgcG9pbnRl ZCBvdXQsIHRoaXMgd2FzIHB1dCBpbnRvIHRoZSBzcGVjIGluIHZpb2xhdGlvbiBvZiBvdXIgcHJv Y2Vzcw0KIGFuZCBJIGFwb2xvZ2l6ZSBmb3IgdGhhdCksIGFuZCBzdGFydCB3b3JraW5nIHRvd2Fy ZHMgYSBsYW5ndWFnZSB0aGUgV0cgY2FuIGFncmVlIG9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RUhMPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEFudGhvbnkgTmFkYWxpbg0KPGEg aHJlZj0ibWFpbHRvOlttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXSI+W21haWx0bzp0b255 bmFkQG1pY3Jvc29mdC5jb21dPC9hPg0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVh cnkgMjUsIDIwMTEgNTozMiBQTTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgUmVjb3Jkb247IDxhIGhy ZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0Ij5IYW5uZXMuVHNjaG9mZW5pZ0Bn bXgubmV0PC9hPjsgRXJhbiBIYW1tZXItTGFoYXY8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHOyBC bGFpbmUgQ29vazxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW09BVVRILVdHXSBSZW1vdmFsOiBD bGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkJhc2VkIG9uIHlvdXIgbG9naWMgdGhlbiBTY29wZSwgQ2xpZW50IFBhc3N3b3JkIEF1dGhl bnRpY2F0aW9uLCBldGMsIHNob3VsZCBiZSByZW1vdmVkLiBOb3Qgc3VyZSBob3cgbGVhdmluZyB0 aGUgcHJvcG9zZWQgdGV4dCBpbiB3b3VsZCBkZWxheSB0aGluZ3M8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERhdmlkIFJlY29yZG9uDQo8YSBocmVmPSJtYWlsdG86 W21haWx0bzpyZWNvcmRvbmRAZ21haWwuY29tXSI+W21haWx0bzpyZWNvcmRvbmRAZ21haWwuY29t XTwvYT4gPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgNToxMSBQ TTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluOyA8YSBocmVmPSJtYWlsdG86SGFubmVz LlRzY2hvZmVuaWdAZ214Lm5ldCI+SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldDwvYT47IEVyYW4g SGFtbWVyLUxhaGF2PGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRzsgQmxhaW5lIENvb2s8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBD cmVkZW50aWFsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXhwbGljaXRseSBzYXlp bmcsICZxdW90OzxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5UaGUgYXNzZXJ0aW9uIGZvcm1hdCwgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhl IGFzc2VydGlvbiBpcyBvYnRhaW5lZCwgYW5kIHRoZSBtZXRob2Qgb2YgdmFsaWRhdGluZyB0aGUg YXNzZXJ0aW9uIGFyZSBkZWZpbmVkDQogYnkgdGhlIGFzc2VydGlvbiBpc3N1ZXIgYW5kIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlciwgYW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbiZxdW90OyBzZWVtcyB0byByZWluZm9yY2UgdGhlIHBvaW50IGFib3V0IHRoaXMg YmVpbmcgdW5kZXJzcGVjaWZpZWQuIFRoaXMgd291bGQgc3RpbGwgcmVxdWlyZSBhIHNlY29uZCBk b2N1bWVudCB3aGljaCBkZXNjcmliZXMgdGhlIGRhdGEgd2l0aGluIHRoZSBTQU1MIGFzc2VydGlv bg0KIGFzIHdlbGwgYXMgaG93IGl0IG1hcHMgYmFjayB0byBhIGNsaWVudF9pZC48L3NwYW4+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PbiB0aGUgcHJvY2VzcyBzaWRlLCBJ SVJDIHRoaXMgd2FzIGFkZGVkIHRvIHRoZSBzcGVjIHdpdGhvdXQgYW55IGNvbnNlbnN1cyBhbmQg b3ZlciBzb21lIHJlc2VydmF0aW9ucyBieSBFcmFuLi4ud2hpY2ggd2FzIGEgYnJva2VuIHByb2Nl c3MgdG8gYmVnaW4gd2l0aCBhbmQgYQ0KIHBvb3IgZGVjaXNpb24gb24gaGlzIHBhcnQuIEkgc2hh cmUgSGFubmVzJyBkZXNpcmUgdG8gbW92ZSB0aGlzIGJhc2Ugc3BlYyB0byBsYXN0IGNhbGwuIFdv cnJpZWQgdGhhdCBsZWF2aW5nIHRoaXMgdGV4dCBpbiBpcyBnb2luZyB0byBkZWxheSB0aGF0IHdo ZXJlYXMgbW92aW5nIGl0IHRvIGEgc2VwYXJhdGUgZG9jdW1lbnQgcHVibGlzaGVkIGJ5IHRoZSBP QXV0aCBXRyB3aWxsIHN0aWxsIGxlYWQgdG93YXJkIG1hcmtldCBhZG9wdGlvbiBvZiBhIG1vcmUN CiBmdWxseSBzcGVjaWZpZWQgZmVhdHVyZS48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt c3R5bGUtc3BhbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tRGF2aWQ8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEphbiAyNSwgMjAxMSBhdCAzOjU4IFBNLCBBbnRob255IE5hZGFsaW4gJmx0 OzxhIGhyZWY9Im1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPnRvbnluYWRAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cD5JIGRv bid0IHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBmb3IgcmVtb3ZpbmcgdGhlIGNsaWVudCBhc3Nl cnRpb24gY3JlZGVudGlhbHMsIGFzIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiBpcyBs ZWZ0IGluLiBDbGllbnQgUGFzc3dvcmQgQXV0aGVudGljYXRpb24gaXMgYWxzbyB1bmRlcnNwZWNp ZmllZCBhcyBjbGllbnRfc2VjcmV0IGNvdWxkIGJlIGFueXRoaW5nIHRoYXQgdGhlIGF1dGhlbnRp Y2F0aW9uIHNlcnZlciBzZWVtcyBmaXQNCiAocmF3IGNsZWFyIHRleHQgcGFzc3dvcmQsJm5ic3A7 IGhhc2gsIGRpZ2VzdCwgZXRjLikgYW5kIG5vIHdheSB0byBkZXRlcm1pbmUgdGhlIGNvbnRlbnQu IGNsaWVudF9zZWNyZXQgaXMgYWxzbyBhIHZlcnkgd2VhayBtZWNoYW5pc20sIHNpbmNlIHRoaXMg aXMgbGVmdCBpbiB0aGUgY29yZSB0aGlzIGxlYWRzIG1lIHRvIGJlbGlldmUgdGhhdCB0aGVyZSBp cyBzdXBwb3J0IGZvciBoYXZpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIE9hdXRoLiBJIGRv bid0DQogc2VlIGhvdyBoYXZpbmcgY2xpZW50X2Fzc2VydGlvbiBhbmQgY2xpZW50X2Fzc2VydGlv bl90eXBlIHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGlzIHVuZGVyc3BlY2lmaWVkIGFzIGJlaW5n IGEgbWVjaGFuaXNtIGluIHdoaWNoIGFzc2VydGlvbnMgY2FuIGJlIHVzZWQgZm9yIGF1dGhlbnRp Y2F0aW9uLiBBZ3JlZSB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgaGFzIHRvIG1ha2Ug cmlnaHQgYW5kIGRlY2xhcmUgd2hhdCBpcyBiZWluZyB1c2VkDQogYnV0IHRoYXQgaXMgdGhlIHNh bWUgZm9yIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbi4gVGhlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBhc3NlcnRpb25zIGFyZSBzb21ldGhpbmcgdGhhdCBNaWNyb3NvZnQgYW5kIEdvb2ds ZSBmaW5kIHVzZWZ1bCBhbmQgcGxhbiBvbiBpbXBsZW1lbnRpbmcgYW5kIHVzaW5nIGFzIGEgbWVh bnMgZm9yIHN0cm9uZ2VyIGF1dGhlbnRpY2F0aW9uIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ci4gVGhpcyBleHRlbnNpYmlsaXR5DQogYmVsb25ncyBpbiB0aGUgY29yZSwgdGhlcmUgaXMgbm8g b3RoZXIgcGxhY2UgdG8gcHV0IHRoaXMgZnVuY3Rpb25hbGl0eS4gSSBkb24ndCBiZWxpZXZlIHRo YXQgdGhlIHJlbW92YWwgKGVpdGhlciBieSBlZGl0b3Igb3IgZGlyZWN0aW9uIGJ5IGNvLWNoYWly KSBpcyBzb21ldGhpbmcgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIGRvbmUgdy9vIGEgY29uc2Vuc3Vz IHZvdGUgc2luY2UgdGhpcyBoYXMgYmVlbiBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3Igc29tZQ0K IHRpbWUgd2l0aG91dCBpc3N1ZSBhbmQgdGhlIHJlbW92YWwgY29tZXMgYXMgY29tcGxldGUgdW53 ZWxjb21lIHN1cnByaXNlLiBHZXR0aW5nIGFsbW9zdCB0b3RhbCByZXdyaXRlcyBvZiB0aGUgc3Bl Y2lmaWNhdGlvbiB0aGlzIGxhdGUgaW4gdGhlIHJldmlldyBjeWNsZSBpcyBhbHNvIHZlcnkgZGlz dHVyYmluZy48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+QSBw cm9wb3NhbCBmb3Iga2VlcGluZyB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiB3 b3VsZCBiZSB0byBzaW1wbGlmeSB0byB0aGUgZm9sbG93aW5nOzxvOnA+PC9vOnA+PC9wPg0KPHA+ PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlIGNsaWVudCBhc3NlcnRpb24g Y3JlZGVudGlhbHMgYXJlIHVzZWQgaW4gY2FzZXMgd2hlcmUgYSBwYXNzd29yZCAoY2xlYXItdGV4 dCBzaGFyZWQgc3ltbWV0cmljIHNlY3JldCkgaXMgdW5zdWl0YWJsZSBvciBkb2VzIG5vdCBwcm92 aWRlIHN1ZmZpY2llbnQgc2VjdXJpdHkgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gVGhlIGNs aWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMNCiBwcm92aWRlIGFuIGV4dGVuc2libGUgbWVjaGFu aXNtIHRvIHVzZSBhbiBhc3NlcnRpb24gZm9ybWF0IHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXph dGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBjbGllbnQuDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Vc2lu ZyBhc3NlcnRpb25zIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFzc2VydGlvbiAo c3VjaCBhcyBhDQo8L3NwYW4+PGEgaHJlZj0iIzEyZGJmOWQyOWEyZWU3Y2RfT0FTSVMuc2FtbC1j b3JlLTIuMC1vcyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZSI+ U0FNTCAoQ2FudG9yLCBTLiwgS2VtcCwgSi4sIFBoaWxwb3R0LCBSLiwgYW5kIEUuIE1hbGVyLCDi gJxBc3NlcnRpb25zIGFuZCBQcm90b2NvbCBmb3IgdGhlIE9BU0lTIFNlY3VyaXR5IEFzc2VydGlv biBNYXJrdXAgTGFuZ3VhZ2UgKFNBTUwpIFYyLjAs4oCdIE1hcmNoJm5ic3A7MjAwNS4pPC9zcGFu PjwvYT48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImNvbG9yOmJsYWNrIj4NCiBbT0FTSVMuc2FtbOKA kWNvcmXigJEyLjDigJFvc10gYXNzZXJ0aW9uKSBmcm9tIGFuIGFzc2VydGlvbiBpc3N1ZXIgb3Ig dG8gc2VsZi1pc3N1ZSBhbiBhc3NlcnRpb24uIFRoZSBhc3NlcnRpb24gZm9ybWF0LCB0aGUgcHJv Y2VzcyBieSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlzIG9idGFpbmVkLCBhbmQgdGhlIG1ldGhvZCBv ZiB2YWxpZGF0aW5nIHRoZSBhc3NlcnRpb24gYXJlIGRlZmluZWQgYnkgdGhlIGFzc2VydGlvbiBp c3N1ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uDQogc2VydmVyLCBhbmQgYXJlIGJleW9uZCB0aGUg c2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImNvbG9yOmJsYWNrIj5XaGVuIHVzaW5nIGEgY2xpZW50IGFz c2VydGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6DQo8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLXJpZ2h0OjYwLjBwdDttYXJnaW4tbGVmdDo2MC4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJjb2xvcjpibGFjayI+Y2xpZW50X2Fzc2VydGlvbl90 eXBlIC0gUkVRVUlSRUQuIFRoZSBmb3JtYXQgb2YgdGhlIGFzc2VydGlvbiBhcyBkZWZpbmVkIGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlIHZhbHVlIE1VU1QgYmUgYW4gYWJzb2x1dGUg VVJJLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjI0LjBwdDt0ZXh0LWluZGVudDouNWluIj4NCjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0i Y29sb3I6YmxhY2siPmNsaWVudF9hc3NlcnRpb24gLSBSRVFVSVJFRC4gVGhlIGNsaWVudCBhc3Nl cnRpb24uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImNvbG9yOmJsYWNrIj5Gb3IgZXhhbXBsZSwgdGhlIGNsaWVudCBzZW5kcyB0aGUgZm9sbG93aW5n IGFjY2VzcyB0b2tlbiByZXF1ZXN0IHVzaW5nIGEgU0FNTCAyLjAgYXNzZXJ0aW9uIHRvIGF1dGhl bnRpY2F0ZSBpdHNlbGYgKGxpbmUgYnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5 KToNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDowaW47bWFyZ2luLXJpZ2h0OjI0LjBwdDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDo2 MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21h cmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6NjAuMHB0O21h cmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7IFBPU1QgL3Rva2VuIEhUVFAv MS4xPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6MGluO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6 NjAuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyBIb3N0 OiA8YSBocmVmPSJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2Vy dmVyLmV4YW1wbGUuY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJFTiI+Jm5ic3A7IENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxl bmNvZGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyBn cmFudF90eXBlPWF1dGhvcml6YXRpb25fY29kZSZhbXA7Y29kZT1pMVdzUm4xdUIxJmFtcDs8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyBjbGllbnRf YXNzZXJ0aW9uPVBITmhiV3h3T2xbLi4ub21pdHRlZCBmb3IgYnJldml0eS4uLl1aVDQlM0QmYW1w Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7IGNs aWVudF9hc3NlcnRpb25fdHlwZT0gJm5ic3A7dXJuJTNBb2FzaXMlM0FuYW1lcyVzQXRjJTNBU0FN TCUzQTIuMCUzQWFzc2VydGlvbiZhbXA7cmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50 JTJFZXhhbXBsZSUyRWNvbSUyRmNiPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWxlZnQ6NjAuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFu Zz0iRU4iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHA+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4NCjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0 bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmFuIEhh bW1lci1MYWhhdjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgMTQsIDIwMTEgMTA6 NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IE9BdXRoIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtPQVVU SC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFsczwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgd291 bGQgbGlrZSB0byBzdWdnZXN0IHdlIGRyb3AgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlh bHMgKC0xMSBzZWN0aW9uIDMuMikgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbiwgYW5kIGlmIG5lZWRl ZCwgcHVibGlzaCBpdCBhcyBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBmb2xsb3dp bmcNCiByZWFzb25zOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwPjEuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5UaGUgbWVjaGFuaXNtIGlz IHVuZGVyIHNwZWNpZmllZCwgZXNwZWNpYWxseSBpbiBpdHMgaGFuZGxpbmcgb2YgdGhlIGNsaWVu dF9pZCBpZGVudGlmaWVyICh3aGVuIHVzZWQgdG8gb2J0YWluIGVuZC11c2VyIGF1dGhvcml6YXRp b24pLiBJdCBkb2VzIG5vdCBjb250YWluIGFueSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRvIGFj Y29tcGxpc2ggYW55IGxldmVsIG9mDQogaW50ZXJvcGVyYWJpbGl0eSBvciBmdW5jdGlvbmFsaXR5 LiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvIHRoZSBhc3NlcnRpb24gZ3JhbnQgdHlwZSB3aGljaCBo YXMgbWF0dXJlZCBvdmVyIGEgeWVhciBpbnRvIGEgZnVsbHkgdGhvdWdodC1vdXQgZXh0ZW5zaW9u IG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBhIHNlcGFyYXRlIFNBTUwgYXNzZXJ0aW9uIHNwZWNpZmlj YXRpb24gd2l0aCBhY3RpdmUgZGVwbG95bWVudCAodGhlIHR3bywgdG9nZXRoZXIgd2l0aA0KIHJ1 bm5pbmcgY29kZSwgc2hvdyBjbGVhciBjb25zZW5zdXMpLjxvOnA+PC9vOnA+PC9wPg0KPHA+Mi48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPlRoZSBzZWN0aW9uIGlzIGEgY29uZnVzZWQgbWl4IG9mIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHNwcmlua2xlZCB3aXRoIG5vcm1hdGl2ZSBsYW5ndWFnZS4gSW5zdGVh ZCwgaXQgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggZ3VpZGVsaW5lcyBmb3IgZXh0ZW5kaW5nIHRo ZSBzZXQgb2Ygc3VwcG9ydGVkIGNsaWVudCBjcmVkZW50aWFscywgYnV0IHdpdGhvdXQgZGVmaW5p bmcNCiBhIG5ldyByZWdpc3RyeS4gSXQgaXMgY2xlYXJseSBhbiBhcmVhIG9mIGxpdHRsZSBkZXBs b3ltZW50IGV4cGVyaWVuY2UgZm9yIE9BdXRoLCBhbmQgdGhhdCBpbmNsdWRlcyB1c2luZyBIVFRQ IEJhc2ljIGF1dGhlbnRpY2F0aW9uIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gKG1vcmUgb24g dGhhdCB0byBjb21lKS48bzpwPjwvbzpwPjwvcD4NCjxwPjMuPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5UaGUg c2VjdGlvbiBoYXMgcmVjZWl2ZWQgYSBsaXR0bGUgc3VwcG9ydCBhbmQgYSBsaXR0bGUgb2JqZWN0 aW9uLiBUaG9zZSB3aG8gc3RpbGwgd2FudCB0byBhZHZvY2F0ZSBmb3IgaXQgbmVlZCB0byBzaG93 IG5vdCBvbmx5IGNvbnNlbnN1cyBmb3Iga2VlcGluZyBpdCwgYnV0IGFsc28gYWN0aXZlIGNvbW11 bml0eSBzdXBwb3J0IGZvciBkZXBsb3lpbmcgaXQuIERlcGxveW1lbnQsDQogb2YgY291cnNlLCB3 aWxsIGFsc28gcmVxdWlyZSBzaG93aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9u cyBwcm9maWxpbmcgdGhlIG1lY2hhbmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVh dHVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbW1lbnRzPyBDb3VudGVyLWFyZ3Vt ZW50cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkVITDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmci Pk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_180155C5EA10854997314CA5E063D18F033B07B0TK5EX14MBXC111r_-- From beaton@google.com Wed Jan 26 13:59:29 2011 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 05E1F3A68B7 for ; Wed, 26 Jan 2011 13:59:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKwRBib5T8Uf for ; Wed, 26 Jan 2011 13:59:27 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 2F1533A69EB for ; Wed, 26 Jan 2011 13:59:27 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p0QM2RSO031349 for ; Wed, 26 Jan 2011 14:02:27 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296079348; bh=xBL8i92PZtrg8penJQI84hr0Wf0=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=fYTRQrybpoSOGZfO0LiZk7ssTwTzI1ZsnY03XNKmQV/IhQ4DL4HPIjCJKXLadL3IU uh7eD5U+IJ/Ru2m5cPzYg== Received: from pzk28 (pzk28.prod.google.com [10.243.19.156]) by wpaz17.hot.corp.google.com with ESMTP id p0QM2PxF006559 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 14:02:26 -0800 Received: by pzk28 with SMTP id 28so199165pzk.7 for ; Wed, 26 Jan 2011 14:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fK/gmz9R7xkp6egfitBbYWqDFkScQlyPmZjqHBe3uzQ=; b=gfIb6+aUbkwzlaZjx5C5DBOEOKZfqvWAhPa9F8pEbvjqIcJObyKXlaqfXH7tzkWofi rmQlpU3j5TVQmyAuoinQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZfHH7oOouAzAvniIq+BkCHFmliEYMsUdPfKXX3j0iPWs2kW6/3Npu8WoJvwV2ej917 HoHOYqs6IwwouHcfvqZw== MIME-Version: 1.0 Received: by 10.142.169.3 with SMTP id r3mr976188wfe.226.1296079345241; Wed, 26 Jan 2011 14:02:25 -0800 (PST) Received: by 10.142.213.7 with HTTP; Wed, 26 Jan 2011 14:02:25 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62609@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723445A8D62544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62609@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 26 Jan 2011 14:02:25 -0800 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] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 26 Jan 2011 21:59:29 -0000 On Wed, Jan 26, 2011 at 9:07 AM, Eran Hammer-Lahav wrote: > Can you share an actual example of how you are authenticating *both* the resource owner and client in a single request? That's not a business requirement. So the desired flow goes like this: kerberos (or other magic sauce) authentication -> access token not like this: client authentication + kerberos authentication -> access token and definitely not like this: client authentication + kerberos authentication -> refresh token If we did see a need to authenticate the client, we would use the same mechanisms as normal: client_id and client_secret, or else client_assertion. (Curious to know if other people looking at these problems break it down the same way.) Cheers, Brian From eran@hueniverse.com Wed Jan 26 14:24:37 2011 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 418613A68AA for ; Wed, 26 Jan 2011 14:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 839NGY41ab2C for ; Wed, 26 Jan 2011 14:24:36 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 5A8233A6852 for ; Wed, 26 Jan 2011 14:24:36 -0800 (PST) Received: (qmail 6669 invoked from network); 26 Jan 2011 22:27:37 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 22:27:37 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 26 Jan 2011 15:27:28 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 26 Jan 2011 15:27:10 -0700 Thread-Topic: [OAUTH-WG] Bear token scheme name Thread-Index: Acu9nzxfYueh9BdsRvadDhK2cYTfYgACLvCA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6273F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A6B9D89C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246EF805@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6253E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Bear token scheme name 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, 26 Jan 2011 22:24:37 -0000 MAC is clearly trying to define something generic and includes an OAuth bin= ding. I think the bearer token is the exception of something completely use= less outside of OAuth, but that doesn't mean it uselessness should promote = it to the canonical authentication scheme, all of which was already dealt w= ith when we split it out. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, January 26, 2011 1:23 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Bear token scheme name >=20 > On Tue, Jan 25, 2011 at 9:59 PM, Eran Hammer-Lahav > wrote: > > Simply because authentication is not what OAuth is about. > > > > OAuth is an authorization protocol for issuing access tokens. Access to= kens > can have different properties and therefore need different schemes. I was > the first to suggest a scheme with sub-schemes but that idea was strongly > rejected (over a year ago). Since then I came to the same conclusion that= the > proper way is to define separate authentication schemes. It is also how m= ost > HTTP authentication framework operate. > > > > One benefit to this approach is that HTTP authentication already covers= the > discovery of which schemes are supported by the resource server, as well = as > token schemes can be used independently from OAuth, something the 2- > legged OAuth 1.0 has shown has great value. Also, it keeps the protocol > modular which enable providers to tailor it to their security needs. > > > > OAuth 2.0 is authentication agnostic and must remain so. It is an > authorization protocol and as such has no business defining authenticatio= n > mechanisms. > > > > For this reason, I object to using the OAuth2 scheme name with the bear= er > token scheme. It's a "trademark" issue. >=20 > I can definitely see your point, but look at the end result. OAuth is use= less > with an authentication mechanism so now a bunch of similar authentication > mechanisms are reinvented in related specifications. > All geared to work with OAuth 2, none of them really trying to define > something generic. >=20 >=20 > Marius From eran@hueniverse.com Wed Jan 26 14:27:00 2011 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 A2A6B3A69ED for ; Wed, 26 Jan 2011 14:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 2iWsgUrkAIoL for ; Wed, 26 Jan 2011 14:26:59 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BDE8D3A69EE for ; Wed, 26 Jan 2011 14:26:58 -0800 (PST) Received: (qmail 11342 invoked from network); 26 Jan 2011 22:30:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 22:30:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 26 Jan 2011 15:29:56 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 26 Jan 2011 15:29:39 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu9oIx5P73VJYhFToOghQQlM3/M2AAB9Sjg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62744@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1296051184.9984.5.camel@pulse> <155BD4E7-F8B3-4B4A-B02D-EAE2048A2F51@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8D6262E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 22:27:00 -0000 How about turn the MUST to a SHOULD for using the x_ prefix? EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, January 26, 2011 1:32 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > On Wed, Jan 26, 2011 at 9:48 AM, Eran Hammer-Lahav > wrote: > > This is not aimed at anyone in particular. > > > > Replying +1 is not justification for a major breaking change. This was = raised > in the past and consensus was that this is not a major concern. Over the = past > 10 months not a single actual issue was raised about conflicts in legacy > platforms. If you have an *actual* issue with a platform, please provide = the > full details, including why known mechanisms such as Apache rewrite rules > can't solve the it. >=20 > I just raised an actual issue. >=20 > Because OAuth 2 parameters are not prefixed, starting with v11 the spec > requires all other parameters to use the "x_" prefix. Google cannot compl= y > with that. >=20 > Dropping the x_ requirement is good enough IMO. If you are worried about > that, then you are probably afraid of an actual issue as well. >=20 >=20 > Marius From mscurtescu@google.com Wed Jan 26 14:42:16 2011 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 E35EE3A6890 for ; Wed, 26 Jan 2011 14:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.055 X-Spam-Level: X-Spam-Status: No, score=-104.055 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 qZUxhJeF4bHF for ; Wed, 26 Jan 2011 14:42:16 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id F24103A6851 for ; Wed, 26 Jan 2011 14:42:15 -0800 (PST) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p0QMjFYL014703 for ; Wed, 26 Jan 2011 14:45:15 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296081916; bh=0f6ESQp/RUaLP+xSG56rSYaKwBs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=akM4LrD8x3s6WB8JzQUW5OGhJlOobwmdpImdPW3p4H7/5ianEI0vn7pdDYeCAu9+P iECagCDq14pLe7paEl7qQ== Received: from yxt33 (yxt33.prod.google.com [10.190.5.225]) by wpaz37.hot.corp.google.com with ESMTP id p0QMiw5R003985 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 14:45:14 -0800 Received: by yxt33 with SMTP id 33so376260yxt.31 for ; Wed, 26 Jan 2011 14:45:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=fz5fNTnPUqbz2qxHQCwX8/Ikr4GsppHTaU9ZR9qwJ28=; b=t4LXXscJtHYLxhh9oR+DunCFCS8ojy4rpQlpV/Lj7xNkOuY/7U04o8a5HyrQLA7UYt bbHL6mTFhAixNP+LYMgw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=un50RqROy07am4qo+l1vU8fz2ldyNAVYgBMuRkfyaJK6sGz8B24d/vAPoRN+Z30fSr 5rdjGMlVYm8nDzpAma3Q== Received: by 10.100.164.2 with SMTP id m2mr8415ane.146.1296081913954; Wed, 26 Jan 2011 14:45:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Wed, 26 Jan 2011 14:44:53 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62744@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1296051184.9984.5.camel@pulse> <155BD4E7-F8B3-4B4A-B02D-EAE2048A2F51@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8D6262E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62744@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Wed, 26 Jan 2011 14:44:53 -0800 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 22:42:17 -0000 On Wed, Jan 26, 2011 at 2:29 PM, Eran Hammer-Lahav wrote: > How about turn the MUST to a SHOULD for using the x_ prefix? OK, let's go with that. Thanks, Marius From eran@hueniverse.com Wed Jan 26 14:48:47 2011 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 410D53A69EB for ; Wed, 26 Jan 2011 14:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.039, 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 ErWs3LOpCD0b for ; Wed, 26 Jan 2011 14:48:44 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 9073D3A69DD for ; Wed, 26 Jan 2011 14:48:44 -0800 (PST) Received: (qmail 30745 invoked from network); 26 Jan 2011 22:51:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 22:51:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 26 Jan 2011 15:51:43 -0700 From: Eran Hammer-Lahav To: Anthony Nadalin Date: Wed, 26 Jan 2011 15:51:24 -0700 Thread-Topic: Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQIaL9MwAAPpZeAAKfLFMAACwaqw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62753@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6250D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033B0798@TK5EX14MBXC111.redmond.corp.microsoft.com> In-Reply-To: <180155C5EA10854997314CA5E063D18F033B0798@TK5EX14MBXC111.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62753P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 26 Jan 2011 22:48:47 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62753P3PW5EX1MB01E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIHlvdSBleHBsYWluIGhvdyBoYXZpbmcgdG8gZGVmaW5lICp0d28qIGV4dGVuc2lvbiBwYXJh bWV0ZXJzIG1ha2VzIHRoZSBzcGVjaWZpY2F0aW9uIHVzZWxlc3M/IFRoZSBiZWFyZXIgdG9rZW4g c3BlY2lmaWNhdGlvbiBpcyBnb2luZyB0byBkZWZpbmUgaXRzIGNvcnJlc3BvbmRpbmcgV1dXLUF1 dGhlbnRpY2F0ZSBoZWFkZXIsIHRvIG1hdGNoIGl0cyBhbHJlYWR5IGRlZmluZWQgQXV0aG9yaXph dGlvbiBoZWFkZXIuIFRoZSBzY2hlbWUgbmFtZSBpcyBqdXN0IHN0eWxlIGFuZCBicmFuZGluZyBh bmQgaGF2ZSBhYnNvbHV0ZWx5IG5vIHRlY2huaWNhbCBpbXBhY3QuIEkgYW0gaG9uZXN0bHkgY29u ZnVzZWQgYnkgeW91ciBjb21tZW50cywgYXMgSSB3YXMgaW4gdGhlIHBhc3Qgd2hlbiB5b3UgZGVj bGFyZWQgdGhlIGVudGlyZSBwcm90b2NvbCB1c2VsZXNzIGJlY2F1c2Ugb2YgbXkgb2JqZWN0aW9u cyB0byBhbiB1bmRlci1kZWZpbmVkIHNjb3BlIHBhcmFtZXRlci4NCg0KQ2FuIHlvdSBwb2ludCBt ZSB3aGVyZSBpbiBXUkFQIGFyZSB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBkZWZp bmVkPyBJIGNhbiBvbmx5IGZpbmQgdGhlIGFzc2VydGlvbiBwcm9maWxlIHdoaWNoIGlzIGNvbXBh cmFibGUgdG8gdGhlIGV4dGVuc2lvbiBncmFudCB0eXBlIHdpdGggdGhlIFNBTUwgYXNzZXJ0aW9u IGV4dGVuc2lvbiAod2hlcmUgdGhlIGFzc2VydGlvbiBwYXJhbWV0ZXIgaXMgZGVmaW5lZCBhbmQg cmVnaXN0ZXJlZCkuIFRoZSBjb25jZXB0IG9mIHRoZSBjbGllbnQgYXNzZXJ0aW9uIHVzZWQgZm9y IGNsaWVudCBhdXRoZW50aWNhdGlvbiAoc2VwYXJhdGUgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBn cmFudCkgaXMgbmV3IGFuZCB3YXMgYWRkZWQgYmFzZWQgb24gYSBwcm9wb3NhbCBmcm9tIFlhcm9u IGluIC0xMSBvbiBEZWNlbWJlciAxc3QsIDIwMTAuDQoNCkFzIGZvciB5b3VyIGFkZGl0aW9uYWwg ZGV0YWlscyBiZWxvdyAodGhhbmtzISksIGl0IHNlZW1zIGxpa2UgeW91IGFyZSBub3QgdXNpbmcg dGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYXQgYWxsIGJ1dCB1c2luZyBhIHNpbXBs ZSBleHRlbnNpb24gZ3JhbnQgd2l0aCBhbiBhc3NlcnRpb24sIGV4YWN0bHkgbGlrZSB0aGUgU0FN TCBleHRlbnNpb24gZ3JhbnQgc3BlY2lmaWNhdGlvbiwgb25seSB5b3UgYXJlIG5vdCBsaW1pdGVk IHRvIFNBTUwgMi4wLiBJcyB0aGF0IGNvcnJlY3Q/IElmIHRoaXMgaXMgY29ycmVjdCwgdGhlbiB0 aGUgb25seSBpc3N1ZSBoZXJlIGlzIG91ciBkZWNpc2lvbiAod2hpY2ggd2FzIG1hZGUgd2l0aG91 dCBhbnkgY29tbWVudCBmcm9tIHlvdSBvciB0aG9zZSBub3cgcmFpc2luZyBpc3N1ZXMgYWJvdXQg dGhpcykgdG8gbW92ZSB0aGUg4oCYYXNzZXJ0aW9u4oCZIHBhcmFtZXRlciBhbmQgcmVuYW1lIHRo ZSBncmFudCB0eXBlIGZyb20gYXNzZXJ0aW9uIHRvIGV4dGVuc2lvbiAod2hpY2ggaGFzIG5vIGlt cGxlbWVudGF0aW9uIGltcGFjdCkuIEFsbCB3ZSBkaWQgaXMgcmVsb2NhdGUgdGhlIGFzc2VydGlv biBwYXJhbWV0ZXIgYmVjYXVzZSBpdCBkb2VzbuKAmXQgYWx3YXlzIGFwcGx5IHRvIGV4dGVuc2lv biBncmFudHMuDQoNCklzIHRoaXMganVzdCBhIGNvbmZ1c2lvbiBhYm91dCB3aGF0IHdhcyBiZWlu ZyByZW1vdmVkIGFuZCB3aGVyZSBpdCB3ZW50Pw0KDQpFSEwNCg0KDQpGcm9tOiBBbnRob255IE5h ZGFsaW4gW21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEph bnVhcnkgMjYsIDIwMTEgMTo1MiBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2DQpDYzogT0F1dGgg V0cNClN1YmplY3Q6IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoN Ck1heWJlIHRoaXMgd2FzIHRoZSBwbGFuIGFsbCBhbG9uZyBidXQgc3BlY2lmaWNhdGlvbiBpcyBi ZWNvbWluZyB1c2VsZXNzIGZvciBvdXIgc2NlbmFyaW9zIGFuZCB3aWxsIHJlcXVpcmUgdGhhdCB3 ZSBoYXZlIHRvIGdvIHdlbGwgYmV5b25kIHRoZSBjb3JlIHNwZWNpZmljYXRpb24gdG8gbWFrZSB0 aGluZ3Mgd29yaywgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYmVpbmcgYSBwcmlt ZSBleGFtcGxlLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBoYXMgYmVlbiBhcm91 bmQgZm9yIGEgd2hpbGUgYXMgaXQgd2FzIGEgcmVxdWlyZW1lbnQgZm9yIFdSQVAsIHRoZW4gZHJv cHBlZCB3aGVuIHRoZSB2YXJpb3VzIHNwZWNzIGdvdCBtZXJnZWQgdG8gZm9ybSBPQVVUSCAyLjAg YW5kIHRoZW4gY2FtZSBiYWNrIGludG8gdGhlIE9BVVRIIDIuMCBhbmQgdGhlbiBoYXMgZ29uZSB0 aHJvdWdoIHZhcmlvdXMgY2hhbmdlcyBzaW5jZSB2ZXJzaW9uIDYgZm9yIHRoZSB3b3JzZS4gVGhl cmUgaGFzIGJlZW4gbXVjaCBkaXNjdXNzaW9uIGluIEp1bHkvQXVndXN0IG92ZXIgdGhpcyBhbmQg bmV3IHRleHQgd2FzIHByb3Bvc2VkLCBidXQgdGhhdCBzZWVtcyB0byBub3QgYmUgZnVsbHkgYWNj ZXB0ZWQsIGJ1dCBJIHRoaW5rIHRoYXQgZm9sbG93cyB0aGUgcGF0aCB3aGVuIHlvdSB3YW50IHRv IHJlbW92ZSBzb21ldGhpbmcuDQoNCk91ciB1c2FnZSB3aWxsIGJlIHZpYSBiZWFyZXIgdG9rZW4g YXNzZXJ0aW9ucyBvbmx5IChhdCB0aGlzIHRpbWUpDQpUaGUgZ3JhbnRfdHlwZSB3b3VsZCBiZSB0 aGUgVVJJIG9mIHRoZSBhc3NlcnRpb24gdHlwZSBiZWluZyB1c2VkDQpUaGUgYXV0aG9yaXphdGlv biBlbmRwb2ludCBjYW4gdXNlIHdoYXQgaXQgd2FudHMgdG8gYmluZCB0aGUgYXNzZXJ0aW9uIHRv IHRoZSBjbGllbnRfaWQsIG11Y2ggbGlrZSBpdCBoYXMgdG8gdG9kYXkgZm9yIHRoZSBwYXNzd29y ZCBhdXRoZW50aWNhdGlvbiwgYXMgd2UgaGF2ZSBzY2VuYXJpb3Mgd2VyZSBjbGllbnRfaWQgaGF2 ZSBtdWx0aXBsZSBwYXNzd29yZHMNCldlIHVzZSBndWlkYW5jZSBmcm9tIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb24gc2VjdGlvbiBvZiB0aGUgYXNzZXJ0aW9uIHR5cGUgYmVpbmcgdXNlZCBhbG9uZyB3 aXRoIHRoZSBndWlkYW5jZSBmcm9tIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlvbg0KSWYg bmVlZGVkIEkgY2FuIGNhcHR1cmUgdGhlIGFzc2VydGlvbnMgYW5kIHJlcXVlc3RzLCBidXQgbm90 IHN1cmUgd2hhdCB0aGUgcG9pbnQgb2YgdGhpcyBpcyBhdCB0aGlzIHRpbWUgc2luY2UgdGhpcyBp cyBub3QgcmVxdWlyZWQgZm9yIHRoZSBwYXNzd29yZCBjcmVkZW50aWFscw0KDQpTdXJlIHdlIGNh biBhZGQgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gdG8gdGhlIGJlYXJlciB0 b2tlbiBzcGVjaWZpY2F0aW9uIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB0aGUgcHJvcGVy IHBsYWNlIHRvIGRvIHRodXMgYnV0IHNpbmNlIGl04oCZcyBnb25lIGZyb20gdGhlIGNvcmUgd2Ug d2lsbCBoYXZlIHRvIGRvIGp1c3QgdGhhdC4gVGhlIHNhbWUgc2VlbXMgdG8gaGFwcGVuIHdpdGgg dGhlIEhUVFAgQXV0aGVudGljYXRpb24gU2NoZW1lIGFzIGl0IHNlZW1zIHRvIGJlIHJlcGVhdGVk IGluIGZvbGxvdy1vbiBjb21wYW5pb24gc3BlY2lmaWNhdGlvbnMuIFdoaWxlIG9hdXRoLXYyIGlz IG5vdCBhbiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IGZv ciBhdXRoZW50aWNhdGlvbiB0byBhZGRyZXNzIHNlY3VyaXR5IGNvbmNlcm5zLiBUaGVyZSBpcyBj bGVhciBzZXBhcmF0aW9uIGJldHdlZW4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb247 IHdlIGFyZSBub3Qgc3VnZ2VzdGluZyB0aGF0IGF1dGhlbnRpY2F0aW9uIGlzIGFwcHJvcHJpYXRl IGZhY2lsaXR5IHRvIG5lZ290aWF0ZSBhdXRob3JpemF0aW9uLiBJIHRoaW5rIHRoYXQgaXQgbWFr ZXMgc2Vuc2UgdG8gaW5jbHVkZSBhIHNjaGVtZSBpbiB0aGUgY29yZSBhbmQgaGF2ZSB0aGUgcGFy dGljdWxhciBmb2xsb3ctb24gY29tcGFuaW9uIHNwZWNpZmljYXRpb25zICh0aGUgdmFyaW91cyB0 b2tlbiBzcGVjaWZpY2F0aW9ucykgc3RhdGUvZGVmaW5lIHRoZSBwYXJhbWV0ZXJzIGFuZCBpZiB0 aGV5IGRvbuKAmXQgbGlrZSB0aGUgZGVmYXVsdCBzY2hlbWUgbGV0IHRoZW0gZGVmaW5lIGEgbmV3 IHNjaGVtZSBidXQgdGhpcyBwdXRzIGEgc3Rha2UgaW4gdGhlIGdyb3VuZCBmb3IgYW4gSFRUUCBB dXRoZW50aWNhdGlvbiBTY2hlbWUuDQoNCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgW21haWx0 bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNSwgMjAxMSA1 OjM4IFBNDQpUbzogQW50aG9ueSBOYWRhbGluDQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJFOiBS ZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoNCkNhbiB5b3Ugc2hhcmUgd2l0 aCB0aGUgbGlzdCBob3cgeW91IHBsYW4gdG8gdXNlIHRoaXMgY2xpZW50IGFzc2VydGlvbiBhdXRo ZW50aWNhdGlvbiBzY2hlbWU/DQpXaGljaCBvZiB0aGUgYXV0aG9yaXphdGlvbiBncmFudCB0eXBl cyB5b3Ugd2lsbCB1c2UgaXQgd2l0aD8NCldpbGwgeW91IHVzZSBpdCB3aXRoIHRoZSBhdXRob3Jp emF0aW9uIGVuZHBvaW50LCBhbmQgaWYgc28sIGhvdyB3aWxsIHlvdSBiaW5kIHRoZSBhc3NlcnRp b24gdG8gdGhlIGNsaWVudF9pZD8NCkNhbiB5b3UgcHJvdmlkZSBmdWxsIGV4YW1wbGVzIG9mIGFz c2VydGlvbnMgYW5kIEhUVFAgcmVxdWVzdHM/DQoNCkl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gc2Vl IGhvdyBmYXIgYXBhcnQgdGhlIHByb3Bvc2VkIHRleHQgYmVsb3cgaXMgZnJvbSBhbiBhY3R1YWwg aW1wbGVtZW50YXRpb24gbWFraW5nIHVzZSBvZiBpdC4gSSBleGNlcHQgdG8gc2VlIHRoZXNlIGFu c3dlcnMgaW4gYW55IHF1YWxpdHkgZG9jdW1lbnQgZGVmaW5pbmcgYSBuZXcgY2xpZW50IGF1dGhl bnRpY2F0aW9uIHNjaGVtZSAod2hpY2ggaXMgdHJ1ZSBmb3IgdGhlIGNsaWVudCBwYXNzd29yZCBh dXRoZW50aWNhdGlvbiB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCkuDQoNCkVITA0KDQoNCkZyb206 IEFudGhvbnkgTmFkYWxpbiBbbWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV08bWFpbHRvOltt YWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXT4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjUs IDIwMTEgMzo1OCBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRzsgSGFubmVzLlRz Y2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldD47IEJsYWlu ZSBDb29rDQpTdWJqZWN0OiBSRTogUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFs cw0KDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGZvciByZW1vdmluZyB0aGUg Y2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscywgYXMgY2xpZW50IHBhc3N3b3JkIGF1dGhlbnRp Y2F0aW9uIGlzIGxlZnQgaW4uIENsaWVudCBQYXNzd29yZCBBdXRoZW50aWNhdGlvbiBpcyBhbHNv IHVuZGVyc3BlY2lmaWVkIGFzIGNsaWVudF9zZWNyZXQgY291bGQgYmUgYW55dGhpbmcgdGhhdCB0 aGUgYXV0aGVudGljYXRpb24gc2VydmVyIHNlZW1zIGZpdCAocmF3IGNsZWFyIHRleHQgcGFzc3dv cmQsICBoYXNoLCBkaWdlc3QsIGV0Yy4pIGFuZCBubyB3YXkgdG8gZGV0ZXJtaW5lIHRoZSBjb250 ZW50LiBjbGllbnRfc2VjcmV0IGlzIGFsc28gYSB2ZXJ5IHdlYWsgbWVjaGFuaXNtLCBzaW5jZSB0 aGlzIGlzIGxlZnQgaW4gdGhlIGNvcmUgdGhpcyBsZWFkcyBtZSB0byBiZWxpZXZlIHRoYXQgdGhl cmUgaXMgc3VwcG9ydCBmb3IgaGF2aW5nIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiBPYXV0aC4g SSBkb24ndCBzZWUgaG93IGhhdmluZyBjbGllbnRfYXNzZXJ0aW9uIGFuZCBjbGllbnRfYXNzZXJ0 aW9uX3R5cGUgd291bGQgYmUgc29tZXRoaW5nIHRoYXQgaXMgdW5kZXJzcGVjaWZpZWQgYXMgYmVp bmcgYSBtZWNoYW5pc20gaW4gd2hpY2ggYXNzZXJ0aW9ucyBjYW4gYmUgdXNlZCBmb3IgYXV0aGVu dGljYXRpb24uIEFncmVlIHRoYXQgdGhlIGF1dGhlbnRpY2F0aW9uIHNlcnZlciBoYXMgdG8gbWFr ZSByaWdodCBhbmQgZGVjbGFyZSB3aGF0IGlzIGJlaW5nIHVzZWQgYnV0IHRoYXQgaXMgdGhlIHNh bWUgZm9yIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbi4gVGhlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBhc3NlcnRpb25zIGFyZSBzb21ldGhpbmcgdGhhdCBNaWNyb3NvZnQgYW5kIEdvb2ds ZSBmaW5kIHVzZWZ1bCBhbmQgcGxhbiBvbiBpbXBsZW1lbnRpbmcgYW5kIHVzaW5nIGFzIGEgbWVh bnMgZm9yIHN0cm9uZ2VyIGF1dGhlbnRpY2F0aW9uIHRvIHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ci4gVGhpcyBleHRlbnNpYmlsaXR5IGJlbG9uZ3MgaW4gdGhlIGNvcmUsIHRoZXJlIGlzIG5vIG90 aGVyIHBsYWNlIHRvIHB1dCB0aGlzIGZ1bmN0aW9uYWxpdHkuIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0 IHRoZSByZW1vdmFsIChlaXRoZXIgYnkgZWRpdG9yIG9yIGRpcmVjdGlvbiBieSBjby1jaGFpcikg aXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiBkb25lIHcvbyBhIGNvbnNlbnN1cyB2 b3RlIHNpbmNlIHRoaXMgaGFzIGJlZW4gaW4gdGhlIHNwZWNpZmljYXRpb24gZm9yIHNvbWUgdGlt ZSB3aXRob3V0IGlzc3VlIGFuZCB0aGUgcmVtb3ZhbCBjb21lcyBhcyBjb21wbGV0ZSB1bndlbGNv bWUgc3VycHJpc2UuIEdldHRpbmcgYWxtb3N0IHRvdGFsIHJld3JpdGVzIG9mIHRoZSBzcGVjaWZp Y2F0aW9uIHRoaXMgbGF0ZSBpbiB0aGUgcmV2aWV3IGN5Y2xlIGlzIGFsc28gdmVyeSBkaXN0dXJi aW5nLg0KDQoNCg0KQSBwcm9wb3NhbCBmb3Iga2VlcGluZyB0aGUgY2xpZW50IGF1dGhlbnRpY2F0 aW9uIGFzc2VydGlvbiB3b3VsZCBiZSB0byBzaW1wbGlmeSB0byB0aGUgZm9sbG93aW5nOw0KDQpU aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhcmUgdXNlZCBpbiBjYXNlcyB3aGVyZSBh IHBhc3N3b3JkIChjbGVhci10ZXh0IHNoYXJlZCBzeW1tZXRyaWMgc2VjcmV0KSBpcyB1bnN1aXRh YmxlIG9yIGRvZXMgbm90IHByb3ZpZGUgc3VmZmljaWVudCBzZWN1cml0eSBmb3IgY2xpZW50IGF1 dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBwcm92aWRlIGFu IGV4dGVuc2libGUgbWVjaGFuaXNtIHRvIHVzZSBhbiBhc3NlcnRpb24gZm9ybWF0IHN1cHBvcnRl ZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSBj bGllbnQuDQoNClVzaW5nIGFzc2VydGlvbnMgcmVxdWlyZXMgdGhlIGNsaWVudCB0byBvYnRhaW4g YW4gYXNzZXJ0aW9uIChzdWNoIGFzIGEgU0FNTCAoQ2FudG9yLCBTLiwgS2VtcCwgSi4sIFBoaWxw b3R0LCBSLiwgYW5kIEUuIE1hbGVyLCDigJxBc3NlcnRpb25zIGFuZCBQcm90b2NvbCBmb3IgdGhl IE9BU0lTIFNlY3VyaXR5IEFzc2VydGlvbiBNYXJrdXAgTGFuZ3VhZ2UgKFNBTUwpIFYyLjAs4oCd IE1hcmNoIDIwMDUuKSBbT0FTSVMuc2FtbOKAkWNvcmXigJEyLjDigJFvc10gYXNzZXJ0aW9uKSBm cm9tIGFuIGFzc2VydGlvbiBpc3N1ZXIgb3IgdG8gc2VsZi1pc3N1ZSBhbiBhc3NlcnRpb24uIFRo ZSBhc3NlcnRpb24gZm9ybWF0LCB0aGUgcHJvY2VzcyBieSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlz IG9idGFpbmVkLCBhbmQgdGhlIG1ldGhvZCBvZiB2YWxpZGF0aW5nIHRoZSBhc3NlcnRpb24gYXJl IGRlZmluZWQgYnkgdGhlIGFzc2VydGlvbiBpc3N1ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciwgYW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0K V2hlbiB1c2luZyBhIGNsaWVudCBhc3NlcnRpb24sIHRoZSBjbGllbnQgaW5jbHVkZXMgdGhlIGZv bGxvd2luZyBwYXJhbWV0ZXJzOg0KY2xpZW50X2Fzc2VydGlvbl90eXBlIC0gUkVRVUlSRUQuIFRo ZSBmb3JtYXQgb2YgdGhlIGFzc2VydGlvbiBhcyBkZWZpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci4gVGhlIHZhbHVlIE1VU1QgYmUgYW4gYWJzb2x1dGUgVVJJLg0KY2xpZW50X2Fzc2Vy dGlvbiAtIFJFUVVJUkVELiBUaGUgY2xpZW50IGFzc2VydGlvbi4NCg0KRm9yIGV4YW1wbGUsIHRo ZSBjbGllbnQgc2VuZHMgdGhlIGZvbGxvd2luZyBhY2Nlc3MgdG9rZW4gcmVxdWVzdCB1c2luZyBh IFNBTUwgMi4wIGFzc2VydGlvbiB0byBhdXRoZW50aWNhdGUgaXRzZWxmIChsaW5lIGJyZWFrcyBh cmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6DQoNCg0KDQoNCg0KICBQT1NUIC90b2tlbiBI VFRQLzEuMQ0KDQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQ0KDQogIENvbnRlbnQtVHlwZTog YXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkDQoNCg0KDQogIGdyYW50X3R5cGU9YXV0 aG9yaXphdGlvbl9jb2RlJmNvZGU9aTFXc1JuMXVCMSYNCg0KICBjbGllbnRfYXNzZXJ0aW9uPVBI TmhiV3h3T2xbLi4ub21pdHRlZCBmb3IgYnJldml0eS4uLl1aVDQlM0QmDQoNCiAgY2xpZW50X2Fz c2VydGlvbl90eXBlPSAgdXJuJTNBb2FzaXMlM0FuYW1lcyVzQXRjJTNBU0FNTCUzQTIuMCUzQWFz c2VydGlvbiZyZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZjbGllbnQlMkVleGFtcGxlJTJFY29t JTJGY2INCg0KDQoNCg0KDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9h dXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ108bWFp bHRvOlttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBFcmFuIEhh bW1lci1MYWhhdg0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDE0LCAyMDExIDEwOjQ1IFBNDQpUbzog T0F1dGggV0cNClN1YmplY3Q6IFtPQVVUSC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBD cmVkZW50aWFscw0KDQpJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB3ZSBkcm9wIHRoZSBjbGllbnQg YXNzZXJ0aW9uIGNyZWRlbnRpYWxzICgtMTEgc2VjdGlvbiAzLjIpIGZyb20gdGhlIHNwZWNpZmlj YXRpb24sIGFuZCBpZiBuZWVkZWQsIHB1Ymxpc2ggaXQgYXMgYSBzZXBhcmF0ZSBzcGVjaWZpY2F0 aW9uIGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6DQoNCg0KMS4gICAgICAgVGhlIG1lY2hhbmlz bSBpcyB1bmRlciBzcGVjaWZpZWQsIGVzcGVjaWFsbHkgaW4gaXRzIGhhbmRsaW5nIG9mIHRoZSBj bGllbnRfaWQgaWRlbnRpZmllciAod2hlbiB1c2VkIHRvIG9idGFpbiBlbmQtdXNlciBhdXRob3Jp emF0aW9uKS4gSXQgZG9lcyBub3QgY29udGFpbiBhbnkgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0 byBhY2NvbXBsaXNoIGFueSBsZXZlbCBvZiBpbnRlcm9wZXJhYmlsaXR5IG9yIGZ1bmN0aW9uYWxp dHkuIFRoaXMgaXMgaW4gY29udHJhc3QgdG8gdGhlIGFzc2VydGlvbiBncmFudCB0eXBlIHdoaWNo IGhhcyBtYXR1cmVkIG92ZXIgYSB5ZWFyIGludG8gYSBmdWxseSB0aG91Z2h0LW91dCBleHRlbnNp b24gbWVjaGFuaXNtLCBhcyB3ZWxsIGFzIGEgc2VwYXJhdGUgU0FNTCBhc3NlcnRpb24gc3BlY2lm aWNhdGlvbiB3aXRoIGFjdGl2ZSBkZXBsb3ltZW50ICh0aGUgdHdvLCB0b2dldGhlciB3aXRoIHJ1 bm5pbmcgY29kZSwgc2hvdyBjbGVhciBjb25zZW5zdXMpLg0KDQoyLiAgICAgICBUaGUgc2VjdGlv biBpcyBhIGNvbmZ1c2VkIG1peCBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzcHJpbmtsZWQg d2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UuIEluc3RlYWQsIGl0IHNob3VsZCBiZSByZXBsYWNlZCB3 aXRoIGd1aWRlbGluZXMgZm9yIGV4dGVuZGluZyB0aGUgc2V0IG9mIHN1cHBvcnRlZCBjbGllbnQg Y3JlZGVudGlhbHMsIGJ1dCB3aXRob3V0IGRlZmluaW5nIGEgbmV3IHJlZ2lzdHJ5LiBJdCBpcyBj bGVhcmx5IGFuIGFyZWEgb2YgbGl0dGxlIGRlcGxveW1lbnQgZXhwZXJpZW5jZSBmb3IgT0F1dGgs IGFuZCB0aGF0IGluY2x1ZGVzIHVzaW5nIEhUVFAgQmFzaWMgYXV0aGVudGljYXRpb24gZm9yIGNs aWVudCBhdXRoZW50aWNhdGlvbiAobW9yZSBvbiB0aGF0IHRvIGNvbWUpLg0KDQozLiAgICAgICBU aGUgc2VjdGlvbiBoYXMgcmVjZWl2ZWQgYSBsaXR0bGUgc3VwcG9ydCBhbmQgYSBsaXR0bGUgb2Jq ZWN0aW9uLiBUaG9zZSB3aG8gc3RpbGwgd2FudCB0byBhZHZvY2F0ZSBmb3IgaXQgbmVlZCB0byBz aG93IG5vdCBvbmx5IGNvbnNlbnN1cyBmb3Iga2VlcGluZyBpdCwgYnV0IGFsc28gYWN0aXZlIGNv bW11bml0eSBzdXBwb3J0IGZvciBkZXBsb3lpbmcgaXQuIERlcGxveW1lbnQsIG9mIGNvdXJzZSwg d2lsbCBhbHNvIHJlcXVpcmUgc2hvd2luZyBwcm9ncmVzcyBvbiBwdWJsaWMgc3BlY2lmaWNhdGlv bnMgcHJvZmlsaW5nIHRoZSBtZWNoYW5pc20gaW50byBhIHVzZWZ1bCBpbnRlcm9wZXJhYmxlIGZl YXR1cmUuDQoNCkNvbW1lbnRzPyBDb3VudGVyLWFyZ3VtZW50cz8NCg0KRUhMDQoNCg0K --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62753P3PW5EX1MB01E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0K LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5N c29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGlu aywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlw ZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFp blRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MjQuMHB0Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjI0LjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJYmFja2dyb3VuZDojQ0NDQ0NDOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpi bGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt YXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCgliYWNrZ3JvdW5kOiNDQ0NDQ0M7fQ0Kc3Bhbi5QbGFpblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5 bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTEzNzg2NTAwOw0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzIxODY5ODg4IDY3Njk4NzAzIDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJ dGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxp bms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Q2FuIHlvdSBleHBsYWluIGhvdyBoYXZpbmcgdG8gZGVm aW5lICo8Yj50d288L2I+KiBleHRlbnNpb24gcGFyYW1ldGVycyBtYWtlcyB0aGUgc3BlY2lmaWNh dGlvbiB1c2VsZXNzPyBUaGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24gaXMgZ29pbmcgdG8g ZGVmaW5lIGl0cyBjb3JyZXNwb25kaW5nIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyLCB0byBtYXRj aCBpdHMgYWxyZWFkeSBkZWZpbmVkIEF1dGhvcml6YXRpb24gaGVhZGVyLiBUaGUgc2NoZW1lIG5h bWUgaXMganVzdCBzdHlsZSBhbmQgYnJhbmRpbmcgYW5kIGhhdmUgYWJzb2x1dGVseSBubyB0ZWNo bmljYWwgaW1wYWN0LiBJIGFtIGhvbmVzdGx5IGNvbmZ1c2VkIGJ5IHlvdXIgY29tbWVudHMsIGFz IEkgd2FzIGluIHRoZSBwYXN0IHdoZW4geW91IGRlY2xhcmVkIHRoZSBlbnRpcmUgcHJvdG9jb2wg dXNlbGVzcyBiZWNhdXNlIG9mIG15IG9iamVjdGlvbnMgdG8gYW4gdW5kZXItZGVmaW5lZCBzY29w ZSBwYXJhbWV0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+Q2FuIHlvdSBwb2ludCBt ZSB3aGVyZSBpbiBXUkFQIGFyZSB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBkZWZp bmVkPyBJIGNhbiBvbmx5IGZpbmQgdGhlIGFzc2VydGlvbiBwcm9maWxlIHdoaWNoIGlzIGNvbXBh cmFibGUgdG8gdGhlIGV4dGVuc2lvbiBncmFudCB0eXBlIHdpdGggdGhlIFNBTUwgYXNzZXJ0aW9u IGV4dGVuc2lvbiAod2hlcmUgdGhlIGFzc2VydGlvbiBwYXJhbWV0ZXIgaXMgZGVmaW5lZCBhbmQg cmVnaXN0ZXJlZCkuIFRoZSBjb25jZXB0IG9mIHRoZSBjbGllbnQgYXNzZXJ0aW9uIHVzZWQgZm9y IGNsaWVudCBhdXRoZW50aWNhdGlvbiAoc2VwYXJhdGUgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBn cmFudCkgaXMgbmV3IGFuZCB3YXMgYWRkZWQgYmFzZWQgb24gYSBwcm9wb3NhbCBmcm9tIFlhcm9u IGluIC0xMSBvbiBEZWNlbWJlciAxPHN1cD5zdDwvc3VwPiwgMjAxMC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj b2xvcjojMUY0OTdEJz5BcyBmb3IgeW91ciBhZGRpdGlvbmFsIGRldGFpbHMgYmVsb3cgKHRoYW5r cyEpLCBpdCBzZWVtcyBsaWtlIHlvdSBhcmUgbm90IHVzaW5nIHRoZSBjbGllbnQgYXNzZXJ0aW9u IGNyZWRlbnRpYWxzIGF0IGFsbCBidXQgdXNpbmcgYSBzaW1wbGUgZXh0ZW5zaW9uIGdyYW50IHdp dGggYW4gYXNzZXJ0aW9uLCBleGFjdGx5IGxpa2UgdGhlIFNBTUwgZXh0ZW5zaW9uIGdyYW50IHNw ZWNpZmljYXRpb24sIG9ubHkgeW91IGFyZSBub3QgbGltaXRlZCB0byBTQU1MIDIuMC4gSXMgdGhh dCBjb3JyZWN0PyBJZiB0aGlzIGlzIGNvcnJlY3QsIHRoZW4gdGhlIG9ubHkgaXNzdWUgaGVyZSBp cyBvdXIgZGVjaXNpb24gKHdoaWNoIHdhcyBtYWRlIHdpdGhvdXQgYW55IGNvbW1lbnQgZnJvbSB5 b3Ugb3IgdGhvc2Ugbm93IHJhaXNpbmcgaXNzdWVzIGFib3V0IHRoaXMpIHRvIG1vdmUgdGhlIOKA mGFzc2VydGlvbuKAmSBwYXJhbWV0ZXIgYW5kIHJlbmFtZSB0aGUgZ3JhbnQgdHlwZSBmcm9tIGFz c2VydGlvbiB0byBleHRlbnNpb24gKHdoaWNoIGhhcyBubyBpbXBsZW1lbnRhdGlvbiBpbXBhY3Qp LiBBbGwgd2UgZGlkIGlzIHJlbG9jYXRlIHRoZSBhc3NlcnRpb24gcGFyYW1ldGVyIGJlY2F1c2Ug aXQgZG9lc27igJl0IGFsd2F5cyBhcHBseSB0byBleHRlbnNpb24gZ3JhbnRzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPklzIHRoaXMganVzdCBhIGNvbmZ1c2lvbiBhYm91dCB3aGF0IHdh cyBiZWluZyByZW1vdmVkIGFuZCB3aGVyZSBpdCB3ZW50PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMx RjQ5N0QnPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiInPiBBbnRob255IE5hZGFsaW4gW21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dIDxicj48 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDI2LCAyMDExIDE6NTIgUE08YnI+PGI+VG86 PC9iPiBFcmFuIEhhbW1lci1MYWhhdjxicj48Yj5DYzo8L2I+IE9BdXRoIFdHPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSRTogUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFsczxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5N YXliZSB0aGlzIHdhcyB0aGUgcGxhbiBhbGwgYWxvbmcgYnV0IHNwZWNpZmljYXRpb24gaXMgYmVj b21pbmcgdXNlbGVzcyBmb3Igb3VyIHNjZW5hcmlvcyBhbmQgd2lsbCByZXF1aXJlIHRoYXQgd2Ug aGF2ZSB0byBnbyB3ZWxsIGJleW9uZCB0aGUgY29yZSBzcGVjaWZpY2F0aW9uIHRvIG1ha2UgdGhp bmdzIHdvcmssIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGJlaW5nIGEgcHJpbWUg ZXhhbXBsZS4gVGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgaGFzIGJlZW4gYXJvdW5k IGZvciBhIHdoaWxlIGFzIGl0IHdhcyBhIHJlcXVpcmVtZW50IGZvciBXUkFQLCB0aGVuIGRyb3Bw ZWQgd2hlbiB0aGUgdmFyaW91cyBzcGVjcyBnb3QgbWVyZ2VkIHRvIGZvcm0gT0FVVEggMi4wIGFu ZCB0aGVuIGNhbWUgYmFjayBpbnRvIHRoZSBPQVVUSCAyLjAgYW5kIHRoZW4gaGFzIGdvbmUgdGhy b3VnaCB2YXJpb3VzIGNoYW5nZXMgc2luY2UgdmVyc2lvbiA2IGZvciB0aGUgd29yc2UuIFRoZXJl IGhhcyBiZWVuIG11Y2ggZGlzY3Vzc2lvbiBpbiBKdWx5L0F1Z3VzdCBvdmVyIHRoaXMgYW5kIG5l dyB0ZXh0IHdhcyBwcm9wb3NlZCwgYnV0IHRoYXQgc2VlbXMgdG8gbm90IGJlIGZ1bGx5IGFjY2Vw dGVkLCBidXQgSSB0aGluayB0aGF0IGZvbGxvd3MgdGhlIHBhdGggd2hlbiB5b3Ugd2FudCB0byBy ZW1vdmUgc29tZXRoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPk91ciB1c2FnZSB3 aWxsIGJlIHZpYSBiZWFyZXIgdG9rZW4gYXNzZXJ0aW9ucyBvbmx5IChhdCB0aGlzIHRpbWUpPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+VGhlIGdyYW50X3R5cGUgd291bGQgYmUgdGhlIFVSSSBvZiB0aGUgYXNzZXJ0aW9u IHR5cGUgYmVpbmcgdXNlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPlRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGNh biB1c2Ugd2hhdCBpdCB3YW50cyB0byBiaW5kIHRoZSBhc3NlcnRpb24gdG8gdGhlIGNsaWVudF9p ZCwgbXVjaCBsaWtlIGl0IGhhcyB0byB0b2RheSBmb3IgdGhlIHBhc3N3b3JkIGF1dGhlbnRpY2F0 aW9uLCBhcyB3ZSBoYXZlIHNjZW5hcmlvcyB3ZXJlIGNsaWVudF9pZCBoYXZlIG11bHRpcGxlIHBh c3N3b3JkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2NvbG9yOiMxRjQ5N0QnPldlIHVzZSBndWlkYW5jZSBmcm9tIHNlY3VyaXR5IGNvbnNpZGVy YXRpb24gc2VjdGlvbiBvZiB0aGUgYXNzZXJ0aW9uIHR5cGUgYmVpbmcgdXNlZCBhbG9uZyB3aXRo IHRoZSBndWlkYW5jZSBmcm9tIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5 N0QnPklmIG5lZWRlZCBJIGNhbiBjYXB0dXJlIHRoZSBhc3NlcnRpb25zIGFuZCByZXF1ZXN0cywg YnV0IG5vdCBzdXJlIHdoYXQgdGhlIHBvaW50IG9mIHRoaXMgaXMgYXQgdGhpcyB0aW1lIHNpbmNl IHRoaXMgaXMgbm90IHJlcXVpcmVkIGZvciB0aGUgcGFzc3dvcmQgY3JlZGVudGlhbHM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdjb2xvcjojMUY0OTdEJz5TdXJlIHdlIGNhbiBhZGQgdGhlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBhc3NlcnRpb24gdG8gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uIGJ1dCBJ IGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB0aGUgcHJvcGVyIHBsYWNlIHRvIGRvIHRodXMgYnV0IHNp bmNlIGl04oCZcyBnb25lIGZyb20gdGhlIGNvcmUgd2Ugd2lsbCBoYXZlIHRvIGRvIGp1c3QgdGhh dC4gVGhlIHNhbWUgc2VlbXMgdG8gaGFwcGVuIHdpdGggdGhlIEhUVFAgQXV0aGVudGljYXRpb24g U2NoZW1lIGFzIGl0IHNlZW1zIHRvIGJlIHJlcGVhdGVkIGluIGZvbGxvdy1vbiBjb21wYW5pb24g c3BlY2lmaWNhdGlvbnMuIFdoaWxlIG9hdXRoLXYyIGlzIG5vdCBhbiBhdXRoZW50aWNhdGlvbiBw cm90b2NvbCB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IGZvciBhdXRoZW50aWNhdGlvbiB0byBhZGRy ZXNzIHNlY3VyaXR5IGNvbmNlcm5zLiBUaGVyZSBpcyBjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4g YXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb247IHdlIGFyZSBub3Qgc3VnZ2VzdGluZyB0 aGF0IGF1dGhlbnRpY2F0aW9uIGlzIGFwcHJvcHJpYXRlIGZhY2lsaXR5IHRvIG5lZ290aWF0ZSBh dXRob3JpemF0aW9uLiBJIHRoaW5rIHRoYXQgaXQgbWFrZXMgc2Vuc2UgdG8gaW5jbHVkZSBhIHNj aGVtZSBpbiB0aGUgY29yZSBhbmQgaGF2ZSB0aGUgcGFydGljdWxhciBmb2xsb3ctb24gY29tcGFu aW9uIHNwZWNpZmljYXRpb25zICh0aGUgdmFyaW91cyB0b2tlbiBzcGVjaWZpY2F0aW9ucykgc3Rh dGUvZGVmaW5lIHRoZSBwYXJhbWV0ZXJzIGFuZCBpZiB0aGV5IGRvbuKAmXQgbGlrZSB0aGUgZGVm YXVsdCBzY2hlbWUgbGV0IHRoZW0gZGVmaW5lIGEgbmV3IHNjaGVtZSBidXQgdGhpcyBwdXRzIGEg c3Rha2UgaW4gdGhlIGdyb3VuZCBmb3IgYW4gSFRUUCBBdXRoZW50aWNhdGlvbiBTY2hlbWUuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5A aHVlbml2ZXJzZS5jb21dIDxicj48Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAyNSwgMjAx MSA1OjM4IFBNPGJyPjxiPlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPjxiPkNjOjwvYj4gT0F1 dGggV0c8YnI+PGI+U3ViamVjdDo8L2I+IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENy ZWRlbnRpYWxzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2NvbG9yOiMxRjQ5N0QnPkNhbiB5b3Ugc2hhcmUgd2l0aCB0aGUgbGlzdCBob3cgeW91IHBsYW4g dG8gdXNlIHRoaXMgY2xpZW50IGFzc2VydGlvbiBhdXRoZW50aWNhdGlvbiBzY2hlbWU/PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+V2hpY2ggb2YgdGhlIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZXMgeW91IHdpbGwgdXNl IGl0IHdpdGg/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nY29sb3I6IzFGNDk3RCc+V2lsbCB5b3UgdXNlIGl0IHdpdGggdGhlIGF1dGhvcml6YXRp b24gZW5kcG9pbnQsIGFuZCBpZiBzbywgaG93IHdpbGwgeW91IGJpbmQgdGhlIGFzc2VydGlvbiB0 byB0aGUgY2xpZW50X2lkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkNhbiB5b3UgcHJvdmlkZSBmdWxsIGV4YW1wbGVz IG9mIGFzc2VydGlvbnMgYW5kIEhUVFAgcmVxdWVzdHM/PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFG NDk3RCc+SXQgd291bGQgYmUgaGVscGZ1bCB0byBzZWUgaG93IGZhciBhcGFydCB0aGUgcHJvcG9z ZWQgdGV4dCBiZWxvdyBpcyBmcm9tIGFuIGFjdHVhbCBpbXBsZW1lbnRhdGlvbiBtYWtpbmcgdXNl IG9mIGl0LiBJIGV4Y2VwdCB0byBzZWUgdGhlc2UgYW5zd2VycyBpbiBhbnkgcXVhbGl0eSBkb2N1 bWVudCBkZWZpbmluZyBhIG5ldyBjbGllbnQgYXV0aGVudGljYXRpb24gc2NoZW1lICh3aGljaCBp cyB0cnVlIGZvciB0aGUgY2xpZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIHRocm91Z2hvdXQg dGhlIGRvY3VtZW50KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5FSEw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluJz48cCBjbGFzcz1Nc29O b3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gQW50aG9ueSBOYWRhbGlu IDxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV0iPlttYWlsdG86 dG9ueW5hZEBtaWNyb3NvZnQuY29tXTwvYT4gPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51 YXJ5IDI1LCAyMDExIDM6NTggUE08YnI+PGI+VG86PC9iPiBFcmFuIEhhbW1lci1MYWhhdjsgT0F1 dGggV0c7IDxhIGhyZWY9Im1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0Ij5IYW5uZXMu VHNjaG9mZW5pZ0BnbXgubmV0PC9hPjsgQmxhaW5lIENvb2s8YnI+PGI+U3ViamVjdDo8L2I+IFJF OiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz1Nc29QbGFpblRleHQ+SSBkb24ndCB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9y IHJlbW92aW5nIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzLCBhcyBjbGllbnQgcGFz c3dvcmQgYXV0aGVudGljYXRpb24gaXMgbGVmdCBpbi4gQ2xpZW50IFBhc3N3b3JkIEF1dGhlbnRp Y2F0aW9uIGlzIGFsc28gdW5kZXJzcGVjaWZpZWQgYXMgY2xpZW50X3NlY3JldCBjb3VsZCBiZSBh bnl0aGluZyB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgc2VlbXMgZml0IChyYXcgY2xl YXIgdGV4dCBwYXNzd29yZCwmbmJzcDsgaGFzaCwgZGlnZXN0LCBldGMuKSBhbmQgbm8gd2F5IHRv IGRldGVybWluZSB0aGUgY29udGVudC4gY2xpZW50X3NlY3JldCBpcyBhbHNvIGEgdmVyeSB3ZWFr IG1lY2hhbmlzbSwgc2luY2UgdGhpcyBpcyBsZWZ0IGluIHRoZSBjb3JlIHRoaXMgbGVhZHMgbWUg dG8gYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIHN1cHBvcnQgZm9yIGhhdmluZyBjbGllbnQgYXV0aGVu dGljYXRpb24gaW4gT2F1dGguIEkgZG9uJ3Qgc2VlIGhvdyBoYXZpbmcgY2xpZW50X2Fzc2VydGlv biBhbmQgY2xpZW50X2Fzc2VydGlvbl90eXBlIHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGlzIHVu ZGVyc3BlY2lmaWVkIGFzIGJlaW5nIGEgbWVjaGFuaXNtIGluIHdoaWNoIGFzc2VydGlvbnMgY2Fu IGJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uLiBBZ3JlZSB0aGF0IHRoZSBhdXRoZW50aWNhdGlv biBzZXJ2ZXIgaGFzIHRvIG1ha2UgcmlnaHQgYW5kIGRlY2xhcmUgd2hhdCBpcyBiZWluZyB1c2Vk IGJ1dCB0aGF0IGlzIHRoZSBzYW1lIGZvciBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24u IFRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gYXNzZXJ0aW9ucyBhcmUgc29tZXRoaW5nIHRoYXQg TWljcm9zb2Z0IGFuZCBHb29nbGUgZmluZCB1c2VmdWwgYW5kIHBsYW4gb24gaW1wbGVtZW50aW5n IGFuZCB1c2luZyBhcyBhIG1lYW5zIGZvciBzdHJvbmdlciBhdXRoZW50aWNhdGlvbiB0byB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoaXMgZXh0ZW5zaWJpbGl0eSBiZWxvbmdzIGluIHRoZSBj b3JlLCB0aGVyZSBpcyBubyBvdGhlciBwbGFjZSB0byBwdXQgdGhpcyBmdW5jdGlvbmFsaXR5LiBJ IGRvbid0IGJlbGlldmUgdGhhdCB0aGUgcmVtb3ZhbCAoZWl0aGVyIGJ5IGVkaXRvciBvciBkaXJl Y3Rpb24gYnkgY28tY2hhaXIpIGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBoYXZlIGJlZW4gZG9u ZSB3L28gYSBjb25zZW5zdXMgdm90ZSBzaW5jZSB0aGlzIGhhcyBiZWVuIGluIHRoZSBzcGVjaWZp Y2F0aW9uIGZvciBzb21lIHRpbWUgd2l0aG91dCBpc3N1ZSBhbmQgdGhlIHJlbW92YWwgY29tZXMg YXMgY29tcGxldGUgdW53ZWxjb21lIHN1cnByaXNlLiBHZXR0aW5nIGFsbW9zdCB0b3RhbCByZXdy aXRlcyBvZiB0aGUgc3BlY2lmaWNhdGlvbiB0aGlzIGxhdGUgaW4gdGhlIHJldmlldyBjeWNsZSBp cyBhbHNvIHZlcnkgZGlzdHVyYmluZy48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29QbGFpblRl eHQ+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvUGxhaW5UZXh0PkEgcHJvcG9zYWwg Zm9yIGtlZXBpbmcgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gd291bGQgYmUg dG8gc2ltcGxpZnkgdG8gdGhlIGZvbGxvd2luZzs8bzpwPjwvbzpwPjwvcD48cD48c3BhbiBsYW5n PUVOIHN0eWxlPSdmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr Jz5UaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhcmUgdXNlZCBpbiBjYXNlcyB3aGVy ZSBhIHBhc3N3b3JkIChjbGVhci10ZXh0IHNoYXJlZCBzeW1tZXRyaWMgc2VjcmV0KSBpcyB1bnN1 aXRhYmxlIG9yIGRvZXMgbm90IHByb3ZpZGUgc3VmZmljaWVudCBzZWN1cml0eSBmb3IgY2xpZW50 IGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBwcm92aWRl IGFuIGV4dGVuc2libGUgbWVjaGFuaXNtIHRvIHVzZSBhbiBhc3NlcnRpb24gZm9ybWF0IHN1cHBv cnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRpY2F0aW9uIG9mIHRo ZSBjbGllbnQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBsYW5nPUVOIHN0eWxlPSdm b250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Vc2luZyBhc3Nl cnRpb25zIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFzc2VydGlvbiAoc3VjaCBh cyBhIDwvc3Bhbj48YSBocmVmPSIjT0FTSVMuc2FtbC1jb3JlLTIuMC1vcyI+PHNwYW4gbGFuZz1F TiBzdHlsZT0nZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNlcmlmIjt0ZXh0LWRlY29yYXRp b246bm9uZSc+U0FNTCAoQ2FudG9yLCBTLiwgS2VtcCwgSi4sIFBoaWxwb3R0LCBSLiwgYW5kIEUu IE1hbGVyLCDigJxBc3NlcnRpb25zIGFuZCBQcm90b2NvbCBmb3IgdGhlIE9BU0lTIFNlY3VyaXR5 IEFzc2VydGlvbiBNYXJrdXAgTGFuZ3VhZ2UgKFNBTUwpIFYyLjAs4oCdIE1hcmNoJm5ic3A7MjAw NS4pPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IlZlcmRhbmEiLCJzYW5zLXNl cmlmIjtjb2xvcjpibGFjayc+IDwvc3Bhbj48c3BhbiBsYW5nPUVOIHN0eWxlPSdmb250LWZhbWls eToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5bT0FTSVMuc2FtbOKAkWNvcmXi gJEyLjDigJFvc10gYXNzZXJ0aW9uKSBmcm9tIGFuIGFzc2VydGlvbiBpc3N1ZXIgb3IgdG8gc2Vs Zi1pc3N1ZSBhbiBhc3NlcnRpb24uIFRoZSBhc3NlcnRpb24gZm9ybWF0LCB0aGUgcHJvY2VzcyBi eSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlzIG9idGFpbmVkLCBhbmQgdGhlIG1ldGhvZCBvZiB2YWxp ZGF0aW5nIHRoZSBhc3NlcnRpb24gYXJlIGRlZmluZWQgYnkgdGhlIGFzc2VydGlvbiBpc3N1ZXIg YW5kIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9m IHRoaXMgc3BlY2lmaWNhdGlvbi4gPG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIGxhbmc9 RU4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn PldoZW4gdXNpbmcgYSBjbGllbnQgYXNzZXJ0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIHRoZSBm b2xsb3dpbmcgcGFyYW1ldGVyczogPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6NjAuMHB0O21h cmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQn PjxzcGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1zZXJpZiI7 Y29sb3I6YmxhY2snPmNsaWVudF9hc3NlcnRpb25fdHlwZSAtIFJFUVVJUkVELiBUaGUgZm9ybWF0 IG9mIHRoZSBhc3NlcnRpb24gYXMgZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu IFRoZSB2YWx1ZSBNVVNUIGJlIGFuIGFic29sdXRlIFVSSS4gPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWxlZnQ6MjQuMHB0O3RleHQtaW5kZW50 Oi41aW4nPjxzcGFuIGxhbmc9RU4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJWZXJkYW5hIiwic2Fucy1z ZXJpZiI7Y29sb3I6YmxhY2snPmNsaWVudF9hc3NlcnRpb24gLSBSRVFVSVJFRC4gVGhlIGNsaWVu dCBhc3NlcnRpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBsYW5nPUVOIHN0eWxl PSdmb250LWZhbWlseToiVmVyZGFuYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Gb3IgZXhh bXBsZSwgdGhlIGNsaWVudCBzZW5kcyB0aGUgZm9sbG93aW5nIGFjY2VzcyB0b2tlbiByZXF1ZXN0 IHVzaW5nIGEgU0FNTCAyLjAgYXNzZXJ0aW9uIHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYgKGxpbmUg YnJlYWtzIGFyZSBmb3IgZGlzcGxheSBwdXJwb3NlcyBvbmx5KTogPG86cD48L286cD48L3NwYW4+ PC9wPjxwcmUgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjI0LjBw dDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAw MXB0Jz48c3BhbiBsYW5nPUVOPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjI0LjBwdDttYXJnaW4tYm90 dG9tOjBpbjttYXJnaW4tbGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Jz48c3BhbiBs YW5nPUVOPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTj4m bmJzcDsgUE9TVCAvdG9rZW4gSFRUUC8xLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0 eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJv dHRvbTowaW47bWFyZ2luLWxlZnQ6NjAuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdCc+PHNwYW4g bGFuZz1FTj4mbmJzcDsgSG9zdDogc2VydmVyLmV4YW1wbGUuY29tPG86cD48L286cD48L3NwYW4+ PC9wcmU+PHByZT48c3BhbiBsYW5nPUVOPiZuYnNwOyBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9u L3gtd3d3LWZvcm0tdXJsZW5jb2RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4g bGFuZz1FTj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9RU4+ Jm5ic3A7IGdyYW50X3R5cGU9YXV0aG9yaXphdGlvbl9jb2RlJmFtcDtjb2RlPWkxV3NSbjF1QjEm YW1wOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmU+PHNwYW4gbGFuZz1FTj4mbmJzcDsgY2xp ZW50X2Fzc2VydGlvbj1QSE5oYld4d09sWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHkuLi5dWlQ0JTNE JmFtcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlPjxzcGFuIGxhbmc9RU4+Jm5ic3A7IGNs aWVudF9hc3NlcnRpb25fdHlwZT0gJm5ic3A7dXJuJTNBb2FzaXMlM0FuYW1lcyVzQXRjJTNBU0FN TCUzQTIuMCUzQWFzc2VydGlvbiZhbXA7cmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50 JTJFZXhhbXBsZSUyRWNvbSUyRmNiPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0n bXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1ib3R0b206 MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQnPjxzcGFuIGxhbmc9 RU4+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+PHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0Bp ZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGEgaHJlZj0ibWFpbHRvOlttYWls dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10iPlttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y Z108L2E+IDxiPk9uIEJlaGFsZiBPZiA8L2I+RXJhbiBIYW1tZXItTGFoYXY8YnI+PGI+U2VudDo8 L2I+IEZyaWRheSwgSmFudWFyeSAxNCwgMjAxMSAxMDo0NSBQTTxicj48Yj5Ubzo8L2I+IE9BdXRo IFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBbT0FVVEgtV0ddIFJlbW92YWw6IENsaWVudCBBc3NlcnRp b24gQ3JlZGVudGlhbHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5JIHdvdWxk IGxpa2UgdG8gc3VnZ2VzdCB3ZSBkcm9wIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxz ICgtMTEgc2VjdGlvbiAzLjIpIGZyb20gdGhlIHNwZWNpZmljYXRpb24sIGFuZCBpZiBuZWVkZWQs IHB1Ymxpc2ggaXQgYXMgYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgZm9sbG93aW5n IHJlYXNvbnM6PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9J21zby1saXN0Oklnbm9yZSc+MS48c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3 IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPlRoZSBtZWNoYW5pc20gaXMgdW5kZXIgc3BlY2lmaWVkLCBlc3BlY2lhbGx5 IGluIGl0cyBoYW5kbGluZyBvZiB0aGUgY2xpZW50X2lkIGlkZW50aWZpZXIgKHdoZW4gdXNlZCB0 byBvYnRhaW4gZW5kLXVzZXIgYXV0aG9yaXphdGlvbikuIEl0IGRvZXMgbm90IGNvbnRhaW4gYW55 IGltcGxlbWVudGF0aW9uIGRldGFpbHMgdG8gYWNjb21wbGlzaCBhbnkgbGV2ZWwgb2YgaW50ZXJv cGVyYWJpbGl0eSBvciBmdW5jdGlvbmFsaXR5LiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvIHRoZSBh c3NlcnRpb24gZ3JhbnQgdHlwZSB3aGljaCBoYXMgbWF0dXJlZCBvdmVyIGEgeWVhciBpbnRvIGEg ZnVsbHkgdGhvdWdodC1vdXQgZXh0ZW5zaW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBhIHNlcGFy YXRlIFNBTUwgYXNzZXJ0aW9uIHNwZWNpZmljYXRpb24gd2l0aCBhY3RpdmUgZGVwbG95bWVudCAo dGhlIHR3bywgdG9nZXRoZXIgd2l0aCBydW5uaW5nIGNvZGUsIHNob3cgY2xlYXIgY29uc2Vuc3Vz KS48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSd0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzInPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPjIuPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQg IlRpbWVzIE5ldyBSb21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgc2VjdGlvbiBpcyBhIGNvbmZ1c2VkIG1peCBvZiBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzcHJpbmtsZWQgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2Uu IEluc3RlYWQsIGl0IHNob3VsZCBiZSByZXBsYWNlZCB3aXRoIGd1aWRlbGluZXMgZm9yIGV4dGVu ZGluZyB0aGUgc2V0IG9mIHN1cHBvcnRlZCBjbGllbnQgY3JlZGVudGlhbHMsIGJ1dCB3aXRob3V0 IGRlZmluaW5nIGEgbmV3IHJlZ2lzdHJ5LiBJdCBpcyBjbGVhcmx5IGFuIGFyZWEgb2YgbGl0dGxl IGRlcGxveW1lbnQgZXhwZXJpZW5jZSBmb3IgT0F1dGgsIGFuZCB0aGF0IGluY2x1ZGVzIHVzaW5n IEhUVFAgQmFzaWMgYXV0aGVudGljYXRpb24gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAobW9y ZSBvbiB0aGF0IHRvIGNvbWUpLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3Jh cGggc3R5bGU9J3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMic+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+My48c3BhbiBz dHlsZT0nZm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBzZWN0aW9uIGhhcyBy ZWNlaXZlZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3NlIHdo byBzdGlsbCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkgY29u c2Vuc3VzIGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBvcnQg Zm9yIGRlcGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsIGFsc28gcmVxdWly ZSBzaG93aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9maWxpbmcgdGhl IG1lY2hhbmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPkNvbW1lbnRzPyBDb3VudGVyLWFyZ3VtZW50cz88bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPkVITDxv OnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9i b2R5PjwvaHRtbD4= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8D62753P3PW5EX1MB01E_-- From eran@hueniverse.com Wed Jan 26 14:51:16 2011 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 5F2823A69ED for ; Wed, 26 Jan 2011 14:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 rCAV3MtcFsCj for ; Wed, 26 Jan 2011 14:51:15 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id AE0BF3A69E8 for ; Wed, 26 Jan 2011 14:51:13 -0800 (PST) Received: (qmail 22090 invoked from network); 26 Jan 2011 22:54:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 22:54:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 26 Jan 2011 15:54:13 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 26 Jan 2011 15:53:55 -0700 Thread-Topic: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? Thread-Index: Acu9pL9EFbgexh7BQZS/qTPUUPV/zwABxJ7w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D62758@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723445A8D62544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62609@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 26 Jan 2011 22:51:16 -0000 Can you share what the actual request looks on the wire? How are you passin= g the Kerberos authentication in the request? What do you set the grant typ= e to? EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Wednesday, January 26, 2011 2:02 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokensendpoint? >=20 > On Wed, Jan 26, 2011 at 9:07 AM, Eran Hammer-Lahav > wrote: > > Can you share an actual example of how you are authenticating *both* th= e > resource owner and client in a single request? >=20 > That's not a business requirement. >=20 > So the desired flow goes like this: >=20 > kerberos (or other magic sauce) authentication -> access token >=20 > not like this: >=20 > client authentication + kerberos authentication -> access token >=20 > and definitely not like this: >=20 > client authentication + kerberos authentication -> refresh token >=20 > If we did see a need to authenticate the client, we would use the same > mechanisms as normal: client_id and client_secret, or else client_asserti= on. >=20 > (Curious to know if other people looking at these problems break it down = the > same way.) >=20 > Cheers, > Brian From eran@hueniverse.com Wed Jan 26 14:54:57 2011 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 A4E103A68C6 for ; Wed, 26 Jan 2011 14:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 J-hJyKQIlN9A for ; Wed, 26 Jan 2011 14:54:56 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C52AC3A6875 for ; Wed, 26 Jan 2011 14:54:56 -0800 (PST) Received: (qmail 2117 invoked from network); 26 Jan 2011 22:57:58 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jan 2011 22:57:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 26 Jan 2011 15:57:56 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Wed, 26 Jan 2011 15:57:39 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu9ogeRAwlXT0bpQq61uKkqcPiAygACe9PA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D6275A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62545@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 22:54:57 -0000 > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Wednesday, January 26, 2011 1:43 PM > To: Eran Hammer-Lahav > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt =20 > >> 1. The token_type parameter is required in responses from the server. > >> If the server supports multiple formats, which one will be used? In > >> this case, would it make sense to allow the client to request a specif= ic > format? > >> > >> For example, if the authorization server supports both MAC and > >> BEARER, which one will the server issue? > > > > It might in some cases, but I suspect most providers are going to decid= e > which scheme provides the right level of security for them and just use t= hat. > If you are going to allow both MAC and BEARER, you are basically letting > clients decide which level to operate at. Do you have a need or plan to > support multiple token types? >=20 > For now we are planning to support only bearer, but I am sure some form o= f > signed tokens will follow sooner than later. At which point we would have= to > support both. >=20 > In most cases I think it is up to the client to decide. Interesting. Given that you are not planning on supporting this in the near= future, I think we should wait until there is more deployment experience i= n allowing the client to negotiate the token type. But of course, you are w= elcome to submit a proposal for inclusion on the WG new charter. EHL From wmills@yahoo-inc.com Wed Jan 26 15:17:30 2011 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 3F2AB3A6A0C for ; Wed, 26 Jan 2011 15:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.533 X-Spam-Level: X-Spam-Status: No, score=-17.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, 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 C7-IGaeM-KCI for ; Wed, 26 Jan 2011 15:17:29 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by core3.amsl.com (Postfix) with ESMTP id 77B0A3A6A08 for ; Wed, 26 Jan 2011 15:17:29 -0800 (PST) Received: from SP2-EX07CAS05.ds.corp.yahoo.com (sp2-ex07cas05.corp.sp2.yahoo.com [98.137.59.39]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0QNHIkY038686; Wed, 26 Jan 2011 15:17:18 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS05.ds.corp.yahoo.com ([98.137.59.39]) with mapi; Wed, 26 Jan 2011 15:17:18 -0800 From: William Mills To: Eran Hammer-Lahav , Marius Scurtescu Date: Wed, 26 Jan 2011 15:17:17 -0800 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu9ogeRAwlXT0bpQq61uKkqcPiAygACe9PAAACUY8A= Message-ID: References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62545@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D6275A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D6275A@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 26 Jan 2011 23:17:30 -0000 Actually I was envisioning a situation where you have multiple possibly dis= parate endpoints that rely on authenticator like Google or Yahoo. One comp= any decides they want to allow federated login and accept SAML assertions, = another accepts bearer, yet a 3rd IMAP server accepts both some form of sig= ned auth and bearer. I think discovery for a service should allow the serv= ice to specify the type(s) of auth accepted and the client can choose one t= hat it supports and pass that on to the token server. The resource server = has to know what auth types are supported by the token server. I would rat= her have this explicit in the discovery information and support multiple ty= pes in the same SASL mechanism than have to offer N mechanisms (or 2N if ch= annel binding is in play). > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Eran Hammer-Lahav > Sent: Wednesday, January 26, 2011 2:58 PM > To: Marius Scurtescu > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 >=20 >=20 > > -----Original Message----- > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > Sent: Wednesday, January 26, 2011 1:43 PM > > To: Eran Hammer-Lahav > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > > >> 1. The token_type parameter is required in responses from the > server. > > >> If the server supports multiple formats, which one will be used? > In > > >> this case, would it make sense to allow the client to request a > specific > > format? > > >> > > >> For example, if the authorization server supports both MAC and > > >> BEARER, which one will the server issue? > > > > > > It might in some cases, but I suspect most providers are going to > decide > > which scheme provides the right level of security for them and just > use that. > > If you are going to allow both MAC and BEARER, you are basically > letting > > clients decide which level to operate at. Do you have a need or plan > to > > support multiple token types? > > > > For now we are planning to support only bearer, but I am sure some > form of > > signed tokens will follow sooner than later. At which point we would > have to > > support both. > > > > In most cases I think it is up to the client to decide. >=20 > Interesting. Given that you are not planning on supporting this in the > near future, I think we should wait until there is more deployment > experience in allowing the client to negotiate the token type. But of > course, you are welcome to submit a proposal for inclusion on the WG > new charter. >=20 > EHL > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From beaton@google.com Wed Jan 26 17:34:35 2011 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 D8D9828C0EB for ; Wed, 26 Jan 2011 17:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.377 X-Spam-Level: X-Spam-Status: No, score=-105.377 tagged_above=-999 required=5 tests=[AWL=0.600, 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 wzQsZxUM581c for ; Wed, 26 Jan 2011 17:34:35 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id E3D5728C0E3 for ; Wed, 26 Jan 2011 17:34:34 -0800 (PST) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p0R1bas0003764 for ; Wed, 26 Jan 2011 17:37:36 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296092256; bh=Qrex4ZQ462n2mVzI1V38HibivgE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=RxD2LhqdPl06ExubGpqNMG6dCn+q+hTxA5e6UQxl4TO2FkdFAUYvc4TmLpwla20S4 Yb5Odsxq08U1lRZCVL7kQ== Received: from pwi7 (pwi7.prod.google.com [10.241.219.7]) by hpaq7.eem.corp.google.com with ESMTP id p0R1bGjQ005765 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 17:37:34 -0800 Received: by pwi7 with SMTP id 7so428151pwi.3 for ; Wed, 26 Jan 2011 17:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y38+a7hKNj5wpIuJI4OVLBGE70OhliGz0Xr2Lcc8Nac=; b=FC2iRMrmLo5VYXT8DjcoWmIpnCCR8EalgbzIUrNhU/73g7peIi6tMBkpGjVa28Wmkq tNvoZcQHMkd1YHIPC3Kw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UCmoxsQxHkz939Q90TwKyuVUaz03dmBnYs6tmF6LkoOH8mW/Ooc1gmDx4MNSizYZZm hj0kLgCsvirW4WnV38JQ== MIME-Version: 1.0 Received: by 10.142.241.18 with SMTP id o18mr1122671wfh.340.1296092254171; Wed, 26 Jan 2011 17:37:34 -0800 (PST) Received: by 10.142.213.7 with HTTP; Wed, 26 Jan 2011 17:37:33 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62758@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723445A8D62544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62609@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62758@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 26 Jan 2011 17:37:33 -0800 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] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 27 Jan 2011 01:34:36 -0000 On Wed, Jan 26, 2011 at 2:53 PM, Eran Hammer-Lahav wrote: > Can you share what the actual request looks on the wire? How are you passing the Kerberos authentication in the request? What do you set the grant type to? Most of this pre-dates grant type and the OAuth2 brand. =) >From memory, the kerberos to access token swap looks like this: GET /some/token/endpoint?s=&g= Authorization: Negotiate And the response includes a ticket that is basically an OAuth2 access token, for the specified scope, with some additional metadata requested by the "g" parameter. Cheers, Brian From beaton@google.com Wed Jan 26 17:35:50 2011 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 53A213A68EF for ; Wed, 26 Jan 2011 17:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.377 X-Spam-Level: X-Spam-Status: No, score=-105.377 tagged_above=-999 required=5 tests=[AWL=0.600, 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 m0CR+1EC-SNh for ; Wed, 26 Jan 2011 17:35:50 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 113C83A6801 for ; Wed, 26 Jan 2011 17:35:49 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p0R1c65Z019283 for ; Wed, 26 Jan 2011 17:38:06 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296092287; bh=Qrex4ZQ462n2mVzI1V38HibivgE=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=ShvZgcvqD/z3mh78r0NpvqiwsaI6LZ9NUjbJ+zqX2gl/u3sSGFDPBInujPKoqhUEs HhVH5yRdnxdmKAMkjb+Dg== Received: from yia25 (yia25.prod.google.com [10.243.65.25]) by hpaq11.eem.corp.google.com with ESMTP id p0R1c4e4016810 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 26 Jan 2011 17:38:05 -0800 Received: by yia25 with SMTP id 25so414881yia.14 for ; Wed, 26 Jan 2011 17:38:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Y38+a7hKNj5wpIuJI4OVLBGE70OhliGz0Xr2Lcc8Nac=; b=aS6KRgOFEdJNncWUyp6WDRi2VrxLL/4zzKClE/LTh1HO2CxQx6HZekQEPv9PIRZPNW wdIdhtnKITNQMkkPkY8g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xEfKgr4htItRMS8WA6r1jggfpXuHZGbJaRSjcZYrGfGq3ICGzfjbVdDGvQkqrvOMGc 0sc+nflKsthapYufN2wQ== MIME-Version: 1.0 Received: by 10.90.63.5 with SMTP id l5mr2164123aga.201.1296092283940; Wed, 26 Jan 2011 17:38:03 -0800 (PST) Received: by 10.90.56.6 with HTTP; Wed, 26 Jan 2011 17:38:01 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62758@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723445A8D62544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62609@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62758@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 26 Jan 2011 17:38:01 -0800 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] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 27 Jan 2011 01:35:50 -0000 On Wed, Jan 26, 2011 at 2:53 PM, Eran Hammer-Lahav wrote: > Can you share what the actual request looks on the wire? How are you passing the Kerberos authentication in the request? What do you set the grant type to? Most of this pre-dates grant type and the OAuth2 brand. =) >From memory, the kerberos to access token swap looks like this: GET /some/token/endpoint?s=&g= Authorization: Negotiate And the response includes a ticket that is basically an OAuth2 access token, for the specified scope, with some additional metadata requested by the "g" parameter. Cheers, Brian From eran@hueniverse.com Wed Jan 26 19:20:13 2011 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 735DB28C0F5 for ; Wed, 26 Jan 2011 19:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 rHpsVGul5gbG for ; Wed, 26 Jan 2011 19:20:09 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id DFB1D28C0F3 for ; Wed, 26 Jan 2011 19:20:06 -0800 (PST) Received: (qmail 8056 invoked from network); 27 Jan 2011 03:22:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Jan 2011 03:22:47 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 26 Jan 2011 20:22:36 -0700 From: Eran Hammer-Lahav To: Brian Eaton Date: Wed, 26 Jan 2011 20:22:17 -0700 Thread-Topic: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? Thread-Index: Acu9wvMjPRtBN57sT2O2hAGlHEyimQADiZeQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D627C2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D3DEAAA.6070201@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E723445A8D62201@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1304418451-1295937330-cardhu_decombobulator_blackberry.rim.net-1631491384-@b1.c11.bise7.blackberry> <90C41DD21FB7C64BB94121FBBC2E723445A8D622A1@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20110125092230.15123t1lj1ap0twk@webmail.df.eu> <90C41DD21FB7C64BB94121FBBC2E723445A8D62544@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62609@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62758@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with tokensendpoint? 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, 27 Jan 2011 03:20:13 -0000 So technically, this is not a token endpoint, per OAuth 2.0, but an endpoin= t where you can get tokens using some other parameters and headers. This is= perfectly fine, but is using a different design. EHL > -----Original Message----- > From: Brian Eaton [mailto:beaton@google.com] > Sent: Wednesday, January 26, 2011 5:38 PM > To: Eran Hammer-Lahav > Cc: Torsten Lodderstedt; OAuth WG > Subject: Re: [OAUTH-WG] How to integrated DIGEST or SPNEGO with > tokensendpoint? >=20 > On Wed, Jan 26, 2011 at 2:53 PM, Eran Hammer-Lahav > wrote: > > Can you share what the actual request looks on the wire? How are you > passing the Kerberos authentication in the request? What do you set the > grant type to? >=20 > Most of this pre-dates grant type and the OAuth2 brand. =3D) >=20 > From memory, the kerberos to access token swap looks like this: >=20 > GET /some/token/endpoint?s=3D&g=3D > Authorization: Negotiate >=20 > And the response includes a ticket that is basically an OAuth2 access tok= en, > for the specified scope, with some additional metadata requested by the "= g" > parameter. >=20 > Cheers, > Brian From eran@hueniverse.com Wed Jan 26 19:23:56 2011 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 6098628C0F3 for ; Wed, 26 Jan 2011 19:23:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 MxWjciZLd1XG for ; Wed, 26 Jan 2011 19:23:54 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C00743A6867 for ; Wed, 26 Jan 2011 19:23:54 -0800 (PST) Received: (qmail 16665 invoked from network); 27 Jan 2011 03:26:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Jan 2011 03:26:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 26 Jan 2011 20:26:54 -0700 From: Eran Hammer-Lahav To: William Mills , Marius Scurtescu Date: Wed, 26 Jan 2011 20:26:35 -0700 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu9ogeRAwlXT0bpQq61uKkqcPiAygACe9PAAACUY8AACOWwUA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8D627C5@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62545@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D6275A@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 27 Jan 2011 03:23:56 -0000 This is a good example of why this is currently out of scope. We have littl= e to no implementation experience with such a setup. EHL > -----Original Message----- > From: William Mills [mailto:wmills@yahoo-inc.com] > Sent: Wednesday, January 26, 2011 3:17 PM > To: Eran Hammer-Lahav; Marius Scurtescu > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > Actually I was envisioning a situation where you have multiple possibly > disparate endpoints that rely on authenticator like Google or Yahoo. One > company decides they want to allow federated login and accept SAML > assertions, another accepts bearer, yet a 3rd IMAP server accepts both so= me > form of signed auth and bearer. I think discovery for a service should a= llow > the service to specify the type(s) of auth accepted and the client can ch= oose > one that it supports and pass that on to the token server. The resource > server has to know what auth types are supported by the token server. I > would rather have this explicit in the discovery information and support > multiple types in the same SASL mechanism than have to offer N > mechanisms (or 2N if channel binding is in play). >=20 > > -----Original Message----- > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > > Of Eran Hammer-Lahav > > Sent: Wednesday, January 26, 2011 2:58 PM > > To: Marius Scurtescu > > Cc: oauth@ietf.org > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > > > > > > -----Original Message----- > > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > > Sent: Wednesday, January 26, 2011 1:43 PM > > > To: Eran Hammer-Lahav > > > Cc: oauth@ietf.org > > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > > >> 1. The token_type parameter is required in responses from the > > server. > > > >> If the server supports multiple formats, which one will be used? > > In > > > >> this case, would it make sense to allow the client to request a > > specific > > > format? > > > >> > > > >> For example, if the authorization server supports both MAC and > > > >> BEARER, which one will the server issue? > > > > > > > > It might in some cases, but I suspect most providers are going to > > decide > > > which scheme provides the right level of security for them and just > > use that. > > > If you are going to allow both MAC and BEARER, you are basically > > letting > > > clients decide which level to operate at. Do you have a need or plan > > to > > > support multiple token types? > > > > > > For now we are planning to support only bearer, but I am sure some > > form of > > > signed tokens will follow sooner than later. At which point we would > > have to > > > support both. > > > > > > In most cases I think it is up to the client to decide. > > > > Interesting. Given that you are not planning on supporting this in the > > near future, I think we should wait until there is more deployment > > experience in allowing the client to negotiate the token type. But of > > course, you are welcome to submit a proposal for inclusion on the WG > > new charter. > > > > EHL > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth From wmills@yahoo-inc.com Wed Jan 26 22:37:14 2011 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 9DD443A6AF3 for ; Wed, 26 Jan 2011 22:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.369 X-Spam-Level: X-Spam-Status: No, score=-17.369 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, NO_RDNS_DOTCOM_HELO=0.001, 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 K2ARmVvaRJ3E for ; Wed, 26 Jan 2011 22:37:12 -0800 (PST) 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 853C93A6AED for ; Wed, 26 Jan 2011 22:37:12 -0800 (PST) Received: from SP2-EX07CAS04.ds.corp.yahoo.com (sp2-ex07cas04.corp.sp2.yahoo.com [98.137.59.5]) by mrout2-b.corp.re1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0R6dnIu028315; Wed, 26 Jan 2011 22:39:50 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS04.ds.corp.yahoo.com ([98.137.59.5]) with mapi; Wed, 26 Jan 2011 22:39:49 -0800 From: William Mills To: Eran Hammer-Lahav , Marius Scurtescu Date: Wed, 26 Jan 2011 22:39:55 -0800 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu9ogeRAwlXT0bpQq61uKkqcPiAygACe9PAAACUY8AACOWwUAAGwYCg Message-ID: References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62545@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D6275A@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D627C5@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D627C5@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 27 Jan 2011 06:37:15 -0000 Well, I guess I better get going with the SASL thing and get a working impl= ementation done based on -12 and the bearer token spec. > -----Original Message----- > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] > Sent: Wednesday, January 26, 2011 7:27 PM > To: William Mills; Marius Scurtescu > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt >=20 > This is a good example of why this is currently out of scope. We have > little to no implementation experience with such a setup. >=20 > EHL >=20 > > -----Original Message----- > > From: William Mills [mailto:wmills@yahoo-inc.com] > > Sent: Wednesday, January 26, 2011 3:17 PM > > To: Eran Hammer-Lahav; Marius Scurtescu > > Cc: oauth@ietf.org > > Subject: RE: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > Actually I was envisioning a situation where you have multiple > possibly > > disparate endpoints that rely on authenticator like Google or Yahoo. > One > > company decides they want to allow federated login and accept SAML > > assertions, another accepts bearer, yet a 3rd IMAP server accepts > both some > > form of signed auth and bearer. I think discovery for a service > should allow > > the service to specify the type(s) of auth accepted and the client > can choose > > one that it supports and pass that on to the token server. The > resource > > server has to know what auth types are supported by the token server. > I > > would rather have this explicit in the discovery information and > support > > multiple types in the same SASL mechanism than have to offer N > > mechanisms (or 2N if channel binding is in play). > > > > > -----Original Message----- > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On > Behalf > > > Of Eran Hammer-Lahav > > > Sent: Wednesday, January 26, 2011 2:58 PM > > > To: Marius Scurtescu > > > Cc: oauth@ietf.org > > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > > > > > > > > > > -----Original Message----- > > > > From: Marius Scurtescu [mailto:mscurtescu@google.com] > > > > Sent: Wednesday, January 26, 2011 1:43 PM > > > > To: Eran Hammer-Lahav > > > > Cc: oauth@ietf.org > > > > Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt > > > > > > > >> 1. The token_type parameter is required in responses from the > > > server. > > > > >> If the server supports multiple formats, which one will be > used? > > > In > > > > >> this case, would it make sense to allow the client to request > a > > > specific > > > > format? > > > > >> > > > > >> For example, if the authorization server supports both MAC and > > > > >> BEARER, which one will the server issue? > > > > > > > > > > It might in some cases, but I suspect most providers are going > to > > > decide > > > > which scheme provides the right level of security for them and > just > > > use that. > > > > If you are going to allow both MAC and BEARER, you are basically > > > letting > > > > clients decide which level to operate at. Do you have a need or > plan > > > to > > > > support multiple token types? > > > > > > > > For now we are planning to support only bearer, but I am sure > some > > > form of > > > > signed tokens will follow sooner than later. At which point we > would > > > have to > > > > support both. > > > > > > > > In most cases I think it is up to the client to decide. > > > > > > Interesting. Given that you are not planning on supporting this in > the > > > near future, I think we should wait until there is more deployment > > > experience in allowing the client to negotiate the token type. But > of > > > course, you are welcome to submit a proposal for inclusion on the > WG > > > new charter. > > > > > > EHL > > > _______________________________________________ > > > OAuth mailing list > > > OAuth@ietf.org > > > https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Thu Jan 27 02:33:59 2011 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 86C5628C10C for ; Thu, 27 Jan 2011 02:33:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 aJQjyfeY61gH for ; Thu, 27 Jan 2011 02:33:58 -0800 (PST) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by core3.amsl.com (Postfix) with SMTP id F32B43A6961 for ; Thu, 27 Jan 2011 02:33:57 -0800 (PST) Received: from source ([209.85.161.50]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKTUFKy9+S+vDovUGpvIoH/OHcJHj6DiWz@postini.com; Thu, 27 Jan 2011 02:37:01 PST Received: by fxm14 with SMTP id 14so2129914fxm.9 for ; Thu, 27 Jan 2011 02:36:58 -0800 (PST) Received: by 10.223.72.10 with SMTP id k10mr744110faj.31.1296124618491; Thu, 27 Jan 2011 02:36:58 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id n3sm5899685faa.29.2011.01.27.02.36.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 02:36:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Thu, 27 Jan 2011 11:36:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Marius Scurtescu X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Draft -12 feedback deadline 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, 27 Jan 2011 10:33:59 -0000 On Jan 26, 2011, at 9:09 PM, Marius Scurtescu wrote: > - 4.1. Authorization Code. It is stated that authorization code is > suitable for clients that can hold a secret. Not necessarily true, it > is the best flow for native apps, for example. We concur with this as well. Our current implementation supports the = auth flow for apps that can and cannot keep secrets (and our developer = UI makes a clear distinction between these two in app registration). = While most native apps should be able to perform a Implicit Grant flow, = it helps to make permissible Auth Code flow as it allows a developer to = reuse a flow with which he's already familiar. That is, Auth Code flow = becomes the default flow with which developers will familiarize = themselves with - the question is just whether or not an client = credentials are required on token request. I actually can't think of a case as Marius suggest where an Auth Code = flow is better than Implicit for a native app, except for the point = about reusing existing developer knowledge. However, we do have the = issue of the Out-of-Band flow (which is an important issue for us) which = I'll address below. -- 3.1.1, 4.1.2, and Out-of-Band flows It is an important consideration for us that clients that cannot capture = a redirect from the user-agent be able to use authentication flow. In = the past this has been dubbed and Out-of-Band (OOB) flow. However, the = reorganization of the document clearly marks out both Auth and Implicit = as flows reserved for clients "capable of receiving incoming requests = (via redirection) from the authorization server." This language makes = these incompatible with OOB clients. In addition, other language = inhibits this use: - 3.1.1 definition of the redirection URI, requirement as an absolute = URI, and other requirements of use - restriction of 4.1 flow to clients that can keep secrets (eg, excludes = OOB device clients) Originally we had planned on the auth-code flow with a redirect_url of = "oob" for such clients. Given the revised language, we'd likely avoid = this now. Perhaps I missed considerations for OOB going forward. If = not, and short of revising the language in 4.1 to accommodate OOB, I = assume the best path forward is an extension to section 4 as a = consideration for clients that can't receive such incoming redirect = requests. Such a flow would be nearly identical to Auth Code but = without the requirement of a redirect UI, open to clients without = credentials, and a response_type of "oob_code." -- Other feedback on flow-based reorganization. The clear delineation of flows for clients with secrets and those = without is the most spectacular improvement to the spec since v10, in my = opinion. This includes Section 2 on Client Auth as well as the = designation of the Auth Code flow for clients with credentials, and the = restriction of the Implicit flow for those without. We consider this = critical to a proper understanding of the protocol and how it should be = used. However, considering the Auth Code mechanic can be used without client = auth as well, consider the following re-statement of client auth = considerations for 4.1 and 4.2 (addition of terms "Verifiable" and = "Forgeable" optional and open to editorial, of course) 1.3.5 Verifiable Client - a client that can keep secrets and can = authenticate with the authorization server. Examples include.. 1.3.6 Forgeable Client - a client whose identity cannot be verified = because the client is unable to keep authentication credentials secret. = Examples include... 4.1 Authorization Code This flow is suitable for VERIFIABLE and FORGEABLE clients. As a = redirection based protocol... 4.1.3 The authorization server MUST: - Validate client credentials for VERIFIABLE clients. 4.2 Implicit Grant This flow is suitable only for FORGEABLE clients. As a redirection = based protocol...= From skylar@kiva.org Thu Jan 27 02:57:18 2011 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 2FB8A28C125 for ; Thu, 27 Jan 2011 02:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_BL_SPAMCOP_NET=1.96] 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 ufA5E01NA0Ka for ; Thu, 27 Jan 2011 02:57:17 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by core3.amsl.com (Postfix) with SMTP id 134FF28C131 for ; Thu, 27 Jan 2011 02:57:16 -0800 (PST) Received: from source ([209.85.161.49]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKTUFQQyLCgNPgiSWQ9EGkRcX0/JC7Dt14@postini.com; Thu, 27 Jan 2011 03:00:20 PST Received: by fxm19 with SMTP id 19so2336613fxm.36 for ; Thu, 27 Jan 2011 03:00:18 -0800 (PST) Received: by 10.223.74.143 with SMTP id u15mr761339faj.27.1296126018598; Thu, 27 Jan 2011 03:00:18 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id n1sm5909650fam.16.2011.01.27.03.00.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 03:00:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Thu, 27 Jan 2011 12:00:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> References: <4D239DCF.4030501@lodderstedt.net> To: Marius Scurtescu X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension 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, 27 Jan 2011 10:57:18 -0000 Marius, I support the extension (as per my previous letter, as I missed this = thread over the holidays) and Kiva is/was planning to support this as = well. Given the unpredictable technology environments of many of our = customers, this flow is essential for our implementation. However, now reviewing language in draft-12, I wonder if it isn't more = clear to define the extension as using a different response_type (eg, = oob_code). In the past, the use of "oob" has been more of hack to work = with existing specs. In truth, it is a unique flow of its own compared = to Implict and Auth Code as they are currently defined. Such a flow = would not accept a redirect_url and could use "oob_code" for both = response_type and grant_type. skylar On Jan 4, 2011, at 11:58 PM, Marius Scurtescu wrote: > On Tue, Jan 4, 2011 at 2:23 PM, Torsten Lodderstedt > wrote: >> +1 >>=20 >> I have asked myself all the time why "oob" disappeared in OAuth 2.0? = Does >> Google use this feature? >=20 > Yes, we are planning to support this, exactly as described in the = extension. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From skylar@kiva.org Thu Jan 27 03:48:33 2011 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 CF2AC3A698D for ; Thu, 27 Jan 2011 03:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 PSxSk-MN4Ins for ; Thu, 27 Jan 2011 03:48:32 -0800 (PST) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by core3.amsl.com (Postfix) with SMTP id 4A5A328C125 for ; Thu, 27 Jan 2011 03:48:32 -0800 (PST) Received: from source ([209.85.161.51]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKTUFcR0DPWt0YL+6nzBZO2VzTW2CM2t57@postini.com; Thu, 27 Jan 2011 03:51:36 PST Received: by fxm5 with SMTP id 5so2182389fxm.24 for ; Thu, 27 Jan 2011 03:51:33 -0800 (PST) Received: by 10.223.101.131 with SMTP id c3mr831033fao.95.1296129093802; Thu, 27 Jan 2011 03:51:33 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id z1sm5931285fau.21.2011.01.27.03.51.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 27 Jan 2011 03:51:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 27 Jan 2011 12:51:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <809B826D-EFC6-439E-9926-D5AF085DBA60@kiva.org> References: <90C41DD21FB7C64BB94121FBBC2E723445A8D61EBF@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: Eran Hammer-Lahav X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] draft-hammer-oauth-v2-mac-token-02 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, 27 Jan 2011 11:48:33 -0000 This is excellent. Thanks for pulling together a signature-based token = spec. Some feedback: - As I think was mentioned in a previous post, this spec is also = attractive as method for asserting client credentials (eg, for access = token requests). Your point is noted on substituting "client_id" as = "token" though some language to recommend the general application of = this field could be helpful for those reading the spec to draw the same = conclusion. My personal preference might be the use of the word = "assertion" over "token" if this is meant to be a general-purpose = mechanism. Otherwise, people will naturally draw a strong correlation = between related OAuth specs. I suppose this is the same sort of tension = involved in keeping a more general name of MAC or assuming a more = integral term, OAUTH_MAC. In any case, it feels like a "hack" to ask = developers to put "client_id" into the "token" field, so I prefer = multi-purpose names where multiple uses are intended. - When presenting an MAC token, it would be attractive if client = credentials could also be captured in the assertion without relying on a = separate assertion (imagine the confusion in two Authorization headers, = MAC [token=3Dclient_id] and MAC [token=3Dtoken]). A simple solution = (and one that preserves the same double-secret signature as OAuth 1.0) = would be to require the value of "secret" (used as the signing key) to = be a concatenation of client_secret and token_secret. I assume this kind = of special instruction could be made by providers just as simply as the = explanation of the use of "token" for client_id in client auth. I = mention it to see if anyone sees conflicts or objections to this use, or = if it is worth including the option in the spec in some manner. If the = spec is trying to remain more independent from the core OAuth spec, then = I suppose that's a reason to both allow such alternate use and not = address it. If the spec means to address common use cases and draw tight = correlation between the two specs, then I see this as an positive = clarification. Validating client identity on the presentation of tokens = is a valuable ability. Using client credentials in the assertion allows = for the signature to include an element that is potentially never sent = over the wire or in a previous OAuth exchange. - Using a body hash and making it optional is a great alternative to the = OAuth 1.0a method incorporating content body params. Given the confusion = that parameter ordering and sorting caused for 1.0a why not apply the = same method for query-string parameters? That is, normalize the = query-string parameters, sort them, create a parameter hash, and include = it in the assertion (optional). This allows providers to not require = this if they consider it to be unnecessary for security as well as a = hurdle to message signing. In any case, I'd see both elements as either = optional or required. - As expressed, I had concerns over versioning of the format as any = modification could introduce brittleness to the construction of the = Signature Base String. Your preference seems to be to introduce MAC2 if = incompatibility or confusion arises. Assuming everyone else is fine with = that, it's an acceptable path forward. Of all these points, I'm most interested in feedback from others on the = use of client_secret+token_secret as option for the signature key. skylar On Jan 22, 2011, at 2:09 AM, Eran Hammer-Lahav wrote: > http://tools.ietf.org/html/draft-hammer-oauth-v2-mac-token-02 > =20 > New version includes the following changes: > =20 > o Added body-hash support. > o Updated OAuth 2.0 reference to -12 and added token type = registration template. > o Removed error and error URI attributes (codes were just a = duplication of the HTTP status codes). > =20 > Feedback would be greatly appreciated. > =20 > EHL > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu Jan 27 05:39:35 2011 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 D5C573A6452 for ; Thu, 27 Jan 2011 05:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 AOb8Wu6EFnU0 for ; Thu, 27 Jan 2011 05:39:35 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 035623A6802 for ; Thu, 27 Jan 2011 05:39:34 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3017921B0D98; Thu, 27 Jan 2011 08:42:38 -0500 (EST) Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 290D121B06AA; Thu, 27 Jan 2011 08:42:38 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub1.MITRE.ORG ([129.83.29.73]) with mapi; Thu, 27 Jan 2011 08:42:38 -0500 From: "Richer, Justin P." To: Marius Scurtescu , Eran Hammer-Lahav Date: Thu, 27 Jan 2011 08:40:14 -0500 Thread-Topic: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt Thread-Index: Acu9qrjedZuq5M7NQ0utei1FdZ2IdAAfQE2o Message-ID: References: <20110121004501.28103.96097.idtracker@localhost> <90C41DD21FB7C64BB94121FBBC2E723445A8D61C8E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D61CBA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <1296051184.9984.5.camel@pulse> <155BD4E7-F8B3-4B4A-B02D-EAE2048A2F51@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8D6262E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8D62744@P3PW5EX1MB01.EX1.SECURESERVER.NET>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt 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, 27 Jan 2011 13:39:35 -0000 In an ideal world, everything that lives alongside the official oauth param= eters is known to oauth, but we don't live in an ideal world and the spec n= eeds to be able to cope with that.=20 I can live with the relaxation here as well -- it's a reasonable compromise= , though not the ideal. I'm also assuming that the relaxation would apply t= o the registry requirement as well?=20 -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Marius S= curtescu [mscurtescu@google.com] Sent: Wednesday, January 26, 2011 5:44 PM To: Eran Hammer-Lahav Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-12.txt On Wed, Jan 26, 2011 at 2:29 PM, Eran Hammer-Lahav wr= ote: > How about turn the MUST to a SHOULD for using the x_ prefix? OK, let's go with that. Thanks, Marius _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu Jan 27 11:38:39 2011 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 A06ED28C179 for ; Thu, 27 Jan 2011 11:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.361 X-Spam-Level: X-Spam-Status: No, score=-4.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, GB_I_LETTER=-2] 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 NKr678jByKf1 for ; Thu, 27 Jan 2011 11:38:38 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id B711F28C178 for ; Thu, 27 Jan 2011 11:38:38 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9AE4721B070E; Thu, 27 Jan 2011 14:41:42 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 93A1021B0E2C; Thu, 27 Jan 2011 14:41:42 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 27 Jan 2011 14:41:42 -0500 From: "Richer, Justin P." To: Skylar Woodward , Marius Scurtescu Date: Thu, 27 Jan 2011 14:39:54 -0500 Thread-Topic: [OAUTH-WG] Native Client Extension Thread-Index: Acu+EWaVnDOBczSKTMSP/6qN/u5OfQASJH7+ Message-ID: References: <4D239DCF.4030501@lodderstedt.net> , <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> In-Reply-To: <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension 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, 27 Jan 2011 19:38:39 -0000 +1 on out of band auth being moved to a more fully-specified extension. It = can (and likely should) still use mechanisms such as auth codes, but with d= ifferent requirements such as no return URL. This is where things like the = code hack can live, as well. -- Justin ________________________________________ From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of Skylar W= oodward [skylar@kiva.org] Sent: Thursday, January 27, 2011 6:00 AM To: Marius Scurtescu Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension Marius, I support the extension (as per my previous letter, as I missed this thread= over the holidays) and Kiva is/was planning to support this as well. Give= n the unpredictable technology environments of many of our customers, this = flow is essential for our implementation. However, now reviewing language in draft-12, I wonder if it isn't more clea= r to define the extension as using a different response_type (eg, oob_code)= . In the past, the use of "oob" has been more of hack to work with existin= g specs. In truth, it is a unique flow of its own compared to Implict and A= uth Code as they are currently defined. Such a flow would not accept a red= irect_url and could use "oob_code" for both response_type and grant_type. skylar On Jan 4, 2011, at 11:58 PM, Marius Scurtescu wrote: > On Tue, Jan 4, 2011 at 2:23 PM, Torsten Lodderstedt > wrote: >> +1 >> >> I have asked myself all the time why "oob" disappeared in OAuth 2.0? Doe= s >> Google use this feature? > > Yes, we are planning to support this, exactly as described in the extensi= on. > > Marius > _______________________________________________ > OAuth mailing 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 Jan 27 11:59:32 2011 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 4C2063A6A36 for ; Thu, 27 Jan 2011 11:59:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=1.038, BAYES_00=-2.599, GB_I_LETTER=-2] 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 dvrjPNtnXIq9 for ; Thu, 27 Jan 2011 11:59:29 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3CA353A6980 for ; Thu, 27 Jan 2011 11:59:27 -0800 (PST) Received: (qmail 27172 invoked from network); 27 Jan 2011 20:02:31 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Jan 2011 20:02:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 27 Jan 2011 13:02:27 -0700 From: Eran Hammer-Lahav To: "Richer, Justin P." , Skylar Woodward , Marius Scurtescu Date: Thu, 27 Jan 2011 13:02:07 -0700 Thread-Topic: [OAUTH-WG] Native Client Extension Thread-Index: Acu+EWaVnDOBczSKTMSP/6qN/u5OfQASJH7+AACn/JA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2729@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D239DCF.4030501@lodderstedt.net> , <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension 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, 27 Jan 2011 19:59:32 -0000 I think it should still use the existing 'token' and 'code' values, but wit= h a special redirect_uri value (preferably something like a urn: to make it= clear). This way, there is no need to add a new mechanism for extending pa= rameter *values* (though such an extension *can* update the registration of= the 'response_type' parameter), no need for special rules about the redire= ct_uri parameters, and the urn: can be used to indicate the style of the de= livery (title, custom scheme, etc.). It also allows using both redirection-= based flows. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Richer, Justin P. > Sent: Thursday, January 27, 2011 11:40 AM > To: Skylar Woodward; Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Native Client Extension >=20 > +1 on out of band auth being moved to a more fully-specified extension. I= t > can (and likely should) still use mechanisms such as auth codes, but with > different requirements such as no return URL. This is where things like t= he > code hack can live, as well. >=20 > -- Justin > ________________________________________ > From: oauth-bounces@ietf.org [oauth-bounces@ietf.org] On Behalf Of > Skylar Woodward [skylar@kiva.org] > Sent: Thursday, January 27, 2011 6:00 AM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Native Client Extension >=20 > Marius, >=20 > I support the extension (as per my previous letter, as I missed this thre= ad > over the holidays) and Kiva is/was planning to support this as well. Giv= en the > unpredictable technology environments of many of our customers, this flow > is essential for our implementation. >=20 > However, now reviewing language in draft-12, I wonder if it isn't more cl= ear > to define the extension as using a different response_type (eg, oob_code)= . > In the past, the use of "oob" has been more of hack to work with existing > specs. In truth, it is a unique flow of its own compared to Implict and A= uth > Code as they are currently defined. Such a flow would not accept a > redirect_url and could use "oob_code" for both response_type and > grant_type. >=20 > skylar >=20 >=20 > On Jan 4, 2011, at 11:58 PM, Marius Scurtescu wrote: >=20 > > On Tue, Jan 4, 2011 at 2:23 PM, Torsten Lodderstedt > > wrote: > >> +1 > >> > >> I have asked myself all the time why "oob" disappeared in OAuth 2.0? > >> Does Google use this feature? > > > > Yes, we are planning to support this, exactly as described in the exten= sion. > > > > Marius > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From jricher@mitre.org Thu Jan 27 12:06:23 2011 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 6C7623A6874 for ; Thu, 27 Jan 2011 12:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=-0.773, 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 7xVxxicM0NaR for ; Thu, 27 Jan 2011 12:06:22 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by core3.amsl.com (Postfix) with ESMTP id 74B9F3A684F for ; Thu, 27 Jan 2011 12:06:22 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 96ABD21B071A for ; Thu, 27 Jan 2011 15:09:26 -0500 (EST) Received: from imchub2.MITRE.ORG (imchub2.mitre.org [129.83.29.74]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9243421B0717 for ; Thu, 27 Jan 2011 15:09:26 -0500 (EST) Received: from IMCMBX3.MITRE.ORG ([129.83.29.206]) by imchub2.MITRE.ORG ([129.83.29.74]) with mapi; Thu, 27 Jan 2011 15:09:26 -0500 From: "Richer, Justin P." To: "oauth@ietf.org" Date: Thu, 27 Jan 2011 15:04:44 -0500 Thread-Topic: [OAUTH-WG] Draft -12 feedback deadline Thread-Index: Acu+DiRiftKVyAT6QuensmfJaoXx7AAT0zJV Message-ID: References: <90C41DD21FB7C64BB94121FBBC2E723445A8D6254D@P3PW5EX1MB01.EX1.SECURESERVER.NET> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Draft -12 feedback deadline 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, 27 Jan 2011 20:06:23 -0000 Overall, I much prefer the organization of this document, and I think it's = going to make a lot more sense to implementers. My thoughts, per section: 1.2 "Tokens may be pure capabilities." To a non-security-engineer such as mysel= f, this bit reads very oddly on its own. I understand that "capability" has= another meaning in the security world, so can we either reference that def= inition or give a small prose example, like "capabilities, such as ...".=20 1.3 Should these introductions link down to their implementation sections? Seem= s like a useful xref. 1.3.2, 4.2 I'm not sold on calling this "Implicit", though "user agent" and "direct" a= ren't much better.=20 1.3.2 "round trip" should be "round trips" 1.3.4 Perhaps add something along the lines of "Client credentials are also usefu= l inside of enterprise environments where there is a high degree of trust b= etween applications, or for direct data exchange between systems with no ex= plicit end users." 2. "client identified" should be "client identifier" Should we strengthen the first "SHOULD NOT" to a "MUST NOT", since this is = about assumptions of security made by the AS? This is possibly bikeshedding= as the AS could always still say "We know that the secret-storage security= of some clients might be bad but that's OK."=20 3.2=20 Can we make the token endpoint MUST support POST and MAY support GET? I und= erstand the arguments for favoring POST, but they don't always apply to all= environments. (Brought this up a while ago, seems like it's not a breaking= change to allow.) 4.2 While it doesn't use the full client credentials defined in section 2, it d= oes still use the client identifier. The identifier is usually just one hal= f of the credentialing pair. As the opening paragraph is worded now it's a = bit confusing and makes it sounds like you don't need a client_id parameter= at all (an assumption which is of course contradicted by 4.2.1). 5.2 "parameters are including" should be "parameters are included" [side note: should I revise the XML encoding to have an explicit example fo= r error responses? I would still like to make the XML encoding extension a = WG item and eventual RFC.] 6. I'd like to see a paragraph on redelegation practices, but I'm not sure it = belongs in the core as it's really more of a way of *using* refresh tokens = and scopes in a slightly different way than it is really a *new* thing. All= the mechanisms are there to support it, a recipe just hasn't been written = out for it. Is there desire for an extension doc for this? 8.2 Already talked about relaxing the MUST to SHOULD here under different cover= , as this actually lines up better with text in other sections stating that= the Auth and Token endpoints MAY have query-string parameters which MUST b= e preserved. -- Justin= From eran@hueniverse.com Thu Jan 27 13:39:27 2011 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 B5CA53A69D4 for ; Thu, 27 Jan 2011 13:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.029, 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 r9xRpAo2Ke2e for ; Thu, 27 Jan 2011 13:39:27 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id ECBCD3A689E for ; Thu, 27 Jan 2011 13:39:26 -0800 (PST) Received: (qmail 19966 invoked from network); 27 Jan 2011 21:42:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 27 Jan 2011 21:42:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 27 Jan 2011 14:42:20 -0700 From: Eran Hammer-Lahav To: "'Michael.Jones@microsoft.com'" Date: Thu, 27 Jan 2011 14:42:00 -0700 Thread-Topic: Update required for bearer token spec Thread-Index: Acu+avwIUa4jqg8VSoSmxUSLKyIfiA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB2785P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: [OAUTH-WG] Update required for bearer token spec 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, 27 Jan 2011 21:39:27 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB2785P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please update the draft to comply with -12 registration guidelines and requ= irements asap. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB2785P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please update th= e draft to comply with -12 registration guidelines and requirements asap.

 

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB2785P3PW5EX1MB01E_-- From Michael.Jones@microsoft.com Thu Jan 27 14:06:46 2011 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 C07D93A6A9E for ; Thu, 27 Jan 2011 14:06:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.589 X-Spam-Level: X-Spam-Status: No, score=-10.589 tagged_above=-999 required=5 tests=[AWL=0.009, 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 MkTCF2NA89i8 for ; Thu, 27 Jan 2011 14:06:44 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 120E43A69E0 for ; Thu, 27 Jan 2011 14:06:44 -0800 (PST) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 27 Jan 2011 14:09:48 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.01.0255.003; Thu, 27 Jan 2011 14:09:48 -0800 From: Mike Jones To: Eran Hammer-Lahav Thread-Topic: Update required for bearer token spec Thread-Index: Acu+avwIUa4jqg8VSoSmxUSLKyIfiAAA88Uw Date: Thu, 27 Jan 2011 22:09:47 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246FB43BTK5EX14MBXC202r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Update required for bearer token spec 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, 27 Jan 2011 22:06:46 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246FB43BTK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your request below is ambiguous. Please provide the precise new text you'r= e requesting and the rationale for it. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, January 27, 2011 1:42 PM To: Mike Jones Cc: OAuth WG Subject: Update required for bearer token spec Please update the draft to comply with -12 registration guidelines and requ= irements asap. EHL --_000_4E1F6AAD24975D4BA5B1680429673943246FB43BTK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Your request below is = ambiguous.  Please provide the precise new text you’re requestin= g and the rationale for it.

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, January 27, 2011 1:42 PM
To: Mike Jones
Cc: OAuth WG
Subject: Update required for bearer token spec

 

Please update the draft to comply with -12 registrat= ion guidelines and requirements asap.

 

EHL

--_000_4E1F6AAD24975D4BA5B1680429673943246FB43BTK5EX14MBXC202r_-- From eran@hueniverse.com Thu Jan 27 14:33:13 2011 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 0F9243A69E2 for ; Thu, 27 Jan 2011 14:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.029, 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 SIca8+1pFg3e for ; Thu, 27 Jan 2011 14:33:10 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C97CC3A684C for ; Thu, 27 Jan 2011 14:33:09 -0800 (PST) Received: (qmail 30948 invoked from network); 27 Jan 2011 22:36:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Jan 2011 22:36:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 27 Jan 2011 15:36:01 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Thu, 27 Jan 2011 15:35:41 -0700 Thread-Topic: Update required for bearer token spec Thread-Index: Acu+avwIUa4jqg8VSoSmxUSLKyIfiAAA88UwAADrfZA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0P3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Update required for bearer token spec 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, 27 Jan 2011 22:33:13 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -12 section 8.1 and 10.1. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, January 27, 2011 2:10 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Your request below is ambiguous. Please provide the precise new text you'r= e requesting and the rationale for it. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, January 27, 2011 1:42 PM To: Mike Jones Cc: OAuth WG Subject: Update required for bearer token spec Please update the draft to comply with -12 registration guidelines and requ= irements asap. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

-12 section 8.1 and 10.1.

 

EHL

 

From: Mike Jones [mailto:Michael.Jones= @microsoft.com]
Sent: Thursday, January 27, 2011 2:10 PM
T= o: Eran Hammer-Lahav
Cc: OAuth WG
Subject: RE: Upda= te required for bearer token spec

 

Your request below is ambiguous.  Please provide the precise= new text you’re requesting and the rationale for it.

 <= /span>

From: Eran Hammer-Lahav [mailto:= eran@hueniverse.com]
Sent: Thursday, January 27, 2011 1:42 PMTo: Mike Jones
Cc: OAuth WG
Subject: Update req= uired for bearer token spec

 

Please update the draft to= comply with -12 registration guidelines and requirements asap.<= /p>

 

EHL<= /o:p>

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0P3PW5EX1MB01E_-- From bcampbell@pingidentity.com Thu Jan 27 15:07:47 2011 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 F20B63A6ACF for ; Thu, 27 Jan 2011 15:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 v1Fk96co8s5d for ; Thu, 27 Jan 2011 15:07:46 -0800 (PST) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by core3.amsl.com (Postfix) with ESMTP id C92DE3A6A9E for ; Thu, 27 Jan 2011 15:07:45 -0800 (PST) Received: from source ([209.85.161.45]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTUH7eisLidqL629XjFNou89sblCs66ms@postini.com; Thu, 27 Jan 2011 15:10:50 PST Received: by mail-fx0-f45.google.com with SMTP id 12so2941301fxm.32 for ; Thu, 27 Jan 2011 15:10:50 -0800 (PST) Received: by 10.223.86.12 with SMTP id q12mr975980fal.18.1296169841184; Thu, 27 Jan 2011 15:10:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.9 with HTTP; Thu, 27 Jan 2011 15:09:59 -0800 (PST) From: Brian Campbell Date: Thu, 27 Jan 2011 16:09:59 -0700 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Subject: [OAUTH-WG] some minor editorial stuff on -12 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, 27 Jan 2011 23:07:47 -0000 All in all, I like the new structure of the document. Below are a few editorial nits and questions. http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-1.4 > The diagram has "Access Grant" but it seems like the rest of the draft is now using "authorization grant" as per section 1.3? http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-2 > Should "credentials include a client identified" read "credentials include a client identifier"? http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-3.2 > "The token endpoint requires client authentication as described in Section 2 ." no space before the period? A more general question is that while section 2 clearly allows for unauthenticated client requests to the token endpoint, the text above, if read without consulting section 2, sounds like client authentication is strictly required. There are a few other places in the spec that are similar too. I honestly don't know if that's a problem or not. But I do know from experience that implementers, vendors, customers, etc. will sometimes focus in on a single line like that and not consider the larger context (even if it's directly referenced like it is there). http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-4.1.2.1 > maybe it's just me but some more white-space between parameter definitions would make this section easier on the eyes. Same for 4.2.2.1 & 5.2 http://tools.ietf.org/html/draft-ietf-oauth-v2-12#section-4.1.3 > I think someone might have said this already but the language about redirect_uri here doesn't seem to match up exactly with what is in other sections. I.e. if a redirect_uri wasn't sent in the initial authorization request, what should be sent here? Nothing? The preregistered value? Something else? From eran@hueniverse.com Thu Jan 27 16:22:29 2011 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 DDF303A6AFD for ; Thu, 27 Jan 2011 16:22:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, HTTP_ESCAPED_HOST=0.134] 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 D8hqkg6oRkWs for ; Thu, 27 Jan 2011 16:22:29 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id DAA4C3A6AED for ; Thu, 27 Jan 2011 16:22:25 -0800 (PST) Received: (qmail 8207 invoked from network); 28 Jan 2011 00:24:34 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Jan 2011 00:24:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 27 Jan 2011 17:24:30 -0700 From: Eran Hammer-Lahav To: Peter Saint-Andre , OAuth WG Date: Thu, 27 Jan 2011 17:24:10 -0700 Thread-Topic: [OAUTH-WG] Fwd: [Technical Errata Reported] RFC5849 (2550) Thread-Index: AcuHkQ+gWSYSnMk+Qve09zMEiDkrFA28IR0w Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB27F9@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4CE5E01F.1020207@stpeter.im> In-Reply-To: <4CE5E01F.1020207@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [OAUTH-WG] Fwd: [Technical Errata Reported] RFC5849 (2550) 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, 28 Jan 2011 00:22:30 -0000 VmVyaWZpZWQgYXMgY29ycmVjdC4NCg0KRUhMDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBQZXRlciBTYWludC1BbmRyZQ0KPiBTZW50OiBUaHVy c2RheSwgTm92ZW1iZXIgMTgsIDIwMTAgNjoyNiBQTQ0KPiBUbzogT0F1dGggV0cNCj4gU3ViamVj dDogW09BVVRILVdHXSBGd2Q6IFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM1ODQ5ICgy NTUwKQ0KPiANCj4gRm9sa3MsIGlzIHRoaXMgZXJyYXR1bSBhY2N1cmF0ZT8NCj4gDQo+IA0KPiAt LS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+IFN1YmplY3Q6IFtUZWNobmljYWwg RXJyYXRhIFJlcG9ydGVkXSBSRkM1ODQ5ICgyNTUwKQ0KPiBEYXRlOiBUdWUsIDEyIE9jdCAyMDEw IDA5OjQyOjE3IC0wNzAwIChQRFQpDQo+IEZyb206IFJGQyBFcnJhdGEgU3lzdGVtIDxyZmMtZWRp dG9yQHJmYy1lZGl0b3Iub3JnPg0KPiBUbzogZXJhbkBodWVuaXZlcnNlLmNvbSwgaWVzZ0BpZXNn Lm9yZw0KPiBDQzogYWxhc2RhaXJAbG92ZWZpbG0uY29tLCByZmMtZWRpdG9yQHJmYy1lZGl0b3Iu b3JnDQo+IA0KPiANCj4gVGhlIGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1p dHRlZCBmb3IgUkZDNTg0OSwgIlRoZSBPQXV0aCAxLjANCj4gUHJvdG9jb2wiLg0KPiANCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWW91IG1heSByZXZpZXcgdGhl IHJlcG9ydCBiZWxvdyBhbmQgYXQ6DQo+IGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRh X3NlYXJjaC5waHA/cmZjPTU4NDkmZWlkPTI1NTANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IFR5cGU6IFRlY2huaWNhbA0KPiBSZXBvcnRlZCBieTogQWxh c2RhaXIgTWNJbnR5cmUgPGFsYXNkYWlyQGxvdmVmaWxtLmNvbT4NCj4gDQo+IFNlY3Rpb246IEdM T0JBTA0KPiANCj4gT3JpZ2luYWwgVGV4dA0KPiAtLS0tLS0tLS0tLS0tDQo+IFNlY3Rpb24gMy4x DQo+IG9hdXRoX3NpZ25hdHVyZT0iYllUNUNNc0djYmdVZEZIT2JZTUVmY3g2YnN3JTNEIg0KPiAN Cj4gU2VjdGlvbiAzLjQuMS4xDQo+IG9hdXRoX3NpZ25hdHVyZT0iYllUNUNNc0djYmdVZEZIT2JZ TUVmY3g2YnN3JTNEIg0KPiANCj4gU2VjdGlvbiAzLjQuMS4zLjENCj4gb2F1dGhfc2lnbmF0dXJl PSJkam9zSktES0pTRDg3NDMyNDMlMkZqZGszM2tsWSUzRCINCj4gDQo+IA0KPiANCj4gQ29ycmVj dGVkIFRleHQNCj4gLS0tLS0tLS0tLS0tLS0NCj4gU2VjdGlvbiAzLjENCj4gb2F1dGhfc2lnbmF0 dXJlPSJyNiUyRlRKamJDT3I5NyUyRiUyQlVVME5zdlNuZTdzNWclM0QiDQo+IA0KPiBTZWN0aW9u IDMuNC4xLjENCj4gb2F1dGhfc2lnbmF0dXJlPSJyNiUyRlRKamJDT3I5NyUyRiUyQlVVME5zdlNu ZTdzNWclM0QiDQo+IA0KPiBTZWN0aW9uIDMuNC4xLjMuMQ0KPiBvYXV0aF9zaWduYXR1cmU9InI2 JTJGVEpqYkNPcjk3JTJGJTJCVVUwTnN2U25lN3M1ZyUzRCINCj4gDQo+IA0KPiBOb3Rlcw0KPiAt LS0tLQ0KPiAoQXBvbG9naWVzIC0gdGhpcyBzdXBlcmNlZGVzIEVycmF0YSBJRCAyNTQ5KS4NCj4g DQo+IFRoZSBzaWduYXR1cmVzIGluIHNlY3Rpb25zIDMuMSwgMy40LjEuMSwgYW5kIDMuNC4xLjMu MSBvZiB0aGUgUkZDIGhhdmUNCj4gbWlzdGFrZW5seSBiZWVuIGNhbGN1bGF0ZWQgYXMgaWYgd2l0 aCAiR0VUIi4gSSBoYXZlIHN1cHBsaWVkIHRoZSBjb3JyZWN0DQo+ICJQT1NUIiBzaWduYXR1cmVz IGluIHRoZSBjb3JyZWN0ZWQgdGV4dC4NCj4gDQo+IEZvciByZWZlcmVuY2UsIGhlcmUgaXMgdGhl IHBlcmwgc2NyaXB0IEkgdXNlZCB0byBjYWxjdWxhdGUgdGhlIHNpZ25hdHVyZXM6DQo+IA0KPiAj IS91c3IvYmluL3BlcmwNCj4gdXNlIHN0cmljdDsNCj4gdXNlIHdhcm5pbmdzOw0KPiB1c2UgRGln ZXN0OjpITUFDX1NIQTE7DQo+IHVzZSBVUkk6OkVzY2FwZTsNCj4gdXNlIE1JTUU6OkJhc2U2NDsN Cj4gDQo+IG15ICR1bnNhZmUgPSAnXi0uX35BLVphLXowLTknOw0KPiBteSAkY2xpZW50X3NlY3Jl dCA9ICdqNDlzazNqMjlkamQnOw0KPiBteSAkdG9rZW5fc2VjcmV0ID0gJ2RoODkzaGRhc2loOSc7 DQo+IG15ICRrZXkgPSBqb2luKCcmJywgJGNsaWVudF9zZWNyZXQsICR0b2tlbl9zZWNyZXQpOw0K PiANCj4gbXkgJHVyaV9iYXNlID0gJ2h0dHAlM0ElMkYlMkZleGFtcGxlLmNvbSUyRnJlcXVlc3Qn Ow0KPiBteSAkcGFyYW1zID0gam9pbignJywgcXcoDQo+ICAgICBhMiUzRHIlMjUyMGIlMjZhMyUz RDIlMjUyMHElMjZhMyUzRGElMjZiNSUzRA0KPiAgICAgJTI1M0QlMjUyNTNEJTI2YyUyNTQwJTNE JTI2YzIlM0QlMjZvYXV0aF9jb24NCj4gICAgIHN1bWVyX2tleSUzRDlkamRqODJoNDhkanM5ZDIl MjZvYXV0aF9ub25jZSUzDQo+ICAgICBEN2Q4ZjNlNGElMjZvYXV0aF9zaWduYXR1cmVfbWV0aG9k JTNESE1BQy1TSA0KPiAgICAgQTElMjZvYXV0aF90aW1lc3RhbXAlM0QxMzcxMzEyMDElMjZvYXV0 aF90b2sNCj4gICAgIGVuJTNEa2trOWQ3ZGgzazM5c2p2Nw0KPiApKTsNCj4gDQo+IGZvcmVhY2gg bXkgJG1ldGhvZCAoJ0dFVCcsICdQT1NUJykgew0KPiAgICAgbXkgJGJhc2Vfc2lnID0gam9pbign JicsICRtZXRob2QsICR1cmlfYmFzZSwgJHBhcmFtcyk7DQo+ICAgICBteSAkYmluX3NpZyA9IERp Z2VzdDo6SE1BQ19TSEExOjpobWFjX3NoYTEoJGJhc2Vfc2lnLCAka2V5KTsNCj4gICAgIG15ICRi NjRfc2lnID0gTUlNRTo6QmFzZTY0OjplbmNvZGVfYmFzZTY0KCRiaW5fc2lnLCAnJyk7DQo+ICAg ICBteSAkZW5jX3NpZyA9IFVSSTo6RXNjYXBlOjp1cmlfZXNjYXBlKCRiNjRfc2lnLCAkdW5zYWZl KTsNCj4gICAgIHByaW50ZiAiJS04cyAlc1xuIiwgJG1ldGhvZCwgJGVuY19zaWc7IH0NCj4gDQo+ IEluc3RydWN0aW9uczoNCj4gLS0tLS0tLS0tLS0tLQ0KPiBUaGlzIGVycmF0YSBpcyBjdXJyZW50 bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElmIG5lY2Vzc2FyeSwgcGxlYXNlIHVzZSAiUmVwbHkN Cj4gQWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yIHJlamVj dGVkLiBXaGVuIGEgZGVjaXNpb24gaXMNCj4gcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAo SUVTRykgY2FuIGxvZyBpbiB0byBjaGFuZ2UgdGhlIHN0YXR1cyBhbmQgZWRpdA0KPiB0aGUgcmVw b3J0LCBpZiBuZWNlc3NhcnkuDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiBSRkM1ODQ5IChkcmFmdC1oYW1tZXItb2F1dGgtMTApDQo+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFRpdGxlICAgICAgICAgICAgICAgOiBUaGUg T0F1dGggMS4wIFByb3RvY29sDQo+IFB1YmxpY2F0aW9uIERhdGUgICAgOiBBcHJpbCAyMDEwDQo+ IEF1dGhvcihzKSAgICAgICAgICAgOiBFLiBIYW1tZXItTGFoYXYsIEVkLg0KPiBDYXRlZ29yeSAg ICAgICAgICAgIDogSU5GT1JNQVRJT05BTA0KPiBTb3VyY2UgICAgICAgICAgICAgIDogSUVURiAt IE5PTiBXT1JLSU5HIEdST1VQDQo+IEFyZWEgICAgICAgICAgICAgICAgOiBOL0ENCj4gU3RyZWFt ICAgICAgICAgICAgICA6IElFVEYNCj4gVmVyaWZ5aW5nIFBhcnR5ICAgICA6IElFU0cNCg0K From mscurtescu@google.com Thu Jan 27 16:41:59 2011 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 8AF673A6A0A for ; Thu, 27 Jan 2011 16:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.004 X-Spam-Level: X-Spam-Status: No, score=-105.004 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1, 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 9T0OqHwMF9mI for ; Thu, 27 Jan 2011 16:41:58 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 7753B3A6A08 for ; Thu, 27 Jan 2011 16:41:58 -0800 (PST) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p0S0j2xB012539 for ; Thu, 27 Jan 2011 16:45:02 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296175502; bh=Mh7K1o8Rp+WgmOXP3SDvju6o28k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=SYPVLYMKjcHCfjAASyevBu+yL/LXb7fZKvrCJgylEliMLWzlYc6xM4+qd5me0n6+i mun7Mt+L1gVYQY+6MVpOA== Received: from gxk10 (gxk10.prod.google.com [10.202.11.10]) by wpaz13.hot.corp.google.com with ESMTP id p0S0j0Ip007865 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 27 Jan 2011 16:45:00 -0800 Received: by gxk10 with SMTP id 10so976174gxk.12 for ; Thu, 27 Jan 2011 16:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=ghFEH+AA4lFgLkkz2zgHrNLnTgHA/jo9zwr/2zKo6BY=; b=Om8Lhd6nvSwpoge5Y1D+XeeS2tsR3r1rr9VTS0pyDJWtuSUO6XC3tpoJoLlVtuv2s1 Uz7TiVm1dtWfGhu5TaFQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=d0i1i0NszCc+HyGdmuy6SUZNKxhENKt3vs/PVsCso01WFGD3y7renRI09D4Q1Vuh6t de/BkRDfuXHgbfw9jTjg== Received: by 10.100.164.2 with SMTP id m2mr1094770ane.146.1296175500096; Thu, 27 Jan 2011 16:45:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Thu, 27 Jan 2011 16:44:39 -0800 (PST) In-Reply-To: <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> From: Marius Scurtescu Date: Thu, 27 Jan 2011 16:44:39 -0800 Message-ID: To: Skylar Woodward 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] Native Client Extension 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, 28 Jan 2011 00:41:59 -0000 On Thu, Jan 27, 2011 at 3:00 AM, Skylar Woodward wrote: > Marius, > > I support the extension (as per my previous letter, as I missed this thre= ad over the holidays) and Kiva is/was planning to support this as well. =A0= Given the unpredictable technology environments of many of our customers, t= his flow is essential for our implementation. > > However, now reviewing language in draft-12, I wonder if it isn't more cl= ear to define the extension as using a different response_type (eg, oob_cod= e). =A0In the past, the use of "oob" has been more of hack to work with exi= sting specs. In truth, it is a unique flow of its own compared to Implict a= nd Auth Code as they are currently defined. =A0Such a flow would not accept= a redirect_url and could use "oob_code" for both response_type and grant_t= ype. I still think that "oob" applies only to the mechanism to return a result, and not to the whole flow. Theoretically redirect_uri=3Doob should work with both response_type=3Dcode and response_type=3Dtoken, but I had in mind only code. Also, I don't see a reason to do anything special with the grant_type, once the client has an authorization code it is all the same. Marius From Michael.Jones@microsoft.com Thu Jan 27 17:12:26 2011 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 DB1CE3A6AD6 for ; Thu, 27 Jan 2011 17:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.589 X-Spam-Level: X-Spam-Status: No, score=-10.589 tagged_above=-999 required=5 tests=[AWL=0.009, 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 vCo1eKYNy0PJ for ; Thu, 27 Jan 2011 17:12:23 -0800 (PST) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id 902CA3A6A04 for ; Thu, 27 Jan 2011 17:12:23 -0800 (PST) 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, 27 Jan 2011 17:15:28 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0255.003; Thu, 27 Jan 2011 17:15:27 -0800 From: Mike Jones To: Eran Hammer-Lahav Thread-Topic: Update required for bearer token spec Thread-Index: Acu+avwIUa4jqg8VSoSmxUSLKyIfiAAA88UwAADrfZAABY/aAA== Date: Fri, 28 Jan 2011 01:15:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246FBB0C@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246FBB0CTK5EX14MBXC202r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Update required for bearer token spec 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, 28 Jan 2011 01:12:27 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246FBB0CTK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Once approved, the existing names will be registered, hence no changes are = needed to the bearer token draft to comply with these requirements. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, January 27, 2011 2:36 PM To: Mike Jones Cc: OAuth WG Subject: RE: Update required for bearer token spec -12 section 8.1 and 10.1. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, January 27, 2011 2:10 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Your request below is ambiguous. Please provide the precise new text you'r= e requesting and the rationale for it. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, January 27, 2011 1:42 PM To: Mike Jones Cc: OAuth WG Subject: Update required for bearer token spec Please update the draft to comply with -12 registration guidelines and requ= irements asap. EHL --_000_4E1F6AAD24975D4BA5B1680429673943246FBB0CTK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Once approved, the exi= sting names will be registered, hence no changes are needed to the bearer t= oken draft to comply with these requirements.

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, January 27, 2011 2:36 PM
To: Mike Jones
Cc: OAuth WG
Subject: RE: Update required for bearer token spec=

 

-12 section 8.1 and 10= .1.

 

EHL<= /p>

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, January 27, 2011 2:10 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: RE: Update required for bearer token spec=

 

Your request below is = ambiguous.  Please provide the precise new text you’re requestin= g and the rationale for it.

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, January 27, 2011 1:42 PM
To: Mike Jones
Cc: OAuth WG
Subject: Update required for bearer token spec

 

Please update the draft to comply with -12 registrat= ion guidelines and requirements asap.

 

EHL

--_000_4E1F6AAD24975D4BA5B1680429673943246FBB0CTK5EX14MBXC202r_-- From eran@hueniverse.com Thu Jan 27 18:20:58 2011 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 E2D783A6B6E for ; Thu, 27 Jan 2011 18:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.029, 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 BVKulyaYRw+R for ; Thu, 27 Jan 2011 18:20:49 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 8EBB73A68B8 for ; Thu, 27 Jan 2011 18:20:49 -0800 (PST) Received: (qmail 16939 invoked from network); 28 Jan 2011 02:23:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Jan 2011 02:23:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 27 Jan 2011 19:23:53 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Thu, 27 Jan 2011 19:23:33 -0700 Thread-Topic: Update required for bearer token spec Thread-Index: Acu+avwIUa4jqg8VSoSmxUSLKyIfiAAA88UwAADrfZAABY/aAAABdGzQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FBB0C@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246FBB0C@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB281BP3PW5EX1MB01E_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Update required for bearer token spec 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, 28 Jan 2011 02:20:58 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB281BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The bearer draft must include the registration template as done in draft-ha= mmer-oauth-v2-mac-token section 8 including giving the name used for issuin= g such tokens for the token_type parameter. Every RFC must include an IANA = Considerations section and your is currently in violation of -12. If you ha= ve an issue with the registration process or language in -12, the appropria= te thing to do is to raise those issues on the list. I will remove the bearer token examples from -13 due to my objections to th= e 'OAuth2' scheme name (which makes it an open issue) and lack of registrat= ion and token type name in the bearer token draft. I will gladly put those = examples back (as they are listed in -12) once these concerns are resolved = (or if instructed to by the chairs and area director). I will keep the info= rmative reference in -13, and will only remove the examples which are incor= rect. --- As for the open issues: the bearer token scheme name - if it wasn't clear, = I plan to use every mean available to me to block the bearer token draft fr= om using the 'OAuth2' scheme name, and will raise this issue in the WGLC, A= rea Director review, IETF LC, and direct appeal to the IESG if necessary. Y= ou might consider this childish, but I consider bearer tokens a disaster w= aiting to happen and will not allow the weakest form of token authenticatio= n to carry the strongest form of endorsement and perception (via the OAuth = brand). At the end, you might get the scheme name you want, but it will cost you si= gnificant delays in getting that document published as an RFC and with a Pr= oposed Standard designation. So far you have failed to raise any technical = justification for your insistence of using that name. The only reason so fa= r is that it will be less confusing. Perhaps. But will be more damaging. Af= ter all, why would anyone look at the MAC token specification or other stro= nger authentication schemes, when you offer them the "official" OAuth 2.0 s= cheme. I also want to point out that I am not the only one here who made this requ= est. I consent that there isn't consensus to changing the name, but there i= sn't consensus to keeping it either. The "vote" is around 2-4 on each side. If you are willing to spend the next few months arguing over 6 characters i= n your document, I will gladly oblige. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, January 27, 2011 5:15 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Once approved, the existing names will be registered, hence no changes are = needed to the bearer token draft to comply with these requirements. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, January 27, 2011 2:36 PM To: Mike Jones Cc: OAuth WG Subject: RE: Update required for bearer token spec -12 section 8.1 and 10.1. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, January 27, 2011 2:10 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Your request below is ambiguous. Please provide the precise new text you'r= e requesting and the rationale for it. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, January 27, 2011 1:42 PM To: Mike Jones Cc: OAuth WG Subject: Update required for bearer token spec Please update the draft to comply with -12 registration guidelines and requ= irements asap. EHL --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB281BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The bearer draft must include the registration template as do= ne in draft-hammer-oauth-v2-mac-token section 8 including giving the name u= sed for issuing such tokens for the token_type parameter. Every RFC must in= clude an IANA Considerations section and your is currently in violation of = -12. If you have an issue with the registration process or language in -12,= the appropriate thing to do is to raise those issues on the list.

 =

I will = remove the bearer token examples from -13 due to my objections to the ̵= 6;OAuth2’ scheme name (which makes it an open issue) and lack of regi= stration and token type name in the bearer token draft. I will gladly put t= hose examples back (as they are listed in -12) once these concerns are reso= lved (or if instructed to by the chairs and area director). I will keep the= informative reference in -13, and will only remove the examples which are = incorrect.

 

---

 

As for the open issues: the bearer token scheme name - i= f it wasn’t clear, I plan to use every mean available to me to block = the bearer token draft from using the ‘OAuth2’ scheme name, and= will raise this issue in the WGLC, Area Director review, IETF LC, and dire= ct appeal to the IESG if necessary. You might consider this childish, but I= consider  bearer tokens a disaster waiting to happen and will not all= ow the weakest form of token authentication to carry the strongest form of = endorsement and perception (via the OAuth brand).

 

=

At the end, you might ge= t the scheme name you want, but it will cost you significant delays in gett= ing that document published as an RFC and with a Proposed Standard designat= ion. So far you have failed to raise any technical justification for your i= nsistence of using that name. The only reason so far is that it will be les= s confusing. Perhaps. But will be more damaging. After all, why would anyon= e look at the MAC token specification or other stronger authentication sche= mes, when you offer them the “official” OAuth 2.0 scheme.<= /o:p>

&nb= sp;

I al= so want to point out that I am not the only one here who made this request.= I consent that there isn’t consensus to changing the name, but there= isn’t consensus to keeping it either. The “vote” is arou= nd 2-4 on each side.

 

If you are willing to spend the next few months argu= ing over 6 characters in your document, I will gladly oblige.

 

EHL

 =

&n= bsp;

 

From:<= /b> Mike= Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, Janu= ary 27, 2011 5:15 PM
To: Eran Hammer-Lahav
Cc: OAuth WG=
Subject: RE: Update required for bearer token spec

 

Once approved, the existing names wil= l be registered, hence no changes are needed to the bearer token draft to c= omply with these requirements.

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
S= ent: Thursday, January 27, 2011 2:36 PM
To: Mike Jones
= Cc: OAuth WG
Subject: RE: Update required for bearer token sp= ec

 <= /p>

-12 section 8.1 and 1= 0.1.

 

EHL

 

Fro= m: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thur= sday, January 27, 2011 2:10 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: RE: Update required for bearer token spec

 

Your request below is ambig= uous.  Please provide the precise new text you’re requesting and= the rationale for it.

 

From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
Sent:= Thursday, January 27, 2011 1:42 PM
To: Mike Jones
Cc: = OAuth WG
Subject: Update required for bearer token spec

 

Please update the draft to comply with -12 registration guidel= ines and requirements asap.

 <= /o:p>

EHL

= --_000_90C41DD21FB7C64BB94121FBBC2E723445A8FB281BP3PW5EX1MB01E_-- From skylar@kiva.org Fri Jan 28 04:06:20 2011 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 99CC23A67F9 for ; Fri, 28 Jan 2011 04:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.606 X-Spam-Level: X-Spam-Status: No, score=-3.606 tagged_above=-999 required=5 tests=[AWL=0.993, BAYES_00=-2.599, GB_I_LETTER=-2] 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 cGgX2EBuSfpm for ; Fri, 28 Jan 2011 04:06:19 -0800 (PST) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by core3.amsl.com (Postfix) with SMTP id 374B63A63EB for ; Fri, 28 Jan 2011 04:06:16 -0800 (PST) Received: from source ([209.85.214.48]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKTUKx8nCsUPLj73/bEzmXePi50UCu2TEI@postini.com; Fri, 28 Jan 2011 04:09:23 PST Received: by bwz8 with SMTP id 8so3471022bwz.7 for ; Fri, 28 Jan 2011 04:09:21 -0800 (PST) Received: by 10.204.113.9 with SMTP id y9mr2285118bkp.201.1296216561214; Fri, 28 Jan 2011 04:09:21 -0800 (PST) Received: from [10.0.1.4] (dan75-7-88-166-184-189.fbx.proxad.net [88.166.184.189]) by mx.google.com with ESMTPS id f20sm8661535bkf.16.2011.01.28.04.09.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 28 Jan 2011 04:09:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Skylar Woodward In-Reply-To: Date: Fri, 28 Jan 2011 13:09:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> To: Marius Scurtescu X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension 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, 28 Jan 2011 12:06:20 -0000 I agree in terms of simplicity, but the language in 4.1 and in the = definition of redirect_url conflicts with group consensus. So it seems a = single exception should be called out for the case where = redirect_url=3Doob (or some compliant absolute url like x-oauth-oob:), = or there should be an extension defined that makes this exceptional case = clearly defined to co-exist with the core language of MUST, REQUIRED, = and absolute. On Jan 28, 2011, at 1:44 AM, Marius Scurtescu wrote: > On Thu, Jan 27, 2011 at 3:00 AM, Skylar Woodward = wrote: >> Marius, >>=20 >> I support the extension (as per my previous letter, as I missed this = thread over the holidays) and Kiva is/was planning to support this as = well. Given the unpredictable technology environments of many of our = customers, this flow is essential for our implementation. >>=20 >> However, now reviewing language in draft-12, I wonder if it isn't = more clear to define the extension as using a different response_type = (eg, oob_code). In the past, the use of "oob" has been more of hack to = work with existing specs. In truth, it is a unique flow of its own = compared to Implict and Auth Code as they are currently defined. Such a = flow would not accept a redirect_url and could use "oob_code" for both = response_type and grant_type. >=20 > I still think that "oob" applies only to the mechanism to return a > result, and not to the whole flow. Theoretically redirect_uri=3Doob > should work with both response_type=3Dcode and response_type=3Dtoken, = but > I had in mind only code. >=20 > Also, I don't see a reason to do anything special with the grant_type, > once the client has an authorization code it is all the same. >=20 > Marius From eran@hueniverse.com Fri Jan 28 08:19:18 2011 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 441353A68C0 for ; Fri, 28 Jan 2011 08:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.569 X-Spam-Level: X-Spam-Status: No, score=-3.569 tagged_above=-999 required=5 tests=[AWL=1.030, BAYES_00=-2.599, GB_I_LETTER=-2] 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 BevK0tUs8ptz for ; Fri, 28 Jan 2011 08:19:16 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 35F043A67C3 for ; Fri, 28 Jan 2011 08:19:15 -0800 (PST) Received: (qmail 16405 invoked from network); 28 Jan 2011 16:22:21 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jan 2011 16:22:21 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 28 Jan 2011 09:22:04 -0700 From: Eran Hammer-Lahav To: Skylar Woodward , Marius Scurtescu Date: Fri, 28 Jan 2011 09:21:43 -0700 Thread-Topic: [OAUTH-WG] Native Client Extension Thread-Index: Acu+5D2S3yVKVs7vTfi0ULDrHbNKwwAIwcJQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB28DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> In-Reply-To: <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension 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, 28 Jan 2011 16:19:18 -0000 Why not: urn:ietf:wg:oauth:2.0:oob Can you can add more flavors for different ways of floating the token/code = up to the application. This requires no changes at all to -12 to allow this= special case. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Skylar Woodward > Sent: Friday, January 28, 2011 4:09 AM > To: Marius Scurtescu > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Native Client Extension >=20 > I agree in terms of simplicity, but the language in 4.1 and in the defini= tion of > redirect_url conflicts with group consensus. So it seems a single excepti= on > should be called out for the case where redirect_url=3Doob (or some compl= iant > absolute url like x-oauth-oob:), or there should be an extension defined = that > makes this exceptional case clearly defined to co-exist with the core > language of MUST, REQUIRED, and absolute. >=20 > On Jan 28, 2011, at 1:44 AM, Marius Scurtescu wrote: >=20 > > On Thu, Jan 27, 2011 at 3:00 AM, Skylar Woodward > wrote: > >> Marius, > >> > >> I support the extension (as per my previous letter, as I missed this t= hread > over the holidays) and Kiva is/was planning to support this as well. Giv= en the > unpredictable technology environments of many of our customers, this flow > is essential for our implementation. > >> > >> However, now reviewing language in draft-12, I wonder if it isn't more > clear to define the extension as using a different response_type (eg, > oob_code). In the past, the use of "oob" has been more of hack to work > with existing specs. In truth, it is a unique flow of its own compared to= Implict > and Auth Code as they are currently defined. Such a flow would not accep= t a > redirect_url and could use "oob_code" for both response_type and > grant_type. > > > > I still think that "oob" applies only to the mechanism to return a > > result, and not to the whole flow. Theoretically redirect_uri=3Doob > > should work with both response_type=3Dcode and response_type=3Dtoken, > but > > I had in mind only code. > > > > Also, I don't see a reason to do anything special with the grant_type, > > once the client has an authorization code it is all the same. > > > > Marius >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From Internet-Drafts@ietf.org Fri Jan 28 09:00:02 2011 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 7FB7E3A6904; Fri, 28 Jan 2011 09:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, 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 tKCDMyXTALux; Fri, 28 Jan 2011 09:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 925963A67AE; Fri, 28 Jan 2011 09:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110128170001.11388.18114.idtracker@localhost> Date: Fri, 28 Jan 2011 09:00:01 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-saml2-bearer-01.txt 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, 28 Jan 2011 17:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : SAML 2.0 Bearer Assertion Grant Type Profile for OAuth 2.0 Author(s) : B. Campbell, C. Mortimore Filename : draft-ietf-oauth-saml2-bearer-01.txt Pages : 12 Date : 2011-01-28 This specification defines the use of a SAML 2.0 bearer Assertion as means for requesting an OAuth 2.0 access token. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-saml2-bearer-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-28085211.I-D@ietf.org> --NextPart-- From bcampbell@pingidentity.com Fri Jan 28 09:20:26 2011 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 1D25E3A68E9 for ; Fri, 28 Jan 2011 09:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.741 X-Spam-Level: X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Yq30CnKvJeKB for ; Fri, 28 Jan 2011 09:20:24 -0800 (PST) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with ESMTP id 255D33A68D2 for ; Fri, 28 Jan 2011 09:20:23 -0800 (PST) Received: from source ([209.85.215.46]) (using TLSv1) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTUL7kjkbWRu6q2sSCM4YJJ2k0wbRvkGP@postini.com; Fri, 28 Jan 2011 09:23:31 PST Received: by mail-ew0-f46.google.com with SMTP id 5so1652285ewy.19 for ; Fri, 28 Jan 2011 09:23:30 -0800 (PST) Received: by 10.223.93.139 with SMTP id v11mr2573172fam.132.1296235375313; Fri, 28 Jan 2011 09:22:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.9 with HTTP; Fri, 28 Jan 2011 09:22:25 -0800 (PST) In-Reply-To: <20110128170001.11388.18114.idtracker@localhost> References: <20110128170001.11388.18114.idtracker@localhost> From: Brian Campbell Date: Fri, 28 Jan 2011 10:22:25 -0700 Message-ID: To: oauth Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [OAUTH-WG] Fwd: I-D Action:draft-ietf-oauth-saml2-bearer-01.txt 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, 28 Jan 2011 17:20:26 -0000 FYI on a new SAML/OAuth draft. Mostly minor changes (copied from appendix below) to align better with draft-ietf-oauth-v2-12 As always, feedback is welcome. Thx, Brian http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-01 (hopefully up s= oon) or the less pretty version http://www.ietf.org/id/draft-ietf-oauth-saml2-bearer-01.txt draft-ietf-oauth-saml2-bearer-01 o Update spec name when referencing draft-ietf-oauth-v2 (The OAuth 2.0 Protocol Framework -> The OAuth 2.0 Authorization Protocol) o Update wording in Introduction to talk about extension grant types rather than the assertion grant type which is a term no longer used in OAuth 2.0 o Updated to reference draft-ietf-oauth-v2-12 and denote as work in progress o Update Parameter Registration Request to use similar terms as draft-ietf-oauth-v2-12 and remove Related information part o Add some text giving discretion to AS on rejecting assertions with unreasonably long validity window. ---------- Forwarded message ---------- From: Date: Fri, Jan 28, 2011 at 10:00 AM Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-saml2-bearer-01.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : SAML 2.0 Bearer Assertion Grant = Type Profile for OAuth 2.0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : B. Campbell, C. Mortimore =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-oauth-saml2-bearer-01.t= xt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 12 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-01-28 This specification defines the use of a SAML 2.0 bearer Assertion as means for requesting an OAuth 2.0 access token. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Fri Jan 28 10:04:23 2011 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 8E3503A68E3 for ; Fri, 28 Jan 2011 10:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.82 X-Spam-Level: X-Spam-Status: No, score=-105.82 tagged_above=-999 required=5 tests=[AWL=0.157, 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 25JoE4g-hC9c for ; Fri, 28 Jan 2011 10:04:22 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id A6C183A681A for ; Fri, 28 Jan 2011 10:04:22 -0800 (PST) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p0SI7TXC027877 for ; Fri, 28 Jan 2011 10:07:29 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296238049; bh=ckmwEdeYnsUVvJ9xXRjFIbUnrLw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wSCn1govVepOV1gj1CSpdEbmSA8CE1NqWVIo3oo+I/rgG+agsQ0j5TbijNFs6LPsL e1NXLYRe5xaE5jeahhrag== Received: from ywf7 (ywf7.prod.google.com [10.192.6.7]) by wpaz1.hot.corp.google.com with ESMTP id p0SI7Rci030251 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 28 Jan 2011 10:07:28 -0800 Received: by ywf7 with SMTP id 7so1804813ywf.22 for ; Fri, 28 Jan 2011 10:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IqwjfzkCJQk2/U/xZDrwwhu8cZ0DGN7V1iaGK2VpVps=; b=xpm2kqjGob1fpGfLmdo0mJQBhunyH2OKVguYm9S6agsoNFuwxeT33crUmUkQod16NZ pAhrf8up6I+bUGfGAmrA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=CYe6EKP8sM1fySEdUAyR89yxrc+nPCYHmlCetaw5I8B32EXURmt6ytgY5Zktt3TvN2 fCgNKp9k7BIoJEXRqr4g== Received: by 10.100.96.13 with SMTP id t13mr1794410anb.112.1296238047324; Fri, 28 Jan 2011 10:07:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Fri, 28 Jan 2011 10:07:07 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB28DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8FB28DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Fri, 28 Jan 2011 10:07:07 -0800 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] Native Client Extension 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, 28 Jan 2011 18:04:23 -0000 On Fri, Jan 28, 2011 at 8:21 AM, Eran Hammer-Lahav wrote: > Why not: > > urn:ietf:wg:oauth:2.0:oob > > Can you can add more flavors for different ways of floating the token/code up to the application. This requires no changes at all to -12 to allow this special case. Using the simpler "oob" does require changes to the core spec? Why? Marius From eran@hueniverse.com Fri Jan 28 10:23:14 2011 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 4A42E3A68CF for ; Fri, 28 Jan 2011 10:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 3Io1C0kfX1Wm for ; Fri, 28 Jan 2011 10:23:13 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 7B19A3A67D1 for ; Fri, 28 Jan 2011 10:23:13 -0800 (PST) Received: (qmail 29926 invoked from network); 28 Jan 2011 18:26:19 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jan 2011 18:26:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 28 Jan 2011 11:26:10 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Fri, 28 Jan 2011 11:25:50 -0700 Thread-Topic: [OAUTH-WG] Native Client Extension Thread-Index: Acu/FjqTBoKVx7MaTw2hFkxJ9YCgVQAAnKJg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB297E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8FB28DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension 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, 28 Jan 2011 18:23:14 -0000 -12 3.1.1: The redirection URI MUST be an absolute URI and MAY include a query component, which MUST be retained by the authorization server when adding additional query parameters. 'oob' is not an absolute URI. EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Friday, January 28, 2011 10:07 AM > To: Eran Hammer-Lahav > Cc: Skylar Woodward; OAuth WG > Subject: Re: [OAUTH-WG] Native Client Extension >=20 > On Fri, Jan 28, 2011 at 8:21 AM, Eran Hammer-Lahav > wrote: > > Why not: > > > > urn:ietf:wg:oauth:2.0:oob > > > > Can you can add more flavors for different ways of floating the token/c= ode > up to the application. This requires no changes at all to -12 to allow th= is > special case. >=20 > Using the simpler "oob" does require changes to the core spec? Why? >=20 > Marius From mscurtescu@google.com Fri Jan 28 11:28:22 2011 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 9480D3A6953 for ; Fri, 28 Jan 2011 11:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.827 X-Spam-Level: X-Spam-Status: No, score=-105.827 tagged_above=-999 required=5 tests=[AWL=0.150, 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 wi9gVU+esE-O for ; Fri, 28 Jan 2011 11:28:21 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id BC2163A68BD for ; Fri, 28 Jan 2011 11:28:21 -0800 (PST) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p0SJVRW6025832 for ; Fri, 28 Jan 2011 11:31:28 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296243088; bh=Fq0drzaqhj8/r5Be9IroQmn458k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=DmrrqO3IU89PEgJJgW7M8F5x3NoOvxWalDR46v63buG27wT4Nl4Jah/g8zs46Jsug g92ie8aOgmzudmAKqARlQ== Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by hpaq11.eem.corp.google.com with ESMTP id p0SJVPt3015827 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 28 Jan 2011 11:31:26 -0800 Received: by yib12 with SMTP id 12so1220892yib.10 for ; Fri, 28 Jan 2011 11:31:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=n8ZsVaY4JXgt4XA2VFRwVpW3Wiz3GaEEgVZQSV0ka78=; b=Ec5DIYIGzpL+LPgS4winS4pEc9TMj3H1n9GlybA4QjRbbdFzyGSVDpRy7aaw0Gyxi0 07KG7y+SXvGY5Kp5S3ug== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=iSZeYPEACXSHpHNt/Uu8ygd1sdmpY9K/ZgsNmyq5WJVbRWPjmu7TuaIRRmjJTOhoju T917NNRFy5YthQP3Srrw== Received: by 10.100.96.13 with SMTP id t13mr1849574anb.112.1296242714622; Fri, 28 Jan 2011 11:25:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Fri, 28 Jan 2011 11:24:54 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB297E@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8FB28DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB297E@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Fri, 28 Jan 2011 11:24:54 -0800 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] Native Client Extension 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, 28 Jan 2011 19:28:22 -0000 On Fri, Jan 28, 2011 at 10:25 AM, Eran Hammer-Lahav w= rote: > -12 3.1.1: > > =A0 The redirection URI MUST be an absolute URI and MAY include a query > =A0 component, which MUST be retained by the authorization server when > =A0 adding additional query parameters. > > 'oob' is not an absolute URI. Good point, I missed the absolute part. Thanks for pointing this out. Let me think about it, the URN you suggested is a good start. Marius From eran@hueniverse.com Fri Jan 28 11:31:36 2011 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 D579D3A6923 for ; Fri, 28 Jan 2011 11:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 DjD6gJflb3Kx for ; Fri, 28 Jan 2011 11:31:35 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BCC7A3A691A for ; Fri, 28 Jan 2011 11:31:35 -0800 (PST) Received: (qmail 12869 invoked from network); 28 Jan 2011 19:34:41 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Jan 2011 19:34:41 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 28 Jan 2011 12:34:30 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Fri, 28 Jan 2011 12:34:09 -0700 Thread-Topic: [OAUTH-WG] Native Client Extension Thread-Index: Acu/IRrya3sAZmuLSoa7B3qxxnVeswAAP6Uw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB29D1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <4D239DCF.4030501@lodderstedt.net> <3C83928E-56D5-4386-A075-9ECF1F3A469C@kiva.org> <4E163351-08AE-47FA-B1F2-ECE6535346C1@kiva.org> <90C41DD21FB7C64BB94121FBBC2E723445A8FB28DE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <90C41DD21FB7C64BB94121FBBC2E723445A8FB297E@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Native Client Extension 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, 28 Jan 2011 19:31:36 -0000 If like many people, URN's give you an allergic reaction, you can also cons= ider: http://oauth.net/2.0/redirection/oob Or something like that. The advantage of the URN is that if the server does= n't support this, it doesn't end up sending the user to oauth.net... ;-) EHL > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Friday, January 28, 2011 11:25 AM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Native Client Extension >=20 > On Fri, Jan 28, 2011 at 10:25 AM, Eran Hammer-Lahav > wrote: > > -12 3.1.1: > > > > =A0 The redirection URI MUST be an absolute URI and MAY include a query > > =A0 component, which MUST be retained by the authorization server when > > =A0 adding additional query parameters. > > > > 'oob' is not an absolute URI. >=20 > Good point, I missed the absolute part. Thanks for pointing this out. >=20 > Let me think about it, the URN you suggested is a good start. >=20 > Marius From tonynad@microsoft.com Fri Jan 28 11:52:52 2011 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 DE1313A68D7 for ; Fri, 28 Jan 2011 11:52:52 -0800 (PST) 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=[AWL=-0.000, 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 zgnf3kUpfnb3 for ; Fri, 28 Jan 2011 11:52:50 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 47CC83A695E for ; Fri, 28 Jan 2011 11:52:50 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 11:55:55 -0800 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.185]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Fri, 28 Jan 2011 11:55:55 -0800 From: Anthony Nadalin To: Eran Hammer-Lahav Thread-Topic: Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQIaL9MwAAPpZeAAKfLFMAACwaqwADAncQA= Date: Fri, 28 Jan 2011 19:55:55 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F033B181B@TK5EX14MBXC111.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6250D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033B0798@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62753@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8D62753@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18F033B181BTK5EX14MBXC111r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 28 Jan 2011 19:52:53 -0000 --_000_180155C5EA10854997314CA5E063D18F033B181BTK5EX14MBXC111r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzYWlkIGl0cyDigJxiZWNvbWluZ+KAnSB1c2VsZXNzIGFzIG1vcmUgYW5kIG1vcmUgc3R1ZmYg aXMgYmVpbmcgcmVtb3ZlZC4NCg0KTWF5YmUgeW91IGRpZCBub3QgdW5kZXJzdGFuZCBvciBJIGRp ZCBub3QgdGVsbCB5b3UgZXZlcnl0aGluZyB5b3UgbmVlZGVkIHRvIGtub3csIHdlIGhhdmUgZW5k cG9pbnRzIHRoYXQgZXhwZWN0IGFzc2VydGlvbnMgYWxvbmcgd2l0aCB0aGUgZ3JhbnRfdHlwZSBv ZiBhdXRob3JpemF0aW9uX2NvZGUgYW5kIHdlIGFsc28gaGF2ZSBlbmRwb2ludHMgdGhhdCBleHBl Y3QgdGhlIGdyYW50X3R5cGUgb2YgVVJJIChvciB0aGUgYXNzZXJ0aW9uLCB3aGljaCBjb3VsZCBi ZSB3aGF0ZXZlciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVjaWRlcyksIHRoZXNlIGFyZSAy IGRpZmZlcmVudCBlbmRwb2ludHMgd2l0aCAyIGRpZmZlcmVudCBmdW5jdGlvbnMuIFRoZSBjaGFu Z2UgdGhhdCB3YXMgbWFkZSB0byByZW1vdmUgdGhlIG5vdGlvbiBvZiBjbGllbnQgYXNzZXJ0aW9u IGNyZWRlbnRpYWxzIG9ubHkgbGVmdCB1cyB3aXRoIHRoZSBleHRlbnNpb24gc28gd2UgY2FuIGxp dmUgd2l0aCB0aGUgY2hhbmdlcyB0byB0aGUgZXh0ZW5zaW9uIChpdCBpcyBhIGNvZGUgY2hhbmdl IGZvciB1cykgYnV0IG5vdCByZW1vdmFsIG9mIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMg d2UgY2Fu4oCZdCBsaXZlIHdpdGggYXMgd2UgYXJlIHVzaW5nIHRoZSBub3Rpb24gb2YgY2xpZW50 IGNyZWRlbnRpYWxzLiBJ4oCZbSBub3Qgc3VyZSB0aGF0IHB1dHRpbmcgdGhpcyBpbiB0aGUgYmVh cmVyIHRva2VuIHNwZWNpZmljYXRpb24gd291bGQgd29yay4NCg0KDQpGcm9tOiBFcmFuIEhhbW1l ci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEph bnVhcnkgMjYsIDIwMTEgMjo1MSBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbg0KQ2M6IE9BdXRoIFdH DQpTdWJqZWN0OiBSRTogUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFscw0KDQpD YW4geW91IGV4cGxhaW4gaG93IGhhdmluZyB0byBkZWZpbmUgKnR3byogZXh0ZW5zaW9uIHBhcmFt ZXRlcnMgbWFrZXMgdGhlIHNwZWNpZmljYXRpb24gdXNlbGVzcz8gVGhlIGJlYXJlciB0b2tlbiBz cGVjaWZpY2F0aW9uIGlzIGdvaW5nIHRvIGRlZmluZSBpdHMgY29ycmVzcG9uZGluZyBXV1ctQXV0 aGVudGljYXRlIGhlYWRlciwgdG8gbWF0Y2ggaXRzIGFscmVhZHkgZGVmaW5lZCBBdXRob3JpemF0 aW9uIGhlYWRlci4gVGhlIHNjaGVtZSBuYW1lIGlzIGp1c3Qgc3R5bGUgYW5kIGJyYW5kaW5nIGFu ZCBoYXZlIGFic29sdXRlbHkgbm8gdGVjaG5pY2FsIGltcGFjdC4gSSBhbSBob25lc3RseSBjb25m dXNlZCBieSB5b3VyIGNvbW1lbnRzLCBhcyBJIHdhcyBpbiB0aGUgcGFzdCB3aGVuIHlvdSBkZWNs YXJlZCB0aGUgZW50aXJlIHByb3RvY29sIHVzZWxlc3MgYmVjYXVzZSBvZiBteSBvYmplY3Rpb25z IHRvIGFuIHVuZGVyLWRlZmluZWQgc2NvcGUgcGFyYW1ldGVyLg0KDQpDYW4geW91IHBvaW50IG1l IHdoZXJlIGluIFdSQVAgYXJlIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGRlZmlu ZWQ/IEkgY2FuIG9ubHkgZmluZCB0aGUgYXNzZXJ0aW9uIHByb2ZpbGUgd2hpY2ggaXMgY29tcGFy YWJsZSB0byB0aGUgZXh0ZW5zaW9uIGdyYW50IHR5cGUgd2l0aCB0aGUgU0FNTCBhc3NlcnRpb24g ZXh0ZW5zaW9uICh3aGVyZSB0aGUgYXNzZXJ0aW9uIHBhcmFtZXRlciBpcyBkZWZpbmVkIGFuZCBy ZWdpc3RlcmVkKS4gVGhlIGNvbmNlcHQgb2YgdGhlIGNsaWVudCBhc3NlcnRpb24gdXNlZCBmb3Ig Y2xpZW50IGF1dGhlbnRpY2F0aW9uIChzZXBhcmF0ZSBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGdy YW50KSBpcyBuZXcgYW5kIHdhcyBhZGRlZCBiYXNlZCBvbiBhIHByb3Bvc2FsIGZyb20gWWFyb24g aW4gLTExIG9uIERlY2VtYmVyIDFzdCwgMjAxMC4NCg0KQXMgZm9yIHlvdXIgYWRkaXRpb25hbCBk ZXRhaWxzIGJlbG93ICh0aGFua3MhKSwgaXQgc2VlbXMgbGlrZSB5b3UgYXJlIG5vdCB1c2luZyB0 aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhdCBhbGwgYnV0IHVzaW5nIGEgc2ltcGxl IGV4dGVuc2lvbiBncmFudCB3aXRoIGFuIGFzc2VydGlvbiwgZXhhY3RseSBsaWtlIHRoZSBTQU1M IGV4dGVuc2lvbiBncmFudCBzcGVjaWZpY2F0aW9uLCBvbmx5IHlvdSBhcmUgbm90IGxpbWl0ZWQg dG8gU0FNTCAyLjAuIElzIHRoYXQgY29ycmVjdD8gSWYgdGhpcyBpcyBjb3JyZWN0LCB0aGVuIHRo ZSBvbmx5IGlzc3VlIGhlcmUgaXMgb3VyIGRlY2lzaW9uICh3aGljaCB3YXMgbWFkZSB3aXRob3V0 IGFueSBjb21tZW50IGZyb20geW91IG9yIHRob3NlIG5vdyByYWlzaW5nIGlzc3VlcyBhYm91dCB0 aGlzKSB0byBtb3ZlIHRoZSDigJhhc3NlcnRpb27igJkgcGFyYW1ldGVyIGFuZCByZW5hbWUgdGhl IGdyYW50IHR5cGUgZnJvbSBhc3NlcnRpb24gdG8gZXh0ZW5zaW9uICh3aGljaCBoYXMgbm8gaW1w bGVtZW50YXRpb24gaW1wYWN0KS4gQWxsIHdlIGRpZCBpcyByZWxvY2F0ZSB0aGUgYXNzZXJ0aW9u IHBhcmFtZXRlciBiZWNhdXNlIGl0IGRvZXNu4oCZdCBhbHdheXMgYXBwbHkgdG8gZXh0ZW5zaW9u IGdyYW50cy4NCg0KSXMgdGhpcyBqdXN0IGEgY29uZnVzaW9uIGFib3V0IHdoYXQgd2FzIGJlaW5n IHJlbW92ZWQgYW5kIHdoZXJlIGl0IHdlbnQ/DQoNCkVITA0KDQoNCkZyb206IEFudGhvbnkgTmFk YWxpbiBbbWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV08bWFpbHRvOlttYWlsdG86dG9ueW5h ZEBtaWNyb3NvZnQuY29tXT4NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAyNiwgMjAxMSAxOjUy IFBNDQpUbzogRXJhbiBIYW1tZXItTGFoYXYNCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogUkU6IFJl bW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMNCg0KTWF5YmUgdGhpcyB3YXMgdGhl IHBsYW4gYWxsIGFsb25nIGJ1dCBzcGVjaWZpY2F0aW9uIGlzIGJlY29taW5nIHVzZWxlc3MgZm9y IG91ciBzY2VuYXJpb3MgYW5kIHdpbGwgcmVxdWlyZSB0aGF0IHdlIGhhdmUgdG8gZ28gd2VsbCBi ZXlvbmQgdGhlIGNvcmUgc3BlY2lmaWNhdGlvbiB0byBtYWtlIHRoaW5ncyB3b3JrLCB0aGUgY2xp ZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBiZWluZyBhIHByaW1lIGV4YW1wbGUuIFRoZSBjbGll bnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGhhcyBiZWVuIGFyb3VuZCBmb3IgYSB3aGlsZSBhcyBp dCB3YXMgYSByZXF1aXJlbWVudCBmb3IgV1JBUCwgdGhlbiBkcm9wcGVkIHdoZW4gdGhlIHZhcmlv dXMgc3BlY3MgZ290IG1lcmdlZCB0byBmb3JtIE9BVVRIIDIuMCBhbmQgdGhlbiBjYW1lIGJhY2sg aW50byB0aGUgT0FVVEggMi4wIGFuZCB0aGVuIGhhcyBnb25lIHRocm91Z2ggdmFyaW91cyBjaGFu Z2VzIHNpbmNlIHZlcnNpb24gNiBmb3IgdGhlIHdvcnNlLiBUaGVyZSBoYXMgYmVlbiBtdWNoIGRp c2N1c3Npb24gaW4gSnVseS9BdWd1c3Qgb3ZlciB0aGlzIGFuZCBuZXcgdGV4dCB3YXMgcHJvcG9z ZWQsIGJ1dCB0aGF0IHNlZW1zIHRvIG5vdCBiZSBmdWxseSBhY2NlcHRlZCwgYnV0IEkgdGhpbmsg dGhhdCBmb2xsb3dzIHRoZSBwYXRoIHdoZW4geW91IHdhbnQgdG8gcmVtb3ZlIHNvbWV0aGluZy4N Cg0KT3VyIHVzYWdlIHdpbGwgYmUgdmlhIGJlYXJlciB0b2tlbiBhc3NlcnRpb25zIG9ubHkgKGF0 IHRoaXMgdGltZSkNClRoZSBncmFudF90eXBlIHdvdWxkIGJlIHRoZSBVUkkgb2YgdGhlIGFzc2Vy dGlvbiB0eXBlIGJlaW5nIHVzZWQNClRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50IGNhbiB1c2Ug d2hhdCBpdCB3YW50cyB0byBiaW5kIHRoZSBhc3NlcnRpb24gdG8gdGhlIGNsaWVudF9pZCwgbXVj aCBsaWtlIGl0IGhhcyB0byB0b2RheSBmb3IgdGhlIHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uLCBh cyB3ZSBoYXZlIHNjZW5hcmlvcyB3ZXJlIGNsaWVudF9pZCBoYXZlIG11bHRpcGxlIHBhc3N3b3Jk cw0KV2UgdXNlIGd1aWRhbmNlIGZyb20gc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIG9m IHRoZSBhc3NlcnRpb24gdHlwZSBiZWluZyB1c2VkIGFsb25nIHdpdGggdGhlIGd1aWRhbmNlIGZy b20gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uDQpJZiBuZWVkZWQgSSBjYW4gY2FwdHVy ZSB0aGUgYXNzZXJ0aW9ucyBhbmQgcmVxdWVzdHMsIGJ1dCBub3Qgc3VyZSB3aGF0IHRoZSBwb2lu dCBvZiB0aGlzIGlzIGF0IHRoaXMgdGltZSBzaW5jZSB0aGlzIGlzIG5vdCByZXF1aXJlZCBmb3Ig dGhlIHBhc3N3b3JkIGNyZWRlbnRpYWxzDQoNClN1cmUgd2UgY2FuIGFkZCB0aGUgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIGFzc2VydGlvbiB0byB0aGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24g YnV0IEkgZG9u4oCZdCB0aGluayB0aGF0IGlzIHRoZSBwcm9wZXIgcGxhY2UgdG8gZG8gdGh1cyBi dXQgc2luY2UgaXTigJlzIGdvbmUgZnJvbSB0aGUgY29yZSB3ZSB3aWxsIGhhdmUgdG8gZG8ganVz dCB0aGF0LiBUaGUgc2FtZSBzZWVtcyB0byBoYXBwZW4gd2l0aCB0aGUgSFRUUCBBdXRoZW50aWNh dGlvbiBTY2hlbWUgYXMgaXQgc2VlbXMgdG8gYmUgcmVwZWF0ZWQgaW4gZm9sbG93LW9uIGNvbXBh bmlvbiBzcGVjaWZpY2F0aW9ucy4gV2hpbGUgb2F1dGgtdjIgaXMgbm90IGFuIGF1dGhlbnRpY2F0 aW9uIHByb3RvY29sIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgZm9yIGF1dGhlbnRpY2F0aW9uIHRv IGFkZHJlc3Mgc2VjdXJpdHkgY29uY2VybnMuIFRoZXJlIGlzIGNsZWFyIHNlcGFyYXRpb24gYmV0 d2VlbiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbjsgd2UgYXJlIG5vdCBzdWdnZXN0 aW5nIHRoYXQgYXV0aGVudGljYXRpb24gaXMgYXBwcm9wcmlhdGUgZmFjaWxpdHkgdG8gbmVnb3Rp YXRlIGF1dGhvcml6YXRpb24uIEkgdGhpbmsgdGhhdCBpdCBtYWtlcyBzZW5zZSB0byBpbmNsdWRl IGEgc2NoZW1lIGluIHRoZSBjb3JlIGFuZCBoYXZlIHRoZSBwYXJ0aWN1bGFyIGZvbGxvdy1vbiBj b21wYW5pb24gc3BlY2lmaWNhdGlvbnMgKHRoZSB2YXJpb3VzIHRva2VuIHNwZWNpZmljYXRpb25z KSBzdGF0ZS9kZWZpbmUgdGhlIHBhcmFtZXRlcnMgYW5kIGlmIHRoZXkgZG9u4oCZdCBsaWtlIHRo ZSBkZWZhdWx0IHNjaGVtZSBsZXQgdGhlbSBkZWZpbmUgYSBuZXcgc2NoZW1lIGJ1dCB0aGlzIHB1 dHMgYSBzdGFrZSBpbiB0aGUgZ3JvdW5kIGZvciBhbiBIVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVt ZS4NCg0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5j b21dPG1haWx0bzpbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dPg0KU2VudDogVHVlc2RheSwg SmFudWFyeSAyNSwgMjAxMSA1OjM4IFBNDQpUbzogQW50aG9ueSBOYWRhbGluDQpDYzogT0F1dGgg V0cNClN1YmplY3Q6IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoN CkNhbiB5b3Ugc2hhcmUgd2l0aCB0aGUgbGlzdCBob3cgeW91IHBsYW4gdG8gdXNlIHRoaXMgY2xp ZW50IGFzc2VydGlvbiBhdXRoZW50aWNhdGlvbiBzY2hlbWU/DQpXaGljaCBvZiB0aGUgYXV0aG9y aXphdGlvbiBncmFudCB0eXBlcyB5b3Ugd2lsbCB1c2UgaXQgd2l0aD8NCldpbGwgeW91IHVzZSBp dCB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBhbmQgaWYgc28sIGhvdyB3aWxsIHlv dSBiaW5kIHRoZSBhc3NlcnRpb24gdG8gdGhlIGNsaWVudF9pZD8NCkNhbiB5b3UgcHJvdmlkZSBm dWxsIGV4YW1wbGVzIG9mIGFzc2VydGlvbnMgYW5kIEhUVFAgcmVxdWVzdHM/DQoNCkl0IHdvdWxk IGJlIGhlbHBmdWwgdG8gc2VlIGhvdyBmYXIgYXBhcnQgdGhlIHByb3Bvc2VkIHRleHQgYmVsb3cg aXMgZnJvbSBhbiBhY3R1YWwgaW1wbGVtZW50YXRpb24gbWFraW5nIHVzZSBvZiBpdC4gSSBleGNl cHQgdG8gc2VlIHRoZXNlIGFuc3dlcnMgaW4gYW55IHF1YWxpdHkgZG9jdW1lbnQgZGVmaW5pbmcg YSBuZXcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHNjaGVtZSAod2hpY2ggaXMgdHJ1ZSBmb3IgdGhl IGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCku DQoNCkVITA0KDQoNCkZyb206IEFudGhvbnkgTmFkYWxpbiBbbWFpbHRvOnRvbnluYWRAbWljcm9z b2Z0LmNvbV08bWFpbHRvOlttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXT4NClNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgMzo1OCBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBP QXV0aCBXRzsgSGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldDxtYWlsdG86SGFubmVzLlRzY2hvZmVu aWdAZ214Lm5ldD47IEJsYWluZSBDb29rDQpTdWJqZWN0OiBSRTogUmVtb3ZhbDogQ2xpZW50IEFz c2VydGlvbiBDcmVkZW50aWFscw0KDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxl IGZvciByZW1vdmluZyB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscywgYXMgY2xpZW50 IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIGlzIGxlZnQgaW4uIENsaWVudCBQYXNzd29yZCBBdXRo ZW50aWNhdGlvbiBpcyBhbHNvIHVuZGVyc3BlY2lmaWVkIGFzIGNsaWVudF9zZWNyZXQgY291bGQg YmUgYW55dGhpbmcgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyIHNlZW1zIGZpdCAocmF3 IGNsZWFyIHRleHQgcGFzc3dvcmQsICBoYXNoLCBkaWdlc3QsIGV0Yy4pIGFuZCBubyB3YXkgdG8g ZGV0ZXJtaW5lIHRoZSBjb250ZW50LiBjbGllbnRfc2VjcmV0IGlzIGFsc28gYSB2ZXJ5IHdlYWsg bWVjaGFuaXNtLCBzaW5jZSB0aGlzIGlzIGxlZnQgaW4gdGhlIGNvcmUgdGhpcyBsZWFkcyBtZSB0 byBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgc3VwcG9ydCBmb3IgaGF2aW5nIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBpbiBPYXV0aC4gSSBkb24ndCBzZWUgaG93IGhhdmluZyBjbGllbnRfYXNzZXJ0aW9u IGFuZCBjbGllbnRfYXNzZXJ0aW9uX3R5cGUgd291bGQgYmUgc29tZXRoaW5nIHRoYXQgaXMgdW5k ZXJzcGVjaWZpZWQgYXMgYmVpbmcgYSBtZWNoYW5pc20gaW4gd2hpY2ggYXNzZXJ0aW9ucyBjYW4g YmUgdXNlZCBmb3IgYXV0aGVudGljYXRpb24uIEFncmVlIHRoYXQgdGhlIGF1dGhlbnRpY2F0aW9u IHNlcnZlciBoYXMgdG8gbWFrZSByaWdodCBhbmQgZGVjbGFyZSB3aGF0IGlzIGJlaW5nIHVzZWQg YnV0IHRoYXQgaXMgdGhlIHNhbWUgZm9yIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbi4g VGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb25zIGFyZSBzb21ldGhpbmcgdGhhdCBN aWNyb3NvZnQgYW5kIEdvb2dsZSBmaW5kIHVzZWZ1bCBhbmQgcGxhbiBvbiBpbXBsZW1lbnRpbmcg YW5kIHVzaW5nIGFzIGEgbWVhbnMgZm9yIHN0cm9uZ2VyIGF1dGhlbnRpY2F0aW9uIHRvIHRoZSBh dXRob3JpemF0aW9uIHNlcnZlci4gVGhpcyBleHRlbnNpYmlsaXR5IGJlbG9uZ3MgaW4gdGhlIGNv cmUsIHRoZXJlIGlzIG5vIG90aGVyIHBsYWNlIHRvIHB1dCB0aGlzIGZ1bmN0aW9uYWxpdHkuIEkg ZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoZSByZW1vdmFsIChlaXRoZXIgYnkgZWRpdG9yIG9yIGRpcmVj dGlvbiBieSBjby1jaGFpcikgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiBkb25l IHcvbyBhIGNvbnNlbnN1cyB2b3RlIHNpbmNlIHRoaXMgaGFzIGJlZW4gaW4gdGhlIHNwZWNpZmlj YXRpb24gZm9yIHNvbWUgdGltZSB3aXRob3V0IGlzc3VlIGFuZCB0aGUgcmVtb3ZhbCBjb21lcyBh cyBjb21wbGV0ZSB1bndlbGNvbWUgc3VycHJpc2UuIEdldHRpbmcgYWxtb3N0IHRvdGFsIHJld3Jp dGVzIG9mIHRoZSBzcGVjaWZpY2F0aW9uIHRoaXMgbGF0ZSBpbiB0aGUgcmV2aWV3IGN5Y2xlIGlz IGFsc28gdmVyeSBkaXN0dXJiaW5nLg0KDQoNCg0KQSBwcm9wb3NhbCBmb3Iga2VlcGluZyB0aGUg Y2xpZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiB3b3VsZCBiZSB0byBzaW1wbGlmeSB0byB0 aGUgZm9sbG93aW5nOw0KDQpUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhcmUgdXNl ZCBpbiBjYXNlcyB3aGVyZSBhIHBhc3N3b3JkIChjbGVhci10ZXh0IHNoYXJlZCBzeW1tZXRyaWMg c2VjcmV0KSBpcyB1bnN1aXRhYmxlIG9yIGRvZXMgbm90IHByb3ZpZGUgc3VmZmljaWVudCBzZWN1 cml0eSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVk ZW50aWFscyBwcm92aWRlIGFuIGV4dGVuc2libGUgbWVjaGFuaXNtIHRvIHVzZSBhbiBhc3NlcnRp b24gZm9ybWF0IHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhl bnRpY2F0aW9uIG9mIHRoZSBjbGllbnQuDQoNClVzaW5nIGFzc2VydGlvbnMgcmVxdWlyZXMgdGhl IGNsaWVudCB0byBvYnRhaW4gYW4gYXNzZXJ0aW9uIChzdWNoIGFzIGEgU0FNTCAoQ2FudG9yLCBT LiwgS2VtcCwgSi4sIFBoaWxwb3R0LCBSLiwgYW5kIEUuIE1hbGVyLCDigJxBc3NlcnRpb25zIGFu ZCBQcm90b2NvbCBmb3IgdGhlIE9BU0lTIFNlY3VyaXR5IEFzc2VydGlvbiBNYXJrdXAgTGFuZ3Vh Z2UgKFNBTUwpIFYyLjAs4oCdIE1hcmNoIDIwMDUuKSBbT0FTSVMuc2FtbOKAkWNvcmXigJEyLjDi gJFvc10gYXNzZXJ0aW9uKSBmcm9tIGFuIGFzc2VydGlvbiBpc3N1ZXIgb3IgdG8gc2VsZi1pc3N1 ZSBhbiBhc3NlcnRpb24uIFRoZSBhc3NlcnRpb24gZm9ybWF0LCB0aGUgcHJvY2VzcyBieSB3aGlj aCB0aGUgYXNzZXJ0aW9uIGlzIG9idGFpbmVkLCBhbmQgdGhlIG1ldGhvZCBvZiB2YWxpZGF0aW5n IHRoZSBhc3NlcnRpb24gYXJlIGRlZmluZWQgYnkgdGhlIGFzc2VydGlvbiBpc3N1ZXIgYW5kIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMg c3BlY2lmaWNhdGlvbi4NCg0KV2hlbiB1c2luZyBhIGNsaWVudCBhc3NlcnRpb24sIHRoZSBjbGll bnQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOg0KY2xpZW50X2Fzc2VydGlvbl90 eXBlIC0gUkVRVUlSRUQuIFRoZSBmb3JtYXQgb2YgdGhlIGFzc2VydGlvbiBhcyBkZWZpbmVkIGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhlIHZhbHVlIE1VU1QgYmUgYW4gYWJzb2x1dGUg VVJJLg0KY2xpZW50X2Fzc2VydGlvbiAtIFJFUVVJUkVELiBUaGUgY2xpZW50IGFzc2VydGlvbi4N Cg0KRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgc2VuZHMgdGhlIGZvbGxvd2luZyBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCB1c2luZyBhIFNBTUwgMi4wIGFzc2VydGlvbiB0byBhdXRoZW50aWNhdGUgaXRz ZWxmIChsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6DQoNCg0KDQoN Cg0KICBQT1NUIC90b2tlbiBIVFRQLzEuMQ0KDQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbQ0K DQogIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkDQoNCg0K DQogIGdyYW50X3R5cGU9YXV0aG9yaXphdGlvbl9jb2RlJmNvZGU9aTFXc1JuMXVCMSYNCg0KICBj bGllbnRfYXNzZXJ0aW9uPVBITmhiV3h3T2xbLi4ub21pdHRlZCBmb3IgYnJldml0eS4uLl1aVDQl M0QmDQoNCiAgY2xpZW50X2Fzc2VydGlvbl90eXBlPSAgdXJuJTNBb2FzaXMlM0FuYW1lcyVzQXRj JTNBU0FNTCUzQTIuMCUzQWFzc2VydGlvbiZyZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZjbGll bnQlMkVleGFtcGxlJTJFY29tJTJGY2INCg0KDQoNCg0KDQoNCkZyb206IG9hdXRoLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91 bmNlc0BpZXRmLm9yZ108bWFpbHRvOlttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10+IE9u IEJlaGFsZiBPZiBFcmFuIEhhbW1lci1MYWhhdg0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDE0LCAy MDExIDEwOjQ1IFBNDQpUbzogT0F1dGggV0cNClN1YmplY3Q6IFtPQVVUSC1XR10gUmVtb3ZhbDog Q2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFscw0KDQpJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB3 ZSBkcm9wIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzICgtMTEgc2VjdGlvbiAzLjIp IGZyb20gdGhlIHNwZWNpZmljYXRpb24sIGFuZCBpZiBuZWVkZWQsIHB1Ymxpc2ggaXQgYXMgYSBz ZXBhcmF0ZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6DQoNCg0KMS4g ICAgICAgVGhlIG1lY2hhbmlzbSBpcyB1bmRlciBzcGVjaWZpZWQsIGVzcGVjaWFsbHkgaW4gaXRz IGhhbmRsaW5nIG9mIHRoZSBjbGllbnRfaWQgaWRlbnRpZmllciAod2hlbiB1c2VkIHRvIG9idGFp biBlbmQtdXNlciBhdXRob3JpemF0aW9uKS4gSXQgZG9lcyBub3QgY29udGFpbiBhbnkgaW1wbGVt ZW50YXRpb24gZGV0YWlscyB0byBhY2NvbXBsaXNoIGFueSBsZXZlbCBvZiBpbnRlcm9wZXJhYmls aXR5IG9yIGZ1bmN0aW9uYWxpdHkuIFRoaXMgaXMgaW4gY29udHJhc3QgdG8gdGhlIGFzc2VydGlv biBncmFudCB0eXBlIHdoaWNoIGhhcyBtYXR1cmVkIG92ZXIgYSB5ZWFyIGludG8gYSBmdWxseSB0 aG91Z2h0LW91dCBleHRlbnNpb24gbWVjaGFuaXNtLCBhcyB3ZWxsIGFzIGEgc2VwYXJhdGUgU0FN TCBhc3NlcnRpb24gc3BlY2lmaWNhdGlvbiB3aXRoIGFjdGl2ZSBkZXBsb3ltZW50ICh0aGUgdHdv LCB0b2dldGhlciB3aXRoIHJ1bm5pbmcgY29kZSwgc2hvdyBjbGVhciBjb25zZW5zdXMpLg0KDQoy LiAgICAgICBUaGUgc2VjdGlvbiBpcyBhIGNvbmZ1c2VkIG1peCBvZiBzZWN1cml0eSBjb25zaWRl cmF0aW9ucyBzcHJpbmtsZWQgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UuIEluc3RlYWQsIGl0IHNo b3VsZCBiZSByZXBsYWNlZCB3aXRoIGd1aWRlbGluZXMgZm9yIGV4dGVuZGluZyB0aGUgc2V0IG9m IHN1cHBvcnRlZCBjbGllbnQgY3JlZGVudGlhbHMsIGJ1dCB3aXRob3V0IGRlZmluaW5nIGEgbmV3 IHJlZ2lzdHJ5LiBJdCBpcyBjbGVhcmx5IGFuIGFyZWEgb2YgbGl0dGxlIGRlcGxveW1lbnQgZXhw ZXJpZW5jZSBmb3IgT0F1dGgsIGFuZCB0aGF0IGluY2x1ZGVzIHVzaW5nIEhUVFAgQmFzaWMgYXV0 aGVudGljYXRpb24gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAobW9yZSBvbiB0aGF0IHRvIGNv bWUpLg0KDQozLiAgICAgICBUaGUgc2VjdGlvbiBoYXMgcmVjZWl2ZWQgYSBsaXR0bGUgc3VwcG9y dCBhbmQgYSBsaXR0bGUgb2JqZWN0aW9uLiBUaG9zZSB3aG8gc3RpbGwgd2FudCB0byBhZHZvY2F0 ZSBmb3IgaXQgbmVlZCB0byBzaG93IG5vdCBvbmx5IGNvbnNlbnN1cyBmb3Iga2VlcGluZyBpdCwg YnV0IGFsc28gYWN0aXZlIGNvbW11bml0eSBzdXBwb3J0IGZvciBkZXBsb3lpbmcgaXQuIERlcGxv eW1lbnQsIG9mIGNvdXJzZSwgd2lsbCBhbHNvIHJlcXVpcmUgc2hvd2luZyBwcm9ncmVzcyBvbiBw dWJsaWMgc3BlY2lmaWNhdGlvbnMgcHJvZmlsaW5nIHRoZSBtZWNoYW5pc20gaW50byBhIHVzZWZ1 bCBpbnRlcm9wZXJhYmxlIGZlYXR1cmUuDQoNCkNvbW1lbnRzPyBDb3VudGVyLWFyZ3VtZW50cz8N Cg0KRUhMDQoNCg0K --_000_180155C5EA10854997314CA5E063D18F033B181BTK5EX14MBXC111r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3Jn L3NvYXAvZW52ZWxvcGUvIiB4bWxuczpkcz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC8wOS94bWxk c2lnIyIgeG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6 eHNpPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYS1pbnN0YW5jZSIgeG1sbnM6bT0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0i aHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1 aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVk IG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAu TXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpwDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MjQuMHB0Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjI0LjBw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz ZXJpZiI7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJYmFja2dyb3VuZDojQ0NDQ0NDOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwi c2Fucy1zZXJpZiI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4t bGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgljb2xvcjpibGFjazsNCgliYWNrZ3JvdW5k OiNDQ0NDQ0M7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJh bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUz MA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTExMzc4NjUwMDsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTMyMTg2OTg4OCA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPkkgc2FpZCBpdHMg4oCcYmVjb21pbmfigJ0gdXNlbGVzcyBhcyBtb3JlIGFuZCBtb3JlIHN0 dWZmIGlzIGJlaW5nIHJlbW92ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5NYXliZSB5b3UgZGlkIG5vdCB1bmRlcnN0YW5kIG9yIEkgZGlkIG5vdCB0ZWxsIHlvdSBldmVy eXRoaW5nIHlvdSBuZWVkZWQgdG8ga25vdywgd2UgaGF2ZSBlbmRwb2ludHMgdGhhdCBleHBlY3Qg YXNzZXJ0aW9ucyBhbG9uZyB3aXRoIHRoZSBncmFudF90eXBlIG9mIGF1dGhvcml6YXRpb25fY29k ZSBhbmQgd2UgYWxzbyBoYXZlIGVuZHBvaW50cyB0aGF0IGV4cGVjdA0KIHRoZSBncmFudF90eXBl IG9mIFVSSSAob3IgdGhlIGFzc2VydGlvbiwgd2hpY2ggY291bGQgYmUgd2hhdGV2ZXIgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGRlY2lkZXMpLCB0aGVzZSBhcmUgMiBkaWZmZXJlbnQgZW5kcG9p bnRzIHdpdGggMiBkaWZmZXJlbnQgZnVuY3Rpb25zLiBUaGUgY2hhbmdlIHRoYXQgd2FzIG1hZGUg dG8gcmVtb3ZlIHRoZSBub3Rpb24gb2YgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBvbmx5 IGxlZnQgdXMgd2l0aA0KIHRoZSBleHRlbnNpb24gc28gd2UgY2FuIGxpdmUgd2l0aCB0aGUgY2hh bmdlcyB0byB0aGUgZXh0ZW5zaW9uIChpdCBpcyBhIGNvZGUgY2hhbmdlIGZvciB1cykgYnV0IG5v dCByZW1vdmFsIG9mIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgd2UgY2Fu4oCZdCBsaXZl IHdpdGggYXMgd2UgYXJlIHVzaW5nIHRoZSBub3Rpb24gb2YgY2xpZW50IGNyZWRlbnRpYWxzLiBJ 4oCZbSBub3Qgc3VyZSB0aGF0IHB1dHRpbmcgdGhpcyBpbiB0aGUgYmVhcmVyIHRva2VuDQogc3Bl Y2lmaWNhdGlvbiB3b3VsZCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFcmFuIEhh bW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBKYW51YXJ5IDI2LCAyMDExIDI6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IEFu dGhvbnkgTmFkYWxpbjxicj4NCjxiPkNjOjwvYj4gT0F1dGggV0c8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Q2FuIHlvdSBleHBsYWluIGhvdyBoYXZpbmcgdG8gZGVmaW5lICo8Yj50d288L2I+KiBl eHRlbnNpb24gcGFyYW1ldGVycyBtYWtlcyB0aGUgc3BlY2lmaWNhdGlvbiB1c2VsZXNzPyBUaGUg YmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24gaXMgZ29pbmcgdG8gZGVmaW5lIGl0cyBjb3JyZXNw b25kaW5nIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyLCB0byBtYXRjaCBpdHMNCiBhbHJlYWR5IGRl ZmluZWQgQXV0aG9yaXphdGlvbiBoZWFkZXIuIFRoZSBzY2hlbWUgbmFtZSBpcyBqdXN0IHN0eWxl IGFuZCBicmFuZGluZyBhbmQgaGF2ZSBhYnNvbHV0ZWx5IG5vIHRlY2huaWNhbCBpbXBhY3QuIEkg YW0gaG9uZXN0bHkgY29uZnVzZWQgYnkgeW91ciBjb21tZW50cywgYXMgSSB3YXMgaW4gdGhlIHBh c3Qgd2hlbiB5b3UgZGVjbGFyZWQgdGhlIGVudGlyZSBwcm90b2NvbCB1c2VsZXNzIGJlY2F1c2Ug b2YgbXkgb2JqZWN0aW9ucyB0bw0KIGFuIHVuZGVyLWRlZmluZWQgc2NvcGUgcGFyYW1ldGVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q2FuIHlvdSBwb2ludCBtZSB3aGVy ZSBpbiBXUkFQIGFyZSB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBkZWZpbmVkPyBJ IGNhbiBvbmx5IGZpbmQgdGhlIGFzc2VydGlvbiBwcm9maWxlIHdoaWNoIGlzIGNvbXBhcmFibGUg dG8gdGhlIGV4dGVuc2lvbiBncmFudCB0eXBlIHdpdGggdGhlIFNBTUwgYXNzZXJ0aW9uIGV4dGVu c2lvbiAod2hlcmUgdGhlDQogYXNzZXJ0aW9uIHBhcmFtZXRlciBpcyBkZWZpbmVkIGFuZCByZWdp c3RlcmVkKS4gVGhlIGNvbmNlcHQgb2YgdGhlIGNsaWVudCBhc3NlcnRpb24gdXNlZCBmb3IgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIChzZXBhcmF0ZSBmcm9tIHRoZSBhdXRob3JpemF0aW9uIGdyYW50 KSBpcyBuZXcgYW5kIHdhcyBhZGRlZCBiYXNlZCBvbiBhIHByb3Bvc2FsIGZyb20gWWFyb24gaW4g LTExIG9uIERlY2VtYmVyIDE8c3VwPnN0PC9zdXA+LCAyMDEwLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+QXMgZm9yIHlvdXIgYWRkaXRpb25hbCBkZXRhaWxzIGJlbG93ICh0 aGFua3MhKSwgaXQgc2VlbXMgbGlrZSB5b3UgYXJlIG5vdCB1c2luZyB0aGUgY2xpZW50IGFzc2Vy dGlvbiBjcmVkZW50aWFscyBhdCBhbGwgYnV0IHVzaW5nIGEgc2ltcGxlIGV4dGVuc2lvbiBncmFu dCB3aXRoIGFuIGFzc2VydGlvbiwgZXhhY3RseSBsaWtlIHRoZSBTQU1MIGV4dGVuc2lvbiBncmFu dA0KIHNwZWNpZmljYXRpb24sIG9ubHkgeW91IGFyZSBub3QgbGltaXRlZCB0byBTQU1MIDIuMC4g SXMgdGhhdCBjb3JyZWN0PyBJZiB0aGlzIGlzIGNvcnJlY3QsIHRoZW4gdGhlIG9ubHkgaXNzdWUg aGVyZSBpcyBvdXIgZGVjaXNpb24gKHdoaWNoIHdhcyBtYWRlIHdpdGhvdXQgYW55IGNvbW1lbnQg ZnJvbSB5b3Ugb3IgdGhvc2Ugbm93IHJhaXNpbmcgaXNzdWVzIGFib3V0IHRoaXMpIHRvIG1vdmUg dGhlIOKAmGFzc2VydGlvbuKAmSBwYXJhbWV0ZXIgYW5kIHJlbmFtZQ0KIHRoZSBncmFudCB0eXBl IGZyb20gYXNzZXJ0aW9uIHRvIGV4dGVuc2lvbiAod2hpY2ggaGFzIG5vIGltcGxlbWVudGF0aW9u IGltcGFjdCkuIEFsbCB3ZSBkaWQgaXMgcmVsb2NhdGUgdGhlIGFzc2VydGlvbiBwYXJhbWV0ZXIg YmVjYXVzZSBpdCBkb2VzbuKAmXQgYWx3YXlzIGFwcGx5IHRvIGV4dGVuc2lvbiBncmFudHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JcyB0aGlzIGp1c3QgYSBjb25mdXNp b24gYWJvdXQgd2hhdCB3YXMgYmVpbmcgcmVtb3ZlZCBhbmQgd2hlcmUgaXQgd2VudD88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVITDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQW50aG9ueSBOYWRhbGluDQo8YSBocmVmPSJt YWlsdG86W21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dIj5bbWFpbHRvOnRvbnluYWRAbWlj cm9zb2Z0LmNvbV08L2E+DQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDI2 LCAyMDExIDE6NTIgUE08YnI+DQo8Yj5Ubzo8L2I+IEVyYW4gSGFtbWVyLUxhaGF2PGJyPg0KPGI+ Q2M6PC9iPiBPQXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogUmVtb3ZhbDogQ2xpZW50 IEFzc2VydGlvbiBDcmVkZW50aWFsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NYXliZSB0aGlzIHdhcyB0 aGUgcGxhbiBhbGwgYWxvbmcgYnV0IHNwZWNpZmljYXRpb24gaXMgYmVjb21pbmcgdXNlbGVzcyBm b3Igb3VyIHNjZW5hcmlvcyBhbmQgd2lsbCByZXF1aXJlIHRoYXQgd2UgaGF2ZSB0byBnbyB3ZWxs IGJleW9uZCB0aGUgY29yZSBzcGVjaWZpY2F0aW9uIHRvIG1ha2UgdGhpbmdzIHdvcmssIHRoZSBj bGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzDQogYmVpbmcgYSBwcmltZSBleGFtcGxlLiBUaGUg Y2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBoYXMgYmVlbiBhcm91bmQgZm9yIGEgd2hpbGUg YXMgaXQgd2FzIGEgcmVxdWlyZW1lbnQgZm9yIFdSQVAsIHRoZW4gZHJvcHBlZCB3aGVuIHRoZSB2 YXJpb3VzIHNwZWNzIGdvdCBtZXJnZWQgdG8gZm9ybSBPQVVUSCAyLjAgYW5kIHRoZW4gY2FtZSBi YWNrIGludG8gdGhlIE9BVVRIIDIuMCBhbmQgdGhlbiBoYXMgZ29uZSB0aHJvdWdoIHZhcmlvdXMg Y2hhbmdlcw0KIHNpbmNlIHZlcnNpb24gNiBmb3IgdGhlIHdvcnNlLiBUaGVyZSBoYXMgYmVlbiBt dWNoIGRpc2N1c3Npb24gaW4gSnVseS9BdWd1c3Qgb3ZlciB0aGlzIGFuZCBuZXcgdGV4dCB3YXMg cHJvcG9zZWQsIGJ1dCB0aGF0IHNlZW1zIHRvIG5vdCBiZSBmdWxseSBhY2NlcHRlZCwgYnV0IEkg dGhpbmsgdGhhdCBmb2xsb3dzIHRoZSBwYXRoIHdoZW4geW91IHdhbnQgdG8gcmVtb3ZlIHNvbWV0 aGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk91ciB1c2FnZSB3aWxs IGJlIHZpYSBiZWFyZXIgdG9rZW4gYXNzZXJ0aW9ucyBvbmx5IChhdCB0aGlzIHRpbWUpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoZSBncmFudF90eXBlIHdvdWxkIGJlIHRoZSBVUkkgb2YgdGhlIGFzc2VydGlv biB0eXBlIGJlaW5nIHVzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlIGF1dGhvcml6YXRpb24gZW5kcG9p bnQgY2FuIHVzZSB3aGF0IGl0IHdhbnRzIHRvIGJpbmQgdGhlIGFzc2VydGlvbiB0byB0aGUgY2xp ZW50X2lkLCBtdWNoIGxpa2UgaXQgaGFzIHRvIHRvZGF5IGZvciB0aGUgcGFzc3dvcmQgYXV0aGVu dGljYXRpb24sIGFzIHdlIGhhdmUgc2NlbmFyaW9zIHdlcmUgY2xpZW50X2lkIGhhdmUgbXVsdGlw bGUgcGFzc3dvcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldlIHVzZSBndWlkYW5jZSBmcm9tIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBvZiB0aGUgYXNzZXJ0aW9uIHR5cGUgYmVpbmcgdXNlZCBh bG9uZyB3aXRoIHRoZSBndWlkYW5jZSBmcm9tIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5JZiBuZWVkZWQgSSBjYW4gY2FwdHVyZSB0aGUgYXNzZXJ0aW9ucyBh bmQgcmVxdWVzdHMsIGJ1dCBub3Qgc3VyZSB3aGF0IHRoZSBwb2ludCBvZiB0aGlzIGlzIGF0IHRo aXMgdGltZSBzaW5jZSB0aGlzIGlzIG5vdCByZXF1aXJlZCBmb3IgdGhlIHBhc3N3b3JkIGNyZWRl bnRpYWxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdXJlIHdlIGNhbiBh ZGQgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gdG8gdGhlIGJlYXJlciB0b2tl biBzcGVjaWZpY2F0aW9uIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB0aGUgcHJvcGVyIHBs YWNlIHRvIGRvIHRodXMgYnV0IHNpbmNlIGl04oCZcyBnb25lIGZyb20gdGhlIGNvcmUgd2Ugd2ls bCBoYXZlIHRvIGRvIGp1c3QgdGhhdC4gVGhlDQogc2FtZSBzZWVtcyB0byBoYXBwZW4gd2l0aCB0 aGUgSFRUUCBBdXRoZW50aWNhdGlvbiBTY2hlbWUgYXMgaXQgc2VlbXMgdG8gYmUgcmVwZWF0ZWQg aW4gZm9sbG93LW9uIGNvbXBhbmlvbiBzcGVjaWZpY2F0aW9ucy4gV2hpbGUgb2F1dGgtdjIgaXMg bm90IGFuIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgZm9y IGF1dGhlbnRpY2F0aW9uIHRvIGFkZHJlc3Mgc2VjdXJpdHkgY29uY2VybnMuIFRoZXJlIGlzIGNs ZWFyDQogc2VwYXJhdGlvbiBiZXR3ZWVuIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9u OyB3ZSBhcmUgbm90IHN1Z2dlc3RpbmcgdGhhdCBhdXRoZW50aWNhdGlvbiBpcyBhcHByb3ByaWF0 ZSBmYWNpbGl0eSB0byBuZWdvdGlhdGUgYXV0aG9yaXphdGlvbi4gSSB0aGluayB0aGF0IGl0IG1h a2VzIHNlbnNlIHRvIGluY2x1ZGUgYSBzY2hlbWUgaW4gdGhlIGNvcmUgYW5kIGhhdmUgdGhlIHBh cnRpY3VsYXIgZm9sbG93LW9uIGNvbXBhbmlvbiBzcGVjaWZpY2F0aW9ucw0KICh0aGUgdmFyaW91 cyB0b2tlbiBzcGVjaWZpY2F0aW9ucykgc3RhdGUvZGVmaW5lIHRoZSBwYXJhbWV0ZXJzIGFuZCBp ZiB0aGV5IGRvbuKAmXQgbGlrZSB0aGUgZGVmYXVsdCBzY2hlbWUgbGV0IHRoZW0gZGVmaW5lIGEg bmV3IHNjaGVtZSBidXQgdGhpcyBwdXRzIGEgc3Rha2UgaW4gdGhlIGdyb3VuZCBmb3IgYW4gSFRU UCBBdXRoZW50aWNhdGlvbiBTY2hlbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyYW4g SGFtbWVyLUxhaGF2DQo8YSBocmVmPSJtYWlsdG86W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29t XSI+W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXTwvYT4gPGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgNTozOCBQTTxicj4NCjxiPlRvOjwvYj4gQW50aG9ueSBO YWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog UmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFsczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5D YW4geW91IHNoYXJlIHdpdGggdGhlIGxpc3QgaG93IHlvdSBwbGFuIHRvIHVzZSB0aGlzIGNsaWVu dCBhc3NlcnRpb24gYXV0aGVudGljYXRpb24gc2NoZW1lPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XaGljaCBv ZiB0aGUgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlcyB5b3Ugd2lsbCB1c2UgaXQgd2l0aD88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+V2lsbCB5b3UgdXNlIGl0IHdpdGggdGhlIGF1dGhvcml6YXRpb24gZW5kcG9p bnQsIGFuZCBpZiBzbywgaG93IHdpbGwgeW91IGJpbmQgdGhlIGFzc2VydGlvbiB0byB0aGUgY2xp ZW50X2lkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5DYW4geW91IHByb3ZpZGUgZnVsbCBleGFtcGxlcyBvZiBh c3NlcnRpb25zIGFuZCBIVFRQIHJlcXVlc3RzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SXQgd291bGQgYmUgaGVscGZ1bCB0byBzZWUgaG93IGZhciBhcGFydCB0aGUgcHJv cG9zZWQgdGV4dCBiZWxvdyBpcyBmcm9tIGFuIGFjdHVhbCBpbXBsZW1lbnRhdGlvbiBtYWtpbmcg dXNlIG9mIGl0LiBJIGV4Y2VwdCB0byBzZWUgdGhlc2UgYW5zd2VycyBpbiBhbnkgcXVhbGl0eSBk b2N1bWVudCBkZWZpbmluZyBhIG5ldyBjbGllbnQgYXV0aGVudGljYXRpb24gc2NoZW1lDQogKHdo aWNoIGlzIHRydWUgZm9yIHRoZSBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gdGhyb3Vn aG91dCB0aGUgZG9jdW1lbnQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ RUhMPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBB bnRob255IE5hZGFsaW4NCjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0 LmNvbV0iPlttYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tXTwvYT4NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDI1LCAyMDExIDM6NTggUE08YnI+DQo8Yj5Ubzo8L2I+IEVy YW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRzsgPGEgaHJlZj0ibWFpbHRvOkhhbm5lcy5Uc2Nob2Zl bmlnQGdteC5uZXQiPg0KSGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldDwvYT47IEJsYWluZSBDb29r PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRl bnRpYWxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ SSBkb24ndCB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9yIHJlbW92aW5nIHRoZSBjbGllbnQg YXNzZXJ0aW9uIGNyZWRlbnRpYWxzLCBhcyBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24g aXMgbGVmdCBpbi4gQ2xpZW50IFBhc3N3b3JkIEF1dGhlbnRpY2F0aW9uIGlzIGFsc28gdW5kZXJz cGVjaWZpZWQgYXMgY2xpZW50X3NlY3JldCBjb3VsZCBiZSBhbnl0aGluZyB0aGF0IHRoZSBhdXRo ZW50aWNhdGlvbg0KIHNlcnZlciBzZWVtcyBmaXQgKHJhdyBjbGVhciB0ZXh0IHBhc3N3b3JkLCZu YnNwOyBoYXNoLCBkaWdlc3QsIGV0Yy4pIGFuZCBubyB3YXkgdG8gZGV0ZXJtaW5lIHRoZSBjb250 ZW50LiBjbGllbnRfc2VjcmV0IGlzIGFsc28gYSB2ZXJ5IHdlYWsgbWVjaGFuaXNtLCBzaW5jZSB0 aGlzIGlzIGxlZnQgaW4gdGhlIGNvcmUgdGhpcyBsZWFkcyBtZSB0byBiZWxpZXZlIHRoYXQgdGhl cmUgaXMgc3VwcG9ydCBmb3IgaGF2aW5nIGNsaWVudCBhdXRoZW50aWNhdGlvbg0KIGluIE9hdXRo LiBJIGRvbid0IHNlZSBob3cgaGF2aW5nIGNsaWVudF9hc3NlcnRpb24gYW5kIGNsaWVudF9hc3Nl cnRpb25fdHlwZSB3b3VsZCBiZSBzb21ldGhpbmcgdGhhdCBpcyB1bmRlcnNwZWNpZmllZCBhcyBi ZWluZyBhIG1lY2hhbmlzbSBpbiB3aGljaCBhc3NlcnRpb25zIGNhbiBiZSB1c2VkIGZvciBhdXRo ZW50aWNhdGlvbi4gQWdyZWUgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyIGhhcyB0byBt YWtlIHJpZ2h0IGFuZCBkZWNsYXJlDQogd2hhdCBpcyBiZWluZyB1c2VkIGJ1dCB0aGF0IGlzIHRo ZSBzYW1lIGZvciBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXV0 aGVudGljYXRpb24gYXNzZXJ0aW9ucyBhcmUgc29tZXRoaW5nIHRoYXQgTWljcm9zb2Z0IGFuZCBH b29nbGUgZmluZCB1c2VmdWwgYW5kIHBsYW4gb24gaW1wbGVtZW50aW5nIGFuZCB1c2luZyBhcyBh IG1lYW5zIGZvciBzdHJvbmdlciBhdXRoZW50aWNhdGlvbiB0byB0aGUgYXV0aG9yaXphdGlvbg0K IHNlcnZlci4gVGhpcyBleHRlbnNpYmlsaXR5IGJlbG9uZ3MgaW4gdGhlIGNvcmUsIHRoZXJlIGlz IG5vIG90aGVyIHBsYWNlIHRvIHB1dCB0aGlzIGZ1bmN0aW9uYWxpdHkuIEkgZG9uJ3QgYmVsaWV2 ZSB0aGF0IHRoZSByZW1vdmFsIChlaXRoZXIgYnkgZWRpdG9yIG9yIGRpcmVjdGlvbiBieSBjby1j aGFpcikgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiBkb25lIHcvbyBhIGNvbnNl bnN1cyB2b3RlIHNpbmNlIHRoaXMgaGFzIGJlZW4NCiBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3Ig c29tZSB0aW1lIHdpdGhvdXQgaXNzdWUgYW5kIHRoZSByZW1vdmFsIGNvbWVzIGFzIGNvbXBsZXRl IHVud2VsY29tZSBzdXJwcmlzZS4gR2V0dGluZyBhbG1vc3QgdG90YWwgcmV3cml0ZXMgb2YgdGhl IHNwZWNpZmljYXRpb24gdGhpcyBsYXRlIGluIHRoZSByZXZpZXcgY3ljbGUgaXMgYWxzbyB2ZXJ5 IGRpc3R1cmJpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkEgcHJvcG9zYWwgZm9y IGtlZXBpbmcgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gd291bGQgYmUgdG8g c2ltcGxpZnkgdG8gdGhlIGZvbGxvd2luZzs8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBh cmUgdXNlZCBpbiBjYXNlcyB3aGVyZSBhIHBhc3N3b3JkIChjbGVhci10ZXh0IHNoYXJlZCBzeW1t ZXRyaWMgc2VjcmV0KSBpcyB1bnN1aXRhYmxlIG9yIGRvZXMgbm90IHByb3ZpZGUgc3VmZmljaWVu dCBzZWN1cml0eSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLg0KIFRoZSBjbGllbnQgYXNzZXJ0 aW9uIGNyZWRlbnRpYWxzIHByb3ZpZGUgYW4gZXh0ZW5zaWJsZSBtZWNoYW5pc20gdG8gdXNlIGFu IGFzc2VydGlvbiBmb3JtYXQgc3VwcG9ydGVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBm b3IgYXV0aGVudGljYXRpb24gb2YgdGhlIGNsaWVudC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Vc2luZyBhc3NlcnRpb25zIHJl cXVpcmVzIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFzc2VydGlvbiAoc3VjaCBhcyBhDQo8L3Nw YW4+PGEgaHJlZj0iI09BU0lTLnNhbWwtY29yZS0yLjAtb3MiPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O3RleHQtZGVjb3JhdGlvbjpub25lIj5TQU1MIChDYW50b3IsIFMuLCBLZW1wLCBKLiwgUGhpbHBv dHQsIFIuLCBhbmQgRS4gTWFsZXIsIOKAnEFzc2VydGlvbnMgYW5kIFByb3RvY29sIGZvciB0aGUg T0FTSVMgU2VjdXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAoU0FNTCkNCiBWMi4wLOKA nSBNYXJjaCZuYnNwOzIwMDUuKTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPltPQVNJUy5zYW1s4oCRY29y ZeKAkTIuMOKAkW9zXSBhc3NlcnRpb24pIGZyb20gYW4gYXNzZXJ0aW9uIGlzc3VlciBvciB0byBz ZWxmLWlzc3VlIGFuIGFzc2VydGlvbi4gVGhlIGFzc2VydGlvbiBmb3JtYXQsIHRoZSBwcm9jZXNz IGJ5IHdoaWNoIHRoZSBhc3NlcnRpb24gaXMgb2J0YWluZWQsIGFuZCB0aGUgbWV0aG9kIG9mDQog dmFsaWRhdGluZyB0aGUgYXNzZXJ0aW9uIGFyZSBkZWZpbmVkIGJ5IHRoZSBhc3NlcnRpb24gaXNz dWVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGFuZCBhcmUgYmV5b25kIHRoZSBzY29w ZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+V2hlbiB1c2luZyBhIGNsaWVudCBhc3NlcnRp b24sIHRoZSBjbGllbnQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjYwLjBwdDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4t bGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5jbGllbnRfYXNzZXJ0aW9uX3R5cGUgLSBSRVFVSVJFRC4gVGhlIGZvcm1h dCBvZiB0aGUgYXNzZXJ0aW9uIGFzIGRlZmluZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVy LiBUaGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0ZSBVUkkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjQuMHB0O3RleHQt aW5kZW50Oi41aW4iPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5jbGllbnRfYXNz ZXJ0aW9uIC0gUkVRVUlSRUQuIFRoZSBjbGllbnQgYXNzZXJ0aW9uLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJk YW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZvciBleGFtcGxl LCB0aGUgY2xpZW50IHNlbmRzIHRoZSBmb2xsb3dpbmcgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXNp bmcgYSBTQU1MIDIuMCBhc3NlcnRpb24gdG8gYXV0aGVudGljYXRlIGl0c2VsZiAobGluZSBicmVh a3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MjQuMHB0 O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIGxhbmc9IkVOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjI0LjBwdDttYXJnaW4t Ym90dG9tOjBpbjttYXJnaW4tbGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48c3Bh biBsYW5nPSJFTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOIj4mbmJzcDsgUE9TVCAvdG9rZW4gSFRUUC8xLjE8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjI0LjBw dDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTouMDAw MXB0Ij48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7IEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7IENvbnRlbnQt VHlwZTogYXBwbGljYXRpb24veC13d3ctZm9ybS11cmxlbmNvZGVkPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyBncmFudF90eXBlPWF1dGhvcml6YXRpb25f Y29kZSZhbXA7Y29kZT1pMVdzUm4xdUIxJmFtcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4iPiZuYnNwOyBjbGllbnRfYXNzZXJ0aW9uPVBITmhiV3h3T2xbLi4u b21pdHRlZCBmb3IgYnJldml0eS4uLl1aVDQlM0QmYW1wOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7IGNsaWVudF9hc3NlcnRpb25fdHlwZT0gJm5i c3A7dXJuJTNBb2FzaXMlM0FuYW1lcyVzQXRjJTNBU0FNTCUzQTIuMCUzQWFzc2VydGlvbiZhbXA7 cmVkaXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6NjAuMHB0 O21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gbGFuZz0iRU4iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4NCjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1i b3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86W21haWx0bzpvYXV0aC1ib3VuY2Vz QGlldGYub3JnXSI+DQpbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddPC9hPiA8Yj5PbiBC ZWhhbGYgT2YgPC9iPkVyYW4gSGFtbWVyLUxhaGF2PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwg SmFudWFyeSAxNCwgMjAxMSAxMDo0NSBQTTxicj4NCjxiPlRvOjwvYj4gT0F1dGggV0c8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRl bnRpYWxzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3 b3VsZCBsaWtlIHRvIHN1Z2dlc3Qgd2UgZHJvcCB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50 aWFscyAoLTExIHNlY3Rpb24gMy4yKSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uLCBhbmQgaWYgbmVl ZGVkLCBwdWJsaXNoIGl0IGFzIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIGZvbGxv d2luZyByZWFzb25zOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+VGhlIG1lY2hhbmlzbSBpcyB1bmRl ciBzcGVjaWZpZWQsIGVzcGVjaWFsbHkgaW4gaXRzIGhhbmRsaW5nIG9mIHRoZSBjbGllbnRfaWQg aWRlbnRpZmllciAod2hlbiB1c2VkIHRvIG9idGFpbiBlbmQtdXNlciBhdXRob3JpemF0aW9uKS4g SXQgZG9lcyBub3QgY29udGFpbiBhbnkgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byBhY2NvbXBs aXNoIGFueSBsZXZlbCBvZiBpbnRlcm9wZXJhYmlsaXR5IG9yIGZ1bmN0aW9uYWxpdHkuDQogVGhp cyBpcyBpbiBjb250cmFzdCB0byB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUgd2hpY2ggaGFzIG1h dHVyZWQgb3ZlciBhIHllYXIgaW50byBhIGZ1bGx5IHRob3VnaHQtb3V0IGV4dGVuc2lvbiBtZWNo YW5pc20sIGFzIHdlbGwgYXMgYSBzZXBhcmF0ZSBTQU1MIGFzc2VydGlvbiBzcGVjaWZpY2F0aW9u IHdpdGggYWN0aXZlIGRlcGxveW1lbnQgKHRoZSB0d28sIHRvZ2V0aGVyIHdpdGggcnVubmluZyBj b2RlLCBzaG93IGNsZWFyIGNvbnNlbnN1cykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+VGhlIHNlY3Rpb24gaXMgYSBjb25mdXNlZCBtaXggb2Ygc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgc3ByaW5rbGVkIHdpdGggbm9ybWF0aXZlIGxhbmd1YWdlLiBJbnN0ZWFkLCBpdCBzaG91 bGQgYmUgcmVwbGFjZWQgd2l0aCBndWlkZWxpbmVzIGZvciBleHRlbmRpbmcgdGhlIHNldCBvZiBz dXBwb3J0ZWQgY2xpZW50IGNyZWRlbnRpYWxzLCBidXQgd2l0aG91dCBkZWZpbmluZyBhIG5ldyBy ZWdpc3RyeS4gSXQNCiBpcyBjbGVhcmx5IGFuIGFyZWEgb2YgbGl0dGxlIGRlcGxveW1lbnQgZXhw ZXJpZW5jZSBmb3IgT0F1dGgsIGFuZCB0aGF0IGluY2x1ZGVzIHVzaW5nIEhUVFAgQmFzaWMgYXV0 aGVudGljYXRpb24gZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAobW9yZSBvbiB0aGF0IHRvIGNv bWUpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0 ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBzZWN0aW9uIGhhcyBy ZWNlaXZlZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3NlIHdo byBzdGlsbCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkgY29u c2Vuc3VzIGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBvcnQg Zm9yIGRlcGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsDQogYWxzbyByZXF1 aXJlIHNob3dpbmcgcHJvZ3Jlc3Mgb24gcHVibGljIHNwZWNpZmljYXRpb25zIHByb2ZpbGluZyB0 aGUgbWVjaGFuaXNtIGludG8gYSB1c2VmdWwgaW50ZXJvcGVyYWJsZSBmZWF0dXJlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Db21tZW50cz8gQ291bnRlci1hcmd1bWVudHM/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkVITDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_180155C5EA10854997314CA5E063D18F033B181BTK5EX14MBXC111r_-- From phil.hunt@oracle.com Fri Jan 28 12:13:40 2011 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 D10DC3A6930 for ; Fri, 28 Jan 2011 12:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock25=0.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 sUg35nmk3-DK for ; Fri, 28 Jan 2011 12:13:38 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 0E13E3A6855 for ; Fri, 28 Jan 2011 12:13:38 -0800 (PST) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0SKGaF9008722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 28 Jan 2011 20:16:38 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0SJ8mQv012333; Fri, 28 Jan 2011 20:16:35 GMT Received: from abhmt015.oracle.com by acsmt353.oracle.com with ESMTP id 1003534231296245793; Fri, 28 Jan 2011 12:16:33 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jan 2011 12:16:32 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-9-111010945 From: Phil Hunt In-Reply-To: <180155C5EA10854997314CA5E063D18F033B181B@TK5EX14MBXC111.redmond.corp.microsoft.com> Date: Fri, 28 Jan 2011 12:16:30 -0800 Message-Id: References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6250D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033B0798@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62753@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033B181B@TK5EX14MBXC111.redmond.corp.microsoft.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 28 Jan 2011 20:13:40 -0000 --Apple-Mail-9-111010945 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tony, I'm not totally understanding what the issue is as far as impact on = code. My understanding was that the removal simply took it out of the = standard but is still covered by "other authentication mechanism". Thus = no impact on code -- you can still use (as we will) the client_assertion = form parameter. That said, I very much agree with your concerns. It may be worthwhile for us to work on a profile that lays out the = specifics of using client_assertion or client_token in a separate = specification. Just as there will be multiple access token formats, I = expect to see multiple client authentication methods. Maybe client auth = methods should also be defined in a registry? Though, I don't see this = as necessarily an OAuth specific issue. There's a much broader = requirement for defining client auth beyond Basic, Digest, Mutual SSL, = etc for non-browser clients.=20 As for value with OAuth, I think OAuth describe an important "pattern" = and won't have much general impact on inter-operability as a standard. = Thus doesn't undervalue the standard that much as it lays a foundation = for other components. The key working inter-op components will likely = have be defined in subsequent related specs such as suggested above. What is not clear to me yet is what should the discovery and = registration components for OAuth be? How much should be defined in = deployment documentation? Deployment documentation is problematic for = development tools. For example, building a .Net or Java platform is much = different than a one time developer who just wants to access a single = google, facebook, etc service. In contrast, .Net/Java tools can't help = much since they can't inspect the service.=20 I agree, too much emphasis is on deployment docs for use of OAuth. Phil phil.hunt@oracle.com On 2011-01-28, at 11:55 AM, Anthony Nadalin wrote: > I said its =E2=80=9Cbecoming=E2=80=9D useless as more and more stuff = is being removed. > =20 > Maybe you did not understand or I did not tell you everything you = needed to know, we have endpoints that expect assertions along with the = grant_type of authorization_code and we also have endpoints that expect = the grant_type of URI (or the assertion, which could be whatever the = authorization server decides), these are 2 different endpoints with 2 = different functions. The change that was made to remove the notion of = client assertion credentials only left us with the extension so we can = live with the changes to the extension (it is a code change for us) but = not removal of client assertion credentials we can=E2=80=99t live with = as we are using the notion of client credentials. I=E2=80=99m not sure = that putting this in the bearer token specification would work. > =20 > =20 > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 > Sent: Wednesday, January 26, 2011 2:51 PM > To: Anthony Nadalin > Cc: OAuth WG > Subject: RE: Removal: Client Assertion Credentials > =20 > Can you explain how having to define *two* extension parameters makes = the specification useless? The bearer token specification is going to = define its corresponding WWW-Authenticate header, to match its already = defined Authorization header. The scheme name is just style and branding = and have absolutely no technical impact. I am honestly confused by your = comments, as I was in the past when you declared the entire protocol = useless because of my objections to an under-defined scope parameter. > =20 > Can you point me where in WRAP are the client assertion credentials = defined? I can only find the assertion profile which is comparable to = the extension grant type with the SAML assertion extension (where the = assertion parameter is defined and registered). The concept of the = client assertion used for client authentication (separate from the = authorization grant) is new and was added based on a proposal from Yaron = in -11 on December 1st, 2010. > =20 > As for your additional details below (thanks!), it seems like you are = not using the client assertion credentials at all but using a simple = extension grant with an assertion, exactly like the SAML extension grant = specification, only you are not limited to SAML 2.0. Is that correct? If = this is correct, then the only issue here is our decision (which was = made without any comment from you or those now raising issues about = this) to move the =E2=80=98assertion=E2=80=99 parameter and rename the = grant type from assertion to extension (which has no implementation = impact). All we did is relocate the assertion parameter because it = doesn=E2=80=99t always apply to extension grants. > =20 > Is this just a confusion about what was being removed and where it = went? > =20 > EHL > =20 > =20 > From: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 > Sent: Wednesday, January 26, 2011 1:52 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: Removal: Client Assertion Credentials > =20 > Maybe this was the plan all along but specification is becoming = useless for our scenarios and will require that we have to go well = beyond the core specification to make things work, the client assertion = credentials being a prime example. The client assertion credentials has = been around for a while as it was a requirement for WRAP, then dropped = when the various specs got merged to form OAUTH 2.0 and then came back = into the OAUTH 2.0 and then has gone through various changes since = version 6 for the worse. There has been much discussion in July/August = over this and new text was proposed, but that seems to not be fully = accepted, but I think that follows the path when you want to remove = something. > =20 > Our usage will be via bearer token assertions only (at this time) > The grant_type would be the URI of the assertion type being used > The authorization endpoint can use what it wants to bind the assertion = to the client_id, much like it has to today for the password = authentication, as we have scenarios were client_id have multiple = passwords > We use guidance from security consideration section of the assertion = type being used along with the guidance from the bearer token = specification > If needed I can capture the assertions and requests, but not sure what = the point of this is at this time since this is not required for the = password credentials > =20 > Sure we can add the client authentication assertion to the bearer = token specification but I don=E2=80=99t think that is the proper place = to do thus but since it=E2=80=99s gone from the core we will have to do = just that. The same seems to happen with the HTTP Authentication Scheme = as it seems to be repeated in follow-on companion specifications. While = oauth-v2 is not an authentication protocol there is a requirement for = authentication to address security concerns. There is clear separation = between authentication and authorization; we are not suggesting that = authentication is appropriate facility to negotiate authorization. I = think that it makes sense to include a scheme in the core and have the = particular follow-on companion specifications (the various token = specifications) state/define the parameters and if they don=E2=80=99t = like the default scheme let them define a new scheme but this puts a = stake in the ground for an HTTP Authentication Scheme. > =20 > =20 > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 > Sent: Tuesday, January 25, 2011 5:38 PM > To: Anthony Nadalin > Cc: OAuth WG > Subject: RE: Removal: Client Assertion Credentials > =20 > Can you share with the list how you plan to use this client assertion = authentication scheme? > Which of the authorization grant types you will use it with? > Will you use it with the authorization endpoint, and if so, how will = you bind the assertion to the client_id? > Can you provide full examples of assertions and HTTP requests? > =20 > It would be helpful to see how far apart the proposed text below is = from an actual implementation making use of it. I except to see these = answers in any quality document defining a new client authentication = scheme (which is true for the client password authentication throughout = the document). > =20 > EHL > =20 > =20 > From: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 > Sent: Tuesday, January 25, 2011 3:58 PM > To: Eran Hammer-Lahav; OAuth WG; Hannes.Tschofenig@gmx.net; Blaine = Cook > Subject: RE: Removal: Client Assertion Credentials > =20 > I don't understand the rationale for removing the client assertion = credentials, as client password authentication is left in. Client = Password Authentication is also underspecified as client_secret could be = anything that the authentication server seems fit (raw clear text = password, hash, digest, etc.) and no way to determine the content. = client_secret is also a very weak mechanism, since this is left in the = core this leads me to believe that there is support for having client = authentication in Oauth. I don't see how having client_assertion and = client_assertion_type would be something that is underspecified as being = a mechanism in which assertions can be used for authentication. Agree = that the authentication server has to make right and declare what is = being used but that is the same for client password authentication. The = client authentication assertions are something that Microsoft and Google = find useful and plan on implementing and using as a means for stronger = authentication to the authorization server. This extensibility belongs = in the core, there is no other place to put this functionality. I don't = believe that the removal (either by editor or direction by co-chair) is = something that should have been done w/o a consensus vote since this has = been in the specification for some time without issue and the removal = comes as complete unwelcome surprise. Getting almost total rewrites of = the specification this late in the review cycle is also very disturbing. > =20 > A proposal for keeping the client authentication assertion would be to = simplify to the following; > The client assertion credentials are used in cases where a password = (clear-text shared symmetric secret) is unsuitable or does not provide = sufficient security for client authentication. The client assertion = credentials provide an extensible mechanism to use an assertion format = supported by the authorization server for authentication of the client. >=20 > Using assertions requires the client to obtain an assertion (such as a = SAML (Cantor, S., Kemp, J., Philpott, R., and E. Maler, =E2=80=9CAssertion= s and Protocol for the OASIS Security Assertion Markup Language (SAML) = V2.0,=E2=80=9D March 2005.)[OASIS.saml=E2=80=91core=E2=80=912.0=E2=80=91os= ] assertion) from an assertion issuer or to self-issue an assertion. The = assertion format, the process by which the assertion is obtained, and = the method of validating the assertion are defined by the assertion = issuer and the authorization server, and are beyond the scope of this = specification. >=20 > When using a client assertion, the client includes the following = parameters: >=20 > client_assertion_type - REQUIRED. The format of the assertion as = defined by the authorization server. The value MUST be an absolute URI. > client_assertion - REQUIRED. The client assertion. > For example, the client sends the following access token request using = a SAML 2.0 assertion to authenticate itself (line breaks are for display = purposes only): >=20 > =20 > =20 > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > =20 > grant_type=3Dauthorization_code&code=3Di1WsRn1uB1& > client_assertion=3DPHNhbWxwOl[...omitted for brevity...]ZT4%3D& > client_assertion_type=3D = urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&redirect_uri=3Dhttps%3A%= 2F%2Fclient%2Eexample%2Ecom%2Fcb > =20 > =20 > =20 > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer-Lahav > Sent: Friday, January 14, 2011 10:45 PM > To: OAuth WG > Subject: [OAUTH-WG] Removal: Client Assertion Credentials > =20 > I would like to suggest we drop the client assertion credentials (-11 = section 3.2) from the specification, and if needed, publish it as a = separate specification for the following reasons: > =20 > 1. The mechanism is under specified, especially in its handling = of the client_id identifier (when used to obtain end-user = authorization). It does not contain any implementation details to = accomplish any level of interoperability or functionality. This is in = contrast to the assertion grant type which has matured over a year into = a fully thought-out extension mechanism, as well as a separate SAML = assertion specification with active deployment (the two, together with = running code, show clear consensus). > 2. The section is a confused mix of security considerations = sprinkled with normative language. Instead, it should be replaced with = guidelines for extending the set of supported client credentials, but = without defining a new registry. It is clearly an area of little = deployment experience for OAuth, and that includes using HTTP Basic = authentication for client authentication (more on that to come). > 3. The section has received a little support and a little = objection. Those who still want to advocate for it need to show not only = consensus for keeping it, but also active community support for = deploying it. Deployment, of course, will also require showing progress = on public specifications profiling the mechanism into a useful = interoperable feature. > =20 > Comments? Counter-arguments? > =20 > EHL > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-9-111010945 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

It may be = worthwhile for us to work on a profile that lays out the specifics of = using client_assertion or client_token in a separate specification. Just = as there will be multiple access token formats, I expect to see multiple = client authentication methods.  Maybe client auth methods should = also be defined in a registry? Though, I don't see this as necessarily = an OAuth specific issue. There's a much broader requirement for defining = client auth beyond Basic, Digest, Mutual SSL, etc for non-browser = clients. 

As for value with OAuth, I think = OAuth describe an important "pattern" and won't have much general impact = on inter-operability as a standard. Thus doesn't undervalue the standard = that much as it lays a foundation for other components. The key working = inter-op components will likely have be defined in subsequent related = specs such as suggested above.

What is not = clear to me yet is what should the discovery and registration components = for OAuth be? How much should be defined in deployment documentation? = Deployment documentation is problematic for development tools. For = example, building a .Net or Java platform is much different than a one = time developer who just wants to access a single google, facebook, etc = service.  In contrast, .Net/Java tools can't help much since they = can't inspect the service. 

I agree, too = much emphasis is on deployment docs for use of = OAuth.


On 2011-01-28, at 11:55 AM, Anthony Nadalin = wrote:

I said its =E2=80=9Cbecoming=E2=80=9D useless as = more and more stuff is being removed.
Maybe you did not understand or I did not tell you = everything you needed to know, we have endpoints that expect assertions = along with the grant_type of authorization_code and we also have = endpoints that expect the grant_type of URI (or the assertion, which = could be whatever the authorization server decides), these are 2 = different endpoints with 2 different functions. The change that was made = to remove the notion of client assertion credentials only left us with = the extension so we can live with the changes to the extension (it is a = code change for us) but not removal of client assertion credentials we = can=E2=80=99t live with as we are using the notion of client = credentials. I=E2=80=99m not sure that putting this in the bearer token = specification would work.
 
 Eran = Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Wednesday, January 26, 2011 = 2:51 PM
To: Anthony = Nadalin
Cc: OAuth = WG
Subject: RE: Removal: Client = Assertion Credentials
 
Can you explain how having to define *two* = extension parameters makes the specification useless? The bearer token = specification is going to define its corresponding WWW-Authenticate = header, to match its already defined Authorization header. The scheme = name is just style and branding and have absolutely no technical impact. = I am honestly confused by your comments, as I was in the past when you = declared the entire protocol useless because of my objections to an = under-defined scope parameter.
Can you point me where in WRAP are the client = assertion credentials defined? I can only find the assertion profile = which is comparable to the extension grant type with the SAML assertion = extension (where the assertion parameter is defined and registered). The = concept of the client assertion used for client authentication (separate = from the authorization grant) is new and was added based on a proposal = from Yaron in -11 on December 1st, = 2010.
 
As for your = additional details below (thanks!), it seems like you are not using the = client assertion credentials at all but using a simple extension grant = with an assertion, exactly like the SAML extension grant specification, = only you are not limited to SAML 2.0. Is that correct? If this is = correct, then the only issue here is our decision (which was made = without any comment from you or those now raising issues about this) to = move the =E2=80=98assertion=E2=80=99 parameter and rename the grant type = from assertion to extension (which has no implementation impact). All we = did is relocate the assertion parameter because it doesn=E2=80=99t = always apply to extension grants.
Is this just a confusion about what was being = removed and where it went?
EHL
 
 Anthony = Nadalin [mailto:tonynad@microsoft.com] 
Sent: Wednesday, January 26, 2011 = 1:52 PM
To: Eran = Hammer-Lahav
Cc: OAuth = WG
Subject: RE: Removal: Client = Assertion Credentials
 
Maybe this was the plan all along but specification = is becoming useless for our scenarios and will require that we have to = go well beyond the core specification to make things work, the client = assertion credentials being a prime example. The client assertion = credentials has been around for a while as it was a requirement for = WRAP, then dropped when the various specs got merged to form OAUTH 2.0 = and then came back into the OAUTH 2.0 and then has gone through various = changes since version 6 for the worse. There has been much discussion in = July/August over this and new text was proposed, but that seems to not = be fully accepted, but I think that follows the path when you want to = remove something.
 
Our usage will be = via bearer token assertions only (at this = time)
The grant_type would be the URI of the assertion = type being used
The authorization endpoint can use what it wants to = bind the assertion to the client_id, much like it has to today for the = password authentication, as we have scenarios were client_id have = multiple passwords
We use guidance from security = consideration section of the assertion type being used along with the = guidance from the bearer token specification
If needed I can = capture the assertions and requests, but not sure what the point of this = is at this time since this is not required for the password = credentials
 
Sure we can add = the client authentication assertion to the bearer token specification = but I don=E2=80=99t think that is the proper place to do thus but since = it=E2=80=99s gone from the core we will have to do just that. The same = seems to happen with the HTTP Authentication Scheme as it seems to be = repeated in follow-on companion specifications. While oauth-v2 is not an = authentication protocol there is a requirement for authentication to = address security concerns. There is clear separation between = authentication and authorization; we are not suggesting that = authentication is appropriate facility to negotiate authorization. I = think that it makes sense to include a scheme in the core and have the = particular follow-on companion specifications (the various token = specifications) state/define the parameters and if they don=E2=80=99t = like the default scheme let them define a new scheme but this puts a = stake in the ground for an HTTP Authentication = Scheme.
 
From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Tuesday, January 25, 2011 = 5:38 PM
To: Anthony = Nadalin
Cc: OAuth = WG
Subject: RE: Removal: Client = Assertion Credentials
 
Can you share with the list how you plan to use this = client assertion authentication scheme?
Which of the = authorization grant types you will use it = with?
Will you use it with the authorization endpoint, and = if so, how will you bind the assertion to the = client_id?
Can you provide full examples of assertions and HTTP = requests?
 
It would be = helpful to see how far apart the proposed text below is from an actual = implementation making use of it. I except to see these answers in any = quality document defining a new client authentication scheme (which is = true for the client password authentication throughout the = document).
 
 
 Anthony = Nadalin [mailto:tonynad@microsoft.com] 
Sent: Tuesday, January 25, 2011 = 3:58 PM
To: Eran Hammer-Lahav; OAuth = WG; Hannes.Tschofenig@gmx.net; Blaine = Cook
Subject: RE: Removal: Client = Assertion Credentials
 
I don't understand the = rationale for removing the client assertion credentials, as client = password authentication is left in. Client Password Authentication is = also underspecified as client_secret could be anything that the = authentication server seems fit (raw clear text password,  hash, = digest, etc.) and no way to determine the content. client_secret is also = a very weak mechanism, since this is left in the core this leads me to = believe that there is support for having client authentication in Oauth. = I don't see how having client_assertion and client_assertion_type would = be something that is underspecified as being a mechanism in which = assertions can be used for authentication. Agree that the authentication = server has to make right and declare what is being used but that is the = same for client password authentication. The client authentication = assertions are something that Microsoft and Google find useful and plan = on implementing and using as a means for stronger authentication to the = authorization server. This extensibility belongs in the core, there is = no other place to put this functionality. I don't believe that the = removal (either by editor or direction by co-chair) is something that = should have been done w/o a consensus vote since this has been in the = specification for some time without issue and the removal comes as = complete unwelcome surprise. Getting almost total rewrites of the = specification this late in the review cycle is also very = disturbing.
 
A proposal for keeping the client authentication assertion = would be to simplify to the following;

The client = assertion credentials are used in cases where a password (clear-text = shared symmetric secret) is unsuitable or does not provide sufficient = security for client authentication. The client assertion credentials = provide an extensible mechanism to use an assertion format supported by = the authorization server for authentication of the = client.

Using assertions requires the client to obtain an = assertion (such as a SAML (Cantor, S., Kemp, = J., Philpott, R., and E. Maler, =E2=80=9CAssertions and Protocol for the = OASIS Security Assertion Markup Language (SAML) V2.0,=E2=80=9D = March 2005.)[OASIS.saml=E2=80=91core=E2=80=912.0= =E2=80=91os] assertion) from an assertion issuer or to self-issue an = assertion. The assertion format, the process by which the assertion is = obtained, and the method of validating the assertion are defined by the = assertion issuer and the authorization server, and are beyond the scope = of this specification.

When using a client assertion, the client = includes the following parameters:

client_assertion_type - REQUIRED. The format of the = assertion as defined by the authorization server. The value MUST be an = absolute URI.
For example, the client sends the following access token = request using a SAML 2.0 assertion to authenticate itself (line breaks = are for display purposes only):

 
 
  POST =
/token HTTP/1.1
  Host:   Content-Type: =
application/x-www-form-urlencoded
 
  =
grant_type=3Dauthorization_code&code=3Di1WsRn1uB1&
  =
client_assertion=3DPHNhbWxwOl[...omitted for =
brevity...]ZT4%3D&
  client_assertion_type=3D =
 urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&redirect_uri=3D=
https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
 
 oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran = Hammer-Lahav
Sent: Friday, January 14, 2011 = 10:45 PM
To: OAuth = WG
Subject: [OAUTH-WG] Removal: Client = Assertion Credentials
 
I would like to suggest we = drop the client assertion credentials (-11 section 3.2) from the = specification, and if needed, publish it as a separate specification for = the following reasons:
 
1. The mechanism = is under specified, especially in its handling of the client_id = identifier (when used to obtain end-user authorization). It does not = contain any implementation details to accomplish any level of = interoperability or functionality. This is in contrast to the assertion = grant type which has matured over a year into a fully thought-out = extension mechanism, as well as a separate SAML assertion specification = with active deployment (the two, together with running code, show clear = consensus).
       The section = is a confused mix of security considerations sprinkled with normative = language. Instead, it should be replaced with guidelines for extending = the set of supported client credentials, but without defining a new = registry. It is clearly an area of little deployment experience for = OAuth, and that includes using HTTP Basic authentication for client = authentication (more on that to come).
3. The section = has received a little support and a little objection. Those who still = want to advocate for it need to show not only consensus for keeping it, = but also active community support for deploying it. Deployment, of = course, will also require showing progress on public specifications = profiling the mechanism into a useful interoperable = feature.
 
Comments? Counter-arguments?
 
EHL
 
OAuth@ietf.org
Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 28 Jan 2011 20:58:35 -0000 --_000_C9686EA51024Deranhueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgYWRkaXRpb25hbCBkZXRhaWxzLg0KDQpJIGFncmVlIHRoYXQgaW5jbHVk aW5nIHRoZSB0d28gcGFyYW1ldGVycyBpbiB0aGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24g bWFrZXMgbm8gc2Vuc2UgYXQgYWxsLg0KDQpJIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB5b3UgdGFr ZSB0aGUgcHJvcG9zZWQgbGFuZ3VhZ2UsIGV4cGFuZCBpdCBidXkgaW5jbHVkaW5nIG1vcmUgZGV0 YWlscyBndWlkZWxpbmVzIGZvciB0aGUgYmluZGluZyBvZiB0aGUgY2xpZW50X2lkIHRvIHRoZSBh c3NlcnRpb24sIGFuZCBkZWZpbmUgYXQgbGVhc3Qgb25lIHVzZWZ1bCBwcm9maWxlIGJhc2VkIG9u IHlvdXIgY3VycmVudCBkZXBsb3ltZW50IHN1Y2ggYXMgYSBTQU1MIDIuMCBjbGllbnQgYXNzZXJ0 aW9uLiBUaGlzIHdpbGwgYmUgcHVibGlzaGVkIGluIGEgbmV3IEktRCB3aXRoIGEgd2VsbCBkZWZp bmVkIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBmb2N1c2VkIHNvbGVseSBvbiB0aGUg dXNlIG9mIGNsaWVudCBhc3NlcnRpb25zIGZvciBhdXRoZW50aWNhdGluZyB0aGUgY2xpZW50LiBP bmNlIHlvdSBoYXZlIHRoaXMgZG9jdW1lbnQgcHVibGlzaGVkLCB0aGUgd29ya2luZyBncm91cCBj YW4gaGF2ZSBhIHF1aWNrIGNvbnNlbnN1cyBjYWxsIHRvIGRvIG9uZSBvZiB0aHJlZSBvcHRpb25z Og0KDQoNCiAxLiAgRGVjaWRlIHRvIGluY29ycG9yYXRlIHRoZSBkcmFmdCBpbnRvIHYyIGdpdmVu IGl0cyBzdWZmaWNpZW50IGRldGFpbHMsIHNwZWNpZmljaXR5LCBleGFtcGxlcywgYW5kIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zLiBXZSBoYXZlIGFib3V0IDItMyBtb250aHMgd2luZG93IHRvIG1h a2UgdGhpcyBjaGFuZ2UgYmVmb3JlIHNoaXBwaW5nIHRoZSBzcGVjIHRvIGFuIElFVEYgTEMuIFRo aXMgd2lsbCByZXF1aXJlIGEgZHJhZnQgcHVibGlzaGVkIHdpdGhpbiBhIG1vbnRoLg0KIDIuICBE ZWNpZGUgdG8ga2VlcCBpdCBhcyBhIHN0YW5kYWxvbmUgZXh0ZW5zaW9uLCBidXQgYXMgYSBXRyBp dGVtLg0KIDMuICBEZWNpZGUgdG8ga2VlcCBpdCBhcyBhbiBpbmRpdmlkdWFsIHN1Ym1pc3Npb24g KHdpdGggSUFOQSByZWdpc3RyYXRpb24gb2YgdGhlIHR3byBuZXcgcGFyYW1ldGVycykuDQoNCkkg YW0gb3BlbiB0byBhbGwgdGhyZWUgb3B0aW9ucyBhbmQgd2lsbCBkbyBteSBiZXN0IHRvIHByb3Zp ZGUgZmVlZGJhY2sgYW5kIGFzc2lzdGFuY2UsIGFzIHNvb24gYXMgYSBuZXcgdGV4dCBpcyBwcm9w b3NlZCB0aGF0IGluY2x1ZGVzIHRoZSBhYm92ZSBkZXRhaWxzLg0KDQpFSEwNCg0KDQpPbiAxLzI4 LzExIDExOjU1IEFNLCAiQW50aG9ueSBOYWRhbGluIiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPiB3 cm90ZToNCg0KSSBzYWlkIGl0cyDigJxiZWNvbWluZ+KAnSB1c2VsZXNzIGFzIG1vcmUgYW5kIG1v cmUgc3R1ZmYgaXMgYmVpbmcgcmVtb3ZlZC4NCg0KTWF5YmUgeW91IGRpZCBub3QgdW5kZXJzdGFu ZCBvciBJIGRpZCBub3QgdGVsbCB5b3UgZXZlcnl0aGluZyB5b3UgbmVlZGVkIHRvIGtub3csIHdl IGhhdmUgZW5kcG9pbnRzIHRoYXQgZXhwZWN0IGFzc2VydGlvbnMgYWxvbmcgd2l0aCB0aGUgZ3Jh bnRfdHlwZSBvZiBhdXRob3JpemF0aW9uX2NvZGUgYW5kIHdlIGFsc28gaGF2ZSBlbmRwb2ludHMg dGhhdCBleHBlY3QgdGhlIGdyYW50X3R5cGUgb2YgVVJJIChvciB0aGUgYXNzZXJ0aW9uLCB3aGlj aCBjb3VsZCBiZSB3aGF0ZXZlciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVjaWRlcyksIHRo ZXNlIGFyZSAyIGRpZmZlcmVudCBlbmRwb2ludHMgd2l0aCAyIGRpZmZlcmVudCBmdW5jdGlvbnMu IFRoZSBjaGFuZ2UgdGhhdCB3YXMgbWFkZSB0byByZW1vdmUgdGhlIG5vdGlvbiBvZiBjbGllbnQg YXNzZXJ0aW9uIGNyZWRlbnRpYWxzIG9ubHkgbGVmdCB1cyB3aXRoIHRoZSBleHRlbnNpb24gc28g d2UgY2FuIGxpdmUgd2l0aCB0aGUgY2hhbmdlcyB0byB0aGUgZXh0ZW5zaW9uIChpdCBpcyBhIGNv ZGUgY2hhbmdlIGZvciB1cykgYnV0IG5vdCByZW1vdmFsIG9mIGNsaWVudCBhc3NlcnRpb24gY3Jl ZGVudGlhbHMgd2UgY2Fu4oCZdCBsaXZlIHdpdGggYXMgd2UgYXJlIHVzaW5nIHRoZSBub3Rpb24g b2YgY2xpZW50IGNyZWRlbnRpYWxzLiBJ4oCZbSBub3Qgc3VyZSB0aGF0IHB1dHRpbmcgdGhpcyBp biB0aGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24gd291bGQgd29yay4NCg0KDQoNCkZyb206 IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgSmFudWFyeSAyNiwgMjAxMSAyOjUxIFBNDQpUbzogQW50aG9ueSBOYWRhbGluDQpD YzogT0F1dGggV0cNClN1YmplY3Q6IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRl bnRpYWxzDQoNCkNhbiB5b3UgZXhwbGFpbiBob3cgaGF2aW5nIHRvIGRlZmluZSAqdHdvKiBleHRl bnNpb24gcGFyYW1ldGVycyBtYWtlcyB0aGUgc3BlY2lmaWNhdGlvbiB1c2VsZXNzPyBUaGUgYmVh cmVyIHRva2VuIHNwZWNpZmljYXRpb24gaXMgZ29pbmcgdG8gZGVmaW5lIGl0cyBjb3JyZXNwb25k aW5nIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyLCB0byBtYXRjaCBpdHMgYWxyZWFkeSBkZWZpbmVk IEF1dGhvcml6YXRpb24gaGVhZGVyLiBUaGUgc2NoZW1lIG5hbWUgaXMganVzdCBzdHlsZSBhbmQg YnJhbmRpbmcgYW5kIGhhdmUgYWJzb2x1dGVseSBubyB0ZWNobmljYWwgaW1wYWN0LiBJIGFtIGhv bmVzdGx5IGNvbmZ1c2VkIGJ5IHlvdXIgY29tbWVudHMsIGFzIEkgd2FzIGluIHRoZSBwYXN0IHdo ZW4geW91IGRlY2xhcmVkIHRoZSBlbnRpcmUgcHJvdG9jb2wgdXNlbGVzcyBiZWNhdXNlIG9mIG15 IG9iamVjdGlvbnMgdG8gYW4gdW5kZXItZGVmaW5lZCBzY29wZSBwYXJhbWV0ZXIuDQoNCkNhbiB5 b3UgcG9pbnQgbWUgd2hlcmUgaW4gV1JBUCBhcmUgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVu dGlhbHMgZGVmaW5lZD8gSSBjYW4gb25seSBmaW5kIHRoZSBhc3NlcnRpb24gcHJvZmlsZSB3aGlj aCBpcyBjb21wYXJhYmxlIHRvIHRoZSBleHRlbnNpb24gZ3JhbnQgdHlwZSB3aXRoIHRoZSBTQU1M IGFzc2VydGlvbiBleHRlbnNpb24gKHdoZXJlIHRoZSBhc3NlcnRpb24gcGFyYW1ldGVyIGlzIGRl ZmluZWQgYW5kIHJlZ2lzdGVyZWQpLiBUaGUgY29uY2VwdCBvZiB0aGUgY2xpZW50IGFzc2VydGlv biB1c2VkIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gKHNlcGFyYXRlIGZyb20gdGhlIGF1dGhv cml6YXRpb24gZ3JhbnQpIGlzIG5ldyBhbmQgd2FzIGFkZGVkIGJhc2VkIG9uIGEgcHJvcG9zYWwg ZnJvbSBZYXJvbiBpbiAtMTEgb24gRGVjZW1iZXIgMXN0LCAyMDEwLg0KDQpBcyBmb3IgeW91ciBh ZGRpdGlvbmFsIGRldGFpbHMgYmVsb3cgKHRoYW5rcyEpLCBpdCBzZWVtcyBsaWtlIHlvdSBhcmUg bm90IHVzaW5nIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGF0IGFsbCBidXQgdXNp bmcgYSBzaW1wbGUgZXh0ZW5zaW9uIGdyYW50IHdpdGggYW4gYXNzZXJ0aW9uLCBleGFjdGx5IGxp a2UgdGhlIFNBTUwgZXh0ZW5zaW9uIGdyYW50IHNwZWNpZmljYXRpb24sIG9ubHkgeW91IGFyZSBu b3QgbGltaXRlZCB0byBTQU1MIDIuMC4gSXMgdGhhdCBjb3JyZWN0PyBJZiB0aGlzIGlzIGNvcnJl Y3QsIHRoZW4gdGhlIG9ubHkgaXNzdWUgaGVyZSBpcyBvdXIgZGVjaXNpb24gKHdoaWNoIHdhcyBt YWRlIHdpdGhvdXQgYW55IGNvbW1lbnQgZnJvbSB5b3Ugb3IgdGhvc2Ugbm93IHJhaXNpbmcgaXNz dWVzIGFib3V0IHRoaXMpIHRvIG1vdmUgdGhlIOKAmGFzc2VydGlvbuKAmSBwYXJhbWV0ZXIgYW5k IHJlbmFtZSB0aGUgZ3JhbnQgdHlwZSBmcm9tIGFzc2VydGlvbiB0byBleHRlbnNpb24gKHdoaWNo IGhhcyBubyBpbXBsZW1lbnRhdGlvbiBpbXBhY3QpLiBBbGwgd2UgZGlkIGlzIHJlbG9jYXRlIHRo ZSBhc3NlcnRpb24gcGFyYW1ldGVyIGJlY2F1c2UgaXQgZG9lc27igJl0IGFsd2F5cyBhcHBseSB0 byBleHRlbnNpb24gZ3JhbnRzLg0KDQpJcyB0aGlzIGp1c3QgYSBjb25mdXNpb24gYWJvdXQgd2hh dCB3YXMgYmVpbmcgcmVtb3ZlZCBhbmQgd2hlcmUgaXQgd2VudD8NCg0KRUhMDQoNCg0KDQpGcm9t OiBBbnRob255IE5hZGFsaW4gW21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dDQpTZW50OiBX ZWRuZXNkYXksIEphbnVhcnkgMjYsIDIwMTEgMTo1MiBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2 DQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENy ZWRlbnRpYWxzDQoNCk1heWJlIHRoaXMgd2FzIHRoZSBwbGFuIGFsbCBhbG9uZyBidXQgc3BlY2lm aWNhdGlvbiBpcyBiZWNvbWluZyB1c2VsZXNzIGZvciBvdXIgc2NlbmFyaW9zIGFuZCB3aWxsIHJl cXVpcmUgdGhhdCB3ZSBoYXZlIHRvIGdvIHdlbGwgYmV5b25kIHRoZSBjb3JlIHNwZWNpZmljYXRp b24gdG8gbWFrZSB0aGluZ3Mgd29yaywgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMg YmVpbmcgYSBwcmltZSBleGFtcGxlLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBo YXMgYmVlbiBhcm91bmQgZm9yIGEgd2hpbGUgYXMgaXQgd2FzIGEgcmVxdWlyZW1lbnQgZm9yIFdS QVAsIHRoZW4gZHJvcHBlZCB3aGVuIHRoZSB2YXJpb3VzIHNwZWNzIGdvdCBtZXJnZWQgdG8gZm9y bSBPQVVUSCAyLjAgYW5kIHRoZW4gY2FtZSBiYWNrIGludG8gdGhlIE9BVVRIIDIuMCBhbmQgdGhl biBoYXMgZ29uZSB0aHJvdWdoIHZhcmlvdXMgY2hhbmdlcyBzaW5jZSB2ZXJzaW9uIDYgZm9yIHRo ZSB3b3JzZS4gVGhlcmUgaGFzIGJlZW4gbXVjaCBkaXNjdXNzaW9uIGluIEp1bHkvQXVndXN0IG92 ZXIgdGhpcyBhbmQgbmV3IHRleHQgd2FzIHByb3Bvc2VkLCBidXQgdGhhdCBzZWVtcyB0byBub3Qg YmUgZnVsbHkgYWNjZXB0ZWQsIGJ1dCBJIHRoaW5rIHRoYXQgZm9sbG93cyB0aGUgcGF0aCB3aGVu IHlvdSB3YW50IHRvIHJlbW92ZSBzb21ldGhpbmcuDQoNCk91ciB1c2FnZSB3aWxsIGJlIHZpYSBi ZWFyZXIgdG9rZW4gYXNzZXJ0aW9ucyBvbmx5IChhdCB0aGlzIHRpbWUpDQpUaGUgZ3JhbnRfdHlw ZSB3b3VsZCBiZSB0aGUgVVJJIG9mIHRoZSBhc3NlcnRpb24gdHlwZSBiZWluZyB1c2VkDQpUaGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCBjYW4gdXNlIHdoYXQgaXQgd2FudHMgdG8gYmluZCB0aGUg YXNzZXJ0aW9uIHRvIHRoZSBjbGllbnRfaWQsIG11Y2ggbGlrZSBpdCBoYXMgdG8gdG9kYXkgZm9y IHRoZSBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiwgYXMgd2UgaGF2ZSBzY2VuYXJpb3Mgd2VyZSBj bGllbnRfaWQgaGF2ZSBtdWx0aXBsZSBwYXNzd29yZHMNCldlIHVzZSBndWlkYW5jZSBmcm9tIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBvZiB0aGUgYXNzZXJ0aW9uIHR5cGUgYmVpbmcg dXNlZCBhbG9uZyB3aXRoIHRoZSBndWlkYW5jZSBmcm9tIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lm aWNhdGlvbg0KSWYgbmVlZGVkIEkgY2FuIGNhcHR1cmUgdGhlIGFzc2VydGlvbnMgYW5kIHJlcXVl c3RzLCBidXQgbm90IHN1cmUgd2hhdCB0aGUgcG9pbnQgb2YgdGhpcyBpcyBhdCB0aGlzIHRpbWUg c2luY2UgdGhpcyBpcyBub3QgcmVxdWlyZWQgZm9yIHRoZSBwYXNzd29yZCBjcmVkZW50aWFscw0K DQpTdXJlIHdlIGNhbiBhZGQgdGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gdG8g dGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBp cyB0aGUgcHJvcGVyIHBsYWNlIHRvIGRvIHRodXMgYnV0IHNpbmNlIGl04oCZcyBnb25lIGZyb20g dGhlIGNvcmUgd2Ugd2lsbCBoYXZlIHRvIGRvIGp1c3QgdGhhdC4gVGhlIHNhbWUgc2VlbXMgdG8g aGFwcGVuIHdpdGggdGhlIEhUVFAgQXV0aGVudGljYXRpb24gU2NoZW1lIGFzIGl0IHNlZW1zIHRv IGJlIHJlcGVhdGVkIGluIGZvbGxvdy1vbiBjb21wYW5pb24gc3BlY2lmaWNhdGlvbnMuIFdoaWxl IG9hdXRoLXYyIGlzIG5vdCBhbiBhdXRoZW50aWNhdGlvbiBwcm90b2NvbCB0aGVyZSBpcyBhIHJl cXVpcmVtZW50IGZvciBhdXRoZW50aWNhdGlvbiB0byBhZGRyZXNzIHNlY3VyaXR5IGNvbmNlcm5z LiBUaGVyZSBpcyBjbGVhciBzZXBhcmF0aW9uIGJldHdlZW4gYXV0aGVudGljYXRpb24gYW5kIGF1 dGhvcml6YXRpb247IHdlIGFyZSBub3Qgc3VnZ2VzdGluZyB0aGF0IGF1dGhlbnRpY2F0aW9uIGlz IGFwcHJvcHJpYXRlIGZhY2lsaXR5IHRvIG5lZ290aWF0ZSBhdXRob3JpemF0aW9uLiBJIHRoaW5r IHRoYXQgaXQgbWFrZXMgc2Vuc2UgdG8gaW5jbHVkZSBhIHNjaGVtZSBpbiB0aGUgY29yZSBhbmQg aGF2ZSB0aGUgcGFydGljdWxhciBmb2xsb3ctb24gY29tcGFuaW9uIHNwZWNpZmljYXRpb25zICh0 aGUgdmFyaW91cyB0b2tlbiBzcGVjaWZpY2F0aW9ucykgc3RhdGUvZGVmaW5lIHRoZSBwYXJhbWV0 ZXJzIGFuZCBpZiB0aGV5IGRvbuKAmXQgbGlrZSB0aGUgZGVmYXVsdCBzY2hlbWUgbGV0IHRoZW0g ZGVmaW5lIGEgbmV3IHNjaGVtZSBidXQgdGhpcyBwdXRzIGEgc3Rha2UgaW4gdGhlIGdyb3VuZCBm b3IgYW4gSFRUUCBBdXRoZW50aWNhdGlvbiBTY2hlbWUuDQoNCg0KDQpGcm9tOiBFcmFuIEhhbW1l ci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51 YXJ5IDI1LCAyMDExIDU6MzggUE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBPQXV0aCBXRw0K U3ViamVjdDogUkU6IFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMNCg0KQ2Fu IHlvdSBzaGFyZSB3aXRoIHRoZSBsaXN0IGhvdyB5b3UgcGxhbiB0byB1c2UgdGhpcyBjbGllbnQg YXNzZXJ0aW9uIGF1dGhlbnRpY2F0aW9uIHNjaGVtZT8NCldoaWNoIG9mIHRoZSBhdXRob3JpemF0 aW9uIGdyYW50IHR5cGVzIHlvdSB3aWxsIHVzZSBpdCB3aXRoPw0KV2lsbCB5b3UgdXNlIGl0IHdp dGggdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIGFuZCBpZiBzbywgaG93IHdpbGwgeW91IGJp bmQgdGhlIGFzc2VydGlvbiB0byB0aGUgY2xpZW50X2lkPw0KQ2FuIHlvdSBwcm92aWRlIGZ1bGwg ZXhhbXBsZXMgb2YgYXNzZXJ0aW9ucyBhbmQgSFRUUCByZXF1ZXN0cz8NCg0KSXQgd291bGQgYmUg aGVscGZ1bCB0byBzZWUgaG93IGZhciBhcGFydCB0aGUgcHJvcG9zZWQgdGV4dCBiZWxvdyBpcyBm cm9tIGFuIGFjdHVhbCBpbXBsZW1lbnRhdGlvbiBtYWtpbmcgdXNlIG9mIGl0LiBJIGV4Y2VwdCB0 byBzZWUgdGhlc2UgYW5zd2VycyBpbiBhbnkgcXVhbGl0eSBkb2N1bWVudCBkZWZpbmluZyBhIG5l dyBjbGllbnQgYXV0aGVudGljYXRpb24gc2NoZW1lICh3aGljaCBpcyB0cnVlIGZvciB0aGUgY2xp ZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50KS4NCg0K RUhMDQoNCg0KDQpGcm9tOiBBbnRob255IE5hZGFsaW4gW21haWx0bzp0b255bmFkQG1pY3Jvc29m dC5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI1LCAyMDExIDM6NTggUE0NClRvOiBFcmFu IEhhbW1lci1MYWhhdjsgT0F1dGggV0c7IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ7IEJsYWlu ZSBDb29rDQpTdWJqZWN0OiBSRTogUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFs cw0KDQpJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBmb3IgcmVtb3ZpbmcgdGhlIGNs aWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMsIGFzIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNh dGlvbiBpcyBsZWZ0IGluLiBDbGllbnQgUGFzc3dvcmQgQXV0aGVudGljYXRpb24gaXMgYWxzbyB1 bmRlcnNwZWNpZmllZCBhcyBjbGllbnRfc2VjcmV0IGNvdWxkIGJlIGFueXRoaW5nIHRoYXQgdGhl IGF1dGhlbnRpY2F0aW9uIHNlcnZlciBzZWVtcyBmaXQgKHJhdyBjbGVhciB0ZXh0IHBhc3N3b3Jk LCAgaGFzaCwgZGlnZXN0LCBldGMuKSBhbmQgbm8gd2F5IHRvIGRldGVybWluZSB0aGUgY29udGVu dC4gY2xpZW50X3NlY3JldCBpcyBhbHNvIGEgdmVyeSB3ZWFrIG1lY2hhbmlzbSwgc2luY2UgdGhp cyBpcyBsZWZ0IGluIHRoZSBjb3JlIHRoaXMgbGVhZHMgbWUgdG8gYmVsaWV2ZSB0aGF0IHRoZXJl IGlzIHN1cHBvcnQgZm9yIGhhdmluZyBjbGllbnQgYXV0aGVudGljYXRpb24gaW4gT2F1dGguIEkg ZG9uJ3Qgc2VlIGhvdyBoYXZpbmcgY2xpZW50X2Fzc2VydGlvbiBhbmQgY2xpZW50X2Fzc2VydGlv bl90eXBlIHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGlzIHVuZGVyc3BlY2lmaWVkIGFzIGJlaW5n IGEgbWVjaGFuaXNtIGluIHdoaWNoIGFzc2VydGlvbnMgY2FuIGJlIHVzZWQgZm9yIGF1dGhlbnRp Y2F0aW9uLiBBZ3JlZSB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgaGFzIHRvIG1ha2Ug cmlnaHQgYW5kIGRlY2xhcmUgd2hhdCBpcyBiZWluZyB1c2VkIGJ1dCB0aGF0IGlzIHRoZSBzYW1l IGZvciBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXV0aGVudGlj YXRpb24gYXNzZXJ0aW9ucyBhcmUgc29tZXRoaW5nIHRoYXQgTWljcm9zb2Z0IGFuZCBHb29nbGUg ZmluZCB1c2VmdWwgYW5kIHBsYW4gb24gaW1wbGVtZW50aW5nIGFuZCB1c2luZyBhcyBhIG1lYW5z IGZvciBzdHJvbmdlciBhdXRoZW50aWNhdGlvbiB0byB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIu IFRoaXMgZXh0ZW5zaWJpbGl0eSBiZWxvbmdzIGluIHRoZSBjb3JlLCB0aGVyZSBpcyBubyBvdGhl ciBwbGFjZSB0byBwdXQgdGhpcyBmdW5jdGlvbmFsaXR5LiBJIGRvbid0IGJlbGlldmUgdGhhdCB0 aGUgcmVtb3ZhbCAoZWl0aGVyIGJ5IGVkaXRvciBvciBkaXJlY3Rpb24gYnkgY28tY2hhaXIpIGlz IHNvbWV0aGluZyB0aGF0IHNob3VsZCBoYXZlIGJlZW4gZG9uZSB3L28gYSBjb25zZW5zdXMgdm90 ZSBzaW5jZSB0aGlzIGhhcyBiZWVuIGluIHRoZSBzcGVjaWZpY2F0aW9uIGZvciBzb21lIHRpbWUg d2l0aG91dCBpc3N1ZSBhbmQgdGhlIHJlbW92YWwgY29tZXMgYXMgY29tcGxldGUgdW53ZWxjb21l IHN1cnByaXNlLiBHZXR0aW5nIGFsbW9zdCB0b3RhbCByZXdyaXRlcyBvZiB0aGUgc3BlY2lmaWNh dGlvbiB0aGlzIGxhdGUgaW4gdGhlIHJldmlldyBjeWNsZSBpcyBhbHNvIHZlcnkgZGlzdHVyYmlu Zy4NCg0KQSBwcm9wb3NhbCBmb3Iga2VlcGluZyB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFz c2VydGlvbiB3b3VsZCBiZSB0byBzaW1wbGlmeSB0byB0aGUgZm9sbG93aW5nOw0KVGhlIGNsaWVu dCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYXJlIHVzZWQgaW4gY2FzZXMgd2hlcmUgYSBwYXNzd29y ZCAoY2xlYXItdGV4dCBzaGFyZWQgc3ltbWV0cmljIHNlY3JldCkgaXMgdW5zdWl0YWJsZSBvciBk b2VzIG5vdCBwcm92aWRlIHN1ZmZpY2llbnQgc2VjdXJpdHkgZm9yIGNsaWVudCBhdXRoZW50aWNh dGlvbi4gVGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgcHJvdmlkZSBhbiBleHRlbnNp YmxlIG1lY2hhbmlzbSB0byB1c2UgYW4gYXNzZXJ0aW9uIGZvcm1hdCBzdXBwb3J0ZWQgYnkgdGhl IGF1dGhvcml6YXRpb24gc2VydmVyIGZvciBhdXRoZW50aWNhdGlvbiBvZiB0aGUgY2xpZW50Lg0K DQpVc2luZyBhc3NlcnRpb25zIHJlcXVpcmVzIHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFzc2Vy dGlvbiAoc3VjaCBhcyBhIFNBTUwgKENhbnRvciwgUy4sIEtlbXAsIEouLCBQaGlscG90dCwgUi4s IGFuZCBFLiBNYWxlciwg4oCcQXNzZXJ0aW9ucyBhbmQgUHJvdG9jb2wgZm9yIHRoZSBPQVNJUyBT ZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdlIChTQU1MKSBWMi4wLOKAnSBNYXJjaCAy MDA1LikgPCNPQVNJUy5zYW1sLWNvcmUtMi4wLW9zPiBbT0FTSVMuc2FtbOKAkWNvcmXigJEyLjDi gJFvc10gYXNzZXJ0aW9uKSBmcm9tIGFuIGFzc2VydGlvbiBpc3N1ZXIgb3IgdG8gc2VsZi1pc3N1 ZSBhbiBhc3NlcnRpb24uIFRoZSBhc3NlcnRpb24gZm9ybWF0LCB0aGUgcHJvY2VzcyBieSB3aGlj aCB0aGUgYXNzZXJ0aW9uIGlzIG9idGFpbmVkLCBhbmQgdGhlIG1ldGhvZCBvZiB2YWxpZGF0aW5n IHRoZSBhc3NlcnRpb24gYXJlIGRlZmluZWQgYnkgdGhlIGFzc2VydGlvbiBpc3N1ZXIgYW5kIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlciwgYW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMg c3BlY2lmaWNhdGlvbi4NCg0KV2hlbiB1c2luZyBhIGNsaWVudCBhc3NlcnRpb24sIHRoZSBjbGll bnQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOg0KDQpjbGllbnRfYXNzZXJ0aW9u X3R5cGUgLSBSRVFVSVJFRC4gVGhlIGZvcm1hdCBvZiB0aGUgYXNzZXJ0aW9uIGFzIGRlZmluZWQg YnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0 ZSBVUkkuDQpjbGllbnRfYXNzZXJ0aW9uIC0gUkVRVUlSRUQuIFRoZSBjbGllbnQgYXNzZXJ0aW9u Lg0KRm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgc2VuZHMgdGhlIGZvbGxvd2luZyBhY2Nlc3MgdG9r ZW4gcmVxdWVzdCB1c2luZyBhIFNBTUwgMi4wIGFzc2VydGlvbiB0byBhdXRoZW50aWNhdGUgaXRz ZWxmIChsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6DQoNCg0KICBQ T1NUIC90b2tlbiBIVFRQLzEuMQ0KICBIb3N0OiBzZXJ2ZXIuZXhhbXBsZS5jb20NCiAgQ29udGVu dC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQNCg0KICBncmFudF90eXBl PWF1dGhvcml6YXRpb25fY29kZSZjb2RlPWkxV3NSbjF1QjEmDQogIGNsaWVudF9hc3NlcnRpb249 UEhOaGJXeHdPbFsuLi5vbWl0dGVkIGZvciBicmV2aXR5Li4uXVpUNCUzRCYNCiAgY2xpZW50X2Fz c2VydGlvbl90eXBlPSAgdXJuJTNBb2FzaXMlM0FuYW1lcyVzQXRjJTNBU0FNTCUzQTIuMCUzQWFz c2VydGlvbiZyZWRpcmVjdF91cmk9aHR0cHMlM0ElMkYlMkZjbGllbnQlMkVleGFtcGxlJTJFY29t JTJGY2INCg0KDQoNCg0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1 dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyYW4gSGFtbWVyLUxhaGF2DQpTZW50 OiBGcmlkYXksIEphbnVhcnkgMTQsIDIwMTEgMTA6NDUgUE0NClRvOiBPQXV0aCBXRw0KU3ViamVj dDogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoNCkkg d291bGQgbGlrZSB0byBzdWdnZXN0IHdlIGRyb3AgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVu dGlhbHMgKC0xMSBzZWN0aW9uIDMuMikgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbiwgYW5kIGlmIG5l ZWRlZCwgcHVibGlzaCBpdCBhcyBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBmb2xs b3dpbmcgcmVhc29uczoNCg0KMS4gICAgICBUaGUgbWVjaGFuaXNtIGlzIHVuZGVyIHNwZWNpZmll ZCwgZXNwZWNpYWxseSBpbiBpdHMgaGFuZGxpbmcgb2YgdGhlIGNsaWVudF9pZCBpZGVudGlmaWVy ICh3aGVuIHVzZWQgdG8gb2J0YWluIGVuZC11c2VyIGF1dGhvcml6YXRpb24pLiBJdCBkb2VzIG5v dCBjb250YWluIGFueSBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzIHRvIGFjY29tcGxpc2ggYW55IGxl dmVsIG9mIGludGVyb3BlcmFiaWxpdHkgb3IgZnVuY3Rpb25hbGl0eS4gVGhpcyBpcyBpbiBjb250 cmFzdCB0byB0aGUgYXNzZXJ0aW9uIGdyYW50IHR5cGUgd2hpY2ggaGFzIG1hdHVyZWQgb3ZlciBh IHllYXIgaW50byBhIGZ1bGx5IHRob3VnaHQtb3V0IGV4dGVuc2lvbiBtZWNoYW5pc20sIGFzIHdl bGwgYXMgYSBzZXBhcmF0ZSBTQU1MIGFzc2VydGlvbiBzcGVjaWZpY2F0aW9uIHdpdGggYWN0aXZl IGRlcGxveW1lbnQgKHRoZSB0d28sIHRvZ2V0aGVyIHdpdGggcnVubmluZyBjb2RlLCBzaG93IGNs ZWFyIGNvbnNlbnN1cykuDQoNCjIuICAgICAgVGhlIHNlY3Rpb24gaXMgYSBjb25mdXNlZCBtaXgg b2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc3ByaW5rbGVkIHdpdGggbm9ybWF0aXZlIGxhbmd1 YWdlLiBJbnN0ZWFkLCBpdCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBndWlkZWxpbmVzIGZvciBl eHRlbmRpbmcgdGhlIHNldCBvZiBzdXBwb3J0ZWQgY2xpZW50IGNyZWRlbnRpYWxzLCBidXQgd2l0 aG91dCBkZWZpbmluZyBhIG5ldyByZWdpc3RyeS4gSXQgaXMgY2xlYXJseSBhbiBhcmVhIG9mIGxp dHRsZSBkZXBsb3ltZW50IGV4cGVyaWVuY2UgZm9yIE9BdXRoLCBhbmQgdGhhdCBpbmNsdWRlcyB1 c2luZyBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24g KG1vcmUgb24gdGhhdCB0byBjb21lKS4NCg0KMy4gICAgICBUaGUgc2VjdGlvbiBoYXMgcmVjZWl2 ZWQgYSBsaXR0bGUgc3VwcG9ydCBhbmQgYSBsaXR0bGUgb2JqZWN0aW9uLiBUaG9zZSB3aG8gc3Rp bGwgd2FudCB0byBhZHZvY2F0ZSBmb3IgaXQgbmVlZCB0byBzaG93IG5vdCBvbmx5IGNvbnNlbnN1 cyBmb3Iga2VlcGluZyBpdCwgYnV0IGFsc28gYWN0aXZlIGNvbW11bml0eSBzdXBwb3J0IGZvciBk ZXBsb3lpbmcgaXQuIERlcGxveW1lbnQsIG9mIGNvdXJzZSwgd2lsbCBhbHNvIHJlcXVpcmUgc2hv d2luZyBwcm9ncmVzcyBvbiBwdWJsaWMgc3BlY2lmaWNhdGlvbnMgcHJvZmlsaW5nIHRoZSBtZWNo YW5pc20gaW50byBhIHVzZWZ1bCBpbnRlcm9wZXJhYmxlIGZlYXR1cmUuDQoNCg0KQ29tbWVudHM/ IENvdW50ZXItYXJndW1lbnRzPw0KDQpFSEwNCg0KDQoNCg== --_000_C9686EA51024Deranhueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5SZTogUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVk ZW50aWFsczwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjxGT05UIEZBQ0U9IkNhbGlicmksIFZl cmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOIFNUWUxFPSdmb250LXNpemU6MTFwdCc+VGhh bmtzIGZvciB0aGUgYWRkaXRpb25hbCBkZXRhaWxzLjxCUj4NCjxCUj4NCkkgYWdyZWUgdGhhdCBp bmNsdWRpbmcgdGhlIHR3byBwYXJhbWV0ZXJzIGluIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNh dGlvbiBtYWtlcyBubyBzZW5zZSBhdCBhbGwuPEJSPg0KPEJSPg0KSSB3b3VsZCBsaWtlIHRvIHN1 Z2dlc3QgeW91IHRha2UgdGhlIHByb3Bvc2VkIGxhbmd1YWdlLCBleHBhbmQgaXQgYnV5IGluY2x1 ZGluZyBtb3JlIGRldGFpbHMgZ3VpZGVsaW5lcyBmb3IgdGhlIGJpbmRpbmcgb2YgdGhlIGNsaWVu dF9pZCB0byB0aGUgYXNzZXJ0aW9uLCBhbmQgZGVmaW5lIGF0IGxlYXN0IG9uZSB1c2VmdWwgcHJv ZmlsZSBiYXNlZCBvbiB5b3VyIGN1cnJlbnQgZGVwbG95bWVudCBzdWNoIGFzIGEgU0FNTCAyLjAg Y2xpZW50IGFzc2VydGlvbi4gVGhpcyB3aWxsIGJlIHB1Ymxpc2hlZCBpbiBhIG5ldyBJLUQgd2l0 aCBhIHdlbGwgZGVmaW5lZCBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24gZm9jdXNlZCBz b2xlbHkgb24gdGhlIHVzZSBvZiBjbGllbnQgYXNzZXJ0aW9ucyBmb3IgYXV0aGVudGljYXRpbmcg dGhlIGNsaWVudC4gT25jZSB5b3UgaGF2ZSB0aGlzIGRvY3VtZW50IHB1Ymxpc2hlZCwgdGhlIHdv cmtpbmcgZ3JvdXAgY2FuIGhhdmUgYSBxdWljayBjb25zZW5zdXMgY2FsbCB0byBkbyBvbmUgb2Yg dGhyZWUgb3B0aW9uczo8QlI+DQo8QlI+DQo8L1NQQU4+PC9GT05UPjxPTD48TEk+PEZPTlQgRkFD RT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQt c2l6ZToxMXB0Jz5EZWNpZGUgdG8gaW5jb3Jwb3JhdGUgdGhlIGRyYWZ0IGludG8gdjIgZ2l2ZW4g aXRzIHN1ZmZpY2llbnQgZGV0YWlscywgc3BlY2lmaWNpdHksIGV4YW1wbGVzLCBhbmQgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMuIFdlIGhhdmUgYWJvdXQgMi0zIG1vbnRocyB3aW5kb3cgdG8gbWFr ZSB0aGlzIGNoYW5nZSBiZWZvcmUgc2hpcHBpbmcgdGhlIHNwZWMgdG8gYW4gSUVURiBMQy4gVGhp cyB3aWxsIHJlcXVpcmUgYSBkcmFmdCBwdWJsaXNoZWQgd2l0aGluIGEgbW9udGguDQo8L1NQQU4+ PC9GT05UPjxMST48Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFs Ij48U1BBTiBTVFlMRT0nZm9udC1zaXplOjExcHQnPkRlY2lkZSB0byBrZWVwIGl0IGFzIGEgc3Rh bmRhbG9uZSBleHRlbnNpb24sIGJ1dCBhcyBhIFdHIGl0ZW0uDQo8L1NQQU4+PC9GT05UPjxMST48 Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiBTVFlM RT0nZm9udC1zaXplOjExcHQnPkRlY2lkZSB0byBrZWVwIGl0IGFzIGFuIGluZGl2aWR1YWwgc3Vi bWlzc2lvbiAod2l0aCBJQU5BIHJlZ2lzdHJhdGlvbiBvZiB0aGUgdHdvIG5ldyBwYXJhbWV0ZXJz KS48QlI+DQo8L1NQQU4+PC9GT05UPjwvT0w+PEZPTlQgRkFDRT0iQ2FsaWJyaSwgVmVyZGFuYSwg SGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMXB0Jz48QlI+DQpJIGFt IG9wZW4gdG8gYWxsIHRocmVlIG9wdGlvbnMgYW5kIHdpbGwgZG8gbXkgYmVzdCB0byBwcm92aWRl IGZlZWRiYWNrIGFuZCBhc3Npc3RhbmNlLCBhcyBzb29uIGFzIGEgbmV3IHRleHQgaXMgcHJvcG9z ZWQgdGhhdCBpbmNsdWRlcyB0aGUgYWJvdmUgZGV0YWlscy48QlI+DQo8QlI+DQpFSEw8QlI+DQo8 QlI+DQo8QlI+DQpPbiAxLzI4LzExIDExOjU1IEFNLCAmcXVvdDtBbnRob255IE5hZGFsaW4mcXVv dDsgJmx0OzxhIGhyZWY9InRvbnluYWRAbWljcm9zb2Z0LmNvbSI+dG9ueW5hZEBtaWNyb3NvZnQu Y29tPC9hPiZndDsgd3JvdGU6PEJSPg0KPEJSPg0KPC9TUEFOPjwvRk9OVD48QkxPQ0tRVU9URT48 Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiBTVFlM RT0nZm9udC1zaXplOjExcHQnPjxGT05UIENPTE9SPSIjMUY0OTdEIj5JIHNhaWQgaXRzICYjODIy MDtiZWNvbWluZyYjODIyMTsgdXNlbGVzcyBhcyBtb3JlIGFuZCBtb3JlIHN0dWZmIGlzIGJlaW5n IHJlbW92ZWQuPEJSPg0KJm5ic3A7PEJSPg0KTWF5YmUgeW91IGRpZCBub3QgdW5kZXJzdGFuZCBv ciBJIGRpZCBub3QgdGVsbCB5b3UgZXZlcnl0aGluZyB5b3UgbmVlZGVkIHRvIGtub3csIHdlIGhh dmUgZW5kcG9pbnRzIHRoYXQgZXhwZWN0IGFzc2VydGlvbnMgYWxvbmcgd2l0aCB0aGUgZ3JhbnRf dHlwZSBvZiBhdXRob3JpemF0aW9uX2NvZGUgYW5kIHdlIGFsc28gaGF2ZSBlbmRwb2ludHMgdGhh dCBleHBlY3QgdGhlIGdyYW50X3R5cGUgb2YgVVJJIChvciB0aGUgYXNzZXJ0aW9uLCB3aGljaCBj b3VsZCBiZSB3aGF0ZXZlciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVjaWRlcyksIHRoZXNl IGFyZSAyIGRpZmZlcmVudCBlbmRwb2ludHMgd2l0aCAyIGRpZmZlcmVudCBmdW5jdGlvbnMuIFRo ZSBjaGFuZ2UgdGhhdCB3YXMgbWFkZSB0byByZW1vdmUgdGhlIG5vdGlvbiBvZiBjbGllbnQgYXNz ZXJ0aW9uIGNyZWRlbnRpYWxzIG9ubHkgbGVmdCB1cyB3aXRoIHRoZSBleHRlbnNpb24gc28gd2Ug Y2FuIGxpdmUgd2l0aCB0aGUgY2hhbmdlcyB0byB0aGUgZXh0ZW5zaW9uIChpdCBpcyBhIGNvZGUg Y2hhbmdlIGZvciB1cykgYnV0IG5vdCByZW1vdmFsIG9mIGNsaWVudCBhc3NlcnRpb24gY3JlZGVu dGlhbHMgd2UgY2FuJiM4MjE3O3QgbGl2ZSB3aXRoIGFzIHdlIGFyZSB1c2luZyB0aGUgbm90aW9u IG9mIGNsaWVudCBjcmVkZW50aWFscy4gSSYjODIxNzttIG5vdCBzdXJlIHRoYXQgcHV0dGluZyB0 aGlzIGluIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlvbiB3b3VsZCB3b3JrLjxCUj4NCiZu YnNwOzxCUj4NCiZuYnNwOzxCUj4NCjwvRk9OVD48QlI+DQo8L1NQQU4+PEZPTlQgU0laRT0iMiI+ PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMHB0Jz48Qj5Gcm9tOjwvQj4gRXJhbiBIYW1tZXItTGFo YXYgWzxhIGhyZWY9Im1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tIj5tYWlsdG86ZXJhbkBodWVu aXZlcnNlLmNvbTwvYT5dIDxCUj4NCjxCPlNlbnQ6PC9CPiBXZWRuZXNkYXksIEphbnVhcnkgMjYs IDIwMTEgMjo1MSBQTTxCUj4NCjxCPlRvOjwvQj4gQW50aG9ueSBOYWRhbGluPEJSPg0KPEI+Q2M6 PC9CPiBPQXV0aCBXRzxCUj4NCjxCPlN1YmplY3Q6PC9CPiBSRTogUmVtb3ZhbDogQ2xpZW50IEFz c2VydGlvbiBDcmVkZW50aWFsczxCUj4NCjwvU1BBTj48L0ZPTlQ+PFNQQU4gU1RZTEU9J2ZvbnQt c2l6ZToxMXB0Jz4gPEJSPg0KPEZPTlQgQ09MT1I9IiMxRjQ5N0QiPkNhbiB5b3UgZXhwbGFpbiBo b3cgaGF2aW5nIHRvIGRlZmluZSAqPEI+dHdvPC9CPiogZXh0ZW5zaW9uIHBhcmFtZXRlcnMgbWFr ZXMgdGhlIHNwZWNpZmljYXRpb24gdXNlbGVzcz8gVGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0 aW9uIGlzIGdvaW5nIHRvIGRlZmluZSBpdHMgY29ycmVzcG9uZGluZyBXV1ctQXV0aGVudGljYXRl IGhlYWRlciwgdG8gbWF0Y2ggaXRzIGFscmVhZHkgZGVmaW5lZCBBdXRob3JpemF0aW9uIGhlYWRl ci4gVGhlIHNjaGVtZSBuYW1lIGlzIGp1c3Qgc3R5bGUgYW5kIGJyYW5kaW5nIGFuZCBoYXZlIGFi c29sdXRlbHkgbm8gdGVjaG5pY2FsIGltcGFjdC4gSSBhbSBob25lc3RseSBjb25mdXNlZCBieSB5 b3VyIGNvbW1lbnRzLCBhcyBJIHdhcyBpbiB0aGUgcGFzdCB3aGVuIHlvdSBkZWNsYXJlZCB0aGUg ZW50aXJlIHByb3RvY29sIHVzZWxlc3MgYmVjYXVzZSBvZiBteSBvYmplY3Rpb25zIHRvIGFuIHVu ZGVyLWRlZmluZWQgc2NvcGUgcGFyYW1ldGVyLjxCUj4NCiZuYnNwOzxCUj4NCkNhbiB5b3UgcG9p bnQgbWUgd2hlcmUgaW4gV1JBUCBhcmUgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMg ZGVmaW5lZD8gSSBjYW4gb25seSBmaW5kIHRoZSBhc3NlcnRpb24gcHJvZmlsZSB3aGljaCBpcyBj b21wYXJhYmxlIHRvIHRoZSBleHRlbnNpb24gZ3JhbnQgdHlwZSB3aXRoIHRoZSBTQU1MIGFzc2Vy dGlvbiBleHRlbnNpb24gKHdoZXJlIHRoZSBhc3NlcnRpb24gcGFyYW1ldGVyIGlzIGRlZmluZWQg YW5kIHJlZ2lzdGVyZWQpLiBUaGUgY29uY2VwdCBvZiB0aGUgY2xpZW50IGFzc2VydGlvbiB1c2Vk IGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gKHNlcGFyYXRlIGZyb20gdGhlIGF1dGhvcml6YXRp b24gZ3JhbnQpIGlzIG5ldyBhbmQgd2FzIGFkZGVkIGJhc2VkIG9uIGEgcHJvcG9zYWwgZnJvbSBZ YXJvbiBpbiAtMTEgb24gRGVjZW1iZXIgMXN0LCAyMDEwLjxCUj4NCiZuYnNwOzxCUj4NCkFzIGZv ciB5b3VyIGFkZGl0aW9uYWwgZGV0YWlscyBiZWxvdyAodGhhbmtzISksIGl0IHNlZW1zIGxpa2Ug eW91IGFyZSBub3QgdXNpbmcgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYXQgYWxs IGJ1dCB1c2luZyBhIHNpbXBsZSBleHRlbnNpb24gZ3JhbnQgd2l0aCBhbiBhc3NlcnRpb24sIGV4 YWN0bHkgbGlrZSB0aGUgU0FNTCBleHRlbnNpb24gZ3JhbnQgc3BlY2lmaWNhdGlvbiwgb25seSB5 b3UgYXJlIG5vdCBsaW1pdGVkIHRvIFNBTUwgMi4wLiBJcyB0aGF0IGNvcnJlY3Q/IElmIHRoaXMg aXMgY29ycmVjdCwgdGhlbiB0aGUgb25seSBpc3N1ZSBoZXJlIGlzIG91ciBkZWNpc2lvbiAod2hp Y2ggd2FzIG1hZGUgd2l0aG91dCBhbnkgY29tbWVudCBmcm9tIHlvdSBvciB0aG9zZSBub3cgcmFp c2luZyBpc3N1ZXMgYWJvdXQgdGhpcykgdG8gbW92ZSB0aGUgJiM4MjE2O2Fzc2VydGlvbiYjODIx NzsgcGFyYW1ldGVyIGFuZCByZW5hbWUgdGhlIGdyYW50IHR5cGUgZnJvbSBhc3NlcnRpb24gdG8g ZXh0ZW5zaW9uICh3aGljaCBoYXMgbm8gaW1wbGVtZW50YXRpb24gaW1wYWN0KS4gQWxsIHdlIGRp ZCBpcyByZWxvY2F0ZSB0aGUgYXNzZXJ0aW9uIHBhcmFtZXRlciBiZWNhdXNlIGl0IGRvZXNuJiM4 MjE3O3QgYWx3YXlzIGFwcGx5IHRvIGV4dGVuc2lvbiBncmFudHMuPEJSPg0KJm5ic3A7PEJSPg0K SXMgdGhpcyBqdXN0IGEgY29uZnVzaW9uIGFib3V0IHdoYXQgd2FzIGJlaW5nIHJlbW92ZWQgYW5k IHdoZXJlIGl0IHdlbnQ/PEJSPg0KJm5ic3A7PEJSPg0KRUhMPEJSPg0KJm5ic3A7PEJSPg0KJm5i c3A7PEJSPg0KPC9GT05UPjxCUj4NCjwvU1BBTj48Rk9OVCBTSVpFPSIyIj48U1BBTiBTVFlMRT0n Zm9udC1zaXplOjEwcHQnPjxCPkZyb206PC9CPiBBbnRob255IE5hZGFsaW4gWzxhIGhyZWY9Im1h aWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20iPm1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb208 L2E+XSA8QlI+DQo8Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBKYW51YXJ5IDI2LCAyMDExIDE6NTIg UE08QlI+DQo8Qj5Ubzo8L0I+IEVyYW4gSGFtbWVyLUxhaGF2PEJSPg0KPEI+Q2M6PC9CPiBPQXV0 aCBXRzxCUj4NCjxCPlN1YmplY3Q6PC9CPiBSRTogUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBD cmVkZW50aWFsczxCUj4NCjwvU1BBTj48L0ZPTlQ+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMXB0 Jz4gPEJSPg0KPEZPTlQgQ09MT1I9IiMxRjQ5N0QiPk1heWJlIHRoaXMgd2FzIHRoZSBwbGFuIGFs bCBhbG9uZyBidXQgc3BlY2lmaWNhdGlvbiBpcyBiZWNvbWluZyB1c2VsZXNzIGZvciBvdXIgc2Nl bmFyaW9zIGFuZCB3aWxsIHJlcXVpcmUgdGhhdCB3ZSBoYXZlIHRvIGdvIHdlbGwgYmV5b25kIHRo ZSBjb3JlIHNwZWNpZmljYXRpb24gdG8gbWFrZSB0aGluZ3Mgd29yaywgdGhlIGNsaWVudCBhc3Nl cnRpb24gY3JlZGVudGlhbHMgYmVpbmcgYSBwcmltZSBleGFtcGxlLiBUaGUgY2xpZW50IGFzc2Vy dGlvbiBjcmVkZW50aWFscyBoYXMgYmVlbiBhcm91bmQgZm9yIGEgd2hpbGUgYXMgaXQgd2FzIGEg cmVxdWlyZW1lbnQgZm9yIFdSQVAsIHRoZW4gZHJvcHBlZCB3aGVuIHRoZSB2YXJpb3VzIHNwZWNz IGdvdCBtZXJnZWQgdG8gZm9ybSBPQVVUSCAyLjAgYW5kIHRoZW4gY2FtZSBiYWNrIGludG8gdGhl IE9BVVRIIDIuMCBhbmQgdGhlbiBoYXMgZ29uZSB0aHJvdWdoIHZhcmlvdXMgY2hhbmdlcyBzaW5j ZSB2ZXJzaW9uIDYgZm9yIHRoZSB3b3JzZS4gVGhlcmUgaGFzIGJlZW4gbXVjaCBkaXNjdXNzaW9u IGluIEp1bHkvQXVndXN0IG92ZXIgdGhpcyBhbmQgbmV3IHRleHQgd2FzIHByb3Bvc2VkLCBidXQg dGhhdCBzZWVtcyB0byBub3QgYmUgZnVsbHkgYWNjZXB0ZWQsIGJ1dCBJIHRoaW5rIHRoYXQgZm9s bG93cyB0aGUgcGF0aCB3aGVuIHlvdSB3YW50IHRvIHJlbW92ZSBzb21ldGhpbmcuPEJSPg0KJm5i c3A7PEJSPg0KT3VyIHVzYWdlIHdpbGwgYmUgdmlhIGJlYXJlciB0b2tlbiBhc3NlcnRpb25zIG9u bHkgKGF0IHRoaXMgdGltZSk8QlI+DQpUaGUgZ3JhbnRfdHlwZSB3b3VsZCBiZSB0aGUgVVJJIG9m IHRoZSBhc3NlcnRpb24gdHlwZSBiZWluZyB1c2VkPEJSPg0KVGhlIGF1dGhvcml6YXRpb24gZW5k cG9pbnQgY2FuIHVzZSB3aGF0IGl0IHdhbnRzIHRvIGJpbmQgdGhlIGFzc2VydGlvbiB0byB0aGUg Y2xpZW50X2lkLCBtdWNoIGxpa2UgaXQgaGFzIHRvIHRvZGF5IGZvciB0aGUgcGFzc3dvcmQgYXV0 aGVudGljYXRpb24sIGFzIHdlIGhhdmUgc2NlbmFyaW9zIHdlcmUgY2xpZW50X2lkIGhhdmUgbXVs dGlwbGUgcGFzc3dvcmRzPEJSPg0KV2UgdXNlIGd1aWRhbmNlIGZyb20gc2VjdXJpdHkgY29uc2lk ZXJhdGlvbiBzZWN0aW9uIG9mIHRoZSBhc3NlcnRpb24gdHlwZSBiZWluZyB1c2VkIGFsb25nIHdp dGggdGhlIGd1aWRhbmNlIGZyb20gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uPEJSPg0K SWYgbmVlZGVkIEkgY2FuIGNhcHR1cmUgdGhlIGFzc2VydGlvbnMgYW5kIHJlcXVlc3RzLCBidXQg bm90IHN1cmUgd2hhdCB0aGUgcG9pbnQgb2YgdGhpcyBpcyBhdCB0aGlzIHRpbWUgc2luY2UgdGhp cyBpcyBub3QgcmVxdWlyZWQgZm9yIHRoZSBwYXNzd29yZCBjcmVkZW50aWFsczxCUj4NCiZuYnNw OzxCUj4NClN1cmUgd2UgY2FuIGFkZCB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlv biB0byB0aGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24gYnV0IEkgZG9uJiM4MjE3O3QgdGhp bmsgdGhhdCBpcyB0aGUgcHJvcGVyIHBsYWNlIHRvIGRvIHRodXMgYnV0IHNpbmNlIGl0JiM4MjE3 O3MgZ29uZSBmcm9tIHRoZSBjb3JlIHdlIHdpbGwgaGF2ZSB0byBkbyBqdXN0IHRoYXQuIFRoZSBz YW1lIHNlZW1zIHRvIGhhcHBlbiB3aXRoIHRoZSBIVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSBh cyBpdCBzZWVtcyB0byBiZSByZXBlYXRlZCBpbiBmb2xsb3ctb24gY29tcGFuaW9uIHNwZWNpZmlj YXRpb25zLiBXaGlsZSBvYXV0aC12MiBpcyBub3QgYW4gYXV0aGVudGljYXRpb24gcHJvdG9jb2wg dGhlcmUgaXMgYSByZXF1aXJlbWVudCBmb3IgYXV0aGVudGljYXRpb24gdG8gYWRkcmVzcyBzZWN1 cml0eSBjb25jZXJucy4gVGhlcmUgaXMgY2xlYXIgc2VwYXJhdGlvbiBiZXR3ZWVuIGF1dGhlbnRp Y2F0aW9uIGFuZCBhdXRob3JpemF0aW9uOyB3ZSBhcmUgbm90IHN1Z2dlc3RpbmcgdGhhdCBhdXRo ZW50aWNhdGlvbiBpcyBhcHByb3ByaWF0ZSBmYWNpbGl0eSB0byBuZWdvdGlhdGUgYXV0aG9yaXph dGlvbi4gSSB0aGluayB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIGluY2x1ZGUgYSBzY2hlbWUgaW4g dGhlIGNvcmUgYW5kIGhhdmUgdGhlIHBhcnRpY3VsYXIgZm9sbG93LW9uIGNvbXBhbmlvbiBzcGVj aWZpY2F0aW9ucyAodGhlIHZhcmlvdXMgdG9rZW4gc3BlY2lmaWNhdGlvbnMpIHN0YXRlL2RlZmlu ZSB0aGUgcGFyYW1ldGVycyBhbmQgaWYgdGhleSBkb24mIzgyMTc7dCBsaWtlIHRoZSBkZWZhdWx0 IHNjaGVtZSBsZXQgdGhlbSBkZWZpbmUgYSBuZXcgc2NoZW1lIGJ1dCB0aGlzIHB1dHMgYSBzdGFr ZSBpbiB0aGUgZ3JvdW5kIGZvciBhbiBIVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVtZS48QlI+DQom bmJzcDs8QlI+DQombmJzcDs8QlI+DQo8L0ZPTlQ+PEJSPg0KPC9TUEFOPjxGT05UIFNJWkU9IjIi PjxTUEFOIFNUWUxFPSdmb250LXNpemU6MTBwdCc+PEI+RnJvbTo8L0I+IEVyYW4gSGFtbWVyLUxh aGF2IFs8YSBocmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+bWFpbHRvOmVyYW5AaHVl bml2ZXJzZS5jb208L2E+XSA8QlI+DQo8Qj5TZW50OjwvQj4gVHVlc2RheSwgSmFudWFyeSAyNSwg MjAxMSA1OjM4IFBNPEJSPg0KPEI+VG86PC9CPiBBbnRob255IE5hZGFsaW48QlI+DQo8Qj5DYzo8 L0I+IE9BdXRoIFdHPEJSPg0KPEI+U3ViamVjdDo8L0I+IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNz ZXJ0aW9uIENyZWRlbnRpYWxzPEJSPg0KPC9TUEFOPjwvRk9OVD48U1BBTiBTVFlMRT0nZm9udC1z aXplOjExcHQnPiA8QlI+DQo8Rk9OVCBDT0xPUj0iIzFGNDk3RCI+Q2FuIHlvdSBzaGFyZSB3aXRo IHRoZSBsaXN0IGhvdyB5b3UgcGxhbiB0byB1c2UgdGhpcyBjbGllbnQgYXNzZXJ0aW9uIGF1dGhl bnRpY2F0aW9uIHNjaGVtZT88QlI+DQpXaGljaCBvZiB0aGUgYXV0aG9yaXphdGlvbiBncmFudCB0 eXBlcyB5b3Ugd2lsbCB1c2UgaXQgd2l0aD88QlI+DQpXaWxsIHlvdSB1c2UgaXQgd2l0aCB0aGUg YXV0aG9yaXphdGlvbiBlbmRwb2ludCwgYW5kIGlmIHNvLCBob3cgd2lsbCB5b3UgYmluZCB0aGUg YXNzZXJ0aW9uIHRvIHRoZSBjbGllbnRfaWQ/PEJSPg0KQ2FuIHlvdSBwcm92aWRlIGZ1bGwgZXhh bXBsZXMgb2YgYXNzZXJ0aW9ucyBhbmQgSFRUUCByZXF1ZXN0cz88QlI+DQombmJzcDs8QlI+DQpJ dCB3b3VsZCBiZSBoZWxwZnVsIHRvIHNlZSBob3cgZmFyIGFwYXJ0IHRoZSBwcm9wb3NlZCB0ZXh0 IGJlbG93IGlzIGZyb20gYW4gYWN0dWFsIGltcGxlbWVudGF0aW9uIG1ha2luZyB1c2Ugb2YgaXQu IEkgZXhjZXB0IHRvIHNlZSB0aGVzZSBhbnN3ZXJzIGluIGFueSBxdWFsaXR5IGRvY3VtZW50IGRl ZmluaW5nIGEgbmV3IGNsaWVudCBhdXRoZW50aWNhdGlvbiBzY2hlbWUgKHdoaWNoIGlzIHRydWUg Zm9yIHRoZSBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gdGhyb3VnaG91dCB0aGUgZG9j dW1lbnQpLjxCUj4NCiZuYnNwOzxCUj4NCkVITDxCUj4NCiZuYnNwOzxCUj4NCiZuYnNwOzxCUj4N CjwvRk9OVD48QlI+DQo8L1NQQU4+PEZPTlQgU0laRT0iMiI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6 ZToxMHB0Jz48Qj5Gcm9tOjwvQj4gQW50aG9ueSBOYWRhbGluIFs8YSBocmVmPSJtYWlsdG86dG9u eW5hZEBtaWNyb3NvZnQuY29tIj5tYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPl0gPEJS Pg0KPEI+U2VudDo8L0I+IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgMzo1OCBQTTxCUj4NCjxC PlRvOjwvQj4gRXJhbiBIYW1tZXItTGFoYXY7IE9BdXRoIFdHOyA8YSBocmVmPSJIYW5uZXMuVHNj aG9mZW5pZ0BnbXgubmV0Ij5IYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0PC9hPjsgQmxhaW5lIENv b2s8QlI+DQo8Qj5TdWJqZWN0OjwvQj4gUkU6IFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3Jl ZGVudGlhbHM8QlI+DQo8L1NQQU4+PC9GT05UPjxTUEFOIFNUWUxFPSdmb250LXNpemU6MTFwdCc+ IDxCUj4NCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGZvciByZW1vdmluZyB0aGUg Y2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscywgYXMgY2xpZW50IHBhc3N3b3JkIGF1dGhlbnRp Y2F0aW9uIGlzIGxlZnQgaW4uIENsaWVudCBQYXNzd29yZCBBdXRoZW50aWNhdGlvbiBpcyBhbHNv IHVuZGVyc3BlY2lmaWVkIGFzIGNsaWVudF9zZWNyZXQgY291bGQgYmUgYW55dGhpbmcgdGhhdCB0 aGUgYXV0aGVudGljYXRpb24gc2VydmVyIHNlZW1zIGZpdCAocmF3IGNsZWFyIHRleHQgcGFzc3dv cmQsICZuYnNwO2hhc2gsIGRpZ2VzdCwgZXRjLikgYW5kIG5vIHdheSB0byBkZXRlcm1pbmUgdGhl IGNvbnRlbnQuIGNsaWVudF9zZWNyZXQgaXMgYWxzbyBhIHZlcnkgd2VhayBtZWNoYW5pc20sIHNp bmNlIHRoaXMgaXMgbGVmdCBpbiB0aGUgY29yZSB0aGlzIGxlYWRzIG1lIHRvIGJlbGlldmUgdGhh dCB0aGVyZSBpcyBzdXBwb3J0IGZvciBoYXZpbmcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIE9h dXRoLiBJIGRvbid0IHNlZSBob3cgaGF2aW5nIGNsaWVudF9hc3NlcnRpb24gYW5kIGNsaWVudF9h c3NlcnRpb25fdHlwZSB3b3VsZCBiZSBzb21ldGhpbmcgdGhhdCBpcyB1bmRlcnNwZWNpZmllZCBh cyBiZWluZyBhIG1lY2hhbmlzbSBpbiB3aGljaCBhc3NlcnRpb25zIGNhbiBiZSB1c2VkIGZvciBh dXRoZW50aWNhdGlvbi4gQWdyZWUgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyIGhhcyB0 byBtYWtlIHJpZ2h0IGFuZCBkZWNsYXJlIHdoYXQgaXMgYmVpbmcgdXNlZCBidXQgdGhhdCBpcyB0 aGUgc2FtZSBmb3IgY2xpZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIGFzc2VydGlvbnMgYXJlIHNvbWV0aGluZyB0aGF0IE1pY3Jvc29mdCBhbmQg R29vZ2xlIGZpbmQgdXNlZnVsIGFuZCBwbGFuIG9uIGltcGxlbWVudGluZyBhbmQgdXNpbmcgYXMg YSBtZWFucyBmb3Igc3Ryb25nZXIgYXV0aGVudGljYXRpb24gdG8gdGhlIGF1dGhvcml6YXRpb24g c2VydmVyLiBUaGlzIGV4dGVuc2liaWxpdHkgYmVsb25ncyBpbiB0aGUgY29yZSwgdGhlcmUgaXMg bm8gb3RoZXIgcGxhY2UgdG8gcHV0IHRoaXMgZnVuY3Rpb25hbGl0eS4gSSBkb24ndCBiZWxpZXZl IHRoYXQgdGhlIHJlbW92YWwgKGVpdGhlciBieSBlZGl0b3Igb3IgZGlyZWN0aW9uIGJ5IGNvLWNo YWlyKSBpcyBzb21ldGhpbmcgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIGRvbmUgdy9vIGEgY29uc2Vu c3VzIHZvdGUgc2luY2UgdGhpcyBoYXMgYmVlbiBpbiB0aGUgc3BlY2lmaWNhdGlvbiBmb3Igc29t ZSB0aW1lIHdpdGhvdXQgaXNzdWUgYW5kIHRoZSByZW1vdmFsIGNvbWVzIGFzIGNvbXBsZXRlIHVu d2VsY29tZSBzdXJwcmlzZS4gR2V0dGluZyBhbG1vc3QgdG90YWwgcmV3cml0ZXMgb2YgdGhlIHNw ZWNpZmljYXRpb24gdGhpcyBsYXRlIGluIHRoZSByZXZpZXcgY3ljbGUgaXMgYWxzbyB2ZXJ5IGRp c3R1cmJpbmcuPEJSPg0KJm5ic3A7PEJSPg0KQSBwcm9wb3NhbCBmb3Iga2VlcGluZyB0aGUgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiB3b3VsZCBiZSB0byBzaW1wbGlmeSB0byB0aGUg Zm9sbG93aW5nOzxCUj4NCjwvU1BBTj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjEycHQnPlRoZSBj bGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGFyZSB1c2VkIGluIGNhc2VzIHdoZXJlIGEgcGFz c3dvcmQgKGNsZWFyLXRleHQgc2hhcmVkIHN5bW1ldHJpYyBzZWNyZXQpIGlzIHVuc3VpdGFibGUg b3IgZG9lcyBub3QgcHJvdmlkZSBzdWZmaWNpZW50IHNlY3VyaXR5IGZvciBjbGllbnQgYXV0aGVu dGljYXRpb24uIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIHByb3ZpZGUgYW4gZXh0 ZW5zaWJsZSBtZWNoYW5pc20gdG8gdXNlIGFuIGFzc2VydGlvbiBmb3JtYXQgc3VwcG9ydGVkIGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBmb3IgYXV0aGVudGljYXRpb24gb2YgdGhlIGNsaWVu dC4gPEJSPg0KPC9TUEFOPjxTUEFOIFNUWUxFPSdmb250LXNpemU6MTFwdCc+PEJSPg0KPC9TUEFO PjxTUEFOIFNUWUxFPSdmb250LXNpemU6MTJwdCc+VXNpbmcgYXNzZXJ0aW9ucyByZXF1aXJlcyB0 aGUgY2xpZW50IHRvIG9idGFpbiBhbiBhc3NlcnRpb24gKHN1Y2ggYXMgYSBTQU1MIChDYW50b3Is IFMuLCBLZW1wLCBKLiwgUGhpbHBvdHQsIFIuLCBhbmQgRS4gTWFsZXIsICYjODIyMDtBc3NlcnRp b25zIGFuZCBQcm90b2NvbCBmb3IgdGhlIE9BU0lTIFNlY3VyaXR5IEFzc2VydGlvbiBNYXJrdXAg TGFuZ3VhZ2UgKFNBTUwpIFYyLjAsJiM4MjIxOyBNYXJjaCAyMDA1Lik8L1NQQU4+PC9GT05UPjxT UEFOIFNUWUxFPSdmb250LXNpemU6MTJwdCc+PEZPTlQgRkFDRT0iVGltZXMgTmV3IFJvbWFuIj4g Jmx0OyNPQVNJUy5zYW1sLWNvcmUtMi4wLW9zJmd0OyA8L0ZPTlQ+PEZPTlQgRkFDRT0iQ2FsaWJy aSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+W09BU0lTLnNhbWzigJFjb3Jl4oCRMi4w4oCR b3NdIGFzc2VydGlvbikgZnJvbSBhbiBhc3NlcnRpb24gaXNzdWVyIG9yIHRvIHNlbGYtaXNzdWUg YW4gYXNzZXJ0aW9uLiBUaGUgYXNzZXJ0aW9uIGZvcm1hdCwgdGhlIHByb2Nlc3MgYnkgd2hpY2gg dGhlIGFzc2VydGlvbiBpcyBvYnRhaW5lZCwgYW5kIHRoZSBtZXRob2Qgb2YgdmFsaWRhdGluZyB0 aGUgYXNzZXJ0aW9uIGFyZSBkZWZpbmVkIGJ5IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIsIGFuZCBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNw ZWNpZmljYXRpb24uIDxCUj4NCjwvRk9OVD48L1NQQU4+PEZPTlQgRkFDRT0iQ2FsaWJyaSwgVmVy ZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMXB0Jz48QlI+ DQo8L1NQQU4+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMnB0Jz5XaGVuIHVzaW5nIGEgY2xpZW50 IGFzc2VydGlvbiwgdGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6 IDxCUj4NCjwvU1BBTj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjExcHQnPjxCUj4NCmNsaWVudF9h c3NlcnRpb25fdHlwZSAtIFJFUVVJUkVELiBUaGUgZm9ybWF0IG9mIHRoZSBhc3NlcnRpb24gYXMg ZGVmaW5lZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoZSB2YWx1ZSBNVVNUIGJlIGFu IGFic29sdXRlIFVSSS4gPEJSPg0KY2xpZW50X2Fzc2VydGlvbiAtIFJFUVVJUkVELiBUaGUgY2xp ZW50IGFzc2VydGlvbi4gPEJSPg0KPC9TUEFOPjxTUEFOIFNUWUxFPSdmb250LXNpemU6MTJwdCc+ Rm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgc2VuZHMgdGhlIGZvbGxvd2luZyBhY2Nlc3MgdG9rZW4g cmVxdWVzdCB1c2luZyBhIFNBTUwgMi4wIGFzc2VydGlvbiB0byBhdXRoZW50aWNhdGUgaXRzZWxm IChsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6IDxCUj4NCjwvU1BB Tj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjExcHQnPiA8QlI+DQombmJzcDs8QlI+DQombmJzcDsm bmJzcDtQT1NUIC90b2tlbiBIVFRQLzEuMTxCUj4NCiZuYnNwOyZuYnNwO0hvc3Q6IHNlcnZlci5l eGFtcGxlLmNvbTxCUj4NCiZuYnNwOyZuYnNwO0NvbnRlbnQtVHlwZTogYXBwbGljYXRpb24veC13 d3ctZm9ybS11cmxlbmNvZGVkPEJSPg0KJm5ic3A7PEJSPg0KJm5ic3A7Jm5ic3A7Z3JhbnRfdHlw ZT1hdXRob3JpemF0aW9uX2NvZGUmYW1wO2NvZGU9aTFXc1JuMXVCMSZhbXA7PEJSPg0KJm5ic3A7 Jm5ic3A7Y2xpZW50X2Fzc2VydGlvbj1QSE5oYld4d09sWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHku Li5dWlQ0JTNEJmFtcDs8QlI+DQombmJzcDsmbmJzcDtjbGllbnRfYXNzZXJ0aW9uX3R5cGU9ICZu YnNwO3VybiUzQW9hc2lzJTNBbmFtZXMlc0F0YyUzQVNBTUwlM0EyLjAlM0Fhc3NlcnRpb24mYW1w O3JlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUlMkVjb20lMkZjYjxC Uj4NCiZuYnNwOzxCUj4NCiZuYnNwOzxCUj4NCjxGT05UIENPTE9SPSIjMUY0OTdEIj4gPEJSPg0K Jm5ic3A7PEJSPg0KPC9GT05UPjxCUj4NCjwvU1BBTj48Rk9OVCBTSVpFPSIyIj48U1BBTiBTVFlM RT0nZm9udC1zaXplOjEwcHQnPjxCPkZyb206PC9CPiA8YSBocmVmPSJvYXV0aC1ib3VuY2VzQGll dGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOm9hdXRo LWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0gPEI+ T24gQmVoYWxmIE9mIDwvQj5FcmFuIEhhbW1lci1MYWhhdjxCUj4NCjxCPlNlbnQ6PC9CPiBGcmlk YXksIEphbnVhcnkgMTQsIDIwMTEgMTA6NDUgUE08QlI+DQo8Qj5Ubzo8L0I+IE9BdXRoIFdHPEJS Pg0KPEI+U3ViamVjdDo8L0I+IFtPQVVUSC1XR10gUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBD cmVkZW50aWFsczxCUj4NCjwvU1BBTj48L0ZPTlQ+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMXB0 Jz4gPEJSPg0KSSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3Qgd2UgZHJvcCB0aGUgY2xpZW50IGFzc2Vy dGlvbiBjcmVkZW50aWFscyAoLTExIHNlY3Rpb24gMy4yKSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9u LCBhbmQgaWYgbmVlZGVkLCBwdWJsaXNoIGl0IGFzIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiBm b3IgdGhlIGZvbGxvd2luZyByZWFzb25zOjxCUj4NCiZuYnNwOzxCUj4NCjEuICZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBtZWNoYW5pc20gaXMgdW5kZXIgc3BlY2lmaWVkLCBlc3Bl Y2lhbGx5IGluIGl0cyBoYW5kbGluZyBvZiB0aGUgY2xpZW50X2lkIGlkZW50aWZpZXIgKHdoZW4g dXNlZCB0byBvYnRhaW4gZW5kLXVzZXIgYXV0aG9yaXphdGlvbikuIEl0IGRvZXMgbm90IGNvbnRh aW4gYW55IGltcGxlbWVudGF0aW9uIGRldGFpbHMgdG8gYWNjb21wbGlzaCBhbnkgbGV2ZWwgb2Yg aW50ZXJvcGVyYWJpbGl0eSBvciBmdW5jdGlvbmFsaXR5LiBUaGlzIGlzIGluIGNvbnRyYXN0IHRv IHRoZSBhc3NlcnRpb24gZ3JhbnQgdHlwZSB3aGljaCBoYXMgbWF0dXJlZCBvdmVyIGEgeWVhciBp bnRvIGEgZnVsbHkgdGhvdWdodC1vdXQgZXh0ZW5zaW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBh IHNlcGFyYXRlIFNBTUwgYXNzZXJ0aW9uIHNwZWNpZmljYXRpb24gd2l0aCBhY3RpdmUgZGVwbG95 bWVudCAodGhlIHR3bywgdG9nZXRoZXIgd2l0aCBydW5uaW5nIGNvZGUsIHNob3cgY2xlYXIgY29u c2Vuc3VzKS48QlI+DQo8QlI+DQoyLiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUg c2VjdGlvbiBpcyBhIGNvbmZ1c2VkIG1peCBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzcHJp bmtsZWQgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UuIEluc3RlYWQsIGl0IHNob3VsZCBiZSByZXBs YWNlZCB3aXRoIGd1aWRlbGluZXMgZm9yIGV4dGVuZGluZyB0aGUgc2V0IG9mIHN1cHBvcnRlZCBj bGllbnQgY3JlZGVudGlhbHMsIGJ1dCB3aXRob3V0IGRlZmluaW5nIGEgbmV3IHJlZ2lzdHJ5LiBJ dCBpcyBjbGVhcmx5IGFuIGFyZWEgb2YgbGl0dGxlIGRlcGxveW1lbnQgZXhwZXJpZW5jZSBmb3Ig T0F1dGgsIGFuZCB0aGF0IGluY2x1ZGVzIHVzaW5nIEhUVFAgQmFzaWMgYXV0aGVudGljYXRpb24g Zm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAobW9yZSBvbiB0aGF0IHRvIGNvbWUpLjxCUj4NCjxC Uj4NCjMuICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBzZWN0aW9uIGhhcyByZWNl aXZlZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3NlIHdobyBz dGlsbCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkgY29uc2Vu c3VzIGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBvcnQgZm9y IGRlcGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsIGFsc28gcmVxdWlyZSBz aG93aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9maWxpbmcgdGhlIG1l Y2hhbmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS48QlI+DQo8QlI+DQom bmJzcDs8QlI+DQpDb21tZW50cz8gQ291bnRlci1hcmd1bWVudHM/PEJSPg0KJm5ic3A7PEJSPg0K RUhMPEJSPg0KJm5ic3A7PEJSPg0KJm5ic3A7PEJSPg0KPEJSPg0KPC9TUEFOPjwvRk9OVD48L0JM T0NLUVVPVEU+DQo8L0JPRFk+DQo8L0hUTUw+DQoNCg== --_000_C9686EA51024Deranhueniversecom_-- From eran@hueniverse.com Fri Jan 28 13:04:40 2011 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 E3F213A68D7 for ; Fri, 28 Jan 2011 13:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RMML_Stock25=0.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 2T0FLzmvsYV0 for ; Fri, 28 Jan 2011 13:04:24 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id BB9A03A68FA for ; Fri, 28 Jan 2011 13:04:23 -0800 (PST) Received: (qmail 31576 invoked from network); 28 Jan 2011 21:07:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Jan 2011 21:07:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 28 Jan 2011 14:06:28 -0700 From: Eran Hammer-Lahav To: Phil Hunt , Anthony Nadalin Date: Fri, 28 Jan 2011 14:06:31 -0700 Thread-Topic: [OAUTH-WG] Removal: Client Assertion Credentials Thread-Index: Acu/KEkZ6HL7q+wwS9K9pOQgvOtN4AABvNuo 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_C9686FD710250eranhueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 28 Jan 2011 21:04:41 -0000 --_000_C9686FD710250eranhueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RldJVywgSSBwbGFuIHRvIGluY2x1ZGUgYW4gT0F1dGggY2xpZW50IGF1dGhlbnRpY2F0aW9uIGJp bmRpbmcgaW4gbXkgTUFDIHNwZWNpZmljYXRpb24gaW4gdGhlIG5leHQgdmVyc2lvbi4NCg0KRUhM DQoNCg0KT24gMS8yOC8xMSAxMjoxNiBQTSwgIlBoaWwgSHVudCIgPHBoaWwuaHVudEBvcmFjbGUu Y29tPiB3cm90ZToNCg0KVG9ueSwNCg0KSSdtIG5vdCB0b3RhbGx5IHVuZGVyc3RhbmRpbmcgd2hh dCB0aGUgaXNzdWUgaXMgYXMgZmFyIGFzIGltcGFjdCBvbiBjb2RlLiBNeSB1bmRlcnN0YW5kaW5n IHdhcyB0aGF0IHRoZSByZW1vdmFsIHNpbXBseSB0b29rIGl0IG91dCBvZiB0aGUgc3RhbmRhcmQg YnV0IGlzIHN0aWxsIGNvdmVyZWQgYnkgIm90aGVyIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSIu ICBUaHVzIG5vIGltcGFjdCBvbiBjb2RlIC0tIHlvdSBjYW4gc3RpbGwgdXNlIChhcyB3ZSB3aWxs KSB0aGUgY2xpZW50X2Fzc2VydGlvbiBmb3JtIHBhcmFtZXRlci4gVGhhdCBzYWlkLCBJIHZlcnkg bXVjaCBhZ3JlZSB3aXRoIHlvdXIgY29uY2VybnMuDQoNCkl0IG1heSBiZSB3b3J0aHdoaWxlIGZv ciB1cyB0byB3b3JrIG9uIGEgcHJvZmlsZSB0aGF0IGxheXMgb3V0IHRoZSBzcGVjaWZpY3Mgb2Yg dXNpbmcgY2xpZW50X2Fzc2VydGlvbiBvciBjbGllbnRfdG9rZW4gaW4gYSBzZXBhcmF0ZSBzcGVj aWZpY2F0aW9uLiBKdXN0IGFzIHRoZXJlIHdpbGwgYmUgbXVsdGlwbGUgYWNjZXNzIHRva2VuIGZv cm1hdHMsIEkgZXhwZWN0IHRvIHNlZSBtdWx0aXBsZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWV0 aG9kcy4gIE1heWJlIGNsaWVudCBhdXRoIG1ldGhvZHMgc2hvdWxkIGFsc28gYmUgZGVmaW5lZCBp biBhIHJlZ2lzdHJ5PyBUaG91Z2gsIEkgZG9uJ3Qgc2VlIHRoaXMgYXMgbmVjZXNzYXJpbHkgYW4g T0F1dGggc3BlY2lmaWMgaXNzdWUuIFRoZXJlJ3MgYSBtdWNoIGJyb2FkZXIgcmVxdWlyZW1lbnQg Zm9yIGRlZmluaW5nIGNsaWVudCBhdXRoIGJleW9uZCBCYXNpYywgRGlnZXN0LCBNdXR1YWwgU1NM LCBldGMgZm9yIG5vbi1icm93c2VyIGNsaWVudHMuDQoNCkFzIGZvciB2YWx1ZSB3aXRoIE9BdXRo LCBJIHRoaW5rIE9BdXRoIGRlc2NyaWJlIGFuIGltcG9ydGFudCAicGF0dGVybiIgYW5kIHdvbid0 IGhhdmUgbXVjaCBnZW5lcmFsIGltcGFjdCBvbiBpbnRlci1vcGVyYWJpbGl0eSBhcyBhIHN0YW5k YXJkLiBUaHVzIGRvZXNuJ3QgdW5kZXJ2YWx1ZSB0aGUgc3RhbmRhcmQgdGhhdCBtdWNoIGFzIGl0 IGxheXMgYSBmb3VuZGF0aW9uIGZvciBvdGhlciBjb21wb25lbnRzLiBUaGUga2V5IHdvcmtpbmcg aW50ZXItb3AgY29tcG9uZW50cyB3aWxsIGxpa2VseSBoYXZlIGJlIGRlZmluZWQgaW4gc3Vic2Vx dWVudCByZWxhdGVkIHNwZWNzIHN1Y2ggYXMgc3VnZ2VzdGVkIGFib3ZlLg0KDQpXaGF0IGlzIG5v dCBjbGVhciB0byBtZSB5ZXQgaXMgd2hhdCBzaG91bGQgdGhlIGRpc2NvdmVyeSBhbmQgcmVnaXN0 cmF0aW9uIGNvbXBvbmVudHMgZm9yIE9BdXRoIGJlPyBIb3cgbXVjaCBzaG91bGQgYmUgZGVmaW5l ZCBpbiBkZXBsb3ltZW50IGRvY3VtZW50YXRpb24/IERlcGxveW1lbnQgZG9jdW1lbnRhdGlvbiBp cyBwcm9ibGVtYXRpYyBmb3IgZGV2ZWxvcG1lbnQgdG9vbHMuIEZvciBleGFtcGxlLCBidWlsZGlu ZyBhIC5OZXQgb3IgSmF2YSBwbGF0Zm9ybSBpcyBtdWNoIGRpZmZlcmVudCB0aGFuIGEgb25lIHRp bWUgZGV2ZWxvcGVyIHdobyBqdXN0IHdhbnRzIHRvIGFjY2VzcyBhIHNpbmdsZSBnb29nbGUsIGZh Y2Vib29rLCBldGMgc2VydmljZS4gIEluIGNvbnRyYXN0LCAuTmV0L0phdmEgdG9vbHMgY2FuJ3Qg aGVscCBtdWNoIHNpbmNlIHRoZXkgY2FuJ3QgaW5zcGVjdCB0aGUgc2VydmljZS4NCg0KSSBhZ3Jl ZSwgdG9vIG11Y2ggZW1waGFzaXMgaXMgb24gZGVwbG95bWVudCBkb2NzIGZvciB1c2Ugb2YgT0F1 dGguDQoNClBoaWwNCnBoaWwuaHVudEBvcmFjbGUuY29tDQoNCg0KDQoNCk9uIDIwMTEtMDEtMjgs IGF0IDExOjU1IEFNLCBBbnRob255IE5hZGFsaW4gd3JvdGU6DQoNCkkgc2FpZCBpdHMg4oCcYmVj b21pbmfigJ0gdXNlbGVzcyBhcyBtb3JlIGFuZCBtb3JlIHN0dWZmIGlzIGJlaW5nIHJlbW92ZWQu DQoNCk1heWJlIHlvdSBkaWQgbm90IHVuZGVyc3RhbmQgb3IgSSBkaWQgbm90IHRlbGwgeW91IGV2 ZXJ5dGhpbmcgeW91IG5lZWRlZCB0byBrbm93LCB3ZSBoYXZlIGVuZHBvaW50cyB0aGF0IGV4cGVj dCBhc3NlcnRpb25zIGFsb25nIHdpdGggdGhlIGdyYW50X3R5cGUgb2YgYXV0aG9yaXphdGlvbl9j b2RlIGFuZCB3ZSBhbHNvIGhhdmUgZW5kcG9pbnRzIHRoYXQgZXhwZWN0IHRoZSBncmFudF90eXBl IG9mIFVSSSAob3IgdGhlIGFzc2VydGlvbiwgd2hpY2ggY291bGQgYmUgd2hhdGV2ZXIgdGhlIGF1 dGhvcml6YXRpb24gc2VydmVyIGRlY2lkZXMpLCB0aGVzZSBhcmUgMiBkaWZmZXJlbnQgZW5kcG9p bnRzIHdpdGggMiBkaWZmZXJlbnQgZnVuY3Rpb25zLiBUaGUgY2hhbmdlIHRoYXQgd2FzIG1hZGUg dG8gcmVtb3ZlIHRoZSBub3Rpb24gb2YgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBvbmx5 IGxlZnQgdXMgd2l0aCB0aGUgZXh0ZW5zaW9uIHNvIHdlIGNhbiBsaXZlIHdpdGggdGhlIGNoYW5n ZXMgdG8gdGhlIGV4dGVuc2lvbiAoaXQgaXMgYSBjb2RlIGNoYW5nZSBmb3IgdXMpIGJ1dCBub3Qg cmVtb3ZhbCBvZiBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIHdlIGNhbuKAmXQgbGl2ZSB3 aXRoIGFzIHdlIGFyZSB1c2luZyB0aGUgbm90aW9uIG9mIGNsaWVudCBjcmVkZW50aWFscy4gSeKA mW0gbm90IHN1cmUgdGhhdCBwdXR0aW5nIHRoaXMgaW4gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZp Y2F0aW9uIHdvdWxkIHdvcmsuDQoNCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgW21haWx0bzpl cmFuQGh1ZW5pdmVyc2UuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI2LCAyMDExIDI6 NTEgUE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogUkU6IFJl bW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMNCg0KQ2FuIHlvdSBleHBsYWluIGhv dyBoYXZpbmcgdG8gZGVmaW5lICp0d28qIGV4dGVuc2lvbiBwYXJhbWV0ZXJzIG1ha2VzIHRoZSBz cGVjaWZpY2F0aW9uIHVzZWxlc3M/IFRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlvbiBpcyBn b2luZyB0byBkZWZpbmUgaXRzIGNvcnJlc3BvbmRpbmcgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIs IHRvIG1hdGNoIGl0cyBhbHJlYWR5IGRlZmluZWQgQXV0aG9yaXphdGlvbiBoZWFkZXIuIFRoZSBz Y2hlbWUgbmFtZSBpcyBqdXN0IHN0eWxlIGFuZCBicmFuZGluZyBhbmQgaGF2ZSBhYnNvbHV0ZWx5 IG5vIHRlY2huaWNhbCBpbXBhY3QuIEkgYW0gaG9uZXN0bHkgY29uZnVzZWQgYnkgeW91ciBjb21t ZW50cywgYXMgSSB3YXMgaW4gdGhlIHBhc3Qgd2hlbiB5b3UgZGVjbGFyZWQgdGhlIGVudGlyZSBw cm90b2NvbCB1c2VsZXNzIGJlY2F1c2Ugb2YgbXkgb2JqZWN0aW9ucyB0byBhbiB1bmRlci1kZWZp bmVkIHNjb3BlIHBhcmFtZXRlci4NCg0KQ2FuIHlvdSBwb2ludCBtZSB3aGVyZSBpbiBXUkFQIGFy ZSB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBkZWZpbmVkPyBJIGNhbiBvbmx5IGZp bmQgdGhlIGFzc2VydGlvbiBwcm9maWxlIHdoaWNoIGlzIGNvbXBhcmFibGUgdG8gdGhlIGV4dGVu c2lvbiBncmFudCB0eXBlIHdpdGggdGhlIFNBTUwgYXNzZXJ0aW9uIGV4dGVuc2lvbiAod2hlcmUg dGhlIGFzc2VydGlvbiBwYXJhbWV0ZXIgaXMgZGVmaW5lZCBhbmQgcmVnaXN0ZXJlZCkuIFRoZSBj b25jZXB0IG9mIHRoZSBjbGllbnQgYXNzZXJ0aW9uIHVzZWQgZm9yIGNsaWVudCBhdXRoZW50aWNh dGlvbiAoc2VwYXJhdGUgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBncmFudCkgaXMgbmV3IGFuZCB3 YXMgYWRkZWQgYmFzZWQgb24gYSBwcm9wb3NhbCBmcm9tIFlhcm9uIGluIC0xMSBvbiBEZWNlbWJl ciAxc3QsIDIwMTAuDQoNCkFzIGZvciB5b3VyIGFkZGl0aW9uYWwgZGV0YWlscyBiZWxvdyAodGhh bmtzISksIGl0IHNlZW1zIGxpa2UgeW91IGFyZSBub3QgdXNpbmcgdGhlIGNsaWVudCBhc3NlcnRp b24gY3JlZGVudGlhbHMgYXQgYWxsIGJ1dCB1c2luZyBhIHNpbXBsZSBleHRlbnNpb24gZ3JhbnQg d2l0aCBhbiBhc3NlcnRpb24sIGV4YWN0bHkgbGlrZSB0aGUgU0FNTCBleHRlbnNpb24gZ3JhbnQg c3BlY2lmaWNhdGlvbiwgb25seSB5b3UgYXJlIG5vdCBsaW1pdGVkIHRvIFNBTUwgMi4wLiBJcyB0 aGF0IGNvcnJlY3Q/IElmIHRoaXMgaXMgY29ycmVjdCwgdGhlbiB0aGUgb25seSBpc3N1ZSBoZXJl IGlzIG91ciBkZWNpc2lvbiAod2hpY2ggd2FzIG1hZGUgd2l0aG91dCBhbnkgY29tbWVudCBmcm9t IHlvdSBvciB0aG9zZSBub3cgcmFpc2luZyBpc3N1ZXMgYWJvdXQgdGhpcykgdG8gbW92ZSB0aGUg 4oCYYXNzZXJ0aW9u4oCZIHBhcmFtZXRlciBhbmQgcmVuYW1lIHRoZSBncmFudCB0eXBlIGZyb20g YXNzZXJ0aW9uIHRvIGV4dGVuc2lvbiAod2hpY2ggaGFzIG5vIGltcGxlbWVudGF0aW9uIGltcGFj dCkuIEFsbCB3ZSBkaWQgaXMgcmVsb2NhdGUgdGhlIGFzc2VydGlvbiBwYXJhbWV0ZXIgYmVjYXVz ZSBpdCBkb2VzbuKAmXQgYWx3YXlzIGFwcGx5IHRvIGV4dGVuc2lvbiBncmFudHMuDQoNCklzIHRo aXMganVzdCBhIGNvbmZ1c2lvbiBhYm91dCB3aGF0IHdhcyBiZWluZyByZW1vdmVkIGFuZCB3aGVy ZSBpdCB3ZW50Pw0KDQpFSEwNCg0KDQpGcm9tOiBBbnRob255IE5hZGFsaW4gW21haWx0bzp0b255 bmFkQG1pY3Jvc29mdC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjYsIDIwMTEgMTo1 MiBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2DQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJFOiBS ZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoNCk1heWJlIHRoaXMgd2FzIHRo ZSBwbGFuIGFsbCBhbG9uZyBidXQgc3BlY2lmaWNhdGlvbiBpcyBiZWNvbWluZyB1c2VsZXNzIGZv ciBvdXIgc2NlbmFyaW9zIGFuZCB3aWxsIHJlcXVpcmUgdGhhdCB3ZSBoYXZlIHRvIGdvIHdlbGwg YmV5b25kIHRoZSBjb3JlIHNwZWNpZmljYXRpb24gdG8gbWFrZSB0aGluZ3Mgd29yaywgdGhlIGNs aWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYmVpbmcgYSBwcmltZSBleGFtcGxlLiBUaGUgY2xp ZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBoYXMgYmVlbiBhcm91bmQgZm9yIGEgd2hpbGUgYXMg aXQgd2FzIGEgcmVxdWlyZW1lbnQgZm9yIFdSQVAsIHRoZW4gZHJvcHBlZCB3aGVuIHRoZSB2YXJp b3VzIHNwZWNzIGdvdCBtZXJnZWQgdG8gZm9ybSBPQVVUSCAyLjAgYW5kIHRoZW4gY2FtZSBiYWNr IGludG8gdGhlIE9BVVRIIDIuMCBhbmQgdGhlbiBoYXMgZ29uZSB0aHJvdWdoIHZhcmlvdXMgY2hh bmdlcyBzaW5jZSB2ZXJzaW9uIDYgZm9yIHRoZSB3b3JzZS4gVGhlcmUgaGFzIGJlZW4gbXVjaCBk aXNjdXNzaW9uIGluIEp1bHkvQXVndXN0IG92ZXIgdGhpcyBhbmQgbmV3IHRleHQgd2FzIHByb3Bv c2VkLCBidXQgdGhhdCBzZWVtcyB0byBub3QgYmUgZnVsbHkgYWNjZXB0ZWQsIGJ1dCBJIHRoaW5r IHRoYXQgZm9sbG93cyB0aGUgcGF0aCB3aGVuIHlvdSB3YW50IHRvIHJlbW92ZSBzb21ldGhpbmcu DQoNCk91ciB1c2FnZSB3aWxsIGJlIHZpYSBiZWFyZXIgdG9rZW4gYXNzZXJ0aW9ucyBvbmx5IChh dCB0aGlzIHRpbWUpDQpUaGUgZ3JhbnRfdHlwZSB3b3VsZCBiZSB0aGUgVVJJIG9mIHRoZSBhc3Nl cnRpb24gdHlwZSBiZWluZyB1c2VkDQpUaGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCBjYW4gdXNl IHdoYXQgaXQgd2FudHMgdG8gYmluZCB0aGUgYXNzZXJ0aW9uIHRvIHRoZSBjbGllbnRfaWQsIG11 Y2ggbGlrZSBpdCBoYXMgdG8gdG9kYXkgZm9yIHRoZSBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiwg YXMgd2UgaGF2ZSBzY2VuYXJpb3Mgd2VyZSBjbGllbnRfaWQgaGF2ZSBtdWx0aXBsZSBwYXNzd29y ZHMNCldlIHVzZSBndWlkYW5jZSBmcm9tIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBv ZiB0aGUgYXNzZXJ0aW9uIHR5cGUgYmVpbmcgdXNlZCBhbG9uZyB3aXRoIHRoZSBndWlkYW5jZSBm cm9tIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlvbg0KSWYgbmVlZGVkIEkgY2FuIGNhcHR1 cmUgdGhlIGFzc2VydGlvbnMgYW5kIHJlcXVlc3RzLCBidXQgbm90IHN1cmUgd2hhdCB0aGUgcG9p bnQgb2YgdGhpcyBpcyBhdCB0aGlzIHRpbWUgc2luY2UgdGhpcyBpcyBub3QgcmVxdWlyZWQgZm9y IHRoZSBwYXNzd29yZCBjcmVkZW50aWFscw0KDQpTdXJlIHdlIGNhbiBhZGQgdGhlIGNsaWVudCBh dXRoZW50aWNhdGlvbiBhc3NlcnRpb24gdG8gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9u IGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB0aGUgcHJvcGVyIHBsYWNlIHRvIGRvIHRodXMg YnV0IHNpbmNlIGl04oCZcyBnb25lIGZyb20gdGhlIGNvcmUgd2Ugd2lsbCBoYXZlIHRvIGRvIGp1 c3QgdGhhdC4gVGhlIHNhbWUgc2VlbXMgdG8gaGFwcGVuIHdpdGggdGhlIEhUVFAgQXV0aGVudGlj YXRpb24gU2NoZW1lIGFzIGl0IHNlZW1zIHRvIGJlIHJlcGVhdGVkIGluIGZvbGxvdy1vbiBjb21w YW5pb24gc3BlY2lmaWNhdGlvbnMuIFdoaWxlIG9hdXRoLXYyIGlzIG5vdCBhbiBhdXRoZW50aWNh dGlvbiBwcm90b2NvbCB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IGZvciBhdXRoZW50aWNhdGlvbiB0 byBhZGRyZXNzIHNlY3VyaXR5IGNvbmNlcm5zLiBUaGVyZSBpcyBjbGVhciBzZXBhcmF0aW9uIGJl dHdlZW4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb247IHdlIGFyZSBub3Qgc3VnZ2Vz dGluZyB0aGF0IGF1dGhlbnRpY2F0aW9uIGlzIGFwcHJvcHJpYXRlIGZhY2lsaXR5IHRvIG5lZ290 aWF0ZSBhdXRob3JpemF0aW9uLiBJIHRoaW5rIHRoYXQgaXQgbWFrZXMgc2Vuc2UgdG8gaW5jbHVk ZSBhIHNjaGVtZSBpbiB0aGUgY29yZSBhbmQgaGF2ZSB0aGUgcGFydGljdWxhciBmb2xsb3ctb24g Y29tcGFuaW9uIHNwZWNpZmljYXRpb25zICh0aGUgdmFyaW91cyB0b2tlbiBzcGVjaWZpY2F0aW9u cykgc3RhdGUvZGVmaW5lIHRoZSBwYXJhbWV0ZXJzIGFuZCBpZiB0aGV5IGRvbuKAmXQgbGlrZSB0 aGUgZGVmYXVsdCBzY2hlbWUgbGV0IHRoZW0gZGVmaW5lIGEgbmV3IHNjaGVtZSBidXQgdGhpcyBw dXRzIGEgc3Rha2UgaW4gdGhlIGdyb3VuZCBmb3IgYW4gSFRUUCBBdXRoZW50aWNhdGlvbiBTY2hl bWUuDQoNCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgW21haWx0bzplcmFuQGh1ZW5pdmVyc2Uu Y29tXQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNSwgMjAxMSA1OjM4IFBNDQpUbzogQW50aG9u eSBOYWRhbGluDQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNz ZXJ0aW9uIENyZWRlbnRpYWxzDQoNCkNhbiB5b3Ugc2hhcmUgd2l0aCB0aGUgbGlzdCBob3cgeW91 IHBsYW4gdG8gdXNlIHRoaXMgY2xpZW50IGFzc2VydGlvbiBhdXRoZW50aWNhdGlvbiBzY2hlbWU/ DQpXaGljaCBvZiB0aGUgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlcyB5b3Ugd2lsbCB1c2UgaXQg d2l0aD8NCldpbGwgeW91IHVzZSBpdCB3aXRoIHRoZSBhdXRob3JpemF0aW9uIGVuZHBvaW50LCBh bmQgaWYgc28sIGhvdyB3aWxsIHlvdSBiaW5kIHRoZSBhc3NlcnRpb24gdG8gdGhlIGNsaWVudF9p ZD8NCkNhbiB5b3UgcHJvdmlkZSBmdWxsIGV4YW1wbGVzIG9mIGFzc2VydGlvbnMgYW5kIEhUVFAg cmVxdWVzdHM/DQoNCkl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gc2VlIGhvdyBmYXIgYXBhcnQgdGhl IHByb3Bvc2VkIHRleHQgYmVsb3cgaXMgZnJvbSBhbiBhY3R1YWwgaW1wbGVtZW50YXRpb24gbWFr aW5nIHVzZSBvZiBpdC4gSSBleGNlcHQgdG8gc2VlIHRoZXNlIGFuc3dlcnMgaW4gYW55IHF1YWxp dHkgZG9jdW1lbnQgZGVmaW5pbmcgYSBuZXcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIHNjaGVtZSAo d2hpY2ggaXMgdHJ1ZSBmb3IgdGhlIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiB0aHJv dWdob3V0IHRoZSBkb2N1bWVudCkuDQoNCkVITA0KDQoNCkZyb206IEFudGhvbnkgTmFkYWxpbiBb bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjUs IDIwMTEgMzo1OCBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2OyBPQXV0aCBXRzsgSGFubmVzLlRz Y2hvZmVuaWdAZ214Lm5ldDsgQmxhaW5lIENvb2sNClN1YmplY3Q6IFJFOiBSZW1vdmFsOiBDbGll bnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoNCkkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgcmF0aW9u YWxlIGZvciByZW1vdmluZyB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscywgYXMgY2xp ZW50IHBhc3N3b3JkIGF1dGhlbnRpY2F0aW9uIGlzIGxlZnQgaW4uIENsaWVudCBQYXNzd29yZCBB dXRoZW50aWNhdGlvbiBpcyBhbHNvIHVuZGVyc3BlY2lmaWVkIGFzIGNsaWVudF9zZWNyZXQgY291 bGQgYmUgYW55dGhpbmcgdGhhdCB0aGUgYXV0aGVudGljYXRpb24gc2VydmVyIHNlZW1zIGZpdCAo cmF3IGNsZWFyIHRleHQgcGFzc3dvcmQsICBoYXNoLCBkaWdlc3QsIGV0Yy4pIGFuZCBubyB3YXkg dG8gZGV0ZXJtaW5lIHRoZSBjb250ZW50LiBjbGllbnRfc2VjcmV0IGlzIGFsc28gYSB2ZXJ5IHdl YWsgbWVjaGFuaXNtLCBzaW5jZSB0aGlzIGlzIGxlZnQgaW4gdGhlIGNvcmUgdGhpcyBsZWFkcyBt ZSB0byBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgc3VwcG9ydCBmb3IgaGF2aW5nIGNsaWVudCBhdXRo ZW50aWNhdGlvbiBpbiBPYXV0aC4gSSBkb24ndCBzZWUgaG93IGhhdmluZyBjbGllbnRfYXNzZXJ0 aW9uIGFuZCBjbGllbnRfYXNzZXJ0aW9uX3R5cGUgd291bGQgYmUgc29tZXRoaW5nIHRoYXQgaXMg dW5kZXJzcGVjaWZpZWQgYXMgYmVpbmcgYSBtZWNoYW5pc20gaW4gd2hpY2ggYXNzZXJ0aW9ucyBj YW4gYmUgdXNlZCBmb3IgYXV0aGVudGljYXRpb24uIEFncmVlIHRoYXQgdGhlIGF1dGhlbnRpY2F0 aW9uIHNlcnZlciBoYXMgdG8gbWFrZSByaWdodCBhbmQgZGVjbGFyZSB3aGF0IGlzIGJlaW5nIHVz ZWQgYnV0IHRoYXQgaXMgdGhlIHNhbWUgZm9yIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlv bi4gVGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb25zIGFyZSBzb21ldGhpbmcgdGhh dCBNaWNyb3NvZnQgYW5kIEdvb2dsZSBmaW5kIHVzZWZ1bCBhbmQgcGxhbiBvbiBpbXBsZW1lbnRp bmcgYW5kIHVzaW5nIGFzIGEgbWVhbnMgZm9yIHN0cm9uZ2VyIGF1dGhlbnRpY2F0aW9uIHRvIHRo ZSBhdXRob3JpemF0aW9uIHNlcnZlci4gVGhpcyBleHRlbnNpYmlsaXR5IGJlbG9uZ3MgaW4gdGhl IGNvcmUsIHRoZXJlIGlzIG5vIG90aGVyIHBsYWNlIHRvIHB1dCB0aGlzIGZ1bmN0aW9uYWxpdHku IEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoZSByZW1vdmFsIChlaXRoZXIgYnkgZWRpdG9yIG9yIGRp cmVjdGlvbiBieSBjby1jaGFpcikgaXMgc29tZXRoaW5nIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiBk b25lIHcvbyBhIGNvbnNlbnN1cyB2b3RlIHNpbmNlIHRoaXMgaGFzIGJlZW4gaW4gdGhlIHNwZWNp ZmljYXRpb24gZm9yIHNvbWUgdGltZSB3aXRob3V0IGlzc3VlIGFuZCB0aGUgcmVtb3ZhbCBjb21l cyBhcyBjb21wbGV0ZSB1bndlbGNvbWUgc3VycHJpc2UuIEdldHRpbmcgYWxtb3N0IHRvdGFsIHJl d3JpdGVzIG9mIHRoZSBzcGVjaWZpY2F0aW9uIHRoaXMgbGF0ZSBpbiB0aGUgcmV2aWV3IGN5Y2xl IGlzIGFsc28gdmVyeSBkaXN0dXJiaW5nLg0KDQpBIHByb3Bvc2FsIGZvciBrZWVwaW5nIHRoZSBj bGllbnQgYXV0aGVudGljYXRpb24gYXNzZXJ0aW9uIHdvdWxkIGJlIHRvIHNpbXBsaWZ5IHRvIHRo ZSBmb2xsb3dpbmc7DQpUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhcmUgdXNlZCBp biBjYXNlcyB3aGVyZSBhIHBhc3N3b3JkIChjbGVhci10ZXh0IHNoYXJlZCBzeW1tZXRyaWMgc2Vj cmV0KSBpcyB1bnN1aXRhYmxlIG9yIGRvZXMgbm90IHByb3ZpZGUgc3VmZmljaWVudCBzZWN1cml0 eSBmb3IgY2xpZW50IGF1dGhlbnRpY2F0aW9uLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50 aWFscyBwcm92aWRlIGFuIGV4dGVuc2libGUgbWVjaGFuaXNtIHRvIHVzZSBhbiBhc3NlcnRpb24g Zm9ybWF0IHN1cHBvcnRlZCBieSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZm9yIGF1dGhlbnRp Y2F0aW9uIG9mIHRoZSBjbGllbnQuDQoNClVzaW5nIGFzc2VydGlvbnMgcmVxdWlyZXMgdGhlIGNs aWVudCB0byBvYnRhaW4gYW4gYXNzZXJ0aW9uIChzdWNoIGFzIGEgU0FNTCAoQ2FudG9yLCBTLiwg S2VtcCwgSi4sIFBoaWxwb3R0LCBSLiwgYW5kIEUuIE1hbGVyLCDigJxBc3NlcnRpb25zIGFuZCBQ cm90b2NvbCBmb3IgdGhlIE9BU0lTIFNlY3VyaXR5IEFzc2VydGlvbiBNYXJrdXAgTGFuZ3VhZ2Ug KFNBTUwpIFYyLjAs4oCdIE1hcmNoIDIwMDUuKSA8eC1tc2c6Ly85My8jT0FTSVMuc2FtbC1jb3Jl LTIuMC1vcz4gW09BU0lTLnNhbWzigJFjb3Jl4oCRMi4w4oCRb3NdIGFzc2VydGlvbikgZnJvbSBh biBhc3NlcnRpb24gaXNzdWVyIG9yIHRvIHNlbGYtaXNzdWUgYW4gYXNzZXJ0aW9uLiBUaGUgYXNz ZXJ0aW9uIGZvcm1hdCwgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhlIGFzc2VydGlvbiBpcyBvYnRh aW5lZCwgYW5kIHRoZSBtZXRob2Qgb2YgdmFsaWRhdGluZyB0aGUgYXNzZXJ0aW9uIGFyZSBkZWZp bmVkIGJ5IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIs IGFuZCBhcmUgYmV5b25kIHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNCldoZW4g dXNpbmcgYSBjbGllbnQgYXNzZXJ0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIHRoZSBmb2xsb3dp bmcgcGFyYW1ldGVyczoNCg0KY2xpZW50X2Fzc2VydGlvbl90eXBlIC0gUkVRVUlSRUQuIFRoZSBm b3JtYXQgb2YgdGhlIGFzc2VydGlvbiBhcyBkZWZpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNl cnZlci4gVGhlIHZhbHVlIE1VU1QgYmUgYW4gYWJzb2x1dGUgVVJJLg0KY2xpZW50X2Fzc2VydGlv biAtIFJFUVVJUkVELiBUaGUgY2xpZW50IGFzc2VydGlvbi4NCkZvciBleGFtcGxlLCB0aGUgY2xp ZW50IHNlbmRzIHRoZSBmb2xsb3dpbmcgYWNjZXNzIHRva2VuIHJlcXVlc3QgdXNpbmcgYSBTQU1M IDIuMCBhc3NlcnRpb24gdG8gYXV0aGVudGljYXRlIGl0c2VsZiAobGluZSBicmVha3MgYXJlIGZv ciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOg0KDQoNCiAgUE9TVCAvdG9rZW4gSFRUUC8xLjENCiAg SG9zdDogc2VydmVyLmV4YW1wbGUuY29tIDxodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tLz4NCiBD b250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZA0KDQogIGdyYW50 X3R5cGU9YXV0aG9yaXphdGlvbl9jb2RlJmNvZGU9aTFXc1JuMXVCMSYNCiAgY2xpZW50X2Fzc2Vy dGlvbj1QSE5oYld4d09sWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHkuLi5dWlQ0JTNEJg0KICBjbGll bnRfYXNzZXJ0aW9uX3R5cGU9ICB1cm4lM0FvYXNpcyUzQW5hbWVzJXNBdGMlM0FTQU1MJTNBMi4w JTNBYXNzZXJ0aW9uJnJlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVudCUyRWV4YW1wbGUl MkVjb20lMkZjYg0KDQoNCg0KDQpGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyYW4gSGFtbWVyLUxhaGF2DQpT ZW50OiBGcmlkYXksIEphbnVhcnkgMTQsIDIwMTEgMTA6NDUgUE0NClRvOiBPQXV0aCBXRw0KU3Vi amVjdDogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoN Ckkgd291bGQgbGlrZSB0byBzdWdnZXN0IHdlIGRyb3AgdGhlIGNsaWVudCBhc3NlcnRpb24gY3Jl ZGVudGlhbHMgKC0xMSBzZWN0aW9uIDMuMikgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbiwgYW5kIGlm IG5lZWRlZCwgcHVibGlzaCBpdCBhcyBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBm b2xsb3dpbmcgcmVhc29uczoNCg0KMS4gICAgICAgVGhlIG1lY2hhbmlzbSBpcyB1bmRlciBzcGVj aWZpZWQsIGVzcGVjaWFsbHkgaW4gaXRzIGhhbmRsaW5nIG9mIHRoZSBjbGllbnRfaWQgaWRlbnRp ZmllciAod2hlbiB1c2VkIHRvIG9idGFpbiBlbmQtdXNlciBhdXRob3JpemF0aW9uKS4gSXQgZG9l cyBub3QgY29udGFpbiBhbnkgaW1wbGVtZW50YXRpb24gZGV0YWlscyB0byBhY2NvbXBsaXNoIGFu eSBsZXZlbCBvZiBpbnRlcm9wZXJhYmlsaXR5IG9yIGZ1bmN0aW9uYWxpdHkuIFRoaXMgaXMgaW4g Y29udHJhc3QgdG8gdGhlIGFzc2VydGlvbiBncmFudCB0eXBlIHdoaWNoIGhhcyBtYXR1cmVkIG92 ZXIgYSB5ZWFyIGludG8gYSBmdWxseSB0aG91Z2h0LW91dCBleHRlbnNpb24gbWVjaGFuaXNtLCBh cyB3ZWxsIGFzIGEgc2VwYXJhdGUgU0FNTCBhc3NlcnRpb24gc3BlY2lmaWNhdGlvbiB3aXRoIGFj dGl2ZSBkZXBsb3ltZW50ICh0aGUgdHdvLCB0b2dldGhlciB3aXRoIHJ1bm5pbmcgY29kZSwgc2hv dyBjbGVhciBjb25zZW5zdXMpLg0KMi4gICAgICAgVGhlIHNlY3Rpb24gaXMgYSBjb25mdXNlZCBt aXggb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc3ByaW5rbGVkIHdpdGggbm9ybWF0aXZlIGxh bmd1YWdlLiBJbnN0ZWFkLCBpdCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBndWlkZWxpbmVzIGZv ciBleHRlbmRpbmcgdGhlIHNldCBvZiBzdXBwb3J0ZWQgY2xpZW50IGNyZWRlbnRpYWxzLCBidXQg d2l0aG91dCBkZWZpbmluZyBhIG5ldyByZWdpc3RyeS4gSXQgaXMgY2xlYXJseSBhbiBhcmVhIG9m IGxpdHRsZSBkZXBsb3ltZW50IGV4cGVyaWVuY2UgZm9yIE9BdXRoLCBhbmQgdGhhdCBpbmNsdWRl cyB1c2luZyBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIGZvciBjbGllbnQgYXV0aGVudGljYXRp b24gKG1vcmUgb24gdGhhdCB0byBjb21lKS4NCjMuICAgICAgIFRoZSBzZWN0aW9uIGhhcyByZWNl aXZlZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3NlIHdobyBz dGlsbCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkgY29uc2Vu c3VzIGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBvcnQgZm9y IGRlcGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsIGFsc28gcmVxdWlyZSBz aG93aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9maWxpbmcgdGhlIG1l Y2hhbmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS4NCg0KQ29tbWVudHM/ IENvdW50ZXItYXJndW1lbnRzPw0KDQpFSEwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg== --_000_C9686FD710250eranhueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PEhUTUw+DQo8SEVBRD4NCjxUSVRMRT5SZTogW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNz ZXJ0aW9uIENyZWRlbnRpYWxzPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPEZPTlQgRkFDRT0i Q2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6 ZToxMXB0Jz5GV0lXLCBJIHBsYW4gdG8gaW5jbHVkZSBhbiBPQXV0aCBjbGllbnQgYXV0aGVudGlj YXRpb24gYmluZGluZyBpbiBteSBNQUMgc3BlY2lmaWNhdGlvbiBpbiB0aGUgbmV4dCB2ZXJzaW9u LjxCUj4NCjxCUj4NCkVITDxCUj4NCjxCUj4NCjxCUj4NCk9uIDEvMjgvMTEgMTI6MTYgUE0sICZx dW90O1BoaWwgSHVudCZxdW90OyAmbHQ7PGEgaHJlZj0icGhpbC5odW50QG9yYWNsZS5jb20iPnBo aWwuaHVudEBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PEJSPg0KPEJSPg0KPC9TUEFOPjwvRk9O VD48QkxPQ0tRVU9URT48Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFy aWFsIj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjExcHQnPlRvbnksPEJSPg0KPEJSPg0KSSdtIG5v dCB0b3RhbGx5IHVuZGVyc3RhbmRpbmcgd2hhdCB0aGUgaXNzdWUgaXMgYXMgZmFyIGFzIGltcGFj dCBvbiBjb2RlLiBNeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHRoZSByZW1vdmFsIHNpbXBseSB0 b29rIGl0IG91dCBvZiB0aGUgc3RhbmRhcmQgYnV0IGlzIHN0aWxsIGNvdmVyZWQgYnkgJnF1b3Q7 b3RoZXIgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtJnF1b3Q7LiAmbmJzcDtUaHVzIG5vIGltcGFj dCBvbiBjb2RlIC0tIHlvdSBjYW4gc3RpbGwgdXNlIChhcyB3ZSB3aWxsKSB0aGUgY2xpZW50X2Fz c2VydGlvbiBmb3JtIHBhcmFtZXRlci4gVGhhdCBzYWlkLCBJIHZlcnkgbXVjaCBhZ3JlZSB3aXRo IHlvdXIgY29uY2VybnMuPEJSPg0KPEJSPg0KSXQgbWF5IGJlIHdvcnRod2hpbGUgZm9yIHVzIHRv IHdvcmsgb24gYSBwcm9maWxlIHRoYXQgbGF5cyBvdXQgdGhlIHNwZWNpZmljcyBvZiB1c2luZyBj bGllbnRfYXNzZXJ0aW9uIG9yIGNsaWVudF90b2tlbiBpbiBhIHNlcGFyYXRlIHNwZWNpZmljYXRp b24uIEp1c3QgYXMgdGhlcmUgd2lsbCBiZSBtdWx0aXBsZSBhY2Nlc3MgdG9rZW4gZm9ybWF0cywg SSBleHBlY3QgdG8gc2VlIG11bHRpcGxlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZXRob2RzLiAm bmJzcDtNYXliZSBjbGllbnQgYXV0aCBtZXRob2RzIHNob3VsZCBhbHNvIGJlIGRlZmluZWQgaW4g YSByZWdpc3RyeT8gVGhvdWdoLCBJIGRvbid0IHNlZSB0aGlzIGFzIG5lY2Vzc2FyaWx5IGFuIE9B dXRoIHNwZWNpZmljIGlzc3VlLiBUaGVyZSdzIGEgbXVjaCBicm9hZGVyIHJlcXVpcmVtZW50IGZv ciBkZWZpbmluZyBjbGllbnQgYXV0aCBiZXlvbmQgQmFzaWMsIERpZ2VzdCwgTXV0dWFsIFNTTCwg ZXRjIGZvciBub24tYnJvd3NlciBjbGllbnRzLiA8QlI+DQo8QlI+DQpBcyBmb3IgdmFsdWUgd2l0 aCBPQXV0aCwgSSB0aGluayBPQXV0aCBkZXNjcmliZSBhbiBpbXBvcnRhbnQgJnF1b3Q7cGF0dGVy biZxdW90OyBhbmQgd29uJ3QgaGF2ZSBtdWNoIGdlbmVyYWwgaW1wYWN0IG9uIGludGVyLW9wZXJh YmlsaXR5IGFzIGEgc3RhbmRhcmQuIFRodXMgZG9lc24ndCB1bmRlcnZhbHVlIHRoZSBzdGFuZGFy ZCB0aGF0IG11Y2ggYXMgaXQgbGF5cyBhIGZvdW5kYXRpb24gZm9yIG90aGVyIGNvbXBvbmVudHMu IFRoZSBrZXkgd29ya2luZyBpbnRlci1vcCBjb21wb25lbnRzIHdpbGwgbGlrZWx5IGhhdmUgYmUg ZGVmaW5lZCBpbiBzdWJzZXF1ZW50IHJlbGF0ZWQgc3BlY3Mgc3VjaCBhcyBzdWdnZXN0ZWQgYWJv dmUuPEJSPg0KPEJSPg0KV2hhdCBpcyBub3QgY2xlYXIgdG8gbWUgeWV0IGlzIHdoYXQgc2hvdWxk IHRoZSBkaXNjb3ZlcnkgYW5kIHJlZ2lzdHJhdGlvbiBjb21wb25lbnRzIGZvciBPQXV0aCBiZT8g SG93IG11Y2ggc2hvdWxkIGJlIGRlZmluZWQgaW4gZGVwbG95bWVudCBkb2N1bWVudGF0aW9uPyBE ZXBsb3ltZW50IGRvY3VtZW50YXRpb24gaXMgcHJvYmxlbWF0aWMgZm9yIGRldmVsb3BtZW50IHRv b2xzLiBGb3IgZXhhbXBsZSwgYnVpbGRpbmcgYSAuTmV0IG9yIEphdmEgcGxhdGZvcm0gaXMgbXVj aCBkaWZmZXJlbnQgdGhhbiBhIG9uZSB0aW1lIGRldmVsb3BlciB3aG8ganVzdCB3YW50cyB0byBh Y2Nlc3MgYSBzaW5nbGUgZ29vZ2xlLCBmYWNlYm9vaywgZXRjIHNlcnZpY2UuICZuYnNwO0luIGNv bnRyYXN0LCAuTmV0L0phdmEgdG9vbHMgY2FuJ3QgaGVscCBtdWNoIHNpbmNlIHRoZXkgY2FuJ3Qg aW5zcGVjdCB0aGUgc2VydmljZS4gPEJSPg0KPEJSPg0KSSBhZ3JlZSwgdG9vIG11Y2ggZW1waGFz aXMgaXMgb24gZGVwbG95bWVudCBkb2NzIGZvciB1c2Ugb2YgT0F1dGguPEJSPg0KPEJSPg0KPC9T UEFOPjwvRk9OVD48Rk9OVCBTSVpFPSIxIj48Rk9OVCBGQUNFPSJIZWx2ZXRpY2EsIFZlcmRhbmEs IEFyaWFsIj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjlwdCc+UGhpbDxCUj4NCjxhIGhyZWY9InBo aWwuaHVudEBvcmFjbGUuY29tIj5waGlsLmh1bnRAb3JhY2xlLmNvbTwvYT48QlI+DQo8L1NQQU4+ PC9GT05UPjwvRk9OVD48Rk9OVCBGQUNFPSJIZWx2ZXRpY2EsIFZlcmRhbmEsIEFyaWFsIj48U1BB TiBTVFlMRT0nZm9udC1zaXplOjEycHQnPjxCUj4NCjxCUj4NCjwvU1BBTj48L0ZPTlQ+PEZPTlQg RkFDRT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2Zv bnQtc2l6ZToxMXB0Jz48QlI+DQo8QlI+DQpPbiAyMDExLTAxLTI4LCBhdCAxMTo1NSBBTSwgQW50 aG9ueSBOYWRhbGluIHdyb3RlOjxCUj4NCjxCUj4NCjwvU1BBTj48L0ZPTlQ+PEJMT0NLUVVPVEU+ PEZPTlQgRkFDRT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZ TEU9J2ZvbnQtc2l6ZToxMXB0Jz5JIHNhaWQgaXRzICYjODIyMDtiZWNvbWluZyYjODIyMTsgdXNl bGVzcyBhcyBtb3JlIGFuZCBtb3JlIHN0dWZmIGlzIGJlaW5nIHJlbW92ZWQuPEJSPg0KJm5ic3A7 PEJSPg0KTWF5YmUgeW91IGRpZCBub3QgdW5kZXJzdGFuZCBvciBJIGRpZCBub3QgdGVsbCB5b3Ug ZXZlcnl0aGluZyB5b3UgbmVlZGVkIHRvIGtub3csIHdlIGhhdmUgZW5kcG9pbnRzIHRoYXQgZXhw ZWN0IGFzc2VydGlvbnMgYWxvbmcgd2l0aCB0aGUgZ3JhbnRfdHlwZSBvZiBhdXRob3JpemF0aW9u X2NvZGUgYW5kIHdlIGFsc28gaGF2ZSBlbmRwb2ludHMgdGhhdCBleHBlY3QgdGhlIGdyYW50X3R5 cGUgb2YgVVJJIChvciB0aGUgYXNzZXJ0aW9uLCB3aGljaCBjb3VsZCBiZSB3aGF0ZXZlciB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVjaWRlcyksIHRoZXNlIGFyZSAyIGRpZmZlcmVudCBlbmRw b2ludHMgd2l0aCAyIGRpZmZlcmVudCBmdW5jdGlvbnMuIFRoZSBjaGFuZ2UgdGhhdCB3YXMgbWFk ZSB0byByZW1vdmUgdGhlIG5vdGlvbiBvZiBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIG9u bHkgbGVmdCB1cyB3aXRoIHRoZSBleHRlbnNpb24gc28gd2UgY2FuIGxpdmUgd2l0aCB0aGUgY2hh bmdlcyB0byB0aGUgZXh0ZW5zaW9uIChpdCBpcyBhIGNvZGUgY2hhbmdlIGZvciB1cykgYnV0IG5v dCByZW1vdmFsIG9mIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgd2UgY2FuJiM4MjE3O3Qg bGl2ZSB3aXRoIGFzIHdlIGFyZSB1c2luZyB0aGUgbm90aW9uIG9mIGNsaWVudCBjcmVkZW50aWFs cy4gSSYjODIxNzttIG5vdCBzdXJlIHRoYXQgcHV0dGluZyB0aGlzIGluIHRoZSBiZWFyZXIgdG9r ZW4gc3BlY2lmaWNhdGlvbiB3b3VsZCB3b3JrLjxCUj4NCiZuYnNwOzxCUj4NCiZuYnNwOzxCUj4N CjwvU1BBTj48L0ZPTlQ+PEZPTlQgU0laRT0iMiI+PEZPTlQgRkFDRT0iVGFob21hLCBWZXJkYW5h LCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjEwcHQnPjxCPkZyb206 PC9CPiBFcmFuIEhhbW1lci1MYWhhdiBbPGEgaHJlZj0ibWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5j b20iPm1haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tPC9hPl0gPEJSPg0KPEI+U2VudDo8L0I+IFdl ZG5lc2RheSwgSmFudWFyeSAyNiwgMjAxMSAyOjUxIFBNPEJSPg0KPEI+VG86PC9CPiBBbnRob255 IE5hZGFsaW48QlI+DQo8Qj5DYzo8L0I+IE9BdXRoIFdHPEJSPg0KPEI+U3ViamVjdDo8L0I+IFJF OiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPEJSPg0KPC9TUEFOPjwvRk9O VD48L0ZPTlQ+PEZPTlQgRkFDRT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+ PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMXB0Jz4gPEJSPg0KQ2FuIHlvdSBleHBsYWluIGhvdyBo YXZpbmcgdG8gZGVmaW5lICo8Qj50d288L0I+KiBleHRlbnNpb24gcGFyYW1ldGVycyBtYWtlcyB0 aGUgc3BlY2lmaWNhdGlvbiB1c2VsZXNzPyBUaGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24g aXMgZ29pbmcgdG8gZGVmaW5lIGl0cyBjb3JyZXNwb25kaW5nIFdXVy1BdXRoZW50aWNhdGUgaGVh ZGVyLCB0byBtYXRjaCBpdHMgYWxyZWFkeSBkZWZpbmVkIEF1dGhvcml6YXRpb24gaGVhZGVyLiBU aGUgc2NoZW1lIG5hbWUgaXMganVzdCBzdHlsZSBhbmQgYnJhbmRpbmcgYW5kIGhhdmUgYWJzb2x1 dGVseSBubyB0ZWNobmljYWwgaW1wYWN0LiBJIGFtIGhvbmVzdGx5IGNvbmZ1c2VkIGJ5IHlvdXIg Y29tbWVudHMsIGFzIEkgd2FzIGluIHRoZSBwYXN0IHdoZW4geW91IGRlY2xhcmVkIHRoZSBlbnRp cmUgcHJvdG9jb2wgdXNlbGVzcyBiZWNhdXNlIG9mIG15IG9iamVjdGlvbnMgdG8gYW4gdW5kZXIt ZGVmaW5lZCBzY29wZSBwYXJhbWV0ZXIuPEJSPg0KJm5ic3A7PEJSPg0KQ2FuIHlvdSBwb2ludCBt ZSB3aGVyZSBpbiBXUkFQIGFyZSB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBkZWZp bmVkPyBJIGNhbiBvbmx5IGZpbmQgdGhlIGFzc2VydGlvbiBwcm9maWxlIHdoaWNoIGlzIGNvbXBh cmFibGUgdG8gdGhlIGV4dGVuc2lvbiBncmFudCB0eXBlIHdpdGggdGhlIFNBTUwgYXNzZXJ0aW9u IGV4dGVuc2lvbiAod2hlcmUgdGhlIGFzc2VydGlvbiBwYXJhbWV0ZXIgaXMgZGVmaW5lZCBhbmQg cmVnaXN0ZXJlZCkuIFRoZSBjb25jZXB0IG9mIHRoZSBjbGllbnQgYXNzZXJ0aW9uIHVzZWQgZm9y IGNsaWVudCBhdXRoZW50aWNhdGlvbiAoc2VwYXJhdGUgZnJvbSB0aGUgYXV0aG9yaXphdGlvbiBn cmFudCkgaXMgbmV3IGFuZCB3YXMgYWRkZWQgYmFzZWQgb24gYSBwcm9wb3NhbCBmcm9tIFlhcm9u IGluIC0xMSBvbiBEZWNlbWJlciAxc3QsIDIwMTAuPEJSPg0KJm5ic3A7PEJSPg0KQXMgZm9yIHlv dXIgYWRkaXRpb25hbCBkZXRhaWxzIGJlbG93ICh0aGFua3MhKSwgaXQgc2VlbXMgbGlrZSB5b3Ug YXJlIG5vdCB1c2luZyB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhdCBhbGwgYnV0 IHVzaW5nIGEgc2ltcGxlIGV4dGVuc2lvbiBncmFudCB3aXRoIGFuIGFzc2VydGlvbiwgZXhhY3Rs eSBsaWtlIHRoZSBTQU1MIGV4dGVuc2lvbiBncmFudCBzcGVjaWZpY2F0aW9uLCBvbmx5IHlvdSBh cmUgbm90IGxpbWl0ZWQgdG8gU0FNTCAyLjAuIElzIHRoYXQgY29ycmVjdD8gSWYgdGhpcyBpcyBj b3JyZWN0LCB0aGVuIHRoZSBvbmx5IGlzc3VlIGhlcmUgaXMgb3VyIGRlY2lzaW9uICh3aGljaCB3 YXMgbWFkZSB3aXRob3V0IGFueSBjb21tZW50IGZyb20geW91IG9yIHRob3NlIG5vdyByYWlzaW5n IGlzc3VlcyBhYm91dCB0aGlzKSB0byBtb3ZlIHRoZSAmIzgyMTY7YXNzZXJ0aW9uJiM4MjE3OyBw YXJhbWV0ZXIgYW5kIHJlbmFtZSB0aGUgZ3JhbnQgdHlwZSBmcm9tIGFzc2VydGlvbiB0byBleHRl bnNpb24gKHdoaWNoIGhhcyBubyBpbXBsZW1lbnRhdGlvbiBpbXBhY3QpLiBBbGwgd2UgZGlkIGlz IHJlbG9jYXRlIHRoZSBhc3NlcnRpb24gcGFyYW1ldGVyIGJlY2F1c2UgaXQgZG9lc24mIzgyMTc7 dCBhbHdheXMgYXBwbHkgdG8gZXh0ZW5zaW9uIGdyYW50cy48QlI+DQombmJzcDs8QlI+DQpJcyB0 aGlzIGp1c3QgYSBjb25mdXNpb24gYWJvdXQgd2hhdCB3YXMgYmVpbmcgcmVtb3ZlZCBhbmQgd2hl cmUgaXQgd2VudD88QlI+DQombmJzcDs8QlI+DQpFSEw8QlI+DQombmJzcDs8QlI+DQombmJzcDs8 QlI+DQo8L1NQQU4+PC9GT05UPjxGT05UIFNJWkU9IjIiPjxGT05UIEZBQ0U9IlRhaG9tYSwgVmVy ZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMHB0Jz48Qj5G cm9tOjwvQj4gQW50aG9ueSBOYWRhbGluIDxGT05UIENPTE9SPSIjMDAwMEZGIj5bPGEgaHJlZj0i bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNv bTwvYT5dPC9GT05UPiA8QlI+DQo8Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBKYW51YXJ5IDI2LCAy MDExIDE6NTIgUE08QlI+DQo8Qj5Ubzo8L0I+IEVyYW4gSGFtbWVyLUxhaGF2PEJSPg0KPEI+Q2M6 PC9CPiBPQXV0aCBXRzxCUj4NCjxCPlN1YmplY3Q6PC9CPiBSRTogUmVtb3ZhbDogQ2xpZW50IEFz c2VydGlvbiBDcmVkZW50aWFsczxCUj4NCjwvU1BBTj48L0ZPTlQ+PC9GT05UPjxGT05UIEZBQ0U9 IkNhbGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOIFNUWUxFPSdmb250LXNp emU6MTFwdCc+IDxCUj4NCk1heWJlIHRoaXMgd2FzIHRoZSBwbGFuIGFsbCBhbG9uZyBidXQgc3Bl Y2lmaWNhdGlvbiBpcyBiZWNvbWluZyB1c2VsZXNzIGZvciBvdXIgc2NlbmFyaW9zIGFuZCB3aWxs IHJlcXVpcmUgdGhhdCB3ZSBoYXZlIHRvIGdvIHdlbGwgYmV5b25kIHRoZSBjb3JlIHNwZWNpZmlj YXRpb24gdG8gbWFrZSB0aGluZ3Mgd29yaywgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlh bHMgYmVpbmcgYSBwcmltZSBleGFtcGxlLiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFs cyBoYXMgYmVlbiBhcm91bmQgZm9yIGEgd2hpbGUgYXMgaXQgd2FzIGEgcmVxdWlyZW1lbnQgZm9y IFdSQVAsIHRoZW4gZHJvcHBlZCB3aGVuIHRoZSB2YXJpb3VzIHNwZWNzIGdvdCBtZXJnZWQgdG8g Zm9ybSBPQVVUSCAyLjAgYW5kIHRoZW4gY2FtZSBiYWNrIGludG8gdGhlIE9BVVRIIDIuMCBhbmQg dGhlbiBoYXMgZ29uZSB0aHJvdWdoIHZhcmlvdXMgY2hhbmdlcyBzaW5jZSB2ZXJzaW9uIDYgZm9y IHRoZSB3b3JzZS4gVGhlcmUgaGFzIGJlZW4gbXVjaCBkaXNjdXNzaW9uIGluIEp1bHkvQXVndXN0 IG92ZXIgdGhpcyBhbmQgbmV3IHRleHQgd2FzIHByb3Bvc2VkLCBidXQgdGhhdCBzZWVtcyB0byBu b3QgYmUgZnVsbHkgYWNjZXB0ZWQsIGJ1dCBJIHRoaW5rIHRoYXQgZm9sbG93cyB0aGUgcGF0aCB3 aGVuIHlvdSB3YW50IHRvIHJlbW92ZSBzb21ldGhpbmcuPEJSPg0KJm5ic3A7PEJSPg0KT3VyIHVz YWdlIHdpbGwgYmUgdmlhIGJlYXJlciB0b2tlbiBhc3NlcnRpb25zIG9ubHkgKGF0IHRoaXMgdGlt ZSk8QlI+DQpUaGUgZ3JhbnRfdHlwZSB3b3VsZCBiZSB0aGUgVVJJIG9mIHRoZSBhc3NlcnRpb24g dHlwZSBiZWluZyB1c2VkPEJSPg0KVGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQgY2FuIHVzZSB3 aGF0IGl0IHdhbnRzIHRvIGJpbmQgdGhlIGFzc2VydGlvbiB0byB0aGUgY2xpZW50X2lkLCBtdWNo IGxpa2UgaXQgaGFzIHRvIHRvZGF5IGZvciB0aGUgcGFzc3dvcmQgYXV0aGVudGljYXRpb24sIGFz IHdlIGhhdmUgc2NlbmFyaW9zIHdlcmUgY2xpZW50X2lkIGhhdmUgbXVsdGlwbGUgcGFzc3dvcmRz PEJSPg0KV2UgdXNlIGd1aWRhbmNlIGZyb20gc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9u IG9mIHRoZSBhc3NlcnRpb24gdHlwZSBiZWluZyB1c2VkIGFsb25nIHdpdGggdGhlIGd1aWRhbmNl IGZyb20gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uPEJSPg0KSWYgbmVlZGVkIEkgY2Fu IGNhcHR1cmUgdGhlIGFzc2VydGlvbnMgYW5kIHJlcXVlc3RzLCBidXQgbm90IHN1cmUgd2hhdCB0 aGUgcG9pbnQgb2YgdGhpcyBpcyBhdCB0aGlzIHRpbWUgc2luY2UgdGhpcyBpcyBub3QgcmVxdWly ZWQgZm9yIHRoZSBwYXNzd29yZCBjcmVkZW50aWFsczxCUj4NCiZuYnNwOzxCUj4NClN1cmUgd2Ug Y2FuIGFkZCB0aGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbiB0byB0aGUgYmVhcmVy IHRva2VuIHNwZWNpZmljYXRpb24gYnV0IEkgZG9uJiM4MjE3O3QgdGhpbmsgdGhhdCBpcyB0aGUg cHJvcGVyIHBsYWNlIHRvIGRvIHRodXMgYnV0IHNpbmNlIGl0JiM4MjE3O3MgZ29uZSBmcm9tIHRo ZSBjb3JlIHdlIHdpbGwgaGF2ZSB0byBkbyBqdXN0IHRoYXQuIFRoZSBzYW1lIHNlZW1zIHRvIGhh cHBlbiB3aXRoIHRoZSBIVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVtZSBhcyBpdCBzZWVtcyB0byBi ZSByZXBlYXRlZCBpbiBmb2xsb3ctb24gY29tcGFuaW9uIHNwZWNpZmljYXRpb25zLiBXaGlsZSBv YXV0aC12MiBpcyBub3QgYW4gYXV0aGVudGljYXRpb24gcHJvdG9jb2wgdGhlcmUgaXMgYSByZXF1 aXJlbWVudCBmb3IgYXV0aGVudGljYXRpb24gdG8gYWRkcmVzcyBzZWN1cml0eSBjb25jZXJucy4g VGhlcmUgaXMgY2xlYXIgc2VwYXJhdGlvbiBiZXR3ZWVuIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRo b3JpemF0aW9uOyB3ZSBhcmUgbm90IHN1Z2dlc3RpbmcgdGhhdCBhdXRoZW50aWNhdGlvbiBpcyBh cHByb3ByaWF0ZSBmYWNpbGl0eSB0byBuZWdvdGlhdGUgYXV0aG9yaXphdGlvbi4gSSB0aGluayB0 aGF0IGl0IG1ha2VzIHNlbnNlIHRvIGluY2x1ZGUgYSBzY2hlbWUgaW4gdGhlIGNvcmUgYW5kIGhh dmUgdGhlIHBhcnRpY3VsYXIgZm9sbG93LW9uIGNvbXBhbmlvbiBzcGVjaWZpY2F0aW9ucyAodGhl IHZhcmlvdXMgdG9rZW4gc3BlY2lmaWNhdGlvbnMpIHN0YXRlL2RlZmluZSB0aGUgcGFyYW1ldGVy cyBhbmQgaWYgdGhleSBkb24mIzgyMTc7dCBsaWtlIHRoZSBkZWZhdWx0IHNjaGVtZSBsZXQgdGhl bSBkZWZpbmUgYSBuZXcgc2NoZW1lIGJ1dCB0aGlzIHB1dHMgYSBzdGFrZSBpbiB0aGUgZ3JvdW5k IGZvciBhbiBIVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVtZS48QlI+DQombmJzcDs8QlI+DQombmJz cDs8QlI+DQo8L1NQQU4+PC9GT05UPjxGT05UIFNJWkU9IjIiPjxGT05UIEZBQ0U9IlRhaG9tYSwg VmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMHB0Jz48 Qj5Gcm9tOjwvQj4gRXJhbiBIYW1tZXItTGFoYXYgPEZPTlQgQ09MT1I9IiMwMDAwRkYiPls8YSBo cmVmPSJtYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNvbSI+bWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5j b208L2E+XTwvRk9OVD4gPEJSPg0KPEI+U2VudDo8L0I+IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIw MTEgNTozOCBQTTxCUj4NCjxCPlRvOjwvQj4gQW50aG9ueSBOYWRhbGluPEJSPg0KPEI+Q2M6PC9C PiBPQXV0aCBXRzxCUj4NCjxCPlN1YmplY3Q6PC9CPiBSRTogUmVtb3ZhbDogQ2xpZW50IEFzc2Vy dGlvbiBDcmVkZW50aWFsczxCUj4NCjwvU1BBTj48L0ZPTlQ+PC9GT05UPjxGT05UIEZBQ0U9IkNh bGlicmksIFZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOIFNUWUxFPSdmb250LXNpemU6 MTFwdCc+IDxCUj4NCkNhbiB5b3Ugc2hhcmUgd2l0aCB0aGUgbGlzdCBob3cgeW91IHBsYW4gdG8g dXNlIHRoaXMgY2xpZW50IGFzc2VydGlvbiBhdXRoZW50aWNhdGlvbiBzY2hlbWU/PEJSPg0KV2hp Y2ggb2YgdGhlIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZXMgeW91IHdpbGwgdXNlIGl0IHdpdGg/ PEJSPg0KV2lsbCB5b3UgdXNlIGl0IHdpdGggdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIGFu ZCBpZiBzbywgaG93IHdpbGwgeW91IGJpbmQgdGhlIGFzc2VydGlvbiB0byB0aGUgY2xpZW50X2lk PzxCUj4NCkNhbiB5b3UgcHJvdmlkZSBmdWxsIGV4YW1wbGVzIG9mIGFzc2VydGlvbnMgYW5kIEhU VFAgcmVxdWVzdHM/PEJSPg0KJm5ic3A7PEJSPg0KSXQgd291bGQgYmUgaGVscGZ1bCB0byBzZWUg aG93IGZhciBhcGFydCB0aGUgcHJvcG9zZWQgdGV4dCBiZWxvdyBpcyBmcm9tIGFuIGFjdHVhbCBp bXBsZW1lbnRhdGlvbiBtYWtpbmcgdXNlIG9mIGl0LiBJIGV4Y2VwdCB0byBzZWUgdGhlc2UgYW5z d2VycyBpbiBhbnkgcXVhbGl0eSBkb2N1bWVudCBkZWZpbmluZyBhIG5ldyBjbGllbnQgYXV0aGVu dGljYXRpb24gc2NoZW1lICh3aGljaCBpcyB0cnVlIGZvciB0aGUgY2xpZW50IHBhc3N3b3JkIGF1 dGhlbnRpY2F0aW9uIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50KS48QlI+DQombmJzcDs8QlI+DQpF SEw8QlI+DQombmJzcDs8QlI+DQombmJzcDs8QlI+DQo8L1NQQU4+PC9GT05UPjxGT05UIFNJWkU9 IjIiPjxGT05UIEZBQ0U9IlRhaG9tYSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4g U1RZTEU9J2ZvbnQtc2l6ZToxMHB0Jz48Qj5Gcm9tOjwvQj4gQW50aG9ueSBOYWRhbGluIDxGT05U IENPTE9SPSIjMDAwMEZGIj5bPGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbSI+ bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT5dPC9GT05UPiA8QlI+DQo8Qj5TZW50Ojwv Qj4gVHVlc2RheSwgSmFudWFyeSAyNSwgMjAxMSAzOjU4IFBNPEJSPg0KPEI+VG86PC9CPiBFcmFu IEhhbW1lci1MYWhhdjsgT0F1dGggV0c7IDxGT05UIENPTE9SPSIjMDAwMEZGIj48YSBocmVmPSJI YW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0Ij5IYW5uZXMuVHNjaG9mZW5pZ0BnbXgubmV0PC9hPjwv Rk9OVD47IEJsYWluZSBDb29rPEJSPg0KPEI+U3ViamVjdDo8L0I+IFJFOiBSZW1vdmFsOiBDbGll bnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPEJSPg0KPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PEZPTlQg RkFDRT0iQ2FsaWJyaSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2Zv bnQtc2l6ZToxMXB0Jz4gPEJSPg0KSSBkb24ndCB1bmRlcnN0YW5kIHRoZSByYXRpb25hbGUgZm9y IHJlbW92aW5nIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzLCBhcyBjbGllbnQgcGFz c3dvcmQgYXV0aGVudGljYXRpb24gaXMgbGVmdCBpbi4gQ2xpZW50IFBhc3N3b3JkIEF1dGhlbnRp Y2F0aW9uIGlzIGFsc28gdW5kZXJzcGVjaWZpZWQgYXMgY2xpZW50X3NlY3JldCBjb3VsZCBiZSBh bnl0aGluZyB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgc2VlbXMgZml0IChyYXcgY2xl YXIgdGV4dCBwYXNzd29yZCwgJm5ic3A7aGFzaCwgZGlnZXN0LCBldGMuKSBhbmQgbm8gd2F5IHRv IGRldGVybWluZSB0aGUgY29udGVudC4gY2xpZW50X3NlY3JldCBpcyBhbHNvIGEgdmVyeSB3ZWFr IG1lY2hhbmlzbSwgc2luY2UgdGhpcyBpcyBsZWZ0IGluIHRoZSBjb3JlIHRoaXMgbGVhZHMgbWUg dG8gYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIHN1cHBvcnQgZm9yIGhhdmluZyBjbGllbnQgYXV0aGVu dGljYXRpb24gaW4gT2F1dGguIEkgZG9uJ3Qgc2VlIGhvdyBoYXZpbmcgY2xpZW50X2Fzc2VydGlv biBhbmQgY2xpZW50X2Fzc2VydGlvbl90eXBlIHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGlzIHVu ZGVyc3BlY2lmaWVkIGFzIGJlaW5nIGEgbWVjaGFuaXNtIGluIHdoaWNoIGFzc2VydGlvbnMgY2Fu IGJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0aW9uLiBBZ3JlZSB0aGF0IHRoZSBhdXRoZW50aWNhdGlv biBzZXJ2ZXIgaGFzIHRvIG1ha2UgcmlnaHQgYW5kIGRlY2xhcmUgd2hhdCBpcyBiZWluZyB1c2Vk IGJ1dCB0aGF0IGlzIHRoZSBzYW1lIGZvciBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24u IFRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gYXNzZXJ0aW9ucyBhcmUgc29tZXRoaW5nIHRoYXQg TWljcm9zb2Z0IGFuZCBHb29nbGUgZmluZCB1c2VmdWwgYW5kIHBsYW4gb24gaW1wbGVtZW50aW5n IGFuZCB1c2luZyBhcyBhIG1lYW5zIGZvciBzdHJvbmdlciBhdXRoZW50aWNhdGlvbiB0byB0aGUg YXV0aG9yaXphdGlvbiBzZXJ2ZXIuIFRoaXMgZXh0ZW5zaWJpbGl0eSBiZWxvbmdzIGluIHRoZSBj b3JlLCB0aGVyZSBpcyBubyBvdGhlciBwbGFjZSB0byBwdXQgdGhpcyBmdW5jdGlvbmFsaXR5LiBJ IGRvbid0IGJlbGlldmUgdGhhdCB0aGUgcmVtb3ZhbCAoZWl0aGVyIGJ5IGVkaXRvciBvciBkaXJl Y3Rpb24gYnkgY28tY2hhaXIpIGlzIHNvbWV0aGluZyB0aGF0IHNob3VsZCBoYXZlIGJlZW4gZG9u ZSB3L28gYSBjb25zZW5zdXMgdm90ZSBzaW5jZSB0aGlzIGhhcyBiZWVuIGluIHRoZSBzcGVjaWZp Y2F0aW9uIGZvciBzb21lIHRpbWUgd2l0aG91dCBpc3N1ZSBhbmQgdGhlIHJlbW92YWwgY29tZXMg YXMgY29tcGxldGUgdW53ZWxjb21lIHN1cnByaXNlLiBHZXR0aW5nIGFsbW9zdCB0b3RhbCByZXdy aXRlcyBvZiB0aGUgc3BlY2lmaWNhdGlvbiB0aGlzIGxhdGUgaW4gdGhlIHJldmlldyBjeWNsZSBp cyBhbHNvIHZlcnkgZGlzdHVyYmluZy48QlI+DQombmJzcDs8QlI+DQpBIHByb3Bvc2FsIGZvciBr ZWVwaW5nIHRoZSBjbGllbnQgYXV0aGVudGljYXRpb24gYXNzZXJ0aW9uIHdvdWxkIGJlIHRvIHNp bXBsaWZ5IHRvIHRoZSBmb2xsb3dpbmc7PEJSPg0KPC9TUEFOPjwvRk9OVD48Rk9OVCBGQUNFPSJW ZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjEycHQnPlRo ZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIGFyZSB1c2VkIGluIGNhc2VzIHdoZXJlIGEg cGFzc3dvcmQgKGNsZWFyLXRleHQgc2hhcmVkIHN5bW1ldHJpYyBzZWNyZXQpIGlzIHVuc3VpdGFi bGUgb3IgZG9lcyBub3QgcHJvdmlkZSBzdWZmaWNpZW50IHNlY3VyaXR5IGZvciBjbGllbnQgYXV0 aGVudGljYXRpb24uIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIHByb3ZpZGUgYW4g ZXh0ZW5zaWJsZSBtZWNoYW5pc20gdG8gdXNlIGFuIGFzc2VydGlvbiBmb3JtYXQgc3VwcG9ydGVk IGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBmb3IgYXV0aGVudGljYXRpb24gb2YgdGhlIGNs aWVudC48QlI+DQo8L1NQQU4+PC9GT05UPjxTUEFOIFNUWUxFPSdmb250LXNpemU6MTJwdCc+PEZP TlQgRkFDRT0iSGVsdmV0aWNhLCBWZXJkYW5hLCBBcmlhbCI+PEJSPg0KPC9GT05UPjxGT05UIEZB Q0U9IlZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPlVzaW5nIGFzc2VydGlvbnMgcmVxdWlyZXMg dGhlIGNsaWVudCB0byBvYnRhaW4gYW4gYXNzZXJ0aW9uIChzdWNoIGFzIGEgPEZPTlQgQ09MT1I9 IiMwMDAwRkYiPlNBTUwgKENhbnRvciwgUy4sIEtlbXAsIEouLCBQaGlscG90dCwgUi4sIGFuZCBF LiBNYWxlciwgJiM4MjIwO0Fzc2VydGlvbnMgYW5kIFByb3RvY29sIGZvciB0aGUgT0FTSVMgU2Vj dXJpdHkgQXNzZXJ0aW9uIE1hcmt1cCBMYW5ndWFnZSAoU0FNTCkgVjIuMCwmIzgyMjE7IE1hcmNo IDIwMDUuKTwvRk9OVD48L0ZPTlQ+PEZPTlQgQ09MT1I9IiMwMDAwRkYiPjxGT05UIEZBQ0U9IlRp bWVzIE5ldyBSb21hbiI+ICZsdDt4LW1zZzovLzkzLyNPQVNJUy5zYW1sLWNvcmUtMi4wLW9zJmd0 OyA8L0ZPTlQ+PC9GT05UPjxGT05UIEZBQ0U9IlZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPltP QVNJUy5zYW1s4oCRY29yZeKAkTIuMOKAkW9zXSBhc3NlcnRpb24pIGZyb20gYW4gYXNzZXJ0aW9u IGlzc3VlciBvciB0byBzZWxmLWlzc3VlIGFuIGFzc2VydGlvbi4gVGhlIGFzc2VydGlvbiBmb3Jt YXQsIHRoZSBwcm9jZXNzIGJ5IHdoaWNoIHRoZSBhc3NlcnRpb24gaXMgb2J0YWluZWQsIGFuZCB0 aGUgbWV0aG9kIG9mIHZhbGlkYXRpbmcgdGhlIGFzc2VydGlvbiBhcmUgZGVmaW5lZCBieSB0aGUg YXNzZXJ0aW9uIGlzc3VlciBhbmQgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLCBhbmQgYXJlIGJl eW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxCUj4NCjwvRk9OVD48Rk9OVCBG QUNFPSJIZWx2ZXRpY2EsIFZlcmRhbmEsIEFyaWFsIj48QlI+DQo8L0ZPTlQ+PEZPTlQgRkFDRT0i VmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+V2hlbiB1c2luZyBhIGNsaWVudCBhc3NlcnRpb24s IHRoZSBjbGllbnQgaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOjxCUj4NCjwvRk9O VD48Rk9OVCBGQUNFPSJIZWx2ZXRpY2EsIFZlcmRhbmEsIEFyaWFsIj48QlI+DQo8L0ZPTlQ+PC9T UEFOPjxGT05UIEZBQ0U9IlZlcmRhbmEsIEhlbHZldGljYSwgQXJpYWwiPjxTUEFOIFNUWUxFPSdm b250LXNpemU6MTFwdCc+Y2xpZW50X2Fzc2VydGlvbl90eXBlIC0gUkVRVUlSRUQuIFRoZSBmb3Jt YXQgb2YgdGhlIGFzc2VydGlvbiBhcyBkZWZpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9uIHNlcnZl ci4gVGhlIHZhbHVlIE1VU1QgYmUgYW4gYWJzb2x1dGUgVVJJLjxCUj4NCmNsaWVudF9hc3NlcnRp b24gLSBSRVFVSVJFRC4gVGhlIGNsaWVudCBhc3NlcnRpb24uPEJSPg0KPC9TUEFOPjxTUEFOIFNU WUxFPSdmb250LXNpemU6MTJwdCc+Rm9yIGV4YW1wbGUsIHRoZSBjbGllbnQgc2VuZHMgdGhlIGZv bGxvd2luZyBhY2Nlc3MgdG9rZW4gcmVxdWVzdCB1c2luZyBhIFNBTUwgMi4wIGFzc2VydGlvbiB0 byBhdXRoZW50aWNhdGUgaXRzZWxmIChsaW5lIGJyZWFrcyBhcmUgZm9yIGRpc3BsYXkgcHVycG9z ZXMgb25seSk6PEJSPg0KPC9TUEFOPjwvRk9OVD48U1BBTiBTVFlMRT0nZm9udC1zaXplOjEycHQn PjxGT05UIEZBQ0U9IkhlbHZldGljYSwgVmVyZGFuYSwgQXJpYWwiPiA8QlI+DQombmJzcDs8QlI+ DQombmJzcDsmbmJzcDtQT1NUIC90b2tlbiBIVFRQLzEuMTxCUj4NCiZuYnNwOyZuYnNwO0hvc3Q6 IDxGT05UIENPTE9SPSIjMDAwMEZGIj5zZXJ2ZXIuZXhhbXBsZS5jb20gJmx0OzxhIGhyZWY9Imh0 dHA6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20vIj5odHRwOi8vc2VydmVyLmV4YW1wbGUuY29tLzwvYT4m Z3Q7IDxCUj4NCjwvRk9OVD4gJm5ic3A7Q29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LXd3dy1m b3JtLXVybGVuY29kZWQ8QlI+DQombmJzcDs8QlI+DQombmJzcDsmbmJzcDtncmFudF90eXBlPWF1 dGhvcml6YXRpb25fY29kZSZhbXA7Y29kZT1pMVdzUm4xdUIxJmFtcDs8QlI+DQombmJzcDsmbmJz cDtjbGllbnRfYXNzZXJ0aW9uPVBITmhiV3h3T2xbLi4ub21pdHRlZCBmb3IgYnJldml0eS4uLl1a VDQlM0QmYW1wOzxCUj4NCiZuYnNwOyZuYnNwO2NsaWVudF9hc3NlcnRpb25fdHlwZT0gJm5ic3A7 dXJuJTNBb2FzaXMlM0FuYW1lcyVzQXRjJTNBU0FNTCUzQTIuMCUzQWFzc2VydGlvbiZhbXA7cmVk aXJlY3RfdXJpPWh0dHBzJTNBJTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiPEJSPg0K Jm5ic3A7PEJSPg0KPC9GT05UPjwvU1BBTj48Rk9OVCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBI ZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjExcHQnPiA8QlI+DQombmJz cDs8QlI+DQombmJzcDs8QlI+DQo8L1NQQU4+PC9GT05UPjxGT05UIFNJWkU9IjIiPjxGT05UIEZB Q0U9IlRhaG9tYSwgVmVyZGFuYSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQt c2l6ZToxMHB0Jz48Qj5Gcm9tOjwvQj4gPEZPTlQgQ09MT1I9IiMwMDAwRkYiPjxhIGhyZWY9Im9h dXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PC9GT05UPiA8 Rk9OVCBDT0xPUj0iIzAwMDBGRiI+WzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dPC9GT05UPiA8Qj5PbiBCZWhh bGYgT2YgPC9CPkVyYW4gSGFtbWVyLUxhaGF2PEJSPg0KPEI+U2VudDo8L0I+IEZyaWRheSwgSmFu dWFyeSAxNCwgMjAxMSAxMDo0NSBQTTxCUj4NCjxCPlRvOjwvQj4gT0F1dGggV0c8QlI+DQo8Qj5T dWJqZWN0OjwvQj4gW09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRp YWxzPEJSPg0KPC9TUEFOPjwvRk9OVD48L0ZPTlQ+PEZPTlQgRkFDRT0iQ2FsaWJyaSwgVmVyZGFu YSwgSGVsdmV0aWNhLCBBcmlhbCI+PFNQQU4gU1RZTEU9J2ZvbnQtc2l6ZToxMXB0Jz4gPEJSPg0K SSB3b3VsZCBsaWtlIHRvIHN1Z2dlc3Qgd2UgZHJvcCB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVk ZW50aWFscyAoLTExIHNlY3Rpb24gMy4yKSBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uLCBhbmQgaWYg bmVlZGVkLCBwdWJsaXNoIGl0IGFzIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiBmb3IgdGhlIGZv bGxvd2luZyByZWFzb25zOjxCUj4NCiZuYnNwOzxCUj4NCjEuICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwO1RoZSBtZWNoYW5pc20gaXMgdW5kZXIgc3BlY2lmaWVkLCBlc3BlY2lh bGx5IGluIGl0cyBoYW5kbGluZyBvZiB0aGUgY2xpZW50X2lkIGlkZW50aWZpZXIgKHdoZW4gdXNl ZCB0byBvYnRhaW4gZW5kLXVzZXIgYXV0aG9yaXphdGlvbikuIEl0IGRvZXMgbm90IGNvbnRhaW4g YW55IGltcGxlbWVudGF0aW9uIGRldGFpbHMgdG8gYWNjb21wbGlzaCBhbnkgbGV2ZWwgb2YgaW50 ZXJvcGVyYWJpbGl0eSBvciBmdW5jdGlvbmFsaXR5LiBUaGlzIGlzIGluIGNvbnRyYXN0IHRvIHRo ZSBhc3NlcnRpb24gZ3JhbnQgdHlwZSB3aGljaCBoYXMgbWF0dXJlZCBvdmVyIGEgeWVhciBpbnRv IGEgZnVsbHkgdGhvdWdodC1vdXQgZXh0ZW5zaW9uIG1lY2hhbmlzbSwgYXMgd2VsbCBhcyBhIHNl cGFyYXRlIFNBTUwgYXNzZXJ0aW9uIHNwZWNpZmljYXRpb24gd2l0aCBhY3RpdmUgZGVwbG95bWVu dCAodGhlIHR3bywgdG9nZXRoZXIgd2l0aCBydW5uaW5nIGNvZGUsIHNob3cgY2xlYXIgY29uc2Vu c3VzKS48QlI+DQoyLiAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtUaGUgc2Vj dGlvbiBpcyBhIGNvbmZ1c2VkIG1peCBvZiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzcHJpbmts ZWQgd2l0aCBub3JtYXRpdmUgbGFuZ3VhZ2UuIEluc3RlYWQsIGl0IHNob3VsZCBiZSByZXBsYWNl ZCB3aXRoIGd1aWRlbGluZXMgZm9yIGV4dGVuZGluZyB0aGUgc2V0IG9mIHN1cHBvcnRlZCBjbGll bnQgY3JlZGVudGlhbHMsIGJ1dCB3aXRob3V0IGRlZmluaW5nIGEgbmV3IHJlZ2lzdHJ5LiBJdCBp cyBjbGVhcmx5IGFuIGFyZWEgb2YgbGl0dGxlIGRlcGxveW1lbnQgZXhwZXJpZW5jZSBmb3IgT0F1 dGgsIGFuZCB0aGF0IGluY2x1ZGVzIHVzaW5nIEhUVFAgQmFzaWMgYXV0aGVudGljYXRpb24gZm9y IGNsaWVudCBhdXRoZW50aWNhdGlvbiAobW9yZSBvbiB0aGF0IHRvIGNvbWUpLjxCUj4NCjMuICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBzZWN0aW9uIGhhcyByZWNlaXZl ZCBhIGxpdHRsZSBzdXBwb3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3NlIHdobyBzdGls bCB3YW50IHRvIGFkdm9jYXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkgY29uc2Vuc3Vz IGZvciBrZWVwaW5nIGl0LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBvcnQgZm9yIGRl cGxveWluZyBpdC4gRGVwbG95bWVudCwgb2YgY291cnNlLCB3aWxsIGFsc28gcmVxdWlyZSBzaG93 aW5nIHByb2dyZXNzIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9maWxpbmcgdGhlIG1lY2hh bmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS48QlI+DQombmJzcDs8QlI+ DQpDb21tZW50cz8gQ291bnRlci1hcmd1bWVudHM/PEJSPg0KJm5ic3A7PEJSPg0KRUhMPEJSPg0K Jm5ic3A7PEJSPg0KJm5ic3A7PEJSPg0KPC9TUEFOPjwvRk9OVD48Rk9OVCBGQUNFPSJIZWx2ZXRp Y2EsIFZlcmRhbmEsIEFyaWFsIj48U1BBTiBTVFlMRT0nZm9udC1zaXplOjEycHQnPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KT0F1dGggbWFpbGlu ZyBsaXN0PEJSPg0KPEZPTlQgQ09MT1I9IiMwMDAwRkYiPjxhIGhyZWY9Ik9BdXRoQGlldGYub3Jn Ij5PQXV0aEBpZXRmLm9yZzwvYT48QlI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29hdXRoPC9hPjxCUj4NCjwvRk9OVD48L1NQQU4+PC9GT05UPjwvQkxPQ0tRVU9URT48Rk9O VCBGQUNFPSJDYWxpYnJpLCBWZXJkYW5hLCBIZWx2ZXRpY2EsIEFyaWFsIj48U1BBTiBTVFlMRT0n Zm9udC1zaXplOjExcHQnPjxCUj4NCjxCUj4NCjwvU1BBTj48L0ZPTlQ+PC9CTE9DS1FVT1RFPg0K PC9CT0RZPg0KPC9IVE1MPg0KDQo= --_000_C9686FD710250eranhueniversecom_-- From Michael.Jones@microsoft.com Fri Jan 28 13:33:15 2011 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 A62933A68A7 for ; Fri, 28 Jan 2011 13:33:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.589 X-Spam-Level: X-Spam-Status: No, score=-10.589 tagged_above=-999 required=5 tests=[AWL=0.009, 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 799d8gARxOsG for ; Fri, 28 Jan 2011 13:33:10 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 7DAF43A6876 for ; Fri, 28 Jan 2011 13:33:10 -0800 (PST) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 13:36:17 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0270.002; Fri, 28 Jan 2011 13:36:17 -0800 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification draft -02 Thread-Index: Acu/M2Nlc5Ah9YfFTfu+PALXm4nBEQ== Date: Fri, 28 Jan 2011 21:36:16 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246FD307@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246FD307TK5EX14MBXC202r_" MIME-Version: 1.0 Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 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, 28 Jan 2011 21:33:15 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246FD307TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've published draft 02 of the bearer token specification. This incorporat= es consensus feedback received to date. It contains no normative changes r= elative to draft 01. Your feedback is solicited. Specific changes were: * Changed terminology from "token reuse" to "token capture and repl= ay". * Removed sentence "Encrypting the token contents is another altern= ative" from the security considerations since it was redundant and potentia= lly confusing. * Corrected some references to "resource server" to be "authorizati= on server" in the security considerations. * Generalized security considerations language about obtaining cons= ent of the resource owner. * Broadened scope of security considerations description for recomm= endation "Don't pass bearer tokens in page URLs". * Removed unused reference to OAuth 1.0. * Updated reference to framework specification and updated David Re= cordon's e-mail address. * Removed security considerations text on authenticating clients. * Registered the "OAuth2" OAuth access token type and "oauth_token"= parameter. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02= .txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02= .xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion= repository, with html, txt, and html versions available) This version is explicitly not ready for working group last call, as change= s may need to be made due to the open issues in the framework spec about th= e removal of the Client Assertion Credentials and OAuth2 HTTP Authenticatio= n Scheme. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943246FD307TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ve published draft 02 of the bearer token sp= ecification.  This incorporates consensus feedback received to date.&n= bsp; It contains no normative changes relative to draft 01.  Your feed= back is solicited.  Specific changes were:

·         Changed terminology from "token reuse&q= uot; to "token capture and replay".

·         Removed sentence "Encrypting the token = contents is another alternative" from the security considerations sinc= e it was redundant and potentially confusing.

·         Corrected some references to "resource = server" to be "authorization server" in the security conside= rations.

·         Generalized security considerations language= about obtaining consent of the resource owner.

·         Broadened scope of security considerations d= escription for recommendation "Don't pass bearer tokens in page URLs&q= uot;.

·         Removed unused reference to OAuth 1.0. =

·         Updated reference to framework specification= and updated David Recordon's e-mail address.

·         Removed security considerations text on auth= enticating clients.

·         Registered the "OAuth2" OAuth acce= ss token type and "oauth_token" parameter.

 

The draft is available at these locations:

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-02.txt

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-02.xml

·         http://self-issued.info/docs/draft-ietf-oau= th-v2-bearer-02.html

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-02.txt

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-02.xml

·         http://svn.openid.net/repos/specifications/oauth/2.0/= (Subversion repository, with html, txt, and html versions available)

 

This version is explicitly not ready for working gro= up last call, as changes may need to be made due to the open issues in the = framework spec about the removal of the Client Assertion Credentials and OA= uth2 HTTP Authentication Scheme.

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943246FD307TK5EX14MBXC202r_-- From Michael.Jones@microsoft.com Fri Jan 28 13:37:04 2011 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 206B53A68A7 for ; Fri, 28 Jan 2011 13:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.59 X-Spam-Level: X-Spam-Status: No, score=-10.59 tagged_above=-999 required=5 tests=[AWL=0.008, 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 dz0fPMDMypzx for ; Fri, 28 Jan 2011 13:36:58 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id 99D383A6876 for ; Fri, 28 Jan 2011 13:36:58 -0800 (PST) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 13:40:05 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.01.0270.002; Fri, 28 Jan 2011 13:40:05 -0800 From: Mike Jones To: Eran Hammer-Lahav Thread-Topic: Update required for bearer token spec Thread-Index: Acu+avwIUa4jqg8VSoSmxUSLKyIfiAAA88UwAADrfZAABY/aAAABdGzQAClRNpA= Date: Fri, 28 Jan 2011 21:40:04 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246FD332@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FBB0C@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246FD332TK5EX14MBXC202r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Update required for bearer token spec 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, 28 Jan 2011 21:37:04 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246FD332TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft 02 as published registers the parameters in the IANA Considerations s= ection and therefore conforms to draft -12, per your request. Therefore pl= ease retain the bearer token examples, as they are useful to implementers. I intentionally made no breaking changes to maintain specification stabilit= y. -- Mike From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, January 27, 2011 6:24 PM To: Mike Jones Cc: OAuth WG; 'Manger, James H (James.H.Manger@team.telstra.com)' Subject: RE: Update required for bearer token spec The bearer draft must include the registration template as done in draft-ha= mmer-oauth-v2-mac-token section 8 including giving the name used for issuin= g such tokens for the token_type parameter. Every RFC must include an IANA = Considerations section and your is currently in violation of -12. If you ha= ve an issue with the registration process or language in -12, the appropria= te thing to do is to raise those issues on the list. I will remove the bearer token examples from -13 due to my objections to th= e 'OAuth2' scheme name (which makes it an open issue) and lack of registrat= ion and token type name in the bearer token draft. I will gladly put those = examples back (as they are listed in -12) once these concerns are resolved = (or if instructed to by the chairs and area director). I will keep the info= rmative reference in -13, and will only remove the examples which are incor= rect. --- As for the open issues: the bearer token scheme name - if it wasn't clear, = I plan to use every mean available to me to block the bearer token draft fr= om using the 'OAuth2' scheme name, and will raise this issue in the WGLC, A= rea Director review, IETF LC, and direct appeal to the IESG if necessary. Y= ou might consider this childish, but I consider bearer tokens a disaster w= aiting to happen and will not allow the weakest form of token authenticatio= n to carry the strongest form of endorsement and perception (via the OAuth = brand). At the end, you might get the scheme name you want, but it will cost you si= gnificant delays in getting that document published as an RFC and with a Pr= oposed Standard designation. So far you have failed to raise any technical = justification for your insistence of using that name. The only reason so fa= r is that it will be less confusing. Perhaps. But will be more damaging. Af= ter all, why would anyone look at the MAC token specification or other stro= nger authentication schemes, when you offer them the "official" OAuth 2.0 s= cheme. I also want to point out that I am not the only one here who made this requ= est. I consent that there isn't consensus to changing the name, but there i= sn't consensus to keeping it either. The "vote" is around 2-4 on each side. If you are willing to spend the next few months arguing over 6 characters i= n your document, I will gladly oblige. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, January 27, 2011 5:15 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Once approved, the existing names will be registered, hence no changes are = needed to the bearer token draft to comply with these requirements. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, January 27, 2011 2:36 PM To: Mike Jones Cc: OAuth WG Subject: RE: Update required for bearer token spec -12 section 8.1 and 10.1. EHL From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Thursday, January 27, 2011 2:10 PM To: Eran Hammer-Lahav Cc: OAuth WG Subject: RE: Update required for bearer token spec Your request below is ambiguous. Please provide the precise new text you'r= e requesting and the rationale for it. From: Eran Hammer-Lahav [mailto:eran@hueniverse.com] Sent: Thursday, January 27, 2011 1:42 PM To: Mike Jones Cc: OAuth WG Subject: Update required for bearer token spec Please update the draft to comply with -12 registration guidelines and requ= irements asap. EHL --_000_4E1F6AAD24975D4BA5B1680429673943246FD332TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Draft 02 as published = registers the parameters in the IANA Considerations section and therefore c= onforms to draft -12, per your request.  Therefore please retain the b= earer token examples, as they are useful to implementers.

 

I intentionally made n= o breaking changes to maintain specification stability.

 

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

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, January 27, 2011 6:24 PM
To: Mike Jones
Cc: OAuth WG; 'Manger, James H (James.H.Manger@team.telstra.com)' Subject: RE: Update required for bearer token spec=

 

The bearer draft must = include the registration template as done in draft-hammer-oauth-v2-mac-toke= n section 8 including giving the name used for issuing such tokens for the = token_type parameter. Every RFC must include an IANA Considerations section and your is currently in violation = of -12. If you have an issue with the registration process or language in -= 12, the appropriate thing to do is to raise those issues on the list.<= /o:p>

 

I will remove the bear= er token examples from -13 due to my objections to the ‘OAuth2’= scheme name (which makes it an open issue) and lack of registration and to= ken type name in the bearer token draft. I will gladly put those examples back (as they are listed in -12) once these conc= erns are resolved (or if instructed to by the chairs and area director). I = will keep the informative reference in -13, and will only remove the exampl= es which are incorrect.

 

---<= /p>

 

As for the open issues= : the bearer token scheme name - if it wasn’t clear, I plan to use ev= ery mean available to me to block the bearer token draft from using the = 216;OAuth2’ scheme name, and will raise this issue in the WGLC, Area Director review, IETF LC, and direct appeal to the IESG = if necessary. You might consider this childish, but I consider  bearer= tokens a disaster waiting to happen and will not allow the weakest form of= token authentication to carry the strongest form of endorsement and perception (via the OAuth brand).

 

At the end, you might = get the scheme name you want, but it will cost you significant delays in ge= tting that document published as an RFC and with a Proposed Standard design= ation. So far you have failed to raise any technical justification for your insistence of using that name. The on= ly reason so far is that it will be less confusing. Perhaps. But will be mo= re damaging. After all, why would anyone look at the MAC token specificatio= n or other stronger authentication schemes, when you offer them the “official” OAuth 2.0 scheme.<= o:p>

 

I also want to point o= ut that I am not the only one here who made this request. I consent that th= ere isn’t consensus to changing the name, but there isn’t conse= nsus to keeping it either. The “vote” is around 2-4 on each side.

 

If you are willing to = spend the next few months arguing over 6 characters in your document, I wil= l gladly oblige.

 

EHL<= /p>

 

 

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, January 27, 2011 5:15 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: RE: Update required for bearer token spec=

 

Once approved, the exi= sting names will be registered, hence no changes are needed to the bearer t= oken draft to comply with these requirements.

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, January 27, 2011 2:36 PM
To: Mike Jones
Cc: OAuth WG
Subject: RE: Update required for bearer token spec=

 

-12 section 8.1 and 10= .1.

 

EHL<= /p>

 

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, January 27, 2011 2:10 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: RE: Update required for bearer token spec=

 

Your request below is = ambiguous.  Please provide the precise new text you’re requestin= g and the rationale for it.

 

From: Eran Ham= mer-Lahav [mailto:eran@hueniverse.com]
Sent: Thursday, January 27, 2011 1:42 PM
To: Mike Jones
Cc: OAuth WG
Subject: Update required for bearer token spec

 

Please update the draft to comply with -12 registrat= ion guidelines and requirements asap.

 

EHL

--_000_4E1F6AAD24975D4BA5B1680429673943246FD332TK5EX14MBXC202r_-- From Internet-Drafts@ietf.org Fri Jan 28 13:45:03 2011 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 BE66F3A6939; Fri, 28 Jan 2011 13:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, 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 YiT7kAQbIPyQ; Fri, 28 Jan 2011 13:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120993A6930; Fri, 28 Jan 2011 13:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110128214502.1294.33582.idtracker@localhost> Date: Fri, 28 Jan 2011 13:45:02 -0800 Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action:draft-ietf-oauth-v2-bearer-02.txt 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, 28 Jan 2011 21:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : M. Jones, et al. Filename : draft-ietf-oauth-v2-bearer-02.txt Pages : 13 Date : 2011-01-28 This specification describes how to use bearer tokens when accessing OAuth 2.0 protected resources. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-oauth-v2-bearer-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-28133100.I-D@ietf.org> --NextPart-- From eran@hueniverse.com Fri Jan 28 13:52:13 2011 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 7010A3A6960 for ; Fri, 28 Jan 2011 13:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.024, 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 U0khAWzmJskG for ; Fri, 28 Jan 2011 13:52:11 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C25873A6975 for ; Fri, 28 Jan 2011 13:52:10 -0800 (PST) Received: (qmail 9448 invoked from network); 28 Jan 2011 21:55:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jan 2011 21:55:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 28 Jan 2011 14:55:14 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Fri, 28 Jan 2011 14:55:09 -0700 Thread-Topic: Update required for bearer token spec Thread-Index: Acu/Ngr27SB15OSEROGX4k45HjPihw== Message-ID: <236CB996-6D46-4590-B308-F4C045F23C84@hueniverse.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FBB0C@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FD332@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246FD332@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_236CB9966D464590B308F4C045F23C84hueniversecom_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Update required for bearer token spec 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, 28 Jan 2011 21:52:13 -0000 --_000_236CB9966D464590B308F4C045F23C84hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3aWxsIGJ1dCB3aWxsIHJlcGxhY2UgdGhlIHNjaGVtZSBhbmQgdG9rZW4gbmFtZXMgd2l0aCBb W3RiZF1dIHVudGlsIHRoZSBpc3N1ZSBpcyByZXNvbHZlZC4NCg0KRUhMDQoNCk9uIEphbiAyOCwg MjAxMSwgYXQgMTM6NDAsICJNaWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KRHJhZnQgMDIg YXMgcHVibGlzaGVkIHJlZ2lzdGVycyB0aGUgcGFyYW1ldGVycyBpbiB0aGUgSUFOQSBDb25zaWRl cmF0aW9ucyBzZWN0aW9uIGFuZCB0aGVyZWZvcmUgY29uZm9ybXMgdG8gZHJhZnQgLTEyLCBwZXIg eW91ciByZXF1ZXN0LiAgVGhlcmVmb3JlIHBsZWFzZSByZXRhaW4gdGhlIGJlYXJlciB0b2tlbiBl eGFtcGxlcywgYXMgdGhleSBhcmUgdXNlZnVsIHRvIGltcGxlbWVudGVycy4NCg0KSSBpbnRlbnRp b25hbGx5IG1hZGUgbm8gYnJlYWtpbmcgY2hhbmdlcyB0byBtYWludGFpbiBzcGVjaWZpY2F0aW9u IHN0YWJpbGl0eS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYg W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjcs IDIwMTEgNjoyNCBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBPQXV0aCBXRzsgJ01hbmdlciwgSmFt ZXMgSCAoSmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5n ZXJAdGVhbS50ZWxzdHJhLmNvbT4pJw0KU3ViamVjdDogUkU6IFVwZGF0ZSByZXF1aXJlZCBmb3Ig YmVhcmVyIHRva2VuIHNwZWMNCg0KVGhlIGJlYXJlciBkcmFmdCBtdXN0IGluY2x1ZGUgdGhlIHJl Z2lzdHJhdGlvbiB0ZW1wbGF0ZSBhcyBkb25lIGluIGRyYWZ0LWhhbW1lci1vYXV0aC12Mi1tYWMt dG9rZW4gc2VjdGlvbiA4IGluY2x1ZGluZyBnaXZpbmcgdGhlIG5hbWUgdXNlZCBmb3IgaXNzdWlu ZyBzdWNoIHRva2VucyBmb3IgdGhlIHRva2VuX3R5cGUgcGFyYW1ldGVyLiBFdmVyeSBSRkMgbXVz dCBpbmNsdWRlIGFuIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhbmQgeW91ciBpcyBjdXJy ZW50bHkgaW4gdmlvbGF0aW9uIG9mIC0xMi4gSWYgeW91IGhhdmUgYW4gaXNzdWUgd2l0aCB0aGUg cmVnaXN0cmF0aW9uIHByb2Nlc3Mgb3IgbGFuZ3VhZ2UgaW4gLTEyLCB0aGUgYXBwcm9wcmlhdGUg dGhpbmcgdG8gZG8gaXMgdG8gcmFpc2UgdGhvc2UgaXNzdWVzIG9uIHRoZSBsaXN0Lg0KDQpJIHdp bGwgcmVtb3ZlIHRoZSBiZWFyZXIgdG9rZW4gZXhhbXBsZXMgZnJvbSAtMTMgZHVlIHRvIG15IG9i amVjdGlvbnMgdG8gdGhlIOKAmE9BdXRoMuKAmSBzY2hlbWUgbmFtZSAod2hpY2ggbWFrZXMgaXQg YW4gb3BlbiBpc3N1ZSkgYW5kIGxhY2sgb2YgcmVnaXN0cmF0aW9uIGFuZCB0b2tlbiB0eXBlIG5h bWUgaW4gdGhlIGJlYXJlciB0b2tlbiBkcmFmdC4gSSB3aWxsIGdsYWRseSBwdXQgdGhvc2UgZXhh bXBsZXMgYmFjayAoYXMgdGhleSBhcmUgbGlzdGVkIGluIC0xMikgb25jZSB0aGVzZSBjb25jZXJu cyBhcmUgcmVzb2x2ZWQgKG9yIGlmIGluc3RydWN0ZWQgdG8gYnkgdGhlIGNoYWlycyBhbmQgYXJl YSBkaXJlY3RvcikuIEkgd2lsbCBrZWVwIHRoZSBpbmZvcm1hdGl2ZSByZWZlcmVuY2UgaW4gLTEz LCBhbmQgd2lsbCBvbmx5IHJlbW92ZSB0aGUgZXhhbXBsZXMgd2hpY2ggYXJlIGluY29ycmVjdC4N Cg0KLS0tDQoNCkFzIGZvciB0aGUgb3BlbiBpc3N1ZXM6IHRoZSBiZWFyZXIgdG9rZW4gc2NoZW1l IG5hbWUgLSBpZiBpdCB3YXNu4oCZdCBjbGVhciwgSSBwbGFuIHRvIHVzZSBldmVyeSBtZWFuIGF2 YWlsYWJsZSB0byBtZSB0byBibG9jayB0aGUgYmVhcmVyIHRva2VuIGRyYWZ0IGZyb20gdXNpbmcg dGhlIOKAmE9BdXRoMuKAmSBzY2hlbWUgbmFtZSwgYW5kIHdpbGwgcmFpc2UgdGhpcyBpc3N1ZSBp biB0aGUgV0dMQywgQXJlYSBEaXJlY3RvciByZXZpZXcsIElFVEYgTEMsIGFuZCBkaXJlY3QgYXBw ZWFsIHRvIHRoZSBJRVNHIGlmIG5lY2Vzc2FyeS4gWW91IG1pZ2h0IGNvbnNpZGVyIHRoaXMgY2hp bGRpc2gsIGJ1dCBJIGNvbnNpZGVyICBiZWFyZXIgdG9rZW5zIGEgZGlzYXN0ZXIgd2FpdGluZyB0 byBoYXBwZW4gYW5kIHdpbGwgbm90IGFsbG93IHRoZSB3ZWFrZXN0IGZvcm0gb2YgdG9rZW4gYXV0 aGVudGljYXRpb24gdG8gY2FycnkgdGhlIHN0cm9uZ2VzdCBmb3JtIG9mIGVuZG9yc2VtZW50IGFu ZCBwZXJjZXB0aW9uICh2aWEgdGhlIE9BdXRoIGJyYW5kKS4NCg0KQXQgdGhlIGVuZCwgeW91IG1p Z2h0IGdldCB0aGUgc2NoZW1lIG5hbWUgeW91IHdhbnQsIGJ1dCBpdCB3aWxsIGNvc3QgeW91IHNp Z25pZmljYW50IGRlbGF5cyBpbiBnZXR0aW5nIHRoYXQgZG9jdW1lbnQgcHVibGlzaGVkIGFzIGFu IFJGQyBhbmQgd2l0aCBhIFByb3Bvc2VkIFN0YW5kYXJkIGRlc2lnbmF0aW9uLiBTbyBmYXIgeW91 IGhhdmUgZmFpbGVkIHRvIHJhaXNlIGFueSB0ZWNobmljYWwganVzdGlmaWNhdGlvbiBmb3IgeW91 ciBpbnNpc3RlbmNlIG9mIHVzaW5nIHRoYXQgbmFtZS4gVGhlIG9ubHkgcmVhc29uIHNvIGZhciBp cyB0aGF0IGl0IHdpbGwgYmUgbGVzcyBjb25mdXNpbmcuIFBlcmhhcHMuIEJ1dCB3aWxsIGJlIG1v cmUgZGFtYWdpbmcuIEFmdGVyIGFsbCwgd2h5IHdvdWxkIGFueW9uZSBsb29rIGF0IHRoZSBNQUMg dG9rZW4gc3BlY2lmaWNhdGlvbiBvciBvdGhlciBzdHJvbmdlciBhdXRoZW50aWNhdGlvbiBzY2hl bWVzLCB3aGVuIHlvdSBvZmZlciB0aGVtIHRoZSDigJxvZmZpY2lhbOKAnSBPQXV0aCAyLjAgc2No ZW1lLg0KDQpJIGFsc28gd2FudCB0byBwb2ludCBvdXQgdGhhdCBJIGFtIG5vdCB0aGUgb25seSBv bmUgaGVyZSB3aG8gbWFkZSB0aGlzIHJlcXVlc3QuIEkgY29uc2VudCB0aGF0IHRoZXJlIGlzbuKA mXQgY29uc2Vuc3VzIHRvIGNoYW5naW5nIHRoZSBuYW1lLCBidXQgdGhlcmUgaXNu4oCZdCBjb25z ZW5zdXMgdG8ga2VlcGluZyBpdCBlaXRoZXIuIFRoZSDigJx2b3Rl4oCdIGlzIGFyb3VuZCAyLTQg b24gZWFjaCBzaWRlLg0KDQpJZiB5b3UgYXJlIHdpbGxpbmcgdG8gc3BlbmQgdGhlIG5leHQgZmV3 IG1vbnRocyBhcmd1aW5nIG92ZXIgNiBjaGFyYWN0ZXJzIGluIHlvdXIgZG9jdW1lbnQsIEkgd2ls bCBnbGFkbHkgb2JsaWdlLg0KDQpFSEwNCg0KDQoNCkZyb206IE1pa2UgSm9uZXMgW21haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyNywg MjAxMSA1OjE1IFBNDQpUbzogRXJhbiBIYW1tZXItTGFoYXYNCkNjOiBPQXV0aCBXRw0KU3ViamVj dDogUkU6IFVwZGF0ZSByZXF1aXJlZCBmb3IgYmVhcmVyIHRva2VuIHNwZWMNCg0KT25jZSBhcHBy b3ZlZCwgdGhlIGV4aXN0aW5nIG5hbWVzIHdpbGwgYmUgcmVnaXN0ZXJlZCwgaGVuY2Ugbm8gY2hh bmdlcyBhcmUgbmVlZGVkIHRvIHRoZSBiZWFyZXIgdG9rZW4gZHJhZnQgdG8gY29tcGx5IHdpdGgg dGhlc2UgcmVxdWlyZW1lbnRzLg0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVy YW5AaHVlbml2ZXJzZS5jb21dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAyNywgMjAxMSAyOjM2 IFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IE9BdXRoIFdHDQpTdWJqZWN0OiBSRTogVXBkYXRlIHJl cXVpcmVkIGZvciBiZWFyZXIgdG9rZW4gc3BlYw0KDQotMTIgc2VjdGlvbiA4LjEgYW5kIDEwLjEu DQoNCkVITA0KDQpGcm9tOiBNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv ZnQuY29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjcsIDIwMTEgMjoxMCBQTQ0KVG86IEVy YW4gSGFtbWVyLUxhaGF2DQpDYzogT0F1dGggV0cNClN1YmplY3Q6IFJFOiBVcGRhdGUgcmVxdWly ZWQgZm9yIGJlYXJlciB0b2tlbiBzcGVjDQoNCllvdXIgcmVxdWVzdCBiZWxvdyBpcyBhbWJpZ3Vv dXMuICBQbGVhc2UgcHJvdmlkZSB0aGUgcHJlY2lzZSBuZXcgdGV4dCB5b3XigJlyZSByZXF1ZXN0 aW5nIGFuZCB0aGUgcmF0aW9uYWxlIGZvciBpdC4NCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYg W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMjcs IDIwMTEgMTo0MiBQTQ0KVG86IE1pa2UgSm9uZXMNCkNjOiBPQXV0aCBXRw0KU3ViamVjdDogVXBk YXRlIHJlcXVpcmVkIGZvciBiZWFyZXIgdG9rZW4gc3BlYw0KDQpQbGVhc2UgdXBkYXRlIHRoZSBk cmFmdCB0byBjb21wbHkgd2l0aCAtMTIgcmVnaXN0cmF0aW9uIGd1aWRlbGluZXMgYW5kIHJlcXVp cmVtZW50cyBhc2FwLg0KDQpFSEwNCg== --_000_236CB9966D464590B308F4C045F23C84hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5JIHdpbGwgYnV0IHdpbGwgcmVwbGFj ZSB0aGUgc2NoZW1lIGFuZCB0b2tlbiBuYW1lcyB3aXRoIFtbdGJkXV0gdW50aWwgdGhlIGlzc3Vl IGlzIHJlc29sdmVkLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RUhMPGJyPjxicj5P biBKYW4gMjgsIDIwMTEsIGF0IDEzOjQwLCAiTWlrZSBKb25lcyIgJmx0OzxhIGhyZWY9Im1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGRpdj48L2Rpdj48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48ZGl2Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAyMDYwIj5EcmFmdCAwMiBhcyBwdWJsaXNoZWQg cmVnaXN0ZXJzIHRoZSBwYXJhbWV0ZXJzIGluIHRoZSBJQU5BIENvbnNpZGVyYXRpb25zIHNlY3Rp b24gYW5kIHRoZXJlZm9yZSBjb25mb3JtcyB0byBkcmFmdCAtMTIsIHBlciB5b3VyIHJlcXVlc3Qu Jm5ic3A7IFRoZXJlZm9yZSBwbGVhc2UgcmV0YWluIHRoZSBiZWFyZXIgdG9rZW4gZXhhbXBsZXMs IGFzIHRoZXkgYXJlIHVzZWZ1bA0KIHRvIGltcGxlbWVudGVycy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMjA2MCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPkkgaW50ZW50aW9uYWxseSBtYWRlIG5vIGJyZWFraW5nIGNoYW5n ZXMgdG8gbWFpbnRhaW4gc3BlY2lmaWNhdGlvbiBzdGFiaWxpdHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg LS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAyNywgMjAxMSA2OjI0IFBN PGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRzsgJ01h bmdlciwgSmFtZXMgSCAoPGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3Ry YS5jb20iPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L2E+KSc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUkU6IFVwZGF0ZSByZXF1aXJlZCBmb3IgYmVhcmVyIHRva2VuIHNwZWM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+VGhlIGJlYXJlciBkcmFmdCBtdXN0IGluY2x1ZGUgdGhlIHJlZ2lzdHJhdGlv biB0ZW1wbGF0ZSBhcyBkb25lIGluIGRyYWZ0LWhhbW1lci1vYXV0aC12Mi1tYWMtdG9rZW4gc2Vj dGlvbiA4IGluY2x1ZGluZyBnaXZpbmcgdGhlIG5hbWUgdXNlZCBmb3IgaXNzdWluZyBzdWNoIHRv a2VucyBmb3IgdGhlIHRva2VuX3R5cGUgcGFyYW1ldGVyLiBFdmVyeSBSRkMgbXVzdA0KIGluY2x1 ZGUgYW4gSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFuZCB5b3VyIGlzIGN1cnJlbnRseSBp biB2aW9sYXRpb24gb2YgLTEyLiBJZiB5b3UgaGF2ZSBhbiBpc3N1ZSB3aXRoIHRoZSByZWdpc3Ry YXRpb24gcHJvY2VzcyBvciBsYW5ndWFnZSBpbiAtMTIsIHRoZSBhcHByb3ByaWF0ZSB0aGluZyB0 byBkbyBpcyB0byByYWlzZSB0aG9zZSBpc3N1ZXMgb24gdGhlIGxpc3QuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIHdpbGwgcmVtb3ZlIHRoZSBiZWFyZXIgdG9rZW4gZXhh bXBsZXMgZnJvbSAtMTMgZHVlIHRvIG15IG9iamVjdGlvbnMgdG8gdGhlIOKAmE9BdXRoMuKAmSBz Y2hlbWUgbmFtZSAod2hpY2ggbWFrZXMgaXQgYW4gb3BlbiBpc3N1ZSkgYW5kIGxhY2sgb2YgcmVn aXN0cmF0aW9uIGFuZCB0b2tlbiB0eXBlIG5hbWUgaW4gdGhlIGJlYXJlciB0b2tlbiBkcmFmdC4g SSB3aWxsDQogZ2xhZGx5IHB1dCB0aG9zZSBleGFtcGxlcyBiYWNrIChhcyB0aGV5IGFyZSBsaXN0 ZWQgaW4gLTEyKSBvbmNlIHRoZXNlIGNvbmNlcm5zIGFyZSByZXNvbHZlZCAob3IgaWYgaW5zdHJ1 Y3RlZCB0byBieSB0aGUgY2hhaXJzIGFuZCBhcmVhIGRpcmVjdG9yKS4gSSB3aWxsIGtlZXAgdGhl IGluZm9ybWF0aXZlIHJlZmVyZW5jZSBpbiAtMTMsIGFuZCB3aWxsIG9ubHkgcmVtb3ZlIHRoZSBl eGFtcGxlcyB3aGljaCBhcmUgaW5jb3JyZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+LS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BcyBmb3Ig dGhlIG9wZW4gaXNzdWVzOiB0aGUgYmVhcmVyIHRva2VuIHNjaGVtZSBuYW1lIC0gaWYgaXQgd2Fz buKAmXQgY2xlYXIsIEkgcGxhbiB0byB1c2UgZXZlcnkgbWVhbiBhdmFpbGFibGUgdG8gbWUgdG8g YmxvY2sgdGhlIGJlYXJlciB0b2tlbiBkcmFmdCBmcm9tIHVzaW5nIHRoZSDigJhPQXV0aDLigJkg c2NoZW1lIG5hbWUsIGFuZCB3aWxsIHJhaXNlIHRoaXMgaXNzdWUNCiBpbiB0aGUgV0dMQywgQXJl YSBEaXJlY3RvciByZXZpZXcsIElFVEYgTEMsIGFuZCBkaXJlY3QgYXBwZWFsIHRvIHRoZSBJRVNH IGlmIG5lY2Vzc2FyeS4gWW91IG1pZ2h0IGNvbnNpZGVyIHRoaXMgY2hpbGRpc2gsIGJ1dCBJIGNv bnNpZGVyICZuYnNwO2JlYXJlciB0b2tlbnMgYSBkaXNhc3RlciB3YWl0aW5nIHRvIGhhcHBlbiBh bmQgd2lsbCBub3QgYWxsb3cgdGhlIHdlYWtlc3QgZm9ybSBvZiB0b2tlbiBhdXRoZW50aWNhdGlv biB0byBjYXJyeSB0aGUgc3Ryb25nZXN0DQogZm9ybSBvZiBlbmRvcnNlbWVudCBhbmQgcGVyY2Vw dGlvbiAodmlhIHRoZSBPQXV0aCBicmFuZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5BdCB0aGUgZW5kLCB5b3UgbWlnaHQgZ2V0IHRoZSBzY2hlbWUgbmFtZSB5b3Ugd2Fu dCwgYnV0IGl0IHdpbGwgY29zdCB5b3Ugc2lnbmlmaWNhbnQgZGVsYXlzIGluIGdldHRpbmcgdGhh dCBkb2N1bWVudCBwdWJsaXNoZWQgYXMgYW4gUkZDIGFuZCB3aXRoIGEgUHJvcG9zZWQgU3RhbmRh cmQgZGVzaWduYXRpb24uIFNvIGZhciB5b3UgaGF2ZSBmYWlsZWQgdG8gcmFpc2UNCiBhbnkgdGVj aG5pY2FsIGp1c3RpZmljYXRpb24gZm9yIHlvdXIgaW5zaXN0ZW5jZSBvZiB1c2luZyB0aGF0IG5h bWUuIFRoZSBvbmx5IHJlYXNvbiBzbyBmYXIgaXMgdGhhdCBpdCB3aWxsIGJlIGxlc3MgY29uZnVz aW5nLiBQZXJoYXBzLiBCdXQgd2lsbCBiZSBtb3JlIGRhbWFnaW5nLiBBZnRlciBhbGwsIHdoeSB3 b3VsZCBhbnlvbmUgbG9vayBhdCB0aGUgTUFDIHRva2VuIHNwZWNpZmljYXRpb24gb3Igb3RoZXIg c3Ryb25nZXIgYXV0aGVudGljYXRpb24NCiBzY2hlbWVzLCB3aGVuIHlvdSBvZmZlciB0aGVtIHRo ZSDigJxvZmZpY2lhbOKAnSBPQXV0aCAyLjAgc2NoZW1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SSBhbHNvIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgSSBhbSBub3QgdGhl IG9ubHkgb25lIGhlcmUgd2hvIG1hZGUgdGhpcyByZXF1ZXN0LiBJIGNvbnNlbnQgdGhhdCB0aGVy ZSBpc27igJl0IGNvbnNlbnN1cyB0byBjaGFuZ2luZyB0aGUgbmFtZSwgYnV0IHRoZXJlIGlzbuKA mXQgY29uc2Vuc3VzIHRvIGtlZXBpbmcgaXQgZWl0aGVyLiBUaGUg4oCcdm90ZeKAnSBpcyBhcm91 bmQNCiAyLTQgb24gZWFjaCBzaWRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SWYgeW91IGFyZSB3aWxsaW5nIHRvIHNwZW5kIHRoZSBuZXh0IGZldyBtb250aHMgYXJndWlu ZyBvdmVyIDYgY2hhcmFjdGVycyBpbiB5b3VyIGRvY3VtZW50LCBJIHdpbGwgZ2xhZGx5IG9ibGln ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkVITDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IE1pa2UgSm9uZXMgW21haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMjcsIDIwMTEgNToxNSBQTTxicj4NCjxi PlRvOjwvYj4gRXJhbiBIYW1tZXItTGFoYXY8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBVcGRhdGUgcmVxdWlyZWQgZm9yIGJlYXJlciB0b2tlbiBzcGVj PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDIwNjAiPk9uY2UgYXBwcm92ZWQsIHRoZSBleGlzdGluZyBuYW1lcyB3aWxs IGJlIHJlZ2lzdGVyZWQsIGhlbmNlIG5vIGNoYW5nZXMgYXJlIG5lZWRlZCB0byB0aGUgYmVhcmVy IHRva2VuIGRyYWZ0IHRvIGNvbXBseSB3aXRoIHRoZXNlIHJlcXVpcmVtZW50cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBFcmFu IEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMjcsIDIwMTEgMjozNiBQTTxicj4NCjxiPlRvOjwvYj4g TWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gT0F1dGggV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UkU6IFVwZGF0ZSByZXF1aXJlZCBmb3IgYmVhcmVyIHRva2VuIHNwZWM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+LTEyIHNlY3Rpb24gOC4xIGFuZCAxMC4xLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+RUhMPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pa2UgSm9uZXMgW21h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEphbnVhcnkgMjcsIDIwMTEgMjoxMCBQTTxicj4NCjxiPlRvOjwvYj4gRXJhbiBIYW1t ZXItTGFoYXY8YnI+DQo8Yj5DYzo8L2I+IE9BdXRoIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJF OiBVcGRhdGUgcmVxdWlyZWQgZm9yIGJlYXJlciB0b2tlbiBzcGVjPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDIwNjAi PllvdXIgcmVxdWVzdCBiZWxvdyBpcyBhbWJpZ3VvdXMuJm5ic3A7IFBsZWFzZSBwcm92aWRlIHRo ZSBwcmVjaXNlIG5ldyB0ZXh0IHlvdeKAmXJlIHJlcXVlc3RpbmcgYW5kIHRoZSByYXRpb25hbGUg Zm9yIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IEVyYW4gSGFtbWVyLUxhaGF2IFttYWlsdG86ZXJhbkBodWVuaXZlcnNlLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAyNywgMjAxMSAxOjQyIFBN PGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVzPGJyPg0KPGI+Q2M6PC9iPiBPQXV0aCBXRzxicj4N CjxiPlN1YmplY3Q6PC9iPiBVcGRhdGUgcmVxdWlyZWQgZm9yIGJlYXJlciB0b2tlbiBzcGVjPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIHVwZGF0 ZSB0aGUgZHJhZnQgdG8gY29tcGx5IHdpdGggLTEyIHJlZ2lzdHJhdGlvbiBndWlkZWxpbmVzIGFu ZCByZXF1aXJlbWVudHMgYXNhcC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RUhMPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQoNCg0KPC9kaXY+PC9ibG9ja3F1b3RlPjwv Ym9keT48L2h0bWw+ --_000_236CB9966D464590B308F4C045F23C84hueniversecom_-- From wmills@yahoo-inc.com Fri Jan 28 14:51:42 2011 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 567B13A68B7 for ; Fri, 28 Jan 2011 14:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.531 X-Spam-Level: X-Spam-Status: No, score=-17.531 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RDNS_DOTCOM_HELO=0.001, 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 ENjKINMZojMl for ; Fri, 28 Jan 2011 14:51:38 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by core3.amsl.com (Postfix) with ESMTP id 4E5CC3A67EC for ; Fri, 28 Jan 2011 14:51:38 -0800 (PST) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout3.yahoo.com (8.13.8/8.13.8/y.out) with ESMTP id p0SMsQEB051933; Fri, 28 Jan 2011 14:54:26 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Fri, 28 Jan 2011 14:54:26 -0800 From: William Mills To: Mike Jones , "oauth@ietf.org" Date: Fri, 28 Jan 2011 14:54:24 -0800 Thread-Topic: OAuth 2.0 Bearer Token Specification draft -02 Thread-Index: Acu/M2Nlc5Ah9YfFTfu+PALXm4nBEQACbVYA Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943246FD307@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246FD307@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A31563848E7D3F7SP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 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, 28 Jan 2011 22:51:42 -0000 --_000_FFDFD7371D517847AD71FBB08F9A31563848E7D3F7SP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to add my objection to using "OAuth2" as the scheme name for the a= ccess token. It's confusing in my opinion. I would much prefer (in my own= order of preference): " oauth_bearer", "oauth2_bearer", or "bearer". I th= ink including OAuth in the name makes sense because it is defined in that c= ontext, but we've already talked about other possible token types. Is there any argument in favor of simply using "OAuth2" that offsets the po= ssible confusion and muddiness? -bill From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, January 28, 2011 1:36 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 I've published draft 02 of the bearer token specification. This incorporat= es consensus feedback received to date. It contains no normative changes r= elative to draft 01. Your feedback is solicited. Specific changes were: * Changed terminology from "token reuse" to "token capture and repl= ay". * Removed sentence "Encrypting the token contents is another altern= ative" from the security considerations since it was redundant and potentia= lly confusing. * Corrected some references to "resource server" to be "authorizati= on server" in the security considerations. * Generalized security considerations language about obtaining cons= ent of the resource owner. * Broadened scope of security considerations description for recomm= endation "Don't pass bearer tokens in page URLs". * Removed unused reference to OAuth 1.0. * Updated reference to framework specification and updated David Re= cordon's e-mail address. * Removed security considerations text on authenticating clients. * Registered the "OAuth2" OAuth access token type and "oauth_token"= parameter. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02= .txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02= .xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion= repository, with html, txt, and html versions available) This version is explicitly not ready for working group last call, as change= s may need to be made due to the open issues in the framework spec about th= e removal of the Client Assertion Credentials and OAuth2 HTTP Authenticatio= n Scheme. -- Mike --_000_FFDFD7371D517847AD71FBB08F9A31563848E7D3F7SP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d like to add my= objection to using “OAuth2” as the scheme name for the access token. = ; It’s confusing in my opinion.  I would much prefer (in my own order of preference): “ oauth_bearer”, “oauth2_bearer”, or &= #8220;bearer”.  I think including OAuth in the name makes sense because it is defined in th= at context, but we’ve already talked about other possible token types.&n= bsp;

 =

Is there any argument in= favor of simply using “OAuth2” that offsets the possible confusion an= d muddiness?

 =

-bill<= /p>

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Friday, January 28, 2011 1:36 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02

 

I’ve published draft 02 of the bearer token specification.  This incorporates consensus feedback received to date.  It contains no normative changes relative to draft 01.  Yo= ur feedback is solicited.  Specific changes were:

·      =    Changed terminology from "token reuse&q= uot; to "token capture and replay".

·      =    Removed sentence "Encrypting the token contents is another alternative" from the security considerations sinc= e it was redundant and potentially confusing.

·      =    Corrected some references to "resource server" to be "authorization server" in the security considerations.

·      =    Generalized security considerations language about obtaining consent of the resource owner.

·      =    Broadened scope of security considerations description for recommendation "Don't pass bearer tokens in page URLs".

·      =    Removed unused reference to OAuth 1.0. =

·      =    Updated reference to framework specification= and updated David Recordon's e-mail address.

·      =    Removed security considerations text on authenticating clients.

·      =    Registered the "OAuth2" OAuth acce= ss token type and "oauth_token" parameter.

 

The draft is available at these locations:<= /p>

·      =    http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.txt

·      =    http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.xml

·      =    ht= tp://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html

·      =    htt= p://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt<= /p>

·      =    htt= p://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml<= /p>

·      =    http://svn.o= penid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available)

 

This version is explicitly not ready for working group= last call, as changes may need to be made due to the open issues in the framewor= k spec about the removal of the Client Assertion Credentials and OAuth2 HTTP Authentication Scheme.

 

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

 

--_000_FFDFD7371D517847AD71FBB08F9A31563848E7D3F7SP2EX07VS06ds_-- From Michael.Jones@microsoft.com Fri Jan 28 15:05:23 2011 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 3C71B3A6997 for ; Fri, 28 Jan 2011 15:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.59 X-Spam-Level: X-Spam-Status: No, score=-10.59 tagged_above=-999 required=5 tests=[AWL=0.008, 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 1TGiz6ooNcDO for ; Fri, 28 Jan 2011 15:05:15 -0800 (PST) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id B7EA33A698D for ; Fri, 28 Jan 2011 15:05:14 -0800 (PST) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 15:08:21 -0800 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.150]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.01.0270.002; Fri, 28 Jan 2011 15:08:21 -0800 From: Mike Jones To: William Mills , "oauth@ietf.org" Thread-Topic: OAuth 2.0 Bearer Token Specification draft -02 Thread-Index: Acu/M2Nlc5Ah9YfFTfu+PALXm4nBEQACbVYAAACL1wA= Date: Fri, 28 Jan 2011 23:08:21 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943246FD522@TK5EX14MBXC202.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943246FD307@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943246FD522TK5EX14MBXC202r_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 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, 28 Jan 2011 23:05:23 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943246FD522TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The argument in favor of "OAuth2" is a consistency argument. Just as this = parameter was called "WRAP" in the WRAP spec and called "OAuth" in the OAut= h specs through draft 10 until it was moved to the OAuth2 bearer token spec= , it should logically be called "OAuth2" to remain consistent with the prec= ursor specifications. Also, since the use of bearer tokens is the primary = OAuth2 use case (it was the motivating use case for WRAP, which was the rea= son for a second version of OAuth in the first place), it makes sense for t= his primary use case bear the primary specification name. I'm not religious about this (I already asked for working group on this top= ic a while ago and received very little), but absent a clear working group = consensus to change the name, as editor, I believe that it's my job to not = introduce breaking changes at this point in the specification development c= ycle. Cheers, -- Mike From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Friday, January 28, 2011 2:54 PM To: Mike Jones; oauth@ietf.org Subject: RE: OAuth 2.0 Bearer Token Specification draft -02 I'd like to add my objection to using "OAuth2" as the scheme name for the a= ccess token. It's confusing in my opinion. I would much prefer (in my own= order of preference): " oauth_bearer", "oauth2_bearer", or "bearer". I th= ink including OAuth in the name makes sense because it is defined in that c= ontext, but we've already talked about other possible token types. Is there any argument in favor of simply using "OAuth2" that offsets the po= ssible confusion and muddiness? -bill From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, January 28, 2011 1:36 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 I've published draft 02 of the bearer token specification. This incorporat= es consensus feedback received to date. It contains no normative changes r= elative to draft 01. Your feedback is solicited. Specific changes were: * Changed terminology from "token reuse" to "token capture and repl= ay". * Removed sentence "Encrypting the token contents is another altern= ative" from the security considerations since it was redundant and potentia= lly confusing. * Corrected some references to "resource server" to be "authorizati= on server" in the security considerations. * Generalized security considerations language about obtaining cons= ent of the resource owner. * Broadened scope of security considerations description for recomm= endation "Don't pass bearer tokens in page URLs". * Removed unused reference to OAuth 1.0. * Updated reference to framework specification and updated David Re= cordon's e-mail address. * Removed security considerations text on authenticating clients. * Registered the "OAuth2" OAuth access token type and "oauth_token"= parameter. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02= .txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02= .xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion= repository, with html, txt, and html versions available) This version is explicitly not ready for working group last call, as change= s may need to be made due to the open issues in the framework spec about th= e removal of the Client Assertion Credentials and OAuth2 HTTP Authenticatio= n Scheme. -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943246FD522TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The argument in favor = of “OAuth2” is a consistency argument.  Just as this param= eter was called “WRAP” in the WRAP spec and called “OAuth= ” in the OAuth specs through draft 10 until it was moved to the OAuth= 2 bearer token spec, it should logically be called “OAuth2” to r= emain consistent with the precursor specifications.  Also, since the u= se of bearer tokens is the primary OAuth2 use case (it was the motivating u= se case for WRAP, which was the reason for a second version of OAuth in the first place), it makes sense for this primary use = case bear the primary specification name.

 

I’m not religiou= s about this (I already asked for working group on this topic a while ago a= nd received very little), but absent a clear working group consensus to cha= nge the name, as editor, I believe that it’s my job to not introduce breaking changes at this point in the specificatio= n development cycle.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Cheers,=

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

From: William = Mills [mailto:wmills@yahoo-inc.com]
Sent: Friday, January 28, 2011 2:54 PM
To: Mike Jones; oauth@ietf.org
Subject: RE: OAuth 2.0 Bearer Token Specification draft -02

 

I’d like to add = my objection to using “OAuth2” as the scheme name for the acces= s token.  It’s confusing in my opinion.  I would much prefe= r (in my own order of preference): “ oauth_bearer”, “oaut= h2_bearer”, or “bearer”.  I think including OAuth in the name makes sens= e because it is defined in that context, but we’ve already talked abo= ut other possible token types. 

 

Is there any argument = in favor of simply using “OAuth2” that offsets the possible con= fusion and muddiness?

 

-bill

 

From: oauth-bo= unces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Mike Jones
Sent: Friday, January 28, 2011 1:36 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02

 

I’ve published draft 02 of the bearer token sp= ecification.  This incorporates consensus feedback received to date.&n= bsp; It contains no normative changes relative to draft 01.  Your feed= back is solicited.  Specific changes were:

·         Changed terminology from "token reuse&q= uot; to "token capture and replay".

·         Removed sentence "Encrypting the token = contents is another alternative" from the security considerations sinc= e it was redundant and potentially confusing.

·         Corrected some references to "resource = server" to be "authorization server" in the security conside= rations.

·         Generalized security considerations language= about obtaining consent of the resource owner.

·         Broadened scope of security considerations d= escription for recommendation "Don't pass bearer tokens in page URLs&q= uot;.

·         Removed unused reference to OAuth 1.0. =

·         Updated reference to framework specification= and updated David Recordon's e-mail address.

·         Removed security considerations text on auth= enticating clients.

·         Registered the "OAuth2" OAuth acce= ss token type and "oauth_token" parameter.

 

The draft is available at these locations:

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-02.txt

·         http://www.ietf.org/internet-drafts/d= raft-ietf-oauth-v2-bearer-02.xml

·         http://self-issued.info/docs/draft-ietf-oau= th-v2-bearer-02.html

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-02.txt

·         http://self-issued.info/docs/draft-ietf-oaut= h-v2-bearer-02.xml

·         http://svn.openid.net/repos/specifications/oauth/2.0/= (Subversion repository, with html, txt, and html versions available)

 

This version is explicitly not ready for working gro= up last call, as changes may need to be made due to the open issues in the = framework spec about the removal of the Client Assertion Credentials and OA= uth2 HTTP Authentication Scheme.

 

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

 

--_000_4E1F6AAD24975D4BA5B1680429673943246FD522TK5EX14MBXC202r_-- From eran@hueniverse.com Fri Jan 28 15:07:56 2011 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 D5A1B3A698D for ; Fri, 28 Jan 2011 15:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.023, 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 ApPoPL1GJsHP for ; Fri, 28 Jan 2011 15:07:55 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 858F43A67EC for ; Fri, 28 Jan 2011 15:07:55 -0800 (PST) Received: (qmail 30491 invoked from network); 28 Jan 2011 23:10:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 28 Jan 2011 23:10:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 28 Jan 2011 16:10:25 -0700 From: Eran Hammer-Lahav To: Mike Jones Date: Fri, 28 Jan 2011 16:10:17 -0700 Thread-Topic: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 Thread-Index: Acu/QIwAoRD/k5VqSYqOHwkldhF5hA== Message-ID: <2BBBDBF1-8969-4C78-8C6B-7EB88A27CDA4@hueniverse.com> References: <4E1F6AAD24975D4BA5B1680429673943246FD307@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246FD307@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2BBBDBF189694C788C6B7EB88A27CDA4hueniversecom_" MIME-Version: 1.0 Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 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, 28 Jan 2011 23:07:56 -0000 --_000_2BBBDBF189694C788C6B7EB88A27CDA4hueniversecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVtb3ZlIHRoZSBvYXV0aF90b2tlbiBwYXJhbWV0ZXIgcmVnaXN0cmF0aW9uLiBJdCBoYXMgbm90 aGluZyB0byBkbyB3aXRoIHRoZSB0b2tlbiBlbmRwb2ludC4NCg0KRUhMDQoNCk9uIEphbiAyOCwg MjAxMSwgYXQgMTM6MzYsICJNaWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29t PG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KSeKAmXZlIHB1 Ymxpc2hlZCBkcmFmdCAwMiBvZiB0aGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24uICBUaGlz IGluY29ycG9yYXRlcyBjb25zZW5zdXMgZmVlZGJhY2sgcmVjZWl2ZWQgdG8gZGF0ZS4gIEl0IGNv bnRhaW5zIG5vIG5vcm1hdGl2ZSBjaGFuZ2VzIHJlbGF0aXZlIHRvIGRyYWZ0IDAxLiAgWW91ciBm ZWVkYmFjayBpcyBzb2xpY2l0ZWQuICBTcGVjaWZpYyBjaGFuZ2VzIHdlcmU6DQoNCsK3ICAgICAg ICAgQ2hhbmdlZCB0ZXJtaW5vbG9neSBmcm9tICJ0b2tlbiByZXVzZSIgdG8gInRva2VuIGNhcHR1 cmUgYW5kIHJlcGxheSIuDQoNCsK3ICAgICAgICAgUmVtb3ZlZCBzZW50ZW5jZSAiRW5jcnlwdGlu ZyB0aGUgdG9rZW4gY29udGVudHMgaXMgYW5vdGhlciBhbHRlcm5hdGl2ZSIgZnJvbSB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMgc2luY2UgaXQgd2FzIHJlZHVuZGFudCBhbmQgcG90ZW50aWFs bHkgY29uZnVzaW5nLg0KDQrCtyAgICAgICAgIENvcnJlY3RlZCBzb21lIHJlZmVyZW5jZXMgdG8g InJlc291cmNlIHNlcnZlciIgdG8gYmUgImF1dGhvcml6YXRpb24gc2VydmVyIiBpbiB0aGUgc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMuDQoNCsK3ICAgICAgICAgR2VuZXJhbGl6ZWQgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgbGFuZ3VhZ2UgYWJvdXQgb2J0YWluaW5nIGNvbnNlbnQgb2YgdGhlIHJl c291cmNlIG93bmVyLg0KDQrCtyAgICAgICAgIEJyb2FkZW5lZCBzY29wZSBvZiBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBkZXNjcmlwdGlvbiBmb3IgcmVjb21tZW5kYXRpb24gIkRvbid0IHBhc3Mg YmVhcmVyIHRva2VucyBpbiBwYWdlIFVSTHMiLg0KDQrCtyAgICAgICAgIFJlbW92ZWQgdW51c2Vk IHJlZmVyZW5jZSB0byBPQXV0aCAxLjAuDQoNCsK3ICAgICAgICAgVXBkYXRlZCByZWZlcmVuY2Ug dG8gZnJhbWV3b3JrIHNwZWNpZmljYXRpb24gYW5kIHVwZGF0ZWQgRGF2aWQgUmVjb3Jkb24ncyBl LW1haWwgYWRkcmVzcy4NCg0KwrcgICAgICAgICBSZW1vdmVkIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zIHRleHQgb24gYXV0aGVudGljYXRpbmcgY2xpZW50cy4NCg0KwrcgICAgICAgICBSZWdpc3Rl cmVkIHRoZSAiT0F1dGgyIiBPQXV0aCBhY2Nlc3MgdG9rZW4gdHlwZSBhbmQgIm9hdXRoX3Rva2Vu IiBwYXJhbWV0ZXIuDQoNClRoZSBkcmFmdCBpcyBhdmFpbGFibGUgYXQgdGhlc2UgbG9jYXRpb25z Og0KDQrCtyAgICAgICAgIDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMi50eHQ+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTAyLnR4dA0KDQrCtyAgICAgICAg IDxodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYy LWJlYXJlci0wMi54bWw+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWlldGYtb2F1dGgtdjItYmVhcmVyLTAyLnhtbA0KDQrCtyAgICAgICAgIDxodHRwOi8vc2VsZi1p c3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTAyLmh0bWw+IGh0dHA6 Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMDIuaHRt bA0KDQrCtyAgICAgICAgIDxodHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYt b2F1dGgtdjItYmVhcmVyLTAyLnR4dD4gaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFm dC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMi50eHQNCg0KwrcgICAgICAgICA8aHR0cDovL3NlbGYt aXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMi54bWw+IGh0dHA6 Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMDIueG1s DQoNCsK3ICAgICAgICAgPGh0dHA6Ly9zdm4ub3BlbmlkLm5ldC9yZXBvcy9zcGVjaWZpY2F0aW9u cy9vYXV0aC8yLjAvPiBodHRwOi8vc3ZuLm9wZW5pZC5uZXQvcmVwb3Mvc3BlY2lmaWNhdGlvbnMv b2F1dGgvMi4wLyAoU3VidmVyc2lvbiByZXBvc2l0b3J5LCB3aXRoIGh0bWwsIHR4dCwgYW5kIGh0 bWwgdmVyc2lvbnMgYXZhaWxhYmxlKQ0KDQpUaGlzIHZlcnNpb24gaXMgZXhwbGljaXRseSBub3Qg cmVhZHkgZm9yIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsLCBhcyBjaGFuZ2VzIG1heSBuZWVkIHRv IGJlIG1hZGUgZHVlIHRvIHRoZSBvcGVuIGlzc3VlcyBpbiB0aGUgZnJhbWV3b3JrIHNwZWMgYWJv dXQgdGhlIHJlbW92YWwgb2YgdGhlIENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMgYW5kIE9B dXRoMiBIVFRQIEF1dGhlbnRpY2F0aW9uIFNjaGVtZS4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K --_000_2BBBDBF189694C788C6B7EB88A27CDA4hueniversecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj5SZW1vdmUgdGhlIG9hdXRoX3Rva2Vu IHBhcmFtZXRlciByZWdpc3RyYXRpb24uIEl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggdGhlIHRv a2VuIGVuZHBvaW50LiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+RUhMPGJyPjxicj5P biBKYW4gMjgsIDIwMTEsIGF0IDEzOjM2LCAiTWlrZSBKb25lcyIgJmx0OzxhIGhyZWY9Im1haWx0 bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj48YnI+PC9kaXY+PGRpdj48L2Rpdj48YmxvY2txdW90ZSB0eXBl PSJjaXRlIj48ZGl2Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPknigJl2ZSBwdWJsaXNoZWQgZHJhZnQgMDIgb2YgdGhlIGJlYXJlciB0b2tlbiBzcGVj aWZpY2F0aW9uLiZuYnNwOyBUaGlzIGluY29ycG9yYXRlcyBjb25zZW5zdXMgZmVlZGJhY2sgcmVj ZWl2ZWQgdG8gZGF0ZS4mbmJzcDsgSXQgY29udGFpbnMgbm8gbm9ybWF0aXZlIGNoYW5nZXMgcmVs YXRpdmUgdG8gZHJhZnQgMDEuJm5ic3A7IFlvdXIgZmVlZGJhY2sgaXMgc29saWNpdGVkLiZuYnNw OyBTcGVjaWZpYyBjaGFuZ2VzIHdlcmU6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVs MSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj5DaGFuZ2VkIHRlcm1pbm9sb2d5IGZyb20gInRva2Vu IHJldXNlIiB0byAidG9rZW4gY2FwdHVyZSBhbmQgcmVwbGF5Ii4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPlJlbW92ZWQgc2VudGVuY2Ug IkVuY3J5cHRpbmcgdGhlIHRva2VuIGNvbnRlbnRzIGlzIGFub3RoZXIgYWx0ZXJuYXRpdmUiIGZy b20gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNpbmNlIGl0IHdhcyByZWR1bmRhbnQgYW5k IHBvdGVudGlhbGx5IGNvbmZ1c2luZy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPkNvcnJlY3RlZCBzb21lIHJlZmVyZW5jZXMgdG8gInJl c291cmNlIHNlcnZlciIgdG8gYmUgImF1dGhvcml6YXRpb24gc2VydmVyIiBpbiB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8x Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj5HZW5lcmFsaXplZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBs YW5ndWFnZSBhYm91dCBvYnRhaW5pbmcgY29uc2VudCBvZiB0aGUgcmVzb3VyY2Ugb3duZXIuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj5C cm9hZGVuZWQgc2NvcGUgb2Ygc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGVzY3JpcHRpb24gZm9y IHJlY29tbWVuZGF0aW9uICJEb24ndCBwYXNzIGJlYXJlciB0b2tlbnMgaW4gcGFnZSBVUkxzIi4N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PlJlbW92ZWQgdW51c2VkIHJlZmVyZW5jZSB0byBPQXV0aCAxLjAuIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPlVwZGF0ZWQgcmVmZXJlbmNl IHRvIGZyYW1ld29yayBzcGVjaWZpY2F0aW9uIGFuZCB1cGRhdGVkIERhdmlkIFJlY29yZG9uJ3Mg ZS1tYWlsIGFkZHJlc3MuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj5SZW1vdmVkIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHRleHQgb24g YXV0aGVudGljYXRpbmcgY2xpZW50cy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPlJlZ2lzdGVyZWQgdGhlICJPQXV0aDIiIE9BdXRoIGFj Y2VzcyB0b2tlbiB0eXBlIGFuZCAib2F1dGhfdG9rZW4iIHBhcmFtZXRlci48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIGRyYWZ0IGlzIGF2YWlsYWJsZSBhdCB0aGVzZSBsb2NhdGlvbnM6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5k ZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PGEg aHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1vYXV0 aC12Mi1iZWFyZXItMDIudHh0Ij48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMi50eHQiPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTAyLnR4dDwv YT48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1vYXV0aC12Mi1iZWFyZXItMDIueG1sIj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMi54bWwiPmh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVy LTAyLnhtbDwvYT48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFm dC1pZXRmLW9hdXRoLXYyLWJlYXJlci0wMi5odG1sIj48YSBocmVmPSJodHRwOi8vc2VsZi1pc3N1 ZWQuaW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTAyLmh0bWwiPmh0dHA6Ly9z ZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMDIuaHRtbDwv YT48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PGEgaHJlZj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLW9h dXRoLXYyLWJlYXJlci0wMi50eHQiPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2Rv Y3MvZHJhZnQtaWV0Zi1vYXV0aC12Mi1iZWFyZXItMDIudHh0Ij5odHRwOi8vc2VsZi1pc3N1ZWQu aW5mby9kb2NzL2RyYWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTAyLnR4dDwvYT48L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PGEgaHJl Zj0iaHR0cDovL3NlbGYtaXNzdWVkLmluZm8vZG9jcy9kcmFmdC1pZXRmLW9hdXRoLXYyLWJlYXJl ci0wMi54bWwiPjxhIGhyZWY9Imh0dHA6Ly9zZWxmLWlzc3VlZC5pbmZvL2RvY3MvZHJhZnQtaWV0 Zi1vYXV0aC12Mi1iZWFyZXItMDIueG1sIj5odHRwOi8vc2VsZi1pc3N1ZWQuaW5mby9kb2NzL2Ry YWZ0LWlldGYtb2F1dGgtdjItYmVhcmVyLTAyLnhtbDwvYT48L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PGEgaHJlZj0iaHR0cDovL3N2 bi5vcGVuaWQubmV0L3JlcG9zL3NwZWNpZmljYXRpb25zL29hdXRoLzIuMC8iPjxhIGhyZWY9Imh0 dHA6Ly9zdm4ub3BlbmlkLm5ldC9yZXBvcy9zcGVjaWZpY2F0aW9ucy9vYXV0aC8yLjAvIj5odHRw Oi8vc3ZuLm9wZW5pZC5uZXQvcmVwb3Mvc3BlY2lmaWNhdGlvbnMvb2F1dGgvMi4wLzwvYT48L2E+ IChTdWJ2ZXJzaW9uIHJlcG9zaXRvcnksIHdpdGggaHRtbCwgdHh0LCBhbmQgaHRtbCB2ZXJzaW9u cyBhdmFpbGFibGUpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgdmVyc2lvbiBpcyBleHBs aWNpdGx5IG5vdCByZWFkeSBmb3Igd29ya2luZyBncm91cCBsYXN0IGNhbGwsIGFzIGNoYW5nZXMg bWF5IG5lZWQgdG8gYmUgbWFkZSBkdWUgdG8gdGhlIG9wZW4gaXNzdWVzIGluIHRoZSBmcmFtZXdv cmsgc3BlYyBhYm91dCB0aGUgcmVtb3ZhbCBvZiB0aGUgQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50 aWFscyBhbmQgT0F1dGgyIEhUVFAgQXV0aGVudGljYXRpb24gU2NoZW1lLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCg0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ PGRpdj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzwvc3Bhbj48YnI+PHNwYW4+T0F1dGggbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBo cmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+ PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0 aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L3NwYW4+ PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg== --_000_2BBBDBF189694C788C6B7EB88A27CDA4hueniversecom_-- From wmills@yahoo-inc.com Fri Jan 28 15:56:56 2011 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 BF92C3A699E for ; Fri, 28 Jan 2011 15:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.534 X-Spam-Level: X-Spam-Status: No, score=-17.534 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RDNS_DOTCOM_HELO=0.001, 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 QVC3I2xsKmED for ; Fri, 28 Jan 2011 15:56:50 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 2DA013A696B for ; Fri, 28 Jan 2011 15:56:50 -0800 (PST) Received: from SP2-EX07CAS03.ds.corp.yahoo.com (sp2-ex07cas03.corp.sp2.yahoo.com [98.137.59.35]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p0SNxkGC065942; Fri, 28 Jan 2011 15:59:46 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS03.ds.corp.yahoo.com ([98.137.59.35]) with mapi; Fri, 28 Jan 2011 15:59:46 -0800 From: William Mills To: Mike Jones , "oauth@ietf.org" Date: Fri, 28 Jan 2011 15:59:45 -0800 Thread-Topic: OAuth 2.0 Bearer Token Specification draft -02 Thread-Index: Acu/M2Nlc5Ah9YfFTfu+PALXm4nBEQACbVYAAACL1wAAAUCxsA== Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943246FD307@TK5EX14MBXC202.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943246FD522@TK5EX14MBXC202.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943246FD522@TK5EX14MBXC202.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FFDFD7371D517847AD71FBB08F9A31563848E7D422SP2EX07VS06ds_" MIME-Version: 1.0 Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 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, 28 Jan 2011 23:56:56 -0000 --_000_FFDFD7371D517847AD71FBB08F9A31563848E7D422SP2EX07VS06ds_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable At that point though we did not have multiple token types. Now that we do = we should make the naming scheme reflect that. OAuth2 implies "the one and= only". From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, January 28, 2011 3:08 PM To: William Mills; oauth@ietf.org Subject: RE: OAuth 2.0 Bearer Token Specification draft -02 The argument in favor of "OAuth2" is a consistency argument. Just as this = parameter was called "WRAP" in the WRAP spec and called "OAuth" in the OAut= h specs through draft 10 until it was moved to the OAuth2 bearer token spec= , it should logically be called "OAuth2" to remain consistent with the prec= ursor specifications. Also, since the use of bearer tokens is the primary = OAuth2 use case (it was the motivating use case for WRAP, which was the rea= son for a second version of OAuth in the first place), it makes sense for t= his primary use case bear the primary specification name. I'm not religious about this (I already asked for working group on this top= ic a while ago and received very little), but absent a clear working group = consensus to change the name, as editor, I believe that it's my job to not = introduce breaking changes at this point in the specification development c= ycle. Cheers, -- Mike From: William Mills [mailto:wmills@yahoo-inc.com] Sent: Friday, January 28, 2011 2:54 PM To: Mike Jones; oauth@ietf.org Subject: RE: OAuth 2.0 Bearer Token Specification draft -02 I'd like to add my objection to using "OAuth2" as the scheme name for the a= ccess token. It's confusing in my opinion. I would much prefer (in my own= order of preference): " oauth_bearer", "oauth2_bearer", or "bearer". I th= ink including OAuth in the name makes sense because it is defined in that c= ontext, but we've already talked about other possible token types. Is there any argument in favor of simply using "OAuth2" that offsets the po= ssible confusion and muddiness? -bill From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of M= ike Jones Sent: Friday, January 28, 2011 1:36 PM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 I've published draft 02 of the bearer token specification. This incorporat= es consensus feedback received to date. It contains no normative changes r= elative to draft 01. Your feedback is solicited. Specific changes were: * Changed terminology from "token reuse" to "token capture and repl= ay". * Removed sentence "Encrypting the token contents is another altern= ative" from the security considerations since it was redundant and potentia= lly confusing. * Corrected some references to "resource server" to be "authorizati= on server" in the security considerations. * Generalized security considerations language about obtaining cons= ent of the resource owner. * Broadened scope of security considerations description for recomm= endation "Don't pass bearer tokens in page URLs". * Removed unused reference to OAuth 1.0. * Updated reference to framework specification and updated David Re= cordon's e-mail address. * Removed security considerations text on authenticating clients. * Registered the "OAuth2" OAuth access token type and "oauth_token"= parameter. The draft is available at these locations: * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02= .txt * http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02= .xml * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt * http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml * http://svn.openid.net/repos/specifications/oauth/2.0/ (Subversion= repository, with html, txt, and html versions available) This version is explicitly not ready for working group last call, as change= s may need to be made due to the open issues in the framework spec about th= e removal of the Client Assertion Credentials and OAuth2 HTTP Authenticatio= n Scheme. -- Mike --_000_FFDFD7371D517847AD71FBB08F9A31563848E7D422SP2EX07VS06ds_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

At that point though we = did not have multiple token types.  Now that we do we should make the naming s= cheme reflect that.  OAuth2 implies “the one and only”.

 =

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, January 28, 2011 3:08 PM
To: William Mills; oauth@ietf.org
Subject: RE: OAuth 2.0 Bearer Token Specification draft -02

 

The argument in favor of “OAuth2” is a consistency argument.  Just as this paramete= r was called “WRAP” in the WRAP spec and called “OAuth̶= 1; in the OAuth specs through draft 10 until it was moved to the OAuth2 bearer token spec, it should logically be called “OAuth2” to remain consistent with the precursor specifications.  Also, since the use of bearer tokens is the primary OAuth2 use case (it was the motivating use cas= e for WRAP, which was the reason for a second version of OAuth in the first place), it makes sense for this primary use case bear the primary specifica= tion name.

 =

I’m not religious = about this (I already asked for working group on this topic a while ago and recei= ved very little), but absent a clear working group consensus to change the name= , as editor, I believe that it’s my job to not introduce breaking changes = at this point in the specification development cycle.

 =

    =             &nb= sp;            =             &nb= sp;            =           Cheers,

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

 =

From: William Mills [mailto:wmills@yahoo-inc.com]
Sent: Friday, January 28, 2011 2:54 PM
To: Mike Jones; oauth@ietf.org
Subject: RE: OAuth 2.0 Bearer Token Specification draft -02

 

I’d like to add my objection to using “OAuth2” as the scheme name for the access token.  It’s confusing in my opinion.  I would much prefer = (in my own order of preference): “ oauth_bearer”, “oauth2_bearer”, or “bearer”.  I think includi= ng OAuth in the name makes sense because it is defined in that context, but we’ve already talked about other possible token types. 

 =

Is there any argument in= favor of simply using “OAuth2” that offsets the possible confusion an= d muddiness?

 =

-bill<= /p>

 =

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of = Mike Jones
Sent: Friday, January 28, 2011 1:36 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02

 

I’ve published draft 02 of the bearer token specification.  This incorporates consensus feedback received to date.  It contains no normative changes relative to draft 01.  Yo= ur feedback is solicited.  Specific changes were:

·      =    Changed terminology from "token reuse&q= uot; to "token capture and replay".

·      =    Removed sentence "Encrypting the token contents is another alternative" from the security considerations sinc= e it was redundant and potentially confusing.

·      =    Corrected some references to "resource server" to be "authorization server" in the security considerations.

·      =    Generalized security considerations language about obtaining consent of the resource owner.

·      =    Broadened scope of security considerations description for recommendation "Don't pass bearer tokens in page URLs".

·      =    Removed unused reference to OAuth 1.0. =

·      =    Updated reference to framework specification= and updated David Recordon's e-mail address.

·      =    Removed security considerations text on authenticating clients.

·      =    Registered the "OAuth2" OAuth acce= ss token type and "oauth_token" parameter.

 

The draft is available at these locations:<= /p>

·      =    http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.txt

·      =    http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.xml

·      =    ht= tp://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html

·      =    htt= p://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt<= /p>

·      =    htt= p://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml<= /p>

·      =    http://svn.o= penid.net/repos/specifications/oauth/2.0/ (Subversion repository, with html, txt, and html versions available)

 

This version is explicitly not ready for working group= last call, as changes may need to be made due to the open issues in the framewor= k spec about the removal of the Client Assertion Credentials and OAuth2 HTTP Authentication Scheme.

 

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

 

--_000_FFDFD7371D517847AD71FBB08F9A31563848E7D422SP2EX07VS06ds_-- From tonynad@microsoft.com Fri Jan 28 15:59:40 2011 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 C5CB73A69A5 for ; Fri, 28 Jan 2011 15:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.198 X-Spam-Level: X-Spam-Status: No, score=-10.198 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_RMML_Stock25=0.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 78FoVh1bXh6z for ; Fri, 28 Jan 2011 15:59:38 -0800 (PST) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id C2BE83A699E for ; Fri, 28 Jan 2011 15:59:37 -0800 (PST) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 28 Jan 2011 16:02:43 -0800 Received: from TK5EX14MBXC111.redmond.corp.microsoft.com ([169.254.2.185]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0270.002; Fri, 28 Jan 2011 16:02:43 -0800 From: Anthony Nadalin To: Phil Hunt Thread-Topic: [OAUTH-WG] Removal: Client Assertion Credentials Thread-Index: Acu0fgHuLdKyp0U3QAWHNiVhYlv/ZQIaL9MwAAPpZeAAKfLFMAACwaqwADAncQAAQF3nAAAJJKng Date: Sat, 29 Jan 2011 00:02:43 +0000 Message-ID: <180155C5EA10854997314CA5E063D18F033B2B0E@TK5EX14MBXC111.redmond.corp.microsoft.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6250D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033B0798@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62753@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033B181B@TK5EX14MBXC111.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_180155C5EA10854997314CA5E063D18F033B2B0ETK5EX14MBXC111r_" MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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, 28 Jan 2011 23:59:40 -0000 --_000_180155C5EA10854997314CA5E063D18F033B2B0ETK5EX14MBXC111r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29kZSBpbXBhY3Qgd2FzIHRoYXQgYXNzZXJ0aW9uX3R5cGUgd2FzIG1vdmVkL2NoYW5nZWQgdG8g Z3JhbnRfdHlwZSwgd2UgYWN0dWFsbHkgbmVlZCBjbGllbnRfYXNzZXJ0aW9uIGFuZCBjbGllbnRf YXNzZXJ0aW9uX3R5cGUgYW5kIG5vdCBoYXZlIHRvIG92ZXJsb2FkIHRoZSBncmFudF90eXBlIGFz IGFzc2VydGlvbl90eXBlLCBJIGNhbiB3aHkgdGhpcyB3YXMgZG9uZSBmb3IgYWxsb3dpbmcgb25l IHRvIHVzZSBhc3NlcnRpb25zIGluIGdlbmVyYWwgZm9yIGF1dGhlbnRjYXRpb25zDQoNCkZyb206 IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KU2VudDogRnJpZGF5LCBK YW51YXJ5IDI4LCAyMDExIDEyOjE3IFBNDQpUbzogQW50aG9ueSBOYWRhbGluDQpDYzogRXJhbiBI YW1tZXItTGFoYXY7IE9BdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBSZW1vdmFsOiBD bGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoNClRvbnksDQoNCkknbSBub3QgdG90YWxseSB1 bmRlcnN0YW5kaW5nIHdoYXQgdGhlIGlzc3VlIGlzIGFzIGZhciBhcyBpbXBhY3Qgb24gY29kZS4g TXkgdW5kZXJzdGFuZGluZyB3YXMgdGhhdCB0aGUgcmVtb3ZhbCBzaW1wbHkgdG9vayBpdCBvdXQg b2YgdGhlIHN0YW5kYXJkIGJ1dCBpcyBzdGlsbCBjb3ZlcmVkIGJ5ICJvdGhlciBhdXRoZW50aWNh dGlvbiBtZWNoYW5pc20iLiAgVGh1cyBubyBpbXBhY3Qgb24gY29kZSAtLSB5b3UgY2FuIHN0aWxs IHVzZSAoYXMgd2Ugd2lsbCkgdGhlIGNsaWVudF9hc3NlcnRpb24gZm9ybSBwYXJhbWV0ZXIuIFRo YXQgc2FpZCwgSSB2ZXJ5IG11Y2ggYWdyZWUgd2l0aCB5b3VyIGNvbmNlcm5zLg0KDQpJdCBtYXkg YmUgd29ydGh3aGlsZSBmb3IgdXMgdG8gd29yayBvbiBhIHByb2ZpbGUgdGhhdCBsYXlzIG91dCB0 aGUgc3BlY2lmaWNzIG9mIHVzaW5nIGNsaWVudF9hc3NlcnRpb24gb3IgY2xpZW50X3Rva2VuIGlu IGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbi4gSnVzdCBhcyB0aGVyZSB3aWxsIGJlIG11bHRpcGxl IGFjY2VzcyB0b2tlbiBmb3JtYXRzLCBJIGV4cGVjdCB0byBzZWUgbXVsdGlwbGUgY2xpZW50IGF1 dGhlbnRpY2F0aW9uIG1ldGhvZHMuICBNYXliZSBjbGllbnQgYXV0aCBtZXRob2RzIHNob3VsZCBh bHNvIGJlIGRlZmluZWQgaW4gYSByZWdpc3RyeT8gVGhvdWdoLCBJIGRvbid0IHNlZSB0aGlzIGFz IG5lY2Vzc2FyaWx5IGFuIE9BdXRoIHNwZWNpZmljIGlzc3VlLiBUaGVyZSdzIGEgbXVjaCBicm9h ZGVyIHJlcXVpcmVtZW50IGZvciBkZWZpbmluZyBjbGllbnQgYXV0aCBiZXlvbmQgQmFzaWMsIERp Z2VzdCwgTXV0dWFsIFNTTCwgZXRjIGZvciBub24tYnJvd3NlciBjbGllbnRzLg0KDQpBcyBmb3Ig dmFsdWUgd2l0aCBPQXV0aCwgSSB0aGluayBPQXV0aCBkZXNjcmliZSBhbiBpbXBvcnRhbnQgInBh dHRlcm4iIGFuZCB3b24ndCBoYXZlIG11Y2ggZ2VuZXJhbCBpbXBhY3Qgb24gaW50ZXItb3BlcmFi aWxpdHkgYXMgYSBzdGFuZGFyZC4gVGh1cyBkb2Vzbid0IHVuZGVydmFsdWUgdGhlIHN0YW5kYXJk IHRoYXQgbXVjaCBhcyBpdCBsYXlzIGEgZm91bmRhdGlvbiBmb3Igb3RoZXIgY29tcG9uZW50cy4g VGhlIGtleSB3b3JraW5nIGludGVyLW9wIGNvbXBvbmVudHMgd2lsbCBsaWtlbHkgaGF2ZSBiZSBk ZWZpbmVkIGluIHN1YnNlcXVlbnQgcmVsYXRlZCBzcGVjcyBzdWNoIGFzIHN1Z2dlc3RlZCBhYm92 ZS4NCg0KV2hhdCBpcyBub3QgY2xlYXIgdG8gbWUgeWV0IGlzIHdoYXQgc2hvdWxkIHRoZSBkaXNj b3ZlcnkgYW5kIHJlZ2lzdHJhdGlvbiBjb21wb25lbnRzIGZvciBPQXV0aCBiZT8gSG93IG11Y2gg c2hvdWxkIGJlIGRlZmluZWQgaW4gZGVwbG95bWVudCBkb2N1bWVudGF0aW9uPyBEZXBsb3ltZW50 IGRvY3VtZW50YXRpb24gaXMgcHJvYmxlbWF0aWMgZm9yIGRldmVsb3BtZW50IHRvb2xzLiBGb3Ig ZXhhbXBsZSwgYnVpbGRpbmcgYSAuTmV0IG9yIEphdmEgcGxhdGZvcm0gaXMgbXVjaCBkaWZmZXJl bnQgdGhhbiBhIG9uZSB0aW1lIGRldmVsb3BlciB3aG8ganVzdCB3YW50cyB0byBhY2Nlc3MgYSBz aW5nbGUgZ29vZ2xlLCBmYWNlYm9vaywgZXRjIHNlcnZpY2UuICBJbiBjb250cmFzdCwgLk5ldC9K YXZhIHRvb2xzIGNhbid0IGhlbHAgbXVjaCBzaW5jZSB0aGV5IGNhbid0IGluc3BlY3QgdGhlIHNl cnZpY2UuDQoNCkkgYWdyZWUsIHRvbyBtdWNoIGVtcGhhc2lzIGlzIG9uIGRlcGxveW1lbnQgZG9j cyBmb3IgdXNlIG9mIE9BdXRoLg0KDQpQaGlsDQpwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86 cGhpbC5odW50QG9yYWNsZS5jb20+DQoNCg0KDQoNCk9uIDIwMTEtMDEtMjgsIGF0IDExOjU1IEFN LCBBbnRob255IE5hZGFsaW4gd3JvdGU6DQoNCg0KSSBzYWlkIGl0cyDigJxiZWNvbWluZ+KAnSB1 c2VsZXNzIGFzIG1vcmUgYW5kIG1vcmUgc3R1ZmYgaXMgYmVpbmcgcmVtb3ZlZC4NCg0KTWF5YmUg eW91IGRpZCBub3QgdW5kZXJzdGFuZCBvciBJIGRpZCBub3QgdGVsbCB5b3UgZXZlcnl0aGluZyB5 b3UgbmVlZGVkIHRvIGtub3csIHdlIGhhdmUgZW5kcG9pbnRzIHRoYXQgZXhwZWN0IGFzc2VydGlv bnMgYWxvbmcgd2l0aCB0aGUgZ3JhbnRfdHlwZSBvZiBhdXRob3JpemF0aW9uX2NvZGUgYW5kIHdl IGFsc28gaGF2ZSBlbmRwb2ludHMgdGhhdCBleHBlY3QgdGhlIGdyYW50X3R5cGUgb2YgVVJJIChv ciB0aGUgYXNzZXJ0aW9uLCB3aGljaCBjb3VsZCBiZSB3aGF0ZXZlciB0aGUgYXV0aG9yaXphdGlv biBzZXJ2ZXIgZGVjaWRlcyksIHRoZXNlIGFyZSAyIGRpZmZlcmVudCBlbmRwb2ludHMgd2l0aCAy IGRpZmZlcmVudCBmdW5jdGlvbnMuIFRoZSBjaGFuZ2UgdGhhdCB3YXMgbWFkZSB0byByZW1vdmUg dGhlIG5vdGlvbiBvZiBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIG9ubHkgbGVmdCB1cyB3 aXRoIHRoZSBleHRlbnNpb24gc28gd2UgY2FuIGxpdmUgd2l0aCB0aGUgY2hhbmdlcyB0byB0aGUg ZXh0ZW5zaW9uIChpdCBpcyBhIGNvZGUgY2hhbmdlIGZvciB1cykgYnV0IG5vdCByZW1vdmFsIG9m IGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgd2UgY2Fu4oCZdCBsaXZlIHdpdGggYXMgd2Ug YXJlIHVzaW5nIHRoZSBub3Rpb24gb2YgY2xpZW50IGNyZWRlbnRpYWxzLiBJ4oCZbSBub3Qgc3Vy ZSB0aGF0IHB1dHRpbmcgdGhpcyBpbiB0aGUgYmVhcmVyIHRva2VuIHNwZWNpZmljYXRpb24gd291 bGQgd29yay4NCg0KDQpGcm9tOiBFcmFuIEhhbW1lci1MYWhhdiBbbWFpbHRvOmVyYW5AaHVlbml2 ZXJzZS5jb21dPG1haWx0bzpbbWFpbHRvOmVyYW5AaHVlbml2ZXJzZS5jb21dPg0KU2VudDogV2Vk bmVzZGF5LCBKYW51YXJ5IDI2LCAyMDExIDI6NTEgUE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNj OiBPQXV0aCBXRw0KU3ViamVjdDogUkU6IFJlbW92YWw6IENsaWVudCBBc3NlcnRpb24gQ3JlZGVu dGlhbHMNCg0KQ2FuIHlvdSBleHBsYWluIGhvdyBoYXZpbmcgdG8gZGVmaW5lICp0d28qIGV4dGVu c2lvbiBwYXJhbWV0ZXJzIG1ha2VzIHRoZSBzcGVjaWZpY2F0aW9uIHVzZWxlc3M/IFRoZSBiZWFy ZXIgdG9rZW4gc3BlY2lmaWNhdGlvbiBpcyBnb2luZyB0byBkZWZpbmUgaXRzIGNvcnJlc3BvbmRp bmcgV1dXLUF1dGhlbnRpY2F0ZSBoZWFkZXIsIHRvIG1hdGNoIGl0cyBhbHJlYWR5IGRlZmluZWQg QXV0aG9yaXphdGlvbiBoZWFkZXIuIFRoZSBzY2hlbWUgbmFtZSBpcyBqdXN0IHN0eWxlIGFuZCBi cmFuZGluZyBhbmQgaGF2ZSBhYnNvbHV0ZWx5IG5vIHRlY2huaWNhbCBpbXBhY3QuIEkgYW0gaG9u ZXN0bHkgY29uZnVzZWQgYnkgeW91ciBjb21tZW50cywgYXMgSSB3YXMgaW4gdGhlIHBhc3Qgd2hl biB5b3UgZGVjbGFyZWQgdGhlIGVudGlyZSBwcm90b2NvbCB1c2VsZXNzIGJlY2F1c2Ugb2YgbXkg b2JqZWN0aW9ucyB0byBhbiB1bmRlci1kZWZpbmVkIHNjb3BlIHBhcmFtZXRlci4NCg0KQ2FuIHlv dSBwb2ludCBtZSB3aGVyZSBpbiBXUkFQIGFyZSB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50 aWFscyBkZWZpbmVkPyBJIGNhbiBvbmx5IGZpbmQgdGhlIGFzc2VydGlvbiBwcm9maWxlIHdoaWNo IGlzIGNvbXBhcmFibGUgdG8gdGhlIGV4dGVuc2lvbiBncmFudCB0eXBlIHdpdGggdGhlIFNBTUwg YXNzZXJ0aW9uIGV4dGVuc2lvbiAod2hlcmUgdGhlIGFzc2VydGlvbiBwYXJhbWV0ZXIgaXMgZGVm aW5lZCBhbmQgcmVnaXN0ZXJlZCkuIFRoZSBjb25jZXB0IG9mIHRoZSBjbGllbnQgYXNzZXJ0aW9u IHVzZWQgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAoc2VwYXJhdGUgZnJvbSB0aGUgYXV0aG9y aXphdGlvbiBncmFudCkgaXMgbmV3IGFuZCB3YXMgYWRkZWQgYmFzZWQgb24gYSBwcm9wb3NhbCBm cm9tIFlhcm9uIGluIC0xMSBvbiBEZWNlbWJlciAxc3QsIDIwMTAuDQoNCkFzIGZvciB5b3VyIGFk ZGl0aW9uYWwgZGV0YWlscyBiZWxvdyAodGhhbmtzISksIGl0IHNlZW1zIGxpa2UgeW91IGFyZSBu b3QgdXNpbmcgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYXQgYWxsIGJ1dCB1c2lu ZyBhIHNpbXBsZSBleHRlbnNpb24gZ3JhbnQgd2l0aCBhbiBhc3NlcnRpb24sIGV4YWN0bHkgbGlr ZSB0aGUgU0FNTCBleHRlbnNpb24gZ3JhbnQgc3BlY2lmaWNhdGlvbiwgb25seSB5b3UgYXJlIG5v dCBsaW1pdGVkIHRvIFNBTUwgMi4wLiBJcyB0aGF0IGNvcnJlY3Q/IElmIHRoaXMgaXMgY29ycmVj dCwgdGhlbiB0aGUgb25seSBpc3N1ZSBoZXJlIGlzIG91ciBkZWNpc2lvbiAod2hpY2ggd2FzIG1h ZGUgd2l0aG91dCBhbnkgY29tbWVudCBmcm9tIHlvdSBvciB0aG9zZSBub3cgcmFpc2luZyBpc3N1 ZXMgYWJvdXQgdGhpcykgdG8gbW92ZSB0aGUg4oCYYXNzZXJ0aW9u4oCZIHBhcmFtZXRlciBhbmQg cmVuYW1lIHRoZSBncmFudCB0eXBlIGZyb20gYXNzZXJ0aW9uIHRvIGV4dGVuc2lvbiAod2hpY2gg aGFzIG5vIGltcGxlbWVudGF0aW9uIGltcGFjdCkuIEFsbCB3ZSBkaWQgaXMgcmVsb2NhdGUgdGhl IGFzc2VydGlvbiBwYXJhbWV0ZXIgYmVjYXVzZSBpdCBkb2VzbuKAmXQgYWx3YXlzIGFwcGx5IHRv IGV4dGVuc2lvbiBncmFudHMuDQoNCklzIHRoaXMganVzdCBhIGNvbmZ1c2lvbiBhYm91dCB3aGF0 IHdhcyBiZWluZyByZW1vdmVkIGFuZCB3aGVyZSBpdCB3ZW50Pw0KDQpFSEwNCg0KDQpGcm9tOiBB bnRob255IE5hZGFsaW4gW21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dPG1haWx0bzpbbWFp bHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV0+DQpTZW50OiBXZWRuZXNkYXksIEphbnVhcnkgMjYs IDIwMTEgMTo1MiBQTQ0KVG86IEVyYW4gSGFtbWVyLUxhaGF2DQpDYzogT0F1dGggV0cNClN1Ympl Y3Q6IFJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoNCk1heWJlIHRo aXMgd2FzIHRoZSBwbGFuIGFsbCBhbG9uZyBidXQgc3BlY2lmaWNhdGlvbiBpcyBiZWNvbWluZyB1 c2VsZXNzIGZvciBvdXIgc2NlbmFyaW9zIGFuZCB3aWxsIHJlcXVpcmUgdGhhdCB3ZSBoYXZlIHRv IGdvIHdlbGwgYmV5b25kIHRoZSBjb3JlIHNwZWNpZmljYXRpb24gdG8gbWFrZSB0aGluZ3Mgd29y aywgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYmVpbmcgYSBwcmltZSBleGFtcGxl LiBUaGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBoYXMgYmVlbiBhcm91bmQgZm9yIGEg d2hpbGUgYXMgaXQgd2FzIGEgcmVxdWlyZW1lbnQgZm9yIFdSQVAsIHRoZW4gZHJvcHBlZCB3aGVu IHRoZSB2YXJpb3VzIHNwZWNzIGdvdCBtZXJnZWQgdG8gZm9ybSBPQVVUSCAyLjAgYW5kIHRoZW4g Y2FtZSBiYWNrIGludG8gdGhlIE9BVVRIIDIuMCBhbmQgdGhlbiBoYXMgZ29uZSB0aHJvdWdoIHZh cmlvdXMgY2hhbmdlcyBzaW5jZSB2ZXJzaW9uIDYgZm9yIHRoZSB3b3JzZS4gVGhlcmUgaGFzIGJl ZW4gbXVjaCBkaXNjdXNzaW9uIGluIEp1bHkvQXVndXN0IG92ZXIgdGhpcyBhbmQgbmV3IHRleHQg d2FzIHByb3Bvc2VkLCBidXQgdGhhdCBzZWVtcyB0byBub3QgYmUgZnVsbHkgYWNjZXB0ZWQsIGJ1 dCBJIHRoaW5rIHRoYXQgZm9sbG93cyB0aGUgcGF0aCB3aGVuIHlvdSB3YW50IHRvIHJlbW92ZSBz b21ldGhpbmcuDQoNCk91ciB1c2FnZSB3aWxsIGJlIHZpYSBiZWFyZXIgdG9rZW4gYXNzZXJ0aW9u cyBvbmx5IChhdCB0aGlzIHRpbWUpDQpUaGUgZ3JhbnRfdHlwZSB3b3VsZCBiZSB0aGUgVVJJIG9m IHRoZSBhc3NlcnRpb24gdHlwZSBiZWluZyB1c2VkDQpUaGUgYXV0aG9yaXphdGlvbiBlbmRwb2lu dCBjYW4gdXNlIHdoYXQgaXQgd2FudHMgdG8gYmluZCB0aGUgYXNzZXJ0aW9uIHRvIHRoZSBjbGll bnRfaWQsIG11Y2ggbGlrZSBpdCBoYXMgdG8gdG9kYXkgZm9yIHRoZSBwYXNzd29yZCBhdXRoZW50 aWNhdGlvbiwgYXMgd2UgaGF2ZSBzY2VuYXJpb3Mgd2VyZSBjbGllbnRfaWQgaGF2ZSBtdWx0aXBs ZSBwYXNzd29yZHMNCldlIHVzZSBndWlkYW5jZSBmcm9tIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24g c2VjdGlvbiBvZiB0aGUgYXNzZXJ0aW9uIHR5cGUgYmVpbmcgdXNlZCBhbG9uZyB3aXRoIHRoZSBn dWlkYW5jZSBmcm9tIHRoZSBiZWFyZXIgdG9rZW4gc3BlY2lmaWNhdGlvbg0KSWYgbmVlZGVkIEkg Y2FuIGNhcHR1cmUgdGhlIGFzc2VydGlvbnMgYW5kIHJlcXVlc3RzLCBidXQgbm90IHN1cmUgd2hh dCB0aGUgcG9pbnQgb2YgdGhpcyBpcyBhdCB0aGlzIHRpbWUgc2luY2UgdGhpcyBpcyBub3QgcmVx dWlyZWQgZm9yIHRoZSBwYXNzd29yZCBjcmVkZW50aWFscw0KDQpTdXJlIHdlIGNhbiBhZGQgdGhl IGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gdG8gdGhlIGJlYXJlciB0b2tlbiBzcGVj aWZpY2F0aW9uIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB0aGUgcHJvcGVyIHBsYWNlIHRv IGRvIHRodXMgYnV0IHNpbmNlIGl04oCZcyBnb25lIGZyb20gdGhlIGNvcmUgd2Ugd2lsbCBoYXZl IHRvIGRvIGp1c3QgdGhhdC4gVGhlIHNhbWUgc2VlbXMgdG8gaGFwcGVuIHdpdGggdGhlIEhUVFAg QXV0aGVudGljYXRpb24gU2NoZW1lIGFzIGl0IHNlZW1zIHRvIGJlIHJlcGVhdGVkIGluIGZvbGxv dy1vbiBjb21wYW5pb24gc3BlY2lmaWNhdGlvbnMuIFdoaWxlIG9hdXRoLXYyIGlzIG5vdCBhbiBh dXRoZW50aWNhdGlvbiBwcm90b2NvbCB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IGZvciBhdXRoZW50 aWNhdGlvbiB0byBhZGRyZXNzIHNlY3VyaXR5IGNvbmNlcm5zLiBUaGVyZSBpcyBjbGVhciBzZXBh cmF0aW9uIGJldHdlZW4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb247IHdlIGFyZSBu b3Qgc3VnZ2VzdGluZyB0aGF0IGF1dGhlbnRpY2F0aW9uIGlzIGFwcHJvcHJpYXRlIGZhY2lsaXR5 IHRvIG5lZ290aWF0ZSBhdXRob3JpemF0aW9uLiBJIHRoaW5rIHRoYXQgaXQgbWFrZXMgc2Vuc2Ug dG8gaW5jbHVkZSBhIHNjaGVtZSBpbiB0aGUgY29yZSBhbmQgaGF2ZSB0aGUgcGFydGljdWxhciBm b2xsb3ctb24gY29tcGFuaW9uIHNwZWNpZmljYXRpb25zICh0aGUgdmFyaW91cyB0b2tlbiBzcGVj aWZpY2F0aW9ucykgc3RhdGUvZGVmaW5lIHRoZSBwYXJhbWV0ZXJzIGFuZCBpZiB0aGV5IGRvbuKA mXQgbGlrZSB0aGUgZGVmYXVsdCBzY2hlbWUgbGV0IHRoZW0gZGVmaW5lIGEgbmV3IHNjaGVtZSBi dXQgdGhpcyBwdXRzIGEgc3Rha2UgaW4gdGhlIGdyb3VuZCBmb3IgYW4gSFRUUCBBdXRoZW50aWNh dGlvbiBTY2hlbWUuDQoNCg0KRnJvbTogRXJhbiBIYW1tZXItTGFoYXYgW21haWx0bzplcmFuQGh1 ZW5pdmVyc2UuY29tXTxtYWlsdG86W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXT4NClNlbnQ6 IFR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgNTozOCBQTQ0KVG86IEFudGhvbnkgTmFkYWxpbg0K Q2M6IE9BdXRoIFdHDQpTdWJqZWN0OiBSRTogUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVk ZW50aWFscw0KDQpDYW4geW91IHNoYXJlIHdpdGggdGhlIGxpc3QgaG93IHlvdSBwbGFuIHRvIHVz ZSB0aGlzIGNsaWVudCBhc3NlcnRpb24gYXV0aGVudGljYXRpb24gc2NoZW1lPw0KV2hpY2ggb2Yg dGhlIGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZXMgeW91IHdpbGwgdXNlIGl0IHdpdGg/DQpXaWxs IHlvdSB1c2UgaXQgd2l0aCB0aGUgYXV0aG9yaXphdGlvbiBlbmRwb2ludCwgYW5kIGlmIHNvLCBo b3cgd2lsbCB5b3UgYmluZCB0aGUgYXNzZXJ0aW9uIHRvIHRoZSBjbGllbnRfaWQ/DQpDYW4geW91 IHByb3ZpZGUgZnVsbCBleGFtcGxlcyBvZiBhc3NlcnRpb25zIGFuZCBIVFRQIHJlcXVlc3RzPw0K DQpJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIHNlZSBob3cgZmFyIGFwYXJ0IHRoZSBwcm9wb3NlZCB0 ZXh0IGJlbG93IGlzIGZyb20gYW4gYWN0dWFsIGltcGxlbWVudGF0aW9uIG1ha2luZyB1c2Ugb2Yg aXQuIEkgZXhjZXB0IHRvIHNlZSB0aGVzZSBhbnN3ZXJzIGluIGFueSBxdWFsaXR5IGRvY3VtZW50 IGRlZmluaW5nIGEgbmV3IGNsaWVudCBhdXRoZW50aWNhdGlvbiBzY2hlbWUgKHdoaWNoIGlzIHRy dWUgZm9yIHRoZSBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gdGhyb3VnaG91dCB0aGUg ZG9jdW1lbnQpLg0KDQpFSEwNCg0KDQpGcm9tOiBBbnRob255IE5hZGFsaW4gW21haWx0bzp0b255 bmFkQG1pY3Jvc29mdC5jb21dPG1haWx0bzpbbWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV0+ DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDI1LCAyMDExIDM6NTggUE0NClRvOiBFcmFuIEhhbW1l ci1MYWhhdjsgT0F1dGggV0c7IEhhbm5lcy5Uc2Nob2ZlbmlnQGdteC5uZXQ8bWFpbHRvOkhhbm5l cy5Uc2Nob2ZlbmlnQGdteC5uZXQ+OyBCbGFpbmUgQ29vaw0KU3ViamVjdDogUkU6IFJlbW92YWw6 IENsaWVudCBBc3NlcnRpb24gQ3JlZGVudGlhbHMNCg0KSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBy YXRpb25hbGUgZm9yIHJlbW92aW5nIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzLCBh cyBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRpb24gaXMgbGVmdCBpbi4gQ2xpZW50IFBhc3N3 b3JkIEF1dGhlbnRpY2F0aW9uIGlzIGFsc28gdW5kZXJzcGVjaWZpZWQgYXMgY2xpZW50X3NlY3Jl dCBjb3VsZCBiZSBhbnl0aGluZyB0aGF0IHRoZSBhdXRoZW50aWNhdGlvbiBzZXJ2ZXIgc2VlbXMg Zml0IChyYXcgY2xlYXIgdGV4dCBwYXNzd29yZCwgIGhhc2gsIGRpZ2VzdCwgZXRjLikgYW5kIG5v IHdheSB0byBkZXRlcm1pbmUgdGhlIGNvbnRlbnQuIGNsaWVudF9zZWNyZXQgaXMgYWxzbyBhIHZl cnkgd2VhayBtZWNoYW5pc20sIHNpbmNlIHRoaXMgaXMgbGVmdCBpbiB0aGUgY29yZSB0aGlzIGxl YWRzIG1lIHRvIGJlbGlldmUgdGhhdCB0aGVyZSBpcyBzdXBwb3J0IGZvciBoYXZpbmcgY2xpZW50 IGF1dGhlbnRpY2F0aW9uIGluIE9hdXRoLiBJIGRvbid0IHNlZSBob3cgaGF2aW5nIGNsaWVudF9h c3NlcnRpb24gYW5kIGNsaWVudF9hc3NlcnRpb25fdHlwZSB3b3VsZCBiZSBzb21ldGhpbmcgdGhh dCBpcyB1bmRlcnNwZWNpZmllZCBhcyBiZWluZyBhIG1lY2hhbmlzbSBpbiB3aGljaCBhc3NlcnRp b25zIGNhbiBiZSB1c2VkIGZvciBhdXRoZW50aWNhdGlvbi4gQWdyZWUgdGhhdCB0aGUgYXV0aGVu dGljYXRpb24gc2VydmVyIGhhcyB0byBtYWtlIHJpZ2h0IGFuZCBkZWNsYXJlIHdoYXQgaXMgYmVp bmcgdXNlZCBidXQgdGhhdCBpcyB0aGUgc2FtZSBmb3IgY2xpZW50IHBhc3N3b3JkIGF1dGhlbnRp Y2F0aW9uLiBUaGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGFzc2VydGlvbnMgYXJlIHNvbWV0aGlu ZyB0aGF0IE1pY3Jvc29mdCBhbmQgR29vZ2xlIGZpbmQgdXNlZnVsIGFuZCBwbGFuIG9uIGltcGxl bWVudGluZyBhbmQgdXNpbmcgYXMgYSBtZWFucyBmb3Igc3Ryb25nZXIgYXV0aGVudGljYXRpb24g dG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGlzIGV4dGVuc2liaWxpdHkgYmVsb25ncyBp biB0aGUgY29yZSwgdGhlcmUgaXMgbm8gb3RoZXIgcGxhY2UgdG8gcHV0IHRoaXMgZnVuY3Rpb25h bGl0eS4gSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhlIHJlbW92YWwgKGVpdGhlciBieSBlZGl0b3Ig b3IgZGlyZWN0aW9uIGJ5IGNvLWNoYWlyKSBpcyBzb21ldGhpbmcgdGhhdCBzaG91bGQgaGF2ZSBi ZWVuIGRvbmUgdy9vIGEgY29uc2Vuc3VzIHZvdGUgc2luY2UgdGhpcyBoYXMgYmVlbiBpbiB0aGUg c3BlY2lmaWNhdGlvbiBmb3Igc29tZSB0aW1lIHdpdGhvdXQgaXNzdWUgYW5kIHRoZSByZW1vdmFs IGNvbWVzIGFzIGNvbXBsZXRlIHVud2VsY29tZSBzdXJwcmlzZS4gR2V0dGluZyBhbG1vc3QgdG90 YWwgcmV3cml0ZXMgb2YgdGhlIHNwZWNpZmljYXRpb24gdGhpcyBsYXRlIGluIHRoZSByZXZpZXcg Y3ljbGUgaXMgYWxzbyB2ZXJ5IGRpc3R1cmJpbmcuDQoNCkEgcHJvcG9zYWwgZm9yIGtlZXBpbmcg dGhlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gd291bGQgYmUgdG8gc2ltcGxpZnkg dG8gdGhlIGZvbGxvd2luZzsNCg0KVGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgYXJl IHVzZWQgaW4gY2FzZXMgd2hlcmUgYSBwYXNzd29yZCAoY2xlYXItdGV4dCBzaGFyZWQgc3ltbWV0 cmljIHNlY3JldCkgaXMgdW5zdWl0YWJsZSBvciBkb2VzIG5vdCBwcm92aWRlIHN1ZmZpY2llbnQg c2VjdXJpdHkgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gVGhlIGNsaWVudCBhc3NlcnRpb24g Y3JlZGVudGlhbHMgcHJvdmlkZSBhbiBleHRlbnNpYmxlIG1lY2hhbmlzbSB0byB1c2UgYW4gYXNz ZXJ0aW9uIGZvcm1hdCBzdXBwb3J0ZWQgYnkgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyIGZvciBh dXRoZW50aWNhdGlvbiBvZiB0aGUgY2xpZW50Lg0KDQpVc2luZyBhc3NlcnRpb25zIHJlcXVpcmVz IHRoZSBjbGllbnQgdG8gb2J0YWluIGFuIGFzc2VydGlvbiAoc3VjaCBhcyBhIFNBTUwgKENhbnRv ciwgUy4sIEtlbXAsIEouLCBQaGlscG90dCwgUi4sIGFuZCBFLiBNYWxlciwg4oCcQXNzZXJ0aW9u cyBhbmQgUHJvdG9jb2wgZm9yIHRoZSBPQVNJUyBTZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExh bmd1YWdlIChTQU1MKSBWMi4wLOKAnSBNYXJjaCAyMDA1Lik8eC1tc2c6Ly85My8jT0FTSVMuc2Ft bC1jb3JlLTIuMC1vcz5bT0FTSVMuc2FtbOKAkWNvcmXigJEyLjDigJFvc10gYXNzZXJ0aW9uKSBm cm9tIGFuIGFzc2VydGlvbiBpc3N1ZXIgb3IgdG8gc2VsZi1pc3N1ZSBhbiBhc3NlcnRpb24uIFRo ZSBhc3NlcnRpb24gZm9ybWF0LCB0aGUgcHJvY2VzcyBieSB3aGljaCB0aGUgYXNzZXJ0aW9uIGlz IG9idGFpbmVkLCBhbmQgdGhlIG1ldGhvZCBvZiB2YWxpZGF0aW5nIHRoZSBhc3NlcnRpb24gYXJl IGRlZmluZWQgYnkgdGhlIGFzc2VydGlvbiBpc3N1ZXIgYW5kIHRoZSBhdXRob3JpemF0aW9uIHNl cnZlciwgYW5kIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCg0K V2hlbiB1c2luZyBhIGNsaWVudCBhc3NlcnRpb24sIHRoZSBjbGllbnQgaW5jbHVkZXMgdGhlIGZv bGxvd2luZyBwYXJhbWV0ZXJzOg0KY2xpZW50X2Fzc2VydGlvbl90eXBlIC0gUkVRVUlSRUQuIFRo ZSBmb3JtYXQgb2YgdGhlIGFzc2VydGlvbiBhcyBkZWZpbmVkIGJ5IHRoZSBhdXRob3JpemF0aW9u IHNlcnZlci4gVGhlIHZhbHVlIE1VU1QgYmUgYW4gYWJzb2x1dGUgVVJJLg0KY2xpZW50X2Fzc2Vy dGlvbiAtIFJFUVVJUkVELiBUaGUgY2xpZW50IGFzc2VydGlvbi4NCg0KRm9yIGV4YW1wbGUsIHRo ZSBjbGllbnQgc2VuZHMgdGhlIGZvbGxvd2luZyBhY2Nlc3MgdG9rZW4gcmVxdWVzdCB1c2luZyBh IFNBTUwgMi4wIGFzc2VydGlvbiB0byBhdXRoZW50aWNhdGUgaXRzZWxmIChsaW5lIGJyZWFrcyBh cmUgZm9yIGRpc3BsYXkgcHVycG9zZXMgb25seSk6DQoNCg0KDQoNCg0KICBQT1NUIC90b2tlbiBI VFRQLzEuMQ0KDQogIEhvc3Q6IHNlcnZlci5leGFtcGxlLmNvbTxodHRwOi8vc2VydmVyLmV4YW1w bGUuY29tLz4NCg0KICBDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5j b2RlZA0KDQoNCg0KICBncmFudF90eXBlPWF1dGhvcml6YXRpb25fY29kZSZjb2RlPWkxV3NSbjF1 QjEmDQoNCiAgY2xpZW50X2Fzc2VydGlvbj1QSE5oYld4d09sWy4uLm9taXR0ZWQgZm9yIGJyZXZp dHkuLi5dWlQ0JTNEJg0KDQogIGNsaWVudF9hc3NlcnRpb25fdHlwZT0gIHVybiUzQW9hc2lzJTNB bmFtZXMlc0F0YyUzQVNBTUwlM0EyLjAlM0Fhc3NlcnRpb24mcmVkaXJlY3RfdXJpPWh0dHBzJTNB JTJGJTJGY2xpZW50JTJFZXhhbXBsZSUyRWNvbSUyRmNiDQoNCg0KDQoNCg0KRnJvbTogb2F1dGgt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpv YXV0aC1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu b3JnXT4gT24gQmVoYWxmIE9mIEVyYW4gSGFtbWVyLUxhaGF2DQpTZW50OiBGcmlkYXksIEphbnVh cnkgMTQsIDIwMTEgMTA6NDUgUE0NClRvOiBPQXV0aCBXRw0KU3ViamVjdDogW09BVVRILVdHXSBS ZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzDQoNCkkgd291bGQgbGlrZSB0byBz dWdnZXN0IHdlIGRyb3AgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVudGlhbHMgKC0xMSBzZWN0 aW9uIDMuMikgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbiwgYW5kIGlmIG5lZWRlZCwgcHVibGlzaCBp dCBhcyBhIHNlcGFyYXRlIHNwZWNpZmljYXRpb24gZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoN Cg0KMS4gICAgICAgVGhlIG1lY2hhbmlzbSBpcyB1bmRlciBzcGVjaWZpZWQsIGVzcGVjaWFsbHkg aW4gaXRzIGhhbmRsaW5nIG9mIHRoZSBjbGllbnRfaWQgaWRlbnRpZmllciAod2hlbiB1c2VkIHRv IG9idGFpbiBlbmQtdXNlciBhdXRob3JpemF0aW9uKS4gSXQgZG9lcyBub3QgY29udGFpbiBhbnkg aW1wbGVtZW50YXRpb24gZGV0YWlscyB0byBhY2NvbXBsaXNoIGFueSBsZXZlbCBvZiBpbnRlcm9w ZXJhYmlsaXR5IG9yIGZ1bmN0aW9uYWxpdHkuIFRoaXMgaXMgaW4gY29udHJhc3QgdG8gdGhlIGFz c2VydGlvbiBncmFudCB0eXBlIHdoaWNoIGhhcyBtYXR1cmVkIG92ZXIgYSB5ZWFyIGludG8gYSBm dWxseSB0aG91Z2h0LW91dCBleHRlbnNpb24gbWVjaGFuaXNtLCBhcyB3ZWxsIGFzIGEgc2VwYXJh dGUgU0FNTCBhc3NlcnRpb24gc3BlY2lmaWNhdGlvbiB3aXRoIGFjdGl2ZSBkZXBsb3ltZW50ICh0 aGUgdHdvLCB0b2dldGhlciB3aXRoIHJ1bm5pbmcgY29kZSwgc2hvdyBjbGVhciBjb25zZW5zdXMp Lg0KMi4gICAgICAgVGhlIHNlY3Rpb24gaXMgYSBjb25mdXNlZCBtaXggb2Ygc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgc3ByaW5rbGVkIHdpdGggbm9ybWF0aXZlIGxhbmd1YWdlLiBJbnN0ZWFkLCBp dCBzaG91bGQgYmUgcmVwbGFjZWQgd2l0aCBndWlkZWxpbmVzIGZvciBleHRlbmRpbmcgdGhlIHNl dCBvZiBzdXBwb3J0ZWQgY2xpZW50IGNyZWRlbnRpYWxzLCBidXQgd2l0aG91dCBkZWZpbmluZyBh IG5ldyByZWdpc3RyeS4gSXQgaXMgY2xlYXJseSBhbiBhcmVhIG9mIGxpdHRsZSBkZXBsb3ltZW50 IGV4cGVyaWVuY2UgZm9yIE9BdXRoLCBhbmQgdGhhdCBpbmNsdWRlcyB1c2luZyBIVFRQIEJhc2lj IGF1dGhlbnRpY2F0aW9uIGZvciBjbGllbnQgYXV0aGVudGljYXRpb24gKG1vcmUgb24gdGhhdCB0 byBjb21lKS4NCjMuICAgICAgIFRoZSBzZWN0aW9uIGhhcyByZWNlaXZlZCBhIGxpdHRsZSBzdXBw b3J0IGFuZCBhIGxpdHRsZSBvYmplY3Rpb24uIFRob3NlIHdobyBzdGlsbCB3YW50IHRvIGFkdm9j YXRlIGZvciBpdCBuZWVkIHRvIHNob3cgbm90IG9ubHkgY29uc2Vuc3VzIGZvciBrZWVwaW5nIGl0 LCBidXQgYWxzbyBhY3RpdmUgY29tbXVuaXR5IHN1cHBvcnQgZm9yIGRlcGxveWluZyBpdC4gRGVw bG95bWVudCwgb2YgY291cnNlLCB3aWxsIGFsc28gcmVxdWlyZSBzaG93aW5nIHByb2dyZXNzIG9u IHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9maWxpbmcgdGhlIG1lY2hhbmlzbSBpbnRvIGEgdXNl ZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS4NCg0KQ29tbWVudHM/IENvdW50ZXItYXJndW1lbnRz Pw0KDQpFSEwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg== --_000_180155C5EA10854997314CA5E063D18F033B2B0ETK5EX14MBXC111r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZl cmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnByZQ0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVk IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0 eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZv bnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5D b2RlIGltcGFjdCB3YXMgdGhhdCBhc3NlcnRpb25fdHlwZSB3YXMgbW92ZWQvY2hhbmdlZCB0byBn cmFudF90eXBlLCB3ZSBhY3R1YWxseSBuZWVkIGNsaWVudF9hc3NlcnRpb24gYW5kIGNsaWVudF9h c3NlcnRpb25fdHlwZSBhbmQgbm90IGhhdmUgdG8gb3ZlcmxvYWQgdGhlDQogZ3JhbnRfdHlwZSBh cyBhc3NlcnRpb25fdHlwZSwgSSBjYW4gd2h5IHRoaXMgd2FzIGRvbmUgZm9yIGFsbG93aW5nIG9u ZSB0byB1c2UgYXNzZXJ0aW9ucyBpbiBnZW5lcmFsIGZvciBhdXRoZW50Y2F0aW9uczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IFBoaWwgSHVudCBbbWFpbHRvOnBoaWwuaHVudEBvcmFjbGUuY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSmFudWFyeSAyOCwgMjAxMSAxMjoxNyBQTTxicj4NCjxi PlRvOjwvYj4gQW50aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9iPiBFcmFuIEhhbW1lci1MYWhh djsgT0F1dGggV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1XR10gUmVtb3ZhbDog Q2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFsczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRvbnksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JJ20gbm90IHRvdGFsbHkgdW5kZXJzdGFuZGluZyB3aGF0IHRoZSBpc3N1 ZSBpcyBhcyBmYXIgYXMgaW1wYWN0IG9uIGNvZGUuIE15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQg dGhlIHJlbW92YWwgc2ltcGx5IHRvb2sgaXQgb3V0IG9mIHRoZSBzdGFuZGFyZCBidXQgaXMgc3Rp bGwgY292ZXJlZCBieSAmcXVvdDtvdGhlciBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc20mcXVvdDsu ICZuYnNwO1RodXMgbm8gaW1wYWN0IG9uIGNvZGUgLS0geW91DQogY2FuIHN0aWxsIHVzZSAoYXMg d2Ugd2lsbCkgdGhlIGNsaWVudF9hc3NlcnRpb24gZm9ybSBwYXJhbWV0ZXIuIFRoYXQgc2FpZCwg SSB2ZXJ5IG11Y2ggYWdyZWUgd2l0aCB5b3VyIGNvbmNlcm5zLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBtYXkgYmUgd29ydGh3aGlsZSBm b3IgdXMgdG8gd29yayBvbiBhIHByb2ZpbGUgdGhhdCBsYXlzIG91dCB0aGUgc3BlY2lmaWNzIG9m IHVzaW5nIGNsaWVudF9hc3NlcnRpb24gb3IgY2xpZW50X3Rva2VuIGluIGEgc2VwYXJhdGUgc3Bl Y2lmaWNhdGlvbi4gSnVzdCBhcyB0aGVyZSB3aWxsIGJlIG11bHRpcGxlIGFjY2VzcyB0b2tlbiBm b3JtYXRzLCBJIGV4cGVjdCB0byBzZWUgbXVsdGlwbGUgY2xpZW50IGF1dGhlbnRpY2F0aW9uDQog bWV0aG9kcy4gJm5ic3A7TWF5YmUgY2xpZW50IGF1dGggbWV0aG9kcyBzaG91bGQgYWxzbyBiZSBk ZWZpbmVkIGluIGEgcmVnaXN0cnk/IFRob3VnaCwgSSBkb24ndCBzZWUgdGhpcyBhcyBuZWNlc3Nh cmlseSBhbiBPQXV0aCBzcGVjaWZpYyBpc3N1ZS4gVGhlcmUncyBhIG11Y2ggYnJvYWRlciByZXF1 aXJlbWVudCBmb3IgZGVmaW5pbmcgY2xpZW50IGF1dGggYmV5b25kIEJhc2ljLCBEaWdlc3QsIE11 dHVhbCBTU0wsIGV0YyBmb3Igbm9uLWJyb3dzZXIgY2xpZW50cy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgZm9yIHZhbHVlIHdp dGggT0F1dGgsIEkgdGhpbmsgT0F1dGggZGVzY3JpYmUgYW4gaW1wb3J0YW50ICZxdW90O3BhdHRl cm4mcXVvdDsgYW5kIHdvbid0IGhhdmUgbXVjaCBnZW5lcmFsIGltcGFjdCBvbiBpbnRlci1vcGVy YWJpbGl0eSBhcyBhIHN0YW5kYXJkLiBUaHVzIGRvZXNuJ3QgdW5kZXJ2YWx1ZSB0aGUgc3RhbmRh cmQgdGhhdCBtdWNoIGFzIGl0IGxheXMgYSBmb3VuZGF0aW9uIGZvciBvdGhlciBjb21wb25lbnRz LiBUaGUNCiBrZXkgd29ya2luZyBpbnRlci1vcCBjb21wb25lbnRzIHdpbGwgbGlrZWx5IGhhdmUg YmUgZGVmaW5lZCBpbiBzdWJzZXF1ZW50IHJlbGF0ZWQgc3BlY3Mgc3VjaCBhcyBzdWdnZXN0ZWQg YWJvdmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldoYXQgaXMgbm90IGNsZWFyIHRvIG1lIHlldCBpcyB3aGF0IHNob3VsZCB0aGUgZGlzY292 ZXJ5IGFuZCByZWdpc3RyYXRpb24gY29tcG9uZW50cyBmb3IgT0F1dGggYmU/IEhvdyBtdWNoIHNo b3VsZCBiZSBkZWZpbmVkIGluIGRlcGxveW1lbnQgZG9jdW1lbnRhdGlvbj8gRGVwbG95bWVudCBk b2N1bWVudGF0aW9uIGlzIHByb2JsZW1hdGljIGZvciBkZXZlbG9wbWVudCB0b29scy4gRm9yIGV4 YW1wbGUsIGJ1aWxkaW5nDQogYSAuTmV0IG9yIEphdmEgcGxhdGZvcm0gaXMgbXVjaCBkaWZmZXJl bnQgdGhhbiBhIG9uZSB0aW1lIGRldmVsb3BlciB3aG8ganVzdCB3YW50cyB0byBhY2Nlc3MgYSBz aW5nbGUgZ29vZ2xlLCBmYWNlYm9vaywgZXRjIHNlcnZpY2UuICZuYnNwO0luIGNvbnRyYXN0LCAu TmV0L0phdmEgdG9vbHMgY2FuJ3QgaGVscCBtdWNoIHNpbmNlIHRoZXkgY2FuJ3QgaW5zcGVjdCB0 aGUgc2VydmljZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSwgdG9vIG11Y2ggZW1waGFzaXMgaXMgb24gZGVwbG95bWVu dCBkb2NzIGZvciB1c2Ugb2YgT0F1dGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNs ZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIwMTEtMDEtMjgsIGF0IDExOjU1 IEFNLCBBbnRob255IE5hZGFsaW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSBzYWlkIGl0cyDigJxiZWNvbWluZ+KAnSB1c2VsZXNzIGFzIG1vcmUgYW5kIG1v cmUgc3R1ZmYgaXMgYmVpbmcgcmVtb3ZlZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1heWJlIHlvdSBkaWQgbm90IHVuZGVyc3RhbmQgb3Ig SSBkaWQgbm90IHRlbGwgeW91IGV2ZXJ5dGhpbmcgeW91IG5lZWRlZCB0byBrbm93LCB3ZSBoYXZl IGVuZHBvaW50cyB0aGF0IGV4cGVjdCBhc3NlcnRpb25zIGFsb25nIHdpdGggdGhlIGdyYW50X3R5 cGUgb2YgYXV0aG9yaXphdGlvbl9jb2RlDQogYW5kIHdlIGFsc28gaGF2ZSBlbmRwb2ludHMgdGhh dCBleHBlY3QgdGhlIGdyYW50X3R5cGUgb2YgVVJJIChvciB0aGUgYXNzZXJ0aW9uLCB3aGljaCBj b3VsZCBiZSB3aGF0ZXZlciB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgZGVjaWRlcyksIHRoZXNl IGFyZSAyIGRpZmZlcmVudCBlbmRwb2ludHMgd2l0aCAyIGRpZmZlcmVudCBmdW5jdGlvbnMuIFRo ZSBjaGFuZ2UgdGhhdCB3YXMgbWFkZSB0byByZW1vdmUgdGhlIG5vdGlvbiBvZiBjbGllbnQgYXNz ZXJ0aW9uDQogY3JlZGVudGlhbHMgb25seSBsZWZ0IHVzIHdpdGggdGhlIGV4dGVuc2lvbiBzbyB3 ZSBjYW4gbGl2ZSB3aXRoIHRoZSBjaGFuZ2VzIHRvIHRoZSBleHRlbnNpb24gKGl0IGlzIGEgY29k ZSBjaGFuZ2UgZm9yIHVzKSBidXQgbm90IHJlbW92YWwgb2YgY2xpZW50IGFzc2VydGlvbiBjcmVk ZW50aWFscyB3ZSBjYW7igJl0IGxpdmUgd2l0aCBhcyB3ZSBhcmUgdXNpbmcgdGhlIG5vdGlvbiBv ZiBjbGllbnQgY3JlZGVudGlhbHMuIEnigJltIG5vdCBzdXJlIHRoYXQNCiBwdXR0aW5nIHRoaXMg aW4gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uIHdvdWxkIHdvcmsuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItd2lkdGg6aW5pdGlhbDti b3JkZXItY29sb3I6aW5pdGlhbCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RXJhbg0KIEhhbW1lci1MYWhh diA8YSBocmVmPSJtYWlsdG86W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXSI+W21haWx0bzpl cmFuQGh1ZW5pdmVyc2UuY29tXTwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgSmFudWFyeSAyNiwgMjAxMSAyOjUx IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5BbnRob255IE5hZGFsaW48YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk9BdXRoIFdHPGJyPg0KPGI+U3ViamVj dDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJF OiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkNhbiB5b3UgZXhwbGFpbiBob3cgaGF2aW5nIHRvIGRlZmluZSAqPGI+dHdvPC9iPiogZXh0 ZW5zaW9uIHBhcmFtZXRlcnMgbWFrZXMgdGhlIHNwZWNpZmljYXRpb24gdXNlbGVzcz8gVGhlIGJl YXJlciB0b2tlbiBzcGVjaWZpY2F0aW9uIGlzIGdvaW5nIHRvIGRlZmluZSBpdHMNCiBjb3JyZXNw b25kaW5nIFdXVy1BdXRoZW50aWNhdGUgaGVhZGVyLCB0byBtYXRjaCBpdHMgYWxyZWFkeSBkZWZp bmVkIEF1dGhvcml6YXRpb24gaGVhZGVyLiBUaGUgc2NoZW1lIG5hbWUgaXMganVzdCBzdHlsZSBh bmQgYnJhbmRpbmcgYW5kIGhhdmUgYWJzb2x1dGVseSBubyB0ZWNobmljYWwgaW1wYWN0LiBJIGFt IGhvbmVzdGx5IGNvbmZ1c2VkIGJ5IHlvdXIgY29tbWVudHMsIGFzIEkgd2FzIGluIHRoZSBwYXN0 IHdoZW4geW91IGRlY2xhcmVkIHRoZQ0KIGVudGlyZSBwcm90b2NvbCB1c2VsZXNzIGJlY2F1c2Ug b2YgbXkgb2JqZWN0aW9ucyB0byBhbiB1bmRlci1kZWZpbmVkIHNjb3BlIHBhcmFtZXRlci48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkNhbiB5 b3UgcG9pbnQgbWUgd2hlcmUgaW4gV1JBUCBhcmUgdGhlIGNsaWVudCBhc3NlcnRpb24gY3JlZGVu dGlhbHMgZGVmaW5lZD8gSSBjYW4gb25seSBmaW5kIHRoZSBhc3NlcnRpb24gcHJvZmlsZSB3aGlj aCBpcyBjb21wYXJhYmxlIHRvIHRoZSBleHRlbnNpb24gZ3JhbnQNCiB0eXBlIHdpdGggdGhlIFNB TUwgYXNzZXJ0aW9uIGV4dGVuc2lvbiAod2hlcmUgdGhlIGFzc2VydGlvbiBwYXJhbWV0ZXIgaXMg ZGVmaW5lZCBhbmQgcmVnaXN0ZXJlZCkuIFRoZSBjb25jZXB0IG9mIHRoZSBjbGllbnQgYXNzZXJ0 aW9uIHVzZWQgZm9yIGNsaWVudCBhdXRoZW50aWNhdGlvbiAoc2VwYXJhdGUgZnJvbSB0aGUgYXV0 aG9yaXphdGlvbiBncmFudCkgaXMgbmV3IGFuZCB3YXMgYWRkZWQgYmFzZWQgb24gYSBwcm9wb3Nh bCBmcm9tIFlhcm9uDQogaW4gLTExIG9uIERlY2VtYmVyIDE8c3VwPnN0PC9zdXA+LCAyMDEwLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QXMg Zm9yIHlvdXIgYWRkaXRpb25hbCBkZXRhaWxzIGJlbG93ICh0aGFua3MhKSwgaXQgc2VlbXMgbGlr ZSB5b3UgYXJlIG5vdCB1c2luZyB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhdCBh bGwgYnV0IHVzaW5nIGEgc2ltcGxlIGV4dGVuc2lvbiBncmFudCB3aXRoDQogYW4gYXNzZXJ0aW9u LCBleGFjdGx5IGxpa2UgdGhlIFNBTUwgZXh0ZW5zaW9uIGdyYW50IHNwZWNpZmljYXRpb24sIG9u bHkgeW91IGFyZSBub3QgbGltaXRlZCB0byBTQU1MIDIuMC4gSXMgdGhhdCBjb3JyZWN0PyBJZiB0 aGlzIGlzIGNvcnJlY3QsIHRoZW4gdGhlIG9ubHkgaXNzdWUgaGVyZSBpcyBvdXIgZGVjaXNpb24g KHdoaWNoIHdhcyBtYWRlIHdpdGhvdXQgYW55IGNvbW1lbnQgZnJvbSB5b3Ugb3IgdGhvc2Ugbm93 IHJhaXNpbmcgaXNzdWVzDQogYWJvdXQgdGhpcykgdG8gbW92ZSB0aGUg4oCYYXNzZXJ0aW9u4oCZ IHBhcmFtZXRlciBhbmQgcmVuYW1lIHRoZSBncmFudCB0eXBlIGZyb20gYXNzZXJ0aW9uIHRvIGV4 dGVuc2lvbiAod2hpY2ggaGFzIG5vIGltcGxlbWVudGF0aW9uIGltcGFjdCkuIEFsbCB3ZSBkaWQg aXMgcmVsb2NhdGUgdGhlIGFzc2VydGlvbiBwYXJhbWV0ZXIgYmVjYXVzZSBpdCBkb2VzbuKAmXQg YWx3YXlzIGFwcGx5IHRvIGV4dGVuc2lvbiBncmFudHMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JcyB0aGlzIGp1c3QgYSBjb25mdXNpb24g YWJvdXQgd2hhdCB3YXMgYmVpbmcgcmVtb3ZlZCBhbmQgd2hlcmUgaXQgd2VudD88L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkVITDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVy LWNvbG9yOmluaXRpYWwiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci13 aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjppbml0aWFsIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbnRo b255DQogTmFkYWxpbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86W21haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb21dIj5bbWFp bHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV08L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIEphbnVhcnkgMjYsIDIw MTEgMTo1MiBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+RXJhbiBIYW1tZXItTGFoYXY8YnI+DQo8Yj5DYzo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk9BdXRoIFdHPGJyPg0K PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk1heWJlIHRoaXMgd2FzIHRoZSBwbGFuIGFsbCBhbG9uZyBidXQgc3BlY2lm aWNhdGlvbiBpcyBiZWNvbWluZyB1c2VsZXNzIGZvciBvdXIgc2NlbmFyaW9zIGFuZCB3aWxsIHJl cXVpcmUgdGhhdCB3ZSBoYXZlIHRvIGdvIHdlbGwgYmV5b25kIHRoZSBjb3JlIHNwZWNpZmljYXRp b24NCiB0byBtYWtlIHRoaW5ncyB3b3JrLCB0aGUgY2xpZW50IGFzc2VydGlvbiBjcmVkZW50aWFs cyBiZWluZyBhIHByaW1lIGV4YW1wbGUuIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxz IGhhcyBiZWVuIGFyb3VuZCBmb3IgYSB3aGlsZSBhcyBpdCB3YXMgYSByZXF1aXJlbWVudCBmb3Ig V1JBUCwgdGhlbiBkcm9wcGVkIHdoZW4gdGhlIHZhcmlvdXMgc3BlY3MgZ290IG1lcmdlZCB0byBm b3JtIE9BVVRIIDIuMCBhbmQgdGhlbiBjYW1lIGJhY2sNCiBpbnRvIHRoZSBPQVVUSCAyLjAgYW5k IHRoZW4gaGFzIGdvbmUgdGhyb3VnaCB2YXJpb3VzIGNoYW5nZXMgc2luY2UgdmVyc2lvbiA2IGZv ciB0aGUgd29yc2UuIFRoZXJlIGhhcyBiZWVuIG11Y2ggZGlzY3Vzc2lvbiBpbiBKdWx5L0F1Z3Vz dCBvdmVyIHRoaXMgYW5kIG5ldyB0ZXh0IHdhcyBwcm9wb3NlZCwgYnV0IHRoYXQgc2VlbXMgdG8g bm90IGJlIGZ1bGx5IGFjY2VwdGVkLCBidXQgSSB0aGluayB0aGF0IGZvbGxvd3MgdGhlIHBhdGgg d2hlbiB5b3UNCiB3YW50IHRvIHJlbW92ZSBzb21ldGhpbmcuPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PdXIgdXNhZ2Ugd2lsbCBiZSB2aWEg YmVhcmVyIHRva2VuIGFzc2VydGlvbnMgb25seSAoYXQgdGhpcyB0aW1lKTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGUgZ3JhbnRfdHlwZSB3b3VsZCBiZSB0aGUgVVJJIG9mIHRoZSBhc3NlcnRp b24gdHlwZSBiZWluZyB1c2VkPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBhdXRob3JpemF0 aW9uIGVuZHBvaW50IGNhbiB1c2Ugd2hhdCBpdCB3YW50cyB0byBiaW5kIHRoZSBhc3NlcnRpb24g dG8gdGhlIGNsaWVudF9pZCwgbXVjaCBsaWtlIGl0IGhhcyB0byB0b2RheSBmb3IgdGhlIHBhc3N3 b3JkIGF1dGhlbnRpY2F0aW9uLCBhcyB3ZSBoYXZlDQogc2NlbmFyaW9zIHdlcmUgY2xpZW50X2lk IGhhdmUgbXVsdGlwbGUgcGFzc3dvcmRzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldlIHVzZSBn dWlkYW5jZSBmcm9tIHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gc2VjdGlvbiBvZiB0aGUgYXNzZXJ0 aW9uIHR5cGUgYmVpbmcgdXNlZCBhbG9uZyB3aXRoIHRoZSBndWlkYW5jZSBmcm9tIHRoZSBiZWFy ZXIgdG9rZW4gc3BlY2lmaWNhdGlvbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBuZWVkZWQg SSBjYW4gY2FwdHVyZSB0aGUgYXNzZXJ0aW9ucyBhbmQgcmVxdWVzdHMsIGJ1dCBub3Qgc3VyZSB3 aGF0IHRoZSBwb2ludCBvZiB0aGlzIGlzIGF0IHRoaXMgdGltZSBzaW5jZSB0aGlzIGlzIG5vdCBy ZXF1aXJlZCBmb3IgdGhlIHBhc3N3b3JkIGNyZWRlbnRpYWxzPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdXJlIHdlIGNhbiBhZGQgdGhlIGNs aWVudCBhdXRoZW50aWNhdGlvbiBhc3NlcnRpb24gdG8gdGhlIGJlYXJlciB0b2tlbiBzcGVjaWZp Y2F0aW9uIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpcyB0aGUgcHJvcGVyIHBsYWNlIHRvIGRv IHRodXMgYnV0IHNpbmNlIGl04oCZcyBnb25lDQogZnJvbSB0aGUgY29yZSB3ZSB3aWxsIGhhdmUg dG8gZG8ganVzdCB0aGF0LiBUaGUgc2FtZSBzZWVtcyB0byBoYXBwZW4gd2l0aCB0aGUgSFRUUCBB dXRoZW50aWNhdGlvbiBTY2hlbWUgYXMgaXQgc2VlbXMgdG8gYmUgcmVwZWF0ZWQgaW4gZm9sbG93 LW9uIGNvbXBhbmlvbiBzcGVjaWZpY2F0aW9ucy4gV2hpbGUgb2F1dGgtdjIgaXMgbm90IGFuIGF1 dGhlbnRpY2F0aW9uIHByb3RvY29sIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgZm9yIGF1dGhlbnRp Y2F0aW9uDQogdG8gYWRkcmVzcyBzZWN1cml0eSBjb25jZXJucy4gVGhlcmUgaXMgY2xlYXIgc2Vw YXJhdGlvbiBiZXR3ZWVuIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uOyB3ZSBhcmUg bm90IHN1Z2dlc3RpbmcgdGhhdCBhdXRoZW50aWNhdGlvbiBpcyBhcHByb3ByaWF0ZSBmYWNpbGl0 eSB0byBuZWdvdGlhdGUgYXV0aG9yaXphdGlvbi4gSSB0aGluayB0aGF0IGl0IG1ha2VzIHNlbnNl IHRvIGluY2x1ZGUgYSBzY2hlbWUgaW4gdGhlIGNvcmUgYW5kDQogaGF2ZSB0aGUgcGFydGljdWxh ciBmb2xsb3ctb24gY29tcGFuaW9uIHNwZWNpZmljYXRpb25zICh0aGUgdmFyaW91cyB0b2tlbiBz cGVjaWZpY2F0aW9ucykgc3RhdGUvZGVmaW5lIHRoZSBwYXJhbWV0ZXJzIGFuZCBpZiB0aGV5IGRv buKAmXQgbGlrZSB0aGUgZGVmYXVsdCBzY2hlbWUgbGV0IHRoZW0gZGVmaW5lIGEgbmV3IHNjaGVt ZSBidXQgdGhpcyBwdXRzIGEgc3Rha2UgaW4gdGhlIGdyb3VuZCBmb3IgYW4gSFRUUCBBdXRoZW50 aWNhdGlvbiBTY2hlbWUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbjtib3JkZXItd2lkdGg6aW5pdGlhbDtib3JkZXItY29sb3I6aW5pdGlhbCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RXJhbg0KIEhhbW1lci1MYWhhdjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86W21haWx0bzplcmFuQGh1ZW5pdmVy c2UuY29tXSI+W21haWx0bzplcmFuQGh1ZW5pdmVyc2UuY29tXTwvYT48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEphbnVh cnkgMjUsIDIwMTEgNTozOCBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QW50aG9ueSBOYWRhbGluPGJyPg0KPGI+Q2M6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5PQXV0aCBX Rzxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5SRTogUmVtb3ZhbDogQ2xpZW50IEFzc2VydGlvbiBDcmVkZW50aWFsczwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5DYW4geW91IHNoYXJlIHdpdGggdGhlIGxpc3QgaG93IHlvdSBw bGFuIHRvIHVzZSB0aGlzIGNsaWVudCBhc3NlcnRpb24gYXV0aGVudGljYXRpb24gc2NoZW1lPzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGljaCBvZiB0aGUgYXV0aG9yaXphdGlvbiBncmFudCB0 eXBlcyB5b3Ugd2lsbCB1c2UgaXQgd2l0aD88L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2lsbCB5 b3UgdXNlIGl0IHdpdGggdGhlIGF1dGhvcml6YXRpb24gZW5kcG9pbnQsIGFuZCBpZiBzbywgaG93 IHdpbGwgeW91IGJpbmQgdGhlIGFzc2VydGlvbiB0byB0aGUgY2xpZW50X2lkPzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5DYW4geW91IHByb3ZpZGUgZnVsbCBleGFtcGxlcyBvZiBhc3NlcnRpb25z IGFuZCBIVFRQIHJlcXVlc3RzPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SXQgd291bGQgYmUgaGVscGZ1bCB0byBzZWUgaG93IGZhciBhcGFy dCB0aGUgcHJvcG9zZWQgdGV4dCBiZWxvdyBpcyBmcm9tIGFuIGFjdHVhbCBpbXBsZW1lbnRhdGlv biBtYWtpbmcgdXNlIG9mIGl0LiBJIGV4Y2VwdCB0byBzZWUgdGhlc2UgYW5zd2VycyBpbiBhbnkg cXVhbGl0eQ0KIGRvY3VtZW50IGRlZmluaW5nIGEgbmV3IGNsaWVudCBhdXRoZW50aWNhdGlvbiBz Y2hlbWUgKHdoaWNoIGlzIHRydWUgZm9yIHRoZSBjbGllbnQgcGFzc3dvcmQgYXV0aGVudGljYXRp b24gdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQpLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RUhMPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGlu IDBpbiA0LjBwdDtib3JkZXItd2lkdGg6aW5pdGlhbDtib3JkZXItY29sb3I6aW5pdGlhbCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVy LWNvbG9yOmluaXRpYWwiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFudGhvbnkNCiBOYWRhbGluPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpbbWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbV0iPlttYWlsdG86dG9ueW5hZEBtaWNyb3Nv ZnQuY29tXTwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIEphbnVhcnkgMjUsIDIwMTEgMzo1OCBQTTxicj4NCjxiPlRv OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RXJh biBIYW1tZXItTGFoYXY7IE9BdXRoIFdHOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5l dCI+SGFubmVzLlRzY2hvZmVuaWdAZ214Lm5ldDwvYT47IEJsYWluZSBDb29rPGJyPg0KPGI+U3Vi amVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PlJFOiBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGRvbid0 IHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBmb3IgcmVtb3ZpbmcgdGhlIGNsaWVudCBhc3NlcnRp b24gY3JlZGVudGlhbHMsIGFzIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbiBpcyBsZWZ0 IGluLiBDbGllbnQgUGFzc3dvcmQgQXV0aGVudGljYXRpb24gaXMgYWxzbyB1bmRlcnNwZWNpZmll ZA0KIGFzIGNsaWVudF9zZWNyZXQgY291bGQgYmUgYW55dGhpbmcgdGhhdCB0aGUgYXV0aGVudGlj YXRpb24gc2VydmVyIHNlZW1zIGZpdCAocmF3IGNsZWFyIHRleHQgcGFzc3dvcmQsJm5ic3A7IGhh c2gsIGRpZ2VzdCwgZXRjLikgYW5kIG5vIHdheSB0byBkZXRlcm1pbmUgdGhlIGNvbnRlbnQuIGNs aWVudF9zZWNyZXQgaXMgYWxzbyBhIHZlcnkgd2VhayBtZWNoYW5pc20sIHNpbmNlIHRoaXMgaXMg bGVmdCBpbiB0aGUgY29yZSB0aGlzIGxlYWRzIG1lIHRvIGJlbGlldmUNCiB0aGF0IHRoZXJlIGlz IHN1cHBvcnQgZm9yIGhhdmluZyBjbGllbnQgYXV0aGVudGljYXRpb24gaW4gT2F1dGguIEkgZG9u J3Qgc2VlIGhvdyBoYXZpbmcgY2xpZW50X2Fzc2VydGlvbiBhbmQgY2xpZW50X2Fzc2VydGlvbl90 eXBlIHdvdWxkIGJlIHNvbWV0aGluZyB0aGF0IGlzIHVuZGVyc3BlY2lmaWVkIGFzIGJlaW5nIGEg bWVjaGFuaXNtIGluIHdoaWNoIGFzc2VydGlvbnMgY2FuIGJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0 aW9uLiBBZ3JlZSB0aGF0DQogdGhlIGF1dGhlbnRpY2F0aW9uIHNlcnZlciBoYXMgdG8gbWFrZSBy aWdodCBhbmQgZGVjbGFyZSB3aGF0IGlzIGJlaW5nIHVzZWQgYnV0IHRoYXQgaXMgdGhlIHNhbWUg Zm9yIGNsaWVudCBwYXNzd29yZCBhdXRoZW50aWNhdGlvbi4gVGhlIGNsaWVudCBhdXRoZW50aWNh dGlvbiBhc3NlcnRpb25zIGFyZSBzb21ldGhpbmcgdGhhdCBNaWNyb3NvZnQgYW5kIEdvb2dsZSBm aW5kIHVzZWZ1bCBhbmQgcGxhbiBvbiBpbXBsZW1lbnRpbmcgYW5kIHVzaW5nDQogYXMgYSBtZWFu cyBmb3Igc3Ryb25nZXIgYXV0aGVudGljYXRpb24gdG8gdGhlIGF1dGhvcml6YXRpb24gc2VydmVy LiBUaGlzIGV4dGVuc2liaWxpdHkgYmVsb25ncyBpbiB0aGUgY29yZSwgdGhlcmUgaXMgbm8gb3Ro ZXIgcGxhY2UgdG8gcHV0IHRoaXMgZnVuY3Rpb25hbGl0eS4gSSBkb24ndCBiZWxpZXZlIHRoYXQg dGhlIHJlbW92YWwgKGVpdGhlciBieSBlZGl0b3Igb3IgZGlyZWN0aW9uIGJ5IGNvLWNoYWlyKSBp cyBzb21ldGhpbmcgdGhhdCBzaG91bGQNCiBoYXZlIGJlZW4gZG9uZSB3L28gYSBjb25zZW5zdXMg dm90ZSBzaW5jZSB0aGlzIGhhcyBiZWVuIGluIHRoZSBzcGVjaWZpY2F0aW9uIGZvciBzb21lIHRp bWUgd2l0aG91dCBpc3N1ZSBhbmQgdGhlIHJlbW92YWwgY29tZXMgYXMgY29tcGxldGUgdW53ZWxj b21lIHN1cnByaXNlLiBHZXR0aW5nIGFsbW9zdCB0b3RhbCByZXdyaXRlcyBvZiB0aGUgc3BlY2lm aWNhdGlvbiB0aGlzIGxhdGUgaW4gdGhlIHJldmlldyBjeWNsZSBpcyBhbHNvIHZlcnkgZGlzdHVy YmluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+QSBwcm9wb3NhbCBmb3Iga2VlcGluZyB0aGUgY2xpZW50IGF1dGhl bnRpY2F0aW9uIGFzc2VydGlvbiB3b3VsZCBiZSB0byBzaW1wbGlmeSB0byB0aGUgZm9sbG93aW5n OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2lu LWxlZnQ6MjQuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgY2xp ZW50IGFzc2VydGlvbiBjcmVkZW50aWFscyBhcmUgdXNlZCBpbiBjYXNlcyB3aGVyZSBhIHBhc3N3 b3JkIChjbGVhci10ZXh0IHNoYXJlZCBzeW1tZXRyaWMgc2VjcmV0KSBpcyB1bnN1aXRhYmxlIG9y IGRvZXMgbm90IHByb3ZpZGUgc3VmZmljaWVudCBzZWN1cml0eSBmb3IgY2xpZW50IGF1dGhlbnRp Y2F0aW9uLg0KIFRoZSBjbGllbnQgYXNzZXJ0aW9uIGNyZWRlbnRpYWxzIHByb3ZpZGUgYW4gZXh0 ZW5zaWJsZSBtZWNoYW5pc20gdG8gdXNlIGFuIGFzc2VydGlvbiBmb3JtYXQgc3VwcG9ydGVkIGJ5 IHRoZSBhdXRob3JpemF0aW9uIHNlcnZlciBmb3IgYXV0aGVudGljYXRpb24gb2YgdGhlIGNsaWVu dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUu MHB0O21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDoy NC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlVzaW5nIGFzc2VydGlv bnMgcmVxdWlyZXMgdGhlIGNsaWVudCB0byBvYnRhaW4gYW4gYXNzZXJ0aW9uIChzdWNoIGFzIGE8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxh IGhyZWY9IngtbXNnOi8vOTMvI09BU0lTLnNhbWwtY29yZS0yLjAtb3MiPjxzcGFuIGxhbmc9IkVO IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O3RleHQtZGVjb3JhdGlvbjpub25lIj5TQU1MDQogKENhbnRvciwgUy4sIEtlbXAsIEou LCBQaGlscG90dCwgUi4sIGFuZCBFLiBNYWxlciwg4oCcQXNzZXJ0aW9ucyBhbmQgUHJvdG9jb2wg Zm9yIHRoZSBPQVNJUyBTZWN1cml0eSBBc3NlcnRpb24gTWFya3VwIExhbmd1YWdlIChTQU1MKSBW Mi4wLOKAnSBNYXJjaCZuYnNwOzIwMDUuKTwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPltPQVNJUy5zYW1s4oCRY29yZeKAkTIuMOKAkW9zXQ0KIGFzc2VydGlvbikg ZnJvbSBhbiBhc3NlcnRpb24gaXNzdWVyIG9yIHRvIHNlbGYtaXNzdWUgYW4gYXNzZXJ0aW9uLiBU aGUgYXNzZXJ0aW9uIGZvcm1hdCwgdGhlIHByb2Nlc3MgYnkgd2hpY2ggdGhlIGFzc2VydGlvbiBp cyBvYnRhaW5lZCwgYW5kIHRoZSBtZXRob2Qgb2YgdmFsaWRhdGluZyB0aGUgYXNzZXJ0aW9uIGFy ZSBkZWZpbmVkIGJ5IHRoZSBhc3NlcnRpb24gaXNzdWVyIGFuZCB0aGUgYXV0aG9yaXphdGlvbiBz ZXJ2ZXIsIGFuZCBhcmUgYmV5b25kDQogdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0 O21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDoyNC4w cHQiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldoZW4gdXNpbmcgYSBjbGll bnQgYXNzZXJ0aW9uLCB0aGUgY2xpZW50IGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVy czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDo2MC4wcHQ7 bWFyZ2luLXJpZ2h0OjYwLjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5jbGllbnRfYXNzZXJ0aW9uX3R5 cGUgLSBSRVFVSVJFRC4gVGhlIGZvcm1hdCBvZiB0aGUgYXNzZXJ0aW9uIGFzIGRlZmluZWQgYnkg dGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiBUaGUgdmFsdWUgTVVTVCBiZSBhbiBhYnNvbHV0ZSBV UkkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoyNC4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi41aW4iPjxzcGFuIGxhbmc9IkVOIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPmNsaWVudF9hc3NlcnRpb24gLSBSRVFVSVJF RC4gVGhlIGNsaWVudCBhc3NlcnRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJn aW4tbGVmdDoyNC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZvciBl eGFtcGxlLCB0aGUgY2xpZW50IHNlbmRzIHRoZSBmb2xsb3dpbmcgYWNjZXNzIHRva2VuIHJlcXVl c3QgdXNpbmcgYSBTQU1MIDIuMCBhc3NlcnRpb24gdG8gYXV0aGVudGljYXRlIGl0c2VsZiAobGlu ZSBicmVha3MgYXJlIGZvciBkaXNwbGF5IHB1cnBvc2VzIG9ubHkpOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjI0 LjBwdDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRvbTou MDAwMXB0O2JhY2tncm91bmQ6I0NDQ0NDQztiYWNrZ3JvdW5kLWltYWdlOmluaXRpYWw7YmFja2dy b3VuZC1hdHRhY2htZW50OmluaXRpYWw7YmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7YmFja2dy b3VuZC1jbGlwOiBpbml0aWFsO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2Jh Y2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MjQuMHB0O21hcmdp bi1ib3R0b206MGluO21hcmdpbi1sZWZ0OjYwLjBwdDttYXJnaW4tYm90dG9tOi4wMDAxcHQ7YmFj a2dyb3VuZDojQ0NDQ0NDO2JhY2tncm91bmQtaW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLWF0dGFj aG1lbnQ6aW5pdGlhbDtiYWNrZ3JvdW5kLW9yaWdpbjogaW5pdGlhbDtiYWNrZ3JvdW5kLWNsaXA6 IGluaXRpYWw7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1y ZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOiNDQ0NDQ0M7YmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtYXR0 YWNobWVudDppbml0aWFsO2JhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsO2JhY2tncm91bmQtY2xp cDogaW5pdGlhbDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5k LXJlcGVhdDppbml0aWFsIGluaXRpYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7IFBPU1QgL3Rva2VuIEhUVFAvMS4xPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0 OjI0LjBwdDttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDo2MC4wcHQ7bWFyZ2luLWJvdHRv bTouMDAwMXB0O2JhY2tncm91bmQ6I0NDQ0NDQztiYWNrZ3JvdW5kLWltYWdlOmluaXRpYWw7YmFj a2dyb3VuZC1hdHRhY2htZW50OmluaXRpYWw7YmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7YmFj a2dyb3VuZC1jbGlwOiBpbml0aWFsO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFs O2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsgSG9zdDogPGEgaHJlZj0iaHR0 cDovL3NlcnZlci5leGFtcGxlLmNvbS8iPnNlcnZlci5leGFtcGxlLmNvbTwvYT48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDojQ0NDQ0NDO2JhY2tncm91bmQtaW1hZ2U6 aW5pdGlhbDtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6aW5pdGlhbDtiYWNrZ3JvdW5kLW9yaWdpbjog aW5pdGlhbDtiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0 aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyBDb250ZW50 LVR5cGU6IGFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOiNDQ0NDQ0M7YmFja2dyb3VuZC1pbWFnZTppbml0aWFs O2JhY2tncm91bmQtYXR0YWNobWVudDppbml0aWFsO2JhY2tncm91bmQtb3JpZ2luOiBpbml0aWFs O2JhY2tncm91bmQtY2xpcDogaW5pdGlhbDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5p dGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPjxzcGFuIGxhbmc9IkVOIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6I0NDQ0NDQztiYWNrZ3JvdW5kLWltYWdlOmluaXRp YWw7YmFja2dyb3VuZC1hdHRhY2htZW50OmluaXRpYWw7YmFja2dyb3VuZC1vcmlnaW46IGluaXRp YWw7YmFja2dyb3VuZC1jbGlwOiBpbml0aWFsO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBp bml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsgZ3JhbnRfdHlwZT1h dXRob3JpemF0aW9uX2NvZGUmYW1wO2NvZGU9aTFXc1JuMXVCMSZhbXA7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6I0NDQ0NDQztiYWNrZ3JvdW5kLWltYWdlOmluaXRp YWw7YmFja2dyb3VuZC1hdHRhY2htZW50OmluaXRpYWw7YmFja2dyb3VuZC1vcmlnaW46IGluaXRp YWw7YmFja2dyb3VuZC1jbGlwOiBpbml0aWFsO2JhY2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBp bml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsgY2xpZW50X2Fzc2Vy dGlvbj1QSE5oYld4d09sWy4uLm9taXR0ZWQgZm9yIGJyZXZpdHkuLi5dWlQ0JTNEJmFtcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDojQ0NDQ0NDO2JhY2tncm91bmQt aW1hZ2U6aW5pdGlhbDtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6aW5pdGlhbDtiYWNrZ3JvdW5kLW9y aWdpbjogaW5pdGlhbDtiYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7YmFja2dyb3VuZC1wb3NpdGlv bjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyBj bGllbnRfYXNzZXJ0aW9uX3R5cGU9ICZuYnNwO3VybiUzQW9hc2lzJTNBbmFtZXMlc0F0YyUzQVNB TUwlM0EyLjAlM0Fhc3NlcnRpb24mYW1wO3JlZGlyZWN0X3VyaT1odHRwcyUzQSUyRiUyRmNsaWVu dCUyRWV4YW1wbGUlMkVjb20lMkZjYjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDoyNC4wcHQ7bWFyZ2luLWJvdHRvbTowaW47 bWFyZ2luLWxlZnQ6NjAuMHB0O21hcmdpbi1ib3R0b206LjAwMDFwdDtiYWNrZ3JvdW5kOiNDQ0ND Q0M7YmFja2dyb3VuZC1pbWFnZTppbml0aWFsO2JhY2tncm91bmQtYXR0YWNobWVudDppbml0aWFs O2JhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsO2JhY2tncm91bmQtY2xpcDogaW5pdGlhbDtiYWNr Z3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFs IGluaXRpYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW47Ym9yZGVyLXdp ZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhy ZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3Jn PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86W21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSI+W21haWx0bzpvYXV0 aC1ib3VuY2VzQGlldGYub3JnXTwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkVyYW4gSGFtbWVyLUxhaGF2PGJyPg0KPGI+U2Vu dDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZy aWRheSwgSmFudWFyeSAxNCwgMjAxMSAxMDo0NSBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+T0F1dGggV0c8YnI+DQo8Yj5T dWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+W09BVVRILVdHXSBSZW1vdmFsOiBDbGllbnQgQXNzZXJ0aW9uIENyZWRlbnRpYWxzPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5JIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB3ZSBkcm9wIHRoZSBjbGllbnQgYXNzZXJ0aW9uIGNy ZWRlbnRpYWxzICgtMTEgc2VjdGlvbiAzLjIpIGZyb20gdGhlIHNwZWNpZmljYXRpb24sIGFuZCBp ZiBuZWVkZWQsIHB1Ymxpc2ggaXQgYXMgYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUg Zm9sbG93aW5nDQogcmVhc29uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5UaGUNCiBtZWNoYW5pc20gaXMgdW5kZXIgc3BlY2lmaWVkLCBlc3Bl Y2lhbGx5IGluIGl0cyBoYW5kbGluZyBvZiB0aGUgY2xpZW50X2lkIGlkZW50aWZpZXIgKHdoZW4g dXNlZCB0byBvYnRhaW4gZW5kLXVzZXIgYXV0aG9yaXphdGlvbikuIEl0IGRvZXMgbm90IGNvbnRh aW4gYW55IGltcGxlbWVudGF0aW9uIGRldGFpbHMgdG8gYWNjb21wbGlzaCBhbnkgbGV2ZWwgb2Yg aW50ZXJvcGVyYWJpbGl0eSBvciBmdW5jdGlvbmFsaXR5LiBUaGlzIGlzIGluIGNvbnRyYXN0DQog dG8gdGhlIGFzc2VydGlvbiBncmFudCB0eXBlIHdoaWNoIGhhcyBtYXR1cmVkIG92ZXIgYSB5ZWFy IGludG8gYSBmdWxseSB0aG91Z2h0LW91dCBleHRlbnNpb24gbWVjaGFuaXNtLCBhcyB3ZWxsIGFz IGEgc2VwYXJhdGUgU0FNTCBhc3NlcnRpb24gc3BlY2lmaWNhdGlvbiB3aXRoIGFjdGl2ZSBkZXBs b3ltZW50ICh0aGUgdHdvLCB0b2dldGhlciB3aXRoIHJ1bm5pbmcgY29kZSwgc2hvdyBjbGVhciBj b25zZW5zdXMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjIuPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUNCiBzZWN0aW9uIGlzIGEgY29uZnVzZWQgbWl4 IG9mIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNwcmlua2xlZCB3aXRoIG5vcm1hdGl2ZSBsYW5n dWFnZS4gSW5zdGVhZCwgaXQgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggZ3VpZGVsaW5lcyBmb3Ig ZXh0ZW5kaW5nIHRoZSBzZXQgb2Ygc3VwcG9ydGVkIGNsaWVudCBjcmVkZW50aWFscywgYnV0IHdp dGhvdXQgZGVmaW5pbmcgYSBuZXcgcmVnaXN0cnkuIEl0IGlzIGNsZWFybHkgYW4gYXJlYSBvZiBs aXR0bGUNCiBkZXBsb3ltZW50IGV4cGVyaWVuY2UgZm9yIE9BdXRoLCBhbmQgdGhhdCBpbmNsdWRl cyB1c2luZyBIVFRQIEJhc2ljIGF1dGhlbnRpY2F0aW9uIGZvciBjbGllbnQgYXV0aGVudGljYXRp b24gKG1vcmUgb24gdGhhdCB0byBjb21lKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4zLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlDQogc2VjdGlvbiBo YXMgcmVjZWl2ZWQgYSBsaXR0bGUgc3VwcG9ydCBhbmQgYSBsaXR0bGUgb2JqZWN0aW9uLiBUaG9z ZSB3aG8gc3RpbGwgd2FudCB0byBhZHZvY2F0ZSBmb3IgaXQgbmVlZCB0byBzaG93IG5vdCBvbmx5 IGNvbnNlbnN1cyBmb3Iga2VlcGluZyBpdCwgYnV0IGFsc28gYWN0aXZlIGNvbW11bml0eSBzdXBw b3J0IGZvciBkZXBsb3lpbmcgaXQuIERlcGxveW1lbnQsIG9mIGNvdXJzZSwgd2lsbCBhbHNvIHJl cXVpcmUgc2hvd2luZyBwcm9ncmVzcw0KIG9uIHB1YmxpYyBzcGVjaWZpY2F0aW9ucyBwcm9maWxp bmcgdGhlIG1lY2hhbmlzbSBpbnRvIGEgdXNlZnVsIGludGVyb3BlcmFibGUgZmVhdHVyZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Q29tbWVudHM/IENvdW50ZXItYXJndW1lbnRzPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5FSEw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1 dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0 aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h dXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_180155C5EA10854997314CA5E063D18F033B2B0ETK5EX14MBXC111r_-- From phil.hunt@oracle.com Fri Jan 28 17:15:25 2011 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 880463A6975 for ; Fri, 28 Jan 2011 17:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.353 X-Spam-Level: X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[AWL=-0.951, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock25=0.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 x4U2gUXyO9jw for ; Fri, 28 Jan 2011 17:15:22 -0800 (PST) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 8509E3A68E4 for ; Fri, 28 Jan 2011 17:15:22 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p0T1IRiA004919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 29 Jan 2011 01:18:29 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p0SNsfRE009163; Sat, 29 Jan 2011 01:18:27 GMT Received: from abhmt006.oracle.com by acsmt354.oracle.com with ESMTP id 1004092441296263871; Fri, 28 Jan 2011 17:17:51 -0800 Received: from [192.168.1.8] (/24.87.204.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 28 Jan 2011 17:17:50 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-15-129088615 From: Phil Hunt In-Reply-To: <180155C5EA10854997314CA5E063D18F033B2B0E@TK5EX14MBXC111.redmond.corp.microsoft.com> Date: Fri, 28 Jan 2011 17:17:48 -0800 Message-Id: <042F375C-D09A-416D-9586-A63D5580855C@oracle.com> References: <90C41DD21FB7C64BB94121FBBC2E723445A5AB7F6C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033A7539@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D6250D@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033B0798@TK5EX14MBXC111.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8D62753@P3PW5EX1MB01.EX1.SECURESERVER.NET> <180155C5EA10854997314CA5E063D18F033B181B@TK5EX14MBXC111.redmond.corp.microsoft.com> <180155C5EA10854997314CA5E063D18F033B2B0E@TK5EX14MBXC111.redmond.corp.microsoft.com> To: Anthony Nadalin X-Mailer: Apple Mail (2.1082) Cc: OAuth WG Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials 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: Sat, 29 Jan 2011 01:15:25 -0000 --Apple-Mail-15-129088615 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks. I don't believe grant_type can or should indicate how a client = must authenticate. The two are unrelated (which is what I think you mean = by overloading). Especially since for any particular grant type one = could be supporting multiple different ways to authenticate a client. I know Eran has suggested that client developers would consult = deployment documentation. But I don't agree that this is sufficient. In a token request failure, if the client has failed to authenticate = (e.g. due to unsupported authentication type), the responses should be = a 401 Unauthorized) message indicating acceptable methods (assuming they = are all registered). This is more appropriate since the server did not = authenticate the client. It also follows the failure pattern of any = other web resource. Note: I would interpret "unauthorized_client" in 4.1.2.1 as meaning = client authenticated but not authorized to perform the operation. Typically clients should not get 401 unauthorized responses (since, as = Eran indicates, they usually know how to authenticate to begin with), = but it would be useful, especially if a deployed site changed it's = security policies or configuration.=20 Phil phil.hunt@oracle.com On 2011-01-28, at 4:02 PM, Anthony Nadalin wrote: > Code impact was that assertion_type was moved/changed to grant_type, = we actually need client_assertion and client_assertion_type and not have = to overload the grant_type as assertion_type, I can why this was done = for allowing one to use assertions in general for authentcations > =20 > From: Phil Hunt [mailto:phil.hunt@oracle.com]=20 > Sent: Friday, January 28, 2011 12:17 PM > To: Anthony Nadalin > Cc: Eran Hammer-Lahav; OAuth WG > Subject: Re: [OAUTH-WG] Removal: Client Assertion Credentials > =20 > Tony, > =20 > I'm not totally understanding what the issue is as far as impact on = code. My understanding was that the removal simply took it out of the = standard but is still covered by "other authentication mechanism". Thus = no impact on code -- you can still use (as we will) the client_assertion = form parameter. That said, I very much agree with your concerns. > =20 > It may be worthwhile for us to work on a profile that lays out the = specifics of using client_assertion or client_token in a separate = specification. Just as there will be multiple access token formats, I = expect to see multiple client authentication methods. Maybe client auth = methods should also be defined in a registry? Though, I don't see this = as necessarily an OAuth specific issue. There's a much broader = requirement for defining client auth beyond Basic, Digest, Mutual SSL, = etc for non-browser clients.=20 > =20 > As for value with OAuth, I think OAuth describe an important "pattern" = and won't have much general impact on inter-operability as a standard. = Thus doesn't undervalue the standard that much as it lays a foundation = for other components. The key working inter-op components will likely = have be defined in subsequent related specs such as suggested above. > =20 > What is not clear to me yet is what should the discovery and = registration components for OAuth be? How much should be defined in = deployment documentation? Deployment documentation is problematic for = development tools. For example, building a .Net or Java platform is much = different than a one time developer who just wants to access a single = google, facebook, etc service. In contrast, .Net/Java tools can't help = much since they can't inspect the service.=20 > =20 > I agree, too much emphasis is on deployment docs for use of OAuth. > =20 > Phil > phil.hunt@oracle.com > =20 >=20 >=20 > =20 > On 2011-01-28, at 11:55 AM, Anthony Nadalin wrote: >=20 >=20 > I said its =E2=80=9Cbecoming=E2=80=9D useless as more and more stuff = is being removed. > =20 > Maybe you did not understand or I did not tell you everything you = needed to know, we have endpoints that expect assertions along with the = grant_type of authorization_code and we also have endpoints that expect = the grant_type of URI (or the assertion, which could be whatever the = authorization server decides), these are 2 different endpoints with 2 = different functions. The change that was made to remove the notion of = client assertion credentials only left us with the extension so we can = live with the changes to the extension (it is a code change for us) but = not removal of client assertion credentials we can=E2=80=99t live with = as we are using the notion of client credentials. I=E2=80=99m not sure = that putting this in the bearer token specification would work. > =20 > =20 > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 > Sent: Wednesday, January 26, 2011 2:51 PM > To: Anthony Nadalin > Cc: OAuth WG > Subject: RE: Removal: Client Assertion Credentials > =20 > Can you explain how having to define *two* extension parameters makes = the specification useless? The bearer token specification is going to = define its corresponding WWW-Authenticate header, to match its already = defined Authorization header. The scheme name is just style and branding = and have absolutely no technical impact. I am honestly confused by your = comments, as I was in the past when you declared the entire protocol = useless because of my objections to an under-defined scope parameter. > =20 > Can you point me where in WRAP are the client assertion credentials = defined? I can only find the assertion profile which is comparable to = the extension grant type with the SAML assertion extension (where the = assertion parameter is defined and registered). The concept of the = client assertion used for client authentication (separate from the = authorization grant) is new and was added based on a proposal from Yaron = in -11 on December 1st, 2010. > =20 > As for your additional details below (thanks!), it seems like you are = not using the client assertion credentials at all but using a simple = extension grant with an assertion, exactly like the SAML extension grant = specification, only you are not limited to SAML 2.0. Is that correct? If = this is correct, then the only issue here is our decision (which was = made without any comment from you or those now raising issues about = this) to move the =E2=80=98assertion=E2=80=99 parameter and rename the = grant type from assertion to extension (which has no implementation = impact). All we did is relocate the assertion parameter because it = doesn=E2=80=99t always apply to extension grants. > =20 > Is this just a confusion about what was being removed and where it = went? > =20 > EHL > =20 > =20 > From: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 > Sent: Wednesday, January 26, 2011 1:52 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: RE: Removal: Client Assertion Credentials > =20 > Maybe this was the plan all along but specification is becoming = useless for our scenarios and will require that we have to go well = beyond the core specification to make things work, the client assertion = credentials being a prime example. The client assertion credentials has = been around for a while as it was a requirement for WRAP, then dropped = when the various specs got merged to form OAUTH 2.0 and then came back = into the OAUTH 2.0 and then has gone through various changes since = version 6 for the worse. There has been much discussion in July/August = over this and new text was proposed, but that seems to not be fully = accepted, but I think that follows the path when you want to remove = something. > =20 > Our usage will be via bearer token assertions only (at this time) > The grant_type would be the URI of the assertion type being used > The authorization endpoint can use what it wants to bind the assertion = to the client_id, much like it has to today for the password = authentication, as we have scenarios were client_id have multiple = passwords > We use guidance from security consideration section of the assertion = type being used along with the guidance from the bearer token = specification > If needed I can capture the assertions and requests, but not sure what = the point of this is at this time since this is not required for the = password credentials > =20 > Sure we can add the client authentication assertion to the bearer = token specification but I don=E2=80=99t think that is the proper place = to do thus but since it=E2=80=99s gone from the core we will have to do = just that. The same seems to happen with the HTTP Authentication Scheme = as it seems to be repeated in follow-on companion specifications. While = oauth-v2 is not an authentication protocol there is a requirement for = authentication to address security concerns. There is clear separation = between authentication and authorization; we are not suggesting that = authentication is appropriate facility to negotiate authorization. I = think that it makes sense to include a scheme in the core and have the = particular follow-on companion specifications (the various token = specifications) state/define the parameters and if they don=E2=80=99t = like the default scheme let them define a new scheme but this puts a = stake in the ground for an HTTP Authentication Scheme. > =20 > =20 > From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]=20 > Sent: Tuesday, January 25, 2011 5:38 PM > To: Anthony Nadalin > Cc: OAuth WG > Subject: RE: Removal: Client Assertion Credentials > =20 > Can you share with the list how you plan to use this client assertion = authentication scheme? > Which of the authorization grant types you will use it with? > Will you use it with the authorization endpoint, and if so, how will = you bind the assertion to the client_id? > Can you provide full examples of assertions and HTTP requests? > =20 > It would be helpful to see how far apart the proposed text below is = from an actual implementation making use of it. I except to see these = answers in any quality document defining a new client authentication = scheme (which is true for the client password authentication throughout = the document). > =20 > EHL > =20 > =20 > From: Anthony Nadalin [mailto:tonynad@microsoft.com]=20 > Sent: Tuesday, January 25, 2011 3:58 PM > To: Eran Hammer-Lahav; OAuth WG; Hannes.Tschofenig@gmx.net; Blaine = Cook > Subject: RE: Removal: Client Assertion Credentials > =20 > I don't understand the rationale for removing the client assertion = credentials, as client password authentication is left in. Client = Password Authentication is also underspecified as client_secret could be = anything that the authentication server seems fit (raw clear text = password, hash, digest, etc.) and no way to determine the content. = client_secret is also a very weak mechanism, since this is left in the = core this leads me to believe that there is support for having client = authentication in Oauth. I don't see how having client_assertion and = client_assertion_type would be something that is underspecified as being = a mechanism in which assertions can be used for authentication. Agree = that the authentication server has to make right and declare what is = being used but that is the same for client password authentication. The = client authentication assertions are something that Microsoft and Google = find useful and plan on implementing and using as a means for stronger = authentication to the authorization server. This extensibility belongs = in the core, there is no other place to put this functionality. I don't = believe that the removal (either by editor or direction by co-chair) is = something that should have been done w/o a consensus vote since this has = been in the specification for some time without issue and the removal = comes as complete unwelcome surprise. Getting almost total rewrites of = the specification this late in the review cycle is also very disturbing. > =20 > A proposal for keeping the client authentication assertion would be to = simplify to the following; > The client assertion credentials are used in cases where a password = (clear-text shared symmetric secret) is unsuitable or does not provide = sufficient security for client authentication. The client assertion = credentials provide an extensible mechanism to use an assertion format = supported by the authorization server for authentication of the client. > Using assertions requires the client to obtain an assertion (such as a = SAML (Cantor, S., Kemp, J., Philpott, R., and E. Maler, =E2=80=9CAssertion= s and Protocol for the OASIS Security Assertion Markup Language (SAML) = V2.0,=E2=80=9D March 2005.)[OASIS.saml=E2=80=91core=E2=80=912.0=E2=80=91os= ] assertion) from an assertion issuer or to self-issue an assertion. The = assertion format, the process by which the assertion is obtained, and = the method of validating the assertion are defined by the assertion = issuer and the authorization server, and are beyond the scope of this = specification. > When using a client assertion, the client includes the following = parameters: > client_assertion_type - REQUIRED. The format of the assertion as = defined by the authorization server. The value MUST be an absolute URI. > client_assertion - REQUIRED. The client assertion. > For example, the client sends the following access token request using = a SAML 2.0 assertion to authenticate itself (line breaks are for display = purposes only): > =20 > =20 > POST /token HTTP/1.1 > Host: server.example.com > Content-Type: application/x-www-form-urlencoded > =20 > grant_type=3Dauthorization_code&code=3Di1WsRn1uB1& > client_assertion=3DPHNhbWxwOl[...omitted for brevity...]ZT4%3D& > client_assertion_type=3D = urn%3Aoasis%3Anames%sAtc%3ASAML%3A2.0%3Aassertion&redirect_uri=3Dhttps%3A%= 2F%2Fclient%2Eexample%2Ecom%2Fcb > =20 > =20 > =20 > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Eran Hammer-Lahav > Sent: Friday, January 14, 2011 10:45 PM > To: OAuth WG > Subject: [OAUTH-WG] Removal: Client Assertion Credentials > =20 > I would like to suggest we drop the client assertion credentials (-11 = section 3.2) from the specification, and if needed, publish it as a = separate specification for the following reasons: > =20 > 1. The mechanism is under specified, especially in its handling = of the client_id identifier (when used to obtain end-user = authorization). It does not contain any implementation details to = accomplish any level of interoperability or functionality. This is in = contrast to the assertion grant type which has matured over a year into = a fully thought-out extension mechanism, as well as a separate SAML = assertion specification with active deployment (the two, together with = running code, show clear consensus). > 2. The section is a confused mix of security considerations = sprinkled with normative language. Instead, it should be replaced with = guidelines for extending the set of supported client credentials, but = without defining a new registry. It is clearly an area of little = deployment experience for OAuth, and that includes using HTTP Basic = authentication for client authentication (more on that to come). > 3. The section has received a little support and a little = objection. Those who still want to advocate for it need to show not only = consensus for keeping it, but also active community support for = deploying it. Deployment, of course, will also require showing progress = on public specifications profiling the mechanism into a useful = interoperable feature. > =20 > Comments? Counter-arguments? > =20 > EHL > =20 > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > =20 --Apple-Mail-15-129088615 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Typically = clients should not get 401 unauthorized responses (since, as Eran = indicates, they usually know how to authenticate to begin with), =  but it would be useful, especially if a deployed site changed it's = security policies or configuration. 


On 2011-01-28, at 4:02 PM, Anthony Nadalin wrote:

Code impact was that assertion_type was = moved/changed to grant_type, we actually need client_assertion and = client_assertion_type and not have to overload the grant_type as = assertion_type, I can why this was done for allowing one to use = assertions in general for authentcations
From: Phil Hunt = [mailto:phil.hunt@oracle.com] 
Sent: Friday, January 28, 2011 = 12:17 PM
To: Anthony = Nadalin
Cc: Eran Hammer-Lahav; OAuth = WG
Subject: Re: [OAUTH-WG] Removal: = Client Assertion Credentials
 
I'm not totally = understanding what the issue is as far as impact on code. My = understanding was that the removal simply took it out of the standard = but is still covered by "other authentication mechanism".  Thus no = impact on code -- you can still use (as we will) the client_assertion = form parameter. That said, I very much agree with your = concerns.
It may be worthwhile = for us to work on a profile that lays out the specifics of using = client_assertion or client_token in a separate specification. Just as = there will be multiple access token formats, I expect to see multiple = client authentication methods.  Maybe client auth methods should = also be defined in a registry? Though, I don't see this as necessarily = an OAuth specific issue. There's a much broader requirement for defining = client auth beyond Basic, Digest, Mutual SSL, etc for non-browser = clients. 
As for value with = OAuth, I think OAuth describe an important "pattern" and won't have much = general impact on inter-operability as a standard. Thus doesn't = undervalue the standard that much as it lays a foundation for other = components. The key working inter-op components will likely have be = defined in subsequent related specs such as suggested = above.
What is not clear to = me yet is what should the discovery and registration components for = OAuth be? How much should be defined in deployment documentation? = Deployment documentation is problematic for development tools. For = example, building a .Net or Java platform is much different than a one = time developer who just wants to access a single google, facebook, etc = service.  In contrast, .Net/Java tools can't help much since they = can't inspect the service. 
 
I agree, too much = emphasis is on deployment docs for use of = OAuth.
Phil




I said its =E2=80=9Cbecoming=E2=80=9D useless as = more and more stuff is being removed. Maybe you did not understand or I did not tell you = everything you needed to know, we have endpoints that expect assertions = along with the grant_type of authorization_code and we also have = endpoints that expect the grant_type of URI (or the assertion, which = could be whatever the authorization server decides), these are 2 = different endpoints with 2 different functions. The change that was made = to remove the notion of client assertion credentials only left us with = the extension so we can live with the changes to the extension (it is a = code change for us) but not removal of client assertion credentials we = can=E2=80=99t live with as we are using the notion of client = credentials. I=E2=80=99m not sure that putting this in the bearer token = specification would work.  
From:Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Wednesday, January 26, 2011 = 2:51 PM
To: Anthony = Nadalin
Cc: OAuth = WG
Subject: RE: Removal: Client = Assertion Credentials 
Can you explain how having to = define *two* extension parameters makes the specification = useless? The bearer token specification is going to define its = corresponding WWW-Authenticate header, to match its already defined = Authorization header. The scheme name is just style and branding and = have absolutely no technical impact. I am honestly confused by your = comments, as I was in the past when you declared the entire protocol = useless because of my objections to an under-defined scope = parameter.
 Can you point me where in WRAP are the client = assertion credentials defined? I can only find the assertion profile = which is comparable to the extension grant type with the SAML assertion = extension (where the assertion parameter is defined and registered). The = concept of the client assertion used for client authentication (separate = from the authorization grant) is new and was added based on a proposal = from Yaron in -11 on December 1st, 2010. As for your additional details below (thanks!), it = seems like you are not using the client assertion credentials at all but = using a simple extension grant with an assertion, exactly like the SAML = extension grant specification, only you are not limited to SAML 2.0. Is = that correct? If this is correct, then the only issue here is our = decision (which was made without any comment from you or those now = raising issues about this) to move the =E2=80=98assertion=E2=80=99 = parameter and rename the grant type from assertion to extension (which = has no implementation impact). All we did is relocate the assertion = parameter because it doesn=E2=80=99t always apply to extension = grants.
 Is this just a confusion about what was being = removed and where it went? EHL  
From:Anthony Nadalin [mailto:tonynad@microsoft.com] 
Sent: Wednesday, January 26, 2011 = 1:52 PM
To: Eran = Hammer-Lahav
Cc: OAuth = WG
Subject: RE: Removal: Client = Assertion Credentials 
Maybe this was the plan all along = but specification is becoming useless for our scenarios and will require = that we have to go well beyond the core specification to make things = work, the client assertion credentials being a prime example. The client = assertion credentials has been around for a while as it was a = requirement for WRAP, then dropped when the various specs got merged to = form OAUTH 2.0 and then came back into the OAUTH 2.0 and then has gone = through various changes since version 6 for the worse. There has been = much discussion in July/August over this and new text was proposed, but = that seems to not be fully accepted, but I think that follows the path = when you want to remove something. Our usage will be via bearer token assertions only = (at this time)
The grant_type would be the URI = of the assertion type being usedThe authorization endpoint can use what it wants to = bind the assertion to the client_id, much like it has to today for the = password authentication, as we have scenarios were client_id have = multiple passwords
We use guidance from security = consideration section of the assertion type being used along with the = guidance from the bearer token specificationIf needed I can capture the assertions and requests, = but not sure what the point of this is at this time since this is not = required for the password credentials Sure we can add the client authentication assertion = to the bearer token specification but I don=E2=80=99t think that is the = proper place to do thus but since it=E2=80=99s gone from the core we = will have to do just that. The same seems to happen with the HTTP = Authentication Scheme as it seems to be repeated in follow-on companion = specifications. While oauth-v2 is not an authentication protocol there = is a requirement for authentication to address security concerns. There = is clear separation between authentication and authorization; we are not = suggesting that authentication is appropriate facility to negotiate = authorization. I think that it makes sense to include a scheme in the = core and have the particular follow-on companion specifications (the = various token specifications) state/define the parameters and if they = don=E2=80=99t like the default scheme let them define a new scheme but = this puts a stake in the ground for an HTTP Authentication = Scheme.
  
From:Eran Hammer-Lahav [mailto:eran@hueniverse.com] 
Sent: Tuesday, January 25, 2011 = 5:38 PM
To: Anthony = Nadalin
Cc: OAuth = WG
Subject: RE: Removal: Client = Assertion Credentials 
Can you share with the list how = you plan to use this client assertion authentication scheme?Which of the authorization grant types you will use = it with?
Will you use it with the = authorization endpoint, and if so, how will you bind the assertion to = the client_id?
Can you provide full examples of = assertions and HTTP requests? It would be helpful to see how far apart the = proposed text below is from an actual implementation making use of it. I = except to see these answers in any quality document defining a new = client authentication scheme (which is true for the client password = authentication throughout the document). EHL  
From:Anthony Nadalin [mailto:tonynad@microsoft.com] 
Sent: Tuesday, January 25, 2011 = 3:58 PM
To: Eran Hammer-Lahav; OAuth = WG; Hannes.Tschofenig@gmx.net; Blaine = Cook
Subject: RE: Removal: Client = Assertion Credentials 
I don't understand the rationale for removing the client = assertion credentials, as client password authentication is left in. = Client Password Authentication is also underspecified as client_secret = could be anything that the authentication server seems fit (raw clear = text password,  hash, digest, etc.) and no way to determine the = content. client_secret is also a very weak mechanism, since this is left = in the core this leads me to believe that there is support for having = client authentication in Oauth. I don't see how having client_assertion = and client_assertion_type would be something that is underspecified as = being a mechanism in which assertions can be used for authentication. = Agree that the authentication server has to make right and declare what = is being used but that is the same for client password authentication. = The client authentication assertions are something that Microsoft and = Google find useful and plan on implementing and using as a means for = stronger authentication to the authorization server. This extensibility = belongs in the core, there is no other place to put this functionality. = I don't believe that the removal (either by editor or direction by = co-chair) is something that should have been done w/o a consensus vote = since this has been in the specification for some time without issue and = the removal comes as complete unwelcome surprise. Getting almost total = rewrites of the specification this late in the review cycle is also very = disturbing.
A proposal = for keeping the client authentication assertion would be to simplify to = the following;

The client = assertion credentials are used in cases where a password (clear-text = shared symmetric secret) is unsuitable or does not provide sufficient = security for client authentication. The client assertion credentials = provide an extensible mechanism to use an assertion format supported by = the authorization server for authentication of the = client.

Using assertions requires the = client to obtain an assertion (such as a SAML (Cantor, S., Kemp, = J., Philpott, R., and E. Maler, =E2=80=9CAssertions and Protocol for the = OASIS Security Assertion Markup Language (SAML) V2.0,=E2=80=9D = March 2005.)[OASIS.saml=E2=80=91core=E2=80=912.0=E2= =80=91os] assertion) from an assertion issuer or to self-issue an = assertion. The assertion format, the process by which the assertion is = obtained, and the method of validating the assertion are defined by the = assertion issuer and the authorization server, and are beyond the scope = of this specification.

When using a = client assertion, the client includes the following = parameters:

client_assertion_type = - REQUIRED. The format of the assertion as defined by the authorization = server. The value MUST be an absolute URI.
client_assertion = - REQUIRED. The client assertion.

server.example.com
  Content-Type: =
application/x-www-form-urlencoded
  =
client_assertion=3DPHNhbWxwOl[...omitted for =
brevity...]ZT4%3D&
  
From: [mailto:oauth-bounces@ietf.org] On Behalf Of Eran =
Hammer-Lahav
Sent: Friday, January 14, 2011 =
10:45 PM
To: OAuth =
WG
Subject: [OAUTH-WG] Removal: Client =
Assertion Credentials 
I would like to suggest we drop the client assertion =
credentials (-11 section 3.2) from the specification, and if needed, =
publish it as a separate specification for the following =
reasons:
1.       The =
mechanism is under specified, especially in its handling of the =
client_id identifier (when used to obtain end-user authorization). It =
does not contain any implementation details to accomplish any level of =
interoperability or functionality. This is in contrast to the assertion =
grant type which has matured over a year into a fully thought-out =
extension mechanism, as well as a separate SAML assertion specification =
with active deployment (the two, together with running code, show clear =
consensus).
2.       The =
section is a confused mix of security considerations sprinkled with =
normative language. Instead, it should be replaced with guidelines for =
extending the set of supported client credentials, but without defining =
a new registry. It is clearly an area of little deployment experience =
for OAuth, and that includes using HTTP Basic authentication for client =
authentication (more on that to come).
 The =
section has received a little support and a little objection. Those who =
still want to advocate for it need to show not only consensus for =
keeping it, but also active community support for deploying it. =
Deployment, of course, will also require showing progress on public =
specifications profiling the mechanism into a useful interoperable =
feature.
Comments? =
Counter-arguments?
 
EHL
 
 
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 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: Sun, 30 Jan 2011 19:33:23 -0000 Representing a provider who will be issuing both bearer and mac token = types, I'll state a preference on behalf of clarity for our developers = to use the "oauth_" prefix for both specifications. Both types will be = referred to as "OAuth" tokens in developer documentation regardless of = specification history or independence-by-extension, so having "OAuth = Bearer Tokens" identified as "OAuth2" and "OAuth Mac Tokens" identified = by "MAC" is mildly confusing, thought nowhere near impossible for = implementers to manage. On the plus side, it adds extra value as = slide-ware during future OAuth talks where=20 =09 "OAuth Bearer" -> "OAuth2" "OAuth MAC" -> "MAC" As I don't understand all the implications or the processes of the = working groups regarding such a change, take the feedback for what you = perceive its worth to be. Though a breaking change, a simple consideration for a provider who has = already supported this is to accept both "OAuth2" and the revised = standard as identifiers for backwards compatibility. Given the current = volatility of the token drafts, this is already a consideration we've = made. On Jan 29, 2011, at 12:59 AM, William Mills wrote: > At that point though we did not have multiple token types. Now that = we do we should make the naming scheme reflect that. OAuth2 implies = =93the one and only=94. > =20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 > Sent: Friday, January 28, 2011 3:08 PM > To: William Mills; oauth@ietf.org > Subject: RE: OAuth 2.0 Bearer Token Specification draft -02 > =20 > The argument in favor of =93OAuth2=94 is a consistency argument. Just = as this parameter was called =93WRAP=94 in the WRAP spec and called = =93OAuth=94 in the OAuth specs through draft 10 until it was moved to = the OAuth2 bearer token spec, it should logically be called =93OAuth2=94 = to remain consistent with the precursor specifications. Also, since the = use of bearer tokens is the primary OAuth2 use case (it was the = motivating use case for WRAP, which was the reason for a second version = of OAuth in the first place), it makes sense for this primary use case = bear the primary specification name. > =20 > I=92m not religious about this (I already asked for working group on = this topic a while ago and received very little), but absent a clear = working group consensus to change the name, as editor, I believe that = it=92s my job to not introduce breaking changes at this point in the = specification development cycle. > =20 > = Cheers, > -- = Mike > =20 > From: William Mills [mailto:wmills@yahoo-inc.com]=20 > Sent: Friday, January 28, 2011 2:54 PM > To: Mike Jones; oauth@ietf.org > Subject: RE: OAuth 2.0 Bearer Token Specification draft -02 > =20 > I=92d like to add my objection to using =93OAuth2=94 as the scheme = name for the access token. It=92s confusing in my opinion. I would = much prefer (in my own order of preference): =93 oauth_bearer=94, = =93oauth2_bearer=94, or =93bearer=94. I think including OAuth in the = name makes sense because it is defined in that context, but we=92ve = already talked about other possible token types.=20 > =20 > Is there any argument in favor of simply using =93OAuth2=94 that = offsets the possible confusion and muddiness? > =20 > -bill > =20 > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf = Of Mike Jones > Sent: Friday, January 28, 2011 1:36 PM > To: oauth@ietf.org > Subject: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -02 > =20 > I=92ve published draft 02 of the bearer token specification. This = incorporates consensus feedback received to date. It contains no = normative changes relative to draft 01. Your feedback is solicited. = Specific changes were: > =B7 Changed terminology from "token reuse" to "token capture = and replay". > =B7 Removed sentence "Encrypting the token contents is another = alternative" from the security considerations since it was redundant and = potentially confusing. > =B7 Corrected some references to "resource server" to be = "authorization server" in the security considerations. > =B7 Generalized security considerations language about = obtaining consent of the resource owner. > =B7 Broadened scope of security considerations description for = recommendation "Don't pass bearer tokens in page URLs". > =B7 Removed unused reference to OAuth 1.0. > =B7 Updated reference to framework specification and updated = David Recordon's e-mail address. > =B7 Removed security considerations text on authenticating = clients. > =B7 Registered the "OAuth2" OAuth access token type and = "oauth_token" parameter. > =20 > The draft is available at these locations: > =B7 = http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.txt > =B7 = http://www.ietf.org/internet-drafts/draft-ietf-oauth-v2-bearer-02.xml > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.html > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.txt > =B7 = http://self-issued.info/docs/draft-ietf-oauth-v2-bearer-02.xml > =B7 http://svn.openid.net/repos/specifications/oauth/2.0/ = (Subversion repository, with html, txt, and html versions available) > =20 > This version is explicitly not ready for working group last call, as = changes may need to be made due to the open issues in the framework spec = about the removal of the Client Assertion Credentials and OAuth2 HTTP = Authentication Scheme. > =20 > -- = Mike > =20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From mscurtescu@google.com Sun Jan 30 14:27:25 2011 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 910113A6881 for ; Sun, 30 Jan 2011 14:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.003 X-Spam-Level: X-Spam-Status: No, score=-104.003 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 tk1tXXGfp0II for ; Sun, 30 Jan 2011 14:27:24 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 5C88A3A6849 for ; Sun, 30 Jan 2011 14:27:24 -0800 (PST) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p0UMUZ5S008609 for ; Sun, 30 Jan 2011 14:30:35 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296426635; bh=QW05pTqDzsKeXwAgFviMfVuMv28=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=UtdF3Vl+W6mt02ygtdI4aNlfc+R/FEU+pQMKrJ8eJwF48/q9ADxCn0l9LZmX5ZeoU zjNr+zuN5Aci/Poyz6DoQ== Received: from gwj23 (gwj23.prod.google.com [10.200.10.23]) by hpaq7.eem.corp.google.com with ESMTP id p0UMUIJL013499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 30 Jan 2011 14:30:34 -0800 Received: by gwj23 with SMTP id 23so2821566gwj.15 for ; Sun, 30 Jan 2011 14:30:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=tnP2QapAYwUVnRDavg1jtMdUCT2Pqe/8SjQ2h4EJyDQ=; b=jS1QOSg7qWHFPSaW7EgUnUFWkh4QJ3fsL54GOJDK+db3EfxtwOs4qXKX78Fvl+ob2q zQUY0g50ho+eolTDVQhg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; b=WILrQXapGnPe5pOcYBlTmeXxGwwYqtmV/xOBC/1vfUKa5QeE5ETrtJH0f/CEZLlhoV 3UxW76LiqOrnmLQCeT9w== Received: by 10.100.96.13 with SMTP id t13mr3454648anb.112.1296426634404; Sun, 30 Jan 2011 14:30:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Sun, 30 Jan 2011 14:30:14 -0800 (PST) From: Marius Scurtescu Date: Sun, 30 Jan 2011 14:30:14 -0800 Message-ID: To: OAuth WG Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Subject: [OAUTH-WG] assertion, client_assertion_type and client_assertion 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: Sun, 30 Jan 2011 22:27:25 -0000 I would like to bring up one more argument to keep the assertion, client_assertion_type and client_assertion parameters in core. If I understood correctly, the main argument to remove them from core was that they are underspecified and extensions are needed anyhow before they are useful. First of all, this is not true for client_assertion_type and client_assertion. A client can acquire assertions from an IdP that works intimately with the client. In this case the client knows how to get a client assertion and then how to present it to the Authorization Server, but it really does not need to know anything more. The IdP and the Authorization Server do need to agree on format and keys, but not the client. I agree that this is a less used use case, and that currently there are no implementations to point at (as far as I know), but there is another reason to keep these parameters in core. The assertion parameter was in core, but it was removed and now it is defined by SAML 2.0 Bearer Assertion Grant Type Profile. What will the next assertion extension do, let's say JWT? It can either re-define the assertion parameter or it can reference SAML 2.0 Bearer. Does re-defining imply registration as well? How would that work? Having JWT depend on SAML does not make much sense. While the above issue is minor, I think it would be useful if core defined these parameters as extension points. Marius From mscurtescu@google.com Sun Jan 30 14:42:19 2011 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 5E7693A6B43 for ; Sun, 30 Jan 2011 14:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.958 X-Spam-Level: X-Spam-Status: No, score=-103.958 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 pO+y+MDF9cw5 for ; Sun, 30 Jan 2011 14:42:18 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by core3.amsl.com (Postfix) with ESMTP id 2E8623A6B41 for ; Sun, 30 Jan 2011 14:42:18 -0800 (PST) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p0UMjUiC012316 for ; Sun, 30 Jan 2011 14:45:30 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1296427530; bh=h/ffY83oOF6qFOJWWwNJoceqm2c=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=ud3trhVix8FJ7rAEDUD7qGtPXCW+pDEB/Pq3v7a4Vyh1m/jrNawy3O3W6RT7QfRpA IIwUCYr73LPkI99MVMxjg== Received: from gxk4 (gxk4.prod.google.com [10.202.11.4]) by hpaq2.eem.corp.google.com with ESMTP id p0UMjSut003269 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 30 Jan 2011 14:45:29 -0800 Received: by gxk4 with SMTP id 4so1944520gxk.35 for ; Sun, 30 Jan 2011 14:45:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=xFfRy2aAjQjITy409frKgg1E8nXf9gmYT7l81AUBgag=; b=wLjVEahChxtXyRQGdsp5IpSBhzU3bUOi7tk0wO8vPjutqotIjQv4s7hvCQBgY0dgjo rueb+wcDTQGHIUmtgQBg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=XitT639Lwvep6rYVxOMd+TBzxIGhmYQA7Nzif2aKj+YeUy5gkEBefhbtdUG6I1z5dR 4Dcxr8phCZDUQQuPfoXQ== Received: by 10.101.71.2 with SMTP id y2mr3470517ank.78.1296427527951; Sun, 30 Jan 2011 14:45:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.153.9 with HTTP; Sun, 30 Jan 2011 14:45:07 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FBB0C@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Marius Scurtescu Date: Sun, 30 Jan 2011 14:45:07 -0800 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] Update required for bearer token spec 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: Sun, 30 Jan 2011 22:42:19 -0000 On Thu, Jan 27, 2011 at 6:23 PM, Eran Hammer-Lahav wr= ote: > As for the open issues: the bearer token scheme name - if it wasn=92t cle= ar, I > plan to use every mean available to me to block the bearer token draft fr= om > using the =91OAuth2=92 scheme name, and will raise this issue in the WGLC= , Area > Director review, IETF LC, and direct appeal to the IESG if necessary. You > might consider this childish, but I consider =A0bearer tokens a disaster > waiting to happen and will not allow the weakest form of token > authentication to carry the strongest form of endorsement and perception > (via the OAuth brand). I do respect your opinion Eran, but is there consensus around this? If anything, the consensus seems to be around bearer tokens. As far as I can tell this is the big selling point of OAuth 2 and all implementations I am aware of will support it. For all intents and purposes OAuth 2 is bearer tokens. > At the end, you might get the scheme name you want, but it will cost you > significant delays in getting that document published as an RFC and with = a > Proposed Standard designation. So far you have failed to raise any techni= cal > justification for your insistence of using that name. The only reason so = far > is that it will be less confusing. Perhaps. But will be more damaging. Such delays would be unfortunate, I truly hope we can sort this out. > After > all, why would anyone look at the MAC token specification or other strong= er > authentication schemes, when you offer them the =93official=94 OAuth 2.0 = scheme. That's a good point. What about using a common prefix for all OAuth 2 related scheme names? Something like "OAuth2Bearer", "OAuth2Mac". Marius From eran@hueniverse.com Sun Jan 30 14:54:56 2011 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 A7F413A6B58 for ; Sun, 30 Jan 2011 14:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 b8jNny7ao0Ib for ; Sun, 30 Jan 2011 14:54:55 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 4ABB43A6B3A for ; Sun, 30 Jan 2011 14:54:55 -0800 (PST) Received: (qmail 18119 invoked from network); 30 Jan 2011 22:58:07 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 30 Jan 2011 22:58:07 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 30 Jan 2011 15:58:07 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu , OAuth WG Date: Sun, 30 Jan 2011 15:58:04 -0700 Thread-Topic: [OAUTH-WG] assertion, client_assertion_type and client_assertion Thread-Index: AcvAzVPy+KkSQbcjToSW6fMAr3HQ+wAAWeJQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2B14@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OAUTH-WG] assertion, client_assertion_type and client_assertion 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: Sun, 30 Jan 2011 22:54:56 -0000 Hey Marius, It is critical for us to discuss the client assertion credentials separatel= y from the assertion authorization grant. The two have nothing to do with o= ne another. EHL > -----Original Message----- > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Sunday, January 30, 2011 2:30 PM > To: OAuth WG > Subject: [OAUTH-WG] assertion, client_assertion_type and client_assertion >=20 > I would like to bring up one more argument to keep the assertion, > client_assertion_type and client_assertion parameters in core. >=20 > If I understood correctly, the main argument to remove them from core was > that they are underspecified and extensions are needed anyhow before > they are useful. This is true for the client assertion credentials. The assertion parameter = was moved because was previously defined, it was a required parameter when = using any extension grant type. This was incorrect because not all extensio= n grant types are assertion-based. Assertions are no longer directly discus= sed. > First of all, this is not true for client_assertion_type and client_asser= tion. A > client can acquire assertions from an IdP that works intimately with the = client. > In this case the client knows how to get a client assertion and then how = to > present it to the Authorization Server, but it really does not need to kn= ow > anything more. The IdP and the Authorization Server do need to agree on > format and keys, but not the client. This IdP entity does not exists in the specification. It's a new role. Beca= use 99% of the work involved in using such a client assertion is determined= elsewhere, the value of defining the two parameters (and nothing else) is = minimal, but the confusion and complexity it brings are non-trivial. Just c= onsider writing a useful security consideration section for this alternativ= e flow. My main issue is the lack of specificity with regard to the client identifi= er and how it maps to the assertion. Since no assertion format is defined, = it is impossible to define the means for the client to provide its client i= dentifier within the assertion. There are many ways to solve this, and I ex= pect to see this address in a new draft. Note that I am not objecting to including such functionality, only the curr= ently underspecified language. This is why I have been asking repeatedly fo= r someone to submit a complete text (I posted the criteria for what will ma= ke it complete earlier) for WG consideration. This text may be integrated b= ack into the specification before publication. But depends completely on a = new text winning consensus. > I agree that this is a less used use case, and that currently there are n= o > implementations to point at (as far as I know), but there is another reas= on to > keep these parameters in core. This other reason has nothing to do with the client assertion credentials..= . > The assertion parameter was in core, but it was removed and now it is > defined by SAML 2.0 Bearer Assertion Grant Type Profile. What will the ne= xt > assertion extension do, let's say JWT? It can either re-define the assert= ion > parameter or it can reference SAML 2.0 Bearer. Does re-defining imply > registration as well? How would that work? Having JWT depend on SAML > does not make much sense. It makes no sense to define this parameter in the authorization specificati= on because assertions are no longer discussed. It would be a very odd and o= ut of context definition. The appropriate solution here is for the SAML spe= cification to change its definition of the assertion parameter to be more g= enerally applicable. For example: assertion REQUIRED. The assertion used to obtain an access token. The value= of the assertion parameter MUST contain a single assertion. When used wit= h the http://oauth.net/grant_type/assertion/saml/2.0/bearer" grant type= , the assertion MUST be a SAML 2.0 Assertion. The SAML 2.0 Assertion XM= L data MUST be encoded using base64url, where the encoding adheres to the definition in Section 5 of RFC4648 [RFC4648] and where the padding bits are set to zero. To avoid the need for subsequent encoding steps (by "application/ x-www-form-urlencoded" [W3C.REC-html401-19991224], for example), the base64url encoded data SHOULD NOT be line wrapped and pad characters ("=3D") SHOULD NOT be included. This way, other specifications can simply use this parameter as-is without = any additional registrations or updates. > While the above issue is minor, I think it would be useful if core define= d > these parameters as extension points. >=20 > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From eran@hueniverse.com Sun Jan 30 15:05:22 2011 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 0C59E3A6B3A for ; Sun, 30 Jan 2011 15:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 yVkWn9LjGJYy for ; Sun, 30 Jan 2011 15:05:21 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 050E53A6B33 for ; Sun, 30 Jan 2011 15:05:20 -0800 (PST) Received: (qmail 18955 invoked from network); 30 Jan 2011 23:08:33 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 30 Jan 2011 23:08:33 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 30 Jan 2011 16:08:22 -0700 From: Eran Hammer-Lahav To: Marius Scurtescu Date: Sun, 30 Jan 2011 16:08:20 -0700 Thread-Topic: [OAUTH-WG] Update required for bearer token spec Thread-Index: AcvAz2a1dsWgo23tSPSYXICbTd6dxAAAdKQg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2B15@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2785@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FB43B@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB27C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B1680429673943246FBB0C@TK5EX14MBXC202.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723445A8FB281B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: OAuth WG Subject: Re: [OAUTH-WG] Update required for bearer token spec 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: Sun, 30 Jan 2011 23:05:22 -0000 Hey Marius, > -----Original Message----- > From: Marius Scurtescu [mailto:mscurtescu@google.com] > Sent: Sunday, January 30, 2011 2:45 PM > To: Eran Hammer-Lahav > Cc: Mike Jones; OAuth WG > Subject: Re: [OAUTH-WG] Update required for bearer token spec >=20 > On Thu, Jan 27, 2011 at 6:23 PM, Eran Hammer-Lahav > wrote: > > As for the open issues: the bearer token scheme name - if it wasn't > > clear, I plan to use every mean available to me to block the bearer > > token draft from using the 'OAuth2' scheme name, and will raise this > > issue in the WGLC, Area Director review, IETF LC, and direct appeal to > > the IESG if necessary. You might consider this childish, but I > > consider =A0bearer tokens a disaster waiting to happen and will not > > allow the weakest form of token authentication to carry the strongest > > form of endorsement and perception (via the OAuth brand). >=20 > I do respect your opinion Eran, but is there consensus around this? If > anything, the consensus seems to be around bearer tokens. As far as I can > tell this is the big selling point of OAuth 2 and all implementations I a= m aware > of will support it. There is no consensus around names. My project does not support bearer token so at least one Yahoo! product API= is going to ban bearer tokens. We have published an open source client and= server MAC token implementation in JS and node.js. I do not speak on behal= f of the rest of the company, and given past opinion, expect them to suppor= t bearer tokens. > For all intents and purposes OAuth 2 is bearer tokens. And this is the issue! It is exactly why I am being so forceful against thi= s perception and why I refuse to allow the bearer token to be named the OAu= th2 token type. This will have the exact effect you have stated. Where I di= sagree with you is that this is a foregone conclusion. I am committed to the message that bearer tokens are a feature of OAuth 2.0= , and when implemented correctly can provide a security level adequate for = any current web services. I am opposed to any perception of bearer tokens a= s the default type, implying that people should always start with bearer to= ken and "upgrade" to something stronger only when needed. > > At the end, you might get the scheme name you want, but it will cost > > you significant delays in getting that document published as an RFC > > and with a Proposed Standard designation. So far you have failed to > > raise any technical justification for your insistence of using that > > name. The only reason so far is that it will be less confusing. Perhaps= . But > will be more damaging. >=20 > Such delays would be unfortunate, I truly hope we can sort this out. I will follow up with a proposal later today and will get a discussion goin= g. =20 > > After > > all, why would anyone look at the MAC token specification or other > > stronger authentication schemes, when you offer them the "official" > OAuth 2.0 scheme. >=20 > That's a good point. What about using a common prefix for all OAuth 2 > related scheme names? Something like "OAuth2Bearer", "OAuth2Mac". I don't see value in limiting MAC to OAuth. It is a generally useful scheme= , especially for "2-legged" authentication as used with 1.0. I'll cover these suggestions in my new discussion thread. Thanks for the feedback. EHL From bcampbell@pingidentity.com Mon Jan 31 06:13:32 2011 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 5480E3A6C04 for ; Mon, 31 Jan 2011 06:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.755 X-Spam-Level: X-Spam-Status: No, score=-5.755 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 zn31FHsyCrvF for ; Mon, 31 Jan 2011 06:13:31 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with ESMTP id 8EAE53A6BFA for ; Mon, 31 Jan 2011 06:13:29 -0800 (PST) Received: from source ([209.85.161.41]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTUbESayjy0cWCAL28ixQD4/Q5xLb4McD@postini.com; Mon, 31 Jan 2011 06:16:45 PST Received: by mail-fx0-f41.google.com with SMTP id 12so6662922fxm.14 for ; Mon, 31 Jan 2011 06:16:41 -0800 (PST) Received: by 10.223.101.135 with SMTP id c7mr1101359fao.76.1296483401416; Mon, 31 Jan 2011 06:16:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.9 with HTTP; Mon, 31 Jan 2011 06:16:11 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2B14@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723445A8FB2B14@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: Brian Campbell Date: Mon, 31 Jan 2011 07:16:11 -0700 Message-ID: To: Eran Hammer-Lahav Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: OAuth WG Subject: Re: [OAUTH-WG] assertion, client_assertion_type and client_assertion 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: Mon, 31 Jan 2011 14:13:32 -0000 I'm happy to make that change. But is it really necessary? The assertion parameter in draft-ietf-oauth-saml2-bearer is defined in the context of using the "http://oauth.net/grant_type/assertion/saml/2.0/bearer" grant type. Couldn't it be argued that other URI grant types could make use of it without issue or conflict? Does this suggest that the registry isn't granular enough? It seems the definition of the assertion parameter in the context of a new grant type should probably prohibit its use in other extension mechanisms that might be used along side the grant but not in other grant definitions (AFAIK, there's no way to present two grants at the same time). On Sun, Jan 30, 2011 at 3:58 PM, Eran Hammer-Lahav wr= ote: >> -----Original Message----- >> Marius Scurtescu >> >> The assertion parameter was in core, but it was removed and now it is >> defined by SAML 2.0 Bearer Assertion Grant Type Profile. What will the n= ext >> assertion extension do, let's say JWT? It can either re-define the asser= tion >> parameter or it can reference SAML 2.0 Bearer. Does re-defining imply >> registration as well? How would that work? Having JWT depend on SAML >> does not make much sense. > > It makes no sense to define this parameter in the authorization specifica= tion because assertions are no longer discussed. It would be a very odd and= out of context definition. The appropriate solution here is for the SAML s= pecification to change its definition of the assertion parameter to be more= generally applicable. For example: > > =A0 assertion > =A0 =A0 =A0 =A0 REQUIRED. =A0The assertion used to obtain an access token= . The value of the > =A0 =A0 =A0 =A0 assertion parameter MUST contain a single assertion. When= used with the > =A0 =A0 =A0 =A0 http://oauth.net/grant_type/assertion/saml/2.0/bearer" = =A0grant type, the > =A0 =A0 =A0 =A0 assertion MUST be a SAML 2.0 Assertion. =A0The SAML 2.0 A= ssertion XML data > =A0 =A0 =A0 =A0 MUST be encoded using base64url, where the encoding adher= es to the > =A0 =A0 =A0 =A0 definition in Section 5 of RFC4648 [RFC4648] and where th= e > =A0 =A0 =A0 =A0 padding bits are set to zero. =A0To avoid the need for > =A0 =A0 =A0 =A0 subsequent encoding steps (by "application/ > =A0 =A0 =A0 =A0 x-www-form-urlencoded" [W3C.REC-html401-19991224], for > =A0 =A0 =A0 =A0 example), the base64url encoded data SHOULD NOT be line w= rapped > =A0 =A0 =A0 =A0 and pad characters ("=3D") SHOULD NOT be included. > > This way, other specifications can simply use this parameter as-is withou= t any additional registrations or updates.
A correction to my previous message below: a = holder-of-key assertion can be sent in what seems to be a single message if= the message is sent over a TLS connection and the assertion is about the k= ey pair used in the connection.  Of course that's not really a single = message, because there are multiple messages involved in the TLS handshake,= and it's precisely the TLS handshake that shows that the subject it is the= holder of the private key.

Specifically, an assertion sent in the b= ody of an HTTP POST request over a TLS connection can be used to bind a cer= tificate used as TLS client certificate to additional data about the subjec= t of the certificate.  And an assertion sent in the body of a response= to an HTTP request over a TLS connection can be used to bind the certifica= te used as TLS server certificate to additional data about the subject of t= he certificate.

Francisco

--- On Sat, 1/22/11, Francisco Cor= ella <fcorella@pomcor.com> wrote:

From: Francisco Corella <fcorella@pomcor.com>
Subject: Re:= [OAUTH-WG] Reasons not to remove Client Assertion Credentials and OAuth2 H= TTP Authentication Scheme
To: oauth@ietf.org
Cc: "Karen P. Lewison" &= lt;kplewison@pomcor.com>
Date: Saturday, January 22, 2011, 6:28 AM
Brian,
> I guess it's somewhat moot now because client assertions
> = have been removed from the latest draft.  However, I don't
> bel= ieve there anything saying that client assertions had to
> be bearer = assertions.  Nor would that really have been
> appropriate for t= he framework spec.

Ah, so I was right in thinking there was something = wrong :-)

You can only use a bearer assertion (or "could" since
a= ssertions are no longer in the spec). 

If a subject (here, the= client) authenticates itself by
sending a single message that contains = an assertion, the
assertion cannot be a holder-of-key assertion.  A=
holder-of-key assertion is an assertion about the holder of
a privat= e key whose corresponding public key or certificate
is contained in the = assertion.  The subject must=0A confirm
that it has the private key= .  The subject typically does
that by signing a nonce supplied by t= he relying party (here,
the authorization server).  That party must= send the nonce
in an earlier protocol message.

Actually, an asse= rtion that authenticates the subject by the
mere fact of being presented= by the subject is, by
definition, a bearer assertion.  That's what= "bearer"
means.  It means "this assertion is about whoever bearsit (carries it, produces it); the bearer does not have to
present any = other proof if its identity".

> The same is true for extension/UR= I grant types (formerly
> known as assertion grant types).  Ther= e is nothing in the
> core OAuth framework spec saying that it is, or= has to be, a
> bearer assertion.  The SAML Bearer Assertion Gra= nt Type
> Profile is an extension spec that constrains/defines the> specific use of bearer=0A SAML assertion.  To me and some
>= ; others, that seemed like a useful enough use-case to write
> an I-D= for, however, the main OAuth spec allows for other
> extensions.&nbs= p; A holder of key SAML Assertion, for example,
> might be profiled a= s a grant type.  Or something completely
> non SAML based.
The same would be true for obtaining an access token by
presenting a S= AML assertion as an access grant.  It would
have to be a bearer ass= ertion, not a holder-of-key
assertion.

As for a non-SAML token, i= t would have to be a bearer token,
by definition of the word "bearer".&n= bsp; But it's not just a
matter of definition.  There is a security= requirement for
any token to be usable as a bearer token: it must only<= br>become known to the subject and the verifier.  So it must be
sen= t by the asserting party to the subject, and then from
the subject to th= e relying party, through=0A channels that
provide confidentiality and au= thentication of the
destination (such as ordinary TLS connections). = ; And all
three parties must keep the bearer token secret.

By the= way, I saw in the discussion that some existing
implementations are usi= ng assertions.  Hopefully they are
using bearer assertions.

= Francisco


-----Inline Attachment= Follows-----

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