From torsten@lodderstedt.net Sat Dec 1 07:11:51 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2CA11E8097 for ; Sat, 1 Dec 2012 07:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_210=0.6, J_CHICKENPOX_55=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7Hdl94h-+Jf for ; Sat, 1 Dec 2012 07:11:50 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.31.102]) by ietfa.amsl.com (Postfix) with ESMTP id EB2831F0C49 for ; Sat, 1 Dec 2012 07:11:49 -0800 (PST) Received: from [80.187.110.63] (helo=[100.65.117.191]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.68) (envelope-from ) id 1TeojK-0006X8-16; Sat, 01 Dec 2012 16:11:47 +0100 User-Agent: K-9 Mail for Android In-Reply-To: <50B90D9E.5070108@mitre.org> References: <50B90D9E.5070108@mitre.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Torsten Lodderstedt Date: Sat, 01 Dec 2012 16:11:36 +0100 To: Justin Richer ,Eve Maler Message-ID: <5fe2bc39-2bed-40ef-a475-a155e05b1b8f@email.android.com> X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU= Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 15:11:51 -0000 >But even so, I think the simple case of "I have a token and want to >know >about it" needs to be supported without extra scaffolding. +1 > > -- Justin > > > >On 11/30/2012 02:06 PM, Eve Maler wrote: >> You're right that UMA bundles several things in the protection API >> (covered by the protection scope, whose keyword is actually the >> resolvable URI >> "http://docs.kantarainitiative.org/uma/scopes/prot.json"). One of >> those things is the use of the token status endpoint; the rest is the > >> whole mechanism for outsourcing protection. Maybe it makes sense for > >> us to define "protection" as a superset scope that includes a smaller > >> scope of "introspection", which would map to using the introspection >> endpoint being defined in your spec. What do you think? >> >> The permissions that get returned as the result of UMA-style >> introspection are actually part of the definition of the "bearer" UMA > >> token profile. Other token contents could be profiled specifically >for >> use with UMA, or we could perhaps also reuse OAuth token profiles. >The >> wrapper being defined in your spec for totally generic token metadata > >> seems like a good idea; the innards could be any number of things >> (with their own unique metadata), such as policy yes/no decisions, >the >> claims gathered, etc. This topic is discussed in the latter part of >> this slide deck: >> >http://kantarainitiative.org/confluence/download/attachments/17760302/UMA+and+XACML+2012-10-18.pdf >> >> Thanks! >> >> Eve >> >> On 30 Nov 2012, at 7:56 AM, Justin Richer > > wrote: >> >>> Hi Eve, >>> >>> Yes, you've got the right idea. In a lot of cases that we're dealing > >>> with, the relationship between the RS and AS is set up ahead of >time. >>> So the RS knows which AS to ask, and the AS knows how to deal with >>> the different RS's it cares about. UMA gives you a nice dynamic way >>> to introduce the two, but I think that the introduction should be a >>> separate step from the query, since both parts are reusable >>> independently. >>> >>> Correct me if I'm wrong, but UMA also has the whole API for >returning >>> permissions associated with a token, beyond just the simple >>> current-status message, right? Even so, I think it makes sense to >>> decide on what the core set of info that would come back from such a > >>> token introspection would be, and what it means. Different types of >>> tokens (Bearer, MAC, HOK) are going to have different types of >>> metadata associated with them, probably, but there are a few core >>> pieces (expiration, scopes) that would be common and useful. >>> >>> -- Justin >>> >>> On 11/29/2012 05:59 PM, Eve Maler wrote: >>>> Hi Justin-- Glad to see this moving forward. This draft seems >pretty >>>> straightforward, and I imagine the UMA core spec >>>> could >>>> probably incorporate a reference out to this rather than continuing > >>>> to use our custom-specified method for what we'd called "token >>>> status". I wanted to highlight a couple of things we've defined >>>> beyond what you have here, in case they're of interest to the wider > >>>> community. >>>> >>>> This spec defines what I'd call "shallow AS/RS communication", in >>>> that it assumes a trust relationship and context that's set up >>>> between them completely out of band. UMA needed "deep AS/RS >>>> communication", which allows for them to live in separate domains, >>>> potentially run by disparate parties. (This is akin to the >>>> separation in OpenID Connect of IdPs and third-party claim >>>> providers, and I've heard of a number of use cases now for the same > >>>> separation in plain OAuth.) Thus, we defined a means by which the >AS >>>> and RS could be introduced -- it's actually just an embedded OAuth >>>> flow -- so that your mention of a "separate OAuth2 Access Token" >>>> option in Section 2.1 is dictated in UMA to be an OAuth token, with > >>>> a particular scope covering the use of the token introspection >endpoint. >>>> >>>> The API exposed by the AS (in UMA, an "authorization manager" or >AM) >>>> that includes usage of the token introspection endpoint is called a > >>>> "protection API", and it includes registration of information about > >>>> protected resources so that the AS can manage the issuance of >tokens >>>> that it will later be asked to introspect. >>>> >>>> Finally, UMA has a simple extension point, called "UMA token >>>> profile", defined in its (JSON-encoded) AM config data that allows >>>> the content associated with the token to be standardized. Actually >>>> it dictates more than the content; there are protocol aspects to it > >>>> too, perhaps akin to OAuth's token profiles. >>>> >>>> If there's interest in sedimenting some of these pieces into the >>>> OAuth layer, we'd certainly be interested to carve out modules >>>> (where possible) and submit them for consideration. Note that all >of >>>> these features are present in our >>>> http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 >submission. >>>> >>>> Thanks, >>>> >>>> Eve >>>> >>>> On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." >>>> > wrote: >>>> >>>>> I took some time this morning to put together a draft of Token >>>>> Introspection. This is largely based on how we implemented it here > >>>>> a few years ago, and I'm hoping that this and the Ping draft can >>>>> help move the conversation about introspection forward. >>>>> >>>>> -- Justin >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> *From: *> >>>>>> *Subject: **New Version Notification for >>>>>> draft-richer-oauth-introspection-00.txt* >>>>>> *Date: *November 27, 2012 1:44:01 PM EST >>>>>> *To: *> >>>>>> >>>>>> >>>>>> A new version of I-D, draft-richer-oauth-introspection-00.txt >>>>>> has been successfully submitted by Justin Richer and posted to >the >>>>>> IETF repository. >>>>>> >>>>>> Filename:draft-richer-oauth-introspection >>>>>> Revision:00 >>>>>> Title:OAuth Token Introspection >>>>>> Creation date:2012-11-27 >>>>>> WG ID:Individual Submission >>>>>> Number of pages: 6 >>>>>> URL: >>>>>> >http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt >>>>>> Status: >>>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection >>>>>> Htmlized: >>>>>> http://tools.ietf.org/html/draft-richer-oauth-introspection-00 >>>>>> >>>>>> >>>>>> Abstract: >>>>>> This specification defines a method for a client or protected >>>>>> resource to query an OAuth authorization server to determine >meta- >>>>>> information about an OAuth token. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The IETF Secretariat >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> >>>> Eve Maler http://www.xmlgrrl.com/blog >>>> +1 425 345 6756 http://www.twitter.com/xmlgrrl >>>> >>>> >>> >> >> >> Eve Maler http://www.xmlgrrl.com/blog >> +1 425 345 6756 http://www.twitter.com/xmlgrrl >> >> > > > >------------------------------------------------------------------------ > >_______________________________________________ >OAuth mailing list >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth From mark@novemberborn.net Sun Dec 2 09:27:19 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130DF21F84D7 for ; Sun, 2 Dec 2012 09:27:19 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hVYEtUkl+-V for ; Sun, 2 Dec 2012 09:27:12 -0800 (PST) Received: from wolfback.joyent.us (wolfback.joyent.us [8.17.171.168]) by ietfa.amsl.com (Postfix) with ESMTP id 5F93921F851B for ; Sun, 2 Dec 2012 09:27:12 -0800 (PST) Received: from [10.0.0.5] (cpc5-acto1-2-0-cust150.4-2.cable.virginmedia.com [86.27.254.151]) by wolfback.joyent.us (Postfix) with ESMTPSA id 98BBB34068 for ; Sun, 2 Dec 2012 17:27:09 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\)) From: Mark Wubben In-Reply-To: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> Date: Sun, 2 Dec 2012 17:27:09 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> To: "oauth@ietf.org WG" X-Mailer: Apple Mail (2.1498) Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 17:27:19 -0000 The draft relies heavily on the definition "access grant", but no = definition is provided in the draft or RFC 6749. It's been my = interpretation that an "access grant" is the *fact* that a resource = owner has authorized a client (potentially scoped) access to the = protected resources. Once access is granted in this manner, further = access tokens may be obtained without explicit permission by the = end-user. That is, in the Protocol Flow there is no user input between = steps A and B. In "1. Introduction" it is stated: > A > revocation request will invalidate the actual token and, if > applicable, other tokens based on the same access grant and the > access grant itself. then, in "2. Token Revocation": > In the next step, the authorization server invalidates the token and > the respective access grant. If the particular token is a refresh > token and the authorization server supports the revocation of = access > tokens, then the authorization server SHOULD also invalidate all > access tokens based on the same access grant This implies that an access grant only applies to an app authorized on a = single device. If an app is installed on multiple devices and the access = grant is shared between both instances, revoking device A's access token = results in the unexpected revocation of device B's token. If "access grant" could be defined as "an authorization issued to the = client, based on the single use of an Authorization Grant" it becomes = clear than only the tokens spawning from the app's authorization on = device A should be revoked. --- I spotted a typo in "3. Implementation Note": > Whether this is an viable option or > whether access token revocation is required should be decided based > on the service provider's risk analysis. "an viable option" should be "a viable option". On 24 Nov 2012, at 18:13, Hannes Tschofenig = wrote: > Hi all,=20 >=20 > this is a working group last call for draft-ietf-oauth-revocation-03 = on "Token Revocation". The draft is available here: > http://tools.ietf.org/html/draft-ietf-oauth-revocation-03 >=20 > Please send you comments to the OAuth mailing list by December 10, = 2012. =20 >=20 > Thanks, > Hannes & Derek >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -- Mark Wubben http://novemberborn.net http://twitter.com/novemberborn From zhou.sujing@zte.com.cn Sun Dec 2 16:51:44 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C6421F893A for ; Sun, 2 Dec 2012 16:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.965 X-Spam-Level: X-Spam-Status: No, score=-97.965 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmFZtLl0lvvj for ; Sun, 2 Dec 2012 16:51:44 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 121BC21F88F0 for ; Sun, 2 Dec 2012 16:51:43 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id B6B531256B95 for ; Mon, 3 Dec 2012 08:53:18 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 0A416710915 for ; Mon, 3 Dec 2012 08:49:45 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qB30pNtb032475 for ; Mon, 3 Dec 2012 08:51:23 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> To: "oauth@ietf.org WG" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 3 Dec 2012 08:51:22 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-03 08:51:23, Serialize complete at 2012-12-03 08:51:23 Content-Type: multipart/alternative; boundary="=_alternative 0004D0B548257AC9_=" X-MAIL: mse02.zte.com.cn qB30pNtb032475 Subject: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 00:51:44 -0000 This is a multipart message in MIME format. --=_alternative 0004D0B548257AC9_= Content-Type: text/plain; charset="US-ASCII" http://datatracker.ietf.org/doc/draft-zhou-oauth-owner-auth/ --=_alternative 0004D0B548257AC9_= Content-Type: text/html; charset="US-ASCII"
http://datatracker.ietf.org/doc/draft-zhou-oauth-owner-auth/
--=_alternative 0004D0B548257AC9_=-- From sakimura@gmail.com Sun Dec 2 19:12:37 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA85521F8920 for ; Sun, 2 Dec 2012 19:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBtlS6hpJ2Do for ; Sun, 2 Dec 2012 19:12:37 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E9E0B21F891E for ; Sun, 2 Dec 2012 19:12:36 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1077512eaa.31 for ; Sun, 02 Dec 2012 19:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=u2l4eSypgZYB4k6UOP1E7+CuAB+vFc0CjyW/hF82juo=; b=lEscrRhjbwLATvCoFCIfUS0a+NU1v4ST2CwwL6wiejgkERXYXkLfZxJsZKgzbAfNEM COjTFlJqFEH6rAkFf+pEZ/MAPvt4PSJNABi4pczVv1xUUeaquFx53NbLbHOp1SkX3LpM xs0Cv19GgXOBSoiSCsJuLfs4aWQYQeuCdNLkWRYxG8jrlc6X+eftgiBiZ2ml7TZMpZfG qSyFlRyOFHf03IiHhk9GiQeTbs6LiJgQcQHpqr5EhgnXaisb5ih57GMJpMWEKi9c3Ec2 xThe4qB3Pi1RVH9VwzFWDJ/3VCa4PZuttA08iF7n7uJhXzf9jGJFFMI+O9D1Iq4ruCxV fSrw== MIME-Version: 1.0 Received: by 10.14.178.196 with SMTP id f44mr31505871eem.14.1354504355937; Sun, 02 Dec 2012 19:12:35 -0800 (PST) Received: by 10.14.215.66 with HTTP; Sun, 2 Dec 2012 19:12:35 -0800 (PST) In-Reply-To: References: <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> Date: Mon, 3 Dec 2012 12:12:35 +0900 Message-ID: From: Nat Sakimura To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=047d7b622520fb7d9f04cfea1ed8 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 03:12:38 -0000 --047d7b622520fb7d9f04cfea1ed8 Content-Type: text/plain; charset=ISO-8859-1 Could you kindly explain the use case a little more, please? Nat On Mon, Dec 3, 2012 at 9:51 AM, wrote: > > http://datatracker.ietf.org/doc/draft-zhou-oauth-owner-auth/ > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b622520fb7d9f04cfea1ed8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Could you kindly explain the use case a little more, please?=A0

Nat

On Mon, Dec 3, 2012 at 9:51 A= M, <zhou.sujing@zte.com.cn> wrote:

http://datatracker.ietf.org/d= oc/draft-zhou-oauth-owner-auth/

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




--
Nat Saki= mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=
--047d7b622520fb7d9f04cfea1ed8-- From zhou.sujing@zte.com.cn Sun Dec 2 22:35:45 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F9921F89B1 for ; Sun, 2 Dec 2012 22:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.373 X-Spam-Level: X-Spam-Status: No, score=-96.373 tagged_above=-999 required=5 tests=[AWL=-1.592, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_28=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPdLZpPKhJmw for ; Sun, 2 Dec 2012 22:35:44 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2F21F8998 for ; Sun, 2 Dec 2012 22:35:43 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 28F421279311 for ; Mon, 3 Dec 2012 14:37:21 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 8AD3E17BD52F; Mon, 3 Dec 2012 14:33:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB36ZRih072800; Mon, 3 Dec 2012 14:35:28 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Nat Sakimura MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 3 Dec 2012 14:35:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-03 14:35:29, Serialize complete at 2012-12-03 14:35:29 Content-Type: multipart/alternative; boundary="=_alternative 002450F248257AC9_=" X-MAIL: mse01.zte.com.cn qB36ZRih072800 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 06:35:45 -0000 This is a multipart message in MIME format. --=_alternative 002450F248257AC9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 V2VsbCwgdGhlcmUgaXMgYSByZWxhdGVkIHRocmVhZCANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp bC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzA5OTQ2Lmh0bWwNCg0KQnV0IG15IHVzZSBj YXNlIGlzIGRpZmZlcmVudCBmcm9tIFNpcml3YXJkZW5hJ3MuIA0KDQp3aGF0IE9BdXRoIGRvZXM6 IA0KLUkgZGVwb3NpdCBteSBjaGlsZChwcmVjaW91cyByZXNvdXJjZSkgYXQga2luZGVyZ2FyZGVu KFJlc291cmNlIFNlcnZlcikNCi13aGVuIHNvbWVvbmUgdHJpZXMgdG8gdGFrZSBoaW0gb3V0c2lk ZSBvZiB0aGUga2luZGVyZ2FyZGVuLCB0aGUgdGVhY2hlciANCndpbGwNCmluZm9ybSBtZShSZXNv dXJjZSBPd25lcikgImRvIHlvdSBhdXRob3JpemUgdGhpcyBndXkgZG8gaXQNCi1JIGF1dGhvcml6 ZSB0aGlzIHBlcnNvbiBhbmQgaXQgZ29zZSBvbi4NCg0KbXkgdXNlIGNhc2UoUk8taW5pdGlhdGVk IGRlbGVnYXRpb24pOg0KLUkgZGVwb3NpdCBteSBjaGlsZChwcmVjaW91cyByZXNvdXJjZSkgYXQg a2luZGVyZ2FyZGVuKFJlc291cmNlIFNlcnZlcikNCi1JIGRlbGVnYXRlIGEgZmV3IHBlcnNvbnMs ZS5nLiwgZ3JhbmRwYXJlbnRzIG9mIG15IGNoaWxkLCB0byBwaWNrIHVwIG15IA0KY2hpbGQgYXQg dGhlIGtpbmRlcmdhcmRlbg0KLXdoZW4gc29tZW9uZSB0cmllcyB0byB0YWtlIGhpbSBvdXRzaWRl IG9mIHRoZSBraW5kZXJnYXJkZW4sICB0aGUgdGVhY2hlciANCndpbGwgYXNrIGhpbS9oZXIgdG8g c2hvdyBteSBkZWxlZ2F0aW9uDQogc3RhdGVtZW50LCBubyBzdGF0ZW1lbnQsIG5vIHRha2luZyBt eSBjaGlsZC4gDQoNClRob21hcyBIYXJkam9ubydzIHVzZSBjYXNlOiANCi0gSSBkZXBvc2l0IG15 IENoaWxkIGF0IHRoZSBLaW5kZXJnYXJ0ZW4uDQotIEkgZGVsZWdhdGUgbXkgb2xkIEdyYW5kbW90 aGVyIHRvIHBpY2sgdXAgdGhlIENoaWxkLg0KLSBNeSBHcmFuZG1vdGhlciB0YWtlcyBhIHRheGku DQotIFRoZSB0YXhpIERyaXZlciBhY3RzIGFzIHByb3h5IHRvIG15IG9sZCBHcmFuZG1vdGhlciB3 aG8gc3RheXMgaW4gdGhlDQp0YXhpLg0KLSBUaGUgdGF4aSBEcml2ZXIgbmVlZHMgdG8gc2hvdyAy IGZvcm1zIG9mIERlbGVnYXRpb24gdG8gdGhlIFRlYWNoZXIuDQotIFRoZSBUYXhpIGRyaXZlciB3 YWxrcyB0aGUgQ2hpbGQgdG8gdGhlIHRheGkuDQogDQoNCg0KDQpOYXQgU2FraW11cmEgPHNha2lt dXJhQGdtYWlsLmNvbT4gDQoyMDEyLTEyLTAzIDExOjEyDQoNCsrVvP7Iyw0KemhvdS5zdWppbmdA enRlLmNvbS5jbg0Ks63LzQ0KIm9hdXRoQGlldGYub3JnIFdHIiA8b2F1dGhAaWV0Zi5vcmc+DQrW 98ziDQpSZTogW09BVVRILVdHXSBIaSxhbnkgY29tbWVudCBvbiBkcmFmdC16aG91LW9hdXRoLW93 bmVyLWF1dGg/DQoNCg0KDQoNCg0KDQpDb3VsZCB5b3Uga2luZGx5IGV4cGxhaW4gdGhlIHVzZSBj YXNlIGEgbGl0dGxlIG1vcmUsIHBsZWFzZT8gDQoNCk5hdA0KDQpPbiBNb24sIERlYyAzLCAyMDEy IGF0IDk6NTEgQU0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPiB3cm90ZToNCg0KaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aG91LW9hdXRoLW93bmVyLWF1dGgvIA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFp bGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9vYXV0aA0KDQoNCg0KDQotLSANCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFu LCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0K DQoNCg== --=_alternative 002450F248257AC9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldlbGwsIHRoZXJlIGlzIGEgcmVs YXRlZCB0aHJlYWQgJm5ic3A7aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29h dXRoL2N1cnJlbnQvbXNnMDk5NDYuaHRtbDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+ QnV0IG15IHVzZSBjYXNlIGlzIGRpZmZlcmVudCBmcm9tIFNpcml3YXJkZW5hJ3MuIDwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTM+d2hhdCBPQXV0aCBkb2VzOiA8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPi1JIGRlcG9zaXQgbXkgY2hpbGQocHJlY2lvdXMgcmVzb3VyY2UpIGF0IGtpbmRl cmdhcmRlbihSZXNvdXJjZQ0KU2VydmVyKTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+LXdoZW4g c29tZW9uZSB0cmllcyB0byB0YWtlIGhpbSBvdXRzaWRlIG9mIHRoZSBraW5kZXJnYXJkZW4sDQp0 aGUgdGVhY2hlciB3aWxsPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5pbmZvcm0gbWUoUmVzb3Vy Y2UgT3duZXIpICZxdW90O2RvIHlvdSBhdXRob3JpemUgdGhpcw0KZ3V5IGRvIGl0PC9mb250Pg0K PGJyPjxmb250IHNpemU9Mz4tSSBhdXRob3JpemUgdGhpcyBwZXJzb24gYW5kIGl0IGdvc2Ugb24u PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5teSB1c2UgY2FzZShSTy1pbml0aWF0ZWQg ZGVsZWdhdGlvbik6PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4tSSBkZXBvc2l0IG15IGNoaWxk KHByZWNpb3VzIHJlc291cmNlKSBhdCBraW5kZXJnYXJkZW4oUmVzb3VyY2UNClNlcnZlcik8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPi1JIGRlbGVnYXRlIGEgZmV3IHBlcnNvbnMsZS5nLiwgZ3Jh bmRwYXJlbnRzIG9mIG15IGNoaWxkLA0KdG8gcGljayB1cCBteSBjaGlsZCBhdCB0aGUga2luZGVy Z2FyZGVuPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4td2hlbiBzb21lb25lIHRyaWVzIHRvIHRh a2UgaGltIG91dHNpZGUgb2YgdGhlIGtpbmRlcmdhcmRlbiwNCiZuYnNwO3RoZSB0ZWFjaGVyIHdp bGwgYXNrIGhpbS9oZXIgdG8gc2hvdyBteSBkZWxlZ2F0aW9uPC9mb250Pg0KPGJyPjxmb250IHNp emU9Mz4mbmJzcDtzdGF0ZW1lbnQsIG5vIHN0YXRlbWVudCwgbm8gdGFraW5nIG15IGNoaWxkLiA8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPlRob21hcyBIYXJkam9ubydzIHVzZSBjYXNl OiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPi0gSSBkZXBvc2l0IG15IENoaWxkIGF0IHRoZSBL aW5kZXJnYXJ0ZW4uPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4tIEkgZGVsZWdhdGUgbXkgb2xk IEdyYW5kbW90aGVyIHRvIHBpY2sgdXAgdGhlIENoaWxkLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTM+LSBNeSBHcmFuZG1vdGhlciB0YWtlcyBhIHRheGkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mz4tIFRoZSB0YXhpIERyaXZlciBhY3RzIGFzIHByb3h5IHRvIG15IG9sZCBHcmFuZG1vdGhlcg0K d2hvIHN0YXlzIGluIHRoZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+dGF4aS48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0zPi0gVGhlIHRheGkgRHJpdmVyIG5lZWRzIHRvIHNob3cgMiBmb3JtcyBv ZiBEZWxlZ2F0aW9uDQp0byB0aGUgVGVhY2hlci48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPi0g VGhlIFRheGkgZHJpdmVyIHdhbGtzIHRoZSBDaGlsZCB0byB0aGUgdGF4aS48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj48Yj5OYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZndDs8 L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMi0w MyAxMToxMjwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj56aG91LnN1amluZ0B6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvN PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtv YXV0aEBpZXRmLm9yZyBXRyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5SZTogW09BVVRILVdHXSBIaSxhbnkgY29tbWVudCBvbiBkcmFmdC16aG91LW9hdXRo LW93bmVyLWF1dGg/PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRv cD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zPkNvdWxkIHlvdSBraW5kbHkgZXhwbGFpbiB0aGUgdXNlIGNhc2UgYSBsaXR0bGUg bW9yZSwgcGxlYXNlPyZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+TmF0PGJy Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5PbiBNb24sIERlYyAzLCAyMDEyIGF0IDk6NTEg QU0sICZsdDs8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbiB0YXJn ZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pnpob3Uuc3VqaW5nQHp0ZS5jb20u Y248L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+Jmd0Ow0Kd3JvdGU6PC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2Zv bnQ+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aG91LW9h dXRoLW93bmVyLWF1dGgvIiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPjx1Pmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt emhvdS1vYXV0aC1vd25lci1hdXRoLzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJz YW5zLXNlcmlmIj4NCjwvZm9udD48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxp c3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBo cmVmPW1haWx0bzpPQXV0aEBpZXRmLm9yZz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5PQXV0 aEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pjxicj4N CjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L29hdXRoIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjxicj4NCjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTM+LS0gPGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KTwvZm9udD4NCjxi cj48Zm9udCBzaXplPTM+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPC9mb250Pjxmb250IHNp emU9MyBjb2xvcj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vbmF0LnNh a2ltdXJhLm9yZy8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5odHRw Oi8vbmF0LnNha2ltdXJhLm9yZy88L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KQF9u YXRfZW48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo= --=_alternative 002450F248257AC9_=-- From sakimura@gmail.com Sun Dec 2 22:44:25 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A9421F86A4 for ; Sun, 2 Dec 2012 22:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.198 X-Spam-Level: X-Spam-Status: No, score=-3.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHvIbaEQoBTt for ; Sun, 2 Dec 2012 22:44:24 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3DB721F85AA for ; Sun, 2 Dec 2012 22:44:23 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1126366eaa.31 for ; Sun, 02 Dec 2012 22:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PsYfCQG0J/O9neueGo8sSBKfHwxAoknkgkiOVHmAaJU=; b=XIBdZ3w0CQ8Kb7IUtxWKpnsX2V7aZQhwPYW0kVXV8AOrqT0EKPfxspUIneMNwM7wL0 gfXeMAwCt6bB1Po5qh1JCGtIefhN1OBHOnwYQ4K8KUOwgs1+yoT/ROagOB1G+6tqtNUQ BlbyWB4GxH8VeJxXSD0mLAgdjOeFOCfxWCv77l5aYY8+C213LcYammSM74XfEDpisHwO Yik76xFd09JL/beN2hIvhOU+iM34B1k5XK5QXcPrKQDe9Vik9eFBqWPqU6QYvyJolVjV Ph0bH3G3vCdgiE207nFdtSCqDpw3F79/C2c1GcM9JYUWLtbe5dN5XHZcyhkDofzjYbey /6Cg== MIME-Version: 1.0 Received: by 10.14.0.133 with SMTP id 5mr7328514eeb.29.1354517063035; Sun, 02 Dec 2012 22:44:23 -0800 (PST) Received: by 10.14.215.66 with HTTP; Sun, 2 Dec 2012 22:44:22 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Dec 2012 15:44:22 +0900 Message-ID: From: Nat Sakimura To: zhou.sujing@zte.com.cn Content-Type: multipart/alternative; boundary=047d7b66fef3626a5c04cfed14b9 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 06:44:25 -0000 --047d7b66fef3626a5c04cfed14b9 Content-Type: text/plain; charset=ISO-8859-1 Your usecase sounds a little bit like the assertion flow. The RO issues an assertion and the rest goes. Is there reasons that an assertion flow cannot do? Nat On Mon, Dec 3, 2012 at 3:35 PM, wrote: > my use case(RO-initiated delegation): > -I deposit my child(precious resource) at kindergarden(Resource Server) > -I delegate a few persons,e.g., grandparents of my child, to pick up my > child at the kindergarden > -when someone tries to take him outside of the kindergarden, the teacher > will ask him/her to show my delegation > statement, no statement, no taking my child. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b66fef3626a5c04cfed14b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Your usecase sounds a little bit like the assertion flow.=A0
The RO iss= ues an assertion and the rest goes.=A0
Is there reasons that an a= ssertion flow cannot do?=A0

Nat

On Mon, Dec 3, 2012 at 3:35 PM, <zhou.sujing@zte.com.cn> wrote:
my use case(RO-initiated delegation):
-I deposit my child(precious resource) at kindergarden= (Resource Server)
-I delegate a few persons,e.g., grandparents of my chi= ld, to pick up my child at the kindergarden
-when someone tries to take him outside of the kinderg= arden, =A0the teacher will ask him/her to show my delegation
=A0statement, no statement, no taking my child.



--
Nat Sakimur= a (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b66fef3626a5c04cfed14b9-- From zhou.sujing@zte.com.cn Mon Dec 3 00:18:41 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F77821F88DC for ; Mon, 3 Dec 2012 00:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.04 X-Spam-Level: X-Spam-Status: No, score=-96.04 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_48=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2+lGOyYrcNE for ; Mon, 3 Dec 2012 00:18:40 -0800 (PST) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 593B121F888E for ; Mon, 3 Dec 2012 00:18:40 -0800 (PST) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 81686127A61E for ; Mon, 3 Dec 2012 16:20:13 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id E727E713F2C; Mon, 3 Dec 2012 16:16:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qB38IGRw076372; Mon, 3 Dec 2012 16:18:16 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Nat Sakimura MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 3 Dec 2012 16:18:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-03 16:18:18, Serialize complete at 2012-12-03 16:18:18 Content-Type: multipart/alternative; boundary="=_alternative 002DBB1748257AC9_=" X-MAIL: mse02.zte.com.cn qB38IGRw076372 Cc: "oauth@ietf.org WG" Subject: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 08:18:41 -0000 This is a multipart message in MIME format. --=_alternative 002DBB1748257AC9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TXkgdXNlIGNhc2UgaXMgaW5kZWVkIHNpbWlsYXIgdG8gIGFzc2VydGlvbiBmbG93ICJzZWN0aW9u IDYuMy4gIENsaWVudCANCkFjdGluZyBvbiBCZWhhbGYgb2YgYSBVc2VyIi4NCkRpZmZlcmVuY2Vz IGFyZToNCjEuICBpZiBteSB1c2UgY2FzZSBpcyBjYXJyaWVkIG91dCBpbiBhc3NlcnRpb24gZnJh bWV3b3JrLCAicHJpY2lwYWwiIA0Kc2hvdWxkIGJlIGNsaWVudCwgd2hpbGUgYXNzZXJ0aW9uIGRv Y3VtZW50IGRvZXMgbm90IA0KaW5jbHVkZSBjbGllbnQgYXMgYW4gb3B0aW9uIHdoZW4gY2xpZW50 IGlzIGFjdGluZyBvbiBiZWhhbGYgb2YgYSANCnVzZXIocmVzb3VyY2Ugb3duZXIpLCBpdCBzYXlz ICAiIGFuIGF1dGhvcml6ZWQgYWNjZXNzb3IgZm9yIHdoaWNoIHRoZSANCmFjY2VzcyB0b2tlbiBp cyBiZWluZyByZXF1ZXN0ZWQgKHR5cGljYWxseSB0aGUgcmVzb3VyY2Ugb3duZXIsIG9yICBhbiAN CmF1dGhvcml6ZWQgZGVsZWdhdGUpLiINCjIuICBpZiBteSB1c2UgY2FzZSBpcyBjYXJyaWVkIG91 dCBpbiBhc3NlcnRpb24gZnJhbWV3b3JrLCAiaXNzdWVyIiBzaG91bGQgDQpiZSByZXNvdXJjZSBv d25lciwgd2hpbGUgYXNzZXJ0aW9uIGRvY3VtZW50IG9ubHkgaW5jbHVkZXMgDQpjbGllbnQgYW5k IHRva2VuIHNlcnZpY2UgDQoNCkluIG15IHVzZSBjYXNlIHRoZSAiYXNzZXJ0aW9uIiBpcyBtb3Jl IGxpa2UgYSBwcml2YXRlIG91dHB1dCwgd2hpbGUgaW4gDQphc3NlcnRpb24gZmxvdyAiYXNzZXJ0 aW9uICIgaXMgZ2VuZXJhdGVkIGJ5IGEgdGhyaWQgcGFydHkgdG9rZW4gc2VydmljZSBvciANCmJ5 IGNsaWVudCBpdHNlbGYuDQoNCg0KDQoNCg0KTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5j b20+IA0KMjAxMi0xMi0wMyAxNDo0NA0KDQrK1bz+yMsNCnpob3Uuc3VqaW5nQHp0ZS5jb20uY24N CrOty80NCiJvYXV0aEBpZXRmLm9yZyBXRyIgPG9hdXRoQGlldGYub3JnPg0K1vfM4g0KUmU6IFJl OiBbT0FVVEgtV0ddIEhpLGFueSBjb21tZW50IG9uIGRyYWZ0LXpob3Utb2F1dGgtb3duZXItYXV0 aD8NCg0KDQoNCg0KDQoNCllvdXIgdXNlY2FzZSBzb3VuZHMgYSBsaXR0bGUgYml0IGxpa2UgdGhl IGFzc2VydGlvbiBmbG93LiANClRoZSBSTyBpc3N1ZXMgYW4gYXNzZXJ0aW9uIGFuZCB0aGUgcmVz dCBnb2VzLiANCklzIHRoZXJlIHJlYXNvbnMgdGhhdCBhbiBhc3NlcnRpb24gZmxvdyBjYW5ub3Qg ZG8/IA0KDQpOYXQNCg0KT24gTW9uLCBEZWMgMywgMjAxMiBhdCAzOjM1IFBNLCA8emhvdS5zdWpp bmdAenRlLmNvbS5jbj4gd3JvdGU6DQpteSB1c2UgY2FzZShSTy1pbml0aWF0ZWQgZGVsZWdhdGlv bik6IA0KLUkgZGVwb3NpdCBteSBjaGlsZChwcmVjaW91cyByZXNvdXJjZSkgYXQga2luZGVyZ2Fy ZGVuKFJlc291cmNlIFNlcnZlcikgDQotSSBkZWxlZ2F0ZSBhIGZldyBwZXJzb25zLGUuZy4sIGdy YW5kcGFyZW50cyBvZiBteSBjaGlsZCwgdG8gcGljayB1cCBteSANCmNoaWxkIGF0IHRoZSBraW5k ZXJnYXJkZW4gDQotd2hlbiBzb21lb25lIHRyaWVzIHRvIHRha2UgaGltIG91dHNpZGUgb2YgdGhl IGtpbmRlcmdhcmRlbiwgIHRoZSB0ZWFjaGVyIA0Kd2lsbCBhc2sgaGltL2hlciB0byBzaG93IG15 IGRlbGVnYXRpb24gDQogc3RhdGVtZW50LCBubyBzdGF0ZW1lbnQsIG5vIHRha2luZyBteSBjaGls ZC4gDQoNCg0KDQotLSANCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91 bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0KDQoNCg== --=_alternative 002DBB1748257AC9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk15IHVzZSBjYXNlIGlzIGluZGVl ZCBzaW1pbGFyIHRvICZuYnNwO2Fzc2VydGlvbg0KZmxvdyAmcXVvdDtzZWN0aW9uIDYuMy4gJm5i c3A7Q2xpZW50IEFjdGluZyBvbiBCZWhhbGYgb2YgYSBVc2VyJnF1b3Q7LjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RGlmZmVyZW5jZXMgYXJlOjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gJm5ic3A7aWYgbXkgdXNlIGNhc2Ug aXMgY2FycmllZCBvdXQNCmluIGFzc2VydGlvbiBmcmFtZXdvcmssICZxdW90O3ByaWNpcGFsJnF1 b3Q7IHNob3VsZCBiZSBjbGllbnQsIHdoaWxlIGFzc2VydGlvbg0KZG9jdW1lbnQgZG9lcyBub3Qg PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pbmNsdWRlIGNsaWVu dCBhcyBhbiBvcHRpb24gd2hlbiBjbGllbnQNCmlzIGFjdGluZyBvbiBiZWhhbGYgb2YgYSB1c2Vy KHJlc291cmNlIG93bmVyKSwgaXQgc2F5cyAmbmJzcDsmcXVvdDsgYW4NCmF1dGhvcml6ZWQgYWNj ZXNzb3IgZm9yIHdoaWNoIHRoZSAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPmFjY2VzcyB0b2tlbiBpcyBiZWluZyByZXF1ZXN0ZWQgKHR5cGljYWxseQ0K dGhlIHJlc291cmNlIG93bmVyLCBvciAmbmJzcDthbiBhdXRob3JpemVkIGRlbGVnYXRlKS4mcXVv dDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuICZuYnNwO2lm IG15IHVzZSBjYXNlIGlzIGNhcnJpZWQgb3V0DQppbiBhc3NlcnRpb24gZnJhbWV3b3JrLCAmcXVv dDtpc3N1ZXImcXVvdDsgc2hvdWxkIGJlIHJlc291cmNlIG93bmVyLCB3aGlsZQ0KYXNzZXJ0aW9u IGRvY3VtZW50IG9ubHkgaW5jbHVkZXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5jbGllbnQgYW5kIHRva2VuIHNlcnZpY2UgPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JbiBteSB1c2UgY2FzZSB0aGUgJnF1b3Q7YXNz ZXJ0aW9uJnF1b3Q7DQppcyBtb3JlIGxpa2UgYSBwcml2YXRlIG91dHB1dCwgd2hpbGUgaW4gYXNz ZXJ0aW9uIGZsb3cgJnF1b3Q7YXNzZXJ0aW9uDQomcXVvdDsgaXMgZ2VuZXJhdGVkIGJ5IGEgdGhy aWQgcGFydHkgdG9rZW4gc2VydmljZSBvciBieSBjbGllbnQgaXRzZWxmLjwvZm9udD4NCjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5OYXQg U2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMi0wMyAxNDo0NDwvZm9udD4NCjx0ZCB3 aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj56aG91LnN1amluZ0B6 dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtvYXV0aEBpZXRmLm9yZyBXRyZxdW90 OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogUmU6IFtPQVVU SC1XR10gSGksYW55IGNvbW1lbnQgb24NCmRyYWZ0LXpob3Utb2F1dGgtb3duZXItYXV0aD88L2Zv bnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwv dGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+WW91ciB1 c2VjYXNlIHNvdW5kcyBhIGxpdHRsZSBiaXQgbGlrZSB0aGUgYXNzZXJ0aW9uIGZsb3cuJm5ic3A7 PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5UaGUgUk8gaXNzdWVzIGFuIGFzc2VydGlvbiBhbmQg dGhlIHJlc3QgZ29lcy4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPklzIHRoZXJlIHJl YXNvbnMgdGhhdCBhbiBhc3NlcnRpb24gZmxvdyBjYW5ub3QgZG8/Jm5ic3A7PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9Mz5OYXQ8YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPk9u IE1vbiwgRGVjIDMsIDIwMTIgYXQgMzozNSBQTSwgJmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp6 aG91LnN1amluZ0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWU+PHU+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4m Z3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPm15IHVzZSBjYXNlKFJPLWluaXRp YXRlZCBkZWxlZ2F0aW9uKTogPGJyPg0KLUkgZGVwb3NpdCBteSBjaGlsZChwcmVjaW91cyByZXNv dXJjZSkgYXQga2luZGVyZ2FyZGVuKFJlc291cmNlIFNlcnZlcikNCjxicj4NCi1JIGRlbGVnYXRl IGEgZmV3IHBlcnNvbnMsZS5nLiwgZ3JhbmRwYXJlbnRzIG9mIG15IGNoaWxkLCB0byBwaWNrIHVw IG15DQpjaGlsZCBhdCB0aGUga2luZGVyZ2FyZGVuIDxicj4NCi13aGVuIHNvbWVvbmUgdHJpZXMg dG8gdGFrZSBoaW0gb3V0c2lkZSBvZiB0aGUga2luZGVyZ2FyZGVuLCAmbmJzcDt0aGUNCnRlYWNo ZXIgd2lsbCBhc2sgaGltL2hlciB0byBzaG93IG15IGRlbGVnYXRpb24gPGJyPg0KJm5ic3A7c3Rh dGVtZW50LCBubyBzdGF0ZW1lbnQsIG5vIHRha2luZyBteSBjaGlsZC4gPC9mb250Pg0KPGJyPjxm b250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPi0tIDxicj4N Ck5hdCBTYWtpbXVyYSAoPW5hdCk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPkNoYWlybWFuLCBP cGVuSUQgRm91bmRhdGlvbjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT48YnI+DQo8 L3U+PC9mb250PjxhIGhyZWY9aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIHRhcmdldD1fYmxhbms+ PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0zPjxicj4NCkBfbmF0X2VuPC9mb250Pg0KPGJyPg0KPGJyPg0K --=_alternative 002DBB1748257AC9_=-- From sakimura@gmail.com Mon Dec 3 00:35:07 2012 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E0D21F88C2 for ; Mon, 3 Dec 2012 00:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hm2X7I-eoVnD for ; Mon, 3 Dec 2012 00:35:07 -0800 (PST) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD02421F888E for ; Mon, 3 Dec 2012 00:35:06 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id a1so1165596eaa.31 for ; Mon, 03 Dec 2012 00:35:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DmdUhECkNo3jAEJYLaf1K0zi0XHD9X3jHD75BfSXMds=; b=YmXY1V9S+T22Vkj+MN8FPf5hKx+mQ+HmqyuXYKVsw6ec9GY3jmjpyNKDG/6AFuytR3 kom7+c2ypCnxiSUTFcyNgMiIlx46tPb5vIV1Uhqnn8rtJTeYL6ss9LfZciZTKmkPHyBk FMaUX0uvG0EXrZPd6Ukea4ir+KBH8GaqAxu1r4KxbHB8nsYsggu906rmaq5fqwT97O7k AHQp6Dw71a171cyizviNQ7IPmfTqiwkBqPaN50UKm5aDQQwopUUy/f+Gsj8V1Fius3YB N0b3EF9gPJE7y7USnt8HdID8Cp5OnbgCHRBhwd9McwE1aO4lKGhrhFGFdViUDm4WDkL2 TzZw== MIME-Version: 1.0 Received: by 10.14.220.71 with SMTP id n47mr33273752eep.39.1354523705460; Mon, 03 Dec 2012 00:35:05 -0800 (PST) Received: by 10.14.215.66 with HTTP; Mon, 3 Dec 2012 00:35:05 -0800 (PST) Date: Mon, 3 Dec 2012 17:35:05 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell , oauth Content-Type: multipart/alternative; boundary=047d7b621ef04dc8c304cfeea037 Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 08:35:08 -0000 --047d7b621ef04dc8c304cfeea037 Content-Type: text/plain; charset=ISO-8859-1 Hi Brian, The assertion framework defines the Issuer as: Issuer The unique identifier for the entity that issued the assertion. Generally this is the entity that holds the key material used to generate the assertion. The issuer may be either an OAuth client (when assertions are self-issued) or a third party token service. I was wondering why it has to be either the client or a third party token service. Conceptually, it could be any token service (functionality) residing in any of the stakeholders (Resource Owner, OAuth Client, Authorization Server, or a third party). I would appreciate if you could clarify why is the case. Best, -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --047d7b621ef04dc8c304cfeea037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Hi Brian, 

The assertion framework defines the Issuer as: 
   Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.  The issuer may be either
      an OAuth client (when assertions are self-issued) or a third party
      token service.

I was wondering why it has to=
 be either the client or a third party token service. 
Conceptually, it could be any token service (functionality) residing i=
n any of 
the stakeholders (Resource Owner, OAuth Client, Authorization Server, or 
a third party). 

I would appreciate if you could clarify why is the case. 

Best, 

-- 
Nat Sakimura (=3Dna=
t)
Chairman, OpenID Foundation
http://nat.sakimura.org/

@_nat_en



--047d7b621ef04dc8c304cfeea037--

From hannes.tschofenig@nsn.com  Mon Dec  3 00:50:01 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F57721F8911 for ; Mon,  3 Dec 2012 00:50:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-+bUrQ2kKWE for ; Mon,  3 Dec 2012 00:50:00 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C2D2E21F890F for ; Mon,  3 Dec 2012 00:49:59 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id qB38nra0017507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Dec 2012 09:49:53 +0100
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id qB38no4T025228; Mon, 3 Dec 2012 09:49:51 +0100
Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 3 Dec 2012 09:49:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CDD133.1089F33A"
Date: Mon, 3 Dec 2012 10:49:11 +0200
Message-ID: <999913AB42CC9341B05A99BBF358718D0229C263@FIESEXC035.nsn-intra.net>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Thread-Index: Ac3RMSYGaVK8RKoLSf6cstScO2ztxgAAXk7g
References: 
From: "Tschofenig, Hannes (NSN - FI/Espoo)" 
To: "ext Nat Sakimura" , "Brian Campbell" , "oauth" 
X-OriginalArrivalTime: 03 Dec 2012 08:49:50.0903 (UTC) FILETIME=[280C1470:01CDD133]
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 8666
X-purgate-ID: 151667::1354524595-000010BC-411592C6/0-0/0-0
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 08:50:01 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CDD133.1089F33A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Nat,=20

=20

The current text essentially says that the assertion can either be
created by the client (in which case it is self-signed) or it can be
created by some other entity (which is then called the third party token
service). So, this third party could be the authorization server.=20

=20

Ciao
Hannes

=20

=20

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
Of ext Nat Sakimura
Sent: Monday, December 03, 2012 10:35 AM
To: Brian Campbell; oauth
Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to be
either the client or a third party token service?

=20

Hi Brian,=20
=20
=20
The assertion framework defines the Issuer as:=20
=20
   Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.  The issuer may be either
      an OAuth client (when assertions are self-issued) or a third party
      token service.
=20
I was wondering why it has to be either the client or a third party
token service.=20
Conceptually, it could be any token service (functionality) residing in
any of=20
=20
the stakeholders (Resource Owner, OAuth Client, Authorization Server, or

a third party).=20
=20
=20
I would appreciate if you could clarify why is the case.=20
=20
=20
Best,=20

=20

--=20
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

=20


------_=_NextPart_001_01CDD133.1089F33A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Nat, 
 
The current text essentially says that the assertion can either be =
created by the client (in which case it is self-signed) or it can be =
created by some other entity (which is then called the third party token =
service). So, this third party could be the authorization server. =

 
Ciao
Hannes
 
 
From:=
 =
oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =
ext Nat Sakimura
Sent: Monday, December 03, 2012 10:35 =
AM
To: Brian Campbell; oauth
Subject: [OAUTH-WG] =
Assertion Framework - Why does issuer have to be either the client or a =
third party token service?
 
Hi Brian, 
 
 
The assertion framework defines the Issuer as: =

 
   Issuer  The unique =
identifier for the entity that issued =
the
      =
assertion.  Generally this is the entity that holds the =
key
      material used =
to generate the assertion.  The issuer may be =
either
      an OAuth client =
(when assertions are self-issued) or a third =
party
      token =
service.
 
I was wondering why it has to be either the =
client or a third party token service. =

Conceptually, it could be any token service =
(functionality) residing in any of 
 
the stakeholders (Resource Owner, OAuth =
Client, Authorization Server, or 
a third party). =

 
 
I would appreciate if you could clarify why is =
the case. 
 
 
Best, 
 
-- =

Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=

 

------_=_NextPart_001_01CDD133.1089F33A--

From zhou.sujing@zte.com.cn  Mon Dec  3 00:53:04 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5589B21F88E0; Mon,  3 Dec 2012 00:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.273
X-Spam-Level: 
X-Spam-Status: No, score=-97.273 tagged_above=-999 required=5 tests=[AWL=1.122, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5U+fdTfZOHE; Mon,  3 Dec 2012 00:53:03 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E8F4921F88A4; Mon,  3 Dec 2012 00:52:56 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 3E7C5127ADA7; Mon,  3 Dec 2012 16:54:36 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB38qatP045269; Mon, 3 Dec 2012 16:52:36 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <999913AB42CC9341B05A99BBF358718D0229C263@FIESEXC035.nsn-intra.net>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Mon, 3 Dec 2012 16:52:35 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-03 16:52:37, Serialize complete at 2012-12-03 16:52:37
Content-Type: multipart/alternative; boundary="=_alternative 0030DFA448257AC9_="
X-MAIL: mse01.zte.com.cn qB38qatP045269
Cc: oauth , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 08:53:04 -0000

This is a multipart message in MIME format.
--=_alternative 0030DFA448257AC9_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

Y291bGQgYmUgUmVzb3VyY2Ugb3duZXI/IA0KDQoNCg0KIlRzY2hvZmVuaWcsIEhhbm5lcyAoTlNO
IC0gRkkvRXNwb28pIiA8aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbT4gDQq3orz+yMs6ICBvYXV0
aC1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTEyLTAzIDE2OjQ5DQoNCsrVvP7Iyw0KImV4dCBOYXQg
U2FraW11cmEiIDxzYWtpbXVyYUBnbWFpbC5jb20+LCAiQnJpYW4gQ2FtcGJlbGwiIA0KPGJjYW1w
YmVsbEBwaW5naWRlbnRpdHkuY29tPiwgIm9hdXRoIiA8b2F1dGhAaWV0Zi5vcmc+DQqzrcvNDQoN
Ctb3zOINClJlOiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1
ZXIgaGF2ZSB0byBiZSBlaXRoZXIgdGhlIA0KY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4g
c2VydmljZT8NCg0KDQoNCg0KDQoNCkhpIE5hdCwgDQogDQpUaGUgY3VycmVudCB0ZXh0IGVzc2Vu
dGlhbGx5IHNheXMgdGhhdCB0aGUgYXNzZXJ0aW9uIGNhbiBlaXRoZXIgYmUgY3JlYXRlZCANCmJ5
IHRoZSBjbGllbnQgKGluIHdoaWNoIGNhc2UgaXQgaXMgc2VsZi1zaWduZWQpIG9yIGl0IGNhbiBi
ZSBjcmVhdGVkIGJ5IA0Kc29tZSBvdGhlciBlbnRpdHkgKHdoaWNoIGlzIHRoZW4gY2FsbGVkIHRo
ZSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlKS4gDQpTbywgdGhpcyB0aGlyZCBwYXJ0eSBjb3Vs
ZCBiZSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIA0KIA0KQ2lhbw0KSGFubmVzDQogDQogDQpG
cm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmIE9mIA0KZXh0IE5hdCBTYWtpbXVyYQ0KU2VudDogTW9uZGF5LCBEZWNlbWJl
ciAwMywgMjAxMiAxMDozNSBBTQ0KVG86IEJyaWFuIENhbXBiZWxsOyBvYXV0aA0KU3ViamVjdDog
W09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8g
YmUgDQplaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/DQog
DQpIaSBCcmlhbiwgDQogDQogDQpUaGUgYXNzZXJ0aW9uIGZyYW1ld29yayBkZWZpbmVzIHRoZSBJ
c3N1ZXIgYXM6IA0KIA0KICAgSXNzdWVyICBUaGUgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBl
bnRpdHkgdGhhdCBpc3N1ZWQgdGhlDQogICAgICBhc3NlcnRpb24uICBHZW5lcmFsbHkgdGhpcyBp
cyB0aGUgZW50aXR5IHRoYXQgaG9sZHMgdGhlIGtleQ0KICAgICAgbWF0ZXJpYWwgdXNlZCB0byBn
ZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLiAgVGhlIGlzc3VlciBtYXkgYmUgZWl0aGVyDQogICAgICBh
biBPQXV0aCBjbGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9yIGEgdGhp
cmQgcGFydHkNCiAgICAgIHRva2VuIHNlcnZpY2UuDQogDQpJIHdhcyB3b25kZXJpbmcgd2h5IGl0
IGhhcyB0byBiZSBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIA0Kc2Vy
dmljZS4gDQpDb25jZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBzZXJ2aWNlIChmdW5j
dGlvbmFsaXR5KSByZXNpZGluZyBpbiANCmFueSBvZiANCiANCnRoZSBzdGFrZWhvbGRlcnMgKFJl
c291cmNlIE93bmVyLCBPQXV0aCBDbGllbnQsIEF1dGhvcml6YXRpb24gU2VydmVyLCBvciANCmEg
dGhpcmQgcGFydHkpLiANCiANCiANCkkgd291bGQgYXBwcmVjaWF0ZSBpZiB5b3UgY291bGQgY2xh
cmlmeSB3aHkgaXMgdGhlIGNhc2UuIA0KIA0KIA0KQmVzdCwgDQogDQotLSANCk5hdCBTYWtpbXVy
YSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVy
YS5vcmcvDQpAX25hdF9lbg0KIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K
--=_alternative 0030DFA448257AC9_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmNvdWxkIGJlIFJlc291cmNlIG93
bmVyPyA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2
YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+
PGI+JnF1b3Q7VHNjaG9mZW5pZywgSGFubmVzDQooTlNOIC0gRkkvRXNwb28pJnF1b3Q7ICZsdDto
YW5uZXMudHNjaG9mZW5pZ0Buc24uY29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9
MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO29hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8
L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMi0xMi0wMyAxNjo0
OTwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249
dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp
ZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm
Ij4mcXVvdDtleHQgTmF0IFNha2ltdXJhJnF1b3Q7ICZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7
LA0KJnF1b3Q7QnJpYW4gQ2FtcGJlbGwmcXVvdDsgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHku
Y29tJmd0OywgJnF1b3Q7b2F1dGgmcXVvdDsNCiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2ZvbnQ+
DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh
Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4N
Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3
zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBb
T0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLQ0KV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8g
YmUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZWl0aGVyIHRoZQ0KY2xpZW50IG9yIGEgdGhp
cmQgcGFydHkgdG9rZW4gc2VydmljZT88L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0
ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5IaSBOYXQs
IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj4m
bmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMxZjQ5N2QgZmFjZT0iQ2FsaWJy
aSI+VGhlIGN1cnJlbnQgdGV4dCBlc3NlbnRpYWxseQ0Kc2F5cyB0aGF0IHRoZSBhc3NlcnRpb24g
Y2FuIGVpdGhlciBiZSBjcmVhdGVkIGJ5IHRoZSBjbGllbnQgKGluIHdoaWNoIGNhc2UNCml0IGlz
IHNlbGYtc2lnbmVkKSBvciBpdCBjYW4gYmUgY3JlYXRlZCBieSBzb21lIG90aGVyIGVudGl0eSAo
d2hpY2ggaXMNCnRoZW4gY2FsbGVkIHRoZSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlKS4gU28s
IHRoaXMgdGhpcmQgcGFydHkgY291bGQNCmJlIHRoZSBhdXRob3JpemF0aW9uIHNlcnZlci4gPC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZhY2U9IkNhbGlicmkiPiZuYnNw
OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3ZCBmYWNlPSJDYWxpYnJpIj5D
aWFvPGJyPg0KSGFubmVzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMWY0OTdkIGZh
Y2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzFmNDk3
ZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRh
aG9tYSI+PGI+RnJvbTo8L2I+IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5leHQgTmF0IFNha2ltdXJhPGI+
PGJyPg0KU2VudDo8L2I+IE1vbmRheSwgRGVjZW1iZXIgMDMsIDIwMTIgMTA6MzUgQU08Yj48YnI+
DQpUbzo8L2I+IEJyaWFuIENhbXBiZWxsOyBvYXV0aDxiPjxicj4NClN1YmplY3Q6PC9iPiBbT0FV
VEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZQ0K
ZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPzwvZm9udD4N
Cjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5IaSBCcmlhbiwgPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250
IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhlIGFzc2VydGlvbiBmcmFtZXdvcmsgZGVmaW5lcyB0aGUN
Cklzc3VlciBhczogPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+
Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7
ICZuYnNwO0lzc3VlciAmbmJzcDtUaGUgdW5pcXVlDQppZGVudGlmaWVyIGZvciB0aGUgZW50aXR5
IHRoYXQgaXNzdWVkIHRoZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO
ZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFzc2VydGlvbi4gJm5ic3A7R2VuZXJhbGx5DQp0aGlz
IGlzIHRoZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUga2V5PC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgbWF0ZXJpYWwgdXNlZA0K
dG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gJm5ic3A7VGhlIGlzc3VlciBtYXkgYmUgZWl0aGVy
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNw
OyAmbmJzcDsgYW4gT0F1dGggY2xpZW50DQood2hlbiBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3Vl
ZCkgb3IgYSB0aGlyZCBwYXJ0eTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll
ciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRva2VuIHNlcnZpY2UuPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp
emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+SSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8gYmUg
ZWl0aGVyDQp0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZS4gPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Q29uY2VwdHVhbGx5LCBpdCBj
b3VsZCBiZSBhbnkgdG9rZW4NCnNlcnZpY2UgKGZ1bmN0aW9uYWxpdHkpIHJlc2lkaW5nIGluIGFu
eSBvZiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij50aGUgc3Rha2Vob2xk
ZXJzIChSZXNvdXJjZSBPd25lciwgT0F1dGgNCkNsaWVudCwgQXV0aG9yaXphdGlvbiBTZXJ2ZXIs
IG9yIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPmEgdGhpcmQg
cGFydHkpLiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJz
cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5JIHdvdWxkIGFwcHJlY2lh
dGUgaWYgeW91IGNvdWxkIGNsYXJpZnkNCndoeSBpcyB0aGUgY2FzZS4gPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp
emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm
YWNlPSJDb3VyaWVyIE5ldyI+QmVzdCwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJU
aW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGlt
ZXMgTmV3IFJvbWFuIj4tLSA8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkNoYWlybWFuLCBPcGVuSUQgRm91bmRh
dGlvbjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
Pjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vbmF0LnNha2ltdXJhLm9yZy8gdGFy
Z2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
Pjx1Pmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCkBfbmF0X2VuPC9mb250Pg0KPGJyPjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48dHQ+PGZvbnQgc2l6ZT0y
Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1
dGggbWFpbGluZyBsaXN0PGJyPg0KT0F1dGhAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo=
--=_alternative 0030DFA448257AC9_=--

From sakimura@gmail.com  Mon Dec  3 00:58:29 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BBC21F88E0; Mon,  3 Dec 2012 00:58:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.253
X-Spam-Level: 
X-Spam-Status: No, score=-2.253 tagged_above=-999 required=5 tests=[AWL=-1.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wyfi5PjswH21; Mon,  3 Dec 2012 00:58:28 -0800 (PST)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE60921F88F9; Mon,  3 Dec 2012 00:58:27 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id a1so1174584eaa.31 for ; Mon, 03 Dec 2012 00:58:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type; bh=eiqtUqJloSToDDWE9uBfADKmNJyJNWHqUE7idA6wKRU=; b=Sd3LTnZnBxgzNG/6pxbfiaJgec1rLa4Z+9KEd2LKO9I/7WOh1criRba0W+dDdD0evw 5zUNqT68zH78PCsda1go9hqMYENtqH5Sg07cudhFD+gyARpNRIgH8XTCI/WwXL9M3Gx5 r65OKJCTix5inLLMq3n+0l2nOTxerL31+OwnRUFw27zwm5vshc43wQPF5JomW4yhdRin IZWSSQMCoVq3oAeoEEe80UMFdcgCmKMHz8V+pRafvFBtGFQ6t5/5UqohrKOHNjX418fN xpRjFjiY0h8/0ePORDxk1VV35hc2njfJ78BQzTTgu0eomDWqqzL0OqWoqI6jnCMRbViP sxiQ==
Received: by 10.14.178.196 with SMTP id f44mr34167565eem.14.1354525106928; Mon, 03 Dec 2012 00:58:26 -0800 (PST)
References: 
From: Nat Sakimura 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Date: Mon, 3 Dec 2012 00:58:27 -0800
Message-ID: <1462369564742567140@unknownmsgid>
To: "zhou.sujing@zte.com.cn" 
Content-Type: multipart/alternative; boundary=047d7b622520d67ad104cfeef3bb
Cc: oauth , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 08:58:29 -0000

--047d7b622520d67ad104cfeef3bb
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

I suppose, yes. I was reading it like that all the time.
Whether it is or not, if it is still ok, it might be better to clarify it.
Word like "third party" tends to be a bit of problem without clearly
defining.
I had similar experience in other fora.

Nat

Sent from iPad

2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn"  =A4=
=CE=A5=E1=A5=C3=A5=BB=A9`=A5=B8:


could be Resource owner?


 *"Tschofenig, Hannes (NSN - FI/Espoo)" *
=B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org

2012-12-03 16:49
  =CA=D5=BC=FE=C8=CB
"ext Nat Sakimura" , "Brian Campbell" <
bcampbell@pingidentity.com>, "oauth" 
=B3=AD=CB=CD
  =D6=F7=CC=E2
Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
 either the client or a third party token service?




Hi Nat,

The current text essentially says that the assertion can either be created
by the client (in which case it is self-signed) or it can be created by
some other entity (which is then called the third party token service). So,
this third party could be the authorization server.

Ciao
Hannes


*From:* oauth-bounces@ietf.org
[mailto:oauth-bounces@ietf.org]
*On Behalf Of *ext Nat Sakimura*
Sent:* Monday, December 03, 2012 10:35 AM*
To:* Brian Campbell; oauth*
Subject:* [OAUTH-WG] Assertion Framework - Why does issuer have to be
either the client or a third party token service?

Hi Brian,


The assertion framework defines the Issuer as:

   Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.  The issuer may be either
      an OAuth client (when assertions are self-issued) or a third party
      token service.

I was wondering why it has to be either the client or a third party token
service.
Conceptually, it could be any token service (functionality) residing in any
of

the stakeholders (Resource Owner, OAuth Client, Authorization Server, or
a third party).


I would appreciate if you could clarify why is the case.


Best,

--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation*
**http://nat.sakimura.org/* 
@_nat_en
 _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--047d7b622520d67ad104cfeef3bb
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable


I suppose, yes. I was reading it l=
ike that all the time. 
Whether it is or not, if it is still=
 ok, it might be better to clarify it. 


Word like "third party" tends to be a bit of problem without=
 clearly defining. 
I had similar experience in other fora.&=
nbsp;

Nat

Sent from iPad
<=
br>2012/12/03 0:52=A1=A2"zho=
u.sujing@zte.com.cn" <zhou.sujing@zte.com.cn> =A4=CE=A5=E1=A5=C3=A5=BB=A9`=A5=B8:




could be Resource owner? 










"Tschofenig,=
 Hannes
(NSN - FI/Espoo)" <han=
nes.tschofenig@nsn.com> 

=B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org

2012-12-03 16:49








=CA=D5=BC=FE=C8=
=CB

"ext Nat Sakimura" =
<sakimura@gmail.com>,
"Brian Campbell" <bcampbell@pingidentity.com>, "oauth"
<oauth@ietf.org>




=B3=AD=CB=CD






=D6=F7=CC=E2

Re: [OAUTH-WG] Assertion Fram=
ework -
Why does issuer have to be        either the
client or a third party token service?

















Hi Nat, 

 

The current text essentially
says that the assertion can either be created by the client (in which case
it is self-signed) or it can be created by some other entity (which is
then called the third party token service). So, this third party could
be the authorization server. 

 

Ciao

Hannes

 

 

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of ext Nat Sakimura

Sent: Monday, December 03, 2012 10:35 AM

To: Brian Campbell; oauth

Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to be
either the client or a third party token service?

 

Hi Brian, 

 

 

The assertion framework defines the
Issuer as: 

 

   Issuer  The unique
identifier for the entity that issued the

      assertion.  Genera=
lly
this is the entity that holds the key

      material used
to generate the assertion.  The issuer may be either

      an OAuth client
(when assertions are self-issued) or a third party

      token service.

 

I was wondering why it has to be either
the client or a third party token service. 

Conceptually, it could be any token
service (functionality) residing in any of 

 

the stakeholders (Resource Owner, OAuth
Client, Authorization Server, or 

a third party). 

 

 

I would appreciate if you could clarify
why is the case. 

 

 

Best, 

 

-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.org/=


@_nat_en

 ______=
_________________________________________

OAuth mailing list

OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth







--047d7b622520d67ad104cfeef3bb--

From zhou.sujing@zte.com.cn  Mon Dec  3 01:02:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99AD21F865F for ; Mon,  3 Dec 2012 01:02:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.195
X-Spam-Level: 
X-Spam-Status: No, score=-97.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_48=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVSOiXhkY-9o for ; Mon,  3 Dec 2012 01:02:31 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B6D1121F861C for ; Mon,  3 Dec 2012 01:02:24 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id DD5147BA48 for ; Mon,  3 Dec 2012 17:02:15 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 8DFE1714400; Mon,  3 Dec 2012 17:00:27 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB391wFS080003; Mon, 3 Dec 2012 17:01:58 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: zhou.sujing@zte.com.cn
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Mon, 3 Dec 2012 17:01:57 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-03 17:01:58, Serialize complete at 2012-12-03 17:01:58
Content-Type: multipart/alternative; boundary="=_alternative 0031BB0248257AC9_="
X-MAIL: mse01.zte.com.cn qB391wFS080003
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 09:02:35 -0000

This is a multipart message in MIME format.
--=_alternative 0031BB0248257AC9_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

QW5kIGFub3RoZXIgZGlmZmVyZW5jZSBpcyBteSB1c2UgY2FzZSBjb3VsZCBiZSB0aGF0ICJhc3Nl
cnRpb24iIGJlIA0KZ2VuZXJhdGVkIHNlcXVlbnRpYWxseSBieSByZXNvdXJjZSBvd25lciBhbmQg
Y2xpZW50Lg0KRm9yIGV4YW1wbGUsIHJlc291cmNlIG93bmVyIGRlbGVnYXRlcyBhIGNsaWVudCB0
byBnZW5lcmF0ZSBzaWduYXR1cmUgb24gDQpiZWhhbGYgb2YgaXQsIGNsaWVudCBnZW5lcmF0ZXMg
YSBzaWduYXR1cmUgdXNpbmcgdGhlIHByaXZhdGUga2V5IG9mIA0KaXRzZWxmLA0Kd2hpY2ggaXMg
Y2FsbGVkIHByb3h5IHNpZ25hdHVyZSBpbiBjcnlwdG9ncmFwaHkuIA0KDQoNCg0KPiBNeSB1c2Ug
Y2FzZSBpcyBpbmRlZWQgc2ltaWxhciB0byAgYXNzZXJ0aW9uIGZsb3cgInNlY3Rpb24gNi4zLiAN
Cj4gQ2xpZW50IEFjdGluZyBvbiBCZWhhbGYgb2YgYSBVc2VyIi4NCj4gRGlmZmVyZW5jZXMgYXJl
Og0KPiAxLiAgaWYgbXkgdXNlIGNhc2UgaXMgY2FycmllZCBvdXQgaW4gYXNzZXJ0aW9uIGZyYW1l
d29yaywgInByaWNpcGFsIg0KPiBzaG91bGQgYmUgY2xpZW50LCB3aGlsZSBhc3NlcnRpb24gZG9j
dW1lbnQgZG9lcyBub3QgDQo+IGluY2x1ZGUgY2xpZW50IGFzIGFuIG9wdGlvbiB3aGVuIGNsaWVu
dCBpcyBhY3Rpbmcgb24gYmVoYWxmIG9mIGEgDQo+IHVzZXIocmVzb3VyY2Ugb3duZXIpLCBpdCBz
YXlzICAiIGFuIGF1dGhvcml6ZWQgYWNjZXNzb3IgZm9yIHdoaWNoIHRoZSANCj4gYWNjZXNzIHRv
a2VuIGlzIGJlaW5nIHJlcXVlc3RlZCAodHlwaWNhbGx5IHRoZSByZXNvdXJjZSBvd25lciwgb3Ig
DQo+IGFuIGF1dGhvcml6ZWQgZGVsZWdhdGUpLiINCj4gMi4gIGlmIG15IHVzZSBjYXNlIGlzIGNh
cnJpZWQgb3V0IGluIGFzc2VydGlvbiBmcmFtZXdvcmssICJpc3N1ZXIiIA0KPiBzaG91bGQgYmUg
cmVzb3VyY2Ugb3duZXIsIHdoaWxlIGFzc2VydGlvbiBkb2N1bWVudCBvbmx5IGluY2x1ZGVzIA0K
PiBjbGllbnQgYW5kIHRva2VuIHNlcnZpY2UgDQo+IA0KPiBJbiBteSB1c2UgY2FzZSB0aGUgImFz
c2VydGlvbiIgaXMgbW9yZSBsaWtlIGEgcHJpdmF0ZSBvdXRwdXQsIHdoaWxlIA0KPiBpbiBhc3Nl
cnRpb24gZmxvdyAiYXNzZXJ0aW9uICIgaXMgZ2VuZXJhdGVkIGJ5IGEgdGhyaWQgcGFydHkgdG9r
ZW4gDQo+IHNlcnZpY2Ugb3IgYnkgY2xpZW50IGl0c2VsZi4NCj4gDQo+IE5hdCBTYWtpbXVyYSA8
c2FraW11cmFAZ21haWwuY29tPiANCj4gMjAxMi0xMi0wMyAxNDo0NA0KPiANCj4gytW8/sjLDQo+
IA0KPiB6aG91LnN1amluZ0B6dGUuY29tLmNuDQo+IA0KPiCzrcvNDQo+IA0KPiAib2F1dGhAaWV0
Zi5vcmcgV0ciIDxvYXV0aEBpZXRmLm9yZz4NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBSZTogW09B
VVRILVdHXSBIaSxhbnkgY29tbWVudCBvbiBkcmFmdC16aG91LW9hdXRoLW93bmVyLWF1dGg/DQo+
IA0KPiBZb3VyIHVzZWNhc2Ugc291bmRzIGEgbGl0dGxlIGJpdCBsaWtlIHRoZSBhc3NlcnRpb24g
Zmxvdy4gDQo+IFRoZSBSTyBpc3N1ZXMgYW4gYXNzZXJ0aW9uIGFuZCB0aGUgcmVzdCBnb2VzLiAN
Cj4gSXMgdGhlcmUgcmVhc29ucyB0aGF0IGFuIGFzc2VydGlvbiBmbG93IGNhbm5vdCBkbz8gDQo+
IA0KPiBOYXQNCg0KPiBPbiBNb24sIERlYyAzLCAyMDEyIGF0IDM6MzUgUE0sIDx6aG91LnN1amlu
Z0B6dGUuY29tLmNuPiB3cm90ZToNCj4gbXkgdXNlIGNhc2UoUk8taW5pdGlhdGVkIGRlbGVnYXRp
b24pOiANCj4gLUkgZGVwb3NpdCBteSBjaGlsZChwcmVjaW91cyByZXNvdXJjZSkgYXQga2luZGVy
Z2FyZGVuKFJlc291cmNlIFNlcnZlcikgDQo+IC1JIGRlbGVnYXRlIGEgZmV3IHBlcnNvbnMsZS5n
LiwgZ3JhbmRwYXJlbnRzIG9mIG15IGNoaWxkLCB0byBwaWNrIHVwDQo+IG15IGNoaWxkIGF0IHRo
ZSBraW5kZXJnYXJkZW4gDQo+IC13aGVuIHNvbWVvbmUgdHJpZXMgdG8gdGFrZSBoaW0gb3V0c2lk
ZSBvZiB0aGUga2luZGVyZ2FyZGVuLCAgdGhlIA0KPiB0ZWFjaGVyIHdpbGwgYXNrIGhpbS9oZXIg
dG8gc2hvdyBteSBkZWxlZ2F0aW9uIA0KPiAgc3RhdGVtZW50LCBubyBzdGF0ZW1lbnQsIG5vIHRh
a2luZyBteSBjaGlsZC4gDQo+IA0KDQo+IA0KPiAtLSANCj4gTmF0IFNha2ltdXJhICg9bmF0KQ0K
PiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcv
DQo+IEBfbmF0X2VuDQo=
--=_alternative 0031BB0248257AC9_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpBbmQgYW5vdGhlciBkaWZmZXJlbmNlIGlzIG15
IHVzZSBjYXNlIGNvdWxkIGJlIHRoYXQgJnF1b3Q7YXNzZXJ0aW9uJnF1b3Q7DQpiZSBnZW5lcmF0
ZWQgc2VxdWVudGlhbGx5IGJ5IHJlc291cmNlIG93bmVyIGFuZCBjbGllbnQuPC9mb250PjwvdHQ+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Gb3IgZXhhbXBsZSwgcmVzb3VyY2Ugb3duZXIgZGVsZWdh
dGVzIGEgY2xpZW50IHRvDQpnZW5lcmF0ZSBzaWduYXR1cmUgb24gYmVoYWxmIG9mIGl0LCBjbGll
bnQgZ2VuZXJhdGVzIGEgc2lnbmF0dXJlIHVzaW5nDQp0aGUgcHJpdmF0ZSBrZXkgb2YgaXRzZWxm
LDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+d2hpY2ggaXMgY2FsbGVkIHByb3h5
IHNpZ25hdHVyZSBpbiBjcnlwdG9ncmFwaHkuIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBNeSB1c2UgY2FzZSBpcyBpbmRlZWQgc2ltaWxh
ciB0byAmbmJzcDthc3NlcnRpb24gZmxvdyAmcXVvdDtzZWN0aW9uDQo2LjMuICZuYnNwOzxicj4N
CiZndDsgQ2xpZW50IEFjdGluZyBvbiBCZWhhbGYgb2YgYSBVc2VyJnF1b3Q7LjwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBEaWZmZXJlbmNlcyBhcmU6PC9mb250PjwvdHQ+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDEuICZuYnNwO2lmIG15IHVzZSBjYXNlIGlzIGNh
cnJpZWQgb3V0IGluIGFzc2VydGlvbg0KZnJhbWV3b3JrLCAmcXVvdDtwcmljaXBhbCZxdW90Ozxi
cj4NCiZndDsgc2hvdWxkIGJlIGNsaWVudCwgd2hpbGUgYXNzZXJ0aW9uIGRvY3VtZW50IGRvZXMg
bm90IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBpbmNsdWRlIGNsaWVu
dCBhcyBhbiBvcHRpb24gd2hlbiBjbGllbnQgaXMgYWN0aW5nDQpvbiBiZWhhbGYgb2YgYSA8YnI+
DQomZ3Q7IHVzZXIocmVzb3VyY2Ugb3duZXIpLCBpdCBzYXlzICZuYnNwOyZxdW90OyBhbiBhdXRo
b3JpemVkIGFjY2Vzc29yDQpmb3Igd2hpY2ggdGhlICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyBhY2Nlc3MgdG9rZW4gaXMgYmVpbmcgcmVxdWVzdGVkICh0eXBp
Y2FsbHkgdGhlDQpyZXNvdXJjZSBvd25lciwgb3IgJm5ic3A7PGJyPg0KJmd0OyBhbiBhdXRob3Jp
emVkIGRlbGVnYXRlKS4mcXVvdDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgMi4gJm5ic3A7aWYgbXkgdXNlIGNhc2UgaXMgY2FycmllZCBvdXQgaW4gYXNzZXJ0aW9uDQpm
cmFtZXdvcmssICZxdW90O2lzc3VlciZxdW90OyA8YnI+DQomZ3Q7IHNob3VsZCBiZSByZXNvdXJj
ZSBvd25lciwgd2hpbGUgYXNzZXJ0aW9uIGRvY3VtZW50IG9ubHkgaW5jbHVkZXMgPC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGNsaWVudCBhbmQgdG9rZW4gc2VydmljZSA8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBJbiBteSB1
c2UgY2FzZSB0aGUgJnF1b3Q7YXNzZXJ0aW9uJnF1b3Q7IGlzIG1vcmUgbGlrZSBhIHByaXZhdGUg
b3V0cHV0LA0Kd2hpbGUgPGJyPg0KJmd0OyBpbiBhc3NlcnRpb24gZmxvdyAmcXVvdDthc3NlcnRp
b24gJnF1b3Q7IGlzIGdlbmVyYXRlZCBieSBhIHRocmlkIHBhcnR5DQp0b2tlbiA8YnI+DQomZ3Q7
IHNlcnZpY2Ugb3IgYnkgY2xpZW50IGl0c2VsZi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBOYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNv
bSZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDIwMTItMTItMDMg
MTQ6NDQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDK
1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyB6
aG91LnN1amluZ0B6dGUuY29tLmNuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7IDxicj4NCiZndDsgs63LzTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0
OyA8YnI+DQomZ3Q7ICZxdW90O29hdXRoQGlldGYub3JnIFdHJnF1b3Q7ICZsdDtvYXV0aEBpZXRm
Lm9yZyZndDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0
OyDW98ziPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg
UmU6IFJlOiBbT0FVVEgtV0ddIEhpLGFueSBjb21tZW50IG9uIGRyYWZ0LXpob3Utb2F1dGgtb3du
ZXItYXV0aD88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0
OyBZb3VyIHVzZWNhc2Ugc291bmRzIGEgbGl0dGxlIGJpdCBsaWtlIHRoZSBhc3NlcnRpb24gZmxv
dy4mbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgVGhlIFJPIGlz
c3VlcyBhbiBhc3NlcnRpb24gYW5kIHRoZSByZXN0IGdvZXMuJm5ic3A7PC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IElzIHRoZXJlIHJlYXNvbnMgdGhhdCBhbiBhc3NlcnRp
b24gZmxvdyBjYW5ub3QNCmRvPyZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyA8YnI+DQomZ3Q7IE5hdDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz
aXplPTI+Jmd0OyBPbiBNb24sIERlYyAzLCAyMDEyIGF0IDM6MzUgUE0sICZsdDt6aG91LnN1amlu
Z0B6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IG15IHVzZSBjYXNlKFJPLWluaXRpYXRlZCBkZWxlZ2F0aW9uKTogPGJyPg0KJmd0OyAt
SSBkZXBvc2l0IG15IGNoaWxkKHByZWNpb3VzIHJlc291cmNlKSBhdCBraW5kZXJnYXJkZW4oUmVz
b3VyY2UgU2VydmVyKQ0KPGJyPg0KJmd0OyAtSSBkZWxlZ2F0ZSBhIGZldyBwZXJzb25zLGUuZy4s
IGdyYW5kcGFyZW50cyBvZiBteSBjaGlsZCwgdG8gcGljaw0KdXA8YnI+DQomZ3Q7IG15IGNoaWxk
IGF0IHRoZSBraW5kZXJnYXJkZW4gPGJyPg0KJmd0OyAtd2hlbiBzb21lb25lIHRyaWVzIHRvIHRh
a2UgaGltIG91dHNpZGUgb2YgdGhlIGtpbmRlcmdhcmRlbiwgJm5ic3A7dGhlDQo8YnI+DQomZ3Q7
IHRlYWNoZXIgd2lsbCBhc2sgaGltL2hlciB0byBzaG93IG15IGRlbGVnYXRpb24gPGJyPg0KJmd0
OyAmbmJzcDtzdGF0ZW1lbnQsIG5vIHN0YXRlbWVudCwgbm8gdGFraW5nIG15IGNoaWxkLiA8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyBOYXQgU2Fr
aW11cmEgKD1uYXQpPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IENoYWly
bWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcv
PGJyPg0KJmd0OyBAX25hdF9lbjwvZm9udD48L3R0Pg0K
--=_alternative 0031BB0248257AC9_=--

From ve7jtb@ve7jtb.com  Mon Dec  3 05:17:49 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85CE21F8744 for ; Mon,  3 Dec 2012 05:17:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.539
X-Spam-Level: 
X-Spam-Status: No, score=-1.539 tagged_above=-999 required=5 tests=[AWL=-1.591, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_48=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sURPdd5fnoxG for ; Mon,  3 Dec 2012 05:17:48 -0800 (PST)
Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71E21F8714 for ; Mon,  3 Dec 2012 05:17:48 -0800 (PST)
Received: by mail-yh0-f42.google.com with SMTP id g71so263195yhg.15 for ; Mon, 03 Dec 2012 05:17:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=7gQJecQnPQHp/2b8cMt0lY+2zLmj4M3BIW5QJ7u3eCI=; b=b5zXR3KQ2V7QAQvZkEn11Di7PffuA5h8zwn2mr1tIjJMhZy60AcCcB3PDkwcadUe3m Ee1OYFqZAQgSF82OtlouE66JEyDi9if3m87FmWPJC3CgwSFTmKESE/8OPSQax/1pQZ1b wJs+OBeghxrex6h4Ib6fDMqB0GCiwhZ+xZgqKkY3g7kiaMvNVgOs1ZUds0/vGmVpn6Uf HwCx2nldSiJ4e8RF4+iMbRSc9kX3UdhgvjPN0nRiuvyBUIj4bco0BhptFBTz/w7VNtCG dUCT9z1d4GS4ZJgSjKXd/jeuUEByA7TFeAaYswIoYG1YSj8MOWXpCSU39oT4smMP4RBn /GVQ==
Received: by 10.236.186.105 with SMTP id v69mr10019890yhm.128.1354540668007; Mon, 03 Dec 2012 05:17:48 -0800 (PST)
Received: from [192.168.1.211] (190-20-29-186.baf.movistar.cl. [190.20.29.186]) by mx.google.com with ESMTPS id e24sm12985149yhh.4.2012.12.03.05.17.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 05:17:46 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_5580A445-2C5D-4E55-9475-88D8DEE144A2"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 3 Dec 2012 10:17:38 -0300
Message-Id: <99EAA8F4-D10A-4657-91A5-0A6BD311DD95@ve7jtb.com>
References: 
To: zhou.sujing@zte.com.cn
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQn5vaBAPvndgMVdJ+/ql3VX4Bk2LIW21IfXI0/X3AgEQ1VRCxsI8GR6lyYVl85qkNRVg/QS
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 13:17:49 -0000

--Apple-Mail=_5580A445-2C5D-4E55-9475-88D8DEE144A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=GB2312

That may relate more to the proof of possession discussion.

You may want to submit that as a use case.

John B.
On 2012-12-03, at 6:01 AM, zhou.sujing@zte.com.cn wrote:

>=20
>=20
> And another difference is my use case could be that "assertion" be =
generated sequentially by resource owner and client.=20
> For example, resource owner delegates a client to generate signature =
on behalf of it, client generates a signature using the private key of =
itself,=20
> which is called proxy signature in cryptography.=20
>=20
>=20
>=20
> > My use case is indeed similar to  assertion flow "section 6.3. =20
> > Client Acting on Behalf of a User".=20
> > Differences are:=20
> > 1.  if my use case is carried out in assertion framework, "pricipal"
> > should be client, while assertion document does not=20
> > include client as an option when client is acting on behalf of a=20
> > user(resource owner), it says  " an authorized accessor for which =
the  =20
> > access token is being requested (typically the resource owner, or =20=

> > an authorized delegate)."=20
> > 2.  if my use case is carried out in assertion framework, "issuer"=20=

> > should be resource owner, while assertion document only includes=20
> > client and token service=20
> >=20
> > In my use case the "assertion" is more like a private output, while=20=

> > in assertion flow "assertion " is generated by a thrid party token=20=

> > service or by client itself.=20
> >=20
> > Nat Sakimura =20
> > 2012-12-03 14:44=20
> >=20
> > =CA=D5=BC=FE=C8=CB=20
> >=20
> > zhou.sujing@zte.com.cn=20
> >=20
> > =B3=AD=CB=CD=20
> >=20
> > "oauth@ietf.org WG" =20
> >=20
> > =D6=F7=CC=E2=20
> >=20
> > Re: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth?=20
> >=20
> > Your usecase sounds a little bit like the assertion flow. =20
> > The RO issues an assertion and the rest goes. =20
> > Is there reasons that an assertion flow cannot do? =20
> >=20
> > Nat
>=20
> > On Mon, Dec 3, 2012 at 3:35 PM,  wrote:=20
> > my use case(RO-initiated delegation):=20
> > -I deposit my child(precious resource) at kindergarden(Resource =
Server)=20
> > -I delegate a few persons,e.g., grandparents of my child, to pick up
> > my child at the kindergarden=20
> > -when someone tries to take him outside of the kindergarden,  the=20
> > teacher will ask him/her to show my delegation=20
> >  statement, no statement, no taking my child.=20
> >=20
>=20
> >=20
> > --=20
> > Nat Sakimura (=3Dnat)=20
> > Chairman, OpenID Foundation
> > http://nat.sakimura.org/
> > @_nat_en _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_5580A445-2C5D-4E55-9475-88D8DEE144A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=GB2312

That =
may relate more to the proof of possession =
discussion.

You may want to submit that as a use =
case.

John B.
On 2012-12-03, at =
6:01 AM, zhou.sujing@zte.com.cn =
wrote:





And another difference is my use case could be that "assertion"
be generated sequentially by resource owner and client.

For example, resource owner delegates a client =
to
generate signature on behalf of it, client generates a signature using
the private key of itself,

which is called proxy signature in =
cryptography. 







> My use case is indeed similar to  assertion flow "section
6.3.  

> Client Acting on Behalf of a User".

> Differences are:

> 1.  if my use case is carried out in =
assertion
framework, "pricipal"

> should be client, while assertion document does not 

> include client as an option when client is =
acting
on behalf of a 

> user(resource owner), it says  " an authorized accessor
for which the  

> access token is being requested (typically =
the
resource owner, or  

> an authorized delegate)."

> 2.  if my use case is carried out in =
assertion
framework, "issuer" 

> should be resource owner, while assertion document only includes =


> client and token service 

> 

> In my use case the "assertion" is more like a private output,
while 

> in assertion flow "assertion " is generated by a thrid party
token 

> service or by client itself.

> 

> Nat Sakimura <sakimura@gmail.com> =


> 2012-12-03 14:44

> 

> =CA=D5=BC=FE=C8=CB

> 

> zhou.sujing@zte.com.cn

> 

> =B3=AD=CB=CD

> 

> "oauth@ietf.org WG" <oauth@ietf.org>

> 

> =D6=F7=CC=E2

> 

> Re: Re: [OAUTH-WG] Hi,any comment on =
draft-zhou-oauth-owner-auth?

> 

> Your usecase sounds a little bit like the assertion =
flow. 

> The RO issues an assertion and the rest =
goes. 

> Is there reasons that an assertion flow =
cannot
do? 

> 

> Nat



> On Mon, Dec 3, 2012 at 3:35 PM, <zhou.sujing@zte.com.cn>
wrote:

> my use case(RO-initiated delegation): 

> -I deposit my child(precious resource) at kindergarden(Resource =
Server)


> -I delegate a few persons,e.g., grandparents of my child, to pick
up

> my child at the kindergarden 

> -when someone tries to take him outside of the kindergarden, =
 the


> teacher will ask him/her to show my delegation 

>  statement, no statement, no taking my child. 

> 



> 

> -- 

> Nat Sakimura (=3Dnat)

> Chairman, OpenID Foundation

> http://nat.sakimura.org/
=

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

=

--Apple-Mail=_5580A445-2C5D-4E55-9475-88D8DEE144A2--

From aanganes@mitre.org  Mon Dec  3 06:26:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B8B21F85CD for ; Mon,  3 Dec 2012 06:26:35 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9MK4RkXoJHY for ; Mon,  3 Dec 2012 06:26:34 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8225521F85AA for ; Mon,  3 Dec 2012 06:26:34 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C52A7439001C for ; Mon,  3 Dec 2012 09:26:33 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A5A4E1F04C0 for ; Mon,  3 Dec 2012 09:26:33 -0500 (EST)
Received: from IMCMBX04.MITRE.ORG ([169.254.4.141]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Mon, 3 Dec 2012 09:26:33 -0500
From: "Anganes, Amanda L" 
To: "Richer, Justin P." , "oauth@ietf.org WG" 
Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-00.txt
Thread-Index: AQHNzM8rmNsVi0Uwi0mDHLc7BRzb4JgHKsMA
Date: Mon, 3 Dec 2012 14:26:33 +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.5.121010
x-originating-ip: [10.146.16.23]
Content-Type: multipart/alternative; boundary="_000_B61A05DAABADEA4EA2F19424825286FA1E649BB5IMCMBX04MITREOR_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 14:26:36 -0000

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

A couple of nits: in section 2.3 you have all of the responses labeled as "=
requests"
"Following is a non-normative example request (with line wraps for

   display purposes only):"


I think those should be labeled as example responses.

--
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
781-271-3103
aanganes@mitre.org

From: , Justin Richer >
Date: Tuesday, November 27, 2012 1:46 PM
To: "oauth@ietf.org" >
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-in=
trospection-00.txt

I took some time this morning to put together a draft of Token Introspectio=
n. This is largely based on how we implemented it here a few years ago, and=
 I'm hoping that this and the Ping draft can help move the conversation abo=
ut introspection forward.

 -- Justin

Begin forwarded message:

From: >
Subject: New Version Notification for draft-richer-oauth-introspection-00.t=
xt
Date: November 27, 2012 1:44:01 PM EST
To: >


A new version of I-D, draft-richer-oauth-introspection-00.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename: draft-richer-oauth-introspection
Revision: 00
Title: OAuth Token Introspection
Creation date: 2012-11-27
WG ID: Individual Submission
Number of pages: 6
URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-int=
rospection-00.txt
Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introsp=
ection
Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspectio=
n-00


Abstract:
  This specification defines a method for a client or protected
  resource to query an OAuth authorization server to determine meta-
  information about an OAuth token.





The IETF Secretariat



--_000_B61A05DAABADEA4EA2F19424825286FA1E649BB5IMCMBX04MITREOR_
Content-Type: text/html; charset="us-ascii"
Content-ID: <55AB8DE31677F9468C6C3ECE48A8A268@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable











A couple of nits: in section 2.3 you have all of the responses labeled=
 as "requests" 


"=
Following is a non-normative example request (with line wraps fo=
r


   display purposes only):"









I think those should be labeled as example responses. 







--




Amanda Anganes


Info Sys Engineer, G061


The MITRE Corporation


781-271-3103


aanganes@mitre.org



















From: <Richer>, Justin Richer=
 <jricher@mitre.org>

Date: Tuesday, November 27, 2012 1:=
46 PM

To: "oauth@ietf.org" <oau=
th@ietf.org>

Subject: [OAUTH-WG] Fwd: New Versio=
n Notification for draft-richer-oauth-introspection-00.txt












I took some time this morning to put together a draft of Token Introspectio=
n. This is largely based on how we implemented it here a few years ago, and=
 I'm hoping that this and the Ping draft can help move the conversation abo=
ut introspection forward.






 -- Justin





Begin forwarded message:







From:
<<=
a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=






Subject:
Ne=
w Version Notification for draft-richer-oauth-introspection-00.txt





Date:
Novem=
ber 27, 2012 1:44:01 PM EST





To:
<<=
a href=3D"mailto:jricher@mitre.org">jricher@mitre.org>








A new version of I-D, draft-richer-oauth-introspection-00.txt

has been successfully submitted by Justin Richer and posted to the

IETF repository.



Filename: d=
raft-richer-oauth-introspection

Revision: 0=
0

Title: OAuth Token Int=
rospection

Creation date: 2012-11-27

WG ID: Individual Subm=
ission

Number of pages: 6

URL:            &nbs=
p;http://www.ietf.org/internet-drafts/draft-richer-oauth-intro=
spection-00.txt

Status:          http://data=
tracker.ietf.org/doc/draft-richer-oauth-introspection

Htmlized:        http://tools.ietf.org/h=
tml/draft-richer-oauth-introspection-00





Abstract:

  This specification defines a method for a client or protected
  resource to query an OAuth authorization server to determine me=
ta-

  information about an OAuth token.











The IETF Secretariat





















--_000_B61A05DAABADEA4EA2F19424825286FA1E649BB5IMCMBX04MITREOR_--

From jricher@mitre.org  Mon Dec  3 07:01:16 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 134AA21F8475 for ; Mon,  3 Dec 2012 07:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.855
X-Spam-Level: 
X-Spam-Status: No, score=-5.855 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_210=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFuPMTfjL5Xl for ; Mon,  3 Dec 2012 07:01:15 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C4BA221F842F for ; Mon,  3 Dec 2012 07:01:14 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 23CAD4350215 for ; Mon,  3 Dec 2012 10:01:14 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 110D31F0874 for ; Mon,  3 Dec 2012 10:01:14 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 3 Dec 2012 10:01:13 -0500
Message-ID: <50BCBE5A.9050703@mitre.org>
Date: Mon, 3 Dec 2012 09:59:38 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Anganes, Amanda L" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------090909090804070203020501"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 15:01:16 -0000

--------------090909090804070203020501
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Thanks, likely a copy-paste error.

  -- Justin

On 12/03/2012 09:26 AM, Anganes, Amanda L wrote:
> A couple of nits: in section 2.3 you have all of the responses labeled 
> as "requests"
> "Following is a non-normative example request (with line wraps for
>     display purposes only):"
> I think those should be labeled as example responses.
>
> --
> Amanda Anganes
> Info Sys Engineer, G061
> The MITRE Corporation
> 781-271-3103
> aanganes@mitre.org
>
> From: , Justin Richer  >
> Date: Tuesday, November 27, 2012 1:46 PM
> To: "oauth@ietf.org "  >
> Subject: [OAUTH-WG] Fwd: New Version Notification for 
> draft-richer-oauth-introspection-00.txt
>
> I took some time this morning to put together a draft of Token 
> Introspection. This is largely based on how we implemented it here a 
> few years ago, and I'm hoping that this and the Ping draft can help 
> move the conversation about introspection forward.
>
>  -- Justin
>
> Begin forwarded message:
>
>> *From: *>
>> *Subject: **New Version Notification for 
>> draft-richer-oauth-introspection-00.txt*
>> *Date: *November 27, 2012 1:44:01 PM EST
>> *To: *>
>>
>>
>> A new version of I-D, draft-richer-oauth-introspection-00.txt
>> has been successfully submitted by Justin Richer and posted to the
>> IETF repository.
>>
>> Filename:draft-richer-oauth-introspection
>> Revision:00
>> Title:OAuth Token Introspection
>> Creation date:2012-11-27
>> WG ID:Individual Submission
>> Number of pages: 6
>> URL: 
>> http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt
>> Status: http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>> Htmlized: http://tools.ietf.org/html/draft-richer-oauth-introspection-00
>>
>>
>> Abstract:
>>   This specification defines a method for a client or protected
>>   resource to query an OAuth authorization server to determine meta-
>>   information about an OAuth token.
>>
>>
>>
>>
>>
>> The IETF Secretariat
>>
>


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


  
    
  
  
    
Thanks, likely a copy-paste error.

      

       -- Justin

      

      On 12/03/2012 09:26 AM, Anganes, Amanda L wrote:

    

    

      
      

        

          
A couple of nits: in section 2.3 you have all of the
            responses labeled as "requests" 

          
"Following is a non-normative example
              request (with line wraps for

          
   display purposes only):"

          

          

            

              
I think those should be labeled as example
                responses. 

              


              

              
--

              

                
Amanda Anganes

                
Info Sys Engineer, G061

                
The MITRE Corporation

                
781-271-3103

                
              

            

          

        

      

      


      

      
        

          From: <Richer>,
          Justin Richer <jricher@mitre.org>

          Date: Tuesday, November
          27, 2012 1:46 PM

          To: "oauth@ietf.org"
          <oauth@ietf.org>

          Subject: [OAUTH-WG]
          Fwd: New Version Notification for
          draft-richer-oauth-introspection-00.txt

        

        


        

        

          

            I took some time this morning to put together a draft of
            Token Introspection. This is largely based on how we
            implemented it here a few years ago, and I'm hoping that
            this and the Ping draft can help move the conversation about
            introspection forward.
            


            

            
 -- Justin

              


                
Begin forwarded message:

                

                

                  
                  

                    Subject:
                      New Version Notification for
                        draft-richer-oauth-introspection-00.txt

                    

                  

                    Date:
                      November 27, 2012 1:44:01 PM
                      EST

                    

                  
                  

                  


                    A new version of I-D,
                    draft-richer-oauth-introspection-00.txt

                    has been successfully submitted by Justin Richer and
                    posted to the

                    IETF repository.

                    

                    Filename: draft-richer-oauth-introspection

                    Revision: 00

                    Title: OAuth
                    Token Introspection

                    Creation date: 2012-11-27

                    WG ID: Individual
                    Submission

                    Number of pages: 6

                    URL:             http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.txt

                    Status:          http://datatracker.ietf.org/doc/draft-richer-oauth-introspection

                    Htmlized:        http://tools.ietf.org/html/draft-richer-oauth-introspection-00

                    

                    

                    Abstract:

                      This specification defines a method for a client
                    or protected

                      resource to query an OAuth authorization server to
                    determine meta-

                      information about an OAuth token.

                    

                    

                    

                    

                    

                    The IETF Secretariat

                    

                  

                

              

              

            

          

        

      
    

    

  


--------------090909090804070203020501--

From jricher@mitre.org  Mon Dec  3 07:31:05 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A6F21F842E for ; Mon,  3 Dec 2012 07:31:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.424
X-Spam-Level: 
X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnkLBwNdbqZr for ; Mon,  3 Dec 2012 07:31:02 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 81FF121F8863 for ; Mon,  3 Dec 2012 07:30:55 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 96B5E43900A6 for ; Mon,  3 Dec 2012 10:30:53 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3582A4510026 for ; Mon,  3 Dec 2012 10:30:53 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 3 Dec 2012 10:30:52 -0500
Message-ID: <50BCC54D.5060609@mitre.org>
Date: Mon, 3 Dec 2012 10:29:17 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Anganes, Amanda L" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040601050608070009060206"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 15:31:05 -0000

--------------040601050608070009060206
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

An early draft of the revocation spec had this token type field, for 
this purpose. From an early conversation on the list with Torsten, we 
decided that most of the time it didn't matter, as different classes of 
token would be recognizable as different by the AS. In some 
implementations (like ours), this means checking different token stores 
in parallel for a given token value. In other implementations, they can 
key on something in the token to make the search more simple.

But one of the reasons behind not having a "token type" parameter any 
more is that OAuth core defines two token classes: access and refresh. 
OpenID Connect adds another type, the id token. UMA adds a whole range 
of other types, from host access tokens and onward. Even dynamic 
registration adds a new class, the registration access token. So the 
problem is how do we manage all of these classes? Right now, the answer 
is "punt" by not having the field and putting the weight on the AS. But 
maybe we can revisit this decision with a bit more deployment experience.

The way I see it, we've got a few options:

1) Leave it as-is, with no field. Client/RS/whoever just sends the token 
over and it's the AS's problem.
2) Define a required field with "access" and "refresh" value semantics, 
and state that other values MAY be accepted by a given AS, or defined by 
extension protocols. These extension values MUST be fully qualified URIs.
3) Same as #2, but with IANA registry to allow for non-collision of 
short names.
4) Define an optional field that the client MAY send as a hint to the 
AS, and it's up to the AS to figure out if it makes any sense in the 
context of the request. All bets are off as to the content of this 
field, other than "it's a string".

There may be other approaches as well.

  -- Justin

On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:
> Here is my review of the Toke Revocation draft 
> (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>
> Section 1. Introduction
> First paragraph has the following definition in it: "A token is the 
> external representation of an access grant issued by a resource owner 
> to a particular client." This seems a bit odd to me. The OAuth2 spec 
> [1] defines "access token" as "An access token is a string 
> representing an authorization issued to the client." (section 1.4) and 
> "refresh token" as "credentials used to obtain access tokens (section 
> 1.5). Should this spec borrow similar language to be more consistent?
>
> Paragraph 2 "From an end-user's perception" should be "From an 
> end-user's perspective".
>
> Section 2. Token Revocation
> What is the reason for requiring the service provider to detect the 
> token type automatically? For our implementation, Access Tokens, 
> Refresh Tokens, and ID Tokens are all structured tokens (with unique 
> structures across the three types), and as such are stored in 3 
> separate database tables. In order to "detect" the token type, we 
> would need to run a get-by-value query across all three tables, check 
> if any of those queries returned anything, and then proceed to revoke 
> the token (if one was found). This does not seem ideal to me.
>
> The spec says that "The authorization server first validates the 
> client credentials (in case of a confidential client) and verifies 
> whether the client is authorized to revoke the particular token." What 
> does this verification entail? Does it just mean that 1) the client 
> credentials must validate and 2) the token must belong to the client 
> requesting the revocation? If so I think the text should be clarified 
> to reflect that. Or are you thinking of a case where a client might 
> not be allowed to revoke its own tokens, via some kind of scoping?
>
> 2.1 Cross Origin Support
> Formatting looks a little off here, otherwise this section looks fine.
>
> 5. Security Considerations
> Paragraph 3 (Malicious clients...): "Appropriate countermeasures, 
> which should be in place for the token endpoint as well, MUST be 
> applied to the revocation endpoint." These countermeasures should be 
> referenced to the proper section(s) of the OAuth core spec or Threat 
> Model document.
>
> Paragraph 4 reads a bit oddly. Suggest following rewording:
> "A malicious client may attempt to guess valid tokens on this endpoint 
> by making revocation requests against potential token strings. 
> According to this specification, a client's request must contain a 
> valid client_id, in the case of a public client, or valid client 
> credentials, in the case of a confidential client. The token being 
> revoked must also belong to the requesting client. If an attacker is 
> able to successfully guess a public client's client_id and one of 
> their tokens, or a private client's credentials and one of their 
> tokens, they could do much worse damage by using the token elsewhere 
> than by revoking it. If they chose to revoke the token, the legitimate 
> client will lose its authorization and will need to prompt the user 
> again. No further damage is done and the guessed token is now worthless."
>
> References:
> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>
> -- 
> Amanda Anganes
> Info Sys Engineer, G061
> The MITRE Corporation
> 781-271-3103
> aanganes@mitre.org
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    
An early draft of the revocation spec
      had this token type field, for this purpose. From an early
      conversation on the list with Torsten, we decided that most of the
      time it didn't matter, as different classes of token would be
      recognizable as different by the AS. In some implementations (like
      ours), this means checking different token stores in parallel for
      a given token value. In other implementations, they can key on
      something in the token to make the search more simple. 

      

      But one of the reasons behind not having a "token type" parameter
      any more is that OAuth core defines two token classes: access and
      refresh. OpenID Connect adds another type, the id token. UMA adds
      a whole range of other types, from host access tokens and onward.
      Even dynamic registration adds a new class, the registration
      access token. So the problem is how do we manage all of these
      classes? Right now, the answer is "punt" by not having the field
      and putting the weight on the AS. But maybe we can revisit this
      decision with a bit more deployment experience.

      

      The way I see it, we've got a few options:

      

      1) Leave it as-is, with no field. Client/RS/whoever just sends the
      token over and it's the AS's problem.

      2) Define a required field with "access" and "refresh" value
      semantics, and state that other values MAY be accepted by a given
      AS, or defined by extension protocols. These extension values MUST
      be fully qualified URIs.

      3) Same as #2, but with IANA registry to allow for non-collision
      of short names.

      4) Define an optional field that the client MAY send as a hint to
      the AS, and it's up to the AS to figure out if it makes any sense
      in the context of the request. All bets are off as to the content
      of this field, other than "it's a string".

      

      There may be other approaches as well.

      

       -- Justin

      

      On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:

    

    

      
      

        

          

            Here is my review of the Toke Revocation draft (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):

          

            

          

          

            Section 1. Introduction

          
First
              paragraph has the following definition in it: "A token is
              the external representation of an access grant
              issued by a resource owner to a particular client." This
              seems a bit odd to me. The OAuth2 spec
              [1] defines "access token" as "An
            access token is a string
              representing an authorization issued to the client." (section 1.4) and "refresh
              token" as "credentials used to obtain access tokens
              (section 1.5). Should this spec borrow similar language to
              be more consistent?

          


            

          
Paragraph 2 "From an end-user's
              perception" should be "From an end-user's perspective".

          


            

          
Section 2. Token Revocation

          
What is the reason for requiring the
              service provider to detect the token type automatically?
              For our implementation, Access Tokens, Refresh Tokens, and
              ID Tokens are all structured tokens (with unique
              structures across the three types), and as such are stored
              in 3 separate database tables. In order to "detect" the
              token type, we would need to run a get-by-value query
              across all three tables, check if any of those queries
              returned anything, and then proceed to revoke the token
              (if one was found). This does not seem ideal to me.
            

          


            

          
The
              spec says that "The authorization server first validates
              the client credentials (in case of a confidential client)
              and verifies whether the client is authorized to revoke
              the particular token." What does this verification entail?
              Does it just mean that 1) the client credentials must
              validate and 2) the token must belong to the client
              requesting the revocation? If so I think the text should
              be clarified to reflect that. Or are you thinking of a
              case where a client might not be allowed to revoke its own
              tokens, via some kind of scoping?
            

          


            

          

            2.1 Cross Origin Support

          

            Formatting looks a little off here, otherwise this section
            looks fine.

          

            

          

          

            5. Security Considerations

          

            Paragraph 3 (Malicious clients…): "Appropriate
            countermeasures, which should be in place for the token
            endpoint as well, MUST be applied to the revocation
            endpoint." These countermeasures should be referenced to the
            proper section(s) of the OAuth core spec or Threat Model
            document. 

          

            

          

          

            Paragraph 4 reads a bit oddly. Suggest following rewording:

          

            "A
            malicious client may attempt to guess valid tokens on this
            endpoint by making revocation requests against potential
            token strings. According to this specification, a client's
            request must contain a valid client_id, in the case of a
            public client, or valid client credentials, in the case of a
            confidential client. The token being revoked must also
            belong to the requesting client. If an attacker is able to
            successfully guess a public client's client_id and one of
            their tokens, or a private client's credentials and one of
            their tokens, they could do much worse damage by using the
            token elsewhere than by revoking it. If they chose to revoke
            the token, the legitimate client will lose its authorization
            and will need to prompt the user again. No further damage is
            done and the guessed token is now worthless." 

          

            

          

          

            References:

          
          

            

          

          

            

              
-- 

              

                
Amanda Anganes

                
Info Sys Engineer, G061

                
The MITRE Corporation

                
781-271-3103

                
              

            

          

        

      

      

      

      

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


    

    

  


--------------040601050608070009060206--

From aanganes@mitre.org  Mon Dec  3 08:57:19 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5A421F886C for ; Mon,  3 Dec 2012 08:57:19 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfYtjGjd9ybz for ; Mon,  3 Dec 2012 08:57:19 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D08F721F8864 for ; Mon,  3 Dec 2012 08:57:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7F3C01F04BF for ; Mon,  3 Dec 2012 11:57:12 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 5607E1F04C4 for ; Mon,  3 Dec 2012 11:57:12 -0500 (EST)
Received: from IMCMBX04.MITRE.ORG ([169.254.4.141]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Mon, 3 Dec 2012 11:57:11 -0500
From: "Anganes, Amanda L" 
To: "Richer, Justin P." , "oauth@ietf.org WG" 
Thread-Topic: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dyn-reg-02.txt
Thread-Index: AQHN0Xc840Mlvfa5eUG2KNMV2lZYkQ==
Date: Mon, 3 Dec 2012 16:57:10 +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.5.121010
x-originating-ip: [10.146.16.23]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-ietf-oauth-dyn-reg-02.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 16:57:19 -0000

Comments:

Introduction, first sentence is awkward. Change from
	In some use-case scenarios, it is desirable or necessary to allow OAuth
clients to obtain authorization from an OAuth authorization server without
the two parties having previously interacted.

To
	In some scenarios, it is desirable or necessary to allow OAuth clients to
obtain authorization from an OAuth authorization server without requiring
the two parties to interact beforehand in order to register the client.

Section 2:

* definition of token_endpoint_auth_method values, definition of
"client_secret_jwt" has "semetric secret" which should be "symmetric
secret".

* definition of jwk_url says that it is OPTIONAL but that if
jwk_encryption_url is not provided, the key at jwk_url will be used for
both encryption and signing. If this is optional, then what happens if
neither of these parameters are defined? Should that be explicitly called
out, if the "jwk but no jwk encryption" case is?

* definition of x509_url - same comment as above. Calls out one specific
case (x509 but no x509 encryption) but does not call out what happens if
x509_url is not specified.

Section 3:

Reorder the following paragraphs so that the 3rd (describing a potential
initial access token) is first, the 2nd stays where it is, and the first
is 3rd.

From:
------
In order to facilitate registered clients updating their information,
   the Client Registration Endpoint issues a request_access_token for
   clients to securely identify themselves in future connections.  As
   such, the Endpoint MUST accept requests with OAuth 2.0 Bearer Tokens
   [RFC6750] for these operations.

   In order to support open registration and facilitate wider
   interoperability, the Client Registration Endpoint SHOULD allow
   client_register requests with no further authentication.  These
   requests MAY be rate-limited to prevent a denial-of-service attack on
   the Client Registration Endpoint.

   In addition, the Client Registration Endpoint MAY accept an initial
   authorization credential in the form of an OAuth 2.0 [RFC6749] access
   token in order to limit registration to only previously authorized
   parties.  The method by which this access token is obtained by the
   registrant is generally out-of-band and is out of scope of this
   Specification.

-------
To:
-------
The Client Registration Endpoint MAY accept an initial
authorization credential in the form of an OAuth 2.0 [RFC6749] access
token in order to limit registration to only previously authorized
parties. The method by which this access token is obtained by the
registrant is generally out-of-band and is out of scope of this
Specification.


In order to support open registration and facilitate wider
interoperability, the Client Registration Endpoint SHOULD allow
client_register requests with no further authentication. These
requests MAY be rate-limited to prevent a denial-of-service attack on
the Client Registration Endpoint.


In order to facilitate registered clients updating their information,
the Client Registration Endpoint issues a request_access_token for
clients to securely identify themselves in future connections. As
such, the Endpoint MUST accept requests with OAuth 2.0 Bearer Tokens
[RFC6750] for these operations.
-------


That way they are in chronological request order, which flows better.

Section 3.4 editor's note: I think it would make sense for the response to
contain the entire client metadata listing.

Section 3.5 access token definition - use same wording as in 3.3. Wording
here is slightly different, wording in 3.3 is better.

Section 5 paragraph 4, last sentence reads: "...especially if they're
dynamically registered, have not been trusted by any users at the
Authorization Server before", should be "=8Aespecially if they're
dynamically registered and have not been trusted by any users at the
Authorization Server before".

--=20
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
781-271-3103
aanganes@mitre.org



From:  , Justin Richer 
Date:  Tuesday, November 27, 2012 6:00 PM
To:  "oauth@ietf.org" 
Subject:  [OAUTH-WG] Fwd: New Version Notification
for	draft-ietf-oauth-dyn-reg-02.txt


Updated dynamic registration draft, thanks to everyone for the comments so
far. Keep them coming, I think we've still got a little ways to go.

 -- Justin

Begin forwarded message:


From:


Subject:
New Version Notification for draft-ietf-oauth-dyn-reg-02.txt

Date:
November 27, 2012 5:58:43 PM EST

To:


Cc:
, , 



A new version of I-D, draft-ietf-oauth-dyn-reg-02.txt
has been successfully submitted by Justin Richer and posted to the
IETF repository.

Filename: draft-ietf-oauth-dyn-reg
Revision: 02
Title: OAuth Dynamic Client Registration Protocol
Creation date: 2012-11-27
WG ID: oauth
Number of pages: 19
URL:            =20
http://www.ietf.org/internet-drafts/draft-ietf-oauth-dyn-reg-02.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
Htmlized:        http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-02
Diff:           =20
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-dyn-reg-02

Abstract:
  This specification defines an endpoint and protocol for dynamic
  registration of OAuth Clients at an Authorizaiton Server.




The IETF Secretariat








From igor.faynberg@alcatel-lucent.com  Mon Dec  3 09:30:58 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8573F21F887C for ; Mon,  3 Dec 2012 09:30:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.148
X-Spam-Level: 
X-Spam-Status: No, score=-4.148 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45,  RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-B3XRcnijbw for ; Mon,  3 Dec 2012 09:30:57 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8978E21F8863 for ; Mon,  3 Dec 2012 09:30:57 -0800 (PST)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id qB3HUu0G018733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Dec 2012 11:30:56 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id qB3HUuvS030015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 3 Dec 2012 11:30:56 -0600
Received: from [135.222.232.243] (USMUYN0L055118.mh.lucent.com [135.222.232.243]) by umail.lucent.com (8.13.8/TPES) with ESMTP id qB3HUtu2004320; Mon, 3 Dec 2012 11:30:55 -0600 (CST)
Message-ID: <50BCE1CF.2000202@alcatel-lucent.com>
Date: Mon, 03 Dec 2012 12:30:55 -0500
From: Igor Faynberg 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: oauth@ietf.org
References:  <1462369564742567140@unknownmsgid>
In-Reply-To: <1462369564742567140@unknownmsgid>
Content-Type: multipart/alternative; boundary="------------090300010107060206020906"
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 17:30:58 -0000

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

Actually, I think it is a good time to start looking at the resourse
owner issuing assertions@ (Interestingly enough, Hui-Lan had brought
this up a couple of years ago.)

Igor

On 12/3/2012 3:58 AM, Nat Sakimura wrote:
> I suppose, yes. I was reading it like that all the time.
> Whether it is or not, if it is still ok, it might be better to clarify
> it.
> Word like "third party" tends to be a bit of problem without clearly
> defining.
> I had similar experience in other fora.
>
> Nat
>
> Sent from iPad
>
> 2012/12/03 0:52"zhou.sujing@zte.com.cn
> "  > Υå`:
>
>>
>> could be Resource owner?
>>
>>
>> *"Tschofenig, Hannes (NSN - FI/Espoo)" > >*
>> : oauth-bounces@ietf.org 
>>
>> 2012-12-03 16:49
>>
>> 	
>> ռ
>> 	"ext Nat Sakimura" >,
>> "Brian Campbell" > >, "oauth" > >
>> 
>> 	
>> 
>> 	Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
>> either the client or a third party token service?
>>
>>
>>
>> 	
>>
>>
>>
>>
>>
>> Hi Nat,
>>
>> The current text essentially says that the assertion can either be
>> created by the client (in which case it is self-signed) or it can be
>> created by some other entity (which is then called the third party
>> token service). So, this third party could be the authorization server.
>>
>> Ciao
>> Hannes
>>
>>
>> *From:* oauth-bounces@ietf.org 
>> [mailto:oauth-bounces@ietf.org] *On Behalf Of *ext Nat Sakimura*
>> Sent:* Monday, December 03, 2012 10:35 AM*
>> To:* Brian Campbell; oauth*
>> Subject:* [OAUTH-WG] Assertion Framework - Why does issuer have to be
>> either the client or a third party token service?
>>
>> Hi Brian,
>>
>>
>> The assertion framework defines the Issuer as:
>>
>> Issuer The unique identifier for the entity that issued the
>> assertion. Generally this is the entity that holds the key
>> material used to generate the assertion. The issuer may be either
>> an OAuth client (when assertions are self-issued) or a third party
>> token service.
>>
>> I was wondering why it has to be either the client or a third party
>> token service.
>> Conceptually, it could be any token service (functionality) residing
>> in any of
>>
>> the stakeholders (Resource Owner, OAuth Client, Authorization Server, or
>> a third party).
>>
>>
>> I would appreciate if you could clarify why is the case.
>>
>>
>> Best,
>>
>> -- 
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation_
>> __http://nat.sakimura.org/_
>> @_nat_en
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--------------090300010107060206020906
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: 8bit



  
    
    
  
  
    Actually, I think it is a good time to start looking at the resourse
    owner issuing assertions@ (Interestingly enough, Hui-Lan had brought
    this up a couple of years ago.)

    

    Igor

    

    On 12/3/2012 3:58 AM, Nat Sakimura wrote:
    

      
      
I suppose, yes. I was reading it like that all the time. 

      
Whether it is or not, if it is still ok, it might be better
        to clarify it. 

      
Word like "third party" tends to be a bit of problem without
        clearly defining. 

      
I had similar experience in other fora. 

      


      

      
Nat

      


        Sent from iPad

      
      

        

          

          could be Resource owner? 
          

          

          

          

            
              

                "Tschofenig,
                      Hannes
                      (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
                  
                  

                  :  oauth-bounces@ietf.org
                  
2012-12-03 16:49
                  

                		
                
                  

                    
                      

                        
                          
ռ

                        		
                        "ext Nat
                            Sakimura" <sakimura@gmail.com>,
"Brian
                            Campbell" <bcampbell@pingidentity.com>,
                            "oauth"
                            <oauth@ietf.org>
                        
                      

                      

                        
                          

                        		
                        
                          

                        		
                      

                      

                        
                          

                        		
                        Re:
                            [OAUTH-WG] Assertion Framework -
                            Why does issuer have to be        either the
                            client or a third party token service?
                      

                    
                  

                  

                  

                    
                      

                        
                          

                        		
                        

                        		
                      

                    
                  

                  

                		
              

            
          

          

          

          

          Hi Nat, 
          

           
          

          The current text
            essentially
            says that the assertion can either be created by the client
            (in which case
            it is self-signed) or it can be created by some other entity
            (which is
            then called the third party token service). So, this third
            party could
            be the authorization server. 
          

           
          

          Ciao

            Hannes
          

           
          

           
          

          From: oauth-bounces@ietf.org
            [mailto:oauth-bounces@ietf.org]
            On Behalf Of ext Nat Sakimura

              Sent: Monday, December 03, 2012 10:35 AM

              To: Brian Campbell; oauth

              Subject: [OAUTH-WG] Assertion Framework - Why does
            issuer have to be
            either the client or a third party token service?
          

           
          

          Hi Brian, 
          

           
          

           
          

          The assertion framework defines the
            Issuer as: 
          

           
          

             Issuer  The unique
            identifier for the entity that issued the
          

                assertion.  Generally
            this is the entity that holds the key
          

                material used
            to generate the assertion.  The issuer may be either
          

                an OAuth client
            (when assertions are self-issued) or a third party
          

                token service.
          

           
          

          I was wondering why it has to be
            either
            the client or a third party token service. 
          

          Conceptually, it could be any token
            service (functionality) residing in any of 
          

           
          

          the stakeholders (Resource Owner,
            OAuth
            Client, Authorization Server, or 
          

          a third party). 
          

           
          

           
          

          I would appreciate if you could
            clarify
            why is the case. 
          

           
          

           
          

          Best, 
          

           
          

          -- 

            Nat Sakimura (=nat)
          

          Chairman, OpenID
            Foundation

            http://nat.sakimura.org/

            @_nat_en
          

           _______________________________________________

              OAuth mailing list

              OAuth@ietf.org

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

            
          

        

      

      

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


    

  


--------------090300010107060206020906--

From iesg-secretary@ietf.org  Mon Dec  3 09:56:43 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF5121F892F; Mon,  3 Dec 2012 09:56:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.484
X-Spam-Level: 
X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAzzv2C9mNH1; Mon,  3 Dec 2012 09:56:42 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD9A21F892D; Mon,  3 Dec 2012 09:56:42 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: IESG Secretary 
To: IETF Announcement List 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.36
Message-ID: <20121203175642.17014.49025.idtracker@ietfa.amsl.com>
Date: Mon, 03 Dec 2012 09:56:42 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] OAuth WG Virtual Interim Meetings, 11 January 2013 & 21 January 2013
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 17:56:43 -0000

The OAuth Working Group will hold virtual interim meetings as follows:

* 11th January 2013, 1pm EST
* 21st January 2013, 1pm EST

Agenda and dial-in information will be posted on the OAuth mailing list =

(http://www.ietf.org/mail-archive/web/oauth/current/maillist.html) prior =

to the meetings.

From zhou.sujing@zte.com.cn  Mon Dec  3 18:07:16 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D8B21F865F; Mon,  3 Dec 2012 18:07:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.795
X-Spam-Level: 
X-Spam-Status: No, score=-97.795 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HO8y0CCpRjSp; Mon,  3 Dec 2012 18:07:15 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9D221F8621; Mon,  3 Dec 2012 18:07:14 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4EE7782E19; Tue,  4 Dec 2012 10:07:06 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 3DDAC71AFC0; Tue,  4 Dec 2012 10:05:18 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qB426t5p044173; Tue, 4 Dec 2012 10:06:55 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <50BCE1CF.2000202@alcatel-lucent.com>
To: igor.faynberg@alcatel-lucent.com
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Tue, 4 Dec 2012 10:06:50 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-04 10:06:54, Serialize complete at 2012-12-04 10:06:54
Content-Type: multipart/alternative; boundary="=_alternative 000BBACC48257ACA_="
X-MAIL: mse02.zte.com.cn qB426t5p044173
Cc: oauth@ietf.org, oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 02:07:16 -0000

This is a multipart message in MIME format.
--=_alternative 000BBACC48257ACA_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

KzEuDQpBbmQgd2h5IGl0IHdhcyBub3QgbG9va2VkIGF0IHRoYXQgdGltZT8gDQoNCm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTEyLTA0IDAxOjMwOjU1Og0KDQo+IEFjdHVhbGx5LCBJ
IHRoaW5rIGl0IGlzIGEgZ29vZCB0aW1lIHRvIHN0YXJ0IGxvb2tpbmcgYXQgdGhlIHJlc291cnNl
DQo+IG93bmVyIGlzc3VpbmcgYXNzZXJ0aW9uc0AgKEludGVyZXN0aW5nbHkgZW5vdWdoLCBIdWkt
TGFuIGhhZCBicm91Z2h0DQo+IHRoaXMgdXAgYSBjb3VwbGUgb2YgeWVhcnMgYWdvLikNCj4gDQo+
IElnb3INCj4gDQo+IE9uIDEyLzMvMjAxMiAzOjU4IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6IA0K
PiBJIHN1cHBvc2UsIHllcy4gSSB3YXMgcmVhZGluZyBpdCBsaWtlIHRoYXQgYWxsIHRoZSB0aW1l
LiANCj4gV2hldGhlciBpdCBpcyBvciBub3QsIGlmIGl0IGlzIHN0aWxsIG9rLCBpdCBtaWdodCBi
ZSBiZXR0ZXIgdG8gY2xhcmlmeSANCml0LiANCj4gV29yZCBsaWtlICJ0aGlyZCBwYXJ0eSIgdGVu
ZHMgdG8gYmUgYSBiaXQgb2YgcHJvYmxlbSB3aXRob3V0IA0KY2xlYXJseWRlZmluaW5nLiANCj4g
SSBoYWQgc2ltaWxhciBleHBlcmllbmNlIGluIG90aGVyIGZvcmEuIA0KPiANCj4gTmF0DQo+IA0K
PiBTZW50IGZyb20gaVBhZA0KPiANCj4gMjAxMi8xMi8wMyAwOjUyoaIiemhvdS5zdWppbmdAenRl
LmNvbS5jbiIgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IKTODQo+IKXhpcOlu6lgpbg6DQoNCj4g
DQo+IGNvdWxkIGJlIFJlc291cmNlIG93bmVyPyANCj4gDQoNCj4gDQo+ICJUc2Nob2ZlbmlnLCBI
YW5uZXMgKE5TTiAtIEZJL0VzcG9vKSIgPGhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20+IA0KPiC3
orz+yMs6ICBvYXV0aC1ib3VuY2VzQGlldGYub3JnIA0KPiAyMDEyLTEyLTAzIDE2OjQ5IA0KPiAN
Cj4gytW8/sjLDQo+IA0KPiAiZXh0IE5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNvbT4s
ICJCcmlhbiBDYW1wYmVsbCIgPA0KPiBiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4sICJvYXV0
aCIgPG9hdXRoQGlldGYub3JnPiANCj4gDQo+ILOty80NCj4gDQo+INb3zOINCj4gDQo+IFJlOiBb
T0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBi
ZSANCj4gZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPw0K
PiANCj4gDQo+IA0KPiANCj4gSGkgTmF0LCANCj4gDQo+IFRoZSBjdXJyZW50IHRleHQgZXNzZW50
aWFsbHkgc2F5cyB0aGF0IHRoZSBhc3NlcnRpb24gY2FuIGVpdGhlciBiZSANCj4gY3JlYXRlZCBi
eSB0aGUgY2xpZW50IChpbiB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2lnbmVkKSBvciBpdCBjYW4g
YmUNCj4gY3JlYXRlZCBieSBzb21lIG90aGVyIGVudGl0eSAod2hpY2ggaXMgdGhlbiBjYWxsZWQg
dGhlIHRoaXJkIHBhcnR5IA0KPiB0b2tlbiBzZXJ2aWNlKS4gU28sIHRoaXMgdGhpcmQgcGFydHkg
Y291bGQgYmUgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLiANCj4gDQo+IENpYW8NCj4gSGFubmVz
IA0KPiANCj4gDQo+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgDQpPZiANCj4gZXh0IE5hdCBTYWtpbXVyYQ0KPiBT
ZW50OiBNb25kYXksIERlY2VtYmVyIDAzLCAyMDEyIDEwOjM1IEFNDQo+IFRvOiBCcmlhbiBDYW1w
YmVsbDsgb2F1dGgNCj4gU3ViamVjdDogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0g
V2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8gYmUNCj4gZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGly
ZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPyANCj4gDQo+IEhpIEJyaWFuLCANCj4gDQo+IA0KPiBUaGUg
YXNzZXJ0aW9uIGZyYW1ld29yayBkZWZpbmVzIHRoZSBJc3N1ZXIgYXM6IA0KPiANCj4gICAgSXNz
dWVyICBUaGUgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhl
IA0KPiAgICAgICBhc3NlcnRpb24uICBHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5IHRoYXQg
aG9sZHMgdGhlIGtleSANCj4gICAgICAgbWF0ZXJpYWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNz
ZXJ0aW9uLiAgVGhlIGlzc3VlciBtYXkgYmUgZWl0aGVyIA0KDQo+ICAgICAgIGFuIE9BdXRoIGNs
aWVudCAod2hlbiBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3VlZCkgb3IgYSB0aGlyZCBwYXJ0eSAN
Cg0KPiAgICAgICB0b2tlbiBzZXJ2aWNlLiANCj4gDQo+IEkgd2FzIHdvbmRlcmluZyB3aHkgaXQg
aGFzIHRvIGJlIGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgDQo+IHRva2VuIHNl
cnZpY2UuIA0KPiBDb25jZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBzZXJ2aWNlIChm
dW5jdGlvbmFsaXR5KSByZXNpZGluZ2luIA0KYW55IG9mIA0KPiANCj4gdGhlIHN0YWtlaG9sZGVy
cyAoUmVzb3VyY2UgT3duZXIsIE9BdXRoIENsaWVudCwgQXV0aG9yaXphdGlvbiBTZXJ2ZXIsIG9y
IA0KDQo+IGEgdGhpcmQgcGFydHkpLiANCj4gDQo+IA0KPiBJIHdvdWxkIGFwcHJlY2lhdGUgaWYg
eW91IGNvdWxkIGNsYXJpZnkgd2h5IGlzIHRoZSBjYXNlLiANCj4gDQo+IA0KPiBCZXN0LCANCj4g
DQo+IC0tIA0KPiBOYXQgU2FraW11cmEgKD1uYXQpIA0KPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5k
YXRpb24NCj4gaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+IEBfbmF0X2VuIA0KPiAgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9y
Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxp
bmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoDQoNCg==
--=_alternative 000BBACC48257ACA_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPisxLjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIHdoeSBpdCB3YXMgbm90IGxvb2tlZCBhdCB0
aGF0IHRpbWU/DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5vYXV0aC1ib3Vu
Y2VzQGlldGYub3JnINC009ogMjAxMi0xMi0wNCAwMTozMDo1NTo8YnI+DQo8YnI+DQomZ3Q7IEFj
dHVhbGx5LCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aW1lIHRvIHN0YXJ0IGxvb2tpbmcgYXQgdGhl
IHJlc291cnNlPGJyPg0KJmd0OyBvd25lciBpc3N1aW5nIGFzc2VydGlvbnNAIChJbnRlcmVzdGlu
Z2x5IGVub3VnaCwgSHVpLUxhbiBoYWQgYnJvdWdodDxicj4NCiZndDsgdGhpcyB1cCBhIGNvdXBs
ZSBvZiB5ZWFycyBhZ28uKTxicj4NCiZndDsgPGJyPg0KJmd0OyBJZ29yPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IE9uIDEyLzMvMjAxMiAzOjU4IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6IDwvZm9udD48
L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJIHN1cHBvc2UsIHllcy4gSSB3YXMgcmVh
ZGluZyBpdCBsaWtlIHRoYXQgYWxsDQp0aGUgdGltZS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm
b250IHNpemU9Mj4mZ3Q7IFdoZXRoZXIgaXQgaXMgb3Igbm90LCBpZiBpdCBpcyBzdGlsbCBvaywg
aXQgbWlnaHQNCmJlIGJldHRlciB0byBjbGFyaWZ5IGl0LiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgV29yZCBsaWtlICZxdW90O3RoaXJkIHBhcnR5JnF1b3Q7IHRlbmRz
IHRvIGJlDQphIGJpdCBvZiBwcm9ibGVtIHdpdGhvdXQgY2xlYXJseWRlZmluaW5nLiA8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSSBoYWQgc2ltaWxhciBleHBlcmllbmNl
IGluIG90aGVyIGZvcmEuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8
YnI+DQomZ3Q7IE5hdDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+
DQomZ3Q7IFNlbnQgZnJvbSBpUGFkPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7IDxicj4NCiZndDsgMjAxMi8xMi8wMyAwOjUyoaImcXVvdDt6aG91LnN1amluZ0B6dGUuY29t
LmNuJnF1b3Q7ICZsdDt6aG91LnN1amluZ0B6dGUuY29tLmNuJmd0Ow0KpM48YnI+DQomZ3Q7IKXh
pcOlu6lgpbg6PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi
cj4NCiZndDsgY291bGQgYmUgUmVzb3VyY2Ugb3duZXI/IDxicj4NCiZndDsgPGJyPg0KPC9mb250
PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJnF1b3Q7VHNjaG9m
ZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykmcXVvdDsgJmx0O2hhbm5lcy50c2Nob2Zlbmln
QG5zbi5jb20mZ3Q7DQo8YnI+DQomZ3Q7ILeivP7IyzogJm5ic3A7b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgMjAxMi0xMi0wMyAx
Njo0OSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDK
1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAm
cXVvdDtleHQgTmF0IFNha2ltdXJhJnF1b3Q7ICZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7LCAm
cXVvdDtCcmlhbg0KQ2FtcGJlbGwmcXVvdDsgJmx0Ozxicj4NCiZndDsgYmNhbXBiZWxsQHBpbmdp
ZGVudGl0eS5jb20mZ3Q7LCAmcXVvdDtvYXV0aCZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7
DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvN
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM4jwv
Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJlOiBbT0FV
VEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZSAm
bmJzcDsNCiZuYnNwOyA8YnI+DQomZ3Q7IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFy
dHkgdG9rZW4gc2VydmljZT88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBOYXQsIDxicj4N
CiZndDsgJm5ic3A7IDxicj4NCiZndDsgVGhlIGN1cnJlbnQgdGV4dCBlc3NlbnRpYWxseSBzYXlz
IHRoYXQgdGhlIGFzc2VydGlvbiBjYW4gZWl0aGVyIGJlDQo8YnI+DQomZ3Q7IGNyZWF0ZWQgYnkg
dGhlIGNsaWVudCAoaW4gd2hpY2ggY2FzZSBpdCBpcyBzZWxmLXNpZ25lZCkgb3IgaXQgY2FuDQpi
ZTxicj4NCiZndDsgY3JlYXRlZCBieSBzb21lIG90aGVyIGVudGl0eSAod2hpY2ggaXMgdGhlbiBj
YWxsZWQgdGhlIHRoaXJkIHBhcnR5DQo8YnI+DQomZ3Q7IHRva2VuIHNlcnZpY2UpLiBTbywgdGhp
cyB0aGlyZCBwYXJ0eSBjb3VsZCBiZSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQo8YnI+DQom
Z3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IENpYW88YnI+DQomZ3Q7IEhhbm5lcyA8YnI+DQomZ3Q7ICZu
YnNwOyA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCk9mIDxicj4N
CiZndDsgZXh0IE5hdCBTYWtpbXVyYTxicj4NCiZndDsgU2VudDogTW9uZGF5LCBEZWNlbWJlciAw
MywgMjAxMiAxMDozNSBBTTxicj4NCiZndDsgVG86IEJyaWFuIENhbXBiZWxsOyBvYXV0aDxicj4N
CiZndDsgU3ViamVjdDogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMg
aXNzdWVyIGhhdmUgdG8NCmJlPGJyPg0KJmd0OyBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJk
IHBhcnR5IHRva2VuIHNlcnZpY2U/IDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgSGkgQnJp
YW4sIDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgVGhlIGFz
c2VydGlvbiBmcmFtZXdvcmsgZGVmaW5lcyB0aGUgSXNzdWVyIGFzOiA8YnI+DQomZ3Q7ICZuYnNw
OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtJc3N1ZXIgJm5ic3A7VGhlIHVuaXF1ZSBpZGVudGlm
aWVyIGZvciB0aGUgZW50aXR5IHRoYXQNCmlzc3VlZCB0aGUgPGJyPg0KJmd0OyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBhc3NlcnRpb24uICZuYnNwO0dlbmVyYWxseSB0aGlzIGlzIHRoZSBlbnRpdHkN
CnRoYXQgaG9sZHMgdGhlIGtleSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1hdGVy
aWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gJm5ic3A7VGhlDQppc3N1ZXIgbWF5
IGJlIGVpdGhlciA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFuIE9BdXRoIGNsaWVu
dCAod2hlbiBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3VlZCkNCm9yIGEgdGhpcmQgcGFydHkgPGJy
Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0b2tlbiBzZXJ2aWNlLiA8YnI+DQomZ3Q7ICZu
YnNwOyA8YnI+DQomZ3Q7IEkgd2FzIHdvbmRlcmluZyB3aHkgaXQgaGFzIHRvIGJlIGVpdGhlciB0
aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkNCjxicj4NCiZndDsgdG9rZW4gc2VydmljZS4gPGJy
Pg0KJmd0OyBDb25jZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBzZXJ2aWNlIChmdW5j
dGlvbmFsaXR5KSByZXNpZGluZ2luDQphbnkgb2YgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0
OyB0aGUgc3Rha2Vob2xkZXJzIChSZXNvdXJjZSBPd25lciwgT0F1dGggQ2xpZW50LCBBdXRob3Jp
emF0aW9uIFNlcnZlciwNCm9yIDxicj4NCiZndDsgYSB0aGlyZCBwYXJ0eSkuIDxicj4NCiZndDsg
Jm5ic3A7IDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgSSB3b3VsZCBhcHByZWNpYXRlIGlm
IHlvdSBjb3VsZCBjbGFyaWZ5IHdoeSBpcyB0aGUgY2FzZS4gPGJyPg0KJmd0OyAmbmJzcDsgPGJy
Pg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyBCZXN0LCA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQom
Z3Q7IC0tIDxicj4NCiZndDsgTmF0IFNha2ltdXJhICg9bmF0KSA8YnI+DQomZ3Q7IENoYWlybWFu
LCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPGJy
Pg0KJmd0OyBAX25hdF9lbiA8YnI+DQomZ3Q7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+
DQomZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0
OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgT0F1
dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGg8YnI+DQo8L2ZvbnQ+PC90dD4NCg==
--=_alternative 000BBACC48257ACA_=--

From cmortimore@salesforce.com  Mon Dec  3 18:12:55 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F73121F86F6 for ; Mon,  3 Dec 2012 18:12:55 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nRCvyJ2rrZj for ; Mon,  3 Dec 2012 18:12:54 -0800 (PST)
Received: from exprod8og106.obsmtp.com (exprod8og106.obsmtp.com [64.18.3.92]) by ietfa.amsl.com (Postfix) with SMTP id D28FD21F867D for ; Mon,  3 Dec 2012 18:12:53 -0800 (PST)
Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob106.postini.com ([64.18.7.12]) with SMTP ID DSNKUL1cJXF3G5Y5imz68KhiM6yRRfPilsSc@postini.com; Mon, 03 Dec 2012 18:12:53 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Mon, 3 Dec 2012 18:12:53 -0800
From: Chuck Mortimore 
To: Nat Sakimura 
Date: Mon, 3 Dec 2012 18:12:52 -0800
Thread-Topic: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Thread-Index: Ac3RxN2GsntGL0uKRqG0qg2aW+R5Gw==
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_C88B26EBAB88494C8D006C50905C726Bsalesforcecom_"
MIME-Version: 1.0
Cc: oauth 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 02:12:55 -0000

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

It's simply the entity that created the assertion.   Third party token serv=
ice was meant to encapsulate pretty much all of your stakeholders below.   =
The only one it doesn't really cover is Authorization Server.



On Dec 3, 2012, at 12:35 AM, Nat Sakimura wrote:


Hi Brian,


The assertion framework defines the Issuer as:


   Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.  The issuer may be either
      an OAuth client (when assertions are self-issued) or a third party
      token service.


I was wondering why it has to be either the client or a third party token s=
ervice.

Conceptually, it could be any token service (functionality) residing in any=
 of

the stakeholders (Resource Owner, OAuth Client, Authorization Server, or

a third party).


I would appreciate if you could clarify why is the case.


Best,

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


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


It's simply the entit=
y that created the assertion.   Third party token service was meant to=
 encapsulate pretty much all of your stakeholders below.   The only on=
e it doesn't really cover is Authorization Server.



On Dec 3, 2012, at 12:35 AM, Nat Sakimura wrote:
Hi Brian, 

The assertion framework de=
fines the Issuer as: 



   Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.  The issuer may be either
      an OAuth client (when assertions are self-issued) or a third party
      token service.

I was wondering why it has to=
 be either the client or a third party token service. 


Conceptually, it could be any token service (functionality) residing i=
n any of 
the stakeholders (Resource Owner, OAuth Client, Authori=
zation Server, or 
a third party). 

I wo=
uld appreciate if you could clarify why is the case. 

<=
pre class=3D"newpage" style=3D"font-size:1em;margin-top:0px;margin-bottom:0=
px">Best, 

-- 
Nat Sakimura (=3Dnat)
Chai=
rman, OpenID Foundation
http://nat.sakimura.org/

@_nat_en


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

=

--_000_C88B26EBAB88494C8D006C50905C726Bsalesforcecom_--

From cmortimore@salesforce.com  Mon Dec  3 18:15:50 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B1621F86F6 for ; Mon,  3 Dec 2012 18:15:50 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9E3b3aF-FRXA for ; Mon,  3 Dec 2012 18:15:49 -0800 (PST)
Received: from exprod8og105.obsmtp.com (exprod8og105.obsmtp.com [64.18.3.90]) by ietfa.amsl.com (Postfix) with SMTP id A6D5121F867D for ; Mon,  3 Dec 2012 18:15:49 -0800 (PST)
Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob105.postini.com ([64.18.7.12]) with SMTP ID DSNKUL1c1ZzIqkZheAgOcZnRuv/aNpfuYZFc@postini.com; Mon, 03 Dec 2012 18:15:49 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Mon, 3 Dec 2012 18:15:49 -0800
From: Chuck Mortimore 
To: Chuck Mortimore 
Date: Mon, 3 Dec 2012 18:15:48 -0800
Thread-Topic: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Thread-Index: Ac3RxUZeKuwGQG57Q4SyTB0SZElh1w==
Message-ID: <085EC757-8D25-421B-BA15-62716114A5F4@salesforce.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_085EC7578D25421BBA1562716114A5F4salesforcecom_"
MIME-Version: 1.0
Cc: oauth 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 02:15:50 -0000

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

Actually - strike that.   Authorization server is covered by the language a=
s well.

In short, Issuer is simply the entity that minted the assertion.   The inte=
nt is to allow the token service to lookup metadata about the issuer used t=
o establish trust ( their Public Key for instance )


On Dec 3, 2012, at 6:12 PM, Chuck Mortimore wrote:

It's simply the entity that created the assertion.   Third party token serv=
ice was meant to encapsulate pretty much all of your stakeholders below.   =
The only one it doesn't really cover is Authorization Server.



On Dec 3, 2012, at 12:35 AM, Nat Sakimura wrote:


Hi Brian,


The assertion framework defines the Issuer as:


   Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.  The issuer may be either
      an OAuth client (when assertions are self-issued) or a third party
      token service.


I was wondering why it has to be either the client or a third party token s=
ervice.

Conceptually, it could be any token service (functionality) residing in any=
 of

the stakeholders (Resource Owner, OAuth Client, Authorization Server, or

a third party).


I would appreciate if you could clarify why is the case.


Best,

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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



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


Actually - strike tha=
t.   Authorization server is covered by the language as well.

In short, Issuer is simply the entity that minted the asse=
rtion.   The intent is to allow the token service to lookup metadata a=
bout the issuer used to establish trust ( their Public Key for instance )


On Dec 3, 2012, at 6:12 PM, Chuck Mortimor=
e wrote:

It's simply the entity that created =
the assertion.   Third party token service was meant to encapsulate pr=
etty much all of your stakeholders below.   The only one it doesn't re=
ally cover is Authorization Server.



=

On Dec 3, 2012, at 12:35 AM, Nat Sakimura wrote:

=
Hi Brian, 

The assertion framework defines the Iss=
uer as: 



   Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.  The issuer may be either
      an OAuth client (when assertions are self-issued) or a third party
      token service.

I was wondering why it has to=
 be either the client or a third party token service. 


Conceptually, it could be any token service (functionality) residing i=
n any of 
the stakeholders (Resource Owner, OAuth Client, Authori=
zation Server, or 
a third party). 

I wo=
uld appreciate if you could clarify why is the case. 

<=
pre class=3D"newpage" style=3D"font-size:1em;margin-top:0px;margin-bottom:0=
px">Best, 

-- 
Nat Sakimura (=3Dnat)
Chai=
rman, OpenID Foundation
http://nat.sakimura.org/

@_nat_en


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


=

--_000_085EC7578D25421BBA1562716114A5F4salesforcecom_--

From cmortimore@salesforce.com  Mon Dec  3 18:17:16 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B6A11E8097; Mon,  3 Dec 2012 18:17:16 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkEGtgyAJ17q; Mon,  3 Dec 2012 18:17:15 -0800 (PST)
Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by ietfa.amsl.com (Postfix) with SMTP id 1F5FE21F884A; Mon,  3 Dec 2012 18:17:15 -0800 (PST)
Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKUL1dKYWOfGUmXKG3xMa9jCDa6uwh9hrd@postini.com; Mon, 03 Dec 2012 18:17:15 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Mon, 3 Dec 2012 18:17:13 -0800
From: Chuck Mortimore 
To: " " 
Date: Mon, 3 Dec 2012 18:17:12 -0800
Thread-Topic: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Thread-Index: Ac3RxXi0GTomg37DTNuP9VuKtO2ajg==
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_AD90DFBD7D52471FB76DE4A17C0BDAB6salesforcecom_"
MIME-Version: 1.0
Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 02:17:16 -0000

--_000_AD90DFBD7D52471FB76DE4A17C0BDAB6salesforcecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlcmUncyBubyByZWFzb24gd2h5IGl0IGNhbid0IGJlIHJlc291cmNlIG93bmVyIHRvZGF5Lg0K
DQoNCk9uIERlYyAzLCAyMDEyLCBhdCA2OjA2IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbjxt
YWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbj4+IDx6aG91LnN1amluZ0B6dGUuY29tLmNuPG1h
aWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPj4gd3JvdGU6DQoNCg0KKzEuDQpBbmQgd2h5IGl0
IHdhcyBub3QgbG9va2VkIGF0IHRoYXQgdGltZT8NCg0Kb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxt
YWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4g5YaZ5LqOIDIwMTItMTItMDQgMDE6MzA6NTU6
DQoNCj4gQWN0dWFsbHksIEkgdGhpbmsgaXQgaXMgYSBnb29kIHRpbWUgdG8gc3RhcnQgbG9va2lu
ZyBhdCB0aGUgcmVzb3Vyc2UNCj4gb3duZXIgaXNzdWluZyBhc3NlcnRpb25zQCAoSW50ZXJlc3Rp
bmdseSBlbm91Z2gsIEh1aS1MYW4gaGFkIGJyb3VnaHQNCj4gdGhpcyB1cCBhIGNvdXBsZSBvZiB5
ZWFycyBhZ28uKQ0KPg0KPiBJZ29yDQo+DQo+IE9uIDEyLzMvMjAxMiAzOjU4IEFNLCBOYXQgU2Fr
aW11cmEgd3JvdGU6DQo+IEkgc3VwcG9zZSwgeWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhh
dCBhbGwgdGhlIHRpbWUuDQo+IFdoZXRoZXIgaXQgaXMgb3Igbm90LCBpZiBpdCBpcyBzdGlsbCBv
aywgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGNsYXJpZnkgaXQuDQo+IFdvcmQgbGlrZSAidGhpcmQg
cGFydHkiIHRlbmRzIHRvIGJlIGEgYml0IG9mIHByb2JsZW0gd2l0aG91dCBjbGVhcmx5ZGVmaW5p
bmcuDQo+IEkgaGFkIHNpbWlsYXIgZXhwZXJpZW5jZSBpbiBvdGhlciBmb3JhLg0KPg0KPiBOYXQN
Cj4NCj4gU2VudCBmcm9tIGlQYWQNCj4NCj4gMjAxMi8xMi8wMyAwOjUy44CBInpob3Uuc3VqaW5n
QHp0ZS5jb20uY248bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IiA8emhvdS5zdWppbmdA
enRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbj4+IOOBrg0KPiDjg6Hjg4Pj
grvjg7zjgrg6DQoNCj4NCj4gY291bGQgYmUgUmVzb3VyY2Ugb3duZXI/DQo+DQoNCj4NCj4gIlRz
Y2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pIiA8aGFubmVzLnRzY2hvZmVuaWdAbnNu
LmNvbTxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbT4+DQo+IOWPkeS7tuS6ujogIG9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+DQo+IDIw
MTItMTItMDMgMTY6NDkNCj4NCj4g5pS25Lu25Lq6DQo+DQo+ICJleHQgTmF0IFNha2ltdXJhIiA8
c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiwgIkJyaWFuIENh
bXBiZWxsIiA8DQo+IGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxA
cGluZ2lkZW50aXR5LmNvbT4+LCAib2F1dGgiIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhA
aWV0Zi5vcmc+Pg0KPg0KPiDmioTpgIENCj4NCj4g5Li76aKYDQo+DQo+IFJlOiBbT0FVVEgtV0dd
IEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZQ0KPiBlaXRo
ZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/DQo+DQo+DQo+DQo+
DQo+IEhpIE5hdCwNCj4NCj4gVGhlIGN1cnJlbnQgdGV4dCBlc3NlbnRpYWxseSBzYXlzIHRoYXQg
dGhlIGFzc2VydGlvbiBjYW4gZWl0aGVyIGJlDQo+IGNyZWF0ZWQgYnkgdGhlIGNsaWVudCAoaW4g
d2hpY2ggY2FzZSBpdCBpcyBzZWxmLXNpZ25lZCkgb3IgaXQgY2FuIGJlDQo+IGNyZWF0ZWQgYnkg
c29tZSBvdGhlciBlbnRpdHkgKHdoaWNoIGlzIHRoZW4gY2FsbGVkIHRoZSB0aGlyZCBwYXJ0eQ0K
PiB0b2tlbiBzZXJ2aWNlKS4gU28sIHRoaXMgdGhpcmQgcGFydHkgY291bGQgYmUgdGhlIGF1dGhv
cml6YXRpb24gc2VydmVyLg0KPg0KPiBDaWFvDQo+IEhhbm5lcw0KPg0KPg0KPiBGcm9tOiBvYXV0
aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRv
Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBleHQgTmF0IFNha2ltdXJh
DQo+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDMsIDIwMTIgMTA6MzUgQU0NCj4gVG86IEJyaWFu
IENhbXBiZWxsOyBvYXV0aA0KPiBTdWJqZWN0OiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdv
cmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZQ0KPiBlaXRoZXIgdGhlIGNsaWVudCBvciBh
IHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/DQo+DQo+IEhpIEJyaWFuLA0KPg0KPg0KPiBUaGUg
YXNzZXJ0aW9uIGZyYW1ld29yayBkZWZpbmVzIHRoZSBJc3N1ZXIgYXM6DQo+DQo+ICAgIElzc3Vl
ciAgVGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVkIHRoZQ0K
PiAgICAgICBhc3NlcnRpb24uICBHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5IHRoYXQgaG9s
ZHMgdGhlIGtleQ0KPiAgICAgICBtYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRp
b24uICBUaGUgaXNzdWVyIG1heSBiZSBlaXRoZXINCj4gICAgICAgYW4gT0F1dGggY2xpZW50ICh3
aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYtaXNzdWVkKSBvciBhIHRoaXJkIHBhcnR5DQo+ICAgICAg
IHRva2VuIHNlcnZpY2UuDQo+DQo+IEkgd2FzIHdvbmRlcmluZyB3aHkgaXQgaGFzIHRvIGJlIGVp
dGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkNCj4gdG9rZW4gc2VydmljZS4NCj4gQ29u
Y2VwdHVhbGx5LCBpdCBjb3VsZCBiZSBhbnkgdG9rZW4gc2VydmljZSAoZnVuY3Rpb25hbGl0eSkg
cmVzaWRpbmdpbiBhbnkgb2YNCj4NCj4gdGhlIHN0YWtlaG9sZGVycyAoUmVzb3VyY2UgT3duZXIs
IE9BdXRoIENsaWVudCwgQXV0aG9yaXphdGlvbiBTZXJ2ZXIsIG9yDQo+IGEgdGhpcmQgcGFydHkp
Lg0KPg0KPg0KPiBJIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IGNvdWxkIGNsYXJpZnkgd2h5IGlz
IHRoZSBjYXNlLg0KPg0KPg0KPiBCZXN0LA0KPg0KPiAtLQ0KPiBOYXQgU2FraW11cmEgKD1uYXQp
DQo+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPiBodHRwOi8vbmF0LnNha2ltdXJhLm9y
Zy8NCj4gQF9uYXRfZW4NCj4gIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86
T0F1dGhAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v
cmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K

--_000_AD90DFBD7D52471FB76DE4A17C0BDAB6salesforcecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13
ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z
cGFjZTsgIj48ZGl2PlRoZXJlJ3Mgbm8gcmVhc29uIHdoeSBpdCBjYW4ndCBiZSByZXNvdXJjZSBv
d25lciB0b2RheS4gJm5ic3A7Jm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGJyPjxkaXY+PGRp
dj5PbiBEZWMgMywgMjAxMiwgYXQgNjowNiBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzp6aG91LnN1
amluZ0B6dGUuY29tLmNuIj56aG91LnN1amluZ0B6dGUuY29tLmNuPC9hPiZndDsgJmx0OzxhIGhy
ZWY9Im1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIj56aG91LnN1amluZ0B6dGUuY29tLmNu
PC9hPiZndDsgd3JvdGU6PC9kaXY+PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5l
Ij48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxicj48Zm9udCBzaXplPSIyIiBmYWNlPSJzYW5z
LXNlcmlmIj4rMS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+
QW5kIHdoeSBpdCB3YXMgbm90IGxvb2tlZCBhdCB0aGF0IHRpbWU/DQo8L2ZvbnQ+DQo8YnI+DQo8
YnI+PHR0Pjxmb250IHNpemU9IjIiPjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiDlhpnkuo4gMjAxMi0xMi0wNCAwMTozMDo1
NTo8YnI+DQo8YnI+DQomZ3Q7IEFjdHVhbGx5LCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aW1lIHRv
IHN0YXJ0IGxvb2tpbmcgYXQgdGhlIHJlc291cnNlPGJyPg0KJmd0OyBvd25lciBpc3N1aW5nIGFz
c2VydGlvbnNAIChJbnRlcmVzdGluZ2x5IGVub3VnaCwgSHVpLUxhbiBoYWQgYnJvdWdodDxicj4N
CiZndDsgdGhpcyB1cCBhIGNvdXBsZSBvZiB5ZWFycyBhZ28uKTxicj4NCiZndDsgPGJyPg0KJmd0
OyBJZ29yPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDEyLzMvMjAxMiAzOjU4IEFNLCBOYXQgU2Fr
aW11cmEgd3JvdGU6IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IEkg
c3VwcG9zZSwgeWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhhdCBhbGwNCnRoZSB0aW1lLiA8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+Jmd0OyBXaGV0aGVyIGl0IGlzIG9y
IG5vdCwgaWYgaXQgaXMgc3RpbGwgb2ssIGl0IG1pZ2h0DQpiZSBiZXR0ZXIgdG8gY2xhcmlmeSBp
dC4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9IjIiPiZndDsgV29yZCBsaWtlICJ0
aGlyZCBwYXJ0eSIgdGVuZHMgdG8gYmUNCmEgYml0IG9mIHByb2JsZW0gd2l0aG91dCBjbGVhcmx5
ZGVmaW5pbmcuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IEkgaGFk
IHNpbWlsYXIgZXhwZXJpZW5jZSBpbiBvdGhlciBmb3JhLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0iMiI+Jmd0OyA8YnI+DQomZ3Q7IE5hdDwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsgU2VudCBmcm9tIGlQYWQ8L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+Jmd0OyA8YnI+DQomZ3Q7IDIwMTIvMTIvMDMgMDo1MuOA
gSI8YSBocmVmPSJtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbiI+emhvdS5zdWppbmdAenRl
LmNvbS5jbjwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbiI+
emhvdS5zdWppbmdAenRlLmNvbS5jbjwvYT4mZ3Q7DQrjga48YnI+DQomZ3Q7IOODoeODg+OCu+OD
vOOCuDo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+Jmd0OyA8YnI+
DQomZ3Q7IGNvdWxkIGJlIFJlc291cmNlIG93bmVyPyA8YnI+DQomZ3Q7IDxicj4NCjwvZm9udD48
L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsgIlRzY2hvZmVuaWcs
IEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhhbm5lcy50c2No
b2ZlbmlnQG5zbi5jb20iPmhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb208L2E+Jmd0Ow0KPGJyPg0K
Jmd0OyDlj5Hku7bkuro6ICZuYnNwOzxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0iMiI+Jmd0OyAyMDEyLTEyLTAzIDE2OjQ5IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsg5pS25Lu25Lq6PC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9IjIiPiZndDsgPGJyPg0KJmd0OyAiZXh0IE5hdCBTYWtpbXVyYSIgJmx0
OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdtYWlsLmNvbTwv
YT4mZ3Q7LCAiQnJpYW4NCkNhbXBiZWxsIiAmbHQ7PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86
YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9h
PiZndDssICJvYXV0aCIgJmx0OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyI+b2F1dGhA
aWV0Zi5vcmc8L2E+Jmd0Ow0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9IjIiPiZn
dDsgPGJyPg0KJmd0OyDmioTpgIE8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+
Jmd0OyA8YnI+DQomZ3Q7IOS4u+mimDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPSIy
Ij4mZ3Q7IDxicj4NCiZndDsgUmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdo
eSBkb2VzIGlzc3VlciBoYXZlIHRvIGJlICZuYnNwOw0KJm5ic3A7IDxicj4NCiZndDsgZWl0aGVy
IHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPzwvZm9udD48L3R0Pg0K
PGJyPjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IDxicj4NCiZndDsgSGkgTmF0LCA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IFRoZSBj
dXJyZW50IHRleHQgZXNzZW50aWFsbHkgc2F5cyB0aGF0IHRoZSBhc3NlcnRpb24gY2FuIGVpdGhl
ciBiZQ0KPGJyPg0KJmd0OyBjcmVhdGVkIGJ5IHRoZSBjbGllbnQgKGluIHdoaWNoIGNhc2UgaXQg
aXMgc2VsZi1zaWduZWQpIG9yIGl0IGNhbg0KYmU8YnI+DQomZ3Q7IGNyZWF0ZWQgYnkgc29tZSBv
dGhlciBlbnRpdHkgKHdoaWNoIGlzIHRoZW4gY2FsbGVkIHRoZSB0aGlyZCBwYXJ0eQ0KPGJyPg0K
Jmd0OyB0b2tlbiBzZXJ2aWNlKS4gU28sIHRoaXMgdGhpcmQgcGFydHkgY291bGQgYmUgdGhlIGF1
dGhvcml6YXRpb24gc2VydmVyLg0KPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyBDaWFvPGJy
Pg0KJmd0OyBIYW5uZXMgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0K
Jmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYNCk9mIDxicj4NCiZndDsgZXh0IE5hdCBTYWtpbXVyYTxicj4NCiZndDsgU2VudDogTW9u
ZGF5LCBEZWNlbWJlciAwMywgMjAxMiAxMDozNSBBTTxicj4NCiZndDsgVG86IEJyaWFuIENhbXBi
ZWxsOyBvYXV0aDxicj4NCiZndDsgU3ViamVjdDogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3
b3JrIC0gV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8NCmJlPGJyPg0KJmd0OyBlaXRoZXIgdGhlIGNs
aWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/IDxicj4NCiZndDsgJm5ic3A7IDxi
cj4NCiZndDsgSGkgQnJpYW4sIDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgJm5ic3A7IDxi
cj4NCiZndDsgVGhlIGFzc2VydGlvbiBmcmFtZXdvcmsgZGVmaW5lcyB0aGUgSXNzdWVyIGFzOiA8
YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtJc3N1ZXIgJm5ic3A7VGhl
IHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQNCmlzc3VlZCB0aGUgPGJyPg0K
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhc3NlcnRpb24uICZuYnNwO0dlbmVyYWxseSB0aGlz
IGlzIHRoZSBlbnRpdHkNCnRoYXQgaG9sZHMgdGhlIGtleSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IG1hdGVyaWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gJm5ic3A7
VGhlDQppc3N1ZXIgbWF5IGJlIGVpdGhlciA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3VlZCkNCm9yIGEg
dGhpcmQgcGFydHkgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0b2tlbiBzZXJ2aWNl
LiA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7IEkgd2FzIHdvbmRlcmluZyB3aHkgaXQgaGFz
IHRvIGJlIGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkNCjxicj4NCiZndDsgdG9r
ZW4gc2VydmljZS4gPGJyPg0KJmd0OyBDb25jZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tl
biBzZXJ2aWNlIChmdW5jdGlvbmFsaXR5KSByZXNpZGluZ2luDQphbnkgb2YgPGJyPg0KJmd0OyAm
bmJzcDsgPGJyPg0KJmd0OyB0aGUgc3Rha2Vob2xkZXJzIChSZXNvdXJjZSBPd25lciwgT0F1dGgg
Q2xpZW50LCBBdXRob3JpemF0aW9uIFNlcnZlciwNCm9yIDxicj4NCiZndDsgYSB0aGlyZCBwYXJ0
eSkuIDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgSSB3b3Vs
ZCBhcHByZWNpYXRlIGlmIHlvdSBjb3VsZCBjbGFyaWZ5IHdoeSBpcyB0aGUgY2FzZS4gPGJyPg0K
Jmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyBCZXN0LCA8YnI+DQomZ3Q7
ICZuYnNwOyA8YnI+DQomZ3Q7IC0tIDxicj4NCiZndDsgTmF0IFNha2ltdXJhICg9bmF0KSA8YnI+
DQomZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsgPGEgaHJlZj0iaHR0
cDovL25hdC5zYWtpbXVyYS5vcmcvIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0K
Jmd0OyBAX25hdF9lbiA8YnI+DQomZ3Q7ICZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQom
Z3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJy
Pg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4N
CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsgPGJy
Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1
dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxp
c3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5v
cmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PC9hPjxicj4NCjwvZm9udD48L3R0Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2JvZHk+
PC9odG1sPg==

--_000_AD90DFBD7D52471FB76DE4A17C0BDAB6salesforcecom_--

From zhou.sujing@zte.com.cn  Mon Dec  3 18:23:46 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4B921F86A5; Mon,  3 Dec 2012 18:23:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.553
X-Spam-Level: 
X-Spam-Status: No, score=-97.553 tagged_above=-999 required=5 tests=[AWL=0.842, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS4HUv3SjJDU; Mon,  3 Dec 2012 18:23:45 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 128D221F8511; Mon,  3 Dec 2012 18:23:42 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 2F49F125BCAA; Tue,  4 Dec 2012 10:25:22 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id CE02471B1E3; Tue,  4 Dec 2012 10:21:48 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qB42NQ68069521; Tue, 4 Dec 2012 10:23:26 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Chuck Mortimore 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Tue, 4 Dec 2012 10:23:22 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-04 10:23:25, Serialize complete at 2012-12-04 10:23:25
Content-Type: multipart/alternative; boundary="=_alternative 000D3E4648257ACA_="
X-MAIL: mse02.zte.com.cn qB42NQ68069521
Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 02:23:46 -0000

This is a multipart message in MIME format.
--=_alternative 000D3E4648257ACA_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

T2J2aW91c2x5LCBpdCBpcyBub3Qgc28gY2xlYXIgZnJvbSB0aGUgbGFuZ3VhZ2UgdGhlcmUuDQoN
Cg0KQ2h1Y2sgTW9ydGltb3JlIDxjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPiDQtNPaIDIwMTIt
MTItMDQgMTA6MTc6MTI6DQoNCj4gVGhlcmUncyBubyByZWFzb24gd2h5IGl0IGNhbid0IGJlIHJl
c291cmNlIG93bmVyIHRvZGF5LiANCj4gDQo+IE9uIERlYyAzLCAyMDEyLCBhdCA2OjA2IFBNLCA8
emhvdS5zdWppbmdAenRlLmNvbS5jbj4gDQo8emhvdS5zdWppbmdAenRlLmNvbS5jbg0KPiA+IHdy
b3RlOg0KPiANCj4gDQo+ICsxLiANCj4gQW5kIHdoeSBpdCB3YXMgbm90IGxvb2tlZCBhdCB0aGF0
IHRpbWU/IA0KPiANCj4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTItMTItMDQgMDE6
MzA6NTU6DQo+IA0KPiA+IEFjdHVhbGx5LCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aW1lIHRvIHN0
YXJ0IGxvb2tpbmcgYXQgdGhlIHJlc291cnNlDQo+ID4gb3duZXIgaXNzdWluZyBhc3NlcnRpb25z
QCAoSW50ZXJlc3RpbmdseSBlbm91Z2gsIEh1aS1MYW4gaGFkIGJyb3VnaHQNCj4gPiB0aGlzIHVw
IGEgY291cGxlIG9mIHllYXJzIGFnby4pDQo+ID4gDQo+ID4gSWdvcg0KPiA+IA0KPiA+IE9uIDEy
LzMvMjAxMiAzOjU4IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6IA0KPiA+IEkgc3VwcG9zZSwgeWVz
LiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhhdCBhbGwgdGhlIHRpbWUuIA0KPiA+IFdoZXRoZXIg
aXQgaXMgb3Igbm90LCBpZiBpdCBpcyBzdGlsbCBvaywgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGNs
YXJpZnkgDQppdC4gDQo+ID4gV29yZCBsaWtlICJ0aGlyZCBwYXJ0eSIgdGVuZHMgdG8gYmUgYSBi
aXQgb2YgcHJvYmxlbSB3aXRob3V0IA0KPiBjbGVhcmx5ZGVmaW5pbmcuIA0KPiA+IEkgaGFkIHNp
bWlsYXIgZXhwZXJpZW5jZSBpbiBvdGhlciBmb3JhLiANCj4gPiANCj4gPiBOYXQgDQo+ID4gDQo+
ID4gU2VudCBmcm9tIGlQYWQgDQo+ID4gDQo+ID4gMjAxMi8xMi8wMyAwOjUyoaIiemhvdS5zdWpp
bmdAenRlLmNvbS5jbiIgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IKTODQo+ID4gpeGlw6W7qWCl
uDoNCj4gDQo+ID4gDQo+ID4gY291bGQgYmUgUmVzb3VyY2Ugb3duZXI/IA0KPiA+IA0KPiANCj4g
PiANCj4gPiAiVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykiIDxoYW5uZXMudHNj
aG9mZW5pZ0Buc24uY29tPiANCj4gPiC3orz+yMs6ICBvYXV0aC1ib3VuY2VzQGlldGYub3JnIA0K
PiA+IDIwMTItMTItMDMgMTY6NDkgDQo+ID4gDQo+ID4gytW8/sjLIA0KPiA+IA0KPiA+ICJleHQg
TmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwuY29tPiwgIkJyaWFuIENhbXBiZWxsIiA8DQo+
ID4gYmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+LCAib2F1dGgiIDxvYXV0aEBpZXRmLm9yZz4g
DQo+ID4gDQo+ID4gs63LzSANCj4gPiANCj4gPiDW98ziIA0KPiA+IA0KPiA+IFJlOiBbT0FVVEgt
V0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZSANCj4g
PiBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/IA0KPiA+
IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IEhpIE5hdCwgDQo+ID4gDQo+ID4gVGhlIGN1cnJlbnQg
dGV4dCBlc3NlbnRpYWxseSBzYXlzIHRoYXQgdGhlIGFzc2VydGlvbiBjYW4gZWl0aGVyIGJlIA0K
PiA+IGNyZWF0ZWQgYnkgdGhlIGNsaWVudCAoaW4gd2hpY2ggY2FzZSBpdCBpcyBzZWxmLXNpZ25l
ZCkgb3IgaXQgY2FuIGJlDQo+ID4gY3JlYXRlZCBieSBzb21lIG90aGVyIGVudGl0eSAod2hpY2gg
aXMgdGhlbiBjYWxsZWQgdGhlIHRoaXJkIHBhcnR5IA0KPiA+IHRva2VuIHNlcnZpY2UpLiBTbywg
dGhpcyB0aGlyZCBwYXJ0eSBjb3VsZCBiZSB0aGUgYXV0aG9yaXphdGlvbiANCnNlcnZlci4gDQo+
ID4gDQo+ID4gQ2lhbw0KPiA+IEhhbm5lcyANCj4gPiANCj4gPiANCj4gPiBGcm9tOiBvYXV0aC1i
b3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm
IA0KT2YgDQo+ID4gZXh0IE5hdCBTYWtpbXVyYQ0KPiA+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIg
MDMsIDIwMTIgMTA6MzUgQU0NCj4gPiBUbzogQnJpYW4gQ2FtcGJlbGw7IG9hdXRoDQo+ID4gU3Vi
amVjdDogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVyIGhh
dmUgdG8gYmUNCj4gPiBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNl
cnZpY2U/IA0KPiA+IA0KPiA+IEhpIEJyaWFuLCANCj4gPiANCj4gPiANCj4gPiBUaGUgYXNzZXJ0
aW9uIGZyYW1ld29yayBkZWZpbmVzIHRoZSBJc3N1ZXIgYXM6IA0KPiA+IA0KPiA+ICAgIElzc3Vl
ciAgVGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVkIHRoZSAN
Cj4gPiAgICAgICBhc3NlcnRpb24uICBHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5IHRoYXQg
aG9sZHMgdGhlIGtleSANCj4gPiAgICAgICBtYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBh
c3NlcnRpb24uICBUaGUgaXNzdWVyIG1heSBiZSANCmVpdGhlciANCj4gPiAgICAgICBhbiBPQXV0
aCBjbGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9yIGEgdGhpcmQgDQpw
YXJ0eSANCj4gPiAgICAgICB0b2tlbiBzZXJ2aWNlLiANCj4gPiANCj4gPiBJIHdhcyB3b25kZXJp
bmcgd2h5IGl0IGhhcyB0byBiZSBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IA0K
PiA+IHRva2VuIHNlcnZpY2UuIA0KPiA+IENvbmNlcHR1YWxseSwgaXQgY291bGQgYmUgYW55IHRv
a2VuIHNlcnZpY2UgKGZ1bmN0aW9uYWxpdHkpIA0KPiByZXNpZGluZ2luIGFueSBvZiANCj4gPiAN
Cj4gPiB0aGUgc3Rha2Vob2xkZXJzIChSZXNvdXJjZSBPd25lciwgT0F1dGggQ2xpZW50LCBBdXRo
b3JpemF0aW9uIFNlcnZlciwgDQpvciANCj4gPiBhIHRoaXJkIHBhcnR5KS4gDQo+ID4gDQo+ID4g
DQo+ID4gSSB3b3VsZCBhcHByZWNpYXRlIGlmIHlvdSBjb3VsZCBjbGFyaWZ5IHdoeSBpcyB0aGUg
Y2FzZS4gDQo+ID4gDQo+ID4gDQo+ID4gQmVzdCwgDQo+ID4gDQo+ID4gLS0gDQo+ID4gTmF0IFNh
a2ltdXJhICg9bmF0KSANCj4gPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4gPiBodHRw
Oi8vbmF0LnNha2ltdXJhLm9yZy8NCj4gPiBAX25hdF9lbiANCj4gPiAgX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QN
Cj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGgNCj4gDQo+ID4gDQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0
aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1
dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0K
--=_alternative 000D3E4648257ACA_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9idmlvdXNseSwgaXQgaXMgbm90
IHNvIGNsZWFyIGZyb20gdGhlDQpsYW5ndWFnZSB0aGVyZS48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj5DaHVjayBNb3J0aW1vcmUgJmx0O2Ntb3J0aW1vcmVAc2FsZXNm
b3JjZS5jb20mZ3Q7DQrQtNPaIDIwMTItMTItMDQgMTA6MTc6MTI6PGJyPg0KPGJyPg0KJmd0OyBU
aGVyZSdzIG5vIHJlYXNvbiB3aHkgaXQgY2FuJ3QgYmUgcmVzb3VyY2Ugb3duZXIgdG9kYXkuICZu
YnNwOyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBP
biBEZWMgMywgMjAxMiwgYXQgNjowNiBQTSwgJmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7
ICZsdDt6aG91LnN1amluZ0B6dGUuY29tLmNuPGJyPg0KJmd0OyAmZ3Q7IHdyb3RlOjwvZm9udD48
L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgKzEu
IDxicj4NCiZndDsgQW5kIHdoeSBpdCB3YXMgbm90IGxvb2tlZCBhdCB0aGF0IHRpbWU/IDxicj4N
CiZndDsgPGJyPg0KJmd0OyBvYXV0aC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMi0xMi0wNCAw
MTozMDo1NTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBBY3R1YWxseSwgSSB0aGluayBpdCBp
cyBhIGdvb2QgdGltZSB0byBzdGFydCBsb29raW5nIGF0IHRoZSByZXNvdXJzZTxicj4NCiZndDsg
Jmd0OyBvd25lciBpc3N1aW5nIGFzc2VydGlvbnNAIChJbnRlcmVzdGluZ2x5IGVub3VnaCwgSHVp
LUxhbiBoYWQNCmJyb3VnaHQ8YnI+DQomZ3Q7ICZndDsgdGhpcyB1cCBhIGNvdXBsZSBvZiB5ZWFy
cyBhZ28uKTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSWdvcjxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgT24gMTIvMy8yMDEyIDM6NTggQU0sIE5hdCBTYWtpbXVyYSB3cm90
ZTogPGJyPg0KJmd0OyAmZ3Q7IEkgc3VwcG9zZSwgeWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2Ug
dGhhdCBhbGwgdGhlIHRpbWUuIDxicj4NCiZndDsgJmd0OyBXaGV0aGVyIGl0IGlzIG9yIG5vdCwg
aWYgaXQgaXMgc3RpbGwgb2ssIGl0IG1pZ2h0IGJlIGJldHRlciB0bw0KY2xhcmlmeSBpdC4gPGJy
Pg0KJmd0OyAmZ3Q7IFdvcmQgbGlrZSAmcXVvdDt0aGlyZCBwYXJ0eSZxdW90OyB0ZW5kcyB0byBi
ZSBhIGJpdCBvZiBwcm9ibGVtDQp3aXRob3V0IDxicj4NCiZndDsgY2xlYXJseWRlZmluaW5nLiA8
YnI+DQomZ3Q7ICZndDsgSSBoYWQgc2ltaWxhciBleHBlcmllbmNlIGluIG90aGVyIGZvcmEuIDxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTmF0IDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgU2VudCBmcm9tIGlQYWQgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAy
MDEyLzEyLzAzIDA6NTKhoiZxdW90O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mcXVvdDsgJmx0O3po
b3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7DQqkzjxicj4NCiZndDsgJmd0OyCl4aXDpbupYKW4Ojxi
cj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBjb3VsZCBiZSBSZXNvdXJj
ZSBvd25lcj8gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmcXVvdDtUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKSZxdW90
OyAmbHQ7aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbSZndDsNCjxicj4NCiZndDsgJmd0OyC3orz+
yMs6ICZuYnNwO29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgPGJyPg0KJmd0OyAmZ3Q7IDIwMTItMTIt
MDMgMTY6NDkgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDK1bz+yMsgPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmcXVvdDtleHQgTmF0IFNha2ltdXJhJnF1b3Q7ICZsdDtz
YWtpbXVyYUBnbWFpbC5jb20mZ3Q7LCAmcXVvdDtCcmlhbg0KQ2FtcGJlbGwmcXVvdDsgJmx0Ozxi
cj4NCiZndDsgJmd0OyBiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDssICZxdW90O29hdXRo
JnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDsNCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7INb3zOIgPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBSZTogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3Jr
IC0gV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8NCmJlICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyAm
Z3Q7IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT8gPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyBIaSBOYXQsIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0K
Jmd0OyAmZ3Q7IFRoZSBjdXJyZW50IHRleHQgZXNzZW50aWFsbHkgc2F5cyB0aGF0IHRoZSBhc3Nl
cnRpb24gY2FuIGVpdGhlcg0KYmUgPGJyPg0KJmd0OyAmZ3Q7IGNyZWF0ZWQgYnkgdGhlIGNsaWVu
dCAoaW4gd2hpY2ggY2FzZSBpdCBpcyBzZWxmLXNpZ25lZCkgb3IgaXQNCmNhbiBiZTxicj4NCiZn
dDsgJmd0OyBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5ICh3aGljaCBpcyB0aGVuIGNhbGxl
ZCB0aGUgdGhpcmQNCnBhcnR5IDxicj4NCiZndDsgJmd0OyB0b2tlbiBzZXJ2aWNlKS4gU28sIHRo
aXMgdGhpcmQgcGFydHkgY291bGQgYmUgdGhlIGF1dGhvcml6YXRpb24NCnNlcnZlci4gPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgQ2lhbzxicj4NCiZndDsgJmd0OyBIYW5u
ZXMgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZn
dDsgJmd0OyBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZ10NCk9uIEJlaGFsZiBPZiA8YnI+DQomZ3Q7ICZndDsgZXh0IE5hdCBTYWtpbXVy
YTxicj4NCiZndDsgJmd0OyBTZW50OiBNb25kYXksIERlY2VtYmVyIDAzLCAyMDEyIDEwOjM1IEFN
PGJyPg0KJmd0OyAmZ3Q7IFRvOiBCcmlhbiBDYW1wYmVsbDsgb2F1dGg8YnI+DQomZ3Q7ICZndDsg
U3ViamVjdDogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVy
IGhhdmUNCnRvIGJlPGJyPg0KJmd0OyAmZ3Q7IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQg
cGFydHkgdG9rZW4gc2VydmljZT8gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZn
dDsgSGkgQnJpYW4sIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw
OyA8YnI+DQomZ3Q7ICZndDsgVGhlIGFzc2VydGlvbiBmcmFtZXdvcmsgZGVmaW5lcyB0aGUgSXNz
dWVyIGFzOiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i
c3A7SXNzdWVyICZuYnNwO1RoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIGVudGl0eQ0KdGhh
dCBpc3N1ZWQgdGhlIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhc3NlcnRp
b24uICZuYnNwO0dlbmVyYWxseSB0aGlzIGlzIHRoZSBlbnRpdHkNCnRoYXQgaG9sZHMgdGhlIGtl
eSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbWF0ZXJpYWwgdXNlZCB0byBn
ZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLg0KJm5ic3A7VGhlIGlzc3VlciBtYXkgYmUgZWl0aGVyIDxi
cj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhbiBPQXV0aCBjbGllbnQgKHdoZW4g
YXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpDQpvciBhIHRoaXJkIHBhcnR5IDxicj4NCiZndDsg
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0b2tlbiBzZXJ2aWNlLiA8YnI+DQomZ3Q7ICZndDsg
Jm5ic3A7IDxicj4NCiZndDsgJmd0OyBJIHdhcyB3b25kZXJpbmcgd2h5IGl0IGhhcyB0byBiZSBl
aXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkDQpwYXJ0eSA8YnI+DQomZ3Q7ICZndDsgdG9rZW4g
c2VydmljZS4gPGJyPg0KJmd0OyAmZ3Q7IENvbmNlcHR1YWxseSwgaXQgY291bGQgYmUgYW55IHRv
a2VuIHNlcnZpY2UgKGZ1bmN0aW9uYWxpdHkpIDxicj4NCiZndDsgcmVzaWRpbmdpbiBhbnkgb2Yg
PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgdGhlIHN0YWtlaG9sZGVycyAo
UmVzb3VyY2UgT3duZXIsIE9BdXRoIENsaWVudCwgQXV0aG9yaXphdGlvbg0KU2VydmVyLCBvciA8
YnI+DQomZ3Q7ICZndDsgYSB0aGlyZCBwYXJ0eSkuIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJy
Pg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgSSB3b3VsZCBhcHByZWNpYXRlIGlm
IHlvdSBjb3VsZCBjbGFyaWZ5IHdoeSBpcyB0aGUgY2FzZS4gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw
OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBCZXN0LCA8YnI+DQomZ3Q7
ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAtLSA8YnI+DQomZ3Q7ICZndDsgTmF0IFNha2lt
dXJhICg9bmF0KSA8YnI+DQomZ3Q7ICZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJy
Pg0KJmd0OyAmZ3Q7IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzxicj4NCiZndDsgJmd0OyBAX25h
dF9lbiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K
Jmd0OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4N
CiZndDsgJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IE9BdXRoIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1
dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvZm9udD48L3R0Pg0K
--=_alternative 000D3E4648257ACA_=--

From cmortimore@salesforce.com  Mon Dec  3 18:26:54 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDD011E809A; Mon,  3 Dec 2012 18:26:54 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oD4+YV7CyPd; Mon,  3 Dec 2012 18:26:53 -0800 (PST)
Received: from exprod8og109.obsmtp.com (exprod8og109.obsmtp.com [64.18.3.98]) by ietfa.amsl.com (Postfix) with SMTP id 3FDA321F86A5; Mon,  3 Dec 2012 18:26:53 -0800 (PST)
Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob109.postini.com ([64.18.7.12]) with SMTP ID DSNKUL1fbBPupnnQUNIA4BBCTSLYPnrFdyXa@postini.com; Mon, 03 Dec 2012 18:26:53 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Mon, 3 Dec 2012 18:26:52 -0800
From: Chuck Mortimore 
To: "" 
Date: Mon, 3 Dec 2012 18:26:50 -0800
Thread-Topic: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Thread-Index: Ac3RxtI7YYJQ31EOR8W0VZ0VVSjSrQ==
Message-ID: <7EBB51A5-A7FC-416E-BF29-D790DFAD9677@salesforce.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7EBB51A5A7FC416EBF29D790DFAD9677salesforcecom_"
MIME-Version: 1.0
Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 02:26:54 -0000

--_000_7EBB51A5A7FC416EBF29D790DFAD9677salesforcecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

UGxlYXNlIGZlZWwgZnJlZSB0byBzdWdnZXN0IGJldHRlciBsYW5ndWFnZS4NCg0KSXNzdWVyIHNp
bXBseSBhbGxvd3MgdGhlIHRva2VuIHNlcnZpY2UgdG8ga25vdyB3aG8gY3JlYXRlZCB0aGUgYXNz
ZXJ0aW9uLCBzbyBpdCBjYW4gbG9vayB0aGVtIHVwIGFuZCBzZWUgaWYgdGhleSdyZSB0cnVzdGVk
LiAgICAgRWZmZWN0aXZlbHkgdGhlIHNhbWUgYXMgYW4gSXNzdWVyIGluIFNBTUwuDQoNCi1jbW9y
dA0KDQoNCg0KT24gRGVjIDMsIDIwMTIsIGF0IDY6MjMgUE0sIDx6aG91LnN1amluZ0B6dGUuY29t
LmNuPG1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPj4gd3JvdGU6DQoNCg0KT2J2aW91c2x5
LCBpdCBpcyBub3Qgc28gY2xlYXIgZnJvbSB0aGUgbGFuZ3VhZ2UgdGhlcmUuDQoNCg0KQ2h1Y2sg
TW9ydGltb3JlIDxjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPG1haWx0bzpjbW9ydGltb3JlQHNh
bGVzZm9yY2UuY29tPj4g5YaZ5LqOIDIwMTItMTItMDQgMTA6MTc6MTI6DQoNCj4gVGhlcmUncyBu
byByZWFzb24gd2h5IGl0IGNhbid0IGJlIHJlc291cmNlIG93bmVyIHRvZGF5Lg0KPg0KPiBPbiBE
ZWMgMywgMjAxMiwgYXQgNjowNiBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFpbHRvOnpo
b3Uuc3VqaW5nQHp0ZS5jb20uY24+PiA8emhvdS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhv
dS5zdWppbmdAenRlLmNvbS5jbj4NCj4gPiB3cm90ZToNCj4NCj4NCj4gKzEuDQo+IEFuZCB3aHkg
aXQgd2FzIG5vdCBsb29rZWQgYXQgdGhhdCB0aW1lPw0KPg0KPiBvYXV0aC1ib3VuY2VzQGlldGYu
b3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiDlhpnkuo4gMjAxMi0xMi0wNCAwMToz
MDo1NToNCj4NCj4gPiBBY3R1YWxseSwgSSB0aGluayBpdCBpcyBhIGdvb2QgdGltZSB0byBzdGFy
dCBsb29raW5nIGF0IHRoZSByZXNvdXJzZQ0KPiA+IG93bmVyIGlzc3VpbmcgYXNzZXJ0aW9uc0Ag
KEludGVyZXN0aW5nbHkgZW5vdWdoLCBIdWktTGFuIGhhZCBicm91Z2h0DQo+ID4gdGhpcyB1cCBh
IGNvdXBsZSBvZiB5ZWFycyBhZ28uKQ0KPiA+DQo+ID4gSWdvcg0KPiA+DQo+ID4gT24gMTIvMy8y
MDEyIDM6NTggQU0sIE5hdCBTYWtpbXVyYSB3cm90ZToNCj4gPiBJIHN1cHBvc2UsIHllcy4gSSB3
YXMgcmVhZGluZyBpdCBsaWtlIHRoYXQgYWxsIHRoZSB0aW1lLg0KPiA+IFdoZXRoZXIgaXQgaXMg
b3Igbm90LCBpZiBpdCBpcyBzdGlsbCBvaywgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGNsYXJpZnkg
aXQuDQo+ID4gV29yZCBsaWtlICJ0aGlyZCBwYXJ0eSIgdGVuZHMgdG8gYmUgYSBiaXQgb2YgcHJv
YmxlbSB3aXRob3V0DQo+IGNsZWFybHlkZWZpbmluZy4NCj4gPiBJIGhhZCBzaW1pbGFyIGV4cGVy
aWVuY2UgaW4gb3RoZXIgZm9yYS4NCj4gPg0KPiA+IE5hdA0KPiA+DQo+ID4gU2VudCBmcm9tIGlQ
YWQNCj4gPg0KPiA+IDIwMTIvMTIvMDMgMDo1MuOAgSJ6aG91LnN1amluZ0B6dGUuY29tLmNuPG1h
aWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPiIgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFp
bHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24+PiDjga4NCj4gPiDjg6Hjg4Pjgrvjg7zjgrg6DQo+
DQo+ID4NCj4gPiBjb3VsZCBiZSBSZXNvdXJjZSBvd25lcj8NCj4gPg0KPg0KPiA+DQo+ID4gIlRz
Y2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pIiA8aGFubmVzLnRzY2hvZmVuaWdAbnNu
LmNvbTxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbT4+DQo+ID4g5Y+R5Lu25Lq6OiAg
b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4NCj4g
PiAyMDEyLTEyLTAzIDE2OjQ5DQo+ID4NCj4gPiDmlLbku7bkuroNCj4gPg0KPiA+ICJleHQgTmF0
IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+
PiwgIkJyaWFuIENhbXBiZWxsIiA8DQo+ID4gYmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFp
bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4sICJvYXV0aCIgPG9hdXRoQGlldGYub3Jn
PG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQo+ID4NCj4gPiDmioTpgIENCj4gPg0KPiA+IOS4u+mi
mA0KPiA+DQo+ID4gUmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2Vz
IGlzc3VlciBoYXZlIHRvIGJlDQo+ID4gZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0
eSB0b2tlbiBzZXJ2aWNlPw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gSGkgTmF0LA0KPiA+DQo+
ID4gVGhlIGN1cnJlbnQgdGV4dCBlc3NlbnRpYWxseSBzYXlzIHRoYXQgdGhlIGFzc2VydGlvbiBj
YW4gZWl0aGVyIGJlDQo+ID4gY3JlYXRlZCBieSB0aGUgY2xpZW50IChpbiB3aGljaCBjYXNlIGl0
IGlzIHNlbGYtc2lnbmVkKSBvciBpdCBjYW4gYmUNCj4gPiBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIg
ZW50aXR5ICh3aGljaCBpcyB0aGVuIGNhbGxlZCB0aGUgdGhpcmQgcGFydHkNCj4gPiB0b2tlbiBz
ZXJ2aWNlKS4gU28sIHRoaXMgdGhpcmQgcGFydHkgY291bGQgYmUgdGhlIGF1dGhvcml6YXRpb24g
c2VydmVyLg0KPiA+DQo+ID4gQ2lhbw0KPiA+IEhhbm5lcw0KPiA+DQo+ID4NCj4gPiBGcm9tOiBv
YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiBbbWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiA+IGV4dCBOYXQgU2Fr
aW11cmENCj4gPiBTZW50OiBNb25kYXksIERlY2VtYmVyIDAzLCAyMDEyIDEwOjM1IEFNDQo+ID4g
VG86IEJyaWFuIENhbXBiZWxsOyBvYXV0aA0KPiA+IFN1YmplY3Q6IFtPQVVUSC1XR10gQXNzZXJ0
aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlIHRvIGJlDQo+ID4gZWl0aGVyIHRo
ZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPw0KPiA+DQo+ID4gSGkgQnJp
YW4sDQo+ID4NCj4gPg0KPiA+IFRoZSBhc3NlcnRpb24gZnJhbWV3b3JrIGRlZmluZXMgdGhlIElz
c3VlciBhczoNCj4gPg0KPiA+ICAgIElzc3VlciAgVGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0
aGUgZW50aXR5IHRoYXQgaXNzdWVkIHRoZQ0KPiA+ICAgICAgIGFzc2VydGlvbi4gIEdlbmVyYWxs
eSB0aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUga2V5DQo+ID4gICAgICAgbWF0ZXJp
YWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLiAgVGhlIGlzc3VlciBtYXkgYmUgZWl0
aGVyDQo+ID4gICAgICAgYW4gT0F1dGggY2xpZW50ICh3aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYt
aXNzdWVkKSBvciBhIHRoaXJkIHBhcnR5DQo+ID4gICAgICAgdG9rZW4gc2VydmljZS4NCj4gPg0K
PiA+IEkgd2FzIHdvbmRlcmluZyB3aHkgaXQgaGFzIHRvIGJlIGVpdGhlciB0aGUgY2xpZW50IG9y
IGEgdGhpcmQgcGFydHkNCj4gPiB0b2tlbiBzZXJ2aWNlLg0KPiA+IENvbmNlcHR1YWxseSwgaXQg
Y291bGQgYmUgYW55IHRva2VuIHNlcnZpY2UgKGZ1bmN0aW9uYWxpdHkpDQo+IHJlc2lkaW5naW4g
YW55IG9mDQo+ID4NCj4gPiB0aGUgc3Rha2Vob2xkZXJzIChSZXNvdXJjZSBPd25lciwgT0F1dGgg
Q2xpZW50LCBBdXRob3JpemF0aW9uIFNlcnZlciwgb3INCj4gPiBhIHRoaXJkIHBhcnR5KS4NCj4g
Pg0KPiA+DQo+ID4gSSB3b3VsZCBhcHByZWNpYXRlIGlmIHlvdSBjb3VsZCBjbGFyaWZ5IHdoeSBp
cyB0aGUgY2FzZS4NCj4gPg0KPiA+DQo+ID4gQmVzdCwNCj4gPg0KPiA+IC0tDQo+ID4gTmF0IFNh
a2ltdXJhICg9bmF0KQ0KPiA+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPiA+IGh0dHA6
Ly9uYXQuc2FraW11cmEub3JnLw0KPiA+IEBfbmF0X2VuDQo+ID4gIF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+
ID4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4gPg0KPiA+DQo+ID4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBtYWls
aW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+ID4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0
DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo=

--_000_7EBB51A5A7FC416EBF29D790DFAD9677salesforcecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13
ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z
cGFjZTsgIj48ZGl2PlBsZWFzZSBmZWVsIGZyZWUgdG8gc3VnZ2VzdCBiZXR0ZXIgbGFuZ3VhZ2Uu
PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Jc3N1ZXIgc2ltcGx5IGFsbG93cyB0aGUgdG9rZW4g
c2VydmljZSB0byBrbm93IHdobyBjcmVhdGVkIHRoZSBhc3NlcnRpb24sIHNvIGl0IGNhbiBsb29r
IHRoZW0gdXAgYW5kIHNlZSBpZiB0aGV5J3JlIHRydXN0ZWQuICZuYnNwOyAmbmJzcDsgRWZmZWN0
aXZlbHkgdGhlIHNhbWUgYXMgYW4gSXNzdWVyIGluIFNBTUwuPC9kaXY+PGRpdj48YnI+PC9kaXY+
PGRpdj4tY21vcnQ8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48YnI+PGRpdj48
ZGl2Pk9uIERlYyAzLCAyMDEyLCBhdCA2OjIzIFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpob3Uu
c3VqaW5nQHp0ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L2E+Jmd0OyB3cm90ZTo8
L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiPg0KPGJyPjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2VyaWYiPk9idmlvdXNs
eSwgaXQgaXMgbm90IHNvIGNsZWFyIGZyb20gdGhlDQpsYW5ndWFnZSB0aGVyZS48L2ZvbnQ+DQo8
YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9IjIiPkNodWNrIE1vcnRpbW9yZSAmbHQ7PGEg
aHJlZj0ibWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20iPmNtb3J0aW1vcmVAc2FsZXNm
b3JjZS5jb208L2E+Jmd0Ow0K5YaZ5LqOIDIwMTItMTItMDQgMTA6MTc6MTI6PGJyPg0KPGJyPg0K
Jmd0OyBUaGVyZSdzIG5vIHJlYXNvbiB3aHkgaXQgY2FuJ3QgYmUgcmVzb3VyY2Ugb3duZXIgdG9k
YXkuICZuYnNwOyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+Jmd0OyA8YnI+
DQomZ3Q7IE9uIERlYyAzLCAyMDEyLCBhdCA2OjA2IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpo
b3Uuc3VqaW5nQHp0ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L2E+Jmd0OyAmbHQ7
PGEgaHJlZj0ibWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5j
b20uY248L2E+PGJyPg0KJmd0OyAmZ3Q7IHdyb3RlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyArMS4gPGJyPg0KJmd0OyBBbmQg
d2h5IGl0IHdhcyBub3QgbG9va2VkIGF0IHRoYXQgdGltZT8gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IDxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGll
dGYub3JnPC9hPiDlhpnkuo4gMjAxMi0xMi0wNCAwMTozMDo1NTo8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgJmd0OyBBY3R1YWxseSwgSSB0aGluayBpdCBpcyBhIGdvb2QgdGltZSB0byBzdGFydCBsb29r
aW5nIGF0IHRoZSByZXNvdXJzZTxicj4NCiZndDsgJmd0OyBvd25lciBpc3N1aW5nIGFzc2VydGlv
bnNAIChJbnRlcmVzdGluZ2x5IGVub3VnaCwgSHVpLUxhbiBoYWQNCmJyb3VnaHQ8YnI+DQomZ3Q7
ICZndDsgdGhpcyB1cCBhIGNvdXBsZSBvZiB5ZWFycyBhZ28uKTxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgSWdvcjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gMTIvMy8y
MDEyIDM6NTggQU0sIE5hdCBTYWtpbXVyYSB3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7IEkgc3VwcG9z
ZSwgeWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhhdCBhbGwgdGhlIHRpbWUuIDxicj4NCiZn
dDsgJmd0OyBXaGV0aGVyIGl0IGlzIG9yIG5vdCwgaWYgaXQgaXMgc3RpbGwgb2ssIGl0IG1pZ2h0
IGJlIGJldHRlciB0bw0KY2xhcmlmeSBpdC4gPGJyPg0KJmd0OyAmZ3Q7IFdvcmQgbGlrZSAidGhp
cmQgcGFydHkiIHRlbmRzIHRvIGJlIGEgYml0IG9mIHByb2JsZW0NCndpdGhvdXQgPGJyPg0KJmd0
OyBjbGVhcmx5ZGVmaW5pbmcuIDxicj4NCiZndDsgJmd0OyBJIGhhZCBzaW1pbGFyIGV4cGVyaWVu
Y2UgaW4gb3RoZXIgZm9yYS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBOYXQgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTZW50IGZyb20gaVBhZCA8YnI+DQomZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IDIwMTIvMTIvMDMgMDo1MuOAgSI8YSBocmVmPSJtYWlsdG86emhv
dS5zdWppbmdAenRlLmNvbS5jbiI+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvYT4iICZsdDs8YSBo
cmVmPSJtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbiI+emhvdS5zdWppbmdAenRlLmNvbS5j
bjwvYT4mZ3Q7DQrjga48YnI+DQomZ3Q7ICZndDsg44Oh44OD44K744O844K4Ojxicj4NCiZndDsg
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBjb3VsZCBiZSBSZXNvdXJjZSBvd25lcj8g
PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyAiVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykiICZsdDs8YSBocmVmPSJtYWls
dG86aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbSI+aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbTwv
YT4mZ3Q7DQo8YnI+DQomZ3Q7ICZndDsg5Y+R5Lu25Lq6OiAmbmJzcDs8YSBocmVmPSJtYWlsdG86
b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gPGJyPg0K
Jmd0OyAmZ3Q7IDIwMTItMTItMDMgMTY6NDkgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyDmlLbku7bkurogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAiZXh0IE5hdCBTYWtp
bXVyYSIgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPnNha2ltdXJhQGdt
YWlsLmNvbTwvYT4mZ3Q7LCAiQnJpYW4NCkNhbXBiZWxsIiAmbHQ7PGJyPg0KJmd0OyAmZ3Q7IDxh
IGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSI+YmNhbXBiZWxsQHBpbmdp
ZGVudGl0eS5jb208L2E+Jmd0OywgIm9hdXRoIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGll
dGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT4mZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7IOaKhOmAgSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IOS4u+mimCA8YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFJlOiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFt
ZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0bw0KYmUgJm5ic3A7ICZuYnNwOyA8YnI+DQom
Z3Q7ICZndDsgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNl
PyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpIE5hdCwgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8
YnI+DQomZ3Q7ICZndDsgVGhlIGN1cnJlbnQgdGV4dCBlc3NlbnRpYWxseSBzYXlzIHRoYXQgdGhl
IGFzc2VydGlvbiBjYW4gZWl0aGVyDQpiZSA8YnI+DQomZ3Q7ICZndDsgY3JlYXRlZCBieSB0aGUg
Y2xpZW50IChpbiB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2lnbmVkKSBvciBpdA0KY2FuIGJlPGJy
Pg0KJmd0OyAmZ3Q7IGNyZWF0ZWQgYnkgc29tZSBvdGhlciBlbnRpdHkgKHdoaWNoIGlzIHRoZW4g
Y2FsbGVkIHRoZSB0aGlyZA0KcGFydHkgPGJyPg0KJmd0OyAmZ3Q7IHRva2VuIHNlcnZpY2UpLiBT
bywgdGhpcyB0aGlyZCBwYXJ0eSBjb3VsZCBiZSB0aGUgYXV0aG9yaXphdGlvbg0Kc2VydmVyLiA8
YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBDaWFvPGJyPg0KJmd0OyAmZ3Q7
IEhhbm5lcyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJy
Pg0KJmd0OyAmZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn
Ij5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmddDQpPbiBCZWhhbGYgT2YgPGJyPg0KJmd0OyAmZ3Q7IGV4dCBOYXQgU2FraW11cmE8YnI+DQom
Z3Q7ICZndDsgU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAxMiAxMDozNSBBTTxicj4NCiZn
dDsgJmd0OyBUbzogQnJpYW4gQ2FtcGJlbGw7IG9hdXRoPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6
IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlDQp0
byBiZTxicj4NCiZndDsgJmd0OyBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRv
a2VuIHNlcnZpY2U/IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEhpIEJy
aWFuLCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0K
Jmd0OyAmZ3Q7IFRoZSBhc3NlcnRpb24gZnJhbWV3b3JrIGRlZmluZXMgdGhlIElzc3VlciBhczog
PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0lzc3Vl
ciAmbmJzcDtUaGUgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkNCnRoYXQgaXNzdWVk
IHRoZSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYXNzZXJ0aW9uLiAmbmJz
cDtHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5DQp0aGF0IGhvbGRzIHRoZSBrZXkgPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1hdGVyaWFsIHVzZWQgdG8gZ2VuZXJhdGUg
dGhlIGFzc2VydGlvbi4NCiZuYnNwO1RoZSBpc3N1ZXIgbWF5IGJlIGVpdGhlciA8YnI+DQomZ3Q7
ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYW4gT0F1dGggY2xpZW50ICh3aGVuIGFzc2VydGlv
bnMgYXJlIHNlbGYtaXNzdWVkKQ0Kb3IgYSB0aGlyZCBwYXJ0eSA8YnI+DQomZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgdG9rZW4gc2VydmljZS4gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyA8
YnI+DQomZ3Q7ICZndDsgSSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8gYmUgZWl0aGVyIHRo
ZSBjbGllbnQgb3IgYSB0aGlyZA0KcGFydHkgPGJyPg0KJmd0OyAmZ3Q7IHRva2VuIHNlcnZpY2Uu
IDxicj4NCiZndDsgJmd0OyBDb25jZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBzZXJ2
aWNlIChmdW5jdGlvbmFsaXR5KSA8YnI+DQomZ3Q7IHJlc2lkaW5naW4gYW55IG9mIDxicj4NCiZn
dDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IHRoZSBzdGFrZWhvbGRlcnMgKFJlc291cmNl
IE93bmVyLCBPQXV0aCBDbGllbnQsIEF1dGhvcml6YXRpb24NClNlcnZlciwgb3IgPGJyPg0KJmd0
OyAmZ3Q7IGEgdGhpcmQgcGFydHkpLiA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsg
Jmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7IEkgd291bGQgYXBwcmVjaWF0ZSBpZiB5b3UgY291
bGQgY2xhcmlmeSB3aHkgaXMgdGhlIGNhc2UuIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgQmVzdCwgPGJyPg0KJmd0OyAmZ3Q7ICZu
YnNwOyA8YnI+DQomZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7IE5hdCBTYWtpbXVyYSAoPW5h
dCkgPGJyPg0KJmd0OyAmZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsg
Jmd0OyA8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iPmh0dHA6Ly9uYXQuc2FraW11
cmEub3JnLzwvYT48YnI+DQomZ3Q7ICZndDsgQF9uYXRfZW4gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw
O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0
OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVm
PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgT0F1dGggbWFpbGlu
ZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1
dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlz
dDxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGll
dGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoPC9hPjxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7
IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9mb250PjwvdHQ+
DQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvYm9keT48L2h0bWw+

--_000_7EBB51A5A7FC416EBF29D790DFAD9677salesforcecom_--

From zhou.sujing@zte.com.cn  Mon Dec  3 18:40:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD281F0C4A; Mon,  3 Dec 2012 18:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.095
X-Spam-Level: 
X-Spam-Status: No, score=-98.095 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ssUQkvUw7+7; Mon,  3 Dec 2012 18:40:34 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 227D221F88FA; Mon,  3 Dec 2012 18:40:34 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 0EE3A7A698A; Tue,  4 Dec 2012 10:40:22 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id D1BB971B42F; Tue,  4 Dec 2012 10:38:35 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qB42eCdQ097037; Tue, 4 Dec 2012 10:40:12 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <7EBB51A5-A7FC-416E-BF29-D790DFAD9677@salesforce.com>
To: Chuck Mortimore 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Tue, 4 Dec 2012 10:40:09 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-04 10:40:11, Serialize complete at 2012-12-04 10:40:11
Content-Type: multipart/alternative; boundary="=_alternative 000EC76948257ACA_="
X-MAIL: mse02.zte.com.cn qB42eCdQ097037
Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 02:40:35 -0000

This is a multipart message in MIME format.
--=_alternative 000EC76948257ACA_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

Q2h1Y2sgTW9ydGltb3JlIDxjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPiDQtNPaIDIwMTItMTIt
MDQgMTA6MjY6NTA6DQoNCj4gUGxlYXNlIGZlZWwgZnJlZSB0byBzdWdnZXN0IGJldHRlciBsYW5n
dWFnZS4NCj4gDQo+IElzc3VlciBzaW1wbHkgYWxsb3dzIHRoZSB0b2tlbiBzZXJ2aWNlIHRvIGtu
b3cgd2hvIGNyZWF0ZWQgdGhlIA0KPiBhc3NlcnRpb24sIHNvIGl0IGNhbiBsb29rIHRoZW0gdXAg
YW5kIHNlZSBpZiB0aGV5J3JlIHRydXN0ZWQuIA0KPiBFZmZlY3RpdmVseSB0aGUgc2FtZSBhcyBh
biBJc3N1ZXIgaW4gU0FNTC4NCg0KYSBjb25mbGljdCA6ICJUaGUgdG9rZW4gc2VydmljZSBpcyB0
aGUgYXNzZXJ0aW9uIGlzc3VlciIgaW4gYXNzZXJ0aW9uIA0KZG9jdW1lbnQuDQp3aGlsZSB5b3Ug
c2FpZCAidG9rZW4gc2VydmljZSBrbm93IHdobyBjcmVhdGVkIHRoZSBhc3NlcnRpb24iDQoNCkkg
d29uZGVyIGlmIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBhY2NlcHRhYmxlOg0KIA0KICBJc3N1ZXIg
IFRoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGUNCiAg
ICAgIGFzc2VydGlvbi4gIEdlbmVyYWxseSB0aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBob2xkcyB0
aGUga2V5DQogICAgICBtYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uICBU
aGUgaXNzdWVyIG1heSBiZSBlaXRoZXINCiAgICAgIGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3Nl
cnRpb25zIGFyZSBzZWxmLWlzc3VlZCkgb3IgYW55IG90aGVyIA0KZW50aXR5LCBlLmcuLCAgYSB0
aGlyZCBwYXJ0eSANCnRva2VuIHNlcnZpY2UsIHJlc291cmNlIG93bmVyLg0KDQoNCjYuMy4gIENs
aWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGEgVXNlcg0KDQpUaGUgSXNzdWVyIG9mIHRoZSBhc3Nl
cnRpb24gTVVTVCBpZGVudGlmeSB0aGUgZW50aXR5IHRoYXQgaXNzdWVkDQogICAgICB0aGUgYXNz
ZXJ0aW9uIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiAgSWYgdGhl
DQogICAgICBhc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRoZSBJc3N1ZXIgU0hPVUxEIGJlIHRo
ZSAiY2xpZW50X2lkIi4NCiAgICAgIElmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSBhIFNl
Y3VyaXR5IFRva2VuIFNlcnZpY2UgKFNUUyksIHRoZQ0KICAgICAgSXNzdWVyIFNIT1VMRCBpZGVu
dGlmeSB0aGUgU1RTIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24NCiAgICAgIFNl
cnZlci5JZiB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCB0
aGUNCiAgICAgIElzc3VlciBTSE9VTEQgaWRlbnRpZnkgdGhlIHJlc291cmNlIG93bmVyIGFzIHJl
Y29nbml6ZWQgYnkgdGhlIA0KQXV0aG9yaXphdGlvbg0KICAgICAgU2VydmVyLg0KDQo+IA0KPiAt
Y21vcnQNCj4gDQo+IE9uIERlYyAzLCAyMDEyLCBhdCA2OjIzIFBNLCA8emhvdS5zdWppbmdAenRl
LmNvbS5jbj4gd3JvdGU6DQo+IA0KPiANCj4gT2J2aW91c2x5LCBpdCBpcyBub3Qgc28gY2xlYXIg
ZnJvbSB0aGUgbGFuZ3VhZ2UgdGhlcmUuIA0KPiANCj4gDQo+IENodWNrIE1vcnRpbW9yZSA8Y21v
cnRpbW9yZUBzYWxlc2ZvcmNlLmNvbT4g0LTT2iAyMDEyLTEyLTA0IDEwOjE3OjEyOg0KPiANCj4g
PiBUaGVyZSdzIG5vIHJlYXNvbiB3aHkgaXQgY2FuJ3QgYmUgcmVzb3VyY2Ugb3duZXIgdG9kYXku
IA0KPiA+IA0KPiA+IE9uIERlYyAzLCAyMDEyLCBhdCA2OjA2IFBNLCA8emhvdS5zdWppbmdAenRl
LmNvbS5jbj4gDQo8emhvdS5zdWppbmdAenRlLmNvbS5jbg0KPiA+ID4gd3JvdGU6IA0KPiA+IA0K
PiA+IA0KPiA+ICsxLiANCj4gPiBBbmQgd2h5IGl0IHdhcyBub3QgbG9va2VkIGF0IHRoYXQgdGlt
ZT8gDQo+ID4gDQo+ID4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTItMTItMDQgMDE6
MzA6NTU6DQo+ID4gDQo+ID4gPiBBY3R1YWxseSwgSSB0aGluayBpdCBpcyBhIGdvb2QgdGltZSB0
byBzdGFydCBsb29raW5nIGF0IHRoZSByZXNvdXJzZQ0KPiA+ID4gb3duZXIgaXNzdWluZyBhc3Nl
cnRpb25zQCAoSW50ZXJlc3RpbmdseSBlbm91Z2gsIEh1aS1MYW4gaGFkIGJyb3VnaHQNCj4gPiA+
IHRoaXMgdXAgYSBjb3VwbGUgb2YgeWVhcnMgYWdvLikNCj4gPiA+IA0KPiA+ID4gSWdvcg0KPiA+
ID4gDQo+ID4gPiBPbiAxMi8zLzIwMTIgMzo1OCBBTSwgTmF0IFNha2ltdXJhIHdyb3RlOiANCj4g
PiA+IEkgc3VwcG9zZSwgeWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhhdCBhbGwgdGhlIHRp
bWUuIA0KPiA+ID4gV2hldGhlciBpdCBpcyBvciBub3QsIGlmIGl0IGlzIHN0aWxsIG9rLCBpdCBt
aWdodCBiZSBiZXR0ZXIgdG8gDQo+IGNsYXJpZnkgaXQuIA0KPiA+ID4gV29yZCBsaWtlICJ0aGly
ZCBwYXJ0eSIgdGVuZHMgdG8gYmUgYSBiaXQgb2YgcHJvYmxlbSB3aXRob3V0IA0KPiA+IGNsZWFy
bHlkZWZpbmluZy4gDQo+ID4gPiBJIGhhZCBzaW1pbGFyIGV4cGVyaWVuY2UgaW4gb3RoZXIgZm9y
YS4gDQo+ID4gPiANCj4gPiA+IE5hdCANCj4gPiA+IA0KPiA+ID4gU2VudCBmcm9tIGlQYWQgDQo+
ID4gPiANCj4gPiA+IDIwMTIvMTIvMDMgMDo1MqGiInpob3Uuc3VqaW5nQHp0ZS5jb20uY24iIDx6
aG91LnN1amluZ0B6dGUuY29tLmNuPiANCqTODQo+ID4gPiCl4aXDpbupYKW4Og0KPiA+IA0KPiA+
ID4gDQo+ID4gPiBjb3VsZCBiZSBSZXNvdXJjZSBvd25lcj8gDQo+ID4gPiANCj4gPiANCj4gPiA+
IA0KPiA+ID4gIlRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pIiA8aGFubmVzLnRz
Y2hvZmVuaWdAbnNuLmNvbT4gDQo+ID4gPiC3orz+yMs6ICBvYXV0aC1ib3VuY2VzQGlldGYub3Jn
IA0KPiA+ID4gMjAxMi0xMi0wMyAxNjo0OSANCj4gPiA+IA0KPiA+ID4gytW8/sjLIA0KPiA+ID4g
DQo+ID4gPiAiZXh0IE5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNvbT4sICJCcmlhbiBD
YW1wYmVsbCIgPA0KPiA+ID4gYmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+LCAib2F1dGgiIDxv
YXV0aEBpZXRmLm9yZz4gDQo+ID4gPiANCj4gPiA+ILOty80gDQo+ID4gPiANCj4gPiA+INb3zOIg
DQo+ID4gPiANCj4gPiA+IFJlOiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkg
ZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZSANCj4gPiA+IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhp
cmQgcGFydHkgdG9rZW4gc2VydmljZT8gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiAN
Cj4gPiA+IEhpIE5hdCwgDQo+ID4gPiANCj4gPiA+IFRoZSBjdXJyZW50IHRleHQgZXNzZW50aWFs
bHkgc2F5cyB0aGF0IHRoZSBhc3NlcnRpb24gY2FuIGVpdGhlciBiZSANCj4gPiA+IGNyZWF0ZWQg
YnkgdGhlIGNsaWVudCAoaW4gd2hpY2ggY2FzZSBpdCBpcyBzZWxmLXNpZ25lZCkgb3IgaXQgY2Fu
IGJlDQo+ID4gPiBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5ICh3aGljaCBpcyB0aGVuIGNh
bGxlZCB0aGUgdGhpcmQgcGFydHkgDQo+ID4gPiB0b2tlbiBzZXJ2aWNlKS4gU28sIHRoaXMgdGhp
cmQgcGFydHkgY291bGQgYmUgdGhlIGF1dGhvcml6YXRpb24gDQpzZXJ2ZXIuIA0KPiA+ID4gDQo+
ID4gPiBDaWFvDQo+ID4gPiBIYW5uZXMgDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gRnJvbTogb2F1
dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0K
QmVoYWxmIE9mIA0KPiA+ID4gZXh0IE5hdCBTYWtpbXVyYQ0KPiA+ID4gU2VudDogTW9uZGF5LCBE
ZWNlbWJlciAwMywgMjAxMiAxMDozNSBBTQ0KPiA+ID4gVG86IEJyaWFuIENhbXBiZWxsOyBvYXV0
aA0KPiA+ID4gU3ViamVjdDogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRv
ZXMgaXNzdWVyIGhhdmUgdG8gYmUNCj4gPiA+IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQg
cGFydHkgdG9rZW4gc2VydmljZT8gDQo+ID4gPiANCj4gPiA+IEhpIEJyaWFuLCANCj4gPiA+IA0K
PiA+ID4gDQo+ID4gPiBUaGUgYXNzZXJ0aW9uIGZyYW1ld29yayBkZWZpbmVzIHRoZSBJc3N1ZXIg
YXM6IA0KPiA+ID4gDQo+ID4gPiAgICBJc3N1ZXIgIFRoZSB1bmlxdWUgaWRlbnRpZmllciBmb3Ig
dGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGUgDQo+ID4gPiAgICAgICBhc3NlcnRpb24uICBHZW5l
cmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5IHRoYXQgaG9sZHMgdGhlIGtleSANCj4gPiA+ICAgICAg
IG1hdGVyaWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gIFRoZSBpc3N1ZXIgbWF5
IGJlIA0KZWl0aGVyIA0KPiA+ID4gICAgICAgYW4gT0F1dGggY2xpZW50ICh3aGVuIGFzc2VydGlv
bnMgYXJlIHNlbGYtaXNzdWVkKSBvciBhIHRoaXJkIA0KcGFydHkgDQo+ID4gPiAgICAgICB0b2tl
biBzZXJ2aWNlLiANCj4gPiA+IA0KPiA+ID4gSSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8g
YmUgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSANCj4gPiA+IHRva2VuIHNlcnZp
Y2UuIA0KPiA+ID4gQ29uY2VwdHVhbGx5LCBpdCBjb3VsZCBiZSBhbnkgdG9rZW4gc2VydmljZSAo
ZnVuY3Rpb25hbGl0eSkgDQo+ID4gcmVzaWRpbmdpbiBhbnkgb2YgDQo+ID4gPiANCj4gPiA+IHRo
ZSBzdGFrZWhvbGRlcnMgKFJlc291cmNlIE93bmVyLCBPQXV0aCBDbGllbnQsIEF1dGhvcml6YXRp
b24gDQpTZXJ2ZXIsIG9yIA0KPiA+ID4gYSB0aGlyZCBwYXJ0eSkuIA0KPiA+ID4gDQo+ID4gPiAN
Cj4gPiA+IEkgd291bGQgYXBwcmVjaWF0ZSBpZiB5b3UgY291bGQgY2xhcmlmeSB3aHkgaXMgdGhl
IGNhc2UuIA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IEJlc3QsIA0KPiA+ID4gDQo+ID4gPiAtLSAN
Cj4gPiA+IE5hdCBTYWtpbXVyYSAoPW5hdCkgDQo+ID4gPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5k
YXRpb24NCj4gPiA+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiA+ID4gQF9uYXRfZW4gDQo+
ID4gPiAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
PiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiA+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiANCj4gPiA+IA0KPiA+
ID4gDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+ID4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1h
aWxpbmcgbGlzdA0KPiA+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRo
QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aCANCg==
--=_alternative 000EC76948257ACA_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5DaHVjayBNb3J0aW1vcmUgJmx0O2Nt
b3J0aW1vcmVAc2FsZXNmb3JjZS5jb20mZ3Q7DQrQtNPaIDIwMTItMTItMDQgMTA6MjY6NTA6PGJy
Pg0KPGJyPg0KJmd0OyBQbGVhc2UgZmVlbCBmcmVlIHRvIHN1Z2dlc3QgYmV0dGVyIGxhbmd1YWdl
LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IElzc3Vl
ciBzaW1wbHkgYWxsb3dzIHRoZSB0b2tlbiBzZXJ2aWNlIHRvIGtub3cgd2hvIGNyZWF0ZWQgdGhl
IDxicj4NCiZndDsgYXNzZXJ0aW9uLCBzbyBpdCBjYW4gbG9vayB0aGVtIHVwIGFuZCBzZWUgaWYg
dGhleSdyZSB0cnVzdGVkLiAmbmJzcDsNCiZuYnNwOyA8YnI+DQomZ3Q7IEVmZmVjdGl2ZWx5IHRo
ZSBzYW1lIGFzIGFuIElzc3VlciBpbiBTQU1MLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+YSBjb25mbGljdCA6ICZxdW90OzwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXpl
PTM+VGhlDQp0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVyPC9mb250PjwvdHQ+
PHR0Pjxmb250IHNpemU9Mj4mcXVvdDsNCmluIGFzc2VydGlvbiBkb2N1bWVudC48L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPndoaWxlIHlvdSBzYWlkICZxdW90O3Rva2VuIHNlcnZp
Y2Uga25vdyB3aG8gY3JlYXRlZA0KdGhlIGFzc2VydGlvbiZxdW90OzwvZm9udD48L3R0Pg0KPGJy
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSB3b25kZXIgaWYgdGhlIGZvbGxvd2luZyB0ZXh0IGlz
IGFjY2VwdGFibGU6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDs8L2Zv
bnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDsg
SXNzdWVyICZuYnNwO1RoZSB1bmlxdWUNCmlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBp
c3N1ZWQgdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
PiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFzc2VydGlvbi4NCiZuYnNwO0dlbmVyYWxseSB0aGlzIGlz
IHRoZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUga2V5PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyAmbmJzcDsgJm5ic3A7IG1hdGVyaWFsIHVzZWQN
CnRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uICZuYnNwO1RoZSBpc3N1ZXIgbWF5IGJlIGVpdGhl
cjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDsg
Jm5ic3A7ICZuYnNwOyBhbiBPQXV0aCBjbGllbnQNCih3aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYt
aXNzdWVkKSBvcjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9cmVkIGZhY2U9IlRpbWVzIE5ldyBS
b21hbiI+DQphbnkgb3RoZXIgZW50aXR5LCBlLmcuLCAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+YQ0KdGhpcmQgcGFydHkgPC9mb250Pg0KPGJyPjxmb250
IHNpemU9Mz50b2tlbiBzZXJ2aWNlPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1yZWQ+LCByZXNv
dXJjZQ0Kb3duZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zPi48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+
PHR0Pjxmb250IHNpemU9Mj42LjMuICZuYnNwO0NsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGEg
VXNlcjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhlIElzc3VlciBv
ZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVudGl0eQ0KdGhhdCBpc3N1ZWQ8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRoZSBh
c3NlcnRpb24gYXMgcmVjb2duaXplZCBieQ0KdGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiAmbmJz
cDtJZiB0aGU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7IGFzc2VydGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlDQpJc3N1ZXIgU0hPVUxEIGJlIHRo
ZSAmcXVvdDtjbGllbnRfaWQmcXVvdDsuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBJZiB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkNCmEg
U2VjdXJpdHkgVG9rZW4gU2VydmljZSAoU1RTKSwgdGhlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm
b250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRo
ZSBTVFMNCmFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb248L2ZvbnQ+PC90dD4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDsgJm5ic3A7IFNlcnZlci48L2ZvbnQ+PC90
dD48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZD5JZg0KdGhlIGFzc2VydGlvbiB3YXMgaXNzdWVk
IGJ5IHRoZSByZXNvdXJjZSBvd25lciwgdGhlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp
emU9MiBjb2xvcj1yZWQ+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSXNzdWVyIFNIT1VMRCBpZGVudGlm
eQ0KdGhlIHJlc291cmNlIG93bmVyIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb248
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZD4mbmJzcDsgJm5ic3A7
ICZuYnNwOyBTZXJ2ZXIuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7IDxicj4NCiZndDsgLWNtb3J0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7IDxicj4NCiZndDsgT24gRGVjIDMsIDIwMTIsIGF0IDY6MjMgUE0sICZsdDt6aG91LnN1amlu
Z0B6dGUuY29tLmNuJmd0OyB3cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y
PiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9idmlvdXNseSwgaXQgaXMgbm90IHNvIGNsZWFy
IGZyb20gdGhlIGxhbmd1YWdlIHRoZXJlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0
OyBDaHVjayBNb3J0aW1vcmUgJmx0O2Ntb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20mZ3Q7INC009og
MjAxMi0xMi0wNA0KMTA6MTc6MTI6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlcmUncyBu
byByZWFzb24gd2h5IGl0IGNhbid0IGJlIHJlc291cmNlIG93bmVyIHRvZGF5LiAmbmJzcDsNCjxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gRGVjIDMsIDIwMTIsIGF0IDY6MDYgUE0s
ICZsdDt6aG91LnN1amluZ0B6dGUuY29tLmNuJmd0OyAmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5j
bjxicj4NCiZndDsgJmd0OyAmZ3Q7IHdyb3RlOiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyArMS4gPGJyPg0KJmd0OyAmZ3Q7IEFuZCB3aHkgaXQgd2FzIG5v
dCBsb29rZWQgYXQgdGhhdCB0aW1lPyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IG9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTEyLTA0IDAxOjMwOjU1Ojxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgSSB0aGluayBpdCBpcyBhIGdvb2Qg
dGltZSB0byBzdGFydCBsb29raW5nIGF0DQp0aGUgcmVzb3Vyc2U8YnI+DQomZ3Q7ICZndDsgJmd0
OyBvd25lciBpc3N1aW5nIGFzc2VydGlvbnNAIChJbnRlcmVzdGluZ2x5IGVub3VnaCwgSHVpLUxh
bg0KaGFkIGJyb3VnaHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGlzIHVwIGEgY291cGxlIG9mIHll
YXJzIGFnby4pPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSWdvcjxi
cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIDEyLzMvMjAxMiAzOjU4
IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgc3VwcG9zZSwg
eWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhhdCBhbGwgdGhlIHRpbWUuDQo8YnI+DQomZ3Q7
ICZndDsgJmd0OyBXaGV0aGVyIGl0IGlzIG9yIG5vdCwgaWYgaXQgaXMgc3RpbGwgb2ssIGl0IG1p
Z2h0IGJlIGJldHRlcg0KdG8gPGJyPg0KJmd0OyBjbGFyaWZ5IGl0LiA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyBXb3JkIGxpa2UgJnF1b3Q7dGhpcmQgcGFydHkmcXVvdDsgdGVuZHMgdG8gYmUgYSBiaXQg
b2YgcHJvYmxlbQ0Kd2l0aG91dCA8YnI+DQomZ3Q7ICZndDsgY2xlYXJseWRlZmluaW5nLiA8YnI+
DQomZ3Q7ICZndDsgJmd0OyBJIGhhZCBzaW1pbGFyIGV4cGVyaWVuY2UgaW4gb3RoZXIgZm9yYS4g
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTmF0IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQgZnJvbSBpUGFkIDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDIwMTIvMTIvMDMgMDo1MqGiJnF1b3Q7emhv
dS5zdWppbmdAenRlLmNvbS5jbiZxdW90OyAmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDsN
CqTOPGJyPg0KJmd0OyAmZ3Q7ICZndDsgpeGlw6W7qWCluDo8YnI+DQomZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY291bGQgYmUgUmVzb3VyY2Ugb3du
ZXI/IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmcXVvdDtUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAt
IEZJL0VzcG9vKSZxdW90OyAmbHQ7aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbSZndDsNCjxicj4N
CiZndDsgJmd0OyAmZ3Q7ILeivP7IyzogJm5ic3A7b2F1dGgtYm91bmNlc0BpZXRmLm9yZyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAyMDEyLTEyLTAzIDE2OjQ5IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IMrVvP7IyyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmcXVvdDtleHQgTmF0IFNha2ltdXJhJnF1b3Q7ICZsdDtzYWtpbXVyYUBnbWFp
bC5jb20mZ3Q7LA0KJnF1b3Q7QnJpYW4gQ2FtcGJlbGwmcXVvdDsgJmx0Ozxicj4NCiZndDsgJmd0
OyAmZ3Q7IGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OywgJnF1b3Q7b2F1dGgmcXVvdDsg
Jmx0O29hdXRoQGlldGYub3JnJmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyDW
98ziIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFJlOiBbT0FVVEgt
V0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZQ0KdG8gYmUgJm5i
c3A7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRo
aXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IEhpIE5hdCwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IFRoZSBjdXJyZW50IHRleHQgZXNzZW50aWFsbHkgc2F5cyB0aGF0IHRo
ZSBhc3NlcnRpb24gY2FuDQplaXRoZXIgYmUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY3JlYXRlZCBi
eSB0aGUgY2xpZW50IChpbiB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2lnbmVkKQ0Kb3IgaXQgY2Fu
IGJlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY3JlYXRlZCBieSBzb21lIG90aGVyIGVudGl0eSAod2hp
Y2ggaXMgdGhlbiBjYWxsZWQgdGhlIHRoaXJkDQpwYXJ0eSA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0
b2tlbiBzZXJ2aWNlKS4gU28sIHRoaXMgdGhpcmQgcGFydHkgY291bGQgYmUgdGhlIGF1dGhvcml6
YXRpb24NCnNlcnZlci4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0
OyAmZ3Q7IENpYW88YnI+DQomZ3Q7ICZndDsgJmd0OyBIYW5uZXMgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZ10NCk9uIEJlaGFsZiBPZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBleHQgTmF0IFNha2ltdXJh
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAxMiAxMDoz
NSBBTTxicj4NCiZndDsgJmd0OyAmZ3Q7IFRvOiBCcmlhbiBDYW1wYmVsbDsgb2F1dGg8YnI+DQom
Z3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBX
aHkgZG9lcyBpc3N1ZXINCmhhdmUgdG8gYmU8YnI+DQomZ3Q7ICZndDsgJmd0OyBlaXRoZXIgdGhl
IGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/IDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBIaSBCcmlhbiwgPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyBUaGUgYXNzZXJ0aW9uIGZyYW1ld29yayBkZWZpbmVzIHRoZSBJc3N1ZXIgYXM6IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7
SXNzdWVyICZuYnNwO1RoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlDQplbnRpdHkgdGhhdCBp
c3N1ZWQgdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFzc2Vy
dGlvbi4gJm5ic3A7R2VuZXJhbGx5IHRoaXMgaXMNCnRoZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUg
a2V5IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG1hdGVyaWFsIHVz
ZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4NCiZuYnNwO1RoZSBpc3N1ZXIgbWF5IGJlIGVp
dGhlciA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhbiBPQXV0aCBj
bGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUNCnNlbGYtaXNzdWVkKSBvciBhIHRoaXJkIHBhcnR5
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRva2VuIHNlcnZpY2Uu
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHdhcyB3
b25kZXJpbmcgd2h5IGl0IGhhcyB0byBiZSBlaXRoZXIgdGhlIGNsaWVudCBvciBhDQp0aGlyZCBw
YXJ0eSA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0b2tlbiBzZXJ2aWNlLiA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyBDb25jZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBzZXJ2aWNlIChmdW5jdGlv
bmFsaXR5KQ0KPGJyPg0KJmd0OyAmZ3Q7IHJlc2lkaW5naW4gYW55IG9mIDxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGUgc3Rha2Vob2xkZXJzIChSZXNv
dXJjZSBPd25lciwgT0F1dGggQ2xpZW50LCBBdXRob3JpemF0aW9uDQpTZXJ2ZXIsIG9yIDxicj4N
CiZndDsgJmd0OyAmZ3Q7IGEgdGhpcmQgcGFydHkpLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJz
cDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEkgd291
bGQgYXBwcmVjaWF0ZSBpZiB5b3UgY291bGQgY2xhcmlmeSB3aHkgaXMgdGhlIGNhc2UuDQo8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IEJlc3QsIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQom
Z3Q7ICZndDsgJmd0OyAtLSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBOYXQgU2FraW11cmEgKD1uYXQp
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZn
dDsgJmd0OyAmZ3Q7IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzxicj4NCiZndDsgJmd0OyAmZ3Q7
IEBfbmF0X2VuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwO19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZn
dDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0K
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm
Z3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsg
Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBPQXV0aEBpZXRmLm9y
Zzxicj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGg8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0
OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGggPC9mb250PjwvdHQ+DQo=
--=_alternative 000EC76948257ACA_=--

From sakimura@gmail.com  Mon Dec  3 20:20:43 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F06A1F0C61; Mon,  3 Dec 2012 20:20:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.069
X-Spam-Level: 
X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fNnP+dM5bbM; Mon,  3 Dec 2012 20:20:41 -0800 (PST)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 91C8B21F8585; Mon,  3 Dec 2012 20:20:40 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id a1so1581720eaa.31 for ; Mon, 03 Dec 2012 20:20:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vd4PzIDRrOIcrd/aZZ32XQ4BfQdzvqayx5TNSQN7jBg=; b=taXREBHr/cdPcRDNsyGYkEDstUMyLsrcUkvPEEpPOM+vMjP1T4Xbtn0y9LundWBpAr c15WVYGrkui6dGDgFcEIjKVHix3eBwgANCJNzE8HVtypOkXurCjwLuXCaDlMVtRZvr56 jsNr+WHorX7HRV+kyP+nOQKZb+OlGlTtBwrfBleU6l/6EsrhFXAgcSK/RnU2nIppC++H ymw5v5TrWBXV4OzE+xFd/8GnovQhqAgB1YxUTa6yh1LPaA8R//tQFe5cQYD2/U7ny1Rb 67mM1+SXwpYt/pyNZFXVYNjqcCduBPMcTdFdpO6Gjm9OOw2+hX27Lv9PJ7d5av7pujYO VFpg==
MIME-Version: 1.0
Received: by 10.14.178.196 with SMTP id f44mr44155771eem.14.1354594839724; Mon, 03 Dec 2012 20:20:39 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Mon, 3 Dec 2012 20:20:39 -0800 (PST)
In-Reply-To: 
References: <7EBB51A5-A7FC-416E-BF29-D790DFAD9677@salesforce.com> 
Date: Tue, 4 Dec 2012 13:20:39 +0900
Message-ID: 
From: Nat Sakimura 
To: zhou.sujing@zte.com.cn
Content-Type: multipart/alternative; boundary=047d7b6225203c824a04cfff3010
Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 04:20:43 -0000

--047d7b6225203c824a04cfff3010
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Actually, "The issuer may be either
      an OAuth client (when assertions are self-issued) or any other
entity, e.g.,  a third party
token service, resource owner. "  is not really clean.

OAuth client is just another example of an issuer.

So, perhaps the sentence could be:

"Example of issuers include an OAuth client, resource owner, an independent
third party."

So, the clause becomes:

 Issuer  The unique identifier for the entity that issued the
      assertion.  Generally this is the entity that holds the key
      material used to generate the assertion.
      Example of issuers include an OAuth client, resource owner, an
independent third party.

Nat

Nat

On Tue, Dec 4, 2012 at 11:40 AM,  wrote:

>
>
>
> Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 10:26=
:50:
>
>
> > Please feel free to suggest better language.
>
> >
> > Issuer simply allows the token service to know who created the
> > assertion, so it can look them up and see if they're trusted.
> > Effectively the same as an Issuer in SAML.
>
> a conflict : "The token service is the assertion issuer" in assertion
> document.
> while you said "token service know who created the assertion"
>
> I wonder if the following text is acceptable:
>
>   Issuer  The unique identifier for the entity that issued the
>       assertion.  Generally this is the entity that holds the key
>       material used to generate the assertion.  The issuer may be either
>       an OAuth client (when assertions are self-issued) or any other
> entity, e.g.,  a third party
> token service, resource owner.
>
>
> 6.3.  Client Acting on Behalf of a User
>
> The Issuer of the assertion MUST identify the entity that issued
>       the assertion as recognized by the Authorization Server.  If the
>       assertion is self-issued, the Issuer SHOULD be the "client_id".
>       If the assertion was issued by a Security Token Service (STS), the
>       Issuer SHOULD identify the STS as recognized by the Authorization
>       Server.If the assertion was issued by the resource owner, the
>       Issuer SHOULD identify the resource owner as recognized by the
> Authorization
>       Server.
>
> >
> > -cmort
> >
> > On Dec 3, 2012, at 6:23 PM,  wrote:
> >
> >
> > Obviously, it is not so clear from the language there.
> >
> >
> > Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 10:=
17:12:
> >
> > > There's no reason why it can't be resource owner today.
> > >
> > > On Dec 3, 2012, at 6:06 PM,  <
> zhou.sujing@zte.com.cn
> > > > wrote:
> > >
> > >
> > > +1.
> > > And why it was not looked at that time?
> > >
> > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:
> > >
> > > > Actually, I think it is a good time to start looking at the resours=
e
> > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had brough=
t
> > > > this up a couple of years ago.)
> > > >
> > > > Igor
> > > >
> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:
> > > > I suppose, yes. I was reading it like that all the time.
> > > > Whether it is or not, if it is still ok, it might be better to
> > clarify it.
> > > > Word like "third party" tends to be a bit of problem without
> > > clearlydefining.
> > > > I had similar experience in other fora.
> > > >
> > > > Nat
> > > >
> > > > Sent from iPad
> > > >
> > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn"  =A4=CE
> > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:
> > >
> > > >
> > > > could be Resource owner?
> > > >
> > >
> > > >
> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" 
> > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org
> > > > 2012-12-03 16:49
> > > >
> > > > =CA=D5=BC=FE=C8=CB
> > > >
> > > > "ext Nat Sakimura" , "Brian Campbell" <
> > > > bcampbell@pingidentity.com>, "oauth" 
> > > >
> > > > =B3=AD=CB=CD
> > > >
> > > > =D6=F7=CC=E2
> > > >
> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
> > > > either the client or a third party token service?
> > > >
> > > >
> > > >
> > > >
> > > > Hi Nat,
> > > >
> > > > The current text essentially says that the assertion can either be
> > > > created by the client (in which case it is self-signed) or it can b=
e
> > > > created by some other entity (which is then called the third party
> > > > token service). So, this third party could be the authorization
> server.
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > >
> > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf Of
> > > > ext Nat Sakimura
> > > > Sent: Monday, December 03, 2012 10:35 AM
> > > > To: Brian Campbell; oauth
> > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to b=
e
> > > > either the client or a third party token service?
> > > >
> > > > Hi Brian,
> > > >
> > > >
> > > > The assertion framework defines the Issuer as:
> > > >
> > > >    Issuer  The unique identifier for the entity that issued the
> > > >       assertion.  Generally this is the entity that holds the key
> > > >       material used to generate the assertion.  The issuer may be
> either
> > > >       an OAuth client (when assertions are self-issued) or a third
> party
> > > >       token service.
> > > >
> > > > I was wondering why it has to be either the client or a third party
> > > > token service.
> > > > Conceptually, it could be any token service (functionality)
> > > residingin any of
> > > >
> > > > the stakeholders (Resource Owner, OAuth Client, Authorization
> Server, or
> > > > a third party).
> > > >
> > > >
> > > > I would appreciate if you could clarify why is the case.
> > > >
> > > >
> > > > Best,
> > > >
> > > > --
> > > > Nat Sakimura (=3Dnat)
> > > > Chairman, OpenID Foundation
> > > > http://nat.sakimura.org/
> > > > @_nat_en
> > > >  _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > >
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b6225203c824a04cfff3010
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Actually, "The issuer may be either =
;

      an OAuth client (whe=
n assertions are self-issued) or=
 any other entity, e.g.,  a third par=
ty 

toke=
n service, resource owner. "  is not really clea=
n. 


=

OAuth client is just another example of an issuer.&nbs=
p;



So, perhaps the sentence could be: 



"Example of issuers include an OAuth client,=
 resource owner, an independent third party."



So, the clause becomes: 



 Issuer  The unique identifier for the entity that=
 issued the 

      assertion. &=
nbsp;Generally this is the entity that holds the key 
      material used to g=
enerate the assertion.  

      Example of i=
ssuers include an OAuth client, resource owner, an independent third party.=
 

Nat



Nat

On Tue, Dec 4, 2012 at 11:40 AM,  <zhou.sujing@zte.com.cn><=
/span> wrote:








Chuck Mortimore <cmortimore@salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:26:50:




> Please feel free to suggest better language.


> 

> Issuer simply allows the token service to know who created the 

> assertion, so it can look them up and see if they're trusted. &nbs=
p;
  

> Effectively the same as an Issuer in SAML.



a conflict : "The
token service is the assertion issuer"
in assertion document.

while you said "token service know who created
the assertion"



I wonder if the following text is acceptable:

 

  Issuer  The uniqu=
e
identifier for the entity that issued the

      assertio=
n.
 Generally this is the entity that holds the key

      material=
 used
to generate the assertion.  The issuer may be either

      an=
 OAuth client
(when assertions are self-issued) or
any other entity, e.g.,  a
third party 

token service, r=
esource
owner.





6.3.  Client Acting on Behalf of a User



The Issuer of the assertion MUST identify the entity
that issued

      the assertion as recognized by
the Authorization Server.  If the

      assertion is self-issued, the
Issuer SHOULD be the "client_id".

      If the assertion was issued by
a Security Token Service (STS), the

      Issuer SHOULD identify the STS
as recognized by the Authorization

      Server.If
the assertion was issued by the resource owner, the

      Issuer SHOULD identify
the resource owner as recognized by the Authorization

      Server.



> 

> -cmort

> 

> On Dec 3, 2012, at 6:23 PM, <zhou.sujing@zte.com.cn> wrote:

> 

> 

> Obviously, it is not so clear from the language there. 

> 

> 

> Chuck Mortimore <cmortimore@salesforce.com> =D0=B4=D3=DA 2012-12-04
10:17:12:

> 

> > There's no reason why it can't be resource owner today. &=
nbsp;


> > 

> > On Dec 3, 2012, at 6:06 PM, <zhou.sujing@zte.com.cn> <zhou.sujing@zte.com.cn
> > > wrote: 

> > 

> > 

> > +1. 

> > And why it was not looked at that time? 

> > 

> > oauth=
-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:

> > 

> > > Actually, I think it is a good time to start looking at
the resourse

> > > owner issuing assertions@ (Interestingly enough, Hui-Lan
had brought

> > > this up a couple of years ago.)

> > > 

> > > Igor

> > > 

> > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: 

> > > I suppose, yes. I was reading it like that all the time.


> > > Whether it is or not, if it is still ok, it might be better
to 

> clarify it. 

> > > Word like "third party" tends to be a bit of probl=
em
without 

> > clearlydefining. 

> > > I had similar experience in other fora. 

> > > 

> > > Nat 

> > > 

> > > Sent from iPad 

> > > 

> > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn=
>
=A4=CE

> > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:

> > 

> > > 

> > > could be Resource owner? 

> > > 

> > 

> > > 

> > > "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@n=
sn.com>


> > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org 

> > > 2012-12-03 16:49 

> > > 

> > > =CA=D5=BC=FE=C8=CB 

> > > 

> > > "ext Nat Sakimura" <sakimura@gmail.com>,
"Brian Campbell" <

> > > bcampbell@pingidentity.com>, "oauth" <oauth@ietf.org>


> > > 

> > > =B3=AD=CB=CD 

> > > 

> > > =D6=F7=CC=E2 

> > > 

> > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have
to be     

> > > either the client or a third party token service? 

> > > 

> > > 

> > > 

> > > 

> > > Hi Nat, 

> > >   

> > > The current text essentially says that the assertion can
either be 

> > > created by the client (in which case it is self-signed)
or it can be

> > > created by some other entity (which is then called the third
party 

> > > token service). So, this third party could be the authorizat=
ion
server. 

> > >   

> > > Ciao

> > > Hannes 

> > >   

> > >   

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

> > > ext Nat Sakimura

> > > Sent: Monday, December 03, 2012 10:35 AM

> > > To: Brian Campbell; oauth

> > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer
have to be

> > > either the client or a third party token service? 

> > >   

> > > Hi Brian, 

> > >   

> > >   

> > > The assertion framework defines the Issuer as: 

> > >   

> > >    Issuer  The unique identifier for the
entity that issued the 

> > >       assertion.  Generally this is
the entity that holds the key 

> > >       material used to generate the assertion=
.
 The issuer may be either 

> > >       an OAuth client (when assertions are
self-issued) or a third party 

> > >       token service. 

> > >   

> > > I was wondering why it has to be either the client or a
third party 

> > > token service. 

> > > Conceptually, it could be any token service (functionality)


> > residingin any of 

> > >   

> > > the stakeholders (Resource Owner, OAuth Client, Authorizatio=
n
Server, or 

> > > a third party). 

> > >   

> > >   

> > > I would appreciate if you could clarify why is the case.


> > >   

> > >   

> > > Best, 

> > >   

> > > -- 

> > > Nat Sakimura (=3Dnat) 

> > > Chairman, OpenID Foundation

> > > http:=
//nat.sakimura.org/

> > > @_nat_en 

> > >  _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> > 

> > > 

> > > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.or=
g

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


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=






--047d7b6225203c824a04cfff3010--

From zhou.sujing@zte.com.cn  Mon Dec  3 21:53:20 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB74A21F8994 for ; Mon,  3 Dec 2012 21:53:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.595
X-Spam-Level: 
X-Spam-Status: No, score=-97.595 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_48=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xelPTCj82Avp for ; Mon,  3 Dec 2012 21:53:19 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A192921F8993 for ; Mon,  3 Dec 2012 21:52:48 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id E845A83DC8 for ; Tue,  4 Dec 2012 13:52:39 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 8607571D15F; Tue,  4 Dec 2012 13:50:52 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB45qXaQ060124; Tue, 4 Dec 2012 13:52:33 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <99EAA8F4-D10A-4657-91A5-0A6BD311DD95@ve7jtb.com>
To: John Bradley 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Tue, 4 Dec 2012 13:52:30 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-04 13:52:32, Serialize complete at 2012-12-04 13:52:32
Content-Type: multipart/alternative; boundary="=_alternative 002063A448257ACA_="
X-MAIL: mse01.zte.com.cn qB45qXaQ060124
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 05:53:20 -0000

This is a multipart message in MIME format.
--=_alternative 002063A448257ACA_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SG93IGFib3V0IHRoZSBmb2xsb3dpbmcgdXNlIGNhc2VzOiANCjEuIERpcmVjdCBEZWxlZ2F0aW9u
IA0KDQogICBEZXNjcmlwdGlvbjoNCg0KICAgQ29tcGFueSBHb29kUGF5IHByZXBhcmVzIHRoZSBl
bXBsb3llZSBwYXlyb2xscyBmb3IgdGhlIGNvbXBhbnkNCiAgIEdvb2RXb3JrLiAgSW4gb3JkZXIg
dG8gZG8gdGhhdCB0aGUgYXBwbGljYXRpb24gYXQgd3d3Lkdvb2RQYXkuZXhhbXBsZQ0KICAgZ2V0
cyBhdXRoZW50aWNhdGVkIGFjY2VzcyB0byB0aGUgZW1wbG95ZWVzJyBhdHRlbmRhbmNlIGRhdGEg
c3RvcmVkIGF0DQogICB3d3cuR29vZFdvcmsuZXhhbXBsZS4NCg0KICAgUHJlLWNvbmRpdGlvbnM6
DQoNCiAgIG8gIFRoZSBhcHBsaWNhdGlvbiBhdCB3d3cuR29vZFBheS5leGFtcGxlIGhhcyBvYnRh
aW5lZCBhbg0KICAgICAgYXV0aGVudGljYXRpb24gZGVsZWdhdGlvbiBmcm9tIGEgcGFydHkgdGhh
dCBpcyB0cnVzdGVkIGJ5IHRoZQ0KICAgICAgYXBwbGljYXRpb24gYXQgd3d3Lkdvb2RXb3JrLmV4
YW1wbGUNCg0KICAgbyAgVGhlIHNjb3BlIG9mIHRoZSBhY2Nlc3MgYnkgdGhlIGFwcGxpY2F0aW9u
IGF0IHd3dy5Hb29kUGF5LmV4YW1wbGUNCiAgICAgIHRvIHRoZSBkYXRhIHN0b3JlZCBhdCB3d3cu
R29vZFdvcmsuZXhhbXBsZSBoYXMgYmVlbiBkZWZpbmVkDQoNCiAgIG8gIFRoZSBhcHBsaWNhdGlv
biBhdCB3d3cuR29vZFBheS5leGFtcGxlIGlzIG5vdCBjYXBhYmxlIG9mIHZhbGlkYXRpbmcNCiAg
ICAgIGl0cyBkZWxlZ2F0aW9uLg0KDQogICBQb3N0LWNvbmRpdGlvbnM6DQoNCiAgIEEgc3VjY2Vz
c2Z1bCBwcm9jZWR1cmUgcmVzdWx0cyBpbiB0aGUgYXBwbGljYXRpb24gYXQNCiAgIHd3dy5Hb29k
UGF5LmV4YW1wbGUgcmVjZWl2aW5nIGFuIGFjY2VzcyB0b2tlbiBhZnRlciBhdXRoZW50aWNhdGlu
ZyB0bw0KICAgdGhlIGF1dGhvcml6YXRpb24gb3IgdGhlIGFwcGxpY2F0aW9uIHJ1bm5pbmcgYXQg
d3d3Lkdvb2RXb3JrLmV4YW1wbGUgYnkgDQpwcmVzZW50aW5nIGFuDQpkZWxlZ2F0aW9uLiANCg0K
ICAgUmVxdWlyZW1lbnRzOg0KDQogICBvICBBdXRoZW50aWNhdGlvbiBvZiB0aGUgYXBwbGljYXRp
b24gYXQgd3d3Lkdvb2RQYXkuZXhhbXBsZSB0byB0aGUNCiAgICAgIGF1dGhvcml6YXRpb24gc2Vy
dmVyIG9yIHRoZSBhcHBsaWNhdGlvbiBhdCB3d3cuR29vZFdvcmsuZXhhbXBsZSBpcyANCnJlcXVp
cmVkDQoNCiAgIG8gIFRoZSBhdXRob3JpemF0aW9uIG9yIHRoZSBhcHBsaWNhdGlvbiBydW5uaW5n
IGF0IHd3dy5Hb29kV29yay5leGFtcGxlIA0KbXVzdCBiZSBjYXBhYmxlIG9mDQogICAgICB2YWxp
ZGF0aW5nIGRlbGVnYXRpb24gIHByZXNlbnRlZCBieSB0aGUgYXBwbGljYXRpb24gcnVubmluZyBh
dA0KICAgICAgd3d3Lkdvb2RQYXkuZXhhbXBsZQ0KDQoNCiANCg0KMi4gUHJveHkgZGVsZWdhdGlv
biANCg0KICAgRGVzY3JpcHRpb246DQoNCiAgIEFsaWNlIGhhcyBoZXIgZmluYW5jaWFsIGRhdGEg
c3RvcmVkIGF0IGEgZmluYW5jaWFsIGNvbXBhbnkgDQp3d3cuZmluYW5jaWFsLmNvbSwgaGVyIGxh
d3llciBuZWVkcyB0byANCiAgIG9idGFpbiBhdXRoZW50aWNhdGVkIGFjY2VzcyB0byBzb21lIG9m
IGhlciBmaW5hbmNpYWwgZGF0YSB0byBydW4gDQphcHBsaWNhdGlvbnMgYXQgd3d3Lmxhd3llci5l
eGFtcGxlLiANCiAgIEFsaWNlIGFuZCB0aGUgbGF3eWVyIGhhdmUgcmF0aGVyIGxvbmcgdGVybSB0
cnVzdCByZWxhdGlvbnNoaXAsIGJ1dCANCnN0aWxsIEFsaWNlIGlzIG5vdCB3aWxsaW5nIHRvIGxl
YWsgaGVyIHNlY3JldCBjcmVkZW50aWFsIHRvIHRoZSANCg0KIGxhd3llci4gVGhlIGFwcGxpY2F0
aW9ucyBhdCB3d3cubGF3eWVyLmV4YW1wbGUgbWF5IGNoYW5nZSBvdmVyIHRoZSB0aW1lLCANCkFs
aWNlIGlzIG5vdCB3aWxsaW5nIHRvIGJlIGJvdGhlcmVkIGJ5IGdlbmVyYXRpbmcgYXNzZXJ0aW9u
IA0KIGVhY2ggdGltZSBhIG5ldyBhcHBsaWNhdGlvbiBjb21lcyBvdXQuIA0KDQogICBQcmUtY29u
ZGl0aW9uczoNCiANCiAgICAgbyBBbGljZSBoYXMgYSBzZWNyZXQgcHJpdmF0ZSBrZXkgYW5kIGNv
cnJlc3BvbmRpbmcgcHVibGljIGtleSANCiAgICAgbyBBbGljZSBjb3VsZCBnZW5lcmF0ZSBhIHBy
b3h5IHByaXZhdGUga2V5IGZvciBoZXIgbGF3eWVyIA0KICAgICBvIExhd3llciBjb3VsZCBnZW5l
cmF0ZSBwcm94eSBzaWduYXR1cmUgYmFzZWQgb24gaGlzIHByb3h5IHByaXZhdGUgDQprZXkgZm9y
IGFueSBhcHBsaWNhdGlvbiBhdCB3d3cubGF3eWVyLmV4YW1wbGV0aGF0IGlzIGluIHRoZSANCg0K
c2NvcGUgKHRoZSBzY29wZSBjb3VsZCBiZSBhcyBicm9hZCBhcyBhbnkgYXBwbGljYXRpb24gYXQg
dGhlIHdlYnNpdGUgDQp3d3cubGF3eWVyLmV4YW1wbGUpIG9mIHRoZSBwcm94eSBwcml2YXRlIGtl
eS4gDQoNCiAgIFBvc3QtY29uZGl0aW9uczoNCg0KICAgQSBzdWNjZXNzZnVsIHByb2NlZHVyZSBy
ZXN1bHRzIGluIHRoZSBhcHBsaWNhdGlvbiBhdA0KICAgd3d3Lmxhd3llci5leGFtcGxlcmVjZWl2
aW5nIGFuIGFjY2VzcyB0b2tlbiBhZnRlciBwcmVzZW50aW5nIGEgcHJveHkgDQpzaWduYXR1cmUg
dG8gDQogICB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIgc3BlY2lmaWVkIGJ5IEFsaWNlLg0KDQog
ICBSZXF1aXJlbWVudHM6DQoNCiAgIG8gIEF1dGhlbnRpY2F0aW9uIG9mIHRoZSBhcHBsaWNhdGlv
biBhdCB3d3cubGF3eWVyLmV4YW1wbGV0byB0aGUNCiAgICAgIGFwcGxpY2F0aW9uIGF0IHd3dy5m
aW5hbmNpYWwuZXhhbXBsZSBpcyByZXF1aXJlZA0KDQogICBvICBUaGUgYXV0aG9yaXphdGlvbiBz
ZXJ2ZXIgbXVzdCBiZSBjYXBhYmxlIG9mDQogICAgICB2YWxpZGF0aW5nIHByb3h5IHNpZ25hdHVy
ZSBwcmVzZW50ZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHJ1bm5pbmcgYXQNCiAgICAgIHd3dy5sYXd5
ZXIuZXhhbXBsZQ0KDQoNCg0KDQpKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPiDQtNPa
IDIwMTItMTItMDMgMjE6MTc6Mzg6DQoNCj4gVGhhdCBtYXkgcmVsYXRlIG1vcmUgdG8gdGhlIHBy
b29mIG9mIHBvc3Nlc3Npb24gZGlzY3Vzc2lvbi4NCj4gDQo+IFlvdSBtYXkgd2FudCB0byBzdWJt
aXQgdGhhdCBhcyBhIHVzZSBjYXNlLg0KPiANCj4gSm9obiBCLg0KPiBPbiAyMDEyLTEyLTAzLCBh
dCA2OjAxIEFNLCB6aG91LnN1amluZ0B6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gDQo+IA0KPiBB
bmQgYW5vdGhlciBkaWZmZXJlbmNlIGlzIG15IHVzZSBjYXNlIGNvdWxkIGJlIHRoYXQgImFzc2Vy
dGlvbiIgYmUgDQo+IGdlbmVyYXRlZCBzZXF1ZW50aWFsbHkgYnkgcmVzb3VyY2Ugb3duZXIgYW5k
IGNsaWVudC4gDQo+IEZvciBleGFtcGxlLCByZXNvdXJjZSBvd25lciBkZWxlZ2F0ZXMgYSBjbGll
bnQgdG8gZ2VuZXJhdGUgc2lnbmF0dXJlDQo+IG9uIGJlaGFsZiBvZiBpdCwgY2xpZW50IGdlbmVy
YXRlcyBhIHNpZ25hdHVyZSB1c2luZyB0aGUgcHJpdmF0ZSBrZXkgb2YgDQppdHNlbGYsDQo+IHdo
aWNoIGlzIGNhbGxlZCBwcm94eSBzaWduYXR1cmUgaW4gY3J5cHRvZ3JhcGh5LiANCj4gDQo+IA0K
PiANCj4gPiBNeSB1c2UgY2FzZSBpcyBpbmRlZWQgc2ltaWxhciB0byAgYXNzZXJ0aW9uIGZsb3cg
InNlY3Rpb24gNi4zLiANCj4gPiBDbGllbnQgQWN0aW5nIG9uIEJlaGFsZiBvZiBhIFVzZXIiLiAN
Cj4gPiBEaWZmZXJlbmNlcyBhcmU6IA0KPiA+IDEuICBpZiBteSB1c2UgY2FzZSBpcyBjYXJyaWVk
IG91dCBpbiBhc3NlcnRpb24gZnJhbWV3b3JrLCAicHJpY2lwYWwiDQo+ID4gc2hvdWxkIGJlIGNs
aWVudCwgd2hpbGUgYXNzZXJ0aW9uIGRvY3VtZW50IGRvZXMgbm90IA0KPiA+IGluY2x1ZGUgY2xp
ZW50IGFzIGFuIG9wdGlvbiB3aGVuIGNsaWVudCBpcyBhY3Rpbmcgb24gYmVoYWxmIG9mIGEgDQo+
ID4gdXNlcihyZXNvdXJjZSBvd25lciksIGl0IHNheXMgICIgYW4gYXV0aG9yaXplZCBhY2Nlc3Nv
ciBmb3Igd2hpY2ggdGhlICANCg0KPiA+IGFjY2VzcyB0b2tlbiBpcyBiZWluZyByZXF1ZXN0ZWQg
KHR5cGljYWxseSB0aGUgcmVzb3VyY2Ugb3duZXIsIG9yIA0KPiA+IGFuIGF1dGhvcml6ZWQgZGVs
ZWdhdGUpLiIgDQo+ID4gMi4gIGlmIG15IHVzZSBjYXNlIGlzIGNhcnJpZWQgb3V0IGluIGFzc2Vy
dGlvbiBmcmFtZXdvcmssICJpc3N1ZXIiIA0KPiA+IHNob3VsZCBiZSByZXNvdXJjZSBvd25lciwg
d2hpbGUgYXNzZXJ0aW9uIGRvY3VtZW50IG9ubHkgaW5jbHVkZXMgDQo+ID4gY2xpZW50IGFuZCB0
b2tlbiBzZXJ2aWNlIA0KPiA+IA0KPiA+IEluIG15IHVzZSBjYXNlIHRoZSAiYXNzZXJ0aW9uIiBp
cyBtb3JlIGxpa2UgYSBwcml2YXRlIG91dHB1dCwgd2hpbGUgDQo+ID4gaW4gYXNzZXJ0aW9uIGZs
b3cgImFzc2VydGlvbiAiIGlzIGdlbmVyYXRlZCBieSBhIHRocmlkIHBhcnR5IHRva2VuIA0KPiA+
IHNlcnZpY2Ugb3IgYnkgY2xpZW50IGl0c2VsZi4gDQo+ID4gDQo+ID4gTmF0IFNha2ltdXJhIDxz
YWtpbXVyYUBnbWFpbC5jb20+IA0KPiA+IDIwMTItMTItMDMgMTQ6NDQgDQo+ID4gDQo+ID4gytW8
/sjLIA0KPiA+IA0KPiA+IHpob3Uuc3VqaW5nQHp0ZS5jb20uY24gDQo+ID4gDQo+ID4gs63LzSAN
Cj4gPiANCj4gPiAib2F1dGhAaWV0Zi5vcmcgV0ciIDxvYXV0aEBpZXRmLm9yZz4gDQo+ID4gDQo+
ID4g1vfM4iANCj4gPiANCj4gPiBSZTogUmU6IFtPQVVUSC1XR10gSGksYW55IGNvbW1lbnQgb24g
ZHJhZnQtemhvdS1vYXV0aC1vd25lci1hdXRoPyANCj4gPiANCj4gPiBZb3VyIHVzZWNhc2Ugc291
bmRzIGEgbGl0dGxlIGJpdCBsaWtlIHRoZSBhc3NlcnRpb24gZmxvdy4gDQo+ID4gVGhlIFJPIGlz
c3VlcyBhbiBhc3NlcnRpb24gYW5kIHRoZSByZXN0IGdvZXMuIA0KPiA+IElzIHRoZXJlIHJlYXNv
bnMgdGhhdCBhbiBhc3NlcnRpb24gZmxvdyBjYW5ub3QgZG8/IA0KPiA+IA0KPiA+IE5hdA0KPiAN
Cj4gPiBPbiBNb24sIERlYyAzLCAyMDEyIGF0IDM6MzUgUE0sIDx6aG91LnN1amluZ0B6dGUuY29t
LmNuPiB3cm90ZTogDQo+ID4gbXkgdXNlIGNhc2UoUk8taW5pdGlhdGVkIGRlbGVnYXRpb24pOiAN
Cj4gPiAtSSBkZXBvc2l0IG15IGNoaWxkKHByZWNpb3VzIHJlc291cmNlKSBhdCBraW5kZXJnYXJk
ZW4oUmVzb3VyY2UgDQpTZXJ2ZXIpIA0KPiA+IC1JIGRlbGVnYXRlIGEgZmV3IHBlcnNvbnMsZS5n
LiwgZ3JhbmRwYXJlbnRzIG9mIG15IGNoaWxkLCB0byBwaWNrIHVwDQo+ID4gbXkgY2hpbGQgYXQg
dGhlIGtpbmRlcmdhcmRlbiANCj4gPiAtd2hlbiBzb21lb25lIHRyaWVzIHRvIHRha2UgaGltIG91
dHNpZGUgb2YgdGhlIGtpbmRlcmdhcmRlbiwgIHRoZSANCj4gPiB0ZWFjaGVyIHdpbGwgYXNrIGhp
bS9oZXIgdG8gc2hvdyBteSBkZWxlZ2F0aW9uIA0KPiA+ICBzdGF0ZW1lbnQsIG5vIHN0YXRlbWVu
dCwgbm8gdGFraW5nIG15IGNoaWxkLiANCj4gPiANCj4gDQo+ID4gDQo+ID4gLS0gDQo+ID4gTmF0
IFNha2ltdXJhICg9bmF0KSANCj4gPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4gPiBo
dHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCj4gPiBAX25hdF9lbiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1
dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0K
--=_alternative 002063A448257ACA_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhvdyBhYm91dCB0aGUgZm9sbG93
aW5nIHVzZSBjYXNlczogPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij4xLiBEaXJlY3QgRGVsZWdhdGlvbiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtEZXNjcmlwdGlvbjo8L2ZvbnQ+DQo8YnI+DQo8
YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtDb21wYW55IEdv
b2RQYXkgcHJlcGFyZXMNCnRoZSBlbXBsb3llZSBwYXlyb2xscyBmb3IgdGhlIGNvbXBhbnk8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtHb29k
V29yay4gJm5ic3A7SW4gb3JkZXINCnRvIGRvIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5H
b29kUGF5LmV4YW1wbGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PiZuYnNwOyAmbmJzcDtnZXRzIGF1dGhlbnRpY2F0ZWQgYWNjZXNzDQp0byB0aGUgZW1wbG95ZWVz
JyBhdHRlbmRhbmNlIGRhdGEgc3RvcmVkIGF0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl
PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7d3d3Lkdvb2RXb3JrLmV4YW1wbGUuPC9mb250Pg0K
PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7UHJl
LWNvbmRpdGlvbnM6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj4mbmJzcDsgJm5ic3A7byAmbmJzcDtUaGUgYXBwbGljYXRpb24NCmF0IHd3dy5Hb29kUGF5
LmV4YW1wbGUgaGFzIG9idGFpbmVkIGFuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz
YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBhdXRoZW50aWNhdGlvbg0KZGVsZWdhdGlv
biBmcm9tIGEgcGFydHkgdGhhdCBpcyB0cnVzdGVkIGJ5IHRoZTwvZm9udD4NCjxicj48Zm9udCBz
aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYXBwbGljYXRpb24g
YXQNCnd3dy5Hb29kV29yay5leGFtcGxlPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm
YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7byAmbmJzcDtUaGUgc2NvcGUgb2YgdGhlDQph
Y2Nlc3MgYnkgdGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5Hb29kUGF5LmV4YW1wbGU8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRv
IHRoZSBkYXRhIHN0b3JlZA0KYXQgd3d3Lkdvb2RXb3JrLmV4YW1wbGUgaGFzIGJlZW4gZGVmaW5l
ZDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7
ICZuYnNwO28gJm5ic3A7VGhlIGFwcGxpY2F0aW9uDQphdCB3d3cuR29vZFBheS5leGFtcGxlIGlz
IG5vdCBjYXBhYmxlIG9mIHZhbGlkYXRpbmc8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGl0cyBkZWxlZ2F0aW9uLjwvZm9udD4N
Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1Bv
c3QtY29uZGl0aW9uczo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt
c2VyaWYiPiZuYnNwOyAmbmJzcDtBIHN1Y2Nlc3NmdWwgcHJvY2VkdXJlDQpyZXN1bHRzIGluIHRo
ZSBhcHBsaWNhdGlvbiBhdDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp
ZiI+Jm5ic3A7ICZuYnNwO3d3dy5Hb29kUGF5LmV4YW1wbGUgcmVjZWl2aW5nDQphbiBhY2Nlc3Mg
dG9rZW4gYWZ0ZXIgYXV0aGVudGljYXRpbmcgdG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDt0aGUgYXV0aG9yaXphdGlvbiBvciB0aGUNCmFw
cGxpY2F0aW9uIHJ1bm5pbmcgYXQgd3d3Lkdvb2RXb3JrLmV4YW1wbGUgYnkgcHJlc2VudGluZyBh
bjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ZGVsZWdhdGlvbi4g
PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsg
Jm5ic3A7UmVxdWlyZW1lbnRzOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7QXV0aGVudGljYXRpb24NCm9mIHRoZSBh
cHBsaWNhdGlvbiBhdCB3d3cuR29vZFBheS5leGFtcGxlIHRvIHRoZTwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgYXV0aG9yaXph
dGlvbiBzZXJ2ZXINCm9yIHRoZSBhcHBsaWNhdGlvbiBhdCB3d3cuR29vZFdvcmsuZXhhbXBsZSBp
cyByZXF1aXJlZDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp
ZiI+Jm5ic3A7ICZuYnNwO28gJm5ic3A7VGhlIGF1dGhvcml6YXRpb24NCm9yIHRoZSBhcHBsaWNh
dGlvbiBydW5uaW5nIGF0IHd3dy5Hb29kV29yay5leGFtcGxlIG11c3QgYmUgY2FwYWJsZSBvZjwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAm
bmJzcDsgdmFsaWRhdGluZyBkZWxlZ2F0aW9uDQombmJzcDtwcmVzZW50ZWQgYnkgdGhlIGFwcGxp
Y2F0aW9uIHJ1bm5pbmcgYXQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHd3dy5Hb29kUGF5LmV4YW1wbGU8L2ZvbnQ+DQo8YnI+
DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDs8
L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuIFByb3h5
IGRlbGVnYXRpb24gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj4mbmJzcDsgJm5ic3A7RGVzY3JpcHRpb246PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp
emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7QWxpY2UgaGFzIGhlciBmaW5hbmNp
YWwNCmRhdGEgc3RvcmVkIGF0IGEgZmluYW5jaWFsIGNvbXBhbnkgd3d3LmZpbmFuY2lhbC5jb20s
IGhlciBsYXd5ZXIgbmVlZHMNCnRvIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu
cy1zZXJpZiI+Jm5ic3A7ICZuYnNwO29idGFpbiBhdXRoZW50aWNhdGVkIGFjY2Vzcw0KdG8gc29t
ZSBvZiBoZXIgZmluYW5jaWFsIGRhdGEgdG8gcnVuIGFwcGxpY2F0aW9ucyBhdCB3d3cubGF3eWVy
LmV4YW1wbGUuDQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu
YnNwOyAmbmJzcDtBbGljZSBhbmQgdGhlIGxhd3llciBoYXZlDQpyYXRoZXIgbG9uZyB0ZXJtIHRy
dXN0IHJlbGF0aW9uc2hpcCwgYnV0IHN0aWxsIEFsaWNlIGlzIG5vdCB3aWxsaW5nIHRvDQpsZWFr
IGhlciBzZWNyZXQgY3JlZGVudGlhbCB0byB0aGUgJm5ic3A7IDwvZm9udD4NCjxicj4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7bGF3eWVyLiBUaGUgYXBwbGljYXRp
b25zIGF0IHd3dy5sYXd5ZXIuZXhhbXBsZQ0KbWF5IGNoYW5nZSBvdmVyIHRoZSB0aW1lLCBBbGlj
ZSBpcyBub3Qgd2lsbGluZyB0byBiZSBib3RoZXJlZCBieSBnZW5lcmF0aW5nDQphc3NlcnRpb24g
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDtlYWNoIHRp
bWUgYSBuZXcgYXBwbGljYXRpb24gY29tZXMNCm91dC4gJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+DQo8
YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtQcmUt
Y29uZGl0aW9uczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu
YnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO28gQWxpY2UgaGFzIGEgc2VjcmV0DQpwcml2YXRlIGtl
eSBhbmQgY29ycmVzcG9uZGluZyBwdWJsaWMga2V5IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtvIEFsaWNlIGNvdWxkIGdlbmVy
YXRlDQphIHByb3h5IHByaXZhdGUga2V5IGZvciBoZXIgbGF3eWVyIDwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtvIExhd3llciBj
b3VsZCBnZW5lcmF0ZQ0KcHJveHkgc2lnbmF0dXJlIGJhc2VkIG9uIGhpcyBwcm94eSBwcml2YXRl
IGtleSBmb3IgYW55IGFwcGxpY2F0aW9uIGF0IHd3dy5sYXd5ZXIuZXhhbXBsZXRoYXQNCmlzIGlu
IHRoZSA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnNj
b3BlICh0aGUgc2NvcGUgY291bGQgYmUgYXMgYnJvYWQgYXMNCmFueSBhcHBsaWNhdGlvbiBhdCB0
aGUgd2Vic2l0ZSB3d3cubGF3eWVyLmV4YW1wbGUpIG9mIHRoZSBwcm94eSBwcml2YXRlDQprZXku
IDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7
ICZuYnNwO1Bvc3QtY29uZGl0aW9uczo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtBIHN1Y2Nlc3NmdWwgcHJvY2VkdXJlDQpyZXN1
bHRzIGluIHRoZSBhcHBsaWNhdGlvbiBhdDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3d3dy5sYXd5ZXIuZXhhbXBsZXJlY2VpdmluZw0KYW4g
YWNjZXNzIHRva2VuIGFmdGVyIHByZXNlbnRpbmcgYSBwcm94eSBzaWduYXR1cmUgdG8gPC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7dGhlIGF1
dGhvcml6YXRpb24gc2VydmVyDQpzcGVjaWZpZWQgYnkgQWxpY2UuPC9mb250Pg0KPGJyPg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7UmVxdWlyZW1lbnRz
OjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7
ICZuYnNwO28gJm5ic3A7QXV0aGVudGljYXRpb24NCm9mIHRoZSBhcHBsaWNhdGlvbiBhdCB3d3cu
bGF3eWVyLmV4YW1wbGV0byB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt
c2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFwcGxpY2F0aW9uIGF0DQp3d3cuZmluYW5jaWFs
LmV4YW1wbGUgaXMgcmVxdWlyZWQ8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtvICZuYnNwO1RoZSBhdXRob3JpemF0aW9uDQpzZXJ2
ZXIgbXVzdCBiZSBjYXBhYmxlIG9mPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z
LXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB2YWxpZGF0aW5nIHByb3h5DQpzaWduYXR1cmUg
cHJlc2VudGVkIGJ5IHRoZSBhcHBsaWNhdGlvbiBydW5uaW5nIGF0PC9mb250Pg0KPGJyPjxmb250
IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB3d3cubGF3eWVy
LmV4YW1wbGU8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj5Kb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0OyDQtNPaIDIwMTItMTIt
MDMNCjIxOjE3OjM4Ojxicj4NCjxicj4NCiZndDsgVGhhdCBtYXkgcmVsYXRlIG1vcmUgdG8gdGhl
IHByb29mIG9mIHBvc3Nlc3Npb24gZGlzY3Vzc2lvbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBZb3UgbWF5IHdhbnQgdG8gc3VibWl0IHRoYXQgYXMg
YSB1c2UgY2FzZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K
Jmd0OyBKb2huIEIuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE9uIDIw
MTItMTItMDMsIGF0IDY6MDEgQU0sIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24NCndyb3RlOjwvZm9u
dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg
PGJyPg0KJmd0OyBBbmQgYW5vdGhlciBkaWZmZXJlbmNlIGlzIG15IHVzZSBjYXNlIGNvdWxkIGJl
IHRoYXQgJnF1b3Q7YXNzZXJ0aW9uJnF1b3Q7DQpiZSA8YnI+DQomZ3Q7IGdlbmVyYXRlZCBzZXF1
ZW50aWFsbHkgYnkgcmVzb3VyY2Ugb3duZXIgYW5kIGNsaWVudC4gPGJyPg0KJmd0OyBGb3IgZXhh
bXBsZSwgcmVzb3VyY2Ugb3duZXIgZGVsZWdhdGVzIGEgY2xpZW50IHRvIGdlbmVyYXRlIHNpZ25h
dHVyZTxicj4NCiZndDsgb24gYmVoYWxmIG9mIGl0LCBjbGllbnQgZ2VuZXJhdGVzIGEgc2lnbmF0
dXJlIHVzaW5nIHRoZSBwcml2YXRlIGtleQ0Kb2YgaXRzZWxmLDxicj4NCiZndDsgd2hpY2ggaXMg
Y2FsbGVkIHByb3h5IHNpZ25hdHVyZSBpbiBjcnlwdG9ncmFwaHkuIDxicj4NCiZndDsgPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBNeSB1c2UgY2FzZSBpcyBpbmRlZWQgc2lt
aWxhciB0byAmbmJzcDthc3NlcnRpb24gZmxvdyAmcXVvdDtzZWN0aW9uDQo2LjMuICZuYnNwOzxi
cj4NCiZndDsgJmd0OyBDbGllbnQgQWN0aW5nIG9uIEJlaGFsZiBvZiBhIFVzZXImcXVvdDsuIDxi
cj4NCiZndDsgJmd0OyBEaWZmZXJlbmNlcyBhcmU6IDxicj4NCiZndDsgJmd0OyAxLiAmbmJzcDtp
ZiBteSB1c2UgY2FzZSBpcyBjYXJyaWVkIG91dCBpbiBhc3NlcnRpb24gZnJhbWV3b3JrLA0KJnF1
b3Q7cHJpY2lwYWwmcXVvdDs8YnI+DQomZ3Q7ICZndDsgc2hvdWxkIGJlIGNsaWVudCwgd2hpbGUg
YXNzZXJ0aW9uIGRvY3VtZW50IGRvZXMgbm90IDxicj4NCiZndDsgJmd0OyBpbmNsdWRlIGNsaWVu
dCBhcyBhbiBvcHRpb24gd2hlbiBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZg0KYSA8YnI+
DQomZ3Q7ICZndDsgdXNlcihyZXNvdXJjZSBvd25lciksIGl0IHNheXMgJm5ic3A7JnF1b3Q7IGFu
IGF1dGhvcml6ZWQgYWNjZXNzb3INCmZvciB3aGljaCB0aGUgJm5ic3A7IDxicj4NCiZndDsgJmd0
OyBhY2Nlc3MgdG9rZW4gaXMgYmVpbmcgcmVxdWVzdGVkICh0eXBpY2FsbHkgdGhlIHJlc291cmNl
IG93bmVyLA0Kb3IgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IGFuIGF1dGhvcml6ZWQgZGVsZWdhdGUp
LiZxdW90OyA8YnI+DQomZ3Q7ICZndDsgMi4gJm5ic3A7aWYgbXkgdXNlIGNhc2UgaXMgY2Fycmll
ZCBvdXQgaW4gYXNzZXJ0aW9uIGZyYW1ld29yaywNCiZxdW90O2lzc3VlciZxdW90OyA8YnI+DQom
Z3Q7ICZndDsgc2hvdWxkIGJlIHJlc291cmNlIG93bmVyLCB3aGlsZSBhc3NlcnRpb24gZG9jdW1l
bnQgb25seSBpbmNsdWRlcw0KPGJyPg0KJmd0OyAmZ3Q7IGNsaWVudCBhbmQgdG9rZW4gc2Vydmlj
ZSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEluIG15IHVzZSBjYXNlIHRoZSAmcXVv
dDthc3NlcnRpb24mcXVvdDsgaXMgbW9yZSBsaWtlIGEgcHJpdmF0ZQ0Kb3V0cHV0LCB3aGlsZSA8
YnI+DQomZ3Q7ICZndDsgaW4gYXNzZXJ0aW9uIGZsb3cgJnF1b3Q7YXNzZXJ0aW9uICZxdW90OyBp
cyBnZW5lcmF0ZWQgYnkgYSB0aHJpZA0KcGFydHkgdG9rZW4gPGJyPg0KJmd0OyAmZ3Q7IHNlcnZp
Y2Ugb3IgYnkgY2xpZW50IGl0c2VsZi4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBO
YXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7IDIw
MTItMTItMDMgMTQ6NDQgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDK1bz+yMsgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyB6aG91LnN1amluZ0B6dGUuY29tLmNuIDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZxdW90O29hdXRoQGlldGYub3JnIFdHJnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDW98ziIDxicj4NCiZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgUmU6IFJlOiBbT0FVVEgtV0ddIEhpLGFueSBjb21tZW50IG9uIGRyYWZ0
LXpob3Utb2F1dGgtb3duZXItYXV0aD8NCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
WW91ciB1c2VjYXNlIHNvdW5kcyBhIGxpdHRsZSBiaXQgbGlrZSB0aGUgYXNzZXJ0aW9uIGZsb3cu
ICZuYnNwOzxicj4NCiZndDsgJmd0OyBUaGUgUk8gaXNzdWVzIGFuIGFzc2VydGlvbiBhbmQgdGhl
IHJlc3QgZ29lcy4gJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7IElzIHRoZXJlIHJlYXNvbnMgdGhhdCBh
biBhc3NlcnRpb24gZmxvdyBjYW5ub3QgZG8/ICZuYnNwOzxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgTmF0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gTW9uLCBEZWMgMywgMjAx
MiBhdCAzOjM1IFBNLCAmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDsNCndyb3RlOiA8YnI+
DQomZ3Q7ICZndDsgbXkgdXNlIGNhc2UoUk8taW5pdGlhdGVkIGRlbGVnYXRpb24pOiA8YnI+DQom
Z3Q7ICZndDsgLUkgZGVwb3NpdCBteSBjaGlsZChwcmVjaW91cyByZXNvdXJjZSkgYXQga2luZGVy
Z2FyZGVuKFJlc291cmNlDQpTZXJ2ZXIpIDxicj4NCiZndDsgJmd0OyAtSSBkZWxlZ2F0ZSBhIGZl
dyBwZXJzb25zLGUuZy4sIGdyYW5kcGFyZW50cyBvZiBteSBjaGlsZCwgdG8NCnBpY2sgdXA8YnI+
DQomZ3Q7ICZndDsgbXkgY2hpbGQgYXQgdGhlIGtpbmRlcmdhcmRlbiA8YnI+DQomZ3Q7ICZndDsg
LXdoZW4gc29tZW9uZSB0cmllcyB0byB0YWtlIGhpbSBvdXRzaWRlIG9mIHRoZSBraW5kZXJnYXJk
ZW4sDQombmJzcDt0aGUgPGJyPg0KJmd0OyAmZ3Q7IHRlYWNoZXIgd2lsbCBhc2sgaGltL2hlciB0
byBzaG93IG15IGRlbGVnYXRpb24gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO3N0YXRlbWVudCwgbm8g
c3RhdGVtZW50LCBubyB0YWtpbmcgbXkgY2hpbGQuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7IE5hdCBT
YWtpbXVyYSAoPW5hdCkgPGJyPg0KJmd0OyAmZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlv
bjxicj4NCiZndDsgJmd0OyBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+DQomZ3Q7ICZndDsg
QF9uYXRfZW4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+
DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2ZvbnQ+
PC90dD4NCg==
--=_alternative 002063A448257ACA_=--

From zhou.sujing@zte.com.cn  Mon Dec  3 21:59:18 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7812321F89AC for ; Mon,  3 Dec 2012 21:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.122
X-Spam-Level: 
X-Spam-Status: No, score=-97.122 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_48=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vNBG6ZSMwVU for ; Mon,  3 Dec 2012 21:59:17 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1007C21F89AB for ; Mon,  3 Dec 2012 21:59:15 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 34FD1125E975; Tue,  4 Dec 2012 14:00:55 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB45wxVM072483; Tue, 4 Dec 2012 13:58:59 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <99EAA8F4-D10A-4657-91A5-0A6BD311DD95@ve7jtb.com>
To: John Bradley 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Tue, 4 Dec 2012 13:58:55 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-04 13:58:57, Serialize complete at 2012-12-04 13:58:57
Content-Type: multipart/alternative; boundary="=_alternative 0020FA2748257ACA_="
X-MAIL: mse01.zte.com.cn qB45wxVM072483
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Hi,any comment on draft-zhou-oauth-owner-auth?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 05:59:18 -0000

This is a multipart message in MIME format.
--=_alternative 0020FA2748257ACA_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

TW9yZSBkaWZmZXJlbmNlczoNCg0KDQpBc3NlcnRpb25zIGFyZSBjbGFzc2lmaWVkIGludG8gdHdv
IHR5cGVzOg0KDQoNCiAgMS4gIEJlYXJlciBBc3NlcnRpb25zOiBBbnkgZW50aXR5IGluIHBvc3Nl
c3Npb24gb2YgYSBiZWFyZXIgYXNzZXJ0aW9uDQogICAgICAgKGUuZy4gdGhlIGJlYXJlcikgY2Fu
IHVzZSBpdCB0byBnZXQgYWNjZXNzIHRvIHRoZSBhc3NvY2lhdGVkDQogICAgICAgcmVzb3VyY2Vz
ICh3aXRob3V0IGRlbW9uc3RyYXRpbmcgcG9zc2Vzc2lvbiBvZiBhIGNyeXB0b2dyYXBoaWMNCiAg
ICAgICBrZXkpLiAgVG8gcHJldmVudCBtaXN1c2UsIGJlYXJlciBhc3NlcnRpb25zIG5lZWQgdG8g
YmUgcHJvdGVjdGVkDQogICAgICAgZnJvbSBkaXNjbG9zdXJlIGluIHN0b3JhZ2UgYW5kIGluIHRy
YW5zcG9ydC4gIEEgc2VjdXJlDQogICAgICAgY29tbXVuaWNhdGlvbiBjaGFubmVsIGlzIHJlcXVp
cmVkIGJldHdlZW4gYWxsIGVudGl0aWVzIHRvIGF2b2lkDQogICAgICAgbGVha2luZyB0aGUgYXNz
ZXJ0aW9uIHRvIHVuYXV0aG9yaXplZCBwYXJ0aWVzLg0KIA0KICAgICAgVGhlIGRlbGVnYXRpb24g
aW4gbXkgdXNlIGNhc2UgZG9lcyBub3QgYmVsb25nIHRvIGJlYXJlciBhc3NlcnRpb24sDQogIGJl
Y2F1c2UgaXQgZG9lcyBub3QgbmVlZCB0byBiZSBwcm90ZWN0ZWQgZnJvbSBkaXNjbG9zdXJlLiAN
Cg0KICAgMi4gIEhvbGRlci1vZi1LZXkgQXNzZXJ0aW9uczogVG8gYWNjZXNzIHRoZSBhc3NvY2lh
dGVkIHJlc291cmNlcywgdGhlDQogICAgICAgZW50aXR5IHByZXNlbnRpbmcgdGhlIGFzc2VydGlv
biBtdXN0IGRlbW9uc3RyYXRlIHBvc3Nlc3Npb24gb2YNCiAgICAgICBhZGRpdGlvbmFsIGNyeXB0
b2dyYXBoaWMgbWF0ZXJpYWwuICBUaGUgdG9rZW4gc2VydmljZSB0aGVyZWJ5DQogICAgICAgYmlu
ZHMgYSBrZXkgaWRlbnRpZmllciB0byB0aGUgYXNzZXJ0aW9uIGFuZCB0aGUgY2xpZW50IGhhcyB0
bw0KICAgICAgIGRlbW9uc3RyYXRlIHRvIHRoZSByZWx5aW5nIHBhcnR5IHRoYXQgaXQga25vd3Mg
dGhlIGtleQ0KICAgICAgIGNvcnJlc3BvbmRpbmcgdG8gdGhhdCBpZGVudGlmaWVyIHdoZW4gcHJl
c2VudGluZyB0aGUgYXNzZXJ0aW9uLg0KICAgICAgIFRoaXMgbWVjaGFuaXNtIHByb3ZpZGVzIGFk
ZGl0aW9uYWwgc2VjdXJpdHkgcHJvcGVydGllcy4NCiAgICBUaGUgZGVsZWdhdGlvbiBpbiBteSB1
c2UgY2FzZSBkb2VzIG5vdCBiZWxvbmcgdG8gaG9sZGVyLW9mLWtleSANCmFzc2VydGlvbiwNCiAg
YmVjYXVzZSAgdGhlIGNsaWVudCBkb2VzIG5vdCBoYXZlIHRvICBkZW1vbnN0cmF0ZSB0byB0aGUg
cmVseWluZyBwYXJ0eSANCnRoYXQgaXQga25vd3MgdGhlIGtleS4gDQogDQogDQoNCkpvaG4gQnJh
ZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+INC009ogMjAxMi0xMi0wMyAyMToxNzozODoNCg0KPiBU
aGF0IG1heSByZWxhdGUgbW9yZSB0byB0aGUgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBkaXNjdXNzaW9u
Lg0KPiANCj4gWW91IG1heSB3YW50IHRvIHN1Ym1pdCB0aGF0IGFzIGEgdXNlIGNhc2UuDQo+IA0K
PiBKb2huIEIuDQo+IE9uIDIwMTItMTItMDMsIGF0IDY6MDEgQU0sIHpob3Uuc3VqaW5nQHp0ZS5j
b20uY24gd3JvdGU6DQo+IA0KPiANCj4gDQo+IEFuZCBhbm90aGVyIGRpZmZlcmVuY2UgaXMgbXkg
dXNlIGNhc2UgY291bGQgYmUgdGhhdCAiYXNzZXJ0aW9uIiBiZSANCj4gZ2VuZXJhdGVkIHNlcXVl
bnRpYWxseSBieSByZXNvdXJjZSBvd25lciBhbmQgY2xpZW50LiANCj4gRm9yIGV4YW1wbGUsIHJl
c291cmNlIG93bmVyIGRlbGVnYXRlcyBhIGNsaWVudCB0byBnZW5lcmF0ZSBzaWduYXR1cmUNCj4g
b24gYmVoYWxmIG9mIGl0LCBjbGllbnQgZ2VuZXJhdGVzIGEgc2lnbmF0dXJlIHVzaW5nIHRoZSBw
cml2YXRlIGtleSBvZiANCml0c2VsZiwNCj4gd2hpY2ggaXMgY2FsbGVkIHByb3h5IHNpZ25hdHVy
ZSBpbiBjcnlwdG9ncmFwaHkuIA0KPiANCj4gDQo+IA0KPiA+IE15IHVzZSBjYXNlIGlzIGluZGVl
ZCBzaW1pbGFyIHRvICBhc3NlcnRpb24gZmxvdyAic2VjdGlvbiA2LjMuIA0KPiA+IENsaWVudCBB
Y3Rpbmcgb24gQmVoYWxmIG9mIGEgVXNlciIuIA0KPiA+IERpZmZlcmVuY2VzIGFyZTogDQo+ID4g
MS4gIGlmIG15IHVzZSBjYXNlIGlzIGNhcnJpZWQgb3V0IGluIGFzc2VydGlvbiBmcmFtZXdvcmss
ICJwcmljaXBhbCINCj4gPiBzaG91bGQgYmUgY2xpZW50LCB3aGlsZSBhc3NlcnRpb24gZG9jdW1l
bnQgZG9lcyBub3QgDQo+ID4gaW5jbHVkZSBjbGllbnQgYXMgYW4gb3B0aW9uIHdoZW4gY2xpZW50
IGlzIGFjdGluZyBvbiBiZWhhbGYgb2YgYSANCj4gPiB1c2VyKHJlc291cmNlIG93bmVyKSwgaXQg
c2F5cyAgIiBhbiBhdXRob3JpemVkIGFjY2Vzc29yIGZvciB3aGljaCB0aGUgIA0KDQo+ID4gYWNj
ZXNzIHRva2VuIGlzIGJlaW5nIHJlcXVlc3RlZCAodHlwaWNhbGx5IHRoZSByZXNvdXJjZSBvd25l
ciwgb3IgDQo+ID4gYW4gYXV0aG9yaXplZCBkZWxlZ2F0ZSkuIiANCj4gPiAyLiAgaWYgbXkgdXNl
IGNhc2UgaXMgY2FycmllZCBvdXQgaW4gYXNzZXJ0aW9uIGZyYW1ld29yaywgImlzc3VlciIgDQo+
ID4gc2hvdWxkIGJlIHJlc291cmNlIG93bmVyLCB3aGlsZSBhc3NlcnRpb24gZG9jdW1lbnQgb25s
eSBpbmNsdWRlcyANCj4gPiBjbGllbnQgYW5kIHRva2VuIHNlcnZpY2UgDQo+ID4gDQo+ID4gSW4g
bXkgdXNlIGNhc2UgdGhlICJhc3NlcnRpb24iIGlzIG1vcmUgbGlrZSBhIHByaXZhdGUgb3V0cHV0
LCB3aGlsZSANCj4gPiBpbiBhc3NlcnRpb24gZmxvdyAiYXNzZXJ0aW9uICIgaXMgZ2VuZXJhdGVk
IGJ5IGEgdGhyaWQgcGFydHkgdG9rZW4gDQo+ID4gc2VydmljZSBvciBieSBjbGllbnQgaXRzZWxm
LiANCj4gPiANCj4gPiBOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4gDQo+ID4gMjAx
Mi0xMi0wMyAxNDo0NCANCj4gPiANCj4gPiDK1bz+yMsgDQo+ID4gDQo+ID4gemhvdS5zdWppbmdA
enRlLmNvbS5jbiANCj4gPiANCj4gPiCzrcvNIA0KPiA+IA0KPiA+ICJvYXV0aEBpZXRmLm9yZyBX
RyIgPG9hdXRoQGlldGYub3JnPiANCj4gPiANCj4gPiDW98ziIA0KPiA+IA0KPiA+IFJlOiBSZTog
W09BVVRILVdHXSBIaSxhbnkgY29tbWVudCBvbiBkcmFmdC16aG91LW9hdXRoLW93bmVyLWF1dGg/
IA0KPiA+IA0KPiA+IFlvdXIgdXNlY2FzZSBzb3VuZHMgYSBsaXR0bGUgYml0IGxpa2UgdGhlIGFz
c2VydGlvbiBmbG93LiANCj4gPiBUaGUgUk8gaXNzdWVzIGFuIGFzc2VydGlvbiBhbmQgdGhlIHJl
c3QgZ29lcy4gDQo+ID4gSXMgdGhlcmUgcmVhc29ucyB0aGF0IGFuIGFzc2VydGlvbiBmbG93IGNh
bm5vdCBkbz8gDQo+ID4gDQo+ID4gTmF0DQo+IA0KPiA+IE9uIE1vbiwgRGVjIDMsIDIwMTIgYXQg
MzozNSBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IHdyb3RlOiANCj4gPiBteSB1c2UgY2Fz
ZShSTy1pbml0aWF0ZWQgZGVsZWdhdGlvbik6IA0KPiA+IC1JIGRlcG9zaXQgbXkgY2hpbGQocHJl
Y2lvdXMgcmVzb3VyY2UpIGF0IGtpbmRlcmdhcmRlbihSZXNvdXJjZSANClNlcnZlcikgDQo+ID4g
LUkgZGVsZWdhdGUgYSBmZXcgcGVyc29ucyxlLmcuLCBncmFuZHBhcmVudHMgb2YgbXkgY2hpbGQs
IHRvIHBpY2sgdXANCj4gPiBteSBjaGlsZCBhdCB0aGUga2luZGVyZ2FyZGVuIA0KPiA+IC13aGVu
IHNvbWVvbmUgdHJpZXMgdG8gdGFrZSBoaW0gb3V0c2lkZSBvZiB0aGUga2luZGVyZ2FyZGVuLCAg
dGhlIA0KPiA+IHRlYWNoZXIgd2lsbCBhc2sgaGltL2hlciB0byBzaG93IG15IGRlbGVnYXRpb24g
DQo+ID4gIHN0YXRlbWVudCwgbm8gc3RhdGVtZW50LCBubyB0YWtpbmcgbXkgY2hpbGQuIA0KPiA+
IA0KPiANCj4gPiANCj4gPiAtLSANCj4gPiBOYXQgU2FraW11cmEgKD1uYXQpIA0KPiA+IENoYWly
bWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPiA+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiA+
IEBfbmF0X2VuIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo=
--=_alternative 0020FA2748257ACA_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk1vcmUgZGlmZmVyZW5jZXM6PC9m
b250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Bc3Nl
cnRpb25zIGFyZSBjbGFzc2lmaWVkIGludG8gdHdvIHR5cGVzOjwvZm9udD4NCjxicj4NCjxicj4N
Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IDEuICZuYnNwO0JlYXJl
ciBBc3NlcnRpb25zOiBBbnkNCmVudGl0eSBpbiBwb3NzZXNzaW9uIG9mIGEgYmVhcmVyIGFzc2Vy
dGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7KGUuZy4gdGhlDQpiZWFyZXIpIGNhbiB1c2UgaXQgdG8gZ2V0IGFj
Y2VzcyB0byB0aGUgYXNzb2NpYXRlZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu
cy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7cmVzb3VyY2VzDQood2l0aG91dCBk
ZW1vbnN0cmF0aW5nIHBvc3Nlc3Npb24gb2YgYSBjcnlwdG9ncmFwaGljPC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtr
ZXkpLiAmbmJzcDtUbw0KcHJldmVudCBtaXN1c2UsIGJlYXJlciBhc3NlcnRpb25zIG5lZWQgdG8g
YmUgcHJvdGVjdGVkPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtmcm9tIGRpc2Nsb3N1cmUNCmluIHN0b3JhZ2UgYW5k
IGluIHRyYW5zcG9ydC4gJm5ic3A7QSBzZWN1cmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvbW11bmljYXRpb24N
CmNoYW5uZWwgaXMgcmVxdWlyZWQgYmV0d2VlbiBhbGwgZW50aXRpZXMgdG8gYXZvaWQ8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO2xlYWtpbmcgdGhlDQphc3NlcnRpb24gdG8gdW5hdXRob3JpemVkIHBhcnRpZXMuPC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu
YnNwOyAmbmJzcDsgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0ic2Fucy1zZXJp
ZiI+Jm5ic3A7DQpUaGUgZGVsZWdhdGlvbiBpbiBteSB1c2UgY2FzZSBkb2VzIG5vdCBiZWxvbmcg
dG8gYmVhcmVyIGFzc2VydGlvbiw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBm
YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgYmVjYXVzZSBpdCBkb2VzIG5vdA0KbmVlZCB0byBiZSBw
cm90ZWN0ZWQgZnJvbSBkaXNjbG9zdXJlLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsyLiAmbmJzcDtIb2xkZXItb2YtS2V5DQpB
c3NlcnRpb25zOiBUbyBhY2Nlc3MgdGhlIGFzc29jaWF0ZWQgcmVzb3VyY2VzLCB0aGU8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwO2VudGl0eSBwcmVzZW50aW5nDQp0aGUgYXNzZXJ0aW9uIG11c3QgZGVtb25zdHJhdGUg
cG9zc2Vzc2lvbiBvZjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YWRkaXRpb25hbA0KY3J5cHRvZ3JhcGhpYyBtYXRl
cmlhbC4gJm5ic3A7VGhlIHRva2VuIHNlcnZpY2UgdGhlcmVieTwvZm9udD4NCjxicj48Zm9udCBz
aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmluZHMg
YSBrZXkNCmlkZW50aWZpZXIgdG8gdGhlIGFzc2VydGlvbiBhbmQgdGhlIGNsaWVudCBoYXMgdG88
L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwO2RlbW9uc3RyYXRlDQp0byB0aGUgcmVseWluZyBwYXJ0eSB0aGF0IGl0IGtu
b3dzIHRoZSBrZXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NvcnJlc3BvbmRpbmcNCnRvIHRoYXQgaWRlbnRpZmll
ciB3aGVuIHByZXNlbnRpbmcgdGhlIGFzc2VydGlvbi48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoaXMgbWVjaGFu
aXNtDQpwcm92aWRlcyBhZGRpdGlvbmFsIHNlY3VyaXR5IHByb3BlcnRpZXMuPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgPC9mb250Pjxmb250IHNpemU9
MiBjb2xvcj1yZWQgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7DQpUaGUgZGVsZWdhdGlvbiBpbiBt
eSB1c2UgY2FzZSBkb2VzIG5vdCBiZWxvbmcgdG8gaG9sZGVyLW9mLWtleSBhc3NlcnRpb24sPC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7
IGJlY2F1c2UgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1yZWQ+Jm5ic3A7dGhlDQpjbGllbnQg
ZG9lcyBub3QgaGF2ZSB0byAmbmJzcDtkZW1vbnN0cmF0ZSB0byB0aGUgcmVseWluZyBwYXJ0eSB0
aGF0IGl0DQprbm93cyB0aDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9InNhbnMt
c2VyaWYiPmUga2V5LiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PiZuYnNwOyAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PiZuYnNwOyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Kb2huIEJyYWRsZXkg
Jmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0OyDQtNPaIDIwMTItMTItMDMNCjIxOjE3OjM4Ojxicj4N
Cjxicj4NCiZndDsgVGhhdCBtYXkgcmVsYXRlIG1vcmUgdG8gdGhlIHByb29mIG9mIHBvc3Nlc3Np
b24gZGlzY3Vzc2lvbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy
Pg0KJmd0OyBZb3UgbWF5IHdhbnQgdG8gc3VibWl0IHRoYXQgYXMgYSB1c2UgY2FzZS48L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBKb2huIEIuPC9mb250
PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IE9uIDIwMTItMTItMDMsIGF0IDY6MDEg
QU0sIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24NCndyb3RlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBBbmQgYW5v
dGhlciBkaWZmZXJlbmNlIGlzIG15IHVzZSBjYXNlIGNvdWxkIGJlIHRoYXQgJnF1b3Q7YXNzZXJ0
aW9uJnF1b3Q7DQpiZSA8YnI+DQomZ3Q7IGdlbmVyYXRlZCBzZXF1ZW50aWFsbHkgYnkgcmVzb3Vy
Y2Ugb3duZXIgYW5kIGNsaWVudC4gPGJyPg0KJmd0OyBGb3IgZXhhbXBsZSwgcmVzb3VyY2Ugb3du
ZXIgZGVsZWdhdGVzIGEgY2xpZW50IHRvIGdlbmVyYXRlIHNpZ25hdHVyZTxicj4NCiZndDsgb24g
YmVoYWxmIG9mIGl0LCBjbGllbnQgZ2VuZXJhdGVzIGEgc2lnbmF0dXJlIHVzaW5nIHRoZSBwcml2
YXRlIGtleQ0Kb2YgaXRzZWxmLDxicj4NCiZndDsgd2hpY2ggaXMgY2FsbGVkIHByb3h5IHNpZ25h
dHVyZSBpbiBjcnlwdG9ncmFwaHkuIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgJmd0OyBNeSB1c2UgY2FzZSBpcyBpbmRlZWQgc2ltaWxhciB0byAmbmJzcDthc3Nl
cnRpb24gZmxvdyAmcXVvdDtzZWN0aW9uDQo2LjMuICZuYnNwOzxicj4NCiZndDsgJmd0OyBDbGll
bnQgQWN0aW5nIG9uIEJlaGFsZiBvZiBhIFVzZXImcXVvdDsuIDxicj4NCiZndDsgJmd0OyBEaWZm
ZXJlbmNlcyBhcmU6IDxicj4NCiZndDsgJmd0OyAxLiAmbmJzcDtpZiBteSB1c2UgY2FzZSBpcyBj
YXJyaWVkIG91dCBpbiBhc3NlcnRpb24gZnJhbWV3b3JrLA0KJnF1b3Q7cHJpY2lwYWwmcXVvdDs8
YnI+DQomZ3Q7ICZndDsgc2hvdWxkIGJlIGNsaWVudCwgd2hpbGUgYXNzZXJ0aW9uIGRvY3VtZW50
IGRvZXMgbm90IDxicj4NCiZndDsgJmd0OyBpbmNsdWRlIGNsaWVudCBhcyBhbiBvcHRpb24gd2hl
biBjbGllbnQgaXMgYWN0aW5nIG9uIGJlaGFsZiBvZg0KYSA8YnI+DQomZ3Q7ICZndDsgdXNlcihy
ZXNvdXJjZSBvd25lciksIGl0IHNheXMgJm5ic3A7JnF1b3Q7IGFuIGF1dGhvcml6ZWQgYWNjZXNz
b3INCmZvciB3aGljaCB0aGUgJm5ic3A7IDxicj4NCiZndDsgJmd0OyBhY2Nlc3MgdG9rZW4gaXMg
YmVpbmcgcmVxdWVzdGVkICh0eXBpY2FsbHkgdGhlIHJlc291cmNlIG93bmVyLA0Kb3IgJm5ic3A7
PGJyPg0KJmd0OyAmZ3Q7IGFuIGF1dGhvcml6ZWQgZGVsZWdhdGUpLiZxdW90OyA8YnI+DQomZ3Q7
ICZndDsgMi4gJm5ic3A7aWYgbXkgdXNlIGNhc2UgaXMgY2FycmllZCBvdXQgaW4gYXNzZXJ0aW9u
IGZyYW1ld29yaywNCiZxdW90O2lzc3VlciZxdW90OyA8YnI+DQomZ3Q7ICZndDsgc2hvdWxkIGJl
IHJlc291cmNlIG93bmVyLCB3aGlsZSBhc3NlcnRpb24gZG9jdW1lbnQgb25seSBpbmNsdWRlcw0K
PGJyPg0KJmd0OyAmZ3Q7IGNsaWVudCBhbmQgdG9rZW4gc2VydmljZSA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IEluIG15IHVzZSBjYXNlIHRoZSAmcXVvdDthc3NlcnRpb24mcXVvdDsg
aXMgbW9yZSBsaWtlIGEgcHJpdmF0ZQ0Kb3V0cHV0LCB3aGlsZSA8YnI+DQomZ3Q7ICZndDsgaW4g
YXNzZXJ0aW9uIGZsb3cgJnF1b3Q7YXNzZXJ0aW9uICZxdW90OyBpcyBnZW5lcmF0ZWQgYnkgYSB0
aHJpZA0KcGFydHkgdG9rZW4gPGJyPg0KJmd0OyAmZ3Q7IHNlcnZpY2Ugb3IgYnkgY2xpZW50IGl0
c2VsZi4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBOYXQgU2FraW11cmEgJmx0O3Nh
a2ltdXJhQGdtYWlsLmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7IDIwMTItMTItMDMgMTQ6NDQgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDK1bz+yMsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyB6aG91LnN1amluZ0B6dGUuY29tLmNuIDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgs63LzSA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O29hdXRo
QGlldGYub3JnIFdHJnF1b3Q7ICZsdDtvYXV0aEBpZXRmLm9yZyZndDsgPGJyPg0KJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyDW98ziIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgUmU6
IFJlOiBbT0FVVEgtV0ddIEhpLGFueSBjb21tZW50IG9uIGRyYWZ0LXpob3Utb2F1dGgtb3duZXIt
YXV0aD8NCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgWW91ciB1c2VjYXNlIHNvdW5k
cyBhIGxpdHRsZSBiaXQgbGlrZSB0aGUgYXNzZXJ0aW9uIGZsb3cuICZuYnNwOzxicj4NCiZndDsg
Jmd0OyBUaGUgUk8gaXNzdWVzIGFuIGFzc2VydGlvbiBhbmQgdGhlIHJlc3QgZ29lcy4gJm5ic3A7
PGJyPg0KJmd0OyAmZ3Q7IElzIHRoZXJlIHJlYXNvbnMgdGhhdCBhbiBhc3NlcnRpb24gZmxvdyBj
YW5ub3QgZG8/ICZuYnNwOzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTmF0PGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gTW9uLCBEZWMgMywgMjAxMiBhdCAzOjM1IFBNLCAmbHQ7
emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDsNCndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgbXkgdXNl
IGNhc2UoUk8taW5pdGlhdGVkIGRlbGVnYXRpb24pOiA8YnI+DQomZ3Q7ICZndDsgLUkgZGVwb3Np
dCBteSBjaGlsZChwcmVjaW91cyByZXNvdXJjZSkgYXQga2luZGVyZ2FyZGVuKFJlc291cmNlDQpT
ZXJ2ZXIpIDxicj4NCiZndDsgJmd0OyAtSSBkZWxlZ2F0ZSBhIGZldyBwZXJzb25zLGUuZy4sIGdy
YW5kcGFyZW50cyBvZiBteSBjaGlsZCwgdG8NCnBpY2sgdXA8YnI+DQomZ3Q7ICZndDsgbXkgY2hp
bGQgYXQgdGhlIGtpbmRlcmdhcmRlbiA8YnI+DQomZ3Q7ICZndDsgLXdoZW4gc29tZW9uZSB0cmll
cyB0byB0YWtlIGhpbSBvdXRzaWRlIG9mIHRoZSBraW5kZXJnYXJkZW4sDQombmJzcDt0aGUgPGJy
Pg0KJmd0OyAmZ3Q7IHRlYWNoZXIgd2lsbCBhc2sgaGltL2hlciB0byBzaG93IG15IGRlbGVnYXRp
b24gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO3N0YXRlbWVudCwgbm8gc3RhdGVtZW50LCBubyB0YWtp
bmcgbXkgY2hpbGQuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7IE5hdCBTYWtpbXVyYSAoPW5hdCkgPGJy
Pg0KJmd0OyAmZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsgJmd0OyBo
dHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+DQomZ3Q7ICZndDsgQF9uYXRfZW4gX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2ZvbnQ+PC90dD4NCg==
--=_alternative 0020FA2748257ACA_=--

From bcampbell@pingidentity.com  Tue Dec  4 07:41:43 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3588021F898B for ; Tue,  4 Dec 2012 07:41:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.751
X-Spam-Level: 
X-Spam-Status: No, score=-4.751 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7WK9JYF+crl for ; Tue,  4 Dec 2012 07:41:41 -0800 (PST)
Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id 5863921F86F9 for ; Tue,  4 Dec 2012 07:41:41 -0800 (PST)
Received: from mail-vb0-f70.google.com ([209.85.212.70]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKUL4ZtMQfpuujt9LS2ANyFlqq6rHD3jke@postini.com; Tue, 04 Dec 2012 07:41:41 PST
Received: by mail-vb0-f70.google.com with SMTP id r6so1203790vbi.5 for ; Tue, 04 Dec 2012 07:41:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xeUGPLAbDCJdOWkMWZEn4RnG9iP7PXJXokFy868In7A=; b=f93NjGOxZNqaq2lYmnt8mqMQ+vlE6HDgH3tg2pOYswpMP+IluwVRNx5VYcKr+DAEgz 6PFb7hc2rLiUznxknLhP51OnWnsSdw61KIMTFer5URg6lN/CYzBhdMVHQT+98gySUpzC ka/7BQ/GDLHJzFja1Ci1ayeoJvmVtJRhdZ/vl1NkHI6KSHBBvtOSZ+D6vgann2LKf8rg W0zrriENCLyyCKlk5dMr/Pdo+OuFO0r7uiVJUv/n3ZRa6ezW3s7xWChWtXA5Xr/aJKYR q14TzAasQd4v4SUPZ8pK07AkKRvS8sRCTCIsKmPgOgfZTS1XwPb7NfuRKmVDGB5ilzie HVqg==
Received: by 10.58.74.196 with SMTP id w4mr12123626vev.7.1354635700043; Tue, 04 Dec 2012 07:41:40 -0800 (PST)
Received: by 10.58.74.196 with SMTP id w4mr12123617vev.7.1354635699888; Tue, 04 Dec 2012 07:41:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.64.47 with HTTP; Tue, 4 Dec 2012 07:41:08 -0800 (PST)
In-Reply-To: 
References: <7EBB51A5-A7FC-416E-BF29-D790DFAD9677@salesforce.com>  
From: Brian Campbell 
Date: Tue, 4 Dec 2012 08:41:08 -0700
Message-ID: 
To: Nat Sakimura 
Content-Type: multipart/alternative; boundary=047d7b86edf6b1235204d008b370
X-Gm-Message-State: ALoCoQm6XB+HH0bb9GVNuCWoO2egFDIyZB/mM6hQ0QbTyZDhQ+3B+3CW1/aqM20/1mPrPU3rbButDo9uxIP4iZpwTFtZffiBaIstH/UT5oGhWHtTBbbOldGHbX3xvBwDXgCFu2Xz/gZ3
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 15:41:43 -0000

--047d7b86edf6b1235204d008b370
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

The intent was definitely not to constrain who/what could be the issuer.
But also try to provide
some guidance around the common cases that are actually being deployed now,
which are the client self-issued and STS variants. Resource owner as an
issuer is an interesting case but seems mostly theoretical at this point.

I feel like mentioning the resource owner there in =A1=EC5.1 would cause mo=
re
confusion than anything else. I'd prefer to just strike the whole sentence
in question and maybe add some additional text to =A1=EC3 that clarifies th=
at
the issuer can really be any entity, if folks think a change is needed
here?



On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura  wrote:

> Actually, "The issuer may be either
>       an OAuth client (when assertions are self-issued) or any other
> entity, e.g.,  a third party
> token service, resource owner. "  is not really clean.
>
> OAuth client is just another example of an issuer.
>
> So, perhaps the sentence could be:
>
> "Example of issuers include an OAuth client, resource owner, an
> independent third party."
>
> So, the clause becomes:
>
>  Issuer  The unique identifier for the entity that issued the
>       assertion.  Generally this is the entity that holds the key
>       material used to generate the assertion.
>        Example of issuers include an OAuth client, resource owner, an
> independent third party.
>
> Nat
>
> Nat
>
> On Tue, Dec 4, 2012 at 11:40 AM,  wrote:
>
>>
>>
>>
>> Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 10:2=
6:50:
>>
>>
>> > Please feel free to suggest better language.
>>
>> >
>> > Issuer simply allows the token service to know who created the
>> > assertion, so it can look them up and see if they're trusted.
>> > Effectively the same as an Issuer in SAML.
>>
>> a conflict : "The token service is the assertion issuer" in assertion
>> document.
>> while you said "token service know who created the assertion"
>>
>> I wonder if the following text is acceptable:
>>
>>   Issuer  The unique identifier for the entity that issued the
>>       assertion.  Generally this is the entity that holds the key
>>       material used to generate the assertion.  The issuer may be either
>>       an OAuth client (when assertions are self-issued) or any other
>> entity, e.g.,  a third party
>> token service, resource owner.
>>
>>
>> 6.3.  Client Acting on Behalf of a User
>>
>> The Issuer of the assertion MUST identify the entity that issued
>>       the assertion as recognized by the Authorization Server.  If the
>>       assertion is self-issued, the Issuer SHOULD be the "client_id".
>>       If the assertion was issued by a Security Token Service (STS), the
>>       Issuer SHOULD identify the STS as recognized by the Authorization
>>       Server.If the assertion was issued by the resource owner, the
>>       Issuer SHOULD identify the resource owner as recognized by the
>> Authorization
>>       Server.
>>
>> >
>> > -cmort
>> >
>> > On Dec 3, 2012, at 6:23 PM,  wrote:
>> >
>> >
>> > Obviously, it is not so clear from the language there.
>> >
>> >
>> > Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 10=
:17:12:
>> >
>> > > There's no reason why it can't be resource owner today.
>> > >
>> > > On Dec 3, 2012, at 6:06 PM,  <
>> zhou.sujing@zte.com.cn
>> > > > wrote:
>> > >
>> > >
>> > > +1.
>> > > And why it was not looked at that time?
>> > >
>> > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:
>> > >
>> > > > Actually, I think it is a good time to start looking at the resour=
se
>> > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had
>> brought
>> > > > this up a couple of years ago.)
>> > > >
>> > > > Igor
>> > > >
>> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:
>> > > > I suppose, yes. I was reading it like that all the time.
>> > > > Whether it is or not, if it is still ok, it might be better to
>> > clarify it.
>> > > > Word like "third party" tends to be a bit of problem without
>> > > clearlydefining.
>> > > > I had similar experience in other fora.
>> > > >
>> > > > Nat
>> > > >
>> > > > Sent from iPad
>> > > >
>> > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn"  =A4=CE
>> > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:
>> > >
>> > > >
>> > > > could be Resource owner?
>> > > >
>> > >
>> > > >
>> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" 
>> > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org
>> > > > 2012-12-03 16:49
>> > > >
>> > > > =CA=D5=BC=FE=C8=CB
>> > > >
>> > > > "ext Nat Sakimura" , "Brian Campbell" <
>> > > > bcampbell@pingidentity.com>, "oauth" 
>> > > >
>> > > > =B3=AD=CB=CD
>> > > >
>> > > > =D6=F7=CC=E2
>> > > >
>> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
>> > > > either the client or a third party token service?
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > Hi Nat,
>> > > >
>> > > > The current text essentially says that the assertion can either be
>> > > > created by the client (in which case it is self-signed) or it can =
be
>> > > > created by some other entity (which is then called the third party
>> > > > token service). So, this third party could be the authorization
>> server.
>> > > >
>> > > > Ciao
>> > > > Hannes
>> > > >
>> > > >
>> > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
>> Behalf Of
>> > > > ext Nat Sakimura
>> > > > Sent: Monday, December 03, 2012 10:35 AM
>> > > > To: Brian Campbell; oauth
>> > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to =
be
>> > > > either the client or a third party token service?
>> > > >
>> > > > Hi Brian,
>> > > >
>> > > >
>> > > > The assertion framework defines the Issuer as:
>> > > >
>> > > >    Issuer  The unique identifier for the entity that issued the
>> > > >       assertion.  Generally this is the entity that holds the key
>> > > >       material used to generate the assertion.  The issuer may be
>> either
>> > > >       an OAuth client (when assertions are self-issued) or a third
>> party
>> > > >       token service.
>> > > >
>> > > > I was wondering why it has to be either the client or a third part=
y
>> > > > token service.
>> > > > Conceptually, it could be any token service (functionality)
>> > > residingin any of
>> > > >
>> > > > the stakeholders (Resource Owner, OAuth Client, Authorization
>> Server, or
>> > > > a third party).
>> > > >
>> > > >
>> > > > I would appreciate if you could clarify why is the case.
>> > > >
>> > > >
>> > > > Best,
>> > > >
>> > > > --
>> > > > Nat Sakimura (=3Dnat)
>> > > > Chairman, OpenID Foundation
>> > > > http://nat.sakimura.org/
>> > > > @_nat_en
>> > > >  _______________________________________________
>> > > > OAuth mailing list
>> > > > OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/oauth
>> > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/oauth
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/oauth
>> > > _______________________________________________
>> > > OAuth mailing list
>> > > OAuth@ietf.org
>> > > https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--047d7b86edf6b1235204d008b370
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

The intent was definitely not to constrain who/what could be the issuer.&nb=
sp; But also try to provide 
some guidance around the common cases that =
are actually being deployed now, which are the client self-issued and STS v=
ariants. Resource owner as an issuer is an interesting case but seems mostl=
y theoretical at this point.



I feel like mentioning the resource owner there in =A1=EC5.1 would caus=
e more confusion than anything else. I'd prefer to just strike the whol=
e sentence in question and maybe add some additional text to =A1=EC3 that c=
larifies that the issuer can really be any entity, if folks think a change =
is needed here? 





On Mon, D=
ec 3, 2012 at 9:20 PM, Nat Sakimura <sakimura@gmail.com> wr=
ote:



Actually, "The issuer may be either&=
nbsp;




      an OAuth client (when asserti=
ons are self-issued) or any =
other entity, e.g.,  a third party 




token service, resource owner. "  is not really clean. 




OAuth clien=
t is just another example of an issuer. 





So, per=
haps the sentence could be: 





"E=
xample of issuers include an OAuth client, resource owner, an independent t=
hird party."





So, the=
 clause becomes: 






 Issuer  The unique identifier for the ent=
ity that issued the 



      assertion. &=
nbsp;Generally this is the entity that holds the key 
      material used to g=
enerate the assertion.  




      Example of i=
ssuers include an OAuth client, resource owner, an independent third party.=
 

Nat





Nat




On Tue, Dec 4, 2012 at 11:40 AM,  <zhou.sujing@zte.com.cn> wrote:








Chuck Mortimore <cmortimore@salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:26:50:




> Please feel free to suggest better language.


> 

> Issuer simply allows the token service to know who created the 

> assertion, so it can look them up and see if they're trusted. &nbs=
p;
  

> Effectively the same as an Issuer in SAML.



a conflict : "The
token service is the assertion issuer"
in assertion document.

while you said "token service know who created
the assertion"



I wonder if the following text is acceptable:

 

  Issuer  The uniqu=
e
identifier for the entity that issued the

      assertio=
n.
 Generally this is the entity that holds the key

      material=
 used
to generate the assertion.  The issuer may be either

      an=
 OAuth client
(when assertions are self-issued) or
any other entity, e.g.,  a
third party 

token service, r=
esource
owner.





6.3.  Client Acting on Behalf of a User



The Issuer of the assertion MUST identify the entity
that issued

      the assertion as recognized by
the Authorization Server.  If the

      assertion is self-issued, the
Issuer SHOULD be the "client_id".

      If the assertion was issued by
a Security Token Service (STS), the

      Issuer SHOULD identify the STS
as recognized by the Authorization

      Server.If
the assertion was issued by the resource owner, the

      Issuer SHOULD identify
the resource owner as recognized by the Authorization

      Server.



> 

> -cmort

> 

> On Dec 3, 2012, at 6:23 PM, <zhou.sujing@zte.com.cn> wrote:

> 

> 

> Obviously, it is not so clear from the language there. 

> 

> 

> Chuck Mortimore <cmortimore@salesforce.com> =D0=B4=D3=DA 2012-12-04
10:17:12:

> 

> > There's no reason why it can't be resource owner today. &=
nbsp;


> > 

> > On Dec 3, 2012, at 6:06 PM, <zhou.sujing@zte.com.cn> <zhou.sujing@zte.com.cn
> > > wrote: 

> > 

> > 

> > +1. 

> > And why it was not looked at that time? 

> > 

> > oauth=
-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:

> > 

> > > Actually, I think it is a good time to start looking at
the resourse

> > > owner issuing assertions@ (Interestingly enough, Hui-Lan
had brought

> > > this up a couple of years ago.)

> > > 

> > > Igor

> > > 

> > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: 

> > > I suppose, yes. I was reading it like that all the time.


> > > Whether it is or not, if it is still ok, it might be better
to 

> clarify it. 

> > > Word like "third party" tends to be a bit of probl=
em
without 

> > clearlydefining. 

> > > I had similar experience in other fora. 

> > > 

> > > Nat 

> > > 

> > > Sent from iPad 

> > > 

> > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn=
>
=A4=CE

> > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:

> > 

> > > 

> > > could be Resource owner? 

> > > 

> > 

> > > 

> > > "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@n=
sn.com>


> > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org 

> > > 2012-12-03 16:49 

> > > 

> > > =CA=D5=BC=FE=C8=CB 

> > > 

> > > "ext Nat Sakimura" <sakimura@gmail.com>,
"Brian Campbell" <

> > > bcampbell@pingidentity.com>, "oauth" <oauth@ietf.org>


> > > 

> > > =B3=AD=CB=CD 

> > > 

> > > =D6=F7=CC=E2 

> > > 

> > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have
to be     

> > > either the client or a third party token service? 

> > > 

> > > 

> > > 

> > > 

> > > Hi Nat, 

> > >   

> > > The current text essentially says that the assertion can
either be 

> > > created by the client (in which case it is self-signed)
or it can be

> > > created by some other entity (which is then called the third
party 

> > > token service). So, this third party could be the authorizat=
ion
server. 

> > >   

> > > Ciao

> > > Hannes 

> > >   

> > >   

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

> > > ext Nat Sakimura

> > > Sent: Monday, December 03, 2012 10:35 AM

> > > To: Brian Campbell; oauth

> > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer
have to be

> > > either the client or a third party token service? 

> > >   

> > > Hi Brian, 

> > >   

> > >   

> > > The assertion framework defines the Issuer as: 

> > >   

> > >    Issuer  The unique identifier for the
entity that issued the 

> > >       assertion.  Generally this is
the entity that holds the key 

> > >       material used to generate the assertion=
.
 The issuer may be either 

> > >       an OAuth client (when assertions are
self-issued) or a third party 

> > >       token service. 

> > >   

> > > I was wondering why it has to be either the client or a
third party 

> > > token service. 

> > > Conceptually, it could be any token service (functionality)


> > residingin any of 

> > >   

> > > the stakeholders (Resource Owner, OAuth Client, Authorizatio=
n
Server, or 

> > > a third party). 

> > >   

> > >   

> > > I would appreciate if you could clarify why is the case.


> > >   

> > >   

> > > Best, 

> > >   

> > > -- 

> > > Nat Sakimura (=3Dnat) 

> > > Chairman, OpenID Foundation

> > > http:=
//nat.sakimura.org/

> > > @_nat_en 

> > >  _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> > 

> > > 

> > > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.or=
g

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


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--047d7b86edf6b1235204d008b370--

From derek@ihtfp.com  Tue Dec  4 08:27:47 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFDE21F8BCE for ; Tue,  4 Dec 2012 08:27:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.293
X-Spam-Level: 
X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=-0.306, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71stsZBp4Mpp for ; Tue,  4 Dec 2012 08:27:45 -0800 (PST)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 439D721F8BEB for ; Tue,  4 Dec 2012 08:27:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 8C924260230 for ; Tue,  4 Dec 2012 11:27:40 -0500 (EST)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 32167-04 for ; Tue,  4 Dec 2012 11:27:39 -0500 (EST)
Received: from mocana.ihtfp.org (unknown [IPv6:fe80::224:d7ff:fee7:8924]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4E2812601FD for ; Tue,  4 Dec 2012 11:27:39 -0500 (EST)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id qB4GRc1M021320; Tue, 4 Dec 2012 11:27:38 -0500
From: Derek Atkins 
To: oauth@ietf.org
Cc: 
References: <20121203175642.17014.49025.idtracker@ietfa.amsl.com>
Date: Tue, 04 Dec 2012 11:27:38 -0500
In-Reply-To: <20121203175642.17014.49025.idtracker@ietfa.amsl.com> (IESG Secretary's message of "Mon, 03 Dec 2012 09:56:42 -0800")
Message-ID: 
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Virus-Scanned: Maia Mailguard 1.0.2a
Subject: [OAUTH-WG] OAUTH Conference Call Dec 14th, 2012 (was Re:  OAuth WG Virtual Interim Meetings, 11 January 2013 & 21 January 2013)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 16:27:47 -0000

FYI,

We will also be holding a conference call on Friday, December 14th at
1pm EST.  This call is not an official virtual interim meeting which
means no decisions can be made, but it is a time where we plan to
discuss progress and discuss any open issues.

We will send out dial-in information ASAP.

Thanks,

-derek, wg co-chair

IESG Secretary  writes:

> The OAuth Working Group will hold virtual interim meetings as follows:
>
> * 11th January 2013, 1pm EST
> * 21st January 2013, 1pm EST
>
> Agenda and dial-in information will be posted on the OAuth mailing list 
> (http://www.ietf.org/mail-archive/web/oauth/current/maillist.html) prior 
> to the meetings.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

From eve@xmlgrrl.com  Tue Dec  4 11:49:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B085121F8CC1 for ; Tue,  4 Dec 2012 11:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.293
X-Spam-Level: 
X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, SARE_URI_CONS7=0.306,  URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmWhbAxRm3X3 for ; Tue,  4 Dec 2012 11:49:31 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id BF2B221F8CAC for ; Tue,  4 Dec 2012 11:49:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by greendome.promanage-inc.com (Postfix) with ESMTP id 36C9539FE9D; Tue,  4 Dec 2012 09:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from greendome.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvtLjyaa12QO; Tue,  4 Dec 2012 09:25:47 -0800 (PST)
Received: from [192.168.168.107] (unknown [192.168.168.107]) by greendome.promanage-inc.com (Postfix) with ESMTPSA id 00AD639FE90; Tue,  4 Dec 2012 09:25:46 -0800 (PST)
From: Eve Maler 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 4 Dec 2012 09:25:46 -0800
To: "oauth@ietf.org WG" 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Subject: [OAUTH-WG] My earlier comments on the dyn client reg draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 19:49:32 -0000

Hannes suggested that, for transparency, I should share with the list =
the comments that I had earlier sent to Justin. Here they are. I believe =
these have all been addressed in one way or another by now.

	Eve

=3D=3D=3D=3D

General

- Authorship: I suspect that Christian Scholz really won't mind if you =
move him to the acknowledgments. He actually had not that much to do =
with the original UMA-based draft, but was our official spec editor of =
the group at the time. (I wrote the bulk of the requirements, and Maciej =
wrote the bulk of the request/response stuff.)

1. Introduction

- Para 2: s/meta information/metadata/ to match other references.

2.1. Client Association Request

- Could you make it a bit clearer that the parameters you list are =
actually defined in Section 3? I found this confusing at first.

2.2. Client Association Response (and following)

- Is it worthwhile defining a media type application/json+something for =
the various JSON-encoded responses defined in the doc? I'm not sure if =
the OAuth spec has been going to this trouble. The UMA spec does -- =
which means that eventually we'll have to submit to IANA for registering =
those types...

- client_secret:
 s/us used/is used/
 s/not required/OPTIONAL/ ?

- registration_access_token: Is there any reason not to call this simple =
"access_token"?

2.3. Client Update Request

- Para 1: Why is the empty-value interpretation a SHOULD rather than a =
MUST? It would seem that we'd want interoperability in how to =
replace/wipe metadata.

2.4. Client Update Response (and following)

- For client_id in responses, does it make sense to say something like =
"A unique Client Identifier matching the one in the request"?

2.5. Rotate Secret Request

- Having it be an error if the client never originally had a secret, and =
the question about rotating the access token, makes me think that we =
should keep things as simple as possible, and make this operation be =
something like "client_refresh", which always refreshes the access token =
and -- if it was issued a secret -- the secret as well? There's sort of =
a recursiveness to managing meta-secrets used to issue client =
identities, and the last thing we want is to embed a full-blown OAuth =
mechanism that makes it token turtles all the way down...

2.7. Client Registration Error Response

- Trying to think of additional error conditions: invalid ID? Invalid =
token? These don't seem covered by the existing options. Of course, it's =
possible this detail shouldn't be exposed in the error response for =
security reasons.

3. Client Metadata

- In "token_endpoint_auth_method": Is "unspecified or omitted" =
redundant? What's the difference?

5. Security Considerations

- I assume that, eventually, the RP/IdP language from the OpenID Connect =
draft will need to be genericized.

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl



From eve@xmlgrrl.com  Tue Dec  4 11:49:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B381921F8CC2 for ; Tue,  4 Dec 2012 11:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.293
X-Spam-Level: 
X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD-A0PwtnJGK for ; Tue,  4 Dec 2012 11:49:31 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id BF25F21F8CAB for ; Tue,  4 Dec 2012 11:49:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by greendome.promanage-inc.com (Postfix) with ESMTP id A8AC1362E70; Fri, 30 Nov 2012 17:43:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from greendome.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZyM9XXRqGPW; Fri, 30 Nov 2012 17:43:02 -0800 (PST)
Received: from [192.168.168.107] (unknown [192.168.168.107]) by greendome.promanage-inc.com (Postfix) with ESMTPSA id 3B84D362E54; Fri, 30 Nov 2012 17:43:02 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_50DAE10E-10D7-4F4E-8B60-EC90179E1C54"
From: Eve Maler 
In-Reply-To: <50B90D9E.5070108@mitre.org>
Date: Fri, 30 Nov 2012 17:43:01 -0800
Message-Id: <5D8CAC05-21D6-453A-8FDE-C8CB48084AD6@xmlgrrl.com>
References: <20121127184401.20364.27482.idtracker@ietfa.amsl.com>  <947EEF6D-12E5-4D6E-A92E-16184AE7119B@xmlgrrl.com> <50B8D71E.3010908@mitre.org>  <50B90D9E.5070108@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 19:49:32 -0000

--Apple-Mail=_50DAE10E-10D7-4F4E-8B60-EC90179E1C54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Preparing generically for context to be provided by the RS/host, as well =
as metadata provided back by the AS/AM, seems like a good idea, and =
hopefully doesn't have to be over-complex. Extension points can be quite =
simple if designed right. But I agree that the basic use case of "give =
me back the info about this token" should be nice and clean.

	Eve

On 30 Nov 2012, at 11:48 AM, Justin Richer  wrote:

> I think this approach makes sense and it gels with the basic concept =
that I'd had about the response from the introspection endpoint being =
extensible and, at some level, service specific. An interesting question =
then is do we want to have some kind of signaling from the client as to =
what they want or need back? In other words, make it into a full query =
API as opposed to a single callback. UMA starts to do this, with fields =
for the resource_set_id and host_id as part of the request. The pattern =
that I had written would have implicitly tied the "resource set id" to =
whatever client credentials were being used to make the request, but we =
already have potential use cases here (not implemented yet) of the RS =
wanting to provide more context to the authorization server. One of =
these would be passing along the user's OIDC id_token in addition to =
their access_token to help make auth decisions.=20
>=20
> All of that's very quickly going down the road to complexity that =
might crowd out the simple case, though, so my gut instinct is to avoid =
it in the core spec. Still, it's something to consider, especially if =
UMA wants to be wrapped using generic introspection, and the right level =
of complexity in the core could make the future much simpler.=20
>=20
> But even so, I think the simple case of "I have a token and want to =
know about it" needs to be supported without extra scaffolding.=20
>=20
>  -- Justin
>=20

\
Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl



--Apple-Mail=_50DAE10E-10D7-4F4E-8B60-EC90179E1C54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



	Eve

On 30 Nov =
2012, at 11:48 AM, Justin Richer <jricher@mitre.org> =
wrote:


 =20
   =20
 =20
  

    
I think this approach makes sense and
      it gels with the basic concept that I'd had about the response
      from the introspection endpoint being extensible and, at some
      level, service specific. An interesting question then is do we
      want to have some kind of signaling from the client as to what
      they want or need back? In other words, make it into a full query
      API as opposed to a single callback. UMA starts to do this, with
      fields for the resource_set_id and host_id as part of the request.
      The pattern that I had written would have implicitly tied the
      "resource set id" to whatever client credentials were being used
      to make the request, but we already have potential use cases here
      (not implemented yet) of the RS wanting to provide more context to
      the authorization server. One of these would be passing along the
      user's OIDC id_token in addition to their access_token to help
      make auth decisions. 

      

      All of that's very quickly going down the road to complexity that
      might crowd out the simple case, though, so my gut instinct is to
      avoid it in the core spec. Still, it's something to consider,
      especially if UMA wants to be wrapped using generic introspection,
      and the right level of complexity in the core could make the
      future much simpler. 

      

      But even so, I think the simple case of "I have a token and want
      to know about it" needs to be supported without extra scaffolding.
      

      

       -- Justin

      
\
Eve Maler =
                    =
             http://www.xmlgrrl.com/blog
+1 425 345 6756         =
                http://www.twitter.com/xmlgrrl=







=

--Apple-Mail=_50DAE10E-10D7-4F4E-8B60-EC90179E1C54--

From eve@xmlgrrl.com  Tue Dec  4 11:49:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1EA21F8CAB for ; Tue,  4 Dec 2012 11:49:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.292
X-Spam-Level: 
X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id difHwuaP6B+T for ; Tue,  4 Dec 2012 11:49:31 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id BF2EF21F8CB6 for ; Tue,  4 Dec 2012 11:49:31 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by greendome.promanage-inc.com (Postfix) with ESMTP id D485234B7AA; Thu, 29 Nov 2012 14:59:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from greendome.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLvwYWpoKnvT; Thu, 29 Nov 2012 14:59:42 -0800 (PST)
Received: from [192.168.168.111] (unknown [192.168.168.111]) by greendome.promanage-inc.com (Postfix) with ESMTPSA id 6920234B792; Thu, 29 Nov 2012 14:59:42 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_6E56121F-CF55-45DD-998C-4B7867AED974"
From: Eve Maler 
In-Reply-To: 
Date: Thu, 29 Nov 2012 14:59:41 -0800
Message-Id: <947EEF6D-12E5-4D6E-A92E-16184AE7119B@xmlgrrl.com>
References: <20121127184401.20364.27482.idtracker@ietfa.amsl.com> 
To: "Richer, Justin P." 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 19:49:33 -0000

--Apple-Mail=_6E56121F-CF55-45DD-998C-4B7867AED974
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Justin-- Glad to see this moving forward. This draft seems pretty =
straightforward, and I imagine the UMA core spec could probably =
incorporate a reference out to this rather than continuing to use our =
custom-specified method for what we'd called "token status". I wanted to =
highlight a couple of things we've defined beyond what you have here, in =
case they're of interest to the wider community.

This spec defines what I'd call "shallow AS/RS communication", in that =
it assumes a trust relationship and context that's set up between them =
completely out of band. UMA needed "deep AS/RS communication", which =
allows for them to live in separate domains, potentially run by =
disparate parties. (This is akin to the separation in OpenID Connect of =
IdPs and third-party claim providers, and I've heard of a number of use =
cases now for the same separation in plain OAuth.) Thus, we defined a =
means by which the AS and RS could be introduced -- it's actually just =
an embedded OAuth flow -- so that your mention of a "separate OAuth2 =
Access Token" option in Section 2.1 is dictated in UMA to be an OAuth =
token, with a particular scope covering the use of the token =
introspection endpoint.

The API exposed by the AS (in UMA, an "authorization manager" or AM) =
that includes usage of the token introspection endpoint is called a =
"protection API", and it includes registration of information about =
protected resources so that the AS can manage the issuance of tokens =
that it will later be asked to introspect.

Finally, UMA has a simple extension point, called "UMA token profile", =
defined in its (JSON-encoded) AM config data that allows the content =
associated with the token to be standardized. Actually it dictates more =
than the content; there are protocol aspects to it too, perhaps akin to =
OAuth's token profiles.

If there's interest in sedimenting some of these pieces into the OAuth =
layer, we'd certainly be interested to carve out modules (where =
possible) and submit them for consideration. Note that all of these =
features are present in our =
http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission.

Thanks,

	Eve

On 27 Nov 2012, at 10:46 AM, "Richer, Justin P."  =
wrote:

> I took some time this morning to put together a draft of Token =
Introspection. This is largely based on how we implemented it here a few =
years ago, and I'm hoping that this and the Ping draft can help move the =
conversation about introspection forward.
>=20
>  -- Justin
>=20
> Begin forwarded message:
>=20
>> From: 
>> Subject: New Version Notification for =
draft-richer-oauth-introspection-00.txt
>> Date: November 27, 2012 1:44:01 PM EST
>> To: 
>>=20
>>=20
>> A new version of I-D, draft-richer-oauth-introspection-00.txt
>> has been successfully submitted by Justin Richer and posted to the
>> IETF repository.
>>=20
>> Filename: draft-richer-oauth-introspection
>> Revision: 00
>> Title: OAuth Token Introspection
>> Creation date: 2012-11-27
>> WG ID: Individual Submission
>> Number of pages: 6
>> URL:             =
http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.tx=
t
>> Status:          =
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>> Htmlized:        =
http://tools.ietf.org/html/draft-richer-oauth-introspection-00
>>=20
>>=20
>> Abstract:
>>   This specification defines a method for a client or protected
>>   resource to query an OAuth authorization server to determine meta-
>>   information about an OAuth token.
>>=20
>>=20
>>=20
>>=20
>>=20
>> The IETF Secretariat
>>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl



--Apple-Mail=_6E56121F-CF55-45DD-998C-4B7867AED974
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

UMA =
core spec could probably incorporate a reference out to this =
rather than continuing to use our custom-specified method for what we'd =
called "token status". I wanted to highlight a couple of things we've =
defined beyond what you have here, in case they're of interest to the =
wider community.

This spec defines what I'd =
call "shallow AS/RS communication", in that it assumes a trust =
relationship and context that's set up between them completely out of =
band. UMA needed "deep AS/RS communication", which allows for them to =
live in separate domains, potentially run by disparate parties. (This is =
akin to the separation in OpenID Connect of IdPs and third-party claim =
providers, and I've heard of a number of use cases now for the same =
separation in plain OAuth.) Thus, we defined a means by which the AS and =
RS could be introduced -- it's actually just an embedded OAuth flow -- =
so that your mention of a "separate =
OAuth2 Access Token" option in Section 2.1 is dictated in UMA to =
be an OAuth token, with a particular scope covering the use of the token =
introspection endpoint.

The API exposed by the =
AS (in UMA, an "authorization manager" or AM) that includes usage of the =
token introspection endpoint is called a "protection API", and it =
includes registration of information about protected resources so that =
the AS can manage the issuance of tokens that it will later be asked to =
introspect.

Finally, UMA has a simple extension =
point, called "UMA token profile", defined in its (JSON-encoded) AM =
config data that allows the content associated with the token to be =
standardized. Actually it dictates more than the content; there are =
protocol aspects to it too, perhaps akin to OAuth's token =
profiles.

If there's interest in sedimenting =
some of these pieces into the OAuth layer, we'd certainly be interested =
to carve out modules (where possible) and submit them for consideration. =
Note that all of these features are present in our http:/=
/tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission.<=
/div>

Thanks,

	=
Eve

On 27 Nov 2012, at 10:46 AM, "Richer, =
Justin P." <jricher@mitre.org> =
wrote:







I took some time this morning to put together a draft of Token =
Introspection. This is largely based on how we implemented it here a few =
years ago, and I'm hoping that this and the Ping draft can help move the =
conversation about introspection forward.






 -- Justin





Begin forwarded message:







From:
<internet-drafts@ietf.org><=
br>




Subject:
New Version Notification for =
draft-richer-oauth-introspection-00.txt





Date:
November 27, 2012 1:44:01 PM EST









A new version of I-D, draft-richer-oauth-introspection-00.txt

has been successfully submitted by Justin Richer and posted to the

IETF repository.



Filename: =
draft-richer-oauth-introspection

Revision: =
00

Title: =
OAuth Token Introspection

Creation date: =
2012-11-27

WG ID: =
Individual Submission

Number of pages: 6

URL: =
            http://www.ietf.org/internet-drafts/draft-richer-oauth-introspe=
ction-00.txt

Status:          =
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection

Htmlized:        ht=
tp://tools.ietf.org/html/draft-richer-oauth-introspection-00





Abstract:

  This specification defines a method for a client or =
protected

  resource to query an OAuth authorization server to determine =
meta-

  information about an OAuth token.











The IETF Secretariat
















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



Eve Maler       =
                    =
       http://www.xmlgrrl.com/blog
+1=
 425 345 6756                 =
        http://www.twitter.com/xmlgrrl=







=

--Apple-Mail=_6E56121F-CF55-45DD-998C-4B7867AED974--

From eve@xmlgrrl.com  Tue Dec  4 12:04:33 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B533321F8C96 for ; Tue,  4 Dec 2012 12:04:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.292
X-Spam-Level: 
X-Spam-Status: No, score=-1.292 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG9od1JDIkvh for ; Tue,  4 Dec 2012 12:04:32 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 53B8221F8C84 for ; Tue,  4 Dec 2012 12:04:32 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by greendome.promanage-inc.com (Postfix) with ESMTP id 06DEB35E62E; Fri, 30 Nov 2012 11:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from greendome.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1awpZByvbdJ; Fri, 30 Nov 2012 11:06:27 -0800 (PST)
Received: from [192.168.168.107] (unknown [192.168.168.107]) by greendome.promanage-inc.com (Postfix) with ESMTPSA id 921CA35E612; Fri, 30 Nov 2012 11:06:27 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_4E48FFA8-66D3-4D7C-8394-39723C18234B"
From: Eve Maler 
In-Reply-To: <50B8D71E.3010908@mitre.org>
Date: Fri, 30 Nov 2012 11:06:27 -0800
Message-Id: 
References: <20121127184401.20364.27482.idtracker@ietfa.amsl.com>  <947EEF6D-12E5-4D6E-A92E-16184AE7119B@xmlgrrl.com> <50B8D71E.3010908@mitre.org>
To: Justin Richer 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] New Version Notification for draft-richer-oauth-introspection-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 20:04:33 -0000

--Apple-Mail=_4E48FFA8-66D3-4D7C-8394-39723C18234B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

You're right that UMA bundles several things in the protection API =
(covered by the protection scope, whose keyword is actually the =
resolvable URI =
"http://docs.kantarainitiative.org/uma/scopes/prot.json"). One of those =
things is the use of the token status endpoint; the rest is the whole =
mechanism for outsourcing protection.  Maybe it makes sense for us to =
define "protection" as a superset scope that includes a smaller scope of =
"introspection", which would map to using the introspection endpoint =
being defined in your spec.  What do you think?

The permissions that get returned as the result of UMA-style =
introspection are actually part of the definition of the "bearer" UMA =
token profile. Other token contents could be profiled specifically for =
use with UMA, or we could perhaps also reuse OAuth token profiles. The =
wrapper being defined in your spec for totally generic token metadata =
seems like a good idea; the innards could be any number of things (with =
their own unique metadata), such as policy yes/no decisions, the claims =
gathered, etc. This topic is discussed in the latter part of this slide =
deck: =
http://kantarainitiative.org/confluence/download/attachments/17760302/UMA+=
and+XACML+2012-10-18.pdf

Thanks!

	Eve

On 30 Nov 2012, at 7:56 AM, Justin Richer  wrote:

> Hi Eve,
>=20
> Yes, you've got the right idea. In a lot of cases that we're dealing =
with, the relationship between the RS and AS is set up ahead of time. So =
the RS knows which AS to ask, and the AS knows how to deal with the =
different RS's it cares about. UMA gives you a nice dynamic way to =
introduce the two, but I think that the introduction should be a =
separate step from the query, since both parts are reusable =
independently.=20
>=20
> Correct me if I'm wrong, but UMA also has the whole API for returning =
permissions associated with a token, beyond just the simple =
current-status message, right? Even so, I think it makes sense to decide =
on what the core set of info that would come back from such a token =
introspection would be, and what it means. Different types of tokens =
(Bearer, MAC, HOK) are going to have different types of metadata =
associated with them, probably, but there are a few core pieces =
(expiration, scopes) that would be common and useful.
>=20
>  -- Justin
>=20
> On 11/29/2012 05:59 PM, Eve Maler wrote:
>> Hi Justin-- Glad to see this moving forward. This draft seems pretty =
straightforward, and I imagine the UMA core spec could probably =
incorporate a reference out to this rather than continuing to use our =
custom-specified method for what we'd called "token status". I wanted to =
highlight a couple of things we've defined beyond what you have here, in =
case they're of interest to the wider community.
>>=20
>> This spec defines what I'd call "shallow AS/RS communication", in =
that it assumes a trust relationship and context that's set up between =
them completely out of band. UMA needed "deep AS/RS communication", =
which allows for them to live in separate domains, potentially run by =
disparate parties. (This is akin to the separation in OpenID Connect of =
IdPs and third-party claim providers, and I've heard of a number of use =
cases now for the same separation in plain OAuth.) Thus, we defined a =
means by which the AS and RS could be introduced -- it's actually just =
an embedded OAuth flow -- so that your mention of a "separate OAuth2 =
Access Token" option in Section 2.1 is dictated in UMA to be an OAuth =
token, with a particular scope covering the use of the token =
introspection endpoint.
>>=20
>> The API exposed by the AS (in UMA, an "authorization manager" or AM) =
that includes usage of the token introspection endpoint is called a =
"protection API", and it includes registration of information about =
protected resources so that the AS can manage the issuance of tokens =
that it will later be asked to introspect.
>>=20
>> Finally, UMA has a simple extension point, called "UMA token =
profile", defined in its (JSON-encoded) AM config data that allows the =
content associated with the token to be standardized. Actually it =
dictates more than the content; there are protocol aspects to it too, =
perhaps akin to OAuth's token profiles.
>>=20
>> If there's interest in sedimenting some of these pieces into the =
OAuth layer, we'd certainly be interested to carve out modules (where =
possible) and submit them for consideration. Note that all of these =
features are present in our =
http://tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission.
>>=20
>> Thanks,
>>=20
>>  Eve
>>=20
>> On 27 Nov 2012, at 10:46 AM, "Richer, Justin P."  =
wrote:
>>=20
>>> I took some time this morning to put together a draft of Token =
Introspection. This is largely based on how we implemented it here a few =
years ago, and I'm hoping that this and the Ping draft can help move the =
conversation about introspection forward.
>>>=20
>>>  -- Justin
>>>=20
>>> Begin forwarded message:
>>>=20
>>>> From: 
>>>> Subject: New Version Notification for =
draft-richer-oauth-introspection-00.txt
>>>> Date: November 27, 2012 1:44:01 PM EST
>>>> To: 
>>>>=20
>>>>=20
>>>> A new version of I-D, draft-richer-oauth-introspection-00.txt
>>>> has been successfully submitted by Justin Richer and posted to the
>>>> IETF repository.
>>>>=20
>>>> Filename: draft-richer-oauth-introspection
>>>> Revision: 00
>>>> Title: OAuth Token Introspection
>>>> Creation date: 2012-11-27
>>>> WG ID: Individual Submission
>>>> Number of pages: 6
>>>> URL:             =
http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-00.tx=
t
>>>> Status:          =
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>> Htmlized:        =
http://tools.ietf.org/html/draft-richer-oauth-introspection-00
>>>>=20
>>>>=20
>>>> Abstract:
>>>>   This specification defines a method for a client or protected
>>>>   resource to query an OAuth authorization server to determine =
meta-
>>>>   information about an OAuth token.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> The IETF Secretariat
>>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> Eve Maler                                  =
http://www.xmlgrrl.com/blog
>> +1 425 345 6756                         =
http://www.twitter.com/xmlgrrl
>>=20
>>=20
>=20


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl



--Apple-Mail=_4E48FFA8-66D3-4D7C-8394-39723C18234B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

http://doc=
s.kantarainitiative.org/uma/scopes/prot.json"). One of those things =
is the use of the token status endpoint; the rest is the whole mechanism =
for outsourcing protection.  Maybe it makes sense for us to define =
"protection" as a superset scope that includes a smaller scope of =
"introspection", which would map to using the introspection endpoint =
being defined in your spec.  What do you =
think?

The permissions that get returned as the =
result of UMA-style introspection are actually part of the definition of =
the "bearer" UMA token profile. Other token contents could be profiled =
specifically for use with UMA, or we could perhaps also reuse OAuth =
token profiles. The wrapper being defined in your spec for totally =
generic token metadata seems like a good idea; the innards could be any =
number of things (with their own unique metadata), such as policy yes/no =
decisions, the claims gathered, etc. This topic is discussed in the =
latter part of this slide deck: http://kantarainitiative.org/co=
nfluence/download/attachments/17760302/UMA+and+XACML+2012-10-18.pdf
<=
div>
Thanks!

	=
Eve

On 30 Nov 2012, at 7:56 AM, Justin Richer =
<jricher@mitre.org> =
wrote:


 =20
   =20
 =20
  

    
Hi Eve,

      

      Yes, you've got the right idea. In a lot of cases that we're
      dealing with, the relationship between the RS and AS is set up
      ahead of time. So the RS knows which AS to ask, and the AS knows
      how to deal with the different RS's it cares about. UMA gives you
      a nice dynamic way to introduce the two, but I think that the
      introduction should be a separate step from the query, since both
      parts are reusable independently. 

      

      Correct me if I'm wrong, but UMA also has the whole API for
      returning permissions associated with a token, beyond just the
      simple current-status message, right? Even so, I think it makes
      sense to decide on what the core set of info that would come back
      from such a token introspection would be, and what it means.
      Different types of tokens (Bearer, MAC, HOK) are going to have
      different types of metadata associated with them, probably, but
      there are a few core pieces (expiration, scopes) that would be
      common and useful.

      

       -- Justin

      

      On 11/29/2012 05:59 PM, Eve Maler wrote:

    

    

     =20
      
Hi Justin-- Glad to see this moving forward. This draft seems
        pretty straightforward, and I imagine the UMA
          core spec could probably incorporate a reference out =
to
        this rather than continuing to use our custom-specified method
        for what we'd called "token status". I wanted to highlight a
        couple of things we've defined beyond what you have here, in
        case they're of interest to the wider community.

      


      

      
This spec defines what I'd call "shallow AS/RS
        communication", in that it assumes a trust relationship and
        context that's set up between them completely out of band. UMA
        needed "deep AS/RS communication", which allows for them to live
        in separate domains, potentially run by disparate parties. (This
        is akin to the separation in OpenID Connect of IdPs and
        third-party claim providers, and I've heard of a number of use
        cases now for the same separation in plain OAuth.) Thus, we
        defined a means by which the AS and RS could be introduced --
        it's actually just an embedded OAuth flow -- so that your
        mention of a "separate OAuth2
          Access Token" option in Section 2.1 is dictated in UMA
        to be an OAuth token, with a particular scope covering the use
        of the token introspection endpoint.

      


      

      
The API exposed by the AS (in UMA, an "authorization manager"
        or AM) that includes usage of the token introspection endpoint
        is called a "protection API", and it includes registration of
        information about protected resources so that the AS can manage
        the issuance of tokens that it will later be asked to
        introspect.

      


      

      
Finally, UMA has a simple extension point, called "UMA token
        profile", defined in its (JSON-encoded) AM config data that
        allows the content associated with the token to be standardized.
        Actually it dictates more than the content; there are protocol
        aspects to it too, perhaps akin to OAuth's token profiles.

      


      

      
If there's interest in sedimenting some of these pieces into
        the OAuth layer, we'd certainly be interested to carve out
        modules (where possible) and submit them for consideration. Note
        that all of these features are present in our http:/=
/tools.ietf.org/html/draft-hardjono-oauth-umacore-05 submission.<=
/div>
      


      

      
Thanks,

      


      

      
 =
Eve

      

      

        
On 27 Nov 2012, at 10:46 AM, "Richer, Justin P." <jricher@mitre.org>
          wrote:

        

        

          

            I took some time this morning to put together a draft of
            Token Introspection. This is largely based on how we
            implemented it here a few years ago, and I'm hoping that
            this and the Ping draft can help move the conversation about
            introspection forward.
            


            

            
 -- Justin

              


                
Begin forwarded message:

                

                

                  

                    From:
                      <internet-drafts@ietf.org><=
br>
                    

                  

                    Subject:
                      New Version Notification for
                        draft-richer-oauth-introspection-00.txt

                    

                  

                    Date:
                      November 27, 2012 1:44:01 PM
                      EST

                    

                  
                  

                  


                    A new version of I-D,
                    draft-richer-oauth-introspection-00.txt

                    has been successfully submitted by Justin Richer and
                    posted to the

                    IETF repository.

                    

                    Filename: draft-richer-oauth-introspection

                    Revision: 00

                    Title: OAuth
                    Token Introspection

                    Creation date: 2012-11-27

                    WG ID: Individual
                    Submission

                    Number of pages: 6

                    URL: =
            http://www.ietf.org/internet-drafts/draft-richer-oauth-introspe=
ction-00.txt

                    Status: =
         =
http://datatracker.ietf.org/doc/draft-richer-oauth-introspection

                    Htmlized: =
       ht=
tp://tools.ietf.org/html/draft-richer-oauth-introspection-00

                    

                    

                    Abstract:

                      This specification defines a method for =
a client
                    or protected

                      resource to query an OAuth authorization =
server to
                    determine meta-

                      information about an OAuth token.

                    

                    

                    

                    

                    

                    The IETF Secretariat

                    

                  

                

              

              

            

          

          _______________________________________________

          OAuth mailing list

          OAuth@ietf.org

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

        

      

      

      

        

            Eve Maler               =
                   http://www.xmlgrrl.com/blog

            +1 425 345 6756             =
            http://www.twitter.com/xmlgrrl=


            

          
      

      

    

    

  






Eve Maler       =
                    =
       http://www.xmlgrrl.com/blog
+1=
 425 345 6756                 =
        http://www.twitter.com/xmlgrrl=







=

--Apple-Mail=_4E48FFA8-66D3-4D7C-8394-39723C18234B--

From sberyozkin@gmail.com  Tue Dec  4 14:24:22 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F82E21F8AF8 for ; Tue,  4 Dec 2012 14:24:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvYUHNe-HBGC for ; Tue,  4 Dec 2012 14:24:21 -0800 (PST)
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 57C4721F8933 for ; Tue,  4 Dec 2012 14:24:21 -0800 (PST)
Received: by mail-wi0-f180.google.com with SMTP id hj13so962726wib.13 for ; Tue, 04 Dec 2012 14:24:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/unjm6GRjeM/bmU6YM8RqDLgz7LSlHB9Kbm1Io6RsE4=; b=sEV49vekRUdTPkMPn0KnhYXzoeh1V8+yvPxm6sX5qNcgRgZO6u9q20PnqQoWIprKB8 Bb8SbwK2fJM85Kvz2Txe7s19PXAyKlMpdsSv22QKsRx+ms5lAjWR5kB/CLHBVBVnfbUN LhH/Oc2nxpnBof+5RfcPlcqOhAaHJTph0cbkR3HDT5e3bnc1n0gIlgYf1ZUk1XS907oA nT70xxPgy4mDkgYmNJsasT9EW13RLQA0adDccAEZGeFDBfTrQufhYr85BPfsV+Sy6NsW FM1gEJSTUZYHzMwfje7F9VgzULxby+oDRcjG99Yoq479gtoN/rk0h4bz2NH3ulWBay5Z l4MQ==
Received: by 10.216.209.145 with SMTP id s17mr5693335weo.144.1354659860471; Tue, 04 Dec 2012 14:24:20 -0800 (PST)
Received: from [192.168.2.5] ([89.100.139.130]) by mx.google.com with ESMTPS id dm3sm16806503wib.9.2012.12.04.14.24.18 (version=SSLv3 cipher=OTHER); Tue, 04 Dec 2012 14:24:19 -0800 (PST)
Message-ID: <50BE7811.7050503@gmail.com>
Date: Tue, 04 Dec 2012 22:24:17 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] Redirection flows, pre-authorized tokens and client-requested scopes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 04 Dec 2012 22:24:22 -0000

We are working with one of our users on the support for pre-authorized 
tokens which can be checked by AS at the initial end user redirection to 
this AS before requesting the end-user authorization.

My assumption is that if the pre-authorized token exists then the client 
provided scope, if any, is basically ignored, because the end user has 
already pre-authorized a given client with a specific token which will 
have a scope set as requested by the end user at the pre-authorization time.

Is that right ? IMHO yes and the best AS can do in this case is simply 
log what scope the client is actually requesting but reply with the 
token containing the pre-authorized scope, please correct me if not

thanks, Sergey



From zhou.sujing@zte.com.cn  Tue Dec  4 16:39:47 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A266F21F8A84 for ; Tue,  4 Dec 2012 16:39:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.197
X-Spam-Level: 
X-Spam-Status: No, score=-100.197 tagged_above=-999 required=5 tests=[AWL=2.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZYYSPZ01rS3 for ; Tue,  4 Dec 2012 16:39:35 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 202E521F8AA6 for ; Tue,  4 Dec 2012 16:39:34 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4E9AA17A308A for ; Wed,  5 Dec 2012 08:39:26 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id A29C11939D22; Wed,  5 Dec 2012 08:37:40 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB50dJV3075829; Wed, 5 Dec 2012 08:39:19 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Brian Campbell 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Wed, 5 Dec 2012 08:39:11 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-05 08:39:15, Serialize complete at 2012-12-05 08:39:15
Content-Type: multipart/alternative; boundary="=_alternative 0003B61448257ACB_="
X-MAIL: mse01.zte.com.cn qB50dJV3075829
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 00:39:47 -0000

This is a multipart message in MIME format.
--=_alternative 0003B61448257ACB_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

V2h5IFJPIGFzIGFuIGlzc3VlciBpcyBvbmx5IHRoZW9yZXRpY2FsIHRvZGF5Pw0KDQoNCg0KQnJp
YW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPiANCjIwMTItMTItMDQgMjM6
NDENCg0K5pS25Lu25Lq6DQpOYXQgU2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4NCuaKhOmA
gQ0KemhvdS5zdWppbmdAenRlLmNvbS5jbiwgIm9hdXRoQGlldGYub3JnIiA8b2F1dGhAaWV0Zi5v
cmc+DQrkuLvpopgNClJlOiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9l
cyBpc3N1ZXIgaGF2ZSB0byBiZSBlaXRoZXIgdGhlIA0KY2xpZW50IG9yIGEgdGhpcmQgcGFydHkg
dG9rZW4gc2VydmljZT8NCg0KDQoNCg0KDQoNClRoZSBpbnRlbnQgd2FzIGRlZmluaXRlbHkgbm90
IHRvIGNvbnN0cmFpbiB3aG8vd2hhdCBjb3VsZCBiZSB0aGUgaXNzdWVyLiANCkJ1dCBhbHNvIHRy
eSB0byBwcm92aWRlIA0Kc29tZSBndWlkYW5jZSBhcm91bmQgdGhlIGNvbW1vbiBjYXNlcyB0aGF0
IGFyZSBhY3R1YWxseSBiZWluZyBkZXBsb3llZCANCm5vdywgd2hpY2ggYXJlIHRoZSBjbGllbnQg
c2VsZi1pc3N1ZWQgYW5kIFNUUyB2YXJpYW50cy4gUmVzb3VyY2Ugb3duZXIgYXMgDQphbiBpc3N1
ZXIgaXMgYW4gaW50ZXJlc3RpbmcgY2FzZSBidXQgc2VlbXMgbW9zdGx5IHRoZW9yZXRpY2FsIGF0
IHRoaXMgDQpwb2ludC4NCg0KSSBmZWVsIGxpa2UgbWVudGlvbmluZyB0aGUgcmVzb3VyY2Ugb3du
ZXIgdGhlcmUgaW4gwqc1LjEgd291bGQgY2F1c2UgbW9yZSANCmNvbmZ1c2lvbiB0aGFuIGFueXRo
aW5nIGVsc2UuIEknZCBwcmVmZXIgdG8ganVzdCBzdHJpa2UgdGhlIHdob2xlIHNlbnRlbmNlIA0K
aW4gcXVlc3Rpb24gYW5kIG1heWJlIGFkZCBzb21lIGFkZGl0aW9uYWwgdGV4dCB0byDCpzMgdGhh
dCBjbGFyaWZpZXMgdGhhdCANCnRoZSBpc3N1ZXIgY2FuIHJlYWxseSBiZSBhbnkgZW50aXR5LCBp
ZiBmb2xrcyB0aGluayBhIGNoYW5nZSBpcyBuZWVkZWQgDQpoZXJlPyANCg0KDQoNCk9uIE1vbiwg
RGVjIDMsIDIwMTIgYXQgOToyMCBQTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+
IHdyb3RlOg0KQWN0dWFsbHksICJUaGUgaXNzdWVyIG1heSBiZSBlaXRoZXIgDQogICAgICBhbiBP
QXV0aCBjbGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9yIGFueSBvdGhl
ciANCmVudGl0eSwgZS5nLiwgIGEgdGhpcmQgcGFydHkgDQp0b2tlbiBzZXJ2aWNlLCByZXNvdXJj
ZSBvd25lci4gIiAgaXMgbm90IHJlYWxseSBjbGVhbi4gDQoNCk9BdXRoIGNsaWVudCBpcyBqdXN0
IGFub3RoZXIgZXhhbXBsZSBvZiBhbiBpc3N1ZXIuIA0KDQpTbywgcGVyaGFwcyB0aGUgc2VudGVu
Y2UgY291bGQgYmU6IA0KDQoiRXhhbXBsZSBvZiBpc3N1ZXJzIGluY2x1ZGUgYW4gT0F1dGggY2xp
ZW50LCByZXNvdXJjZSBvd25lciwgYW4gDQppbmRlcGVuZGVudCB0aGlyZCBwYXJ0eS4iDQoNClNv
LCB0aGUgY2xhdXNlIGJlY29tZXM6IA0KDQogSXNzdWVyICBUaGUgdW5pcXVlIGlkZW50aWZpZXIg
Zm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhlIA0KICAgICAgYXNzZXJ0aW9uLiAgR2VuZXJh
bGx5IHRoaXMgaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSBrZXkgDQogICAgICBtYXRlcmlh
bCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uIA0KICAgICAgRXhhbXBsZSBvZiBpc3N1
ZXJzIGluY2x1ZGUgYW4gT0F1dGggY2xpZW50LCByZXNvdXJjZSBvd25lciwgYW4gDQppbmRlcGVu
ZGVudCB0aGlyZCBwYXJ0eS4gDQoNCk5hdA0KDQpOYXQNCg0KT24gVHVlLCBEZWMgNCwgMjAxMiBh
dCAxMTo0MCBBTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IHdyb3RlOg0KDQoNCg0KQ2h1Y2sg
TW9ydGltb3JlIDxjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPiDlhpnkuo4gMjAxMi0xMi0wNCAx
MDoyNjo1MDoNCg0KDQo+IFBsZWFzZSBmZWVsIGZyZWUgdG8gc3VnZ2VzdCBiZXR0ZXIgbGFuZ3Vh
Z2UuDQoNCj4gDQo+IElzc3VlciBzaW1wbHkgYWxsb3dzIHRoZSB0b2tlbiBzZXJ2aWNlIHRvIGtu
b3cgd2hvIGNyZWF0ZWQgdGhlIA0KPiBhc3NlcnRpb24sIHNvIGl0IGNhbiBsb29rIHRoZW0gdXAg
YW5kIHNlZSBpZiB0aGV5J3JlIHRydXN0ZWQuIA0KPiBFZmZlY3RpdmVseSB0aGUgc2FtZSBhcyBh
biBJc3N1ZXIgaW4gU0FNTC4gDQoNCmEgY29uZmxpY3QgOiAiVGhlIHRva2VuIHNlcnZpY2UgaXMg
dGhlIGFzc2VydGlvbiBpc3N1ZXIiIGluIGFzc2VydGlvbiANCmRvY3VtZW50LiANCndoaWxlIHlv
dSBzYWlkICJ0b2tlbiBzZXJ2aWNlIGtub3cgd2hvIGNyZWF0ZWQgdGhlIGFzc2VydGlvbiIgDQoN
Ckkgd29uZGVyIGlmIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBhY2NlcHRhYmxlOiANCiAgDQogIElz
c3VlciAgVGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVkIHRo
ZSANCiAgICAgIGFzc2VydGlvbi4gIEdlbmVyYWxseSB0aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBo
b2xkcyB0aGUga2V5IA0KICAgICAgbWF0ZXJpYWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNzZXJ0
aW9uLiAgVGhlIGlzc3VlciBtYXkgYmUgZWl0aGVyIA0KICAgICAgYW4gT0F1dGggY2xpZW50ICh3
aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYtaXNzdWVkKSBvciBhbnkgb3RoZXIgDQplbnRpdHksIGUu
Zy4sICBhIHRoaXJkIHBhcnR5IA0KdG9rZW4gc2VydmljZSwgcmVzb3VyY2Ugb3duZXIuIA0KDQoN
CjYuMy4gIENsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGEgVXNlciANCg0KVGhlIElzc3VlciBv
ZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCANCiAg
ICAgIHRoZSBhc3NlcnRpb24gYXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2
ZXIuICBJZiB0aGUgDQogICAgICBhc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRoZSBJc3N1ZXIg
U0hPVUxEIGJlIHRoZSAiY2xpZW50X2lkIi4gDQogICAgICBJZiB0aGUgYXNzZXJ0aW9uIHdhcyBp
c3N1ZWQgYnkgYSBTZWN1cml0eSBUb2tlbiBTZXJ2aWNlIChTVFMpLCB0aGUgDQogICAgICBJc3N1
ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSBTVFMgYXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXph
dGlvbiANCiAgICAgIFNlcnZlci5JZiB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkgdGhlIHJl
c291cmNlIG93bmVyLCB0aGUgDQogICAgICBJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSByZXNv
dXJjZSBvd25lciBhcyByZWNvZ25pemVkIGJ5IHRoZSANCkF1dGhvcml6YXRpb24gDQogICAgICBT
ZXJ2ZXIuIA0KDQo+IA0KPiAtY21vcnQgDQo+IA0KPiBPbiBEZWMgMywgMjAxMiwgYXQgNjoyMyBQ
TSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IHdyb3RlOiANCj4gDQo+IA0KPiBPYnZpb3VzbHks
IGl0IGlzIG5vdCBzbyBjbGVhciBmcm9tIHRoZSBsYW5ndWFnZSB0aGVyZS4gDQo+IA0KPiANCj4g
Q2h1Y2sgTW9ydGltb3JlIDxjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPiDlhpnkuo4gMjAxMi0x
Mi0wNCAxMDoxNzoxMjoNCj4gDQo+ID4gVGhlcmUncyBubyByZWFzb24gd2h5IGl0IGNhbid0IGJl
IHJlc291cmNlIG93bmVyIHRvZGF5LiANCj4gPiANCj4gPiBPbiBEZWMgMywgMjAxMiwgYXQgNjow
NiBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IDwNCnpob3Uuc3VqaW5nQHp0ZS5jb20uY24N
Cj4gPiA+IHdyb3RlOiANCj4gPiANCj4gPiANCj4gPiArMS4gDQo+ID4gQW5kIHdoeSBpdCB3YXMg
bm90IGxvb2tlZCBhdCB0aGF0IHRpbWU/IA0KPiA+IA0KPiA+IG9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmcg5YaZ5LqOIDIwMTItMTItMDQgMDE6MzA6NTU6DQo+ID4gDQo+ID4gPiBBY3R1YWxseSwgSSB0
aGluayBpdCBpcyBhIGdvb2QgdGltZSB0byBzdGFydCBsb29raW5nIGF0IHRoZSByZXNvdXJzZQ0K
PiA+ID4gb3duZXIgaXNzdWluZyBhc3NlcnRpb25zQCAoSW50ZXJlc3RpbmdseSBlbm91Z2gsIEh1
aS1MYW4gaGFkIGJyb3VnaHQNCj4gPiA+IHRoaXMgdXAgYSBjb3VwbGUgb2YgeWVhcnMgYWdvLikN
Cj4gPiA+IA0KPiA+ID4gSWdvcg0KPiA+ID4gDQo+ID4gPiBPbiAxMi8zLzIwMTIgMzo1OCBBTSwg
TmF0IFNha2ltdXJhIHdyb3RlOiANCj4gPiA+IEkgc3VwcG9zZSwgeWVzLiBJIHdhcyByZWFkaW5n
IGl0IGxpa2UgdGhhdCBhbGwgdGhlIHRpbWUuIA0KPiA+ID4gV2hldGhlciBpdCBpcyBvciBub3Qs
IGlmIGl0IGlzIHN0aWxsIG9rLCBpdCBtaWdodCBiZSBiZXR0ZXIgdG8gDQo+IGNsYXJpZnkgaXQu
IA0KPiA+ID4gV29yZCBsaWtlICJ0aGlyZCBwYXJ0eSIgdGVuZHMgdG8gYmUgYSBiaXQgb2YgcHJv
YmxlbSB3aXRob3V0IA0KPiA+IGNsZWFybHlkZWZpbmluZy4gDQo+ID4gPiBJIGhhZCBzaW1pbGFy
IGV4cGVyaWVuY2UgaW4gb3RoZXIgZm9yYS4gDQo+ID4gPiANCj4gPiA+IE5hdCANCj4gPiA+IA0K
PiA+ID4gU2VudCBmcm9tIGlQYWQgDQo+ID4gPiANCj4gPiA+IDIwMTIvMTIvMDMgMDo1MuOAgSJ6
aG91LnN1amluZ0B6dGUuY29tLmNuIiA8emhvdS5zdWppbmdAenRlLmNvbS5jbj4gDQrjga4NCj4g
PiA+IOODoeODg+OCu+ODvOOCuDoNCj4gPiANCj4gPiA+IA0KPiA+ID4gY291bGQgYmUgUmVzb3Vy
Y2Ugb3duZXI/IA0KPiA+ID4gDQo+ID4gDQo+ID4gPiANCj4gPiA+ICJUc2Nob2ZlbmlnLCBIYW5u
ZXMgKE5TTiAtIEZJL0VzcG9vKSIgPGhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20+IA0KPiA+ID4g
5Y+R5Lu25Lq6OiAgb2F1dGgtYm91bmNlc0BpZXRmLm9yZyANCj4gPiA+IDIwMTItMTItMDMgMTY6
NDkgDQo+ID4gPiANCj4gPiA+IOaUtuS7tuS6uiANCj4gPiA+IA0KPiA+ID4gImV4dCBOYXQgU2Fr
aW11cmEiIDxzYWtpbXVyYUBnbWFpbC5jb20+LCAiQnJpYW4gQ2FtcGJlbGwiIDwNCj4gPiA+IGJj
YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPiwgIm9hdXRoIiA8b2F1dGhAaWV0Zi5vcmc+IA0KPiA+
ID4gDQo+ID4gPiDmioTpgIEgDQo+ID4gPiANCj4gPiA+IOS4u+mimCANCj4gPiA+IA0KPiA+ID4g
UmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZl
IHRvIGJlIA0KPiA+ID4gZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBz
ZXJ2aWNlPyANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gSGkgTmF0LCAN
Cj4gPiA+IA0KPiA+ID4gVGhlIGN1cnJlbnQgdGV4dCBlc3NlbnRpYWxseSBzYXlzIHRoYXQgdGhl
IGFzc2VydGlvbiBjYW4gZWl0aGVyIGJlIA0KPiA+ID4gY3JlYXRlZCBieSB0aGUgY2xpZW50IChp
biB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2lnbmVkKSBvciBpdCBjYW4gYmUNCj4gPiA+IGNyZWF0
ZWQgYnkgc29tZSBvdGhlciBlbnRpdHkgKHdoaWNoIGlzIHRoZW4gY2FsbGVkIHRoZSB0aGlyZCBw
YXJ0eSANCj4gPiA+IHRva2VuIHNlcnZpY2UpLiBTbywgdGhpcyB0aGlyZCBwYXJ0eSBjb3VsZCBi
ZSB0aGUgYXV0aG9yaXphdGlvbiANCnNlcnZlci4gDQo+ID4gPiANCj4gPiA+IENpYW8NCj4gPiA+
IEhhbm5lcyANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYu
b3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gT24gDQpCZWhhbGYgT2YgDQo+ID4g
PiBleHQgTmF0IFNha2ltdXJhDQo+ID4gPiBTZW50OiBNb25kYXksIERlY2VtYmVyIDAzLCAyMDEy
IDEwOjM1IEFNDQo+ID4gPiBUbzogQnJpYW4gQ2FtcGJlbGw7IG9hdXRoDQo+ID4gPiBTdWJqZWN0
OiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0
byBiZQ0KPiA+ID4gZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2
aWNlPyANCj4gPiA+IA0KPiA+ID4gSGkgQnJpYW4sIA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IFRo
ZSBhc3NlcnRpb24gZnJhbWV3b3JrIGRlZmluZXMgdGhlIElzc3VlciBhczogDQo+ID4gPiANCj4g
PiA+ICAgIElzc3VlciAgVGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQg
aXNzdWVkIHRoZSANCj4gPiA+ICAgICAgIGFzc2VydGlvbi4gIEdlbmVyYWxseSB0aGlzIGlzIHRo
ZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUga2V5IA0KPiA+ID4gICAgICAgbWF0ZXJpYWwgdXNlZCB0
byBnZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLiAgVGhlIGlzc3VlciBtYXkgYmUgDQplaXRoZXIgDQo+
ID4gPiAgICAgICBhbiBPQXV0aCBjbGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1
ZWQpIG9yIGEgdGhpcmQgDQpwYXJ0eSANCj4gPiA+ICAgICAgIHRva2VuIHNlcnZpY2UuIA0KPiA+
ID4gDQo+ID4gPiBJIHdhcyB3b25kZXJpbmcgd2h5IGl0IGhhcyB0byBiZSBlaXRoZXIgdGhlIGNs
aWVudCBvciBhIHRoaXJkIHBhcnR5IA0KPiA+ID4gdG9rZW4gc2VydmljZS4gDQo+ID4gPiBDb25j
ZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBzZXJ2aWNlIChmdW5jdGlvbmFsaXR5KSAN
Cj4gPiByZXNpZGluZ2luIGFueSBvZiANCj4gPiA+IA0KPiA+ID4gdGhlIHN0YWtlaG9sZGVycyAo
UmVzb3VyY2UgT3duZXIsIE9BdXRoIENsaWVudCwgQXV0aG9yaXphdGlvbiANClNlcnZlciwgb3Ig
DQo+ID4gPiBhIHRoaXJkIHBhcnR5KS4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gSSB3b3VsZCBh
cHByZWNpYXRlIGlmIHlvdSBjb3VsZCBjbGFyaWZ5IHdoeSBpcyB0aGUgY2FzZS4gDQo+ID4gPiAN
Cj4gPiA+IA0KPiA+ID4gQmVzdCwgDQo+ID4gPiANCj4gPiA+IC0tIA0KPiA+ID4gTmF0IFNha2lt
dXJhICg9bmF0KSANCj4gPiA+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPiA+ID4gaHR0
cDovL25hdC5zYWtpbXVyYS5vcmcvDQo+ID4gPiBAX25hdF9lbiANCj4gPiA+ICBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBPQXV0aCBt
YWlsaW5nIGxpc3QNCj4gPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4g
PiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIA0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0
DQpPQXV0aEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aA0KDQoNCg0KDQotLSANCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQg
Rm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoDQoNCg0KDQo=
--=_alternative 0003B61448257ACB_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoeSBSTyBhcyBhbiBpc3N1ZXIg
aXMgb25seSB0aGVvcmV0aWNhbA0KdG9kYXk/PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRh
YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNiU+PGZvbnQgc2l6
ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxAcGlu
Z2lkZW50aXR5LmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+MjAxMi0xMi0wNCAyMzo0MTwvZm9udD4NCjx0ZCB3aWR0aD02MyU+DQo8dGFibGUg
d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+5pS25Lu25Lq6PC9mb250PjwvZGl2Pg0KPHRkPjxm
b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5OYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdt
YWlsLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln
aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPuaKhOmAgTwvZm9udD48L2Rpdj4NCjx0
ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+emhvdS5zdWppbmdAenRlLmNvbS5jbiwg
JnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsNCiZsdDtvYXV0aEBpZXRmLm9yZyZndDs8L2ZvbnQ+
DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh
Y2U9InNhbnMtc2VyaWYiPuS4u+mimDwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj
ZT0ic2Fucy1zZXJpZiI+UmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtDQpXaHkg
ZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZSBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5
IHRva2VuIHNlcnZpY2U/PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWdu
PXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+
PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPlRoZSBpbnRlbnQgd2FzIGRlZmluaXRlbHkg
bm90IHRvIGNvbnN0cmFpbg0Kd2hvL3doYXQgY291bGQgYmUgdGhlIGlzc3Vlci4gJm5ic3A7QnV0
IGFsc28gdHJ5IHRvIHByb3ZpZGUgPGJyPg0Kc29tZSBndWlkYW5jZSBhcm91bmQgdGhlIGNvbW1v
biBjYXNlcyB0aGF0IGFyZSBhY3R1YWxseSBiZWluZyBkZXBsb3llZA0Kbm93LCB3aGljaCBhcmUg
dGhlIGNsaWVudCBzZWxmLWlzc3VlZCBhbmQgU1RTIHZhcmlhbnRzLiBSZXNvdXJjZSBvd25lcg0K
YXMgYW4gaXNzdWVyIGlzIGFuIGludGVyZXN0aW5nIGNhc2UgYnV0IHNlZW1zIG1vc3RseSB0aGVv
cmV0aWNhbCBhdCB0aGlzDQpwb2ludC48YnI+DQo8YnI+DQpJIGZlZWwgbGlrZSBtZW50aW9uaW5n
IHRoZSByZXNvdXJjZSBvd25lciB0aGVyZSBpbiDCpzUuMSB3b3VsZCBjYXVzZSBtb3JlDQpjb25m
dXNpb24gdGhhbiBhbnl0aGluZyBlbHNlLiBJJ2QgcHJlZmVyIHRvIGp1c3Qgc3RyaWtlIHRoZSB3
aG9sZSBzZW50ZW5jZQ0KaW4gcXVlc3Rpb24gYW5kIG1heWJlIGFkZCBzb21lIGFkZGl0aW9uYWwg
dGV4dCB0byDCpzMgdGhhdCBjbGFyaWZpZXMgdGhhdA0KdGhlIGlzc3VlciBjYW4gcmVhbGx5IGJl
IGFueSBlbnRpdHksIGlmIGZvbGtzIHRoaW5rIGEgY2hhbmdlIGlzIG5lZWRlZA0KaGVyZT8gPGJy
Pg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPk9uIE1vbiwgRGVjIDMsIDIw
MTIgYXQgOToyMCBQTSwgTmF0DQpTYWtpbXVyYSAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnNh
a2ltdXJhQGdtYWlsLmNvbSB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZh
Y2U9InNhbnMtc2VyaWYiPjx1PnNha2ltdXJhQGdtYWlsLmNvbTwvdT48L2ZvbnQ+PC9hPjxmb250
IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkFjdHVhbGx5LCAmcXVvdDs8L2ZvbnQ+PGZvbnQgc2l6
ZT0zIGNvbG9yPSM1MDAwNTAgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaGUNCmlzc3VlciBtYXkg
YmUgZWl0aGVyPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jNTAwMDUwIGZhY2U9IkFyaWFsIj4g
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jMjIyMjIyIGZhY2U9IlRpbWVzIE5ldyBS
b21hbiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsNCmFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRp
b25zIGFyZSBzZWxmLWlzc3VlZCkgb3I8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPXJlZCBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPg0KYW55IG90aGVyIGVudGl0eSwgZS5nLiwgJm5ic3A7PC9mb250
Pjxmb250IHNpemU9MyBjb2xvcj0jMjIyMjIyIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+YQ0KdGhp
cmQgcGFydHkgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jMjIyMjIyIGZhY2U9IkFy
aWFsIj50b2tlbiBzZXJ2aWNlPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1yZWQgZmFjZT0iQXJp
YWwiPiwNCnJlc291cmNlIG93bmVyPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj0jMjIyMjIyIGZh
Y2U9IkFyaWFsIj4uICZxdW90OyAmbmJzcDtpcw0Kbm90IHJlYWxseSBjbGVhbi4gPC9mb250Pg0K
PGJyPg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFsIj5PQXV0aCBj
bGllbnQgaXMganVzdCBhbm90aGVyDQpleGFtcGxlIG9mIGFuIGlzc3Vlci4gPC9mb250Pg0KPGJy
Pg0KPGJyPjxmb250IHNpemU9MyBjb2xvcj0jMjIyMjIyIGZhY2U9IkFyaWFsIj5TbywgcGVyaGFw
cyB0aGUgc2VudGVuY2UgY291bGQNCmJlOiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z
IGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPiZxdW90O0V4YW1wbGUgb2YgaXNzdWVycyBpbmNs
dWRlDQphbiBPQXV0aCBjbGllbnQsIHJlc291cmNlIG93bmVyLCBhbiBpbmRlcGVuZGVudCB0aGly
ZCBwYXJ0eS4mcXVvdDs8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGNvbG9yPSMyMjIy
MjIgZmFjZT0iQXJpYWwiPlNvLCB0aGUgY2xhdXNlIGJlY29tZXM6IDwvZm9udD4NCjxicj4NCjxi
cj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDtJc3N1ZXIgJm5ic3A7
VGhlIHVuaXF1ZSBpZGVudGlmaWVyDQpmb3IgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGU8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7YXNzZXJ0aW9u
LiAmbmJzcDtHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5IHRoYXQNCmhvbGRzIHRoZSBrZXk8
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7bWF0ZXJp
YWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRXhh
bXBsZSBvZg0KaXNzdWVycyBpbmNsdWRlIGFuIE9BdXRoIGNsaWVudCwgcmVzb3VyY2Ugb3duZXIs
IGFuIGluZGVwZW5kZW50IHRoaXJkIHBhcnR5Lg0KPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp
emU9MyBmYWNlPSJzYW5zLXNlcmlmIj5OYXQ8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0z
IGNvbG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPk5hdDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz
aXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+T24gVHVlLCBEZWMgNCwgMjAxMiBhdCAxMTo0MCBBTSwg
Jmx0OzwvZm9udD48YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIHRhcmdldD1f
Ymxhbms+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+emhvdS5z
dWppbmdAenRlLmNvbS5jbjwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl
cmlmIj4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy
aWYiPjxicj4NCjxicj4NCjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0zPjxicj4NCkNodWNrIE1vcnRp
bW9yZSAmbHQ7PC9mb250PjwvdHQ+PGEgaHJlZj1tYWlsdG86Y21vcnRpbW9yZUBzYWxlc2ZvcmNl
LmNvbSB0YXJnZXQ9X2JsYW5rPjx0dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5jbW9ydGlt
b3JlQHNhbGVzZm9yY2UuY29tPC91PjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0zPiZn
dDsNCuWGmeS6jiAyMDEyLTEyLTA0IDEwOjI2OjUwOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTM+PGJyPg0KPGJyPg0KJmd0OyBQbGVhc2UgZmVlbCBmcmVlIHRvIHN1Z2dlc3QgYmV0
dGVyIGxhbmd1YWdlLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTM+Jmd0
OyA8YnI+DQomZ3Q7IElzc3VlciBzaW1wbHkgYWxsb3dzIHRoZSB0b2tlbiBzZXJ2aWNlIHRvIGtu
b3cgd2hvIGNyZWF0ZWQgdGhlIDxicj4NCiZndDsgYXNzZXJ0aW9uLCBzbyBpdCBjYW4gbG9vayB0
aGVtIHVwIGFuZCBzZWUgaWYgdGhleSdyZSB0cnVzdGVkLiAmbmJzcDsNCiZuYnNwOyA8YnI+DQom
Z3Q7IEVmZmVjdGl2ZWx5IHRoZSBzYW1lIGFzIGFuIElzc3VlciBpbiBTQU1MLjwvZm9udD48L3R0
Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0zPmEgY29uZmxpY3QgOiAmcXVvdDtUaGUgdG9rZW4gc2VydmljZSBpcyB0aGUg
YXNzZXJ0aW9uDQppc3N1ZXImcXVvdDsgaW4gYXNzZXJ0aW9uIGRvY3VtZW50LjwvZm9udD48L3R0
Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0z
Pjxicj4NCndoaWxlIHlvdSBzYWlkICZxdW90O3Rva2VuIHNlcnZpY2Uga25vdyB3aG8gY3JlYXRl
ZCB0aGUgYXNzZXJ0aW9uJnF1b3Q7PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt
c2VyaWYiPg0KPGJyPg0KPC9mb250Pjx0dD48Zm9udCBzaXplPTM+PGJyPg0KSSB3b25kZXIgaWYg
dGhlIGZvbGxvd2luZyB0ZXh0IGlzIGFjY2VwdGFibGU6PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0z
IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPGJyPjx0dD48Zm9udCBzaXplPTM+Jm5ic3A7
PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiAmbmJzcDtJc3N1ZXIgJm5ic3A7
VGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVkIHRoZTwvZm9u
dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7YXNzZXJ0aW9u
LiAmbmJzcDtHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5IHRoYXQNCmhvbGRzIHRoZSBrZXk8
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7bWF0ZXJp
YWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLiAmbmJzcDtUaGUNCmlzc3VlciBtYXkg
YmUgZWl0aGVyPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pg0K
PGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyAmbmJzcDsgJm5i
c3A7IGFuIE9BdXRoIGNsaWVudA0KKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9y
PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1yZWQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCmFu
eSBvdGhlciBlbnRpdHksIGUuZy4sICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGlt
ZXMgTmV3IFJvbWFuIj5hDQp0aGlyZCBwYXJ0eSA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh
bnMtc2VyaWYiPjxicj4NCnRva2VuIHNlcnZpY2U8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPXJl
ZCBmYWNlPSJzYW5zLXNlcmlmIj4sIHJlc291cmNlDQpvd25lcjwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0ic2Fucy1zZXJpZiI+LiA8YnI+DQo8YnI+DQo8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mz48
YnI+DQo2LjMuICZuYnNwO0NsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGEgVXNlcjwvZm9udD48
L3R0Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4NCjwvZm9udD48dHQ+PGZv
bnQgc2l6ZT0zPjxicj4NClRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbiBNVVNUIGlkZW50aWZ5
IHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQ8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTMgZmFjZT0ic2Fu
cy1zZXJpZiI+DQo8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mz48YnI+DQogJm5ic3A7ICZuYnNwOyAm
bmJzcDt0aGUgYXNzZXJ0aW9uIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2Vy
dmVyLg0KJm5ic3A7SWYgdGhlPC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy
aWYiPiA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mz48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDth
c3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRoZSBJc3N1ZXIgU0hPVUxEIGJlIHRoZQ0KJnF1b3Q7
Y2xpZW50X2lkJnF1b3Q7LjwvZm9udD48L3R0Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm
Ij4gPC9mb250Pjx0dD48Zm9udCBzaXplPTM+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7SWYg
dGhlIGFzc2VydGlvbiB3YXMgaXNzdWVkIGJ5IGEgU2VjdXJpdHkgVG9rZW4gU2VydmljZQ0KKFNU
UyksIHRoZTwvZm9udD48L3R0Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250
Pjx0dD48Zm9udCBzaXplPTM+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7SXNzdWVyIFNIT1VM
RCBpZGVudGlmeSB0aGUgU1RTIGFzIHJlY29nbml6ZWQgYnkgdGhlDQpBdXRob3JpemF0aW9uPC9m
b250PjwvdHQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8L2ZvbnQ+PHR0Pjxmb250
IHNpemU9Mz48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDtTZXJ2ZXIuPC9mb250PjwvdHQ+PHR0
Pjxmb250IHNpemU9MyBjb2xvcj1yZWQ+SWYgdGhlDQphc3NlcnRpb24gd2FzIGlzc3VlZCBieSB0
aGUgcmVzb3VyY2Ugb3duZXIsIHRoZTwvZm9udD48L3R0Pjxmb250IHNpemU9MyBmYWNlPSJzYW5z
LXNlcmlmIj4NCjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPXJlZD48YnI+DQogJm5ic3A7
ICZuYnNwOyAmbmJzcDtJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSByZXNvdXJjZSBvd25lciBh
cyByZWNvZ25pemVkDQpieSB0aGUgQXV0aG9yaXphdGlvbjwvZm9udD48L3R0Pjxmb250IHNpemU9
MyBmYWNlPSJzYW5zLXNlcmlmIj4gPC9mb250Pjx0dD48Zm9udCBzaXplPTMgY29sb3I9cmVkPjxi
cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO1NlcnZlci48L2ZvbnQ+PC90dD48Zm9udCBzaXplPTMg
ZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mz48YnI+DQom
Z3Q7IDxicj4NCiZndDsgLWNtb3J0PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMt
c2VyaWYiPiA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mz48YnI+DQomZ3Q7IDxicj4NCiZndDsgT24g
RGVjIDMsIDIwMTIsIGF0IDY6MjMgUE0sICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzp6
aG91LnN1amluZ0B6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PHR0Pjxmb250IHNpemU9MyBjb2xv
cj1ibHVlPjx1Pnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48
Zm9udCBzaXplPTM+Jmd0Ow0Kd3JvdGU6PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNh
bnMtc2VyaWYiPiA8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mz48YnI+DQomZ3Q7IDxicj4NCiZndDsg
PGJyPg0KJmd0OyBPYnZpb3VzbHksIGl0IGlzIG5vdCBzbyBjbGVhciBmcm9tIHRoZSBsYW5ndWFn
ZSB0aGVyZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ2h1Y2sgTW9ydGltb3Jl
ICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29t
IHRhcmdldD1fYmxhbms+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1PmNtb3J0aW1vcmVA
c2FsZXNmb3JjZS5jb208L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTM+Jmd0Ow0K
5YaZ5LqOIDIwMTItMTItMDQgMTA6MTc6MTI6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhl
cmUncyBubyByZWFzb24gd2h5IGl0IGNhbid0IGJlIHJlc291cmNlIG93bmVyIHRvZGF5LiAmbmJz
cDsNCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gRGVjIDMsIDIwMTIsIGF0IDY6
MDYgUE0sICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUuY29t
LmNuIHRhcmdldD1fYmxhbms+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pnpob3Uuc3Vq
aW5nQHp0ZS5jb20uY248L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTM+Jmd0Ow0K
Jmx0OzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24gdGFy
Z2V0PV9ibGFuaz48dHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+emhvdS5zdWppbmdAenRl
LmNvbS5jbjwvdT48L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz48YnI+DQomZ3Q7ICZn
dDsgJmd0OyB3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgKzEuIDxicj4NCiZndDsgJmd0OyBBbmQgd2h5IGl0IHdhcyBub3QgbG9va2VkIGF0IHRo
YXQgdGltZT8gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBo
cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz48dHQ+PGZv
bnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+
PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz4NCuWGmeS6jiAyMDEyLTEyLTA0IDAxOjMwOjU1Ojxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgSSB0aGluayBpdCBp
cyBhIGdvb2QgdGltZSB0byBzdGFydCBsb29raW5nIGF0DQp0aGUgcmVzb3Vyc2U8YnI+DQomZ3Q7
ICZndDsgJmd0OyBvd25lciBpc3N1aW5nIGFzc2VydGlvbnNAIChJbnRlcmVzdGluZ2x5IGVub3Vn
aCwgSHVpLUxhbg0KaGFkIGJyb3VnaHQ8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGlzIHVwIGEgY291
cGxlIG9mIHllYXJzIGFnby4pPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgSWdvcjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIDEyLzMv
MjAxMiAzOjU4IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEkg
c3VwcG9zZSwgeWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhhdCBhbGwgdGhlIHRpbWUuDQo8
YnI+DQomZ3Q7ICZndDsgJmd0OyBXaGV0aGVyIGl0IGlzIG9yIG5vdCwgaWYgaXQgaXMgc3RpbGwg
b2ssIGl0IG1pZ2h0IGJlIGJldHRlcg0KdG8gPGJyPg0KJmd0OyBjbGFyaWZ5IGl0LiA8YnI+DQom
Z3Q7ICZndDsgJmd0OyBXb3JkIGxpa2UgJnF1b3Q7dGhpcmQgcGFydHkmcXVvdDsgdGVuZHMgdG8g
YmUgYSBiaXQgb2YgcHJvYmxlbQ0Kd2l0aG91dCA8YnI+DQomZ3Q7ICZndDsgY2xlYXJseWRlZmlu
aW5nLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIGhhZCBzaW1pbGFyIGV4cGVyaWVuY2UgaW4gb3Ro
ZXIgZm9yYS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTmF0IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQgZnJvbSBpUGFkIDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDIwMTIvMTIvMDMgMDo1MuOA
gSZxdW90OzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24g
dGFyZ2V0PV9ibGFuaz48dHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+emhvdS5zdWppbmdA
enRlLmNvbS5jbjwvdT48L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz4mcXVvdDsNCiZs
dDs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIHRhcmdl
dD1fYmxhbms+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1Pnpob3Uuc3VqaW5nQHp0ZS5j
b20uY248L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTM+Jmd0Ow0K44GuPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsg44Oh44OD44K744O844K4Ojxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBjb3VsZCBiZSBSZXNvdXJjZSBvd25lcj8g
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZxdW90O1RzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkv
RXNwb28pJnF1b3Q7ICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpoYW5uZXMudHNjaG9m
ZW5pZ0Buc24uY29tIHRhcmdldD1fYmxhbms+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1
Pmhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb208L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBz
aXplPTM+Jmd0Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsg5Y+R5Lu25Lq6OiAmbmJzcDs8L2ZvbnQ+
PC90dD48YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFu
az48dHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwv
dT48L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz4NCjxicj4NCiZndDsgJmd0OyAmZ3Q7
IDIwMTItMTItMDMgMTY6NDkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsg5pS25Lu25Lq6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZx
dW90O2V4dCBOYXQgU2FraW11cmEmcXVvdDsgJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRv
OnNha2ltdXJhQGdtYWlsLmNvbSB0YXJnZXQ9X2JsYW5rPjx0dD48Zm9udCBzaXplPTMgY29sb3I9
Ymx1ZT48dT5zYWtpbXVyYUBnbWFpbC5jb208L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBz
aXplPTM+Jmd0OywNCiZxdW90O0JyaWFuIENhbXBiZWxsJnF1b3Q7ICZsdDs8YnI+DQomZ3Q7ICZn
dDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5
LmNvbSB0YXJnZXQ9X2JsYW5rPjx0dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5iY2FtcGJl
bGxAcGluZ2lkZW50aXR5LmNvbTwvdT48L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz4m
Z3Q7LA0KJnF1b3Q7b2F1dGgmcXVvdDsgJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOm9h
dXRoQGlldGYub3JnIHRhcmdldD1fYmxhbms+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1
Pm9hdXRoQGlldGYub3JnPC91PjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0zPiZndDsN
Cjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IOaKhOmAgSA8YnI+DQom
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyDkuLvpopggPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgUmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1l
d29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlDQp0byBiZSAmbmJzcDsgJm5ic3A7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2Vy
dmljZT8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSGkg
TmF0LCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhl
IGN1cnJlbnQgdGV4dCBlc3NlbnRpYWxseSBzYXlzIHRoYXQgdGhlIGFzc2VydGlvbiBjYW4NCmVp
dGhlciBiZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBjcmVhdGVkIGJ5IHRoZSBjbGllbnQgKGluIHdo
aWNoIGNhc2UgaXQgaXMgc2VsZi1zaWduZWQpDQpvciBpdCBjYW4gYmU8YnI+DQomZ3Q7ICZndDsg
Jmd0OyBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5ICh3aGljaCBpcyB0aGVuIGNhbGxlZCB0
aGUgdGhpcmQNCnBhcnR5IDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRva2VuIHNlcnZpY2UpLiBTbywg
dGhpcyB0aGlyZCBwYXJ0eSBjb3VsZCBiZSB0aGUgYXV0aG9yaXphdGlvbg0Kc2VydmVyLiA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2lhbzxicj4NCiZn
dDsgJmd0OyAmZ3Q7IEhhbm5lcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEZyb206IDwvZm9udD48L3R0
PjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9X2JsYW5rPjx0
dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC91Pjwv
Zm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0zPg0KW21haWx0bzo8L2ZvbnQ+PC90dD48YSBo
cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PV9ibGFuaz48dHQ+PGZv
bnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+
PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz5dDQpPbiBCZWhhbGYgT2YgPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgZXh0IE5hdCBTYWtpbXVyYTxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRheSwg
RGVjZW1iZXIgMDMsIDIwMTIgMTA6MzUgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyBUbzogQnJpYW4g
Q2FtcGJlbGw7IG9hdXRoPGJyPg0KJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogW09BVVRILVdHXSBB
c3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVyDQpoYXZlIHRvIGJlPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2
aWNlPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSGkg
QnJpYW4sIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
bmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIGFzc2VydGlvbiBmcmFtZXdvcmsgZGVmaW5l
cyB0aGUgSXNzdWVyIGFzOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO0lzc3VlciAmbmJzcDtUaGUgdW5pcXVlIGlkZW50aWZpZXIg
Zm9yIHRoZQ0KZW50aXR5IHRoYXQgaXNzdWVkIHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyBhc3NlcnRpb24uICZuYnNwO0dlbmVyYWxseSB0aGlzIGlzDQp0aGUg
ZW50aXR5IHRoYXQgaG9sZHMgdGhlIGtleSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBtYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uDQombmJz
cDtUaGUgaXNzdWVyIG1heSBiZSBlaXRoZXIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgYW4gT0F1dGggY2xpZW50ICh3aGVuIGFzc2VydGlvbnMgYXJlDQpzZWxmLWlz
c3VlZCkgb3IgYSB0aGlyZCBwYXJ0eSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyB0b2tlbiBzZXJ2aWNlLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgSSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8gYmUgZWl0aGVyIHRo
ZSBjbGllbnQgb3IgYQ0KdGhpcmQgcGFydHkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdG9rZW4gc2Vy
dmljZS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ29uY2VwdHVhbGx5LCBpdCBjb3VsZCBiZSBhbnkg
dG9rZW4gc2VydmljZSAoZnVuY3Rpb25hbGl0eSkNCjxicj4NCiZndDsgJmd0OyByZXNpZGluZ2lu
IGFueSBvZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
dGhlIHN0YWtlaG9sZGVycyAoUmVzb3VyY2UgT3duZXIsIE9BdXRoIENsaWVudCwgQXV0aG9yaXph
dGlvbg0KU2VydmVyLCBvciA8YnI+DQomZ3Q7ICZndDsgJmd0OyBhIHRoaXJkIHBhcnR5KS4gPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyBJIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IGNvdWxkIGNsYXJpZnkg
d2h5IGlzIHRoZSBjYXNlLg0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBCZXN0LCA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgTmF0IFNha2ltdXJhICg9bmF0KSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBDaGFpcm1hbiwgT3Bl
bklEIEZvdW5kYXRpb248YnI+DQomZ3Q7ICZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0
dHA6Ly9uYXQuc2FraW11cmEub3JnLyB0YXJnZXQ9X2JsYW5rPjx0dD48Zm9udCBzaXplPTMgY29s
b3I9Ymx1ZT48dT5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L3U+PC9mb250PjwvdHQ+PC9hPjx0
dD48Zm9udCBzaXplPTM+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQF9uYXRfZW4gPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZn
dDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpPQXV0aEBpZXRmLm9yZyB0YXJnZXQ9
X2JsYW5rPjx0dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5PQXV0aEBpZXRmLm9yZzwvdT48
L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz48YnI+DQomZ3Q7ICZndDsgJmd0OyA8L2Zv
bnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGggdGFyZ2V0PV9ibGFuaz48dHQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvdT48L2ZvbnQ+PC90dD48L2E+PHR0
Pjxmb250IHNpemU9Mz48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBPQXV0aCBtYWls
aW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPW1haWx0bzpP
QXV0aEBpZXRmLm9yZyB0YXJnZXQ9X2JsYW5rPjx0dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48
dT5PQXV0aEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz48YnI+
DQomZ3Q7ICZndDsgJmd0OyA8L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGggdGFyZ2V0PV9ibGFuaz48dHQ+PGZvbnQgc2l6ZT0zIGNv
bG9yPWJsdWU+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv
dT48L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz48YnI+DQomZ3Q7ICZndDsgJmd0OyBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg
Jmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IDwvZm9udD48
L3R0PjxhIGhyZWY9bWFpbHRvOk9BdXRoQGlldGYub3JnIHRhcmdldD1fYmxhbms+PHR0Pjxmb250
IHNpemU9MyBjb2xvcj1ibHVlPjx1Pk9BdXRoQGlldGYub3JnPC91PjwvZm9udD48L3R0PjwvYT48
dHQ+PGZvbnQgc2l6ZT0zPjxicj4NCiZndDsgJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCB0YXJnZXQ9X2JsYW5r
Pjx0dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC91PjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0zPjxi
cj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCiZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPC9m
b250PjwvdHQ+PGEgaHJlZj1tYWlsdG86T0F1dGhAaWV0Zi5vcmcgdGFyZ2V0PV9ibGFuaz48dHQ+
PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+T0F1dGhAaWV0Zi5vcmc8L3U+PC9mb250PjwvdHQ+
PC9hPjx0dD48Zm9udCBzaXplPTM+PGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCB0YXJnZXQ9X2JsYW5r
Pjx0dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoPC91PjwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0zPg0K
PC9mb250PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg
bWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy
aWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86T0F1dGhAaWV0Zi5vcmcgdGFy
Z2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5P
QXV0aEBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9
InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0zIGNv
bG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNl
cmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxi
cj4NCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+LS0g
PGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KTwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i
c2Fucy1zZXJpZiI+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPC9mb250Pjxmb250IHNpemU9
MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2VyaWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJl
Zj1odHRwOi8vbmF0LnNha2ltdXJhLm9yZy8gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29s
b3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L3U+
PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KQF9uYXRfZW48
L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg
bWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9InNhbnMtc2Vy
aWYiPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86T0F1dGhAaWV0Zi5vcmc+PGZv
bnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+T0F1dGhAaWV0Zi5vcmc8
L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlmIj48
dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aCB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9
InNhbnMtc2VyaWYiPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGg8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPC9m
b250Pg0KPGJyPg0KPGJyPg0K
--=_alternative 0003B61448257ACB_=--

From zhou.sujing@zte.com.cn  Wed Dec  5 00:32:14 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9CA21F8BFE for ; Wed,  5 Dec 2012 00:32:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.834
X-Spam-Level: 
X-Spam-Status: No, score=-96.834 tagged_above=-999 required=5 tests=[AWL=-0.239, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_48=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1TNGZOMAAZK for ; Wed,  5 Dec 2012 00:32:10 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1D63A21F8CA4 for ; Wed,  5 Dec 2012 00:32:09 -0800 (PST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 1728012841A8; Wed,  5 Dec 2012 16:33:51 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qB58VktZ040925; Wed, 5 Dec 2012 16:31:47 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: "oauth@ietf.org WG" , John Bradley 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Wed, 5 Dec 2012 16:31:39 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-05 16:31:45, Serialize complete at 2012-12-05 16:31:45
Content-Type: multipart/alternative; boundary="=_alternative 002EF7A148257ACB_="
X-MAIL: mse02.zte.com.cn qB58VktZ040925
Subject: [OAUTH-WG] Any comment on the use cases based on draft-zhou-oauth-owner-auth?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 08:32:14 -0000

This is a multipart message in MIME format.
--=_alternative 002EF7A148257ACB_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

WmhvdVN1SmluZzAwMTMyODMxL3VzZXIvenRlX2x0ZCDQtNPaIDIwMTItMTItMDQgMTM6NTI6MzA6
DQoNCj4gSG93IGFib3V0IHRoZSBmb2xsb3dpbmcgdXNlIGNhc2VzOiANCj4gMS4gRGlyZWN0IERl
bGVnYXRpb24gDQo+IA0KPiAgICBEZXNjcmlwdGlvbjoNCj4gDQo+ICAgIENvbXBhbnkgR29vZFBh
eSBwcmVwYXJlcyB0aGUgZW1wbG95ZWUgcGF5cm9sbHMgZm9yIHRoZSBjb21wYW55DQo+ICAgIEdv
b2RXb3JrLiAgSW4gb3JkZXIgdG8gZG8gdGhhdCB0aGUgYXBwbGljYXRpb24gYXQgd3d3Lkdvb2RQ
YXkuZXhhbXBsZQ0KPiAgICBnZXRzIGF1dGhlbnRpY2F0ZWQgYWNjZXNzIHRvIHRoZSBlbXBsb3ll
ZXMnIGF0dGVuZGFuY2UgZGF0YSBzdG9yZWQgYXQNCj4gICAgd3d3Lkdvb2RXb3JrLmV4YW1wbGUu
DQo+IA0KPiAgICBQcmUtY29uZGl0aW9uczoNCj4gDQo+ICAgIG8gIFRoZSBhcHBsaWNhdGlvbiBh
dCB3d3cuR29vZFBheS5leGFtcGxlIGhhcyBvYnRhaW5lZCBhbg0KPiAgICAgICBhdXRoZW50aWNh
dGlvbiBkZWxlZ2F0aW9uIGZyb20gYSBwYXJ0eSB0aGF0IGlzIHRydXN0ZWQgYnkgdGhlDQo+ICAg
ICAgIGFwcGxpY2F0aW9uIGF0IHd3dy5Hb29kV29yay5leGFtcGxlDQo+IA0KPiAgICBvICBUaGUg
c2NvcGUgb2YgdGhlIGFjY2VzcyBieSB0aGUgYXBwbGljYXRpb24gYXQgd3d3Lkdvb2RQYXkuZXhh
bXBsZQ0KPiAgICAgICB0byB0aGUgZGF0YSBzdG9yZWQgYXQgd3d3Lkdvb2RXb3JrLmV4YW1wbGUg
aGFzIGJlZW4gZGVmaW5lZA0KPiANCj4gICAgbyAgVGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5Hb29k
UGF5LmV4YW1wbGUgaXMgbm90IGNhcGFibGUgb2YgDQp2YWxpZGF0aW5nDQo+ICAgICAgIGl0cyBk
ZWxlZ2F0aW9uLg0KPiANCj4gICAgUG9zdC1jb25kaXRpb25zOg0KPiANCj4gICAgQSBzdWNjZXNz
ZnVsIHByb2NlZHVyZSByZXN1bHRzIGluIHRoZSBhcHBsaWNhdGlvbiBhdA0KPiAgICB3d3cuR29v
ZFBheS5leGFtcGxlIHJlY2VpdmluZyBhbiBhY2Nlc3MgdG9rZW4gYWZ0ZXIgYXV0aGVudGljYXRp
bmcgdG8NCj4gICAgdGhlIGF1dGhvcml6YXRpb24gb3IgdGhlIGFwcGxpY2F0aW9uIHJ1bm5pbmcg
YXQgd3d3Lkdvb2RXb3JrLg0KPiBleGFtcGxlIGJ5IHByZXNlbnRpbmcgYW4NCj4gZGVsZWdhdGlv
bi4gDQo+IA0KPiAgICBSZXF1aXJlbWVudHM6DQo+IA0KPiAgICBvICBBdXRoZW50aWNhdGlvbiBv
ZiB0aGUgYXBwbGljYXRpb24gYXQgd3d3Lkdvb2RQYXkuZXhhbXBsZSB0byB0aGUNCj4gICAgICAg
YXV0aG9yaXphdGlvbiBzZXJ2ZXIgb3IgdGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5Hb29kV29yay4N
Cj4gZXhhbXBsZSBpcyByZXF1aXJlZA0KPiANCj4gICAgbyAgVGhlIGF1dGhvcml6YXRpb24gb3Ig
dGhlIGFwcGxpY2F0aW9uIHJ1bm5pbmcgYXQgd3d3Lkdvb2RXb3JrLg0KPiBleGFtcGxlIG11c3Qg
YmUgY2FwYWJsZSBvZg0KPiAgICAgICB2YWxpZGF0aW5nIGRlbGVnYXRpb24gIHByZXNlbnRlZCBi
eSB0aGUgYXBwbGljYXRpb24gcnVubmluZyBhdA0KPiAgICAgICB3d3cuR29vZFBheS5leGFtcGxl
DQo+IA0KPiANCj4gDQo+IDIuIFByb3h5IGRlbGVnYXRpb24gDQo+IA0KPiAgICBEZXNjcmlwdGlv
bjoNCj4gDQo+ICAgIEFsaWNlIGhhcyBoZXIgZmluYW5jaWFsIGRhdGEgc3RvcmVkIGF0IGEgZmlu
YW5jaWFsIGNvbXBhbnkgd3d3Lg0KPiBmaW5hbmNpYWwuY29tLCBoZXIgbGF3eWVyIG5lZWRzIHRv
IA0KPiAgICBvYnRhaW4gYXV0aGVudGljYXRlZCBhY2Nlc3MgdG8gc29tZSBvZiBoZXIgZmluYW5j
aWFsIGRhdGEgdG8gcnVuIA0KPiBhcHBsaWNhdGlvbnMgYXQgd3d3Lmxhd3llci5leGFtcGxlLiAN
Cj4gICAgQWxpY2UgYW5kIHRoZSBsYXd5ZXIgaGF2ZSByYXRoZXIgbG9uZyB0ZXJtIHRydXN0IHJl
bGF0aW9uc2hpcCwgDQo+IGJ1dCBzdGlsbCBBbGljZSBpcyBub3Qgd2lsbGluZyB0byBsZWFrIGhl
ciBzZWNyZXQgY3JlZGVudGlhbCB0byB0aGUgDQo+IA0KPiAgbGF3eWVyLiBUaGUgYXBwbGljYXRp
b25zIGF0IHd3dy5sYXd5ZXIuZXhhbXBsZSBtYXkgY2hhbmdlIG92ZXIgdGhlIA0KPiB0aW1lLCBB
bGljZSBpcyBub3Qgd2lsbGluZyB0byBiZSBib3RoZXJlZCBieSBnZW5lcmF0aW5nIGFzc2VydGlv
biANCj4gIGVhY2ggdGltZSBhIG5ldyBhcHBsaWNhdGlvbiBjb21lcyBvdXQuIA0KPiANCj4gICAg
UHJlLWNvbmRpdGlvbnM6DQo+IA0KPiAgICAgIG8gQWxpY2UgaGFzIGEgc2VjcmV0IHByaXZhdGUg
a2V5IGFuZCBjb3JyZXNwb25kaW5nIHB1YmxpYyBrZXkgDQo+ICAgICAgbyBBbGljZSBjb3VsZCBn
ZW5lcmF0ZSBhIHByb3h5IHByaXZhdGUga2V5IGZvciBoZXIgbGF3eWVyIA0KPiAgICAgIG8gTGF3
eWVyIGNvdWxkIGdlbmVyYXRlIHByb3h5IHNpZ25hdHVyZSBiYXNlZCBvbiBoaXMgcHJveHkgDQo+
IHByaXZhdGUga2V5IGZvciBhbnkgYXBwbGljYXRpb24gYXQgd3d3Lmxhd3llci5leGFtcGxldGhh
dCBpcyBpbiB0aGUgDQo+IA0KPiBzY29wZSAodGhlIHNjb3BlIGNvdWxkIGJlIGFzIGJyb2FkIGFz
IGFueSBhcHBsaWNhdGlvbiBhdCB0aGUgd2Vic2l0ZQ0KPiB3d3cubGF3eWVyLmV4YW1wbGUpIG9m
IHRoZSBwcm94eSBwcml2YXRlIGtleS4gDQo+IA0KPiAgICBQb3N0LWNvbmRpdGlvbnM6DQo+IA0K
PiAgICBBIHN1Y2Nlc3NmdWwgcHJvY2VkdXJlIHJlc3VsdHMgaW4gdGhlIGFwcGxpY2F0aW9uIGF0
DQo+ICAgIHd3dy5sYXd5ZXIuZXhhbXBsZXJlY2VpdmluZyBhbiBhY2Nlc3MgdG9rZW4gYWZ0ZXIg
cHJlc2VudGluZyBhIA0KPiBwcm94eSBzaWduYXR1cmUgdG8gDQo+ICAgIHRoZSBhdXRob3JpemF0
aW9uIHNlcnZlciBzcGVjaWZpZWQgYnkgQWxpY2UuDQo+IA0KPiAgICBSZXF1aXJlbWVudHM6DQo+
IA0KPiAgICBvICBBdXRoZW50aWNhdGlvbiBvZiB0aGUgYXBwbGljYXRpb24gYXQgd3d3Lmxhd3ll
ci5leGFtcGxldG8gdGhlDQo+ICAgICAgIGFwcGxpY2F0aW9uIGF0IHd3dy5maW5hbmNpYWwuZXhh
bXBsZSBpcyByZXF1aXJlZA0KPiANCj4gICAgbyAgVGhlIGF1dGhvcml6YXRpb24gc2VydmVyIG11
c3QgYmUgY2FwYWJsZSBvZg0KPiAgICAgICB2YWxpZGF0aW5nIHByb3h5IHNpZ25hdHVyZSBwcmVz
ZW50ZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHJ1bm5pbmcgYXQNCj4gICAgICAgd3d3Lmxhd3llci5l
eGFtcGxlDQo+IA0KPiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPiDQtNPaIDIwMTIt
MTItMDMgMjE6MTc6Mzg6DQo+IA0KPiA+IFRoYXQgbWF5IHJlbGF0ZSBtb3JlIHRvIHRoZSBwcm9v
ZiBvZiBwb3NzZXNzaW9uIGRpc2N1c3Npb24uDQo+ID4gDQo+ID4gWW91IG1heSB3YW50IHRvIHN1
Ym1pdCB0aGF0IGFzIGEgdXNlIGNhc2UuDQo+ID4gDQo+ID4gSm9obiBCLg0KPiA+IE9uIDIwMTIt
MTItMDMsIGF0IDY6MDEgQU0sIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4gDQo+
ID4gDQo+ID4gDQo+ID4gQW5kIGFub3RoZXIgZGlmZmVyZW5jZSBpcyBteSB1c2UgY2FzZSBjb3Vs
ZCBiZSB0aGF0ICJhc3NlcnRpb24iIGJlIA0KPiA+IGdlbmVyYXRlZCBzZXF1ZW50aWFsbHkgYnkg
cmVzb3VyY2Ugb3duZXIgYW5kIGNsaWVudC4gDQo+ID4gRm9yIGV4YW1wbGUsIHJlc291cmNlIG93
bmVyIGRlbGVnYXRlcyBhIGNsaWVudCB0byBnZW5lcmF0ZSBzaWduYXR1cmUNCj4gPiBvbiBiZWhh
bGYgb2YgaXQsIGNsaWVudCBnZW5lcmF0ZXMgYSBzaWduYXR1cmUgdXNpbmcgdGhlIHByaXZhdGUg
DQo+IGtleSBvZiBpdHNlbGYsDQo+ID4gd2hpY2ggaXMgY2FsbGVkIHByb3h5IHNpZ25hdHVyZSBp
biBjcnlwdG9ncmFwaHkuIA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+ID4gTXkgdXNlIGNhc2UgaXMg
aW5kZWVkIHNpbWlsYXIgdG8gIGFzc2VydGlvbiBmbG93ICJzZWN0aW9uIDYuMy4gDQo+ID4gPiBD
bGllbnQgQWN0aW5nIG9uIEJlaGFsZiBvZiBhIFVzZXIiLiANCj4gPiA+IERpZmZlcmVuY2VzIGFy
ZTogDQo+ID4gPiAxLiAgaWYgbXkgdXNlIGNhc2UgaXMgY2FycmllZCBvdXQgaW4gYXNzZXJ0aW9u
IGZyYW1ld29yaywgInByaWNpcGFsIg0KPiA+ID4gc2hvdWxkIGJlIGNsaWVudCwgd2hpbGUgYXNz
ZXJ0aW9uIGRvY3VtZW50IGRvZXMgbm90IA0KPiA+ID4gaW5jbHVkZSBjbGllbnQgYXMgYW4gb3B0
aW9uIHdoZW4gY2xpZW50IGlzIGFjdGluZyBvbiBiZWhhbGYgb2YgYSANCj4gPiA+IHVzZXIocmVz
b3VyY2Ugb3duZXIpLCBpdCBzYXlzICAiIGFuIGF1dGhvcml6ZWQgYWNjZXNzb3IgZm9yIHdoaWNo
IA0KdGhlIA0KPiA+ID4gYWNjZXNzIHRva2VuIGlzIGJlaW5nIHJlcXVlc3RlZCAodHlwaWNhbGx5
IHRoZSByZXNvdXJjZSBvd25lciwgb3IgDQo+ID4gPiBhbiBhdXRob3JpemVkIGRlbGVnYXRlKS4i
IA0KPiA+ID4gMi4gIGlmIG15IHVzZSBjYXNlIGlzIGNhcnJpZWQgb3V0IGluIGFzc2VydGlvbiBm
cmFtZXdvcmssICJpc3N1ZXIiIA0KPiA+ID4gc2hvdWxkIGJlIHJlc291cmNlIG93bmVyLCB3aGls
ZSBhc3NlcnRpb24gZG9jdW1lbnQgb25seSBpbmNsdWRlcyANCj4gPiA+IGNsaWVudCBhbmQgdG9r
ZW4gc2VydmljZSANCj4gPiA+IA0KPiA+ID4gSW4gbXkgdXNlIGNhc2UgdGhlICJhc3NlcnRpb24i
IGlzIG1vcmUgbGlrZSBhIHByaXZhdGUgb3V0cHV0LCB3aGlsZSANCj4gPiA+IGluIGFzc2VydGlv
biBmbG93ICJhc3NlcnRpb24gIiBpcyBnZW5lcmF0ZWQgYnkgYSB0aHJpZCBwYXJ0eSB0b2tlbiAN
Cj4gPiA+IHNlcnZpY2Ugb3IgYnkgY2xpZW50IGl0c2VsZi4gDQo+ID4gPiANCj4gPiA+IE5hdCBT
YWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPiANCj4gPiA+IDIwMTItMTItMDMgMTQ6NDQgDQo+
ID4gPiANCj4gPiA+IMrVvP7IyyANCj4gPiA+IA0KPiA+ID4gemhvdS5zdWppbmdAenRlLmNvbS5j
biANCj4gPiA+IA0KPiA+ID4gs63LzSANCj4gPiA+IA0KPiA+ID4gIm9hdXRoQGlldGYub3JnIFdH
IiA8b2F1dGhAaWV0Zi5vcmc+IA0KPiA+ID4gDQo+ID4gPiDW98ziIA0KPiA+ID4gDQo+ID4gPiBS
ZTogUmU6IFtPQVVUSC1XR10gSGksYW55IGNvbW1lbnQgb24gZHJhZnQtemhvdS1vYXV0aC1vd25l
ci1hdXRoPyANCj4gPiA+IA0KPiA+ID4gWW91ciB1c2VjYXNlIHNvdW5kcyBhIGxpdHRsZSBiaXQg
bGlrZSB0aGUgYXNzZXJ0aW9uIGZsb3cuIA0KPiA+ID4gVGhlIFJPIGlzc3VlcyBhbiBhc3NlcnRp
b24gYW5kIHRoZSByZXN0IGdvZXMuIA0KPiA+ID4gSXMgdGhlcmUgcmVhc29ucyB0aGF0IGFuIGFz
c2VydGlvbiBmbG93IGNhbm5vdCBkbz8gDQo+ID4gPiANCj4gPiA+IE5hdA0KPiA+IA0KPiA+ID4g
T24gTW9uLCBEZWMgMywgMjAxMiBhdCAzOjM1IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbj4g
d3JvdGU6IA0KPiA+ID4gbXkgdXNlIGNhc2UoUk8taW5pdGlhdGVkIGRlbGVnYXRpb24pOiANCj4g
PiA+IC1JIGRlcG9zaXQgbXkgY2hpbGQocHJlY2lvdXMgcmVzb3VyY2UpIGF0IGtpbmRlcmdhcmRl
bihSZXNvdXJjZSANClNlcnZlcikgDQo+ID4gPiAtSSBkZWxlZ2F0ZSBhIGZldyBwZXJzb25zLGUu
Zy4sIGdyYW5kcGFyZW50cyBvZiBteSBjaGlsZCwgdG8gcGljayB1cA0KPiA+ID4gbXkgY2hpbGQg
YXQgdGhlIGtpbmRlcmdhcmRlbiANCj4gPiA+IC13aGVuIHNvbWVvbmUgdHJpZXMgdG8gdGFrZSBo
aW0gb3V0c2lkZSBvZiB0aGUga2luZGVyZ2FyZGVuLCAgdGhlIA0KPiA+ID4gdGVhY2hlciB3aWxs
IGFzayBoaW0vaGVyIHRvIHNob3cgbXkgZGVsZWdhdGlvbiANCj4gPiA+ICBzdGF0ZW1lbnQsIG5v
IHN0YXRlbWVudCwgbm8gdGFraW5nIG15IGNoaWxkLiANCj4gPiA+IA0KPiA+IA0KPiA+ID4gDQo+
ID4gPiAtLSANCj4gPiA+IE5hdCBTYWtpbXVyYSAoPW5hdCkgDQo+ID4gPiBDaGFpcm1hbiwgT3Bl
bklEIEZvdW5kYXRpb24NCj4gPiA+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiA+ID4gQF9u
YXRfZW4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==
--=_alternative 002EF7A148257ACB_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5aaG91U3VKaW5nMDAxMzI4MzEvdXNlci96dGVf
bHRkINC009ogMjAxMi0xMi0wNA0KMTM6NTI6MzA6PGJyPg0KPGJyPg0KJmd0OyBIb3cgYWJvdXQg
dGhlIGZvbGxvd2luZyB1c2UgY2FzZXM6IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyAxLiBEaXJlY3QgRGVsZWdhdGlvbiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7RGVzY3JpcHRpb246PC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0Nv
bXBhbnkgR29vZFBheSBwcmVwYXJlcyB0aGUgZW1wbG95ZWUgcGF5cm9sbHMgZm9yIHRoZQ0KY29t
cGFueTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7
R29vZFdvcmsuICZuYnNwO0luIG9yZGVyIHRvIGRvIHRoYXQNCnRoZSBhcHBsaWNhdGlvbiBhdCB3
d3cuR29vZFBheS5leGFtcGxlPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7
ICZuYnNwOyAmbmJzcDtnZXRzIGF1dGhlbnRpY2F0ZWQgYWNjZXNzIHRvIHRoZQ0KZW1wbG95ZWVz
JyBhdHRlbmRhbmNlIGRhdGEgc3RvcmVkIGF0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDt3d3cuR29vZFdvcmsuZXhhbXBsZS48L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7UHJlLWNv
bmRpdGlvbnM6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZn
dDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7VGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5Hb29kUGF5LmV4
YW1wbGUgaGFzIG9idGFpbmVkDQphbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhdXRoZW50aWNhdGlvbiBkZWxlZ2F0aW9uDQpmcm9t
IGEgcGFydHkgdGhhdCBpcyB0cnVzdGVkIGJ5IHRoZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhcHBsaWNhdGlvbiBhdCB3d3cuR29v
ZFdvcmsuZXhhbXBsZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+
DQomZ3Q7ICZuYnNwOyAmbmJzcDtvICZuYnNwO1RoZSBzY29wZSBvZiB0aGUgYWNjZXNzIGJ5IHRo
ZSBhcHBsaWNhdGlvbiBhdA0Kd3d3Lkdvb2RQYXkuZXhhbXBsZTwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0byB0aGUgZGF0YSBzdG9y
ZWQgYXQgd3d3Lkdvb2RXb3JrLmV4YW1wbGUNCmhhcyBiZWVuIGRlZmluZWQ8L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7byAmbmJz
cDtUaGUgYXBwbGljYXRpb24gYXQgd3d3Lkdvb2RQYXkuZXhhbXBsZSBpcyBub3QNCmNhcGFibGUg
b2YgdmFsaWRhdGluZzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyBpdHMgZGVsZWdhdGlvbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7UG9zdC1jb25kaXRpb25zOjwv
Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAm
bmJzcDtBIHN1Y2Nlc3NmdWwgcHJvY2VkdXJlIHJlc3VsdHMgaW4gdGhlIGFwcGxpY2F0aW9uIGF0
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDt3d3cu
R29vZFBheS5leGFtcGxlIHJlY2VpdmluZyBhbg0KYWNjZXNzIHRva2VuIGFmdGVyIGF1dGhlbnRp
Y2F0aW5nIHRvPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAm
bmJzcDt0aGUgYXV0aG9yaXphdGlvbiBvciB0aGUgYXBwbGljYXRpb24NCnJ1bm5pbmcgYXQgd3d3
Lkdvb2RXb3JrLjxicj4NCiZndDsgZXhhbXBsZSBieSBwcmVzZW50aW5nIGFuPC9mb250PjwvdHQ+
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IGRlbGVnYXRpb24uIDwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtSZXF1aXJlbWVu
dHM6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5i
c3A7ICZuYnNwO28gJm5ic3A7QXV0aGVudGljYXRpb24gb2YgdGhlIGFwcGxpY2F0aW9uIGF0IHd3
dy5Hb29kUGF5LmV4YW1wbGUNCnRvIHRoZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhdXRob3JpemF0aW9uIHNlcnZlciBvcg0KdGhl
IGFwcGxpY2F0aW9uIGF0IHd3dy5Hb29kV29yay48YnI+DQomZ3Q7IGV4YW1wbGUgaXMgcmVxdWly
ZWQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmbmJz
cDsgJm5ic3A7byAmbmJzcDtUaGUgYXV0aG9yaXphdGlvbiBvciB0aGUgYXBwbGljYXRpb24gcnVu
bmluZw0KYXQgd3d3Lkdvb2RXb3JrLjxicj4NCiZndDsgZXhhbXBsZSBtdXN0IGJlIGNhcGFibGUg
b2Y8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgdmFsaWRhdGluZyBkZWxlZ2F0aW9uICZuYnNwO3ByZXNlbnRlZA0KYnkgdGhlIGFwcGxp
Y2F0aW9uIHJ1bm5pbmcgYXQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgd3d3Lkdvb2RQYXkuZXhhbXBsZTwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAyLiBQcm94eSBkZWxlZ2F0
aW9uIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZu
YnNwOyAmbmJzcDtEZXNjcmlwdGlvbjo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y
PiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7QWxpY2UgaGFzIGhlciBmaW5hbmNpYWwgZGF0
YSBzdG9yZWQgYXQgYSBmaW5hbmNpYWwgY29tcGFueQ0Kd3d3Ljxicj4NCiZndDsgZmluYW5jaWFs
LmNvbSwgaGVyIGxhd3llciBuZWVkcyB0byA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgJm5ic3A7ICZuYnNwO29idGFpbiBhdXRoZW50aWNhdGVkIGFjY2VzcyB0byBzb21l
DQpvZiBoZXIgZmluYW5jaWFsIGRhdGEgdG8gcnVuIDxicj4NCiZndDsgYXBwbGljYXRpb25zIGF0
IHd3dy5sYXd5ZXIuZXhhbXBsZS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m
Z3Q7ICZuYnNwOyAmbmJzcDtBbGljZSBhbmQgdGhlIGxhd3llciBoYXZlIHJhdGhlcg0KbG9uZyB0
ZXJtIHRydXN0IHJlbGF0aW9uc2hpcCwgPGJyPg0KJmd0OyBidXQgc3RpbGwgQWxpY2UgaXMgbm90
IHdpbGxpbmcgdG8gbGVhayBoZXIgc2VjcmV0IGNyZWRlbnRpYWwgdG8gdGhlDQombmJzcDsgPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7bGF3
eWVyLiBUaGUgYXBwbGljYXRpb25zIGF0IHd3dy5sYXd5ZXIuZXhhbXBsZSBtYXkgY2hhbmdlIG92
ZXINCnRoZSA8YnI+DQomZ3Q7IHRpbWUsIEFsaWNlIGlzIG5vdCB3aWxsaW5nIHRvIGJlIGJvdGhl
cmVkIGJ5IGdlbmVyYXRpbmcgYXNzZXJ0aW9uDQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgJm5ic3A7ZWFjaCB0aW1lIGEgbmV3IGFwcGxpY2F0aW9uIGNvbWVzIG91dC4N
CiZuYnNwOyAmbmJzcDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi
cj4NCiZndDsgJm5ic3A7ICZuYnNwO1ByZS1jb25kaXRpb25zOjwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO28gQWxpY2UgaGFzIGEg
c2VjcmV0IHByaXZhdGUNCmtleSBhbmQgY29ycmVzcG9uZGluZyBwdWJsaWMga2V5IDwvZm9udD48
L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO28gQWxp
Y2UgY291bGQgZ2VuZXJhdGUgYQ0KcHJveHkgcHJpdmF0ZSBrZXkgZm9yIGhlciBsYXd5ZXIgPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
byBMYXd5ZXIgY291bGQgZ2VuZXJhdGUgcHJveHkNCnNpZ25hdHVyZSBiYXNlZCBvbiBoaXMgcHJv
eHkgPGJyPg0KJmd0OyBwcml2YXRlIGtleSBmb3IgYW55IGFwcGxpY2F0aW9uIGF0IHd3dy5sYXd5
ZXIuZXhhbXBsZXRoYXQgaXMgaW4gdGhlDQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgPGJyPg0KJmd0OyBzY29wZSAodGhlIHNjb3BlIGNvdWxkIGJlIGFzIGJyb2FkIGFz
IGFueSBhcHBsaWNhdGlvbiBhdCB0aGUgd2Vic2l0ZTxicj4NCiZndDsgd3d3Lmxhd3llci5leGFt
cGxlKSBvZiB0aGUgcHJveHkgcHJpdmF0ZSBrZXkuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtQb3N0LWNvbmRpdGlvbnM6PC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZu
YnNwO0Egc3VjY2Vzc2Z1bCBwcm9jZWR1cmUgcmVzdWx0cyBpbiB0aGUgYXBwbGljYXRpb24gYXQ8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO3d3dy5s
YXd5ZXIuZXhhbXBsZXJlY2VpdmluZyBhbiBhY2Nlc3MNCnRva2VuIGFmdGVyIHByZXNlbnRpbmcg
YSA8YnI+DQomZ3Q7IHByb3h5IHNpZ25hdHVyZSB0byA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO3RoZSBhdXRob3JpemF0aW9uIHNlcnZlciBzcGVj
aWZpZWQNCmJ5IEFsaWNlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8
YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtSZXF1aXJlbWVudHM6PC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7QXV0aGVu
dGljYXRpb24gb2YgdGhlIGFwcGxpY2F0aW9uIGF0IHd3dy5sYXd5ZXIuZXhhbXBsZXRvDQp0aGU8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgYXBwbGljYXRpb24gYXQgd3d3LmZpbmFuY2lhbC5leGFtcGxlDQppcyByZXF1aXJlZDwvZm9u
dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz
cDtvICZuYnNwO1RoZSBhdXRob3JpemF0aW9uIHNlcnZlciBtdXN0IGJlIGNhcGFibGUgb2Y8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
dmFsaWRhdGluZyBwcm94eSBzaWduYXR1cmUNCnByZXNlbnRlZCBieSB0aGUgYXBwbGljYXRpb24g
cnVubmluZyBhdDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyB3d3cubGF3eWVyLmV4YW1wbGU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIu
Y29tJmd0OyDQtNPaIDIwMTItMTItMDMgMjE6MTc6Mzg6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgVGhhdCBtYXkgcmVsYXRlIG1vcmUgdG8gdGhlIHByb29mIG9mIHBvc3Nlc3Npb24gZGlzY3Vz
c2lvbi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgWW91IG1heSB3YW50IHRvIHN1Ym1pdCB0aGF0IGFzIGEgdXNlIGNhc2UuPC9mb250
PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEpv
aG4gQi48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyBPbiAyMDEy
LTEyLTAzLCBhdCA2OjAxIEFNLCB6aG91LnN1amluZ0B6dGUuY29tLmNuDQp3cm90ZTo8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBbmQgYW5vdGhlciBkaWZmZXJlbmNlIGlzIG15
IHVzZSBjYXNlIGNvdWxkIGJlIHRoYXQgJnF1b3Q7YXNzZXJ0aW9uJnF1b3Q7DQpiZSA8YnI+DQom
Z3Q7ICZndDsgZ2VuZXJhdGVkIHNlcXVlbnRpYWxseSBieSByZXNvdXJjZSBvd25lciBhbmQgY2xp
ZW50LiA8YnI+DQomZ3Q7ICZndDsgRm9yIGV4YW1wbGUsIHJlc291cmNlIG93bmVyIGRlbGVnYXRl
cyBhIGNsaWVudCB0byBnZW5lcmF0ZSBzaWduYXR1cmU8YnI+DQomZ3Q7ICZndDsgb24gYmVoYWxm
IG9mIGl0LCBjbGllbnQgZ2VuZXJhdGVzIGEgc2lnbmF0dXJlIHVzaW5nIHRoZSBwcml2YXRlDQo8
YnI+DQomZ3Q7IGtleSBvZiBpdHNlbGYsPGJyPg0KJmd0OyAmZ3Q7IHdoaWNoIGlzIGNhbGxlZCBw
cm94eSBzaWduYXR1cmUgaW4gY3J5cHRvZ3JhcGh5LiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBNeSB1c2UgY2FzZSBp
cyBpbmRlZWQgc2ltaWxhciB0byAmbmJzcDthc3NlcnRpb24gZmxvdyAmcXVvdDtzZWN0aW9uDQo2
LjMuICZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7IENsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9m
IGEgVXNlciZxdW90Oy4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRGlmZmVyZW5jZXMgYXJlOiA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAxLiAmbmJzcDtpZiBteSB1c2UgY2FzZSBpcyBjYXJyaWVkIG91dCBp
biBhc3NlcnRpb24gZnJhbWV3b3JrLA0KJnF1b3Q7cHJpY2lwYWwmcXVvdDs8YnI+DQomZ3Q7ICZn
dDsgJmd0OyBzaG91bGQgYmUgY2xpZW50LCB3aGlsZSBhc3NlcnRpb24gZG9jdW1lbnQgZG9lcyBu
b3QgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaW5jbHVkZSBjbGllbnQgYXMgYW4gb3B0aW9uIHdoZW4g
Y2xpZW50IGlzIGFjdGluZyBvbiBiZWhhbGYNCm9mIGEgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdXNl
cihyZXNvdXJjZSBvd25lciksIGl0IHNheXMgJm5ic3A7JnF1b3Q7IGFuIGF1dGhvcml6ZWQNCmFj
Y2Vzc29yIGZvciB3aGljaCB0aGUgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFjY2VzcyB0
b2tlbiBpcyBiZWluZyByZXF1ZXN0ZWQgKHR5cGljYWxseSB0aGUgcmVzb3VyY2UNCm93bmVyLCBv
ciAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBhbiBhdXRob3JpemVkIGRlbGVnYXRlKS4mcXVv
dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgMi4gJm5ic3A7aWYgbXkgdXNlIGNhc2UgaXMgY2Fycmll
ZCBvdXQgaW4gYXNzZXJ0aW9uIGZyYW1ld29yaywNCiZxdW90O2lzc3VlciZxdW90OyA8YnI+DQom
Z3Q7ICZndDsgJmd0OyBzaG91bGQgYmUgcmVzb3VyY2Ugb3duZXIsIHdoaWxlIGFzc2VydGlvbiBk
b2N1bWVudCBvbmx5DQppbmNsdWRlcyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBjbGllbnQgYW5kIHRv
a2VuIHNlcnZpY2UgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSW4g
bXkgdXNlIGNhc2UgdGhlICZxdW90O2Fzc2VydGlvbiZxdW90OyBpcyBtb3JlIGxpa2UgYQ0KcHJp
dmF0ZSBvdXRwdXQsIHdoaWxlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGluIGFzc2VydGlvbiBmbG93
ICZxdW90O2Fzc2VydGlvbiAmcXVvdDsgaXMgZ2VuZXJhdGVkIGJ5DQphIHRocmlkIHBhcnR5IHRv
a2VuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHNlcnZpY2Ugb3IgYnkgY2xpZW50IGl0c2VsZi4gPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTmF0IFNha2ltdXJhICZsdDtz
YWtpbXVyYUBnbWFpbC5jb20mZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDIwMTItMTItMDMgMTQ6
NDQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgytW8/sjLIDxicj4N
CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IHpob3Uuc3VqaW5nQHp0ZS5jb20u
Y24gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgs63LzSA8YnI+DQom
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmcXVvdDtvYXV0aEBpZXRmLm9yZyBX
RyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7INb3zOIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgUmU6IFJlOiBbT0FVVEgtV0ddIEhpLGFueSBjb21tZW50IG9uIGRyYWZ0LXpob3Utb2F1
dGgtb3duZXItYXV0aD8NCjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
IFlvdXIgdXNlY2FzZSBzb3VuZHMgYSBsaXR0bGUgYml0IGxpa2UgdGhlIGFzc2VydGlvbiBmbG93
Lg0KJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIFJPIGlzc3VlcyBhbiBhc3NlcnRpb24g
YW5kIHRoZSByZXN0IGdvZXMuICZuYnNwOzxicj4NCiZndDsgJmd0OyAmZ3Q7IElzIHRoZXJlIHJl
YXNvbnMgdGhhdCBhbiBhc3NlcnRpb24gZmxvdyBjYW5ub3QgZG8/ICZuYnNwOzxicj4NCiZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE5hdDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgJmd0OyBPbiBNb24sIERlYyAzLCAyMDEyIGF0IDM6MzUgUE0sICZsdDt6aG91LnN1
amluZ0B6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IG15IHVzZSBj
YXNlKFJPLWluaXRpYXRlZCBkZWxlZ2F0aW9uKTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLUkgZGVw
b3NpdCBteSBjaGlsZChwcmVjaW91cyByZXNvdXJjZSkgYXQga2luZGVyZ2FyZGVuKFJlc291cmNl
DQpTZXJ2ZXIpIDxicj4NCiZndDsgJmd0OyAmZ3Q7IC1JIGRlbGVnYXRlIGEgZmV3IHBlcnNvbnMs
ZS5nLiwgZ3JhbmRwYXJlbnRzIG9mIG15IGNoaWxkLA0KdG8gcGljayB1cDxicj4NCiZndDsgJmd0
OyAmZ3Q7IG15IGNoaWxkIGF0IHRoZSBraW5kZXJnYXJkZW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
LXdoZW4gc29tZW9uZSB0cmllcyB0byB0YWtlIGhpbSBvdXRzaWRlIG9mIHRoZSBraW5kZXJnYXJk
ZW4sDQombmJzcDt0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGVhY2hlciB3aWxsIGFzayBoaW0v
aGVyIHRvIHNob3cgbXkgZGVsZWdhdGlvbiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDtzdGF0
ZW1lbnQsIG5vIHN0YXRlbWVudCwgbm8gdGFraW5nIG15IGNoaWxkLiA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTmF0IFNha2ltdXJhICg9bmF0KSA8YnI+DQom
Z3Q7ICZndDsgJmd0OyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQomZ3Q7ICZndDsg
Jmd0OyBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+DQomZ3Q7ICZndDsgJmd0OyBAX25hdF9l
biBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn
dDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8
YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aDwvZm9udD48L3R0Pg0K
--=_alternative 002EF7A148257ACB_=--

From bcampbell@pingidentity.com  Wed Dec  5 06:05:59 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCE321F8BC7 for ; Wed,  5 Dec 2012 06:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.139
X-Spam-Level: 
X-Spam-Status: No, score=-4.139 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWHtFhhiM-Bh for ; Wed,  5 Dec 2012 06:05:57 -0800 (PST)
Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACC421F8BD3 for ; Wed,  5 Dec 2012 06:05:56 -0800 (PST)
Received: from mail-yh0-f71.google.com ([209.85.213.71]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUL9UxMHtvMuVO9NeXceBt5+pXRtKWoou@postini.com; Wed, 05 Dec 2012 06:05:57 PST
Received: by mail-yh0-f71.google.com with SMTP id j63so3214665yhj.6 for ; Wed, 05 Dec 2012 06:05:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=4vDWApPADYDLv49ZkM+hk7Hhh/sHR+Vm1IN3vpBQv1s=; b=duofVxMPzBwrRFW1awqR/hBYVEqNJZRoWp//O43hByfbJnnr4e8kGctG26ClLVPrON edrUQCM0oxqLjnKqCbik8uXT+QiRXPA4/+yn16dljD+zaWSxlgpTdphNRnJJU5fsbAdr +TfMHGyE4r0lBN6J1Vp5M2bBPh0CVS+86MP5gd/JodXnfrseRzYTwuTLmOAqVVcS68TV Kif/scSKhemGpjED0e1lYCjyng8KcmNxXQ71wkQ0xG6ywZENzZRM9p+MkN6Ohf5Ob85q SlGV9+hz93jWtneC0EjDzzeoN3br2VbcfO+UcLL46RSY5w/F2rtab+zAEiQ07TtmaPBV 63Fg==
Received: by 10.52.19.20 with SMTP id a20mr13598244vde.26.1354716356009; Wed, 05 Dec 2012 06:05:56 -0800 (PST)
Received: by 10.52.19.20 with SMTP id a20mr13598226vde.26.1354716355851; Wed, 05 Dec 2012 06:05:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.163.170 with HTTP; Wed, 5 Dec 2012 06:05:25 -0800 (PST)
In-Reply-To: 
References:  
From: Brian Campbell 
Date: Wed, 5 Dec 2012 07:05:25 -0700
Message-ID: 
To: zhou.sujing@zte.com.cn
Content-Type: multipart/alternative; boundary=bcaec504083829776c04d01b7b2e
X-Gm-Message-State: ALoCoQmgMhj+TtWrQPaIRB9SI7x+XlFcoxIf/DWw6ZzsVXtFwmtlypgjjol6yr5FMX/dCnK8iFqH9lm8bLNuo22+KUdcEVKikfc3Lkkkv+lxds9di3/soWuzjmdpR6F0i6B3n9sheiBP
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 14:05:59 -0000

--bcaec504083829776c04d01b7b2e
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

I say that it's only theoretical because I don't believe there are any
actual deployments supporting, or planning on supporting, RO as an
assertion issuer.


On Tue, Dec 4, 2012 at 5:39 PM,  wrote:

>
> Why RO as an issuer is only theoretical today?
>
>
>  *Brian Campbell *
>
> 2012-12-04 23:41
>   =CA=D5=BC=FE=C8=CB
> Nat Sakimura 
> =B3=AD=CB=CD
> zhou.sujing@zte.com.cn, "oauth@ietf.org" 
> =D6=F7=CC=E2
> Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either th=
e
> client or a third party token service?
>
>
>
>
> The intent was definitely not to constrain who/what could be the issuer.
>  But also try to provide
> some guidance around the common cases that are actually being deployed
> now, which are the client self-issued and STS variants. Resource owner as
> an issuer is an interesting case but seems mostly theoretical at this poi=
nt.
>
> I feel like mentioning the resource owner there in =A1=EC5.1 would cause =
more
> confusion than anything else. I'd prefer to just strike the whole sentenc=
e
> in question and maybe add some additional text to =A1=EC3 that clarifies =
that
> the issuer can really be any entity, if folks think a change is needed
> here?
>
>
>
> On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura <*sakimura@gmail.com*>
> wrote:
> Actually, "The issuer may be either
>       an OAuth client (when assertions are self-issued) or any other
> entity, e.g.,  a third party
> token service, resource owner. "  is not really clean.
>
> OAuth client is just another example of an issuer.
>
> So, perhaps the sentence could be:
>
> "Example of issuers include an OAuth client, resource owner, an
> independent third party."
>
> So, the clause becomes:
>
>  Issuer  The unique identifier for the entity that issued the
>      assertion.  Generally this is the entity that holds the key
>      material used to generate the assertion.
>       Example of issuers include an OAuth client, resource owner, an
> independent third party.
>
> Nat
>
> Nat
>
> On Tue, Dec 4, 2012 at 11:40 AM, <*zhou.sujing@zte.com.cn*>
> wrote:
>
>
>
> Chuck Mortimore <*cmortimore@salesforce.com* >
> =D0=B4=D3=DA 2012-12-04 10:26:50:
>
>
> > Please feel free to suggest better language.
>
> >
> > Issuer simply allows the token service to know who created the
> > assertion, so it can look them up and see if they're trusted.
> > Effectively the same as an Issuer in SAML.
>
> a conflict : "The token service is the assertion issuer" in assertion
> document.
> while you said "token service know who created the assertion"
>
> I wonder if the following text is acceptable:
>
>  Issuer  The unique identifier for the entity that issued the
>      assertion.  Generally this is the entity that holds the key
>      material used to generate the assertion.  The issuer may be either
>       an OAuth client (when assertions are self-issued) or any other
> entity, e.g.,  a third party
> token service, resource owner.
>
>
> 6.3.  Client Acting on Behalf of a User
>
> The Issuer of the assertion MUST identify the entity that issued
>      the assertion as recognized by the Authorization Server.  If the
>      assertion is self-issued, the Issuer SHOULD be the "client_id".
>      If the assertion was issued by a Security Token Service (STS), the
>      Issuer SHOULD identify the STS as recognized by the Authorization
>      Server.If the assertion was issued by the resource owner, the
>      Issuer SHOULD identify the resource owner as recognized by the
> Authorization
>      Server.
>
> >
> > -cmort
> >
> > On Dec 3, 2012, at 6:23 PM, <*zhou.sujing@zte.com.cn*>
> wrote:
> >
> >
> > Obviously, it is not so clear from the language there.
> >
> >
> > Chuck Mortimore <*cmortimore@salesforce.com* >
> =D0=B4=D3=DA 2012-12-04 10:17:12:
> >
> > > There's no reason why it can't be resource owner today.
> > >
> > > On Dec 3, 2012, at 6:06 PM, <*zhou.sujing@zte.com.cn*>
> <*zhou.sujing@zte.com.cn* 
> > > > wrote:
> > >
> > >
> > > +1.
> > > And why it was not looked at that time?
> > >
> > > *oauth-bounces@ietf.org*  =D0=B4=D3=DA 2012-1=
2-04
> 01:30:55:
> > >
> > > > Actually, I think it is a good time to start looking at the resours=
e
> > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had brough=
t
> > > > this up a couple of years ago.)
> > > >
> > > > Igor
> > > >
> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:
> > > > I suppose, yes. I was reading it like that all the time.
> > > > Whether it is or not, if it is still ok, it might be better to
> > clarify it.
> > > > Word like "third party" tends to be a bit of problem without
> > > clearlydefining.
> > > > I had similar experience in other fora.
> > > >
> > > > Nat
> > > >
> > > > Sent from iPad
> > > >
> > > > 2012/12/03 0:52=A1=A2"*zhou.sujing@zte.com.cn* "
> <*zhou.sujing@zte.com.cn* > =A4=CE
> > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:
> > >
> > > >
> > > > could be Resource owner?
> > > >
> > >
> > > >
> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" <*hannes.tschofenig@nsn.com*<=
hannes.tschofenig@nsn.com>>
>
> > > > =B7=A2=BC=FE=C8=CB:  *oauth-bounces@ietf.org* 
> > > > 2012-12-03 16:49
> > > >
> > > > =CA=D5=BC=FE=C8=CB
> > > >
> > > > "ext Nat Sakimura" <*sakimura@gmail.com* >,
> "Brian Campbell" <
> > > > *bcampbell@pingidentity.com* >, "oauth"
> <*oauth@ietf.org* >
> > > >
> > > > =B3=AD=CB=CD
> > > >
> > > > =D6=F7=CC=E2
> > > >
> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
> > > > either the client or a third party token service?
> > > >
> > > >
> > > >
> > > >
> > > > Hi Nat,
> > > >
> > > > The current text essentially says that the assertion can either be
> > > > created by the client (in which case it is self-signed) or it can b=
e
> > > > created by some other entity (which is then called the third party
> > > > token service). So, this third party could be the authorization
> server.
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > >
> > > > From: *oauth-bounces@ietf.org*  [mailto:*
> oauth-bounces@ietf.org* ] On Behalf Of
> > > > ext Nat Sakimura
> > > > Sent: Monday, December 03, 2012 10:35 AM
> > > > To: Brian Campbell; oauth
> > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to b=
e
> > > > either the client or a third party token service?
> > > >
> > > > Hi Brian,
> > > >
> > > >
> > > > The assertion framework defines the Issuer as:
> > > >
> > > >    Issuer  The unique identifier for the entity that issued the
> > > >       assertion.  Generally this is the entity that holds the key
> > > >       material used to generate the assertion.  The issuer may be
> either
> > > >       an OAuth client (when assertions are self-issued) or a third
> party
> > > >       token service.
> > > >
> > > > I was wondering why it has to be either the client or a third party
> > > > token service.
> > > > Conceptually, it could be any token service (functionality)
> > > residingin any of
> > > >
> > > > the stakeholders (Resource Owner, OAuth Client, Authorization
> Server, or
> > > > a third party).
> > > >
> > > >
> > > > I would appreciate if you could clarify why is the case.
> > > >
> > > >
> > > > Best,
> > > >
> > > > --
> > > > Nat Sakimura (=3Dnat)
> > > > Chairman, OpenID Foundation
> > > > *http://nat.sakimura.org/* 
> > > > @_nat_en
> > > >  _______________________________________________
> > > > OAuth mailing list
> > > > *OAuth@ietf.org* 
> > > > *https://www.ietf.org/mailman/listinfo/oauth*
> > >
> > > >
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > *OAuth@ietf.org* 
> > > > *https://www.ietf.org/mailman/listinfo/oauth*
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > *OAuth@ietf.org* 
> > > > *https://www.ietf.org/mailman/listinfo/oauth*
> > > _______________________________________________
> > > OAuth mailing list
> > > *OAuth@ietf.org* 
> > > *https://www.ietf.org/mailman/listinfo/oauth*
>
> _______________________________________________
> OAuth mailing list*
> **OAuth@ietf.org* *
> **https://www.ietf.org/mailman/listinfo/oauth*
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation*
> **http://nat.sakimura.org/* 
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list*
> **OAuth@ietf.org* *
> **https://www.ietf.org/mailman/listinfo/oauth*
>
>
>

--bcaec504083829776c04d01b7b2e
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

I say that it's only theoretical because I don't believe there are =
any actual deployments supporting, or planning on supporting, RO as an assertion issuer. 




On Tue, Dec 4, 2012 at 5:39 PM,  <=
zhou.sujing@zte.com.cn> wrote:




Why RO as an issuer is only theoretical
today?










Brian Campbell &l=
t;bcampbell=
@pingidentity.com>


2012-12-04 23:41








=CA=D5=BC=FE=C8=
=CB

Nat Sakimura <sakimura@gmail.com>




=B3=AD=CB=CD

zhou.sujing@zte.com.cn, "oauth@ietf.org"
<oauth@ietf.org&=
gt;




=D6=F7=CC=E2

Re: [OAUTH-WG] Assertion Fram=
ework -
Why does issuer have to be either the client or a third party token service=
?

















The intent was definitely not to c=
onstrain
who/what could be the issuer.  But also try to provide 

some guidance around the common cases that are actually being deployed
now, which are the client self-issued and STS variants. Resource owner
as an issuer is an interesting case but seems mostly theoretical at this
point.



I feel like mentioning the resource owner there in =A1=EC5.1 would cause mo=
re
confusion than anything else. I'd prefer to just strike the whole sente=
nce
in question and maybe add some additional text to =A1=EC3 that clarifies th=
at
the issuer can really be any entity, if folks think a change is needed
here? 







On Mon, Dec 3, 2012 at 9:20 PM, Na=
t
Sakimura <sakimura@gmail.com<=
/u>>
wrote:

Actually, "The
issuer may be either 

  &nbs=
p;  
an OAuth client (when assertions are self-issued) or
any other entity, e.g.,  a
third party 

token service<=
font color=3D"red" face=3D"Arial" size=3D"3">,
resource owner. &q=
uot;  is
not really clean. 



OAuth client is just =
another
example of an issuer. 



So, perhaps the sente=
nce could
be: 



"Example of issu=
ers include
an OAuth client, resource owner, an independent third party."



So, the clause become=
s: 



 Issuer  The unique=
 identifier
for the entity that issued the =


      assertion.  Generally this is the entity that
holds the key 

      material used to generate the assertion.  

      Example =
of
issuers include an OAuth client, resource owner, an independent third party=
.




Nat



Nat



On Tue, Dec 4, 2012 at 11:40 AM, &=
lt;zhou.sujing@zte.com.cn>
wrote:







Chuck Mortimore <cmortimore@sales=
force.com>
=D0=B4=D3=DA 2012-12-04 10:26:50:





> Please feel free to suggest better language.



> 

> Issuer simply allows the token service to know who created the 

> assertion, so it can look them up and see if they're trusted. &nbs=
p;
  

> Effectively the same as an Issuer in SAML.




a conflict : "The token service is the assert=
ion
issuer" in assertion document.


while you said "token service know who created the assertion"




I wonder if the following text is acceptable:


 


  Issuer  The unique identifier for the entity that issued the


      assertion.  Generally this is the entity that
holds the key 

      material used to generate the assertion.  The
issuer may be either 

      an OAuth=
 client
(when assertions are self-issued) or
any other entity, e.g.,  a
third party 

token service, re=
source
owner. 





6.3.  Client Acting on Behalf of a User




The Issuer of the assertion MUST identify the entity that issued


      the assertion as recognized by the Authorization Serve=
r.
 If the 

      assertion is self-issued, the Issuer SHOULD be the
"client_id". 

      If the assertion was issued by a Security Token Servic=
e
(STS), the 

      Issuer SHOULD identify the STS as recognized by the
Authorization <=
font size=3D"3">

      Server.=
If the
assertion was issued by the resource owner, the


      Issuer SHOULD identify the resource owner as recognize=
d
by the Authorization 

      Server.




> 

> -cmort 

> 

> On Dec 3, 2012, at 6:23 PM, <zh=
ou.sujing@zte.com.cn>
wrote: 

> 

> 

> Obviously, it is not so clear from the language there. 

> 

> 

> Chuck Mortimore <cmortimore@=
salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:17:12:

> 

> > There's no reason why it can't be resource owner today. &=
nbsp;


> > 

> > On Dec 3, 2012, at 6:06 PM, <=
zhou.sujing@zte.com.cn>
<zhou.sujing@zte.com.cn

> > > wrote: 

> > 

> > 

> > +1. 

> > And why it was not looked at that time? 

> > 

> > oauth-bounces@ietf.org
=D0=B4=D3=DA 2012-12-04 01:30:55:

> > 

> > > Actually, I think it is a good time to start looking at
the resourse

> > > owner issuing assertions@ (Interestingly enough, Hui-Lan
had brought

> > > this up a couple of years ago.)

> > > 

> > > Igor

> > > 

> > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: 

> > > I suppose, yes. I was reading it like that all the time.


> > > Whether it is or not, if it is still ok, it might be better
to 

> clarify it. 

> > > Word like "third party" tends to be a bit of probl=
em
without 

> > clearlydefining. 

> > > I had similar experience in other fora. 

> > > 

> > > Nat 

> > > 

> > > Sent from iPad 

> > > 

> > > 2012/12/03 0:52=A1=A2"=
zhou.sujing@zte.com.cn"
<zhou.sujing@zte.com.cn>
=A4=CE

> > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:

> > 

> > > 

> > > could be Resource owner? 

> > > 

> > 

> > > 

> > > "Tschofenig, Hannes (NSN - FI/Espoo)" <<=
/tt>hannes.tschofenig@nsn.com>


> > > =B7=A2=BC=FE=C8=CB:  <=
u>oauth-bounces@ietf.org


> > > 2012-12-03 16:49 

> > > 

> > > =CA=D5=BC=FE=C8=CB 

> > > 

> > > "ext Nat Sakimura" <sakimura@gmail.com>,
"Brian Campbell" <

> > > bcampbell@pingidenti=
ty.com>,
"oauth" <oauth@ietf.org>


> > > 

> > > =B3=AD=CB=CD 

> > > 

> > > =D6=F7=CC=E2 

> > > 

> > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have
to be     

> > > either the client or a third party token service? 

> > > 

> > > 

> > > 

> > > 

> > > Hi Nat, 

> > >   

> > > The current text essentially says that the assertion can
either be 

> > > created by the client (in which case it is self-signed)
or it can be

> > > created by some other entity (which is then called the third
party 

> > > token service). So, this third party could be the authorizat=
ion
server. 

> > >   

> > > Ciao

> > > Hannes 

> > >   

> > >   

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

> > > ext Nat Sakimura

> > > Sent: Monday, December 03, 2012 10:35 AM

> > > To: Brian Campbell; oauth

> > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer
have to be

> > > either the client or a third party token service? 

> > >   

> > > Hi Brian, 

> > >   

> > >   

> > > The assertion framework defines the Issuer as: 

> > >   

> > >    Issuer  The unique identifier for the
entity that issued the 

> > >       assertion.  Generally this is
the entity that holds the key 

> > >       material used to generate the assertion=
.
 The issuer may be either 

> > >       an OAuth client (when assertions are
self-issued) or a third party 

> > >       token service. 

> > >   

> > > I was wondering why it has to be either the client or a
third party 

> > > token service. 

> > > Conceptually, it could be any token service (functionality)


> > residingin any of 

> > >   

> > > the stakeholders (Resource Owner, OAuth Client, Authorizatio=
n
Server, or 

> > > a third party). 

> > >   

> > >   

> > > I would appreciate if you could clarify why is the case.


> > >   

> > >   

> > > Best, 

> > >   

> > > -- 

> > > Nat Sakimura (=3Dnat) 

> > > Chairman, OpenID Foundation

> > > http://nat.sakimura.org/<=
/font>

> > > @_nat_en 

> > >  _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

> > > https://ww=
w.ietf.org/mailman/listinfo/oauth<=
br>
> > 

> > > 

> > > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

> > > https://ww=
w.ietf.org/mailman/listinfo/oauth<=
br>
> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

> > > https://ww=
w.ietf.org/mailman/listinfo/oauth<=
br>
> > _______________________________________________

> > OAuth mailing list

> > <=
tt>OAuth@ietf.org

> > https://www.iet=
f.org/mailman/listinfo/oauth




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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











-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation=


http://nat.sakimura.org/<=
/font>

@_nat_en





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












--bcaec504083829776c04d01b7b2e--

From Adam.Lewis@motorolasolutions.com  Wed Dec  5 06:49:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4141821F8CCA for ; Wed,  5 Dec 2012 06:49:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.135
X-Spam-Level: 
X-Spam-Status: No, score=0.135 tagged_above=-999 required=5 tests=[AWL=-3.602,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qsi0xfIdbC50 for ; Wed,  5 Dec 2012 06:49:33 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id F32BC21F8CC2 for ; Wed,  5 Dec 2012 06:49:28 -0800 (PST)
Received: from mail22-ch1-R.bigfish.com (10.43.68.225) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Dec 2012 14:49:27 +0000
Received: from mail22-ch1 (localhost [127.0.0.1])	by mail22-ch1-R.bigfish.com (Postfix) with ESMTP id 9EAA0C0235	for ; Wed,  5 Dec 2012 14:49:27 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.188.136.18; KIP:(null); UIP:(null); IPV:NLI; H:il06msg02.am.mot-solutions.com; RD:none; EFVD:NLI
X-SpamScore: -32
X-BigFish: VPS-32(zzbb2dI98dI9371Ic89bh936eI1454Ic85bhc3f2M1521I1432Izz1de0h1202h1d1ah1d2ahzz1033IL18c58eh6d524h17326ah8275bh8275dh18c673h110f33hz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1155h)
Received-SPF: pass (mail22-ch1: domain of motorolasolutions.com designates 129.188.136.18 as permitted sender) client-ip=129.188.136.18; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg02.am.mot-solutions.com ; olutions.com ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.232.197; KIP:(null); UIP:(null); (null); H:BLUPRD0411HT001.namprd04.prod.outlook.com; R:internal; EFV:INT
Received: from mail22-ch1 (localhost.localdomain [127.0.0.1]) by mail22-ch1 (MessageSwitch) id 1354718965505992_2408; Wed,  5 Dec 2012 14:49:25 +0000 (UTC)
Received: from CH1EHSMHS011.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250])	by mail22-ch1.bigfish.com (Postfix) with ESMTP id 67CF74C0058 for ; Wed,  5 Dec 2012 14:49:25 +0000 (UTC)
Received: from il06msg02.am.mot-solutions.com (129.188.136.18) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Dec 2012 14:49:24 +0000
Received: from il06msg02.am.mot-solutions.com (il06vts02.mot.com [129.188.137.142])	by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qB5EnMR7022640	for ; Wed, 5 Dec 2012 09:49:22 -0500 (EST)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206])	by il06msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qB5En1I8022597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)	for ; Wed, 5 Dec 2012 09:49:15 -0500 (EST)
Received: from mail86-am1-R.bigfish.com (10.3.201.234) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 5 Dec 2012 14:48:58 +0000
Received: from mail86-am1 (localhost [127.0.0.1])	by mail86-am1-R.bigfish.com (Postfix) with ESMTP id E64F940149	for ; Wed,  5 Dec 2012 14:48:57 +0000 (UTC)
Received: from mail86-am1 (localhost.localdomain [127.0.0.1]) by mail86-am1 (MessageSwitch) id 1354718935400782_8288; Wed,  5 Dec 2012 14:48:55 +0000 (UTC)
Received: from AM1EHSMHS014.bigfish.com (unknown [10.3.201.238])	by mail86-am1.bigfish.com (Postfix) with ESMTP id 5E86F4800AD; Wed,  5 Dec 2012 14:48:55 +0000 (UTC)
Received: from BLUPRD0411HT001.namprd04.prod.outlook.com (157.56.232.197) by AM1EHSMHS014.bigfish.com (10.3.207.152) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 5 Dec 2012 14:48:50 +0000
Received: from BLUPRD0411MB436.namprd04.prod.outlook.com ([169.254.9.195]) by BLUPRD0411HT001.namprd04.prod.outlook.com ([10.255.127.36]) with mapi id 14.16.0245.002; Wed, 5 Dec 2012 14:48:49 +0000
From: Lewis Adam-CAL022 
To: Brian Campbell , "zhou.sujing@zte.com.cn" 
Thread-Topic: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Thread-Index: AQHN0vG+ArF/isYTKUGOaC3W4kM6j5gKSGFQ
Date: Wed, 5 Dec 2012 14:48:49 +0000
Message-ID: <59E470B10C4630419ED717AC79FCF9A92F1A9015@BLUPRD0411MB436.namprd04.prod.outlook.com>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [150.130.61.90]
Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A92F1A9015BLUPRD0411MB436_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%ZTE.COM.CN$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-CFilter-Loop: Reflected
X-OriginatorOrg: motorolasolutions.com
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 14:49:35 -0000

--_000_59E470B10C4630419ED717AC79FCF9A92F1A9015BLUPRD0411MB436_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgQnJpYW4sDQoNClRoaXMgaXMgc29ydCBvZiBteSBmZWVsaW5nIG9uIHRoZSBTVFMgYXMgd2Vs
bCAodGhlb3JldGljYWwpLiAgQXJlIHRoZXJlIGFueSByZWFsLWxpZmUgZXhhbXBsZXMgb2Ygb2J0
YWluaW5nIGEgSldUIGFzc2VydGlvbiBmcm9tIGFuIFNUUyB0aGF0IGNhbiBiZSB1c2VkIGZvciB0
aGUgYXNzZXJ0aW9uIGZsb3c/ICBBbmQgaWYgc28gdGhlbiBob3cgaXMgaXQgb2J0YWluZWQ/ICBJ
dCBjYW5ub3QgYmUgYW4gaWRfdG9rZW4gYmVjYXVzZSB0aGF0IGlzIGF1ZGllbmNlIHJlc3RyaWN0
ZWQgdG8gdGhlIGNsaWVudC4gIEkgZ3Vlc3MgaXQgY291bGQgYmUgYW4gYWNjZXNzX3Rva2VuIHdp
dGggYSBzY29wZSBvZiBhc3NlcnRpb24/ICBCdXQgSaGvdmUgbm90IHNlZW4gYW55IGRpc2N1c3Np
b24gb2YgdGhhdC4gIEmhr3ZlIGJlZW4gaW50ZXJlc3RlZCBpbiB0aGlzIGZsb3cgZm9yIGEgd2hp
bGUgYnV0IHRoZSBvbmx5IGV4YW1wbGVzIEmhr20gYXdhcmUgb2YgYXJlIHNlbGYtaXNzdWVkIEpX
VHMuICBJoa9kIGJlIHZlcnkgaW50ZXJlc3RlZCBpbiBrbm93aW5nIHJlYWwgbGlmZSBvZiBleGFt
cGxlcyBvZiBjbGllbnRzIG9idGFpbmluZyBhIEpXVCBhc3NlcnRpb24gZnJvbSBhbiBTVFMgdG8g
dXNlIGFzIGEgZ3JhbnQsIGFuZCB0aGUgbWV0aG9kIHRoZXkgdXNlIHRvIGRvIHRoYXQuDQoNCnR4
DQphZGFtDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFdlZG5lc2Rh
eSwgRGVjZW1iZXIgMDUsIDIwMTIgODowNSBBTQ0KVG86IHpob3Uuc3VqaW5nQHp0ZS5jb20uY24N
CkNjOiBvYXV0aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZy
YW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlIHRvIGJlIGVpdGhlciB0aGUgY2xpZW50IG9y
IGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT8NCg0KSSBzYXkgdGhhdCBpdCdzIG9ubHkgdGhl
b3JldGljYWwgYmVjYXVzZSBJIGRvbid0IGJlbGlldmUgdGhlcmUgYXJlIGFueSBhY3R1YWwgZGVw
bG95bWVudHMgc3VwcG9ydGluZywgb3IgcGxhbm5pbmcgb24gc3VwcG9ydGluZywgUk8gYXMgYW4g
YXNzZXJ0aW9uIGlzc3Vlci4NCg0KT24gVHVlLCBEZWMgNCwgMjAxMiBhdCA1OjM5IFBNLCA8emhv
dS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbj4+IHdyb3Rl
Og0KDQpXaHkgUk8gYXMgYW4gaXNzdWVyIGlzIG9ubHkgdGhlb3JldGljYWwgdG9kYXk/DQoNCkJy
aWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxs
QHBpbmdpZGVudGl0eS5jb20+Pg0KDQoyMDEyLTEyLTA0IDIzOjQxDQoNCsrVvP7Iyw0KDQpOYXQg
U2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbTxtYWlsdG86c2FraW11cmFAZ21haWwuY29tPj4N
Cg0Ks63LzQ0KDQp6aG91LnN1amluZ0B6dGUuY29tLmNuPG1haWx0bzp6aG91LnN1amluZ0B6dGUu
Y29tLmNuPiwgIm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4iIDxvYXV0aEBp
ZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KDQrW98ziDQoNClJlOiBbT0FVVEgtV0dd
IEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZSBlaXRoZXIg
dGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/DQoNCg0KDQoNCg0KDQoN
ClRoZSBpbnRlbnQgd2FzIGRlZmluaXRlbHkgbm90IHRvIGNvbnN0cmFpbiB3aG8vd2hhdCBjb3Vs
ZCBiZSB0aGUgaXNzdWVyLiAgQnV0IGFsc28gdHJ5IHRvIHByb3ZpZGUNCnNvbWUgZ3VpZGFuY2Ug
YXJvdW5kIHRoZSBjb21tb24gY2FzZXMgdGhhdCBhcmUgYWN0dWFsbHkgYmVpbmcgZGVwbG95ZWQg
bm93LCB3aGljaCBhcmUgdGhlIGNsaWVudCBzZWxmLWlzc3VlZCBhbmQgU1RTIHZhcmlhbnRzLiBS
ZXNvdXJjZSBvd25lciBhcyBhbiBpc3N1ZXIgaXMgYW4gaW50ZXJlc3RpbmcgY2FzZSBidXQgc2Vl
bXMgbW9zdGx5IHRoZW9yZXRpY2FsIGF0IHRoaXMgcG9pbnQuDQoNCkkgZmVlbCBsaWtlIG1lbnRp
b25pbmcgdGhlIHJlc291cmNlIG93bmVyIHRoZXJlIGluIKHsNS4xIHdvdWxkIGNhdXNlIG1vcmUg
Y29uZnVzaW9uIHRoYW4gYW55dGhpbmcgZWxzZS4gSSdkIHByZWZlciB0byBqdXN0IHN0cmlrZSB0
aGUgd2hvbGUgc2VudGVuY2UgaW4gcXVlc3Rpb24gYW5kIG1heWJlIGFkZCBzb21lIGFkZGl0aW9u
YWwgdGV4dCB0byCh7DMgdGhhdCBjbGFyaWZpZXMgdGhhdCB0aGUgaXNzdWVyIGNhbiByZWFsbHkg
YmUgYW55IGVudGl0eSwgaWYgZm9sa3MgdGhpbmsgYSBjaGFuZ2UgaXMgbmVlZGVkIGhlcmU/DQoN
Cg0KDQpPbiBNb24sIERlYyAzLCAyMDEyIGF0IDk6MjAgUE0sIE5hdCBTYWtpbXVyYSA8c2FraW11
cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiB3cm90ZToNCkFjdHVhbGx5
LCAiVGhlIGlzc3VlciBtYXkgYmUgZWl0aGVyDQogICAgICBhbiBPQXV0aCBjbGllbnQgKHdoZW4g
YXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9yIGFueSBvdGhlciBlbnRpdHksIGUuZy4sICBh
IHRoaXJkIHBhcnR5DQp0b2tlbiBzZXJ2aWNlLCByZXNvdXJjZSBvd25lci4gIiAgaXMgbm90IHJl
YWxseSBjbGVhbi4NCg0KT0F1dGggY2xpZW50IGlzIGp1c3QgYW5vdGhlciBleGFtcGxlIG9mIGFu
IGlzc3Vlci4NCg0KU28sIHBlcmhhcHMgdGhlIHNlbnRlbmNlIGNvdWxkIGJlOg0KDQoiRXhhbXBs
ZSBvZiBpc3N1ZXJzIGluY2x1ZGUgYW4gT0F1dGggY2xpZW50LCByZXNvdXJjZSBvd25lciwgYW4g
aW5kZXBlbmRlbnQgdGhpcmQgcGFydHkuIg0KDQpTbywgdGhlIGNsYXVzZSBiZWNvbWVzOg0KDQog
SXNzdWVyICBUaGUgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQg
dGhlDQogICAgIGFzc2VydGlvbi4gIEdlbmVyYWxseSB0aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBo
b2xkcyB0aGUga2V5DQogICAgIG1hdGVyaWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlv
bi4NCiAgICAgIEV4YW1wbGUgb2YgaXNzdWVycyBpbmNsdWRlIGFuIE9BdXRoIGNsaWVudCwgcmVz
b3VyY2Ugb3duZXIsIGFuIGluZGVwZW5kZW50IHRoaXJkIHBhcnR5Lg0KDQpOYXQNCg0KTmF0DQoN
Ck9uIFR1ZSwgRGVjIDQsIDIwMTIgYXQgMTE6NDAgQU0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNu
PG1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPj4gd3JvdGU6DQoNCg0KDQpDaHVjayBNb3J0
aW1vcmUgPGNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208bWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNm
b3JjZS5jb20+PiDQtNPaIDIwMTItMTItMDQgMTA6MjY6NTA6DQoNCg0KPiBQbGVhc2UgZmVlbCBm
cmVlIHRvIHN1Z2dlc3QgYmV0dGVyIGxhbmd1YWdlLg0KDQo+DQo+IElzc3VlciBzaW1wbHkgYWxs
b3dzIHRoZSB0b2tlbiBzZXJ2aWNlIHRvIGtub3cgd2hvIGNyZWF0ZWQgdGhlDQo+IGFzc2VydGlv
biwgc28gaXQgY2FuIGxvb2sgdGhlbSB1cCBhbmQgc2VlIGlmIHRoZXkncmUgdHJ1c3RlZC4NCj4g
RWZmZWN0aXZlbHkgdGhlIHNhbWUgYXMgYW4gSXNzdWVyIGluIFNBTUwuDQoNCmEgY29uZmxpY3Qg
OiAiVGhlIHRva2VuIHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbiBpc3N1ZXIiIGluIGFzc2VydGlv
biBkb2N1bWVudC4NCndoaWxlIHlvdSBzYWlkICJ0b2tlbiBzZXJ2aWNlIGtub3cgd2hvIGNyZWF0
ZWQgdGhlIGFzc2VydGlvbiINCg0KSSB3b25kZXIgaWYgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIGFj
Y2VwdGFibGU6DQoNCiBJc3N1ZXIgIFRoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIGVudGl0
eSB0aGF0IGlzc3VlZCB0aGUNCiAgICAgYXNzZXJ0aW9uLiAgR2VuZXJhbGx5IHRoaXMgaXMgdGhl
IGVudGl0eSB0aGF0IGhvbGRzIHRoZSBrZXkNCiAgICAgbWF0ZXJpYWwgdXNlZCB0byBnZW5lcmF0
ZSB0aGUgYXNzZXJ0aW9uLiAgVGhlIGlzc3VlciBtYXkgYmUgZWl0aGVyDQogICAgICBhbiBPQXV0
aCBjbGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9yIGFueSBvdGhlciBl
bnRpdHksIGUuZy4sICBhIHRoaXJkIHBhcnR5DQp0b2tlbiBzZXJ2aWNlLCByZXNvdXJjZSBvd25l
ci4NCg0KDQo2LjMuICBDbGllbnQgQWN0aW5nIG9uIEJlaGFsZiBvZiBhIFVzZXINCg0KVGhlIElz
c3VlciBvZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVudGl0eSB0aGF0IGlzc3Vl
ZA0KICAgICB0aGUgYXNzZXJ0aW9uIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24g
U2VydmVyLiAgSWYgdGhlDQogICAgIGFzc2VydGlvbiBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3Vl
ciBTSE9VTEQgYmUgdGhlICJjbGllbnRfaWQiLg0KICAgICBJZiB0aGUgYXNzZXJ0aW9uIHdhcyBp
c3N1ZWQgYnkgYSBTZWN1cml0eSBUb2tlbiBTZXJ2aWNlIChTVFMpLCB0aGUNCiAgICAgSXNzdWVy
IFNIT1VMRCBpZGVudGlmeSB0aGUgU1RTIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRp
b24NCiAgICAgU2VydmVyLklmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSB0aGUgcmVzb3Vy
Y2Ugb3duZXIsIHRoZQ0KICAgICBJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSByZXNvdXJjZSBv
d25lciBhcyByZWNvZ25pemVkIGJ5IHRoZSBBdXRob3JpemF0aW9uDQogICAgIFNlcnZlci4NCg0K
Pg0KPiAtY21vcnQNCj4NCj4gT24gRGVjIDMsIDIwMTIsIGF0IDY6MjMgUE0sIDx6aG91LnN1amlu
Z0B6dGUuY29tLmNuPG1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPj4gd3JvdGU6DQo+DQo+
DQo+IE9idmlvdXNseSwgaXQgaXMgbm90IHNvIGNsZWFyIGZyb20gdGhlIGxhbmd1YWdlIHRoZXJl
Lg0KPg0KPg0KPiBDaHVjayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208bWFp
bHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20+PiDQtNPaIDIwMTItMTItMDQgMTA6MTc6MTI6
DQo+DQo+ID4gVGhlcmUncyBubyByZWFzb24gd2h5IGl0IGNhbid0IGJlIHJlc291cmNlIG93bmVy
IHRvZGF5Lg0KPiA+DQo+ID4gT24gRGVjIDMsIDIwMTIsIGF0IDY6MDYgUE0sIDx6aG91LnN1amlu
Z0B6dGUuY29tLmNuPG1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPj4gPHpob3Uuc3VqaW5n
QHp0ZS5jb20uY248bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24+DQo+ID4gPiB3cm90ZToN
Cj4gPg0KPiA+DQo+ID4gKzEuDQo+ID4gQW5kIHdoeSBpdCB3YXMgbm90IGxvb2tlZCBhdCB0aGF0
IHRpbWU/DQo+ID4NCj4gPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnPiDQtNPaIDIwMTItMTItMDQgMDE6MzA6NTU6DQo+ID4NCj4gPiA+IEFjdHVh
bGx5LCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aW1lIHRvIHN0YXJ0IGxvb2tpbmcgYXQgdGhlIHJl
c291cnNlDQo+ID4gPiBvd25lciBpc3N1aW5nIGFzc2VydGlvbnNAIChJbnRlcmVzdGluZ2x5IGVu
b3VnaCwgSHVpLUxhbiBoYWQgYnJvdWdodA0KPiA+ID4gdGhpcyB1cCBhIGNvdXBsZSBvZiB5ZWFy
cyBhZ28uKQ0KPiA+ID4NCj4gPiA+IElnb3INCj4gPiA+DQo+ID4gPiBPbiAxMi8zLzIwMTIgMzo1
OCBBTSwgTmF0IFNha2ltdXJhIHdyb3RlOg0KPiA+ID4gSSBzdXBwb3NlLCB5ZXMuIEkgd2FzIHJl
YWRpbmcgaXQgbGlrZSB0aGF0IGFsbCB0aGUgdGltZS4NCj4gPiA+IFdoZXRoZXIgaXQgaXMgb3Ig
bm90LCBpZiBpdCBpcyBzdGlsbCBvaywgaXQgbWlnaHQgYmUgYmV0dGVyIHRvDQo+IGNsYXJpZnkg
aXQuDQo+ID4gPiBXb3JkIGxpa2UgInRoaXJkIHBhcnR5IiB0ZW5kcyB0byBiZSBhIGJpdCBvZiBw
cm9ibGVtIHdpdGhvdXQNCj4gPiBjbGVhcmx5ZGVmaW5pbmcuDQo+ID4gPiBJIGhhZCBzaW1pbGFy
IGV4cGVyaWVuY2UgaW4gb3RoZXIgZm9yYS4NCj4gPiA+DQo+ID4gPiBOYXQNCj4gPiA+DQo+ID4g
PiBTZW50IGZyb20gaVBhZA0KPiA+ID4NCj4gPiA+IDIwMTIvMTIvMDMgMDo1MqGiInpob3Uuc3Vq
aW5nQHp0ZS5jb20uY248bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IiA8emhvdS5zdWpp
bmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbj4+IKTODQo+ID4gPiCl
4aXDpbupYKW4Og0KPiA+DQo+ID4gPg0KPiA+ID4gY291bGQgYmUgUmVzb3VyY2Ugb3duZXI/DQo+
ID4gPg0KPiA+DQo+ID4gPg0KPiA+ID4gIlRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNw
b28pIiA8aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbTxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdA
bnNuLmNvbT4+DQo+ID4gPiC3orz+yMs6ICBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnPg0KPiA+ID4gMjAxMi0xMi0wMyAxNjo0OQ0KPiA+ID4NCj4g
PiA+IMrVvP7Iyw0KPiA+ID4NCj4gPiA+ICJleHQgTmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21h
aWwuY29tPG1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+PiwgIkJyaWFuIENhbXBiZWxsIiA8DQo+
ID4gPiBiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu
dGl0eS5jb20+PiwgIm9hdXRoIiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3Jn
Pj4NCj4gPiA+DQo+ID4gPiCzrcvNDQo+ID4gPg0KPiA+ID4g1vfM4g0KPiA+ID4NCj4gPiA+IFJl
OiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0
byBiZQ0KPiA+ID4gZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2
aWNlPw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IEhpIE5hdCwNCj4gPiA+DQo+
ID4gPiBUaGUgY3VycmVudCB0ZXh0IGVzc2VudGlhbGx5IHNheXMgdGhhdCB0aGUgYXNzZXJ0aW9u
IGNhbiBlaXRoZXIgYmUNCj4gPiA+IGNyZWF0ZWQgYnkgdGhlIGNsaWVudCAoaW4gd2hpY2ggY2Fz
ZSBpdCBpcyBzZWxmLXNpZ25lZCkgb3IgaXQgY2FuIGJlDQo+ID4gPiBjcmVhdGVkIGJ5IHNvbWUg
b3RoZXIgZW50aXR5ICh3aGljaCBpcyB0aGVuIGNhbGxlZCB0aGUgdGhpcmQgcGFydHkNCj4gPiA+
IHRva2VuIHNlcnZpY2UpLiBTbywgdGhpcyB0aGlyZCBwYXJ0eSBjb3VsZCBiZSB0aGUgYXV0aG9y
aXphdGlvbiBzZXJ2ZXIuDQo+ID4gPg0KPiA+ID4gQ2lhbw0KPiA+ID4gSGFubmVzDQo+ID4gPg0K
PiA+ID4NCj4gPiA+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZg0KPiA+ID4gZXh0IE5hdCBTYWtpbXVy
YQ0KPiA+ID4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAxMiAxMDozNSBBTQ0KPiA+ID4g
VG86IEJyaWFuIENhbXBiZWxsOyBvYXV0aA0KPiA+ID4gU3ViamVjdDogW09BVVRILVdHXSBBc3Nl
cnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8gYmUNCj4gPiA+IGVpdGhl
ciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT8NCj4gPiA+DQo+ID4g
PiBIaSBCcmlhbiwNCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIGFzc2VydGlvbiBmcmFtZXdvcmsg
ZGVmaW5lcyB0aGUgSXNzdWVyIGFzOg0KPiA+ID4NCj4gPiA+ICAgIElzc3VlciAgVGhlIHVuaXF1
ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVkIHRoZQ0KPiA+ID4gICAgICAg
YXNzZXJ0aW9uLiAgR2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSBr
ZXkNCj4gPiA+ICAgICAgIG1hdGVyaWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4g
IFRoZSBpc3N1ZXIgbWF5IGJlIGVpdGhlcg0KPiA+ID4gICAgICAgYW4gT0F1dGggY2xpZW50ICh3
aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYtaXNzdWVkKSBvciBhIHRoaXJkIHBhcnR5DQo+ID4gPiAg
ICAgICB0b2tlbiBzZXJ2aWNlLg0KPiA+ID4NCj4gPiA+IEkgd2FzIHdvbmRlcmluZyB3aHkgaXQg
aGFzIHRvIGJlIGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkNCj4gPiA+IHRva2Vu
IHNlcnZpY2UuDQo+ID4gPiBDb25jZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBzZXJ2
aWNlIChmdW5jdGlvbmFsaXR5KQ0KPiA+IHJlc2lkaW5naW4gYW55IG9mDQo+ID4gPg0KPiA+ID4g
dGhlIHN0YWtlaG9sZGVycyAoUmVzb3VyY2UgT3duZXIsIE9BdXRoIENsaWVudCwgQXV0aG9yaXph
dGlvbiBTZXJ2ZXIsIG9yDQo+ID4gPiBhIHRoaXJkIHBhcnR5KS4NCj4gPiA+DQo+ID4gPg0KPiA+
ID4gSSB3b3VsZCBhcHByZWNpYXRlIGlmIHlvdSBjb3VsZCBjbGFyaWZ5IHdoeSBpcyB0aGUgY2Fz
ZS4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gQmVzdCwNCj4gPiA+DQo+ID4gPiAtLQ0KPiA+ID4gTmF0
IFNha2ltdXJhICg9bmF0KQ0KPiA+ID4gQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+ID4g
PiBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCj4gPiA+IEBfbmF0X2VuDQo+ID4gPiAgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1h
aWxpbmcgbGlzdA0KPiA+ID4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+DQo+
ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+ID4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiA+IE9BdXRoQGlldGYub3Jn
PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgNCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+ID4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiA+IE9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0
bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCg0KDQoNCg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQg
Rm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0KDQoNCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQo=

--_000_59E470B10C4630419ED717AC79FCF9A92F1A9015BLUPRD0411MB436_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi Brian,=



 

This is sort of my feeling =
on the STS as well (theoretical).  Are there any real-life examples of=
 obtaining a JWT assertion from an STS that can be used for the
 assertion flow?  And if so then how is it obtained?  It cannot b=
e an id_token because that is audience restricted to the client.  I gu=
ess it could be an access_token with a scope of assertion?  But I=A1=
=AFve not seen any discussion of that.  I=A1=AFve been interested
 in this flow for a while but the only examples I=A1=AFm aware of are self-=
issued JWTs.  I=A1=AFd be very interested in knowing real life of exam=
ples of clients obtaining a JWT assertion from an STS to use as a grant, an=
d the method they use to do that.


 

tx


adam


 



From: oauth-bo=
unces@ietf.org [mailto:oauth-bounces@ietf.org]
On Behalf Of Brian Campbell

Sent: Wednesday, December 05, 2012 8:05 AM

To: zhou.sujing@zte.com.cn

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have t=
o be either the client or a third party token service?



 


I say that it's only theoretical because I don't bel=
ieve there are any actual deployments supporting, or planning on supporting=
,
RO as =
an assertion issuer. 





 




On Tue, Dec 4, 2012 at 5:39 PM, <zhou.sujing@zte.com.cn> =
wrote:




Why RO=
 as an issuer is only theoretical today?













Brian Campbell <bcampbell@pingidentity.com&=
gt;



2012-12-04 23:41











=CA=D5=BC=FE=C8=CB<=
/p>




Nat Sakimura <sakimura@gmail.com>









=B3=AD=CB=CD




zhou.sujing@zte.com.cn, "oauth@ietf.org" <oauth@ietf.org>









=D6=F7=CC=E2




Re: [OAUTH-WG] Assertion Framework - Why d=
oes issuer have to be either the client or a third party token service?








 






























The in=
tent was definitely not to constrain who/what could be the issuer.  Bu=
t also try to provide


some guidance around the common cases that are actually being deployed now,=
 which are the client self-issued and STS variants. Resource owner as an is=
suer is an interesting case but seems mostly theoretical at this point.



I feel like mentioning the resource owner there in =A1=EC5.1 would cause mo=
re confusion than anything else. I'd prefer to just strike the whole senten=
ce in question and maybe add some additional text to =A1=EC3 that clarifies=
 that the issuer can really be any entity,
 if folks think a change is needed here? 







On Mon=
, Dec 3, 2012 at 9:20 PM, Nat Sakimura <sakimura@gmail.com>
 wrote: 

Actual=
ly, "The issuer may be either


      an OAuth client (when assertions are self=
-issued) or any other entity, e.g.,  a
 third party 

token service, resource owner. " &nb=
sp;is not really clean.




OAuth client is just another example of an issuer.




So, perhaps the sentence could be:




"Example of issuers include an OAuth client, resource owner, a=
n independent third party."




So, the clause becomes:




&=
nbsp;Issuer  The unique identifier for the entity that issued the


     assertion.  Generally this is the entity that hold=
s the key


     material used to generate the assertion.   =


&=
nbsp;     Example of issuers include an OAuth client, resource ow=
ner, an independent third party.




Nat 



Nat 



On Tue=
, Dec 4, 2012 at 11:40 AM, <zhou.sujing@zte.com.cn>
 wrote: 







Chuck Mortimore <cmortimore@salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:26:50: 





> Please feel free to suggest better language. 



> 

> Issuer simply allows the token service to know who created the 

> assertion, so it can look them up and see if they're trusted.  
  =


> Effectively the same as an Issuer in SAML.




a conflict : "The token service is the assertion issuer" in a=
ssertion document.


while you said "token service know who created the assertion"=





I wonder if the following text is acceptable:


 <=
span style=3D"font-family:"Arial","sans-serif"">


 Issuer  The unique identifier for the entity that issued the


     assertion.  Generally this is the entity that hold=
s the key


     material used to generate the assertion.  The issu=
er may be either


&=
nbsp;     an OAuth client (when assertions are self-issued) or any other entity, e.g.,  a third party


token service, resource owner. 





6.3.  =
;Client Acting on Behalf of a User




The Issuer of the assertion MUST identify the entity that issued


  =
 
 t=
he assertion as recognized by the Authorization Server.
 I=
f the


  =
 
 a=
ssertion is self-issued, the Issuer SHOULD be the "client_id".


  =
 
 I=
f the assertion was issued by a Security Token Service (STS), the


  =
 
 I=
ssuer SHOULD identify the STS as recognized by the Authorization


  =
 
 S=
erver.If the assertion was issued by the resource=
 owner, the


&n=
bsp;
 
 Issuer SHOULD identify the resour=
ce owner as recognized by the Authorization


&n=
bsp;
 
 Server.




> 

> -cmort 

> 

> On Dec 3, 2012, at 6:23 PM, <zhou.sujing@zte.com.cn> =
wrote:


> 

> 

> Obviously, it is not so clear from the language there. 

> 

> 

> Chuck Mortimore <cmortimore@salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:17:12:

> 

> > There's no reason why it can't be resource owner today. =
 


> > 

> > On Dec 3, 2012, at 6:06 PM, <zhou.sujing@zte.com.cn=
> <<=
tt>zhou.sujing@zte.com.cn

> > > wrote: 

> > 

> > 

> > +1. 

> > And why it was not looked at that time? 

> > 

> > oauth-bounces@ietf.org
=D0=B4=D3=DA 2012-12-04 01:30:55:

> > 

> > > Actually, I think it is a good time to start looking at =
the resourse

> > > owner issuing assertions@ (Interestingly enough, Hui-Lan=
 had brought

> > > this up a couple of years ago.)

> > > 

> > > Igor

> > > 

> > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: 

> > > I suppose, yes. I was reading it like that all the time.=
 

> > > Whether it is or not, if it is still ok, it might be bet=
ter to 

> clarify it. 

> > > Word like "third party" tends to be a bit of p=
roblem without 

> > clearlydefining. 

> > > I had similar experience in other fora. 

> > > 

> > > Nat 

> > > 

> > > Sent from iPad 

> > > 

> > > 2012/12/03 0:52=A1=A2"<=
/tt>zhou.su=
jing@zte.com.cn" <zhou.sujing@zte.com.cn>
=A4=CE

> > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8=
:

> > 

> > > 

> > > could be Resource owner? 

> > > 

> > 

> > > 

> > > "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.=
tschofenig@nsn.com>


> > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@i=
etf.org


> > > 2012-12-03 16:49 

> > > 

> > > =CA=D5=BC=FE=C8=CB 

> > > 

> > > "ext Nat Sakimura" <sakimura@gmail.com&g=
t;, "Brian Campbell" <

> > > bcampbell@pingidentity.com>, "oauth&q=
uot; <oauth=
@ietf.org>


> > > 

> > > =B3=AD=CB=CD 

> > > 

> > > =D6=F7=CC=E2 

> > > 

> > > Re: [OAUTH-WG] Assertion Framework - Why does issuer hav=
e to be  =

  =


> > > either the client or a third party token service? <=
br>
> > > 

> > > 

> > > 

> > > 

> > > Hi Nat, 

> > >   

> > > The current text essentially says that the assertion can=
 either be 


> > > created by the client (in which case it is self-signed) =
or it can be

> > > created by some other entity (which is then called the t=
hird party 


> > > token service). So, this third party could be the author=
ization server.


> > >   

> > > Ciao

> > > Hannes 

> > >   

> > >   

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


> > > ext Nat Sakimura

> > > Sent: Monday, December 03, 2012 10:35 AM

> > > To: Brian Campbell; oauth

> > > Subject: [OAUTH-WG] Assertion Framework - Why does issue=
r have to be

> > > either the client or a third party token service? <=
br>
> > >   

> > > Hi Brian, 

> > >   

> > >   

> > > The assertion framework defines the Issuer as: 

> > >   

> > >    Issuer
 T=
he unique identifier for the entity that issued the


> > >    
  =
assertion. &nb=
sp;Generally this is the entity that holds the key


> > >    
  =
material used to generate the assertion.
 T=
he issuer may be either


> > >    
  =
an OAuth client (when assertions are self-issued) or a third party


> > >    
  =
token service. 

> > >   

> > > I was wondering why it has to be either the client or a =
third party 


> > > token service. 

> > > Conceptually, it could be any token service (functionali=
ty) 

> > residingin any of 

> > >   

> > > the stakeholders (Resource Owner, OAuth Client, Authoriz=
ation Server, or


> > > a third party). 

> > >   

> > >   

> > > I would appreciate if you could clarify why is the case.=
 

> > >   

> > >   

> > > Best, 

> > >   

> > > -- 

> > > Nat Sakimura (=3Dnat) 

> > > Chairman, OpenID Foundation

> > > http://nat.sakimura.org/

> > > @_nat_en 

> > >  _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

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


> > 

> > > 

> > > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

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


> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

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


> > _______________________________________________

> > OAuth mailing list

> > =
OAuth@ietf.org

> > https://www.ietf.org/mailman/listinfo/oauth<=
tt>




_______________________________________________

OAuth mailing list

OAuth@ietf.=
org

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









-- 
Nat Sakimura (=3Dnat) 

Chairm=
an, OpenID Foundation

http://n=
at.sakimura.org/

@_nat_en 





_______________________________________________

OAuth mailing list

OAuth@ietf.=
org

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












 








--_000_59E470B10C4630419ED717AC79FCF9A92F1A9015BLUPRD0411MB436_--

From bcampbell@pingidentity.com  Wed Dec  5 07:38:22 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04E21F8CC1 for ; Wed,  5 Dec 2012 07:38:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.934
X-Spam-Level: 
X-Spam-Status: No, score=-3.934 tagged_above=-999 required=5 tests=[AWL=-0.408, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDW7lnlLXy0Z for ; Wed,  5 Dec 2012 07:38:16 -0800 (PST)
Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 2211821F8CBF for ; Wed,  5 Dec 2012 07:38:16 -0800 (PST)
Received: from mail-yh0-f71.google.com ([209.85.213.71]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKUL9qZwa1CUqXdO/sLsHwCrIg78KeQAo8@postini.com; Wed, 05 Dec 2012 07:38:16 PST
Received: by mail-yh0-f71.google.com with SMTP id j63so3372641yhj.6 for ; Wed, 05 Dec 2012 07:38:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=XcBZsRxHh6KAlY/WvD8BwPctlX0PGTATq0JI8DMHV2c=; b=MVf90m2NyW0XF8Q+1kNKUl109I61Wi/hI8fuevzgpPD1871GpBsr1mKQbEQ3fqjetA eT9qhYSqf+VC1neLnrXb+aZ08qVOBoRgGXWfCzEz4ZniKekJIbr9pPfYcBTknDyWMZLK jTFrYoY+akoWu3/IwrPHNVO1lAUG+CdUCH86JvfIxl658S8n+yvviecqPK6MDO5sFaq1 VL1xtoeBIr+1PeWZYXQixM0/heJENH+O9jmob3WXEBEmXKH40EQC28UHcEGyKPhbYnw+ VC4URT9nf5VilNezqCzhPBdCXF5mkS7D2NkjrGbuwMN1B6nbDxphQob0CsnhzudAefH4 tvhA==
Received: by 10.52.90.241 with SMTP id bz17mr13476244vdb.40.1354721895121; Wed, 05 Dec 2012 07:38:15 -0800 (PST)
Received: by 10.52.90.241 with SMTP id bz17mr13476236vdb.40.1354721894986; Wed, 05 Dec 2012 07:38:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.163.170 with HTTP; Wed, 5 Dec 2012 07:37:43 -0800 (PST)
In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F1A9015@BLUPRD0411MB436.namprd04.prod.outlook.com>
References:    <59E470B10C4630419ED717AC79FCF9A92F1A9015@BLUPRD0411MB436.namprd04.prod.outlook.com>
From: Brian Campbell 
Date: Wed, 5 Dec 2012 08:37:43 -0700
Message-ID: 
To: Lewis Adam-CAL022 
Content-Type: multipart/alternative; boundary=20cf307ca14451f54704d01cc527
X-Gm-Message-State: ALoCoQln18RGnxO8vOx73HT3eqQWGbV/LgZBk1WXa1OgFgyo0DvscYltFJxMYZJtqRD5ntdYpCcq5hviExp18lWwj51pSgDh/5yQoTgNkD5vvbgxGjnmBJ4gf8tRRMiCt8wATo7gYvV+
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 15:38:22 -0000

--20cf307ca14451f54704d01cc527
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi Adam,

My employer's product supports the STS case for getting SAML to be used in
the assertion flow. We and the employer of one of my co-authors on the spec
have a few very significant mutual customers that are using it today. The
JWT variant is 'on the road map' as we juggle other priorities and wait for
JOSE/JWT specs to stabilize a little more. It's just a different token
format from SAML though so I view it as much more concrete and likely to
happen. Granted the nature of JWT lends itself better to the self-signed
case so I think that will be more common but certainly won't preclude the
STS case.


On Wed, Dec 5, 2012 at 7:48 AM, Lewis Adam-CAL022 <
Adam.Lewis@motorolasolutions.com> wrote:

>  Hi Brian,****
>
> ** **
>
> This is sort of my feeling on the STS as well (theoretical).  Are there
> any real-life examples of obtaining a JWT assertion from an STS that can =
be
> used for the assertion flow?  And if so then how is it obtained?  It cann=
ot
> be an id_token because that is audience restricted to the client.  I gues=
s
> it could be an access_token with a scope of assertion?  But I=A1=AFve not=
 seen
> any discussion of that.  I=A1=AFve been interested in this flow for a whi=
le but
> the only examples I=A1=AFm aware of are self-issued JWTs.  I=A1=AFd be ve=
ry
> interested in knowing real life of examples of clients obtaining a JWT
> assertion from an STS to use as a grant, and the method they use to do th=
at.
> ****
>
> ** **
>
> tx****
>
> adam****
>
> ** **
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Brian Campbell
> *Sent:* Wednesday, December 05, 2012 8:05 AM
> *To:* zhou.sujing@zte.com.cn
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Assertion Framework - Why does issuer have to
> be either the client or a third party token service?****
>
> ** **
>
> I say that it's only theoretical because I don't believe there are any
> actual deployments supporting, or planning on supporting, RO as an
> assertion issuer. ****
>
> ** **
>
> On Tue, Dec 4, 2012 at 5:39 PM,  wrote:****
>
>
> Why RO as an issuer is only theoretical today?
>
> ****
>
> *Brian Campbell * ****
>
> 2012-12-04 23:41 ****
>
> =CA=D5=BC=FE=C8=CB****
>
> Nat Sakimura  ****
>
> =B3=AD=CB=CD****
>
> zhou.sujing@zte.com.cn, "oauth@ietf.org"  ****
>
> =D6=F7=CC=E2****
>
> Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either th=
e
> client or a third party token service?****
>
> ** **
>
>
>
>
> The intent was definitely not to constrain who/what could be the issuer.
>  But also try to provide
> some guidance around the common cases that are actually being deployed
> now, which are the client self-issued and STS variants. Resource owner as
> an issuer is an interesting case but seems mostly theoretical at this poi=
nt.
>
> I feel like mentioning the resource owner there in =A1=EC5.1 would cause =
more
> confusion than anything else. I'd prefer to just strike the whole sentenc=
e
> in question and maybe add some additional text to =A1=EC3 that clarifies =
that
> the issuer can really be any entity, if folks think a change is needed
> here?
>
>
>
> On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura  wrote:
> Actually, "The issuer may be either
>       an OAuth client (when assertions are self-issued) or any other
> entity, e.g.,  a third party
> token service, resource owner. "  is not really clean.
>
> OAuth client is just another example of an issuer.
>
> So, perhaps the sentence could be:
>
> "Example of issuers include an OAuth client, resource owner, an
> independent third party."
>
> So, the clause becomes:
>
>  Issuer  The unique identifier for the entity that issued the
>      assertion.  Generally this is the entity that holds the key
>      material used to generate the assertion.
>       Example of issuers include an OAuth client, resource owner, an
> independent third party.
>
> Nat
>
> Nat
>
> On Tue, Dec 4, 2012 at 11:40 AM,  wrote:
>
>
>
> Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 10:26=
:50:
>
>
> > Please feel free to suggest better language.
>
> >
> > Issuer simply allows the token service to know who created the
> > assertion, so it can look them up and see if they're trusted.
> > Effectively the same as an Issuer in SAML.
>
> a conflict : "The token service is the assertion issuer" in assertion
> document.
> while you said "token service know who created the assertion"
>
> I wonder if the following text is acceptable:
>
>  Issuer  The unique identifier for the entity that issued the
>      assertion.  Generally this is the entity that holds the key
>      material used to generate the assertion.  The issuer may be either
>       an OAuth client (when assertions are self-issued) or any other
> entity, e.g.,  a third party
> token service, resource owner.
>
>
> 6.3.  Client Acting on Behalf of a User
>
> The Issuer of the assertion MUST identify the entity that issued
>      the assertion as recognized by the Authorization Server.  If the
>      assertion is self-issued, the Issuer SHOULD be the "client_id".
>      If the assertion was issued by a Security Token Service (STS), the
>      Issuer SHOULD identify the STS as recognized by the Authorization
>      Server.If the assertion was issued by the resource owner, the
>      Issuer SHOULD identify the resource owner as recognized by the
> Authorization
>      Server.
>
> >
> > -cmort
> >
> > On Dec 3, 2012, at 6:23 PM,  wrote:
> >
> >
> > Obviously, it is not so clear from the language there.
> >
> >
> > Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 10:=
17:12:
> >
> > > There's no reason why it can't be resource owner today.
> > >
> > > On Dec 3, 2012, at 6:06 PM,  <
> zhou.sujing@zte.com.cn
> > > > wrote:
> > >
> > >
> > > +1.
> > > And why it was not looked at that time?
> > >
> > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:
> > >
> > > > Actually, I think it is a good time to start looking at the resours=
e
> > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had brough=
t
> > > > this up a couple of years ago.)
> > > >
> > > > Igor
> > > >
> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:
> > > > I suppose, yes. I was reading it like that all the time.
> > > > Whether it is or not, if it is still ok, it might be better to
> > clarify it.
> > > > Word like "third party" tends to be a bit of problem without
> > > clearlydefining.
> > > > I had similar experience in other fora.
> > > >
> > > > Nat
> > > >
> > > > Sent from iPad
> > > >
> > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn"  =A4=CE
> > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:
> > >
> > > >
> > > > could be Resource owner?
> > > >
> > >
> > > >
> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" 
> > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org
> > > > 2012-12-03 16:49
> > > >
> > > > =CA=D5=BC=FE=C8=CB
> > > >
> > > > "ext Nat Sakimura" , "Brian Campbell" <
> > > > bcampbell@pingidentity.com>, "oauth" 
> > > >
> > > > =B3=AD=CB=CD
> > > >
> > > > =D6=F7=CC=E2
> > > >
> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
> > > > either the client or a third party token service?
> > > >
> > > >
> > > >
> > > >
> > > > Hi Nat,
> > > >
> > > > The current text essentially says that the assertion can either be
> > > > created by the client (in which case it is self-signed) or it can b=
e
> > > > created by some other entity (which is then called the third party
> > > > token service). So, this third party could be the authorization
> server.
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > >
> > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf Of
> > > > ext Nat Sakimura
> > > > Sent: Monday, December 03, 2012 10:35 AM
> > > > To: Brian Campbell; oauth
> > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to b=
e
> > > > either the client or a third party token service?
> > > >
> > > > Hi Brian,
> > > >
> > > >
> > > > The assertion framework defines the Issuer as:
> > > >
> > > >    Issuer  The unique identifier for the entity that issued the
> > > >       assertion.  Generally this is the entity that holds the key
> > > >       material used to generate the assertion.  The issuer may be
> either
> > > >       an OAuth client (when assertions are self-issued) or a third
> party
> > > >       token service.
> > > >
> > > > I was wondering why it has to be either the client or a third party
> > > > token service.
> > > > Conceptually, it could be any token service (functionality)
> > > residingin any of
> > > >
> > > > the stakeholders (Resource Owner, OAuth Client, Authorization
> Server, or
> > > > a third party).
> > > >
> > > >
> > > > I would appreciate if you could clarify why is the case.
> > > >
> > > >
> > > > Best,
> > > >
> > > > --
> > > > Nat Sakimura (=3Dnat)
> > > > Chairman, OpenID Foundation
> > > > http://nat.sakimura.org/
> > > > @_nat_en
> > > >  _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > >
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list*
> *OAuth@ietf.org*
> *https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation*
> *http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list*
> *OAuth@ietf.org*
> *https://www.ietf.org/mailman/listinfo/oauth
>
> ****
>
> ** **
>

--20cf307ca14451f54704d01cc527
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Hi Adam,

My employer's product supports the STS case for getting=
 SAML to be used in the assertion flow. We and the employer of one of my co=
-authors on the spec have a few very significant mutual customers that are =
using it today. The JWT variant is 'on the road map' as we juggle o=
ther priorities and wait for JOSE/JWT specs to stabilize a little more. It&=
#39;s just a different token format from SAML though so I view it as much m=
ore concrete and likely to happen. Granted the nature of JWT lends itself b=
etter to the self-signed case so I think that will be more common but certa=
inly won't preclude the STS case.






On Wed, Dec 5=
, 2012 at 7:48 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolaso=
lutions.com> wrote:














Hi Brian,


 =



This is sort of my feeling =
on the STS as well (theoretical).  Are there any real-life examples of=
 obtaining a JWT assertion from an STS that can be used for the
 assertion flow?  And if so then how is it obtained?  It cannot b=
e an id_token because that is audience restricted to the client.  I gu=
ess it could be an access_token with a scope of assertion?  But I&rsqu=
o;ve not seen any discussion of that.  I’ve been interested
 in this flow for a while but the only examples I’m aware of are self=
-issued JWTs.  I’d be very interested in knowing real life of ex=
amples of clients obtaining a JWT assertion from an STS to use as a grant, =
and the method they use to do that.




 =



tx


adam

 =





From: oauth-bounces@ietf.org=
 [mailto:oa=
uth-bounces@ietf.org]
On Behalf Of Brian Campbell

Sent: Wednesday, December 05, 2012 8:05 AM

To: zhou=
.sujing@zte.com.cn

Cc: oauth@ietf.o=
rg

Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have t=
o be either the client or a third party token service?=





 


I say that it's only theoretical because I don&#=
39;t believe there are any actual deployments supporting, or planning on su=
pporting,
RO as =
an assertion issuer. 





 <=
/p>



On Tue, Dec 4, 2012 at 5:39 PM, <zhou.sujing@zte.com.cn> =
wrote:




Why RO=
 as an issuer is only theoretical today?













Brian Campbell <bcampbell@pingidentity.com&=
gt;



2012-12-04 23:41











=CA=D5=BC=FE=C8=CB




Nat Sakimura <sakimura@gmail.com>









=B3=AD=CB=CD




zhou.sujing@zte.com.cn, "oauth@ietf.org" <oauth@ietf.org>









=D6=F7=CC=E2




Re: [OAUTH-WG] Assertion Framework - Why d=
oes issuer have to be either the client or a third party token service?










 






























The in=
tent was definitely not to constrain who/what could be the issuer.  Bu=
t also try to provide


some guidance around the common cases that are actually being deployed now,=
 which are the client self-issued and STS variants. Resource owner as an is=
suer is an interesting case but seems mostly theoretical at this point.





I feel like mentioning the resource owner there in =A1=EC5.1 would cause mo=
re confusion than anything else. I'd prefer to just strike the whole se=
ntence in question and maybe add some additional text to =A1=EC3 that clari=
fies that the issuer can really be any entity,
 if folks think a change is needed here? 







On Mon=
, Dec 3, 2012 at 9:20 PM, Nat Sakimura <sakimura@gmail.com>
 wrote: 

Actual=
ly, "The issuer may be either


      an OAuth client (when assertions are self=
-issued) or any other entity, e.g.,  a
 third party 

token service, resource owner. " &nb=
sp;is not really clean.




OAuth client is just another example of an issuer.




So, perhaps the sentence could be:




"Example of issuers include an OAuth client, resource owner, a=
n independent third party."




So, the clause becomes:




&=
nbsp;Issuer  The unique identifier for the entity that issued the


     assertion.  Generally this is the entity that hold=
s the key


     material used to generate the assertion.   =


&=
nbsp;     Example of issuers include an OAuth client, resource ow=
ner, an independent third party.




Nat 



Nat 



On Tue=
, Dec 4, 2012 at 11:40 AM, <zhou.sujing@zte.com.cn>
 wrote: 







Chuck Mortimore <cmortimore@salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:26:50: 





> Please feel free to suggest better language. 



> 

> Issuer simply allows the token service to know who created the 

> assertion, so it can look them up and see if they're trusted. =
 
  =


> Effectively the same as an Issuer in SAML.




a conflict : "The token service is the assertion issuer" in a=
ssertion document.


while you said "token service know who created the assertion"=





I wonder if the following text is acceptable:


 <=
span style=3D"font-family:"Arial","sans-serif"">


 Issuer  The unique identifier for the entity that issued the


     assertion.  Generally this is the entity that hold=
s the key


     material used to generate the assertion.  The issu=
er may be either


&=
nbsp;     an OAuth client (when assertions are self-issued) or any other entity, e.g.,  a third party


token service, resource owner. 





6.3.  =
;Client Acting on Behalf of a User




The Issuer of the assertion MUST identify the entity that issued


  =
 
 t=
he assertion as recognized by the Authorization Server.
 I=
f the


  =
 
 a=
ssertion is self-issued, the Issuer SHOULD be the "client_id".


  =
 
 I=
f the assertion was issued by a Security Token Service (STS), the


  =
 
 I=
ssuer SHOULD identify the STS as recognized by the Authorization


  =
 
 S=
erver.If the assertion was issued by the resource=
 owner, the


&n=
bsp;
 
 Issuer SHOULD identify the resour=
ce owner as recognized by the Authorization


&n=
bsp;
 
 Server.




> 

> -cmort 

> 

> On Dec 3, 2012, at 6:23 PM, <zhou.sujing@zte.com.cn> =
wrote:


> 

> 

> Obviously, it is not so clear from the language there. 

> 

> 

> Chuck Mortimore <cmortimore@salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:17:12:

> 

> > There's no reason why it can't be resource owner toda=
y.  


> > 

> > On Dec 3, 2012, at 6:06 PM, <zhou.sujing@zte.com.cn=
> <<=
tt>zhou.sujing@zte.com.cn



> > > wrote: 

> > 

> > 

> > +1. 

> > And why it was not looked at that time? 

> > 

> > oauth-bounces@ietf.org
=D0=B4=D3=DA 2012-12-04 01:30:55:

> > 

> > > Actually, I think it is a good time to start looking at =
the resourse

> > > owner issuing assertions@ (Interestingly enough, Hui-Lan=
 had brought

> > > this up a couple of years ago.)

> > > 

> > > Igor

> > > 

> > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: 

> > > I suppose, yes. I was reading it like that all the time.=
 

> > > Whether it is or not, if it is still ok, it might be bet=
ter to 

> clarify it. 

> > > Word like "third party" tends to be a bit of p=
roblem without 

> > clearlydefining. 

> > > I had similar experience in other fora. 

> > > 

> > > Nat 

> > > 

> > > Sent from iPad 

> > > 

> > > 2012/12/03 0:52=A1=A2"<=
/tt>zhou.su=
jing@zte.com.cn" <zhou.sujing@zte.com.cn>
=A4=CE

> > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8=
:

> > 

> > > 

> > > could be Resource owner? 

> > > 

> > 

> > > 

> > > "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.=
tschofenig@nsn.com>


> > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@i=
etf.org


> > > 2012-12-03 16:49 

> > > 

> > > =CA=D5=BC=FE=C8=CB 

> > > 

> > > "ext Nat Sakimura" <sakimura@gmail.com&g=
t;, "Brian Campbell" <

> > > bcampbell@pingidentity.com>, "oauth&q=
uot; <oauth=
@ietf.org>


> > > 

> > > =B3=AD=CB=CD 

> > > 

> > > =D6=F7=CC=E2 

> > > 

> > > Re: [OAUTH-WG] Assertion Framework - Why does issuer hav=
e to be  =

  =


> > > either the client or a third party token service? <=
br>
> > > 

> > > 

> > > 

> > > 

> > > Hi Nat, 

> > >   

> > > The current text essentially says that the assertion can=
 either be 


> > > created by the client (in which case it is self-signed) =
or it can be

> > > created by some other entity (which is then called the t=
hird party 


> > > token service). So, this third party could be the author=
ization server.


> > >   

> > > Ciao

> > > Hannes 

> > >   

> > >   

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


> > > ext Nat Sakimura

> > > Sent: Monday, December 03, 2012 10:35 AM

> > > To: Brian Campbell; oauth

> > > Subject: [OAUTH-WG] Assertion Framework - Why does issue=
r have to be

> > > either the client or a third party token service? <=
br>
> > >   

> > > Hi Brian, 

> > >   

> > >   

> > > The assertion framework defines the Issuer as: 

> > >   

> > >    Issuer
 T=
he unique identifier for the entity that issued the


> > >    
  =
assertion. &nb=
sp;Generally this is the entity that holds the key


> > >    
  =
material used to generate the assertion.
 T=
he issuer may be either


> > >    
  =
an OAuth client (when assertions are self-issued) or a third party


> > >    
  =
token service. 

> > >   

> > > I was wondering why it has to be either the client or a =
third party 


> > > token service. 

> > > Conceptually, it could be any token service (functionali=
ty) 

> > residingin any of 

> > >   

> > > the stakeholders (Resource Owner, OAuth Client, Authoriz=
ation Server, or


> > > a third party). 

> > >   

> > >   

> > > I would appreciate if you could clarify why is the case.=
 

> > >   

> > >   

> > > Best, 

> > >   

> > > -- 

> > > Nat Sakimura (=3Dnat) 

> > > Chairman, OpenID Foundation

> > > http://nat.sakimura.org/

> > > @_nat_en 

> > >  _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

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


> > 

> > > 

> > > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

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


> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

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


> > _______________________________________________

> > OAuth mailing list

> > =
OAuth@ietf.org

> > https://www.ietf.org/mailman/listinfo/oauth<=
tt>




_______________________________________________

OAuth mailing list

OAuth@ietf.=
org



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











-- 
Nat Sakimura (=3Dnat) 

Chairm=
an, OpenID Foundation

http://n=
at.sakimura.org/



@_nat_en 





_______________________________________________

OAuth mailing list

OAuth@ietf.=
org



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














 












--20cf307ca14451f54704d01cc527--

From sberyozkin@gmail.com  Wed Dec  5 08:03:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CE821F8CA2 for ; Wed,  5 Dec 2012 08:03:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zosEbZkxDVnj for ; Wed,  5 Dec 2012 08:03:07 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55F9721F8BA9 for ; Wed,  5 Dec 2012 08:03:07 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so4699438lbk.31 for ; Wed, 05 Dec 2012 08:03:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HegExJ3pJaVB8FFVQ22S9+uvtupZN0XPJ8KNQb94I54=; b=rsa3h6cSV/vuQYZDaMngWCkCG4xnE+2LVMcjuvj1N1V5lqVo8338qNDFrlGxw5gb5l am4xerk0bsf2bLnUeUdUJqT27tQFuHxHyIwlJp6JEm8olmrAQfJyAV6phzp6JWbDZNQB Td1gYtA0YFK8KWDblYN7/Ga7QcpSND/VJYZlIKHCmU//1KS7F+HCRjOjGsRug2eVGSBy xQb0/fkosUwsh9RR5pjipn9EXp/sMUwDnPRtQxkTEMC8r5ufQEqYUe5+ObM05gclwiId 9KusQDUiGma5tZVLzPGOJpPUVUy4rUIt3LbbXuRnInHjX/Ao+swf1rAqjsQ6HKoWCS74 SIkg==
Received: by 10.112.17.129 with SMTP id o1mr7614732lbd.54.1354723386334; Wed, 05 Dec 2012 08:03:06 -0800 (PST)
Received: from [10.36.224.154] ([217.173.99.61]) by mx.google.com with ESMTPS id oz12sm2309009lab.17.2012.12.05.08.03.03 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 08:03:04 -0800 (PST)
Message-ID: <50BF7035.8060609@gmail.com>
Date: Wed, 05 Dec 2012 16:03:01 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "" 
References:  <50BE7811.7050503@gmail.com>
In-Reply-To: <50BE7811.7050503@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] Redirection flows, pre-authorized tokens and client-requested scopes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 16:03:08 -0000

On 04/12/12 22:24, Sergey Beryozkin wrote:
> We are working with one of our users on the support for pre-authorized
> tokens which can be checked by AS at the initial end user redirection to
> this AS before requesting the end-user authorization.
>
> My assumption is that if the pre-authorized token exists then the client
> provided scope, if any, is basically ignored, because the end user has
> already pre-authorized a given client with a specific token which will
> have a scope set as requested by the end user at the pre-authorization
> time.
>
> Is that right ? IMHO yes and the best AS can do in this case is simply
> log what scope the client is actually requesting but reply with the
> token containing the pre-authorized scope, please correct me if not
>

We've decided to treat this case similarly to the client-driven 
down-scoping request with the help of the refresh grant...


> thanks, Sergey
>
>


From sberyozkin@gmail.com  Wed Dec  5 08:09:39 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C04E21F8C08 for ; Wed,  5 Dec 2012 08:09:39 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Rjr2TqveQyP for ; Wed,  5 Dec 2012 08:09:38 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3384421F8CD8 for ; Wed,  5 Dec 2012 08:09:38 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so4705950lbk.31 for ; Wed, 05 Dec 2012 08:09:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=9b9rOiLHWlDBqVkMEapJ+zUWqzDw69FT9ypbY4uFb4c=; b=SjLBR9hHWJ+uAWtSEuIUFebUJvDc6xJWsctkhDc5C8VJCKoPWuwvzz6/rudKWtGRZr Fw72KbJ4QOXcpHfYDBGQ/gAawb7ZeYKgz4bgfh3HtoYRqHplAKJJlWwn1SspGpkIFlfa XSiMIU1FTDi/jSpEV1SF/911vs6AWnWuYh9kElNU0b++8f2rIc0xCbYqn/eRXhBg5n2f Pzhf8P4Ptq86HOFYs9q2WJsU77fmN7S1lwDYqaCxuq/nkIgariqi51IoTkhQehIiwovo 8W+3dbjQ6MdYC0cprQVQnn+PSZ6bN8PJdUmvmQq3U7pS0bmmnCnX+vYMFFfkMzSXB/i5 UPtQ==
Received: by 10.112.29.231 with SMTP id n7mr7748373lbh.107.1354723777146; Wed, 05 Dec 2012 08:09:37 -0800 (PST)
Received: from [10.36.224.154] ([217.173.99.61]) by mx.google.com with ESMTPS id hu6sm2320544lab.13.2012.12.05.08.09.34 (version=SSLv3 cipher=OTHER); Wed, 05 Dec 2012 08:09:35 -0800 (PST)
Message-ID: <50BF71BD.2010308@gmail.com>
Date: Wed, 05 Dec 2012 16:09:33 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Phil Hunt 
References:  <1AA88EE7AC2F2644989D65F506C031AE5A3887EE2B@QEO40072.de.t-online.corp> <50B88AE5.3070809@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] review: draft-richer-oauth-chain-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 16:09:39 -0000

Hi
On 30/11/12 16:36, Phil Hunt wrote:
> Two things.
>
> 1. I think access_token would be a bit confusing in some contexts even though thats what it is. However it is likely a foreign access token. "chain" is also shorter.
>
> 2. Regarding refresh, any idea on the use case? My impression is that if anything lifetime should be shorter than the current access token. All cases i have been looking at tend to be closer to single use -->  which has led o feedback that a single leg solution would be better for same domain cases.
>
If 2. refers to my comment re adding another optional parameter to the 
refresh grant: I thought, that the case of the immediate client issuing 
a down-scoping request with the help of the refresh grant is very 
similar to the RS issuing its own down-scoping request, with the only 
difference being that the proposed redelegate grant additionally 
introduces an access_token parameter.

My comment was only about the possibility of using the common processing 
path for both cases: if the scope is there it is a down-scoping request 
and if the access token parameter is there too then it must be a 
redelegate one.

However may be it is bad idea :-) to overload refresh grant further and 
having another dedicated grant type will work better longer term if some 
more parameters can be possibly added

thanks. Sergey


> Phil
>
> Sent from my phone.
>
> On 2012-11-30, at 2:31, Sergey Beryozkin  wrote:
>
>> On 30/11/12 10:25, Ebling, Sebastian wrote:
>>> Hi Phil,
>>>
>>> Some comments on draft-richer-oauth-chain-00.txt:
>>>
>>> Section 3.1.
>>> - I dislike the name of the grant type. "redelegate" is the use case but not the grant presented to the AS from RS1. I suggest to use "access_token" according to other grant types like authorization_code, password, refresh_token.
>> Interesting. What about adding one more optional parameter to "refresh_grant" ?
>>
>> thanks, Sergey
>>
>>> Section 3.2
>>> "As this access token is bound to an existing access token, the authorization server MUST NOT issue a refresh token."
>>>  From our operating experience [1] it may be useful to issue a refresh token in some cases.
>>>
>>> Example:
>>> RS1 may be a batch processing system that must be able to access RS2 some hours later to fulfill the originary request from the Client. The access tokens (AS to C and AS to RS1) may have expired when the job starts from the queue. Issuing a refresh token enables RS1 to obtain a fresh access token (AS to RS1).
>>> AS may limit the duration of the refresh token for such clients (RS1).
>>>
>>> Regards
>>>
>>> Sebastian
>>>
>>> [1] I'm a colleague of Torsten Lodderstedt at Deutsche Telekom, responsible for the system life cycle of our Secure Token Service. We have already implemented a very similar custom grant type for service chaining at Deutsche Telekom.
>>> _______________________________________________
>>> OAuth mailing 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 prateek.mishra@oracle.com  Wed Dec  5 08:41:30 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF6321F86EA for ; Wed,  5 Dec 2012 08:41:30 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NZUaX0DNg6a for ; Wed,  5 Dec 2012 08:41:19 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0F321F8539 for ; Wed,  5 Dec 2012 08:41:19 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB5GfHsi022659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 5 Dec 2012 16:41:18 GMT
Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id qB5GfG00027973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2012 16:41:16 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id qB5GfGVN008334; Wed, 5 Dec 2012 10:41:16 -0600
Received: from [192.168.1.2] (/71.184.95.145) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 05 Dec 2012 08:41:15 -0800
Message-ID: <50BF7922.6050803@oracle.com>
Date: Wed, 05 Dec 2012 11:41:06 -0500
From: Prateek Mishra 
Organization: Oracle Corporation
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Lewis Adam-CAL022 
References:    <59E470B10C4630419ED717AC79FCF9A92F1A9015@BLUPRD0411MB436.namprd04.prod.outlook.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080009030106000406090007"
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 16:41:30 -0000

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

We have a number of use-cases where a user's authentication/session is 
locally exchanged for a SAML assertion by a client; the client then uses 
the SAML assertion to acquire an OAuth 2.0 access token from a service 
provider and goes onto use services from the provider.

Its more of an instance of the "STS pattern" than an explicit use of a 
STS (or WS-Trust exchange) but it fits easily with the SAML 2.0 Bearer 
assertion profile for OAuth 2.0.
> Hi Adam,
>
> My employer's product supports the STS case for getting SAML to be 
> used in the assertion flow. We and the employer of one of my 
> co-authors on the spec have a few very significant mutual customers 
> that are using it today. The JWT variant is 'on the road map' as we 
> juggle other priorities and wait for JOSE/JWT specs to stabilize a 
> little more. It's just a different token format from SAML though so I 
> view it as much more concrete and likely to happen. Granted the nature 
> of JWT lends itself better to the self-signed case so I think that 
> will be more common but certainly won't preclude the STS case.
>
>
> On Wed, Dec 5, 2012 at 7:48 AM, Lewis Adam-CAL022 
>  > wrote:
>
>     Hi Brian,
>
>     This is sort of my feeling on the STS as well (theoretical).  Are
>     there any real-life examples of obtaining a JWT assertion from an
>     STS that can be used for the assertion flow?  And if so then how
>     is it obtained?  It cannot be an id_token because that is audience
>     restricted to the client.  I guess it could be an access_token
>     with a scope of assertion? But I've not seen any discussion of
>     that.  I've been interested in this flow for a while but the only
>     examples I'm aware of are self-issued JWTs.  I'd be very
>     interested in knowing real life of examples of clients obtaining a
>     JWT assertion from an STS to use as a grant, and the method they
>     use to do that.
>
>     tx
>
>     adam
>
>     *From:*oauth-bounces@ietf.org 
>     [mailto:oauth-bounces@ietf.org ]
>     *On Behalf Of *Brian Campbell
>     *Sent:* Wednesday, December 05, 2012 8:05 AM
>     *To:* zhou.sujing@zte.com.cn 
>     *Cc:* oauth@ietf.org 
>     *Subject:* Re: [OAUTH-WG] Assertion Framework - Why does issuer
>     have to be either the client or a third party token service?
>
>     I say that it's only theoretical because I don't believe there are
>     any actual deployments supporting, or planning on supporting, RO
>     as an assertion issuer.
>
>     On Tue, Dec 4, 2012 at 5:39 PM,      > wrote:
>
>
>     Why RO as an issuer is only theoretical today?
>
>     *Brian Campbell      >*
>
>     2012-12-04 23:41
>
>     	
>
>     ???
>
>     	
>
>     Nat Sakimura >
>
>     ??
>
>     	
>
>     zhou.sujing@zte.com.cn ,
>     "oauth@ietf.org "      >
>
>     ??
>
>     	
>
>     Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
>     either the client or a third party token service?
>
>
>     	
>
>
>
>
>     The intent was definitely not to constrain who/what could be the
>     issuer.  But also try to provide
>     some guidance around the common cases that are actually being
>     deployed now, which are the client self-issued and STS variants.
>     Resource owner as an issuer is an interesting case but seems
>     mostly theoretical at this point.
>
>     I feel like mentioning the resource owner there in 5.1 would
>     cause more confusion than anything else. I'd prefer to just strike
>     the whole sentence in question and maybe add some additional text
>     to 3 that clarifies that the issuer can really be any entity, if
>     folks think a change is needed here?
>
>
>
>     On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura      > wrote:
>     Actually, "The issuer may be either
>         an OAuth client (when assertions are self-issued) orany other
>     entity, e.g., a third party
>     token service, resource owner. "  is not really clean.
>
>     OAuth client is just another example of an issuer.
>
>     So, perhaps the sentence could be:
>
>     "Example of issuers include an OAuth client, resource owner, an
>     independent third party."
>
>     So, the clause becomes:
>
>      Issuer  The unique identifier for the entity that issued the
>          assertion.  Generally this is the entity that holds the key
>          material used to generate the assertion.
>     Example of issuers include an OAuth client, resource owner, an
>     independent third party.
>
>     Nat
>
>     Nat
>
>     On Tue, Dec 4, 2012 at 11:40 AM,      > wrote:
>
>
>
>     Chuck Mortimore      > ?? 2012-12-04 10:26:50:
>
>
>     > Please feel free to suggest better language.
>
>     >
>     > Issuer simply allows the token service to know who created the
>     > assertion, so it can look them up and see if they're trusted.
>     > Effectively the same as an Issuer in SAML.
>
>     a conflict : "The token service is the assertion issuer" in
>     assertion document.
>     while you said "token service know who created the assertion"
>
>     I wonder if the following text is acceptable:
>
>      Issuer  The unique identifier for the entity that issued the
>          assertion.  Generally this is the entity that holds the key
>          material used to generate the assertion.  The issuer may be
>     either
>           an OAuth client (when assertions are self-issued) orany
>     other entity, e.g., a third party
>     token service, resource owner.
>
>
>     6.3. Client Acting on Behalf of a User
>
>     The Issuer of the assertion MUST identify the entity that issued
>     the assertion as recognized by the Authorization Server. If the
>     assertion is self-issued, the Issuer SHOULD be the "client_id".
>     If the assertion was issued by a Security Token Service (STS), the
>     Issuer SHOULD identify the STS as recognized by the Authorization
>     Server.If the assertion was issued by the resource owner, the
>     Issuer SHOULD identify the resource owner as recognized by the
>     Authorization
>     Server.
>
>     >
>     > -cmort
>     >
>     > On Dec 3, 2012, at 6:23 PM,      > wrote:
>     >
>     >
>     > Obviously, it is not so clear from the language there.
>     >
>     >
>     > Chuck Mortimore      > ?? 2012-12-04 10:17:12:
>     >
>     > > There's no reason why it can't be resource owner today.
>     > >
>     > > On Dec 3, 2012, at 6:06 PM,      >      
>     > > > wrote:
>     > >
>     > >
>     > > +1.
>     > > And why it was not looked at that time?
>     > >
>     > > oauth-bounces@ietf.org ??
>     2012-12-04 01:30:55:
>     > >
>     > > > Actually, I think it is a good time to start looking at the
>     resourse
>     > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had
>     brought
>     > > > this up a couple of years ago.)
>     > > >
>     > > > Igor
>     > > >
>     > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:
>     > > > I suppose, yes. I was reading it like that all the time.
>     > > > Whether it is or not, if it is still ok, it might be better to
>     > clarify it.
>     > > > Word like "third party" tends to be a bit of problem without
>     > > clearlydefining.
>     > > > I had similar experience in other fora.
>     > > >
>     > > > Nat
>     > > >
>     > > > Sent from iPad
>     > > >
>     > > > 2012/12/03 0:52?"zhou.sujing@zte.com.cn
>     "      > ?
>     > > > ?? ???:
>     > >
>     > > >
>     > > > could be Resource owner?
>     > > >
>     > >
>     > > >
>     > > > "Tschofenig, Hannes (NSN - FI/Espoo)"
>     >
>     > > > ???: oauth-bounces@ietf.org 
>     > > > 2012-12-03 16:49
>     > > >
>     > > > ???
>     > > >
>     > > > "ext Nat Sakimura"      >, "Brian Campbell" <
>     > > > bcampbell@pingidentity.com
>     >, "oauth"      >
>     > > >
>     > > > ??
>     > > >
>     > > > ??
>     > > >
>     > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
>     > > > either the client or a third party token service?
>     > > >
>     > > >
>     > > >
>     > > >
>     > > > Hi Nat,
>     > > >
>     > > > The current text essentially says that the assertion can
>     either be
>     > > > created by the client (in which case it is self-signed) or
>     it can be
>     > > > created by some other entity (which is then called the third
>     party
>     > > > token service). So, this third party could be the
>     authorization server.
>     > > >
>     > > > Ciao
>     > > > Hannes
>     > > >
>     > > >
>     > > > From: oauth-bounces@ietf.org
>     [mailto:oauth-bounces@ietf.org
>     ] On Behalf Of
>     > > > ext Nat Sakimura
>     > > > Sent: Monday, December 03, 2012 10:35 AM
>     > > > To: Brian Campbell; oauth
>     > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer
>     have to be
>     > > > either the client or a third party token service?
>     > > >
>     > > > Hi Brian,
>     > > >
>     > > >
>     > > > The assertion framework defines the Issuer as:
>     > > >
>     > > > Issuer The unique identifier for the entity that issued the
>     > > > assertion. Generally this is the entity that holds the key
>     > > > material used to generate the assertion. The issuer may be
>     either
>     > > > an OAuth client (when assertions are self-issued) or a third
>     party
>     > > > token service.
>     > > >
>     > > > I was wondering why it has to be either the client or a
>     third party
>     > > > token service.
>     > > > Conceptually, it could be any token service (functionality)
>     > > residingin any of
>     > > >
>     > > > the stakeholders (Resource Owner, OAuth Client,
>     Authorization Server, or
>     > > > a third party).
>     > > >
>     > > >
>     > > > I would appreciate if you could clarify why is the case.
>     > > >
>     > > >
>     > > > Best,
>     > > >
>     > > > --
>     > > > Nat Sakimura (=nat)
>     > > > Chairman, OpenID Foundation
>     > > > http://nat.sakimura.org/
>     > > > @_nat_en
>     > > > _______________________________________________
>     > > > OAuth mailing list
>     > > > OAuth@ietf.org 
>     > > > https://www.ietf.org/mailman/listinfo/oauth
>     > >
>     > > >
>     > > >
>     > > > _______________________________________________
>     > > > OAuth mailing list
>     > > > OAuth@ietf.org 
>     > > > https://www.ietf.org/mailman/listinfo/oauth
>     > > > _______________________________________________
>     > > > OAuth mailing list
>     > > > OAuth@ietf.org 
>     > > > https://www.ietf.org/mailman/listinfo/oauth
>     > > _______________________________________________
>     > > OAuth mailing list
>     > > OAuth@ietf.org 
>     > > https://www.ietf.org/mailman/listinfo/oauth
>
>     _______________________________________________
>     OAuth mailing list_
>     _OAuth@ietf.org _
>     _https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>     -- 
>     Nat Sakimura (=nat)
>     Chairman, OpenID Foundation_
>     _http://nat.sakimura.org/
>     @_nat_en
>
>
>     _______________________________________________
>     OAuth mailing list_
>     _OAuth@ietf.org _
>     _https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    We have a number of use-cases where a user's authentication/session
    is locally exchanged for a SAML assertion by a client; the client
    then uses the SAML assertion to acquire an OAuth 2.0 access token
    from a service provider and goes onto use services from the
    provider. 

    

    Its more of an instance of the "STS pattern" than an explicit use of
    a STS (or WS-Trust exchange) but it fits easily with the SAML 2.0
    Bearer assertion profile for OAuth 2.0.

    
Hi Adam,

      

      My employer's product supports the STS case for getting SAML to be
      used in the assertion flow. We and the employer of one of my
      co-authors on the spec have a few very significant mutual
      customers that are using it today. The JWT variant is 'on the road
      map' as we juggle other priorities and wait for JOSE/JWT specs to
      stabilize a little more. It's just a different token format from
      SAML though so I view it as much more concrete and likely to
      happen. Granted the nature of JWT lends itself better to the
      self-signed case so I think that will be more common but certainly
      won't preclude the STS case.

      


        

        
On Wed, Dec 5, 2012 at 7:48 AM, Lewis
          Adam-CAL022 <Adam.Lewis@motorolasolutions.com>
          wrote:

          

            

              

                
Hi
                    Brian,

                
 

                
This is
                    sort of my feeling on the STS as well
                    (theoretical).  Are there any real-life examples of
                    obtaining a JWT assertion from an STS that can be
                    used for the assertion flow?  And if so then how is
                    it obtained?  It cannot be an id_token because that
                    is audience restricted to the client.  I guess it
                    could be an access_token with a scope of assertion? 
                    But I’ve not seen any discussion of that.  I’ve been
                    interested in this flow for a while but the only
                    examples I’m aware of are self-issued JWTs.  I’d be
                    very interested in knowing real life of examples of
                    clients obtaining a JWT assertion from an STS to use
                    as a grant, and the method they use to do that.

                
 

                
tx

                
adam

                
 

                

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

                      Sent: Wednesday, December 05, 2012 8:05 AM

                      To: zhou.sujing@zte.com.cn

                      Cc: oauth@ietf.org

                      Subject: Re: [OAUTH-WG] Assertion Framework
                      - Why does issuer have to be either the client or
                      a third party token service?

                

                

                  

                    
 

                    
I say that it's only
                      theoretical because I don't believe there are any
                      actual deployments supporting, or planning on
                      supporting,
                      RO
                        as an assertion issuer. 
                    

                    

                      
 

                      

                        
On Tue, Dec 4, 2012 at 5:39
                          PM, <zhou.sujing@zte.com.cn>
                          wrote:

                        


                          Why
                            RO as an issuer is only theoretical today?
                          

                          

                        

                        

                          
                            

                              
                                
Brian
                                      Campbell <bcampbell@pingidentity.com>
                                  

                                
2012-12-04
                                    23:41
                                

                              		
                              
                                

                                  
                                    

                                      
                                        
收件人

                                      		
                                      
                                        
Nat
                                            Sakimura <sakimura@gmail.com>
                                        

                                      		
                                    

                                    

                                      
                                        
抄送

                                      		
                                      
                                        
zhou.sujing@zte.com.cn,
                                            "oauth@ietf.org"
                                            <oauth@ietf.org>
                                        

                                      		
                                    

                                    

                                      
                                        
主题

                                      		
                                      
                                        
Re:
                                            [OAUTH-WG] Assertion
                                            Framework - Why does issuer
                                            have to be either the client
                                            or a third party token
                                            service?

                                      		
                                    

                                  
                                

                                
 

                                

                                  
                                    

                                      

                                      		
                                      

                                      		
                                    

                                  
                                

                              		
                            

                          
                        

                        

                          

                            


                              

                              

                              The
                                intent was definitely not to constrain
                                who/what could be the issuer.  But also
                                try to provide
                                

                                some guidance around the common cases
                                that are actually being deployed now,
                                which are the client self-issued and STS
                                variants. Resource owner as an issuer is
                                an interesting case but seems mostly
                                theoretical at this point.

                                

                                I feel like mentioning the resource
                                owner there in §5.1 would cause more
                                confusion than anything else. I'd prefer
                                to just strike the whole sentence in
                                question and maybe add some additional
                                text to §3 that clarifies that the
                                issuer can really be any entity, if
                                folks think a change is needed here? 

                              

                              

                              

                              On
                                Mon, Dec 3, 2012 at 9:20 PM, Nat
                                Sakimura <sakimura@gmail.com> wrote:
                              

                              Actually,
                                "The
                                issuer may be either

                               
                                    an OAuth client (when assertions are
                                self-issued) or
                                any other entity, e.g.,  a
                                third party 

                              token
                                service,
                                resource owner.
                                "  is not really clean.
                              

                              

                              OAuth
                                client is just another example of an
                                issuer.
                              

                              

                              So,
                                perhaps the sentence could be:
                              

                              

                              "Example
                                of issuers include an OAuth client,
                                resource owner, an independent third
                                party."
                              

                              

                              So,
                                the clause becomes:
                              

                              

                               Issuer
                                 The unique identifier for the entity
                                that issued the
                              

                                     assertion.  Generally this is the
                                entity that holds the key
                              

                                     material used to generate the
                                assertion.   

                                   
                                Example of issuers include an OAuth
                                client, resource owner, an independent
                                third party.
                              

                              

                              Nat
                              

                              

                              Nat
                              

                              

                              On
                                Tue, Dec 4, 2012 at 11:40 AM, <zhou.sujing@zte.com.cn> wrote:
                              

                              

                                

                              

                              Chuck Mortimore <cmortimore@salesforce.com>
                                写于 2012-12-04
                                10:26:50: 

                              

                              

                              > Please feel free to suggest
                                better language. 

                              

                              > 

                              > Issuer simply allows the token
                                service to know who created the 

                              > assertion, so it can look them up
                                and see if they're trusted.  
                                

                              > Effectively the same as an Issuer
                                in SAML.
                                

                              

                              a conflict : "The token service is the
                                assertion issuer" in assertion document.
                              

                              while you said "token service know who
                                created the assertion"
                                

                              

                              I wonder if the following text is
                                acceptable:
                              

                               
                              

                                 Issuer  The unique identifier for the
                                entity that issued the
                              

                                     assertion.  Generally this is the
                                entity that holds the key
                              

                                     material used to generate the
                                assertion.  The issuer may be either
                              

                                    an
                                OAuth client (when assertions are
                                self-issued) or
                                  any other entity, e.g.,  a
                                third party
                              

                                token service,
                                  resource owner. 

                                

                              

                              6.3.  Client Acting on
                                Behalf of a User
                                

                              

                              The Issuer of the assertion MUST
                                identify the entity that issued
                              

                                 
                               the assertion as
                                recognized by the Authorization Server.
                               If the
                              

                                 
                               assertion is
                                self-issued, the Issuer SHOULD be the
                                "client_id".
                              

                                 
                               If the assertion
                                was issued by a Security Token Service
                                (STS), the
                              

                                 
                               Issuer SHOULD
                                identify the STS as recognized by the
                                Authorization
                              

                                 
                               Server.If the assertion was
                                  issued by the resource owner, the
                              

                               
                                 
                                 Issuer SHOULD
                                  identify the resource owner as
                                  recognized by the Authorization
                              

                               
                                 
                                 Server.
                              

                              

                              > 

                              > -cmort
                              

                              > 

                              > On Dec 3, 2012, at 6:23 PM, <zhou.sujing@zte.com.cn>
                                wrote:
                              

                              > 

                              > 

                              > Obviously, it is not so clear
                                from the language there. 

                              > 

                              > 

                              > Chuck Mortimore <cmortimore@salesforce.com>
                                写于 2012-12-04
                                10:17:12:

                              > 

                              > > There's no reason why it
                                can't be resource owner today.  
                              

                              > > 

                              > > On Dec 3, 2012, at 6:06 PM,
                                <zhou.sujing@zte.com.cn>
                                <zhou.sujing@zte.com.cn

                              > > > wrote: 

                              > > 

                              > > 

                              > > +1. 

                              > > And why it was not looked at
                                that time? 

                              > > 

                              > > oauth-bounces@ietf.org
                                写于 2012-12-04
                                01:30:55:

                              > > 

                              > > > Actually, I think it is
                                a good time to start looking at the
                                resourse

                              > > > owner issuing
                                assertions@ (Interestingly enough,
                                Hui-Lan had brought

                              > > > this up a couple of
                                years ago.)

                              > > > 

                              > > > Igor

                              > > > 

                              > > > On 12/3/2012 3:58 AM,
                                Nat Sakimura wrote: 

                              > > > I suppose, yes. I was
                                reading it like that all the time. 

                              > > > Whether it is or not,
                                if it is still ok, it might be better to
                              

                              > clarify it. 

                              > > > Word like "third party"
                                tends to be a bit of problem without 

                              > > clearlydefining. 

                              > > > I had similar
                                experience in other fora. 

                              > > > 

                              > > > Nat 

                              > > > 

                              > > > Sent from iPad 

                              > > > 

                              > > > 2012/12/03 0:52、"zhou.sujing@zte.com.cn"
                                <zhou.sujing@zte.com.cn>
                                の

                              > > > メッ
                                  セージ:

                              > > 

                              > > > 

                              > > > could be Resource
                                owner? 

                              > > > 

                              > > 

                              > > > 

                              > > > "Tschofenig, Hannes
                                (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
                              

                              > > > 发件人:
                               oauth-bounces@ietf.org
                              

                              > > > 2012-12-03 16:49 

                              > > > 

                              > > > 收件人
                                

                              > > > 

                              > > > "ext Nat Sakimura" <sakimura@gmail.com>,
                                "Brian Campbell" <

                              > > > bcampbell@pingidentity.com>,
                                "oauth" <oauth@ietf.org>
                              

                              > > > 

                              > > > 抄送
                                

                              > > > 

                              > > > 主题
                                

                              > > > 

                              > > > Re: [OAUTH-WG]
                                Assertion Framework - Why does issuer
                                have to be  
                                

                              > > > either the client or a
                                third party token service? 

                              > > > 

                              > > > 

                              > > > 

                              > > > 

                              > > > Hi Nat, 

                              > > >   

                              > > > The current text
                                essentially says that the assertion can
                                either be 
                              

                              > > > created by the client
                                (in which case it is self-signed) or it
                                can be

                              > > > created by some other
                                entity (which is then called the third
                                party 
                              

                              > > > token service). So,
                                this third party could be the
                                authorization server.
                              

                              > > >   

                              > > > Ciao

                              > > > Hannes 

                              > > >   

                              > > >   

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

                              > > > ext Nat Sakimura

                              > > > Sent: Monday, December
                                03, 2012 10:35 AM

                              > > > To: Brian Campbell;
                                oauth

                              > > > Subject: [OAUTH-WG]
                                Assertion Framework - Why does issuer
                                have to be

                              > > > either the client or a
                                third party token service? 

                              > > >   

                              > > > Hi Brian, 

                              > > >   

                              > > >   

                              > > > The assertion framework
                                defines the Issuer as: 

                              > > >   

                              > > >    Issuer
                               The unique
                                identifier for the entity that issued
                                the
                              

                              > > >    
                                assertion.  Generally this is
                                the entity that holds the key
                              

                              > > >    
                                material used to
                                generate the assertion.
                               The issuer may be
                                either
                              

                              > > >    
                                an OAuth client
                                (when assertions are self-issued) or a
                                third party
                              

                              > > >    
                                token service. 

                              > > >   

                              > > > I was wondering why it
                                has to be either the client or a third
                                party 
                              

                              > > > token service. 

                              > > > Conceptually, it could
                                be any token service (functionality) 

                              > > residingin any of 

                              > > >   

                              > > > the stakeholders
                                (Resource Owner, OAuth Client,
                                Authorization Server, or
                              

                              > > > a third party). 

                              > > >   

                              > > >   

                              > > > I would appreciate if
                                you could clarify why is the case. 

                              > > >   

                              > > >   

                              > > > Best, 

                              > > >   

                              > > > -- 

                              > > > Nat Sakimura (=nat) 

                              > > > Chairman, OpenID
                                Foundation

                              > > > http://nat.sakimura.org/

                              > > > @_nat_en 

                              > > >  _______________________________________________

                              > > > OAuth mailing list

                              > > > OAuth@ietf.org

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

                              > > 

                              > > > 

                              > > > 

                              > > >
                                _______________________________________________

                              > > > OAuth mailing list

                              > > > OAuth@ietf.org

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

                              > > >
                                _______________________________________________

                              > > > OAuth mailing list

                              > > > OAuth@ietf.org

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

                              > >
                                _______________________________________________

                              > > OAuth mailing list

                              > > OAuth@ietf.org

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

                              

_______________________________________________

                                OAuth mailing list

                                  OAuth@ietf.org

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

                              

                              

                              

                              

                              --
                                

                                Nat Sakimura (=nat) 

                              Chairman,
                                OpenID Foundation

                                  http://nat.sakimura.org/

                                @_nat_en 

                              

                              

_______________________________________________

                                OAuth mailing list

                                  OAuth@ietf.org

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

                                

                              

                          

                        

                      

                      
 

                    

                  

                

              

            

          

        

        

      

      

      

      

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


    

    

  


--------------080009030106000406090007--

From sakimura@gmail.com  Wed Dec  5 09:13:44 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5A421F8D06 for ; Wed,  5 Dec 2012 09:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.937
X-Spam-Level: 
X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4kM-C6EKNsk for ; Wed,  5 Dec 2012 09:13:40 -0800 (PST)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3524321F8D00 for ; Wed,  5 Dec 2012 09:13:40 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id a1so2366774eaa.31 for ; Wed, 05 Dec 2012 09:13:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wPiOgQDPV9zUN+R6t8caAbWzdPblterenzxLKNf/OEM=; b=0OyUIaWE7s0NXn9zwpknJNqUJiJaBUleD31rfIRhwbLPp/BHP784e+jFNeMcDHJLgI Cnwk6bkEq/QnELjTSjOdONAPF1xOTVa5LSByFS2hO6o25zq/NMfaSItwiVCrchRMuB8K sWdZthW7FF/IWnnm4NYf/eejvSXf4Qn0WP/4BwR5ickpC50ySODYMEm52QZrKdZxBO+G m63lD9312888mI2GnHEjkxp6RQiQCjZgrScJVcw1MzypuScsi+QQBmw0RZ41yHgBiVZA OEvxEwwZjhxubmQm6b8LHpch+mUTJD/PFzJTmsLjgF0tFjTlySc54r9PdCqfGAGtvEJ+ az7Q==
MIME-Version: 1.0
Received: by 10.14.220.71 with SMTP id n47mr61807828eep.39.1354727619326; Wed, 05 Dec 2012 09:13:39 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Wed, 5 Dec 2012 09:13:39 -0800 (PST)
In-Reply-To: 
References:   
Date: Thu, 6 Dec 2012 02:13:39 +0900
Message-ID: 
From: Nat Sakimura 
To: Brian Campbell 
Content-Type: multipart/alternative; boundary=047d7b621ef08472bf04d01e1a1a
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 17:13:44 -0000

--047d7b621ef08472bf04d01e1a1a
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

It is not OAuth, but Austrian eID system is an example of RO as an
assertion issuer pattern. They have their own SAML IdP on their PC (at
least a few years ago) and combined with the qualified certs in the user's
smart card and another file, creates a SAML assertion with sectoral
identifier and supply it to other systems.

Nat

On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell
wrote:

> I say that it's only theoretical because I don't believe there are any
> actual deployments supporting, or planning on supporting, RO as an
> assertion issuer.
>
>
> On Tue, Dec 4, 2012 at 5:39 PM,  wrote:
>
>>
>> Why RO as an issuer is only theoretical today?
>>
>>
>>  *Brian Campbell *
>>
>> 2012-12-04 23:41
>>   =CA=D5=BC=FE=C8=CB
>> Nat Sakimura 
>> =B3=AD=CB=CD
>> zhou.sujing@zte.com.cn, "oauth@ietf.org" 
>> =D6=F7=CC=E2
>> Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either
>> the client or a third party token service?
>>
>>
>>
>>
>> The intent was definitely not to constrain who/what could be the issuer.
>>  But also try to provide
>> some guidance around the common cases that are actually being deployed
>> now, which are the client self-issued and STS variants. Resource owner a=
s
>> an issuer is an interesting case but seems mostly theoretical at this po=
int.
>>
>> I feel like mentioning the resource owner there in =A1=EC5.1 would cause=
 more
>> confusion than anything else. I'd prefer to just strike the whole senten=
ce
>> in question and maybe add some additional text to =A1=EC3 that clarifies=
 that
>> the issuer can really be any entity, if folks think a change is needed
>> here?
>>
>>
>>
>> On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura <*sakimura@gmail.com*>
>> wrote:
>> Actually, "The issuer may be either
>>       an OAuth client (when assertions are self-issued) or any other
>> entity, e.g.,  a third party
>> token service, resource owner. "  is not really clean.
>>
>> OAuth client is just another example of an issuer.
>>
>> So, perhaps the sentence could be:
>>
>> "Example of issuers include an OAuth client, resource owner, an
>> independent third party."
>>
>> So, the clause becomes:
>>
>>  Issuer  The unique identifier for the entity that issued the
>>      assertion.  Generally this is the entity that holds the key
>>      material used to generate the assertion.
>>       Example of issuers include an OAuth client, resource owner, an
>> independent third party.
>>
>> Nat
>>
>> Nat
>>
>> On Tue, Dec 4, 2012 at 11:40 AM, <*zhou.sujing@zte.com.cn*>
>> wrote:
>>
>>
>>
>> Chuck Mortimore <*cmortimore@salesforce.com* =
>
>> =D0=B4=D3=DA 2012-12-04 10:26:50:
>>
>>
>> > Please feel free to suggest better language.
>>
>> >
>> > Issuer simply allows the token service to know who created the
>> > assertion, so it can look them up and see if they're trusted.
>> > Effectively the same as an Issuer in SAML.
>>
>> a conflict : "The token service is the assertion issuer" in assertion
>> document.
>> while you said "token service know who created the assertion"
>>
>> I wonder if the following text is acceptable:
>>
>>  Issuer  The unique identifier for the entity that issued the
>>      assertion.  Generally this is the entity that holds the key
>>      material used to generate the assertion.  The issuer may be either
>>       an OAuth client (when assertions are self-issued) or any other
>> entity, e.g.,  a third party
>> token service, resource owner.
>>
>>
>> 6.3.  Client Acting on Behalf of a User
>>
>> The Issuer of the assertion MUST identify the entity that issued
>>      the assertion as recognized by the Authorization Server.  If the
>>      assertion is self-issued, the Issuer SHOULD be the "client_id".
>>      If the assertion was issued by a Security Token Service (STS), the
>>      Issuer SHOULD identify the STS as recognized by the Authorization
>>      Server.If the assertion was issued by the resource owner, the
>>      Issuer SHOULD identify the resource owner as recognized by the
>> Authorization
>>      Server.
>>
>> >
>> > -cmort
>> >
>> > On Dec 3, 2012, at 6:23 PM, <*zhou.sujing@zte.com.cn*>
>> wrote:
>> >
>> >
>> > Obviously, it is not so clear from the language there.
>> >
>> >
>> > Chuck Mortimore <*cmortimore@salesforce.com*>
>> =D0=B4=D3=DA 2012-12-04 10:17:12:
>> >
>> > > There's no reason why it can't be resource owner today.
>> > >
>> > > On Dec 3, 2012, at 6:06 PM, <*zhou.sujing@zte.com.cn*>
>> <*zhou.sujing@zte.com.cn* 
>> > > > wrote:
>> > >
>> > >
>> > > +1.
>> > > And why it was not looked at that time?
>> > >
>> > > *oauth-bounces@ietf.org*  =D0=B4=D3=DA 2012-=
12-04
>> 01:30:55:
>> > >
>> > > > Actually, I think it is a good time to start looking at the resour=
se
>> > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had
>> brought
>> > > > this up a couple of years ago.)
>> > > >
>> > > > Igor
>> > > >
>> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:
>> > > > I suppose, yes. I was reading it like that all the time.
>> > > > Whether it is or not, if it is still ok, it might be better to
>> > clarify it.
>> > > > Word like "third party" tends to be a bit of problem without
>> > > clearlydefining.
>> > > > I had similar experience in other fora.
>> > > >
>> > > > Nat
>> > > >
>> > > > Sent from iPad
>> > > >
>> > > > 2012/12/03 0:52=A1=A2"*zhou.sujing@zte.com.cn* "
>> <*zhou.sujing@zte.com.cn* > =A4=CE
>> > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:
>> > >
>> > > >
>> > > > could be Resource owner?
>> > > >
>> > >
>> > > >
>> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" <*hannes.tschofenig@nsn.com*=
>
>>
>> > > > =B7=A2=BC=FE=C8=CB:  *oauth-bounces@ietf.org* 
>> > > > 2012-12-03 16:49
>> > > >
>> > > > =CA=D5=BC=FE=C8=CB
>> > > >
>> > > > "ext Nat Sakimura" <*sakimura@gmail.com* >,
>> "Brian Campbell" <
>> > > > *bcampbell@pingidentity.com* >,
>> "oauth" <*oauth@ietf.org* >
>> > > >
>> > > > =B3=AD=CB=CD
>> > > >
>> > > > =D6=F7=CC=E2
>> > > >
>> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
>> > > > either the client or a third party token service?
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > Hi Nat,
>> > > >
>> > > > The current text essentially says that the assertion can either be
>> > > > created by the client (in which case it is self-signed) or it can =
be
>> > > > created by some other entity (which is then called the third party
>> > > > token service). So, this third party could be the authorization
>> server.
>> > > >
>> > > > Ciao
>> > > > Hannes
>> > > >
>> > > >
>> > > > From: *oauth-bounces@ietf.org*  [mailto:*
>> oauth-bounces@ietf.org* ] On Behalf Of
>> > > > ext Nat Sakimura
>> > > > Sent: Monday, December 03, 2012 10:35 AM
>> > > > To: Brian Campbell; oauth
>> > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to =
be
>> > > > either the client or a third party token service?
>> > > >
>> > > > Hi Brian,
>> > > >
>> > > >
>> > > > The assertion framework defines the Issuer as:
>> > > >
>> > > >    Issuer  The unique identifier for the entity that issued the
>> > > >       assertion.  Generally this is the entity that holds the key
>> > > >       material used to generate the assertion.  The issuer may be
>> either
>> > > >       an OAuth client (when assertions are self-issued) or a third
>> party
>> > > >       token service.
>> > > >
>> > > > I was wondering why it has to be either the client or a third part=
y
>> > > > token service.
>> > > > Conceptually, it could be any token service (functionality)
>> > > residingin any of
>> > > >
>> > > > the stakeholders (Resource Owner, OAuth Client, Authorization
>> Server, or
>> > > > a third party).
>> > > >
>> > > >
>> > > > I would appreciate if you could clarify why is the case.
>> > > >
>> > > >
>> > > > Best,
>> > > >
>> > > > --
>> > > > Nat Sakimura (=3Dnat)
>> > > > Chairman, OpenID Foundation
>> > > > *http://nat.sakimura.org/* 
>> > > > @_nat_en
>> > > >  _______________________________________________
>> > > > OAuth mailing list
>> > > > *OAuth@ietf.org* 
>> > > > *https://www.ietf.org/mailman/listinfo/oauth*
>> > >
>> > > >
>> > > >
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > *OAuth@ietf.org* 
>> > > > *https://www.ietf.org/mailman/listinfo/oauth*
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > *OAuth@ietf.org* 
>> > > > *https://www.ietf.org/mailman/listinfo/oauth*
>> > > _______________________________________________
>> > > OAuth mailing list
>> > > *OAuth@ietf.org* 
>> > > *https://www.ietf.org/mailman/listinfo/oauth*
>>
>> _______________________________________________
>> OAuth mailing list*
>> **OAuth@ietf.org* *
>> **https://www.ietf.org/mailman/listinfo/oauth*
>>
>>
>>
>>
>> --
>> Nat Sakimura (=3Dnat)
>> Chairman, OpenID Foundation*
>> **http://nat.sakimura.org/* 
>> @_nat_en
>>
>>
>> _______________________________________________
>> OAuth mailing list*
>> **OAuth@ietf.org* *
>> **https://www.ietf.org/mailman/listinfo/oauth*
>>
>>
>>
>


--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b621ef08472bf04d01e1a1a
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

It is not OAuth, but Austrian eID system is an example of RO as an assertio=
n issuer pattern. They have their own SAML IdP on their PC (at least a few =
years ago) and combined with the qualified certs in the user's smart ca=
rd and another file, creates a SAML assertion with sectoral identifier and =
supply it to other systems. 


Nat

On Wed, Dec 5, 2012 at=
 11:05 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:


I say that it's only theoretical because=
 I don't believe there are any actual deployments supporting, or planni=
ng on supporting, RO as an assertion issuer. 






On Tue, Dec 4, 2012 at 5:39 PM,  <=
zhou.sujing@zte.com.cn> wrote:





Why RO as an issuer is only theoretical
today?










Brian Campbell &l=
t;bcampbell=
@pingidentity.com>


2012-12-04 23:41








=CA=D5=BC=FE=C8=
=CB

Nat Sakimura <sakimura@gmail.com>




=B3=AD=CB=CD

zhou.sujing@zte.com.cn, "oauth@ietf.org"
<oauth@ietf.org&=
gt;




=D6=F7=CC=E2

Re: [OAUTH-WG] Assertion Fram=
ework -
Why does issuer have to be either the client or a third party token service=
?

















The intent was definitely not to c=
onstrain
who/what could be the issuer.  But also try to provide 

some guidance around the common cases that are actually being deployed
now, which are the client self-issued and STS variants. Resource owner
as an issuer is an interesting case but seems mostly theoretical at this
point.



I feel like mentioning the resource owner there in =A1=EC5.1 would cause mo=
re
confusion than anything else. I'd prefer to just strike the whole sente=
nce
in question and maybe add some additional text to =A1=EC3 that clarifies th=
at
the issuer can really be any entity, if folks think a change is needed
here? 







On Mon, Dec 3, 2012 at 9:20 PM, Na=
t
Sakimura <sakimura@gmail.com<=
/u>>
wrote:

Actually, "The
issuer may be either 

  &nbs=
p;  
an OAuth client (when assertions are self-issued) or
any other entity, e.g.,  a
third party 

token service<=
font color=3D"red" face=3D"Arial" size=3D"3">,
resource owner. &q=
uot;  is
not really clean. 



OAuth client is just =
another
example of an issuer. 



So, perhaps the sente=
nce could
be: 



"Example of issu=
ers include
an OAuth client, resource owner, an independent third party."



So, the clause become=
s: 



 Issuer  The unique=
 identifier
for the entity that issued the =


      assertion.  Generally this is the entity that
holds the key 

      material used to generate the assertion.  

      Example =
of
issuers include an OAuth client, resource owner, an independent third party=
.




Nat



Nat



On Tue, Dec 4, 2012 at 11:40 AM, &=
lt;zhou.sujing@zte.com.cn>
wrote:







Chuck Mortimore <cmortimore@sales=
force.com>
=D0=B4=D3=DA 2012-12-04 10:26:50:





> Please feel free to suggest better language.



> 

> Issuer simply allows the token service to know who created the 

> assertion, so it can look them up and see if they're trusted. &nbs=
p;
  

> Effectively the same as an Issuer in SAML.




a conflict : "The token service is the assert=
ion
issuer" in assertion document.


while you said "token service know who created the assertion"




I wonder if the following text is acceptable:


 


  Issuer  The unique identifier for the entity that issued the


      assertion.  Generally this is the entity that
holds the key 

      material used to generate the assertion.  The
issuer may be either 

      an OAuth=
 client
(when assertions are self-issued) or
any other entity, e.g.,  a
third party 

token service, re=
source
owner. 





6.3.  Client Acting on Behalf of a User




The Issuer of the assertion MUST identify the entity that issued


      the assertion as recognized by the Authorization Serve=
r.
 If the 

      assertion is self-issued, the Issuer SHOULD be the
"client_id". 

      If the assertion was issued by a Security Token Servic=
e
(STS), the 

      Issuer SHOULD identify the STS as recognized by the
Authorization <=
font size=3D"3">

      Server.=
If the
assertion was issued by the resource owner, the


      Issuer SHOULD identify the resource owner as recognize=
d
by the Authorization 

      Server.




> 

> -cmort 

> 

> On Dec 3, 2012, at 6:23 PM, <zh=
ou.sujing@zte.com.cn>
wrote: 

> 

> 

> Obviously, it is not so clear from the language there. 

> 

> 

> Chuck Mortimore <cmortimore@=
salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:17:12:

> 

> > There's no reason why it can't be resource owner today. &=
nbsp;


> > 

> > On Dec 3, 2012, at 6:06 PM, <=
zhou.sujing@zte.com.cn>
<zhou.sujing@zte.com.cn

> > > wrote: 

> > 

> > 

> > +1. 

> > And why it was not looked at that time? 

> > 

> > oauth-bounces@ietf.org
=D0=B4=D3=DA 2012-12-04 01:30:55:

> > 

> > > Actually, I think it is a good time to start looking at
the resourse

> > > owner issuing assertions@ (Interestingly enough, Hui-Lan
had brought

> > > this up a couple of years ago.)

> > > 

> > > Igor

> > > 

> > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: 

> > > I suppose, yes. I was reading it like that all the time.


> > > Whether it is or not, if it is still ok, it might be better
to 

> clarify it. 

> > > Word like "third party" tends to be a bit of probl=
em
without 

> > clearlydefining. 

> > > I had similar experience in other fora. 

> > > 

> > > Nat 

> > > 

> > > Sent from iPad 

> > > 

> > > 2012/12/03 0:52=A1=A2"=
zhou.sujing@zte.com.cn"
<zhou.sujing@zte.com.cn>
=A4=CE

> > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:

> > 

> > > 

> > > could be Resource owner? 

> > > 

> > 

> > > 

> > > "Tschofenig, Hannes (NSN - FI/Espoo)" <<=
/tt>hannes.tschofenig@nsn.com>


> > > =B7=A2=BC=FE=C8=CB:  <=
u>oauth-bounces@ietf.org


> > > 2012-12-03 16:49 

> > > 

> > > =CA=D5=BC=FE=C8=CB 

> > > 

> > > "ext Nat Sakimura" <sakimura@gmail.com>,
"Brian Campbell" <

> > > bcampbell@pingidenti=
ty.com>,
"oauth" <oauth@ietf.org>


> > > 

> > > =B3=AD=CB=CD 

> > > 

> > > =D6=F7=CC=E2 

> > > 

> > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have
to be     

> > > either the client or a third party token service? 

> > > 

> > > 

> > > 

> > > 

> > > Hi Nat, 

> > >   

> > > The current text essentially says that the assertion can
either be 

> > > created by the client (in which case it is self-signed)
or it can be

> > > created by some other entity (which is then called the third
party 

> > > token service). So, this third party could be the authorizat=
ion
server. 

> > >   

> > > Ciao

> > > Hannes 

> > >   

> > >   

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

> > > ext Nat Sakimura

> > > Sent: Monday, December 03, 2012 10:35 AM

> > > To: Brian Campbell; oauth

> > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer
have to be

> > > either the client or a third party token service? 

> > >   

> > > Hi Brian, 

> > >   

> > >   

> > > The assertion framework defines the Issuer as: 

> > >   

> > >    Issuer  The unique identifier for the
entity that issued the 

> > >       assertion.  Generally this is
the entity that holds the key 

> > >       material used to generate the assertion=
.
 The issuer may be either 

> > >       an OAuth client (when assertions are
self-issued) or a third party 

> > >       token service. 

> > >   

> > > I was wondering why it has to be either the client or a
third party 

> > > token service. 

> > > Conceptually, it could be any token service (functionality)


> > residingin any of 

> > >   

> > > the stakeholders (Resource Owner, OAuth Client, Authorizatio=
n
Server, or 

> > > a third party). 

> > >   

> > >   

> > > I would appreciate if you could clarify why is the case.


> > >   

> > >   

> > > Best, 

> > >   

> > > -- 

> > > Nat Sakimura (=3Dnat) 

> > > Chairman, OpenID Foundation

> > > http://nat.sakimura.org/<=
/font>

> > > @_nat_en 

> > >  _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

> > > https://ww=
w.ietf.org/mailman/listinfo/oauth<=
br>
> > 

> > > 

> > > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

> > > https://ww=
w.ietf.org/mailman/listinfo/oauth<=
br>
> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

> > > https://ww=
w.ietf.org/mailman/listinfo/oauth<=
br>
> > _______________________________________________

> > OAuth mailing list

> > <=
tt>OAuth@ietf.org

> > https://www.iet=
f.org/mailman/listinfo/oauth




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation=


http://nat.sakimura.org/<=
/font>

@_nat_en





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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
















-- 
=
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_=
en






--047d7b621ef08472bf04d01e1a1a--

From eve@xmlgrrl.com  Wed Dec  5 09:35:21 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A4121F8D02 for ; Wed,  5 Dec 2012 09:35:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.067
X-Spam-Level: 
X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYcxwRJryApf for ; Wed,  5 Dec 2012 09:35:17 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id 2E31321F8C9F for ; Wed,  5 Dec 2012 09:35:17 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id BF7E63B142C; Wed,  5 Dec 2012 09:35:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWwoUdgzOBhp; Wed,  5 Dec 2012 09:35:11 -0800 (PST)
Received: from [192.168.168.107] (unknown [192.168.168.107]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 696F63B1412; Wed,  5 Dec 2012 09:35:11 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_849F16A8-5759-4D94-BB75-AEEC47D46324"
From: Eve Maler 
In-Reply-To: 
Date: Wed, 5 Dec 2012 09:35:10 -0800
Message-Id: <254DA4A9-6155-46D8-BCB6-A6A04868FC0E@xmlgrrl.com>
References:    
To: Nat Sakimura 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 17:35:21 -0000

--Apple-Mail=_849F16A8-5759-4D94-BB75-AEEC47D46324
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=gb18030

Just checking that I understand: If the RO =3D=3D the issuer, then the =
RO =3D=3D the AS, right? Just as in Nat's example, the user (or at least =
the device presenting a user agent to them) =3D=3D the IdP? Colocating =
the RO and AS functions shouldn't be precluded, but I would be awfully =
confused if there were an RO/issuer in the picture and *also* an AS that =
*doesn't* issue assertions.

	Eve

On 5 Dec 2012, at 9:13 AM, Nat Sakimura  wrote:

> It is not OAuth, but Austrian eID system is an example of RO as an =
assertion issuer pattern. They have their own SAML IdP on their PC (at =
least a few years ago) and combined with the qualified certs in the =
user's smart card and another file, creates a SAML assertion with =
sectoral identifier and supply it to other systems.=20
>=20
> Nat
>=20
> On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell =
 wrote:
> I say that it's only theoretical because I don't believe there are any =
actual deployments supporting, or planning on supporting, RO as an =
assertion issuer.=20
>=20
>=20
> On Tue, Dec 4, 2012 at 5:39 PM,  wrote:
>=20
> Why RO as an issuer is only theoretical today?=20
>=20
>=20
>=20
> Brian Campbell 
> 2012-12-04 23:41
>=20
> =CA=D5=BC=FE=C8=CB
> Nat Sakimura 
> =B3=AD=CB=CD
> zhou.sujing@zte.com.cn, "oauth@ietf.org" 
> =D6=F7=CC=E2
> Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either =
the client or a third party token service?
>=20
>=20
>=20
>=20
>=20
> The intent was definitely not to constrain who/what could be the =
issuer.  But also try to provide=20
> some guidance around the common cases that are actually being deployed =
now, which are the client self-issued and STS variants. Resource owner =
as an issuer is an interesting case but seems mostly theoretical at this =
point.
>=20
> I feel like mentioning the resource owner there in =A1=EC5.1 would =
cause more confusion than anything else. I'd prefer to just strike the =
whole sentence in question and maybe add some additional text to =A1=EC3 =
that clarifies that the issuer can really be any entity, if folks think =
a change is needed here?=20
>=20
>=20
>=20
> On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura  =
wrote:=20
> Actually, "The issuer may be either=20
>       an OAuth client (when assertions are self-issued) or any other =
entity, e.g.,  a third party=20
> token service, resource owner. "  is not really clean.=20
>=20
> OAuth client is just another example of an issuer.=20
>=20
> So, perhaps the sentence could be:=20
>=20
> "Example of issuers include an OAuth client, resource owner, an =
independent third party."=20
>=20
> So, the clause becomes:=20
>=20
>  Issuer  The unique identifier for the entity that issued the=20
>      assertion.  Generally this is the entity that holds the key=20
>      material used to generate the assertion.  =20
>       Example of issuers include an OAuth client, resource owner, an =
independent third party.=20
>=20
> Nat=20
>=20
> Nat=20
>=20
> On Tue, Dec 4, 2012 at 11:40 AM,  wrote:=20
>=20
>=20
>=20
> Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 =
10:26:50:=20
>=20
>=20
> > Please feel free to suggest better language.=20
>=20
> >=20
> > Issuer simply allows the token service to know who created the=20
> > assertion, so it can look them up and see if they're trusted.    =20
> > Effectively the same as an Issuer in SAML.=20
>=20
> a conflict : "The token service is the assertion issuer" in assertion =
document.=20
> while you said "token service know who created the assertion"=20
>=20
> I wonder if the following text is acceptable:=20
>  =20
>  Issuer  The unique identifier for the entity that issued the=20
>      assertion.  Generally this is the entity that holds the key=20
>      material used to generate the assertion.  The issuer may be =
either=20
>       an OAuth client (when assertions are self-issued) or any other =
entity, e.g.,  a third party=20
> token service, resource owner.=20
>=20
>=20
> 6.3.  Client Acting on Behalf of a User=20
>=20
> The Issuer of the assertion MUST identify the entity that issued=20
>      the assertion as recognized by the Authorization Server.  If the=20=

>      assertion is self-issued, the Issuer SHOULD be the "client_id".=20=

>      If the assertion was issued by a Security Token Service (STS), =
the=20
>      Issuer SHOULD identify the STS as recognized by the Authorization=20=

>      Server.If the assertion was issued by the resource owner, the=20
>      Issuer SHOULD identify the resource owner as recognized by the =
Authorization=20
>      Server.=20
>=20
> >=20
> > -cmort=20
> >=20
> > On Dec 3, 2012, at 6:23 PM,  wrote:=20
> >=20
> >=20
> > Obviously, it is not so clear from the language there.=20
> >=20
> >=20
> > Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 =
10:17:12:
> >=20
> > > There's no reason why it can't be resource owner today.  =20
> > >=20
> > > On Dec 3, 2012, at 6:06 PM,  =
 > > > wrote:=20
> > >=20
> > >=20
> > > +1.=20
> > > And why it was not looked at that time?=20
> > >=20
> > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:
> > >=20
> > > > Actually, I think it is a good time to start looking at the =
resourse
> > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had =
brought
> > > > this up a couple of years ago.)
> > > >=20
> > > > Igor
> > > >=20
> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:=20
> > > > I suppose, yes. I was reading it like that all the time.=20
> > > > Whether it is or not, if it is still ok, it might be better to=20=

> > clarify it.=20
> > > > Word like "third party" tends to be a bit of problem without=20
> > > clearlydefining.=20
> > > > I had similar experience in other fora.=20
> > > >=20
> > > > Nat=20
> > > >=20
> > > > Sent from iPad=20
> > > >=20
> > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn" =
 =A4=CE
> > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:
> > >=20
> > > >=20
> > > > could be Resource owner?=20
> > > >=20
> > >=20
> > > >=20
> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" =
=20
> > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org=20
> > > > 2012-12-03 16:49=20
> > > >=20
> > > > =CA=D5=BC=FE=C8=CB=20
> > > >=20
> > > > "ext Nat Sakimura" , "Brian Campbell" <
> > > > bcampbell@pingidentity.com>, "oauth" =20
> > > >=20
> > > > =B3=AD=CB=CD=20
> > > >=20
> > > > =D6=F7=CC=E2=20
> > > >=20
> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be  =
  =20
> > > > either the client or a third party token service?=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > Hi Nat,=20
> > > >  =20
> > > > The current text essentially says that the assertion can either =
be=20
> > > > created by the client (in which case it is self-signed) or it =
can be
> > > > created by some other entity (which is then called the third =
party=20
> > > > token service). So, this third party could be the authorization =
server.=20
> > > >  =20
> > > > Ciao
> > > > Hannes=20
> > > >  =20
> > > >  =20
> > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of=20
> > > > ext Nat Sakimura
> > > > Sent: Monday, December 03, 2012 10:35 AM
> > > > To: Brian Campbell; oauth
> > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have =
to be
> > > > either the client or a third party token service?=20
> > > >  =20
> > > > Hi Brian,=20
> > > >  =20
> > > >  =20
> > > > The assertion framework defines the Issuer as:=20
> > > >  =20
> > > >    Issuer  The unique identifier for the entity that issued the=20=

> > > >       assertion.  Generally this is the entity that holds the =
key=20
> > > >       material used to generate the assertion.  The issuer may =
be either=20
> > > >       an OAuth client (when assertions are self-issued) or a =
third party=20
> > > >       token service.=20
> > > >  =20
> > > > I was wondering why it has to be either the client or a third =
party=20
> > > > token service.=20
> > > > Conceptually, it could be any token service (functionality)=20
> > > residingin any of=20
> > > >  =20
> > > > the stakeholders (Resource Owner, OAuth Client, Authorization =
Server, or=20
> > > > a third party).=20
> > > >  =20
> > > >  =20
> > > > I would appreciate if you could clarify why is the case.=20
> > > >  =20
> > > >  =20
> > > > Best,=20
> > > >  =20
> > > > --=20
> > > > Nat Sakimura (=3Dnat)=20
> > > > Chairman, OpenID Foundation
> > > > http://nat.sakimura.org/
> > > > @_nat_en=20
> > > >  _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > >=20
> > > >=20
> > > >=20
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > _______________________________________________
> > > > OAuth mailing 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
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
>=20
> --=20
> Nat Sakimura (=3Dnat)=20
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en=20
>=20
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>=20
>=20
>=20
>=20
>=20
>=20
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl



--Apple-Mail=_849F16A8-5759-4D94-BB75-AEEC47D46324
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=gb18030

	=
Eve
On 5 Dec 2012, at 9:13 AM, Nat Sakimura =
<sakimura@gmail.com> =
wrote:

It is not OAuth, but Austrian eID system is an example of =
RO as an assertion issuer pattern. They have their own SAML IdP on their =
PC (at least a few years ago) and combined with the qualified certs in =
the user's smart card and another file, creates a SAML assertion with =
sectoral identifier and supply it to other systems. 


Nat

On Wed, Dec 5, 2012 =
at 11:05 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:


I say that it's only =
theoretical because I don't believe there are any actual deployments =
supporting, or planning on supporting, RO as =
an assertion issuer. 


=




On Tue, Dec 4, 2012 at 5:39 PM,  =
<zhou.sujing@zte.com.cn> =
wrote:





Why RO as an issuer is only theoretical
today?









Brian Campbell =
<bcampbell@pingidentity.com>

2012-12-04 23:41








=CA=D5=BC=FE=C8=CB

Nat Sakimura <sakimura@gmail.com>




=B3=AD=CB=CD

zhou.sujing@zte.com.cn, "oauth@ietf.org"
<oauth@ietf.org>




=D6=F7=CC=E2

Re: [OAUTH-WG] Assertion =
Framework -
Why does issuer have to be either the client or a third party token =
service?

















The intent was definitely not =
to constrain
who/what could be the issuer.  But also try to provide 

some guidance around the common cases that are actually being deployed
now, which are the client self-issued and STS variants. Resource owner
as an issuer is an interesting case but seems mostly theoretical at this
point.



I feel like mentioning the resource owner there in =A1=EC5.1 would cause =
more
confusion than anything else. I'd prefer to just strike the whole =
sentence
in question and maybe add some additional text to =A1=EC3 that clarifies =
that
the issuer can really be any entity, if folks think a change is needed
here? 







On Mon, Dec 3, 2012 at 9:20 PM, =
Nat
Sakimura <sakimura@gmail.com>
wrote:

Actually, "The
issuer may be either =


  =
   
an OAuth client (when assertions are self-issued) or
any other entity, e.g.,  a
third party 

token =
service,
resource owner. =
"  is
not really clean. 



OAuth client is =
just another
example of an issuer. 



So, perhaps the =
sentence could
be: 



"Example of =
issuers include
an OAuth client, resource owner, an independent third party."



So, the clause =
becomes: 



 Issuer  The =
unique identifier
for the entity that issued the=
 

      assertion.  Generally this is the entity that
holds the key 

      material used to generate the assertion. =
 

      =
Example of
issuers include an OAuth client, resource owner, an independent third =
party.




Nat



Nat



On Tue, Dec 4, 2012 at 11:40 =
AM, <zhou.sujing@zte.com.cn>
wrote:







Chuck Mortimore <cmortimore@salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:26:50:





> Please feel free to suggest better language.



> 

> Issuer simply allows the token service to know who created the 

> assertion, so it can look them up and see if they're trusted. =
 
  

> Effectively the same as an Issuer in SAML.




a conflict : "The token service is the assertion
issuer" in assertion document.


while you said "token service know who created the assertion"




I wonder if the following text is acceptable:


 


  Issuer  The unique identifier for the entity that issued =
the


      assertion.  Generally this is the entity that
holds the key 

      material used to generate the assertion.  The
issuer may be either 

      an =
OAuth client
(when assertions are self-issued) or
any other entity, e.g.,  a
third party 

token service, =
resource
owner. 





6.3.  Client Acting on Behalf of a User




The Issuer of the assertion MUST identify the entity that =
issued


      the assertion as recognized by the Authorization =
Server.
 If the 

      assertion is self-issued, the Issuer SHOULD be the
"client_id". 

      If the assertion was issued by a Security Token =
Service
(STS), the 

      Issuer SHOULD identify the STS as recognized by the
Authorization 

      Server.If =
the
assertion was issued by the resource owner, the


      Issuer SHOULD identify the resource owner as =
recognized
by the Authorization =


      Server.




> 

> -cmort 

> 

> On Dec 3, 2012, at 6:23 PM, <zhou.sujing@zte.com.cn>
wrote: 

> 

> 

> Obviously, it is not so clear from the language there. 

> 

> 

> Chuck Mortimore <cmortimore@salesforce.com>
=D0=B4=D3=DA 2012-12-04 10:17:12:

> 

> > There's no reason why it can't be resource owner today.  


> > 

> > On Dec 3, 2012, at 6:06 PM, <zhou.sujing@zte.com.cn>
<zhou.sujing@zte.com.cn

> > > wrote: 

> > 

> > 

> > +1. 

> > And why it was not looked at that time? 

> > 

> > oauth-bounces@ietf.org
=D0=B4=D3=DA 2012-12-04 01:30:55:

> > 

> > > Actually, I think it is a good time to start looking at
the resourse

> > > owner issuing assertions@ (Interestingly enough, Hui-Lan
had brought

> > > this up a couple of years ago.)

> > > 

> > > Igor

> > > 

> > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: 

> > > I suppose, yes. I was reading it like that all the time.


> > > Whether it is or not, if it is still ok, it might be =
better
to 

> clarify it. 

> > > Word like "third party" tends to be a bit of problem
without 

> > clearlydefining. 

> > > I had similar experience in other fora. 

> > > 

> > > Nat 

> > > 

> > > Sent from iPad 

> > > 

> > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn"
<zhou.sujing@zte.com.cn>
=A4=CE

> > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:

> > 

> > > 

> > > could be Resource owner? 

> > > 

> > 

> > > 

> > > "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>


> > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org


> > > 2012-12-03 16:49 

> > > 

> > > =CA=D5=BC=FE=C8=CB 

> > > 

> > > "ext Nat Sakimura" <sakimura@gmail.com>,
"Brian Campbell" <

> > > bcampbell@pingidentity.com>,
"oauth" <oauth@ietf.org>


> > > 

> > > =B3=AD=CB=CD 

> > > 

> > > =D6=F7=CC=E2 

> > > 

> > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have
to be     

> > > either the client or a third party token service? 

> > > 

> > > 

> > > 

> > > 

> > > Hi Nat, 

> > >   

> > > The current text essentially says that the assertion can
either be 

> > > created by the client (in which case it is self-signed)
or it can be

> > > created by some other entity (which is then called the =
third
party 

> > > token service). So, this third party could be the =
authorization
server. 

> > >   

> > > Ciao

> > > Hannes 

> > >   

> > >   

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

> > > ext Nat Sakimura

> > > Sent: Monday, December 03, 2012 10:35 AM

> > > To: Brian Campbell; oauth

> > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer
have to be

> > > either the client or a third party token service? 

> > >   

> > > Hi Brian, 

> > >   

> > >   

> > > The assertion framework defines the Issuer as: 

> > >   

> > >    Issuer  The unique identifier for the
entity that issued the 

> > >       assertion.  Generally this is
the entity that holds the key 

> > >       material used to generate the =
assertion.
 The issuer may be either 

> > >       an OAuth client (when assertions are
self-issued) or a third party 

> > >       token service. 

> > >   

> > > I was wondering why it has to be either the client or a
third party 

> > > token service. 

> > > Conceptually, it could be any token service =
(functionality)


> > residingin any of 

> > >   

> > > the stakeholders (Resource Owner, OAuth Client, =
Authorization
Server, or 

> > > a third party). 

> > >   

> > >   

> > > I would appreciate if you could clarify why is the case.


> > >   

> > >   

> > > Best, 

> > >   

> > > -- 

> > > Nat Sakimura (=3Dnat) 

> > > Chairman, OpenID Foundation

> > > http://nat.sakimura.org/

> > > @_nat_en 

> > >  _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

> > > https://www.ietf.org/mailman/listinfo/oauth<=
/a>

> > 

> > > 

> > > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

> > > https://www.ietf.org/mailman/listinfo/oauth<=
/a>

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ietf.org

> > > https://www.ietf.org/mailman/listinfo/oauth<=
/a>

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.org

> > https://www.ietf.org/mailman/listinfo/oauth<=
/a>




_______________________________________________

OAuth mailing list

OAuth@ietf.org

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












-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID =
Foundation

http://nat.sakimura.org/

@_nat_en





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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
















-- =

Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en





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



Eve Maler       =
                    =
       http://www.xmlgrrl.com/blog
+1=
 425 345 6756                 =
        http://www.twitter.com/xmlgrrl=







=

--Apple-Mail=_849F16A8-5759-4D94-BB75-AEEC47D46324--

From cmortimore@salesforce.com  Wed Dec  5 15:30:05 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2526821F8C1A for ; Wed,  5 Dec 2012 15:30:05 -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=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnnBWS3DW0N9 for ; Wed,  5 Dec 2012 15:30:03 -0800 (PST)
Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by ietfa.amsl.com (Postfix) with SMTP id C3ABA21F8C23 for ; Wed,  5 Dec 2012 15:30:02 -0800 (PST)
Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKUL/Y+kNNs/5HCDC/WdnHgBOKBZQjSjmM@postini.com; Wed, 05 Dec 2012 15:30:02 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Wed, 5 Dec 2012 15:30:01 -0800
From: Chuck Mortimore 
To: Lewis Adam-CAL022 
Date: Wed, 5 Dec 2012 15:30:00 -0800
Thread-Topic: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Thread-Index: Ac3TQHH/dDdb17ZXTFWuPz4BBLjbrw==
Message-ID: <7A54FDF5-D910-4E60-BB5F-5FB98A4B88E5@salesforce.com>
References:    <59E470B10C4630419ED717AC79FCF9A92F1A9015@BLUPRD0411MB436.namprd04.prod.outlook.com>
In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F1A9015@BLUPRD0411MB436.namprd04.prod.outlook.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_7A54FDF5D9104E60BB5F5FB98A4B88E5salesforcecom_"
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 05 Dec 2012 23:30:05 -0000

--_000_7A54FDF5D9104E60BB5F5FB98A4B88E5salesforcecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

TW9zdCBvZiB0aGUgU1RTIHN0eWxlIHVzYWdlIEkndmUgc2VlbiBoYXMgYmVlbiB1c2luZyB0aGUg
U0FNTCBCZWFyZXIgVG9rZW4sIHJhdGhlciB0aGFuIHRoZSBKV1QgQmVhcmVyIFRva2VuIGZsb3cu
ICAgVGhlIHByZWRvbWluYW50IEpXVCB1c2FnZSBJJ3ZlIHNlZW4gdGh1cyBmYXIgaGFzIGJlZW4g
Zm9yIHNlbGYtaXNzdWVkIGFzc2VydGlvbnMuDQoNClRoYXQgc2FpZCwgdGhlIGxhbmd1YWdlIGlu
IHF1ZXN0aW9uIGlzIGdlbmVyYWxpemVkIHRvIEFzc2VydGlvbiB1c2UtY2FzZXMgcmF0aGVyIHRo
YW4gYSBzcGVjaWZpYyBBc3NlcnRpb24gZm9ybWF0Lg0KDQotY21vcnQNCg0KDQpPbiBEZWMgNSwg
MjAxMiwgYXQgNjo0OCBBTSwgTGV3aXMgQWRhbS1DQUwwMjIgd3JvdGU6DQoNCkhpIEJyaWFuLA0K
DQpUaGlzIGlzIHNvcnQgb2YgbXkgZmVlbGluZyBvbiB0aGUgU1RTIGFzIHdlbGwgKHRoZW9yZXRp
Y2FsKS4gIEFyZSB0aGVyZSBhbnkgcmVhbC1saWZlIGV4YW1wbGVzIG9mIG9idGFpbmluZyBhIEpX
VCBhc3NlcnRpb24gZnJvbSBhbiBTVFMgdGhhdCBjYW4gYmUgdXNlZCBmb3IgdGhlIGFzc2VydGlv
biBmbG93PyAgQW5kIGlmIHNvIHRoZW4gaG93IGlzIGl0IG9idGFpbmVkPyAgSXQgY2Fubm90IGJl
IGFuIGlkX3Rva2VuIGJlY2F1c2UgdGhhdCBpcyBhdWRpZW5jZSByZXN0cmljdGVkIHRvIHRoZSBj
bGllbnQuICBJIGd1ZXNzIGl0IGNvdWxkIGJlIGFuIGFjY2Vzc190b2tlbiB3aXRoIGEgc2NvcGUg
b2YgYXNzZXJ0aW9uPyAgQnV0IEnigJl2ZSBub3Qgc2VlbiBhbnkgZGlzY3Vzc2lvbiBvZiB0aGF0
LiAgSeKAmXZlIGJlZW4gaW50ZXJlc3RlZCBpbiB0aGlzIGZsb3cgZm9yIGEgd2hpbGUgYnV0IHRo
ZSBvbmx5IGV4YW1wbGVzIEnigJltIGF3YXJlIG9mIGFyZSBzZWxmLWlzc3VlZCBKV1RzLiAgSeKA
mWQgYmUgdmVyeSBpbnRlcmVzdGVkIGluIGtub3dpbmcgcmVhbCBsaWZlIG9mIGV4YW1wbGVzIG9m
IGNsaWVudHMgb2J0YWluaW5nIGEgSldUIGFzc2VydGlvbiBmcm9tIGFuIFNUUyB0byB1c2UgYXMg
YSBncmFudCwgYW5kIHRoZSBtZXRob2QgdGhleSB1c2UgdG8gZG8gdGhhdC4NCg0KdHgNCmFkYW0N
Cg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4g
Q2FtcGJlbGwNClNlbnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMDUsIDIwMTIgODowNSBBTQ0KVG86
IHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24+DQpD
Yzogb2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtP
QVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlIHRvIGJl
IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT8NCg0KSSBz
YXkgdGhhdCBpdCdzIG9ubHkgdGhlb3JldGljYWwgYmVjYXVzZSBJIGRvbid0IGJlbGlldmUgdGhl
cmUgYXJlIGFueSBhY3R1YWwgZGVwbG95bWVudHMgc3VwcG9ydGluZywgb3IgcGxhbm5pbmcgb24g
c3VwcG9ydGluZywgUk8gYXMgYW4gYXNzZXJ0aW9uIGlzc3Vlci4NCg0KT24gVHVlLCBEZWMgNCwg
MjAxMiBhdCA1OjM5IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWpp
bmdAenRlLmNvbS5jbj4+IHdyb3RlOg0KDQpXaHkgUk8gYXMgYW4gaXNzdWVyIGlzIG9ubHkgdGhl
b3JldGljYWwgdG9kYXk/DQoNCkJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5
LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+Pg0KDQoyMDEyLTEyLTA0IDIz
OjQxDQoNCg0K5pS25Lu25Lq6DQoNCk5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1h
aWx0bzpzYWtpbXVyYUBnbWFpbC5jb20+Pg0KDQrmioTpgIENCg0KemhvdS5zdWppbmdAenRlLmNv
bS5jbjxtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbj4sICJvYXV0aEBpZXRmLm9yZzxtYWls
dG86b2F1dGhAaWV0Zi5vcmc+IiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3Jn
Pj4NCg0K5Li76aKYDQoNClJlOiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkg
ZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZSBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5
IHRva2VuIHNlcnZpY2U/DQoNCg0KDQoNCg0KDQoNClRoZSBpbnRlbnQgd2FzIGRlZmluaXRlbHkg
bm90IHRvIGNvbnN0cmFpbiB3aG8vd2hhdCBjb3VsZCBiZSB0aGUgaXNzdWVyLiAgQnV0IGFsc28g
dHJ5IHRvIHByb3ZpZGUNCnNvbWUgZ3VpZGFuY2UgYXJvdW5kIHRoZSBjb21tb24gY2FzZXMgdGhh
dCBhcmUgYWN0dWFsbHkgYmVpbmcgZGVwbG95ZWQgbm93LCB3aGljaCBhcmUgdGhlIGNsaWVudCBz
ZWxmLWlzc3VlZCBhbmQgU1RTIHZhcmlhbnRzLiBSZXNvdXJjZSBvd25lciBhcyBhbiBpc3N1ZXIg
aXMgYW4gaW50ZXJlc3RpbmcgY2FzZSBidXQgc2VlbXMgbW9zdGx5IHRoZW9yZXRpY2FsIGF0IHRo
aXMgcG9pbnQuDQoNCkkgZmVlbCBsaWtlIG1lbnRpb25pbmcgdGhlIHJlc291cmNlIG93bmVyIHRo
ZXJlIGluIMKnNS4xIHdvdWxkIGNhdXNlIG1vcmUgY29uZnVzaW9uIHRoYW4gYW55dGhpbmcgZWxz
ZS4gSSdkIHByZWZlciB0byBqdXN0IHN0cmlrZSB0aGUgd2hvbGUgc2VudGVuY2UgaW4gcXVlc3Rp
b24gYW5kIG1heWJlIGFkZCBzb21lIGFkZGl0aW9uYWwgdGV4dCB0byDCpzMgdGhhdCBjbGFyaWZp
ZXMgdGhhdCB0aGUgaXNzdWVyIGNhbiByZWFsbHkgYmUgYW55IGVudGl0eSwgaWYgZm9sa3MgdGhp
bmsgYSBjaGFuZ2UgaXMgbmVlZGVkIGhlcmU/DQoNCg0KDQpPbiBNb24sIERlYyAzLCAyMDEyIGF0
IDk6MjAgUE0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpzYWtpbXVy
YUBnbWFpbC5jb20+PiB3cm90ZToNCkFjdHVhbGx5LCAiVGhlIGlzc3VlciBtYXkgYmUgZWl0aGVy
DQogICAgICBhbiBPQXV0aCBjbGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQp
IG9yIGFueSBvdGhlciBlbnRpdHksIGUuZy4sICBhIHRoaXJkIHBhcnR5DQp0b2tlbiBzZXJ2aWNl
LCByZXNvdXJjZSBvd25lci4gIiAgaXMgbm90IHJlYWxseSBjbGVhbi4NCg0KT0F1dGggY2xpZW50
IGlzIGp1c3QgYW5vdGhlciBleGFtcGxlIG9mIGFuIGlzc3Vlci4NCg0KU28sIHBlcmhhcHMgdGhl
IHNlbnRlbmNlIGNvdWxkIGJlOg0KDQoiRXhhbXBsZSBvZiBpc3N1ZXJzIGluY2x1ZGUgYW4gT0F1
dGggY2xpZW50LCByZXNvdXJjZSBvd25lciwgYW4gaW5kZXBlbmRlbnQgdGhpcmQgcGFydHkuIg0K
DQpTbywgdGhlIGNsYXVzZSBiZWNvbWVzOg0KDQogSXNzdWVyICBUaGUgdW5pcXVlIGlkZW50aWZp
ZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhlDQogICAgIGFzc2VydGlvbi4gIEdlbmVy
YWxseSB0aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUga2V5DQogICAgIG1hdGVyaWFs
IHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4NCiAgICAgIEV4YW1wbGUgb2YgaXNzdWVy
cyBpbmNsdWRlIGFuIE9BdXRoIGNsaWVudCwgcmVzb3VyY2Ugb3duZXIsIGFuIGluZGVwZW5kZW50
IHRoaXJkIHBhcnR5Lg0KDQpOYXQNCg0KTmF0DQoNCk9uIFR1ZSwgRGVjIDQsIDIwMTIgYXQgMTE6
NDAgQU0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPG1haWx0bzp6aG91LnN1amluZ0B6dGUuY29t
LmNuPj4gd3JvdGU6DQoNCg0KDQpDaHVjayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVAc2FsZXNmb3Jj
ZS5jb208bWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20+PiDlhpnkuo4gMjAxMi0xMi0w
NCAxMDoyNjo1MDoNCg0KDQo+IFBsZWFzZSBmZWVsIGZyZWUgdG8gc3VnZ2VzdCBiZXR0ZXIgbGFu
Z3VhZ2UuDQoNCj4NCj4gSXNzdWVyIHNpbXBseSBhbGxvd3MgdGhlIHRva2VuIHNlcnZpY2UgdG8g
a25vdyB3aG8gY3JlYXRlZCB0aGUNCj4gYXNzZXJ0aW9uLCBzbyBpdCBjYW4gbG9vayB0aGVtIHVw
IGFuZCBzZWUgaWYgdGhleSdyZSB0cnVzdGVkLg0KPiBFZmZlY3RpdmVseSB0aGUgc2FtZSBhcyBh
biBJc3N1ZXIgaW4gU0FNTC4NCg0KYSBjb25mbGljdCA6ICJUaGUgdG9rZW4gc2VydmljZSBpcyB0
aGUgYXNzZXJ0aW9uIGlzc3VlciIgaW4gYXNzZXJ0aW9uIGRvY3VtZW50Lg0Kd2hpbGUgeW91IHNh
aWQgInRva2VuIHNlcnZpY2Uga25vdyB3aG8gY3JlYXRlZCB0aGUgYXNzZXJ0aW9uIg0KDQpJIHdv
bmRlciBpZiB0aGUgZm9sbG93aW5nIHRleHQgaXMgYWNjZXB0YWJsZToNCg0KIElzc3VlciAgVGhl
IHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVkIHRoZQ0KICAgICBh
c3NlcnRpb24uICBHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5IHRoYXQgaG9sZHMgdGhlIGtl
eQ0KICAgICBtYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uICBUaGUgaXNz
dWVyIG1heSBiZSBlaXRoZXINCiAgICAgIGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25z
IGFyZSBzZWxmLWlzc3VlZCkgb3IgYW55IG90aGVyIGVudGl0eSwgZS5nLiwgIGEgdGhpcmQgcGFy
dHkNCnRva2VuIHNlcnZpY2UsIHJlc291cmNlIG93bmVyLg0KDQoNCjYuMy4gIENsaWVudCBBY3Rp
bmcgb24gQmVoYWxmIG9mIGEgVXNlcg0KDQpUaGUgSXNzdWVyIG9mIHRoZSBhc3NlcnRpb24gTVVT
VCBpZGVudGlmeSB0aGUgZW50aXR5IHRoYXQgaXNzdWVkDQogICAgIHRoZSBhc3NlcnRpb24gYXMg
cmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIuICBJZiB0aGUNCiAgICAgYXNz
ZXJ0aW9uIGlzIHNlbGYtaXNzdWVkLCB0aGUgSXNzdWVyIFNIT1VMRCBiZSB0aGUgImNsaWVudF9p
ZCIuDQogICAgIElmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSBhIFNlY3VyaXR5IFRva2Vu
IFNlcnZpY2UgKFNUUyksIHRoZQ0KICAgICBJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSBTVFMg
YXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlvbg0KICAgICBTZXJ2ZXIuSWYgdGhlIGFz
c2VydGlvbiB3YXMgaXNzdWVkIGJ5IHRoZSByZXNvdXJjZSBvd25lciwgdGhlDQogICAgIElzc3Vl
ciBTSE9VTEQgaWRlbnRpZnkgdGhlIHJlc291cmNlIG93bmVyIGFzIHJlY29nbml6ZWQgYnkgdGhl
IEF1dGhvcml6YXRpb24NCiAgICAgU2VydmVyLg0KDQo+DQo+IC1jbW9ydA0KPg0KPiBPbiBEZWMg
MywgMjAxMiwgYXQgNjoyMyBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFpbHRvOnpob3Uu
c3VqaW5nQHp0ZS5jb20uY24+PiB3cm90ZToNCj4NCj4NCj4gT2J2aW91c2x5LCBpdCBpcyBub3Qg
c28gY2xlYXIgZnJvbSB0aGUgbGFuZ3VhZ2UgdGhlcmUuDQo+DQo+DQo+IENodWNrIE1vcnRpbW9y
ZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbTxtYWlsdG86Y21vcnRpbW9yZUBzYWxlc2ZvcmNl
LmNvbT4+IOWGmeS6jiAyMDEyLTEyLTA0IDEwOjE3OjEyOg0KPg0KPiA+IFRoZXJlJ3Mgbm8gcmVh
c29uIHdoeSBpdCBjYW4ndCBiZSByZXNvdXJjZSBvd25lciB0b2RheS4NCj4gPg0KPiA+IE9uIERl
YyAzLCAyMDEyLCBhdCA2OjA2IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhv
dS5zdWppbmdAenRlLmNvbS5jbj4+IDx6aG91LnN1amluZ0B6dGUuY29tLmNuPG1haWx0bzp6aG91
LnN1amluZ0B6dGUuY29tLmNuPg0KPiA+ID4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+ICsxLg0KPiA+
IEFuZCB3aHkgaXQgd2FzIG5vdCBsb29rZWQgYXQgdGhhdCB0aW1lPw0KPiA+DQo+ID4gb2F1dGgt
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4g5YaZ5LqOIDIw
MTItMTItMDQgMDE6MzA6NTU6DQo+ID4NCj4gPiA+IEFjdHVhbGx5LCBJIHRoaW5rIGl0IGlzIGEg
Z29vZCB0aW1lIHRvIHN0YXJ0IGxvb2tpbmcgYXQgdGhlIHJlc291cnNlDQo+ID4gPiBvd25lciBp
c3N1aW5nIGFzc2VydGlvbnNAIChJbnRlcmVzdGluZ2x5IGVub3VnaCwgSHVpLUxhbiBoYWQgYnJv
dWdodA0KPiA+ID4gdGhpcyB1cCBhIGNvdXBsZSBvZiB5ZWFycyBhZ28uKQ0KPiA+ID4NCj4gPiA+
IElnb3INCj4gPiA+DQo+ID4gPiBPbiAxMi8zLzIwMTIgMzo1OCBBTSwgTmF0IFNha2ltdXJhIHdy
b3RlOg0KPiA+ID4gSSBzdXBwb3NlLCB5ZXMuIEkgd2FzIHJlYWRpbmcgaXQgbGlrZSB0aGF0IGFs
bCB0aGUgdGltZS4NCj4gPiA+IFdoZXRoZXIgaXQgaXMgb3Igbm90LCBpZiBpdCBpcyBzdGlsbCBv
aywgaXQgbWlnaHQgYmUgYmV0dGVyIHRvDQo+IGNsYXJpZnkgaXQuDQo+ID4gPiBXb3JkIGxpa2Ug
InRoaXJkIHBhcnR5IiB0ZW5kcyB0byBiZSBhIGJpdCBvZiBwcm9ibGVtIHdpdGhvdXQNCj4gPiBj
bGVhcmx5ZGVmaW5pbmcuDQo+ID4gPiBJIGhhZCBzaW1pbGFyIGV4cGVyaWVuY2UgaW4gb3RoZXIg
Zm9yYS4NCj4gPiA+DQo+ID4gPiBOYXQNCj4gPiA+DQo+ID4gPiBTZW50IGZyb20gaVBhZA0KPiA+
ID4NCj4gPiA+IDIwMTIvMTIvMDMgMDo1MuOAgSJ6aG91LnN1amluZ0B6dGUuY29tLmNuPG1haWx0
bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPiIgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFpbHRv
Onpob3Uuc3VqaW5nQHp0ZS5jb20uY24+PiDjga4NCj4gPiA+IOODoeODg+OCu+ODvOOCuDoNCj4g
Pg0KPiA+ID4NCj4gPiA+IGNvdWxkIGJlIFJlc291cmNlIG93bmVyPw0KPiA+ID4NCj4gPg0KPiA+
ID4NCj4gPiA+ICJUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKSIgPGhhbm5lcy50
c2Nob2ZlbmlnQG5zbi5jb208bWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20+Pg0KPiA+
ID4g5Y+R5Lu25Lq6OiAgb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZz4NCj4gPiA+IDIwMTItMTItMDMgMTY6NDkNCj4gPiA+DQo+ID4gPiDmlLbku7bk
uroNCj4gPiA+DQo+ID4gPiAiZXh0IE5hdCBTYWtpbXVyYSIgPHNha2ltdXJhQGdtYWlsLmNvbTxt
YWlsdG86c2FraW11cmFAZ21haWwuY29tPj4sICJCcmlhbiBDYW1wYmVsbCIgPA0KPiA+ID4gYmNh
bXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t
Pj4sICJvYXV0aCIgPG9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0aEBpZXRmLm9yZz4+DQo+ID4g
Pg0KPiA+ID4g5oqE6YCBDQo+ID4gPg0KPiA+ID4g5Li76aKYDQo+ID4gPg0KPiA+ID4gUmU6IFtP
QVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlIHRvIGJl
DQo+ID4gPiBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/
DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gSGkgTmF0LA0KPiA+ID4NCj4gPiA+
IFRoZSBjdXJyZW50IHRleHQgZXNzZW50aWFsbHkgc2F5cyB0aGF0IHRoZSBhc3NlcnRpb24gY2Fu
IGVpdGhlciBiZQ0KPiA+ID4gY3JlYXRlZCBieSB0aGUgY2xpZW50IChpbiB3aGljaCBjYXNlIGl0
IGlzIHNlbGYtc2lnbmVkKSBvciBpdCBjYW4gYmUNCj4gPiA+IGNyZWF0ZWQgYnkgc29tZSBvdGhl
ciBlbnRpdHkgKHdoaWNoIGlzIHRoZW4gY2FsbGVkIHRoZSB0aGlyZCBwYXJ0eQ0KPiA+ID4gdG9r
ZW4gc2VydmljZSkuIFNvLCB0aGlzIHRoaXJkIHBhcnR5IGNvdWxkIGJlIHRoZSBhdXRob3JpemF0
aW9uIHNlcnZlci4NCj4gPiA+DQo+ID4gPiBDaWFvDQo+ID4gPiBIYW5uZXMNCj4gPiA+DQo+ID4g
Pg0KPiA+ID4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1i
b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mDQo+ID4gPiBleHQgTmF0IFNha2ltdXJhDQo+
ID4gPiBTZW50OiBNb25kYXksIERlY2VtYmVyIDAzLCAyMDEyIDEwOjM1IEFNDQo+ID4gPiBUbzog
QnJpYW4gQ2FtcGJlbGw7IG9hdXRoDQo+ID4gPiBTdWJqZWN0OiBbT0FVVEgtV0ddIEFzc2VydGlv
biBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZQ0KPiA+ID4gZWl0aGVyIHRo
ZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPw0KPiA+ID4NCj4gPiA+IEhp
IEJyaWFuLA0KPiA+ID4NCj4gPiA+DQo+ID4gPiBUaGUgYXNzZXJ0aW9uIGZyYW1ld29yayBkZWZp
bmVzIHRoZSBJc3N1ZXIgYXM6DQo+ID4gPg0KPiA+ID4gICAgSXNzdWVyICBUaGUgdW5pcXVlIGlk
ZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhlDQo+ID4gPiAgICAgICBhc3Nl
cnRpb24uICBHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5IHRoYXQgaG9sZHMgdGhlIGtleQ0K
PiA+ID4gICAgICAgbWF0ZXJpYWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLiAgVGhl
IGlzc3VlciBtYXkgYmUgZWl0aGVyDQo+ID4gPiAgICAgICBhbiBPQXV0aCBjbGllbnQgKHdoZW4g
YXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9yIGEgdGhpcmQgcGFydHkNCj4gPiA+ICAgICAg
IHRva2VuIHNlcnZpY2UuDQo+ID4gPg0KPiA+ID4gSSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMg
dG8gYmUgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eQ0KPiA+ID4gdG9rZW4gc2Vy
dmljZS4NCj4gPiA+IENvbmNlcHR1YWxseSwgaXQgY291bGQgYmUgYW55IHRva2VuIHNlcnZpY2Ug
KGZ1bmN0aW9uYWxpdHkpDQo+ID4gcmVzaWRpbmdpbiBhbnkgb2YNCj4gPiA+DQo+ID4gPiB0aGUg
c3Rha2Vob2xkZXJzIChSZXNvdXJjZSBPd25lciwgT0F1dGggQ2xpZW50LCBBdXRob3JpemF0aW9u
IFNlcnZlciwgb3INCj4gPiA+IGEgdGhpcmQgcGFydHkpLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBJ
IHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IGNvdWxkIGNsYXJpZnkgd2h5IGlzIHRoZSBjYXNlLg0K
PiA+ID4NCj4gPiA+DQo+ID4gPiBCZXN0LA0KPiA+ID4NCj4gPiA+IC0tDQo+ID4gPiBOYXQgU2Fr
aW11cmEgKD1uYXQpDQo+ID4gPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4gPiA+IGh0
dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiA+ID4gQF9uYXRfZW4NCj4gPiA+ICBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+ID4g
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4NCj4gPiA+
DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gT0F1dGhAaWV0Zi5vcmc8bWFp
bHRvOk9BdXRoQGlldGYub3JnPg0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9vYXV0aA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gT0F1dGhAaWV0Zi5v
cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5v
cmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3Vu
ZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlz
dA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYu
b3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg0K

--_000_7A54FDF5D9104E60BB5F5FB98A4B88E5salesforcecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PGJhc2UgaHJlZj0ieC1tc2c6Ly80NzkvIj48L2hlYWQ+PGJvZHkgc3R5bGU9
IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0
LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPk1vc3Qgb2YgdGhlIFNUUyBzdHlsZSB1
c2FnZSBJJ3ZlIHNlZW4gaGFzIGJlZW4gdXNpbmcgdGhlIFNBTUwgQmVhcmVyIFRva2VuLCByYXRo
ZXIgdGhhbiB0aGUgSldUIEJlYXJlciBUb2tlbiBmbG93LiAmbmJzcDsgVGhlIHByZWRvbWluYW50
IEpXVCB1c2FnZSBJJ3ZlIHNlZW4gdGh1cyBmYXIgaGFzIGJlZW4gZm9yIHNlbGYtaXNzdWVkIGFz
c2VydGlvbnMuICZuYnNwOyAmbmJzcDs8ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYXQgc2FpZCwgdGhl
IGxhbmd1YWdlIGluIHF1ZXN0aW9uIGlzIGdlbmVyYWxpemVkIHRvIEFzc2VydGlvbiB1c2UtY2Fz
ZXMgcmF0aGVyIHRoYW4gYSBzcGVjaWZpYyBBc3NlcnRpb24gZm9ybWF0LjwvZGl2PjxkaXY+PGJy
PjwvZGl2PjxkaXY+LWNtb3J0PGJyPjxkaXY+PGRpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48
L2Rpdj48ZGl2Pk9uIERlYyA1LCAyMDEyLCBhdCA2OjQ4IEFNLCBMZXdpcyBBZGFtLUNBTDAyMiB3
cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjxibG9ja3F1
b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iYm9y
ZGVyLWNvbGxhcHNlOiBzZXBhcmF0ZTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zdHls
ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0
dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4
dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog
bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsg
LXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLXZl
cnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDog
bm9uZTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7IGZvbnQtc2l6ZTogbWVkaXVtOyAiPjxkaXYgbGFuZz0iRU4tVVMiIGxpbms9
ImJsdWUiIHZsaW5rPSJwdXJwbGUiPjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBh
Z2U6IFdvcmRTZWN0aW9uMTsgIj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2lu
LWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
bWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiAnQm9vayBBbnRpcXVhJywgc2VyaWY7IGNv
bG9yOiBvbGl2ZTsgIj5IaSBCcmlhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxl
PSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBm
b250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9t
OiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5
OiAnQm9vayBBbnRpcXVhJywgc2VyaWY7IGNvbG9yOiBvbGl2ZTsgIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6
IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgbWFyZ2lu
LXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOiAxMC41cHQ7IGZvbnQtZmFtaWx5OiAnQm9vayBBbnRpcXVhJywgc2VyaWY7IGNvbG9yOiBv
bGl2ZTsgIj5UaGlzIGlzIHNvcnQgb2YgbXkgZmVlbGluZyBvbiB0aGUgU1RTIGFzIHdlbGwgKHRo
ZW9yZXRpY2FsKS4mbmJzcDsgQXJlIHRoZXJlIGFueSByZWFsLWxpZmUgZXhhbXBsZXMgb2Ygb2J0
YWluaW5nIGEgSldUIGFzc2VydGlvbiBmcm9tIGFuIFNUUyB0aGF0IGNhbiBiZSB1c2VkIGZvciB0
aGUgYXNzZXJ0aW9uIGZsb3c/Jm5ic3A7IEFuZCBpZiBzbyB0aGVuIGhvdyBpcyBpdCBvYnRhaW5l
ZD8mbmJzcDsgSXQgY2Fubm90IGJlIGFuIGlkX3Rva2VuIGJlY2F1c2UgdGhhdCBpcyBhdWRpZW5j
ZSByZXN0cmljdGVkIHRvIHRoZSBjbGllbnQuJm5ic3A7IEkgZ3Vlc3MgaXQgY291bGQgYmUgYW4g
YWNjZXNzX3Rva2VuIHdpdGggYSBzY29wZSBvZiBhc3NlcnRpb24/Jm5ic3A7IEJ1dCBJ4oCZdmUg
bm90IHNlZW4gYW55IGRpc2N1c3Npb24gb2YgdGhhdC4mbmJzcDsgSeKAmXZlIGJlZW4gaW50ZXJl
c3RlZCBpbiB0aGlzIGZsb3cgZm9yIGEgd2hpbGUgYnV0IHRoZSBvbmx5IGV4YW1wbGVzIEnigJlt
IGF3YXJlIG9mIGFyZSBzZWxmLWlzc3VlZCBKV1RzLiZuYnNwOyBJ4oCZZCBiZSB2ZXJ5IGludGVy
ZXN0ZWQgaW4ga25vd2luZyByZWFsIGxpZmUgb2YgZXhhbXBsZXMgb2YgY2xpZW50cyBvYnRhaW5p
bmcgYSBKV1QgYXNzZXJ0aW9uIGZyb20gYW4gU1RTIHRvIHVzZSBhcyBhIGdyYW50LCBhbmQgdGhl
IG1ldGhvZCB0aGV5IHVzZSB0byBkbyB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYg
c3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEy
cHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1i
b3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgZm9udC1m
YW1pbHk6ICdCb29rIEFudGlxdWEnLCBzZXJpZjsgY29sb3I6IG9saXZlOyAiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4t
bGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyBt
YXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6IDEwLjVwdDsgZm9udC1mYW1pbHk6ICdCb29rIEFudGlxdWEnLCBzZXJpZjsgY29s
b3I6IG9saXZlOyAiPnR4PG86cD48L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2lu
LXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p
bHk6IFNpbVN1biwgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAx
cHQ7ICI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBmb250LWZhbWlseTogJ0Jvb2sg
QW50aXF1YScsIHNlcmlmOyBjb2xvcjogb2xpdmU7ICI+YWRhbTxvOnA+PC9vOnA+PC9zcGFuPjwv
ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBmb250
LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47
IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjVw
dDsgZm9udC1mYW1pbHk6ICdCb29rIEFudGlxdWEnLCBzZXJpZjsgY29sb3I6IG9saXZlOyAiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImJvcmRlci1yaWdodC1zdHls
ZTogbm9uZTsgYm9yZGVyLWJvdHRvbS1zdHlsZTogbm9uZTsgYm9yZGVyLWxlZnQtc3R5bGU6IG5v
bmU7IGJvcmRlci13aWR0aDogaW5pdGlhbDsgYm9yZGVyLWNvbG9yOiBpbml0aWFsOyBib3JkZXIt
dG9wLXN0eWxlOiBzb2xpZDsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBi
b3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmctdG9wOiAzcHQ7IHBhZGRpbmctcmlnaHQ6IDBp
bjsgcGFkZGluZy1ib3R0b206IDBpbjsgcGFkZGluZy1sZWZ0OiAwaW47ICI+PGRpdiBzdHlsZT0i
bWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9u
dC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTog
MC4wMDAxcHQ7ICI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6
IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsgIj48c3BhbiBjbGFz
cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9u
OiB1bmRlcmxpbmU7ICI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W21haWx0bzpvYXV0aC1ib3VuY2VzQGll
dGYub3JnXTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8
L3NwYW4+PC9iPkJyaWFuIENhbXBiZWxsPGJyPjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIERlY2VtYmVyIDA1LCAy
MDEyIDg6MDUgQU08YnI+PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbiIg
c3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj56aG91LnN1
amluZ0B6dGUuY29tLmNuPC9hPjxicj48Yj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIg
c3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj5vYXV0aEBp
ZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsg
LSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZSBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJk
IHBhcnR5IHRva2VuIHNlcnZpY2U/PG86cD48L286cD48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiBz
dHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJw
dDsgZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJv
dHRvbTogMC4wMDAxcHQ7ICI+PG86cD4mbmJzcDs8L286cD48L2Rpdj48ZGl2IHN0eWxlPSJtYXJn
aW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh
bWlseTogU2ltU3VuLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBtYXJnaW4tYm90dG9tOiAwLjAw
MDFwdDsgIj5JIHNheSB0aGF0IGl0J3Mgb25seSB0aGVvcmV0aWNhbCBiZWNhdXNlIEkgZG9uJ3Qg
YmVsaWV2ZSB0aGVyZSBhcmUgYW55IGFjdHVhbCBkZXBsb3ltZW50cyBzdXBwb3J0aW5nLCBvciBw
bGFubmluZyBvbiBzdXBwb3J0aW5nLDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm
OyAiPlJPIGFzIGFuIGFzc2VydGlvbiBpc3N1ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PGRp
dj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s
ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7IG1h
cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMTJwdDsgIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDogMGluOyBm
b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyBtYXJnaW4tdG9wOiAw
aW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPk9uIFR1ZSwgRGVjIDQsIDIwMTIgYXQgNToz
OSBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIiB0YXJnZXQ9
Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsg
Ij56aG91LnN1amluZ0B6dGUuY29tLmNuPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L2Rpdj48
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0
OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7IG1hcmdp
bi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMTJwdDsgIj48YnI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj5XaHkgUk8gYXMgYW4gaXNzdWVyIGlzIG9ubHkg
dGhlb3JldGljYWwgdG9kYXk/PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjx0YWJsZSBjbGFzcz0iTXNv
Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBzdHls
ZT0id2lkdGg6IDEyMjFweDsgIj48dGJvZHk+PHRyPjx0ZCB3aWR0aD0iMzYlIiB2YWxpZ249InRv
cCIgc3R5bGU9IndpZHRoOiA0MzlweDsgcGFkZGluZy10b3A6IDAuNzVwdDsgcGFkZGluZy1yaWdo
dDogMC43NXB0OyBwYWRkaW5nLWJvdHRvbTogMC43NXB0OyBwYWRkaW5nLWxlZnQ6IDAuNzVwdDsg
Ij48ZGl2IHN0eWxlPSJtYXJnaW4tcmlnaHQ6IDBpbjsgbWFyZ2luLWxlZnQ6IDBpbjsgZm9udC1z
aXplOiAxMnB0OyBmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgbWFyZ2luLXRvcDogMGluOyBt
YXJnaW4tYm90dG9tOiAwLjAwMDFwdDsgIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA3LjVw
dDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPkJyaWFuIENhbXBiZWxsICZsdDs8
YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5r
IiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPmJjYW1w
YmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6IDcuNXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+PC9zcGFuPjxv
OnA+PC9vOnA+PC9kaXY+PHAgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog
MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6IDcuNXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7
ICI+MjAxMi0xMi0wNCAyMzo0MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L3RkPjx0ZCB3aWR0aD0i
NjMlIiB2YWxpZ249InRvcCIgc3R5bGU9IndpZHRoOiA3NzJweDsgcGFkZGluZy10b3A6IDAuNzVw
dDsgcGFkZGluZy1yaWdodDogMC43NXB0OyBwYWRkaW5nLWJvdHRvbTogMC43NXB0OyBwYWRkaW5n
LWxlZnQ6IDAuNzVwdDsgIj48dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAi
IGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOiA3NzJweDsgIj48dGJv
ZHk+PHRyPjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmctdG9wOiAwLjc1cHQ7IHBhZGRp
bmctcmlnaHQ6IDAuNzVwdDsgcGFkZGluZy1ib3R0b206IDAuNzVwdDsgcGFkZGluZy1sZWZ0OiAw
Ljc1cHQ7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47
IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7IG1hcmdpbi10b3A6
IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IHRleHQtYWxpZ246IHJpZ2h0OyAiPjxzcGFu
IGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOiA3LjVwdDsgIj7mlLbku7bkuro8L3NwYW4+
PG86cD48L286cD48L2Rpdj48L3RkPjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmctdG9w
OiAwLjc1cHQ7IHBhZGRpbmctcmlnaHQ6IDAuNzVwdDsgcGFkZGluZy1ib3R0b206IDAuNzVwdDsg
cGFkZGluZy1sZWZ0OiAwLjc1cHQ7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1h
cmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1biwgc2Vy
aWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTogNy41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj5O
YXQgU2FraW11cmEgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iIHRhcmdl
dD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5l
OyAiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9kaXY+PC90
ZD48L3RyPjx0cj48dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nLXRvcDogMC43NXB0OyBw
YWRkaW5nLXJpZ2h0OiAwLjc1cHQ7IHBhZGRpbmctYm90dG9tOiAwLjc1cHQ7IHBhZGRpbmctbGVm
dDogMC43NXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJnaW4tbGVmdDog
MGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyBtYXJnaW4t
dG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyB0ZXh0LWFsaWduOiByaWdodDsgIj48
c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTogNy41cHQ7ICI+5oqE6YCBPC9zcGFu
PjxvOnA+PC9vOnA+PC9kaXY+PC90ZD48dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nLXRv
cDogMC43NXB0OyBwYWRkaW5nLXJpZ2h0OiAwLjc1cHQ7IHBhZGRpbmctYm90dG9tOiAwLjc1cHQ7
IHBhZGRpbmctbGVmdDogMC43NXB0OyAiPjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBt
YXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW4sIHNl
cmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6IDcuNXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+
PGEgaHJlZj0ibWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24iIHRhcmdldD0iX2JsYW5rIiBz
dHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPnpob3Uuc3Vq
aW5nQHp0ZS5jb20uY248L2E+LCAiPGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGlu
ZTsgIj5vYXV0aEBpZXRmLm9yZzwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86b2F1dGhAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjog
dW5kZXJsaW5lOyAiPm9hdXRoQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48L2Rp
dj48L3RkPjwvdHI+PHRyPjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmctdG9wOiAwLjc1
cHQ7IHBhZGRpbmctcmlnaHQ6IDAuNzVwdDsgcGFkZGluZy1ib3R0b206IDAuNzVwdDsgcGFkZGlu
Zy1sZWZ0OiAwLjc1cHQ7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1s
ZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7IG1h
cmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7IHRleHQtYWxpZ246IHJpZ2h0
OyAiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOiA3LjVwdDsgIj7kuLvpopg8
L3NwYW4+PG86cD48L286cD48L2Rpdj48L3RkPjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp
bmctdG9wOiAwLjc1cHQ7IHBhZGRpbmctcmlnaHQ6IDAuNzVwdDsgcGFkZGluZy1ib3R0b206IDAu
NzVwdDsgcGFkZGluZy1sZWZ0OiAwLjc1cHQ7ICI+PGRpdiBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAw
aW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1
biwgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2luLWJvdHRvbTogMC4wMDAxcHQ7ICI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTogNy41cHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp
ZjsgIj5SZTogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVy
IGhhdmUgdG8gYmUgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2
aWNlPzwvc3Bhbj48bzpwPjwvbzpwPjwvZGl2PjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PGRp
diBzdHlsZT0ibWFyZ2luLXJpZ2h0OiAwaW47IG1hcmdpbi1sZWZ0OiAwaW47IGZvbnQtc2l6ZTog
MTJwdDsgZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7IG1hcmdpbi10b3A6IDBpbjsgbWFyZ2lu
LWJvdHRvbTogMC4wMDAxcHQ7ICI+PG86cD4mbmJzcDs8L286cD48L2Rpdj48dGFibGUgY2xhc3M9
Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj48dGJvZHk+PHRyPjx0
ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmctdG9wOiAwLjc1cHQ7IHBhZGRpbmctcmlnaHQ6
IDAuNzVwdDsgcGFkZGluZy1ib3R0b206IDAuNzVwdDsgcGFkZGluZy1sZWZ0OiAwLjc1cHQ7ICI+
PC90ZD48dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nLXRvcDogMC43NXB0OyBwYWRkaW5n
LXJpZ2h0OiAwLjc1cHQ7IHBhZGRpbmctYm90dG9tOiAwLjc1cHQ7IHBhZGRpbmctbGVmdDogMC43
NXB0OyAiPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PC90ZD48L3RyPjwvdGJvZHk+PC90YWJs
ZT48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1yaWdodDogMGlu
OyBtYXJnaW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW4s
IHNlcmlmOyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDEycHQ7ICI+PGJyPjxicj48
YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj5UaGUgaW50
ZW50IHdhcyBkZWZpbml0ZWx5IG5vdCB0byBjb25zdHJhaW4gd2hvL3doYXQgY291bGQgYmUgdGhl
IGlzc3Vlci4gJm5ic3A7QnV0IGFsc28gdHJ5IHRvIHByb3ZpZGU8c3BhbiBjbGFzcz0iQXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPnNvbWUgZ3VpZGFuY2UgYXJvdW5kIHRo
ZSBjb21tb24gY2FzZXMgdGhhdCBhcmUgYWN0dWFsbHkgYmVpbmcgZGVwbG95ZWQgbm93LCB3aGlj
aCBhcmUgdGhlIGNsaWVudCBzZWxmLWlzc3VlZCBhbmQgU1RTIHZhcmlhbnRzLiBSZXNvdXJjZSBv
d25lciBhcyBhbiBpc3N1ZXIgaXMgYW4gaW50ZXJlc3RpbmcgY2FzZSBidXQgc2VlbXMgbW9zdGx5
IHRoZW9yZXRpY2FsIGF0IHRoaXMgcG9pbnQuPGJyPjxicj5JIGZlZWwgbGlrZSBtZW50aW9uaW5n
IHRoZSByZXNvdXJjZSBvd25lciB0aGVyZSBpbiDCpzUuMSB3b3VsZCBjYXVzZSBtb3JlIGNvbmZ1
c2lvbiB0aGFuIGFueXRoaW5nIGVsc2UuIEknZCBwcmVmZXIgdG8ganVzdCBzdHJpa2UgdGhlIHdo
b2xlIHNlbnRlbmNlIGluIHF1ZXN0aW9uIGFuZCBtYXliZSBhZGQgc29tZSBhZGRpdGlvbmFsIHRl
eHQgdG8gwqczIHRoYXQgY2xhcmlmaWVzIHRoYXQgdGhlIGlzc3VlciBjYW4gcmVhbGx5IGJlIGFu
eSBlbnRpdHksIGlmIGZvbGtzIHRoaW5rIGEgY2hhbmdlIGlzIG5lZWRlZCBoZXJlPzxzcGFuIGNs
YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+PC9zcGFuPjxicj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPjxicj48L3NwYW4+
PGJyPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+T24gTW9u
LCBEZWMgMywgMjAxMiBhdCA5OjIwIFBNLCBOYXQgU2FraW11cmEgJmx0Ozwvc3Bhbj48YSBocmVm
PSJtYWlsdG86c2FraW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9y
OiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPnNha2ltdXJhQGdtYWlsLmNvbTwvc3Bhbj48L2E+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj4mZ3Q7IHdyb3Rl
Ojwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PGJyPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+QWN0dWFs
bHksICI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg
c2VyaWY7IGNvbG9yOiByZ2IoODAsIDAsIDgwKTsgIj5UaGUgaXNzdWVyIG1heSBiZSBlaXRoZXI8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6
IHJnYig4MCwgMCwgODApOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PGJyPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5l
dyBSb21hbicsIHNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyAiPiZuYnNwOyAmbmJzcDsg
Jm5ic3A7IGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3VlZCkg
b3I8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy
aWY7IGNvbG9yOiByZWQ7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPmFueSBvdGhlciBlbnRpdHksIGUuZy4sICZuYnNwOzwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IHJnYigzNCwg
MzQsIDM0KTsgIj5hIHRoaXJkIHBhcnR5PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh
bCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzNCwgMzQsIDM0KTsgIj50b2tlbiBzZXJ2aWNlPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBy
ZWQ7ICI+LCByZXNvdXJjZSBvd25lcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy
aWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyAiPi4gIiAmbmJzcDtpcyBu
b3QgcmVhbGx5IGNsZWFuLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L3NwYW4+PGJyPjxicj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBz
YW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyAiPk9BdXRoIGNsaWVudCBpcyBqdXN0
IGFub3RoZXIgZXhhbXBsZSBvZiBhbiBpc3N1ZXIuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+PGJyPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7ICI+U28sIHBl
cmhhcHMgdGhlIHNlbnRlbmNlIGNvdWxkIGJlOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyPjxicj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDM0LCAzNCwgMzQpOyAiPiJFeGFtcGxl
IG9mIGlzc3VlcnMgaW5jbHVkZSBhbiBPQXV0aCBjbGllbnQsIHJlc291cmNlIG93bmVyLCBhbiBp
bmRlcGVuZGVudCB0aGlyZCBwYXJ0eS4iPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+PGJyPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog
QXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzQsIDM0LCAzNCk7ICI+U28sIHRoZSBjbGF1
c2UgYmVjb21lczo8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PC9zcGFuPjxicj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv
bWFuJywgc2VyaWY7ICI+Jm5ic3A7SXNzdWVyICZuYnNwO1RoZSB1bmlxdWUgaWRlbnRpZmllciBm
b3IgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVz
IE5ldyBSb21hbicsIHNlcmlmOyAiPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwO2Fzc2VydGlvbi4g
Jm5ic3A7R2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSBrZXk8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj48c3BhbiBj
bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxicj4mbmJzcDsg
Jm5ic3A7ICZuYnNwO21hdGVyaWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gJm5i
c3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7
ICI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgRXhhbXBsZSBvZiBpc3N1ZXJzIGluY2x1ZGUgYW4gT0F1
dGggY2xpZW50LCByZXNvdXJjZSBvd25lciwgYW4gaW5kZXBlbmRlbnQgdGhpcmQgcGFydHkuPHNw
YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+
PGJyPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+TmF0PC9z
cGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+
PGJyPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBy
Z2IoMzQsIDM0LCAzNCk7ICI+TmF0PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+PGJyPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJp
YWwsIHNhbnMtc2VyaWY7ICI+T24gVHVlLCBEZWMgNCwgMjAxMiBhdCAxMTo0MCBBTSwgJmx0Ozwv
c3Bhbj48YSBocmVmPSJtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbiIgdGFyZ2V0PSJfYmxh
bmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj56aG91LnN1amluZ0B6
dGUuY29tLmNuPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z
LXNlcmlmOyAiPiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg
c2Fucy1zZXJpZjsgIj48YnI+PGJyPjwvc3Bhbj48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTog
U2ltU3VuLCBzZXJpZjsgIj5DaHVjayBNb3J0aW1vcmUgJmx0OzwvdHQ+PGEgaHJlZj0ibWFpbHRv
OmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6
IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjx0dCBzdHlsZT0iZm9udC1mYW1p
bHk6IFNpbVN1biwgc2VyaWY7ICI+Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbTwvdHQ+PC9hPjx0
dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OzxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiI+5YaZ
5LqOPC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj4yMDEyLTEyLTA0IDEwOjI2OjUwOjwvdHQ+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj48YnI+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNp
bVN1biwgc2VyaWY7ICI+Jmd0OyBQbGVhc2UgZmVlbCBmcmVlIHRvIHN1Z2dlc3QgYmV0dGVyIGxh
bmd1YWdlLjwvdHQ+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxicj48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJy
Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyBJc3N1ZXIgc2lt
cGx5IGFsbG93cyB0aGUgdG9rZW4gc2VydmljZSB0byBrbm93IHdobyBjcmVhdGVkIHRoZTxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQg
c3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgYXNzZXJ0aW9uLCBzbyBp
dCBjYW4gbG9vayB0aGVtIHVwIGFuZCBzZWUgaWYgdGhleSdyZSB0cnVzdGVkLjxzcGFuIGNsYXNz
PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iZm9u
dC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291
cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNl
cmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8
L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv
dHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyBFZmZl
Y3RpdmVseSB0aGUgc2FtZSBhcyBhbiBJc3N1ZXIgaW4gU0FNTC48L3R0PjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj48L3NwYW4+PGJyPjx0dCBzdHlsZT0iZm9udC1m
YW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+YSBjb25mbGljdCA6ICJUaGUgdG9rZW4gc2VydmljZSBp
cyB0aGUgYXNzZXJ0aW9uIGlzc3VlciIgaW4gYXNzZXJ0aW9uIGRvY3VtZW50LjwvdHQ+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj48c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj48dHQgc3R5bGU9ImZv
bnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPndoaWxlIHlvdSBzYWlkICJ0b2tlbiBzZXJ2aWNl
IGtub3cgd2hvIGNyZWF0ZWQgdGhlIGFzc2VydGlvbiI8L3R0PjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjxicj48L3NwYW4+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6
IFNpbVN1biwgc2VyaWY7ICI+SSB3b25kZXIgaWYgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIGFjY2Vw
dGFibGU6PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAi
PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+
PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+PHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgIj48YnI+Jm5ic3A7SXNzdWVyICZuYnNw
O1RoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGU8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj48c3BhbiBj
bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyAiPjxicj4mbmJzcDsg
Jm5ic3A7ICZuYnNwO2Fzc2VydGlvbi4gJm5ic3A7R2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0
eSB0aGF0IGhvbGRzIHRoZSBrZXk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh
bCwgc2Fucy1zZXJpZjsgIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h
bicsIHNlcmlmOyAiPjxicj4mbmJzcDsgJm5ic3A7ICZuYnNwO21hdGVyaWFsIHVzZWQgdG8gZ2Vu
ZXJhdGUgdGhlIGFzc2VydGlvbi4gJm5ic3A7VGhlIGlzc3VlciBtYXkgYmUgZWl0aGVyPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+PHNwYW4gY2xh
c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7ICI+Jm5ic3A7ICZu
YnNwOyAmbmJzcDsgYW4gT0F1dGggY2xpZW50ICh3aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYtaXNz
dWVkKSBvcjxzcGFuIHN0eWxlPSJjb2xvcjogcmVkOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5hbnkgb3RoZXIgZW50aXR5LCBlLmcuLCAmbmJzcDs8
L3NwYW4+YSB0aGlyZCBwYXJ0eTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z
ZXJpZjsgIj48YnI+dG9rZW4gc2VydmljZTxzcGFuIHN0eWxlPSJjb2xvcjogcmVkOyAiPiwgcmVz
b3VyY2Ugb3duZXI8L3NwYW4+LjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48YnI+PGJyPjwvc3Bhbj48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2lt
U3VuLCBzZXJpZjsgIj42LjMuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFuPkNs
aWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGEgVXNlcjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PGJyPjwvc3Bhbj48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTog
U2ltU3VuLCBzZXJpZjsgIj5UaGUgSXNzdWVyIG9mIHRoZSBhc3NlcnRpb24gTVVTVCBpZGVudGlm
eSB0aGUgZW50aXR5IHRoYXQgaXNzdWVkPC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy
aWFsLCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2Vy
aWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwv
c3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90
dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZh
bWlseTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVy
IE5ldyc7ICI+Jm5ic3A7PC9zcGFuPnRoZSBhc3NlcnRpb24gYXMgcmVjb2duaXplZCBieSB0aGUg
QXV0aG9yaXphdGlvbiBTZXJ2ZXIuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFu
PklmIHRoZTwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsg
Ij48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFu
Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9
IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250
LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3Vy
aWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2Vy
aWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwv
c3Bhbj5hc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRoZSBJc3N1ZXIgU0hPVUxEIGJlIHRoZSAi
Y2xpZW50X2lkIi48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy
aWY7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv
c3Bhbj48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNs
YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0i
Zm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAn
Q291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4s
IHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJz
cDs8L3NwYW4+SWYgdGhlIGFzc2VydGlvbiB3YXMgaXNzdWVkIGJ5IGEgU2VjdXJpdHkgVG9rZW4g
U2VydmljZSAoU1RTKSwgdGhlPC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBz
YW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj48L3NwYW4+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQg
c3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTog
U2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7
ICI+Jm5ic3A7PC9zcGFuPklzc3VlciBTSE9VTEQgaWRlbnRpZnkgdGhlIFNUUyBhcyByZWNvZ25p
emVkIGJ5IHRoZSBBdXRob3JpemF0aW9uPC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy
aWFsLCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2Vy
aWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwv
c3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90
dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZh
bWlseTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVy
IE5ldyc7ICI+Jm5ic3A7PC9zcGFuPlNlcnZlci48c3BhbiBzdHlsZT0iY29sb3I6IHJlZDsgIj5J
ZiB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCB0aGU8L3Nw
YW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPjxz
cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw
YW4gc3R5bGU9ImNvbG9yOiByZWQ7ICI+PGJyPjwvc3Bhbj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5
OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3
JzsgY29sb3I6IHJlZDsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZWQ7ICI+
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48
L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBjb2xvcjogcmVkOyAiPiZuYnNwOzwvc3Bhbj48
c3BhbiBzdHlsZT0iY29sb3I6IHJlZDsgIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2lt
U3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7IGNv
bG9yOiByZWQ7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmVkOyAiPklzc3Vl
ciBTSE9VTEQgaWRlbnRpZnkgdGhlIHJlc291cmNlIG93bmVyIGFzIHJlY29nbml6ZWQgYnkgdGhl
IEF1dGhvcml6YXRpb248L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs
LCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZWQ7ICI+PGJyPjwvc3Bhbj48dHQg
c3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTogJ0NvdXJpZXIgTmV3JzsgY29sb3I6IHJlZDsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5
bGU9ImNvbG9yOiByZWQ7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2Vy
aWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyBjb2xvcjogcmVk
OyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJlZDsgIj48c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvdHQ+PHR0IHN0eWxl
PSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
ICdDb3VyaWVyIE5ldyc7IGNvbG9yOiByZWQ7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj
b2xvcjogcmVkOyAiPlNlcnZlci48L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
IEFyaWFsLCBzYW5zLXNlcmlmOyAiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyPjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1T
dW4sIHNlcmlmOyAiPiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
Ij4mZ3Q7IC1jbW9ydDwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z
ZXJpZjsgIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PC9zcGFuPjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDs8
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+
PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7IE9uIERlYyAzLCAy
MDEyLCBhdCA2OjIzIFBNLCAmbHQ7PC90dD48YSBocmVmPSJtYWlsdG86emhvdS5zdWppbmdAenRl
LmNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0
aW9uOiB1bmRlcmxpbmU7ICI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
Ij56aG91LnN1amluZ0B6dGUuY29tLmNuPC90dD48L2E+PHR0IHN0eWxlPSJmb250LWZhbWlseTog
U2ltU3VuLCBzZXJpZjsgIj4mZ3Q7IHdyb3RlOjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4s
IHNlcmlmOyAiPiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8
L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4m
Z3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+
PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyBPYnZpb3Vz
bHksIGl0IGlzIG5vdCBzbyBjbGVhciBmcm9tIHRoZSBsYW5ndWFnZSB0aGVyZS48c3BhbiBjbGFz
cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxl
PSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1p
bHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4s
IHNlcmlmOyAiPiZndDsgQ2h1Y2sgTW9ydGltb3JlICZsdDs8L3R0PjxhIGhyZWY9Im1haWx0bzpj
bW9ydGltb3JlQHNhbGVzZm9yY2UuY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBi
bHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5
OiBTaW1TdW4sIHNlcmlmOyAiPmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208L3R0PjwvYT48dHQg
c3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDs8c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iPuWGmeS6
jjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
MjAxMi0xMi0wNCAxMDoxNzoxMjo8L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1T
dW4sIHNlcmlmOyAiPiZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
Ij4mZ3Q7ICZndDsgVGhlcmUncyBubyByZWFzb24gd2h5IGl0IGNhbid0IGJlIHJlc291cmNlIG93
bmVyIHRvZGF5LjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFz
cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxl
PSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250
LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgT24gRGVjIDMsIDIwMTIsIGF0IDY6
MDYgUE0sICZsdDs8L3R0PjxhIGhyZWY9Im1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIiB0
YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy
bGluZTsgIj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPnpob3Uuc3Vq
aW5nQHp0ZS5jb20uY248L3R0PjwvYT48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNl
cmlmOyAiPiZndDsgJmx0OzwvdHQ+PGEgaHJlZj0ibWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20u
Y24iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjog
dW5kZXJsaW5lOyAiPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+emhv
dS5zdWppbmdAenRlLmNvbS5jbjwvdHQ+PC9hPjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBT
aW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IHdyb3RlOjxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFt
aWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBT
aW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4s
IHNlcmlmOyAiPiZndDsgJmd0OyArMS48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl
Ij4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBz
ZXJpZjsgIj4mZ3Q7ICZndDsgQW5kIHdoeSBpdCB3YXMgbm90IGxvb2tlZCBhdCB0aGF0IHRpbWU/
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJy
Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7PHNwYW4g
Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBz
dHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7PHNwYW4gY2xhc3M9
IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGEgaHJlZj0ibWFpbHRv
Om9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJs
dWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6
IFNpbVN1biwgc2VyaWY7ICI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvdHQ+PC9hPjx0dCBzdHls
ZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7lhpnkuo48L3NwYW4+
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjIwMTItMTIt
MDQgMDE6MzA6NTU6PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJp
ZjsgIj4mZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8
L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4m
Z3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgSSB0aGluayBpdCBpcyBhIGdvb2QgdGltZSB0byBzdGFy
dCBsb29raW5nIGF0IHRoZSByZXNvdXJzZTwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6
IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgb3duZXIgaXNzdWluZyBhc3NlcnRpb25z
QCAoSW50ZXJlc3RpbmdseSBlbm91Z2gsIEh1aS1MYW4gaGFkIGJyb3VnaHQ8L3R0Pjxicj48dHQg
c3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IHRoaXMg
dXAgYSBjb3VwbGUgb2YgeWVhcnMgYWdvLik8L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5
OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6
IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgSWdvcjwvdHQ+PGJyPjx0dCBzdHlsZT0i
Zm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJm
b250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OyBPbiAxMi8zLzIwMTIg
Mzo1OCBBTSwgTmF0IFNha2ltdXJhIHdyb3RlOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1T
dW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IEkgc3VwcG9zZSwgeWVzLiBJIHdhcyByZWFkaW5n
IGl0IGxpa2UgdGhhdCBhbGwgdGhlIHRpbWUuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1
biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgV2hldGhlciBpdCBpcyBvciBub3QsIGlmIGl0IGlz
IHN0aWxsIG9rLCBpdCBtaWdodCBiZSBiZXR0ZXIgdG88c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTog
U2ltU3VuLCBzZXJpZjsgIj4mZ3Q7IGNsYXJpZnkgaXQuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6
IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgV29yZCBsaWtlICJ0aGlyZCBwYXJ0eSIg
dGVuZHMgdG8gYmUgYSBiaXQgb2YgcHJvYmxlbSB3aXRob3V0PHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1p
bHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7IGNsZWFybHlkZWZpbmluZy48c3BhbiBjbGFz
cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxl
PSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OyBJIGhhZCBzaW1p
bGFyIGV4cGVyaWVuY2UgaW4gb3RoZXIgZm9yYS48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2lt
U3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1T
dW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IE5hdDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBT
aW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNp
bVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgU2VudCBmcm9tIGlQYWQ8c3BhbiBjbGFzcz0i
QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJm
b250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OzxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZv
bnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IDIwMTIvMTIvMDMgMDo1
MjxzcGFuIGxhbmc9IlpILUNOIj7jgIE8L3NwYW4+IjwvdHQ+PGEgaHJlZj0ibWFpbHRvOnpob3Uu
c3VqaW5nQHp0ZS5jb20uY24iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRl
eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1
biwgc2VyaWY7ICI+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvdHQ+PC9hPjx0dCBzdHlsZT0iZm9u
dC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+IiAmbHQ7PC90dD48YSBocmVmPSJtYWlsdG86emhv
dS5zdWppbmdAenRlLmNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsg
dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2lt
U3VuLCBzZXJpZjsgIj56aG91LnN1amluZ0B6dGUuY29tLmNuPC90dD48L2E+PHR0IHN0eWxlPSJm
b250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7jga48L3NwYW4+PC90
dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsg
Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3Bh
biBsYW5nPSJaSC1DTiI+44Oh44OD44K744O844K4PC9zcGFuPjo8L3R0Pjxicj48dHQgc3R5bGU9
ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQt
ZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1m
YW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgY291bGQgYmUgUmVzb3VyY2Ug
b3duZXI/PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv
dHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7
ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90
dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDs8
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+
PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0Ozxz
cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48
dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7ICJU
c2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKSIgJmx0OzwvdHQ+PGEgaHJlZj0ibWFp
bHRvOmhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29s
b3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjx0dCBzdHlsZT0iZm9udC1m
YW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbTwvdHQ+PC9h
Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OzxzcGFuIGNsYXNz
PSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9
ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9
IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIj7l
j5Hku7bkuro8L3NwYW4+OjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48L3R0
PjxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIg
c3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj48dHQgc3R5
bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8
L3R0PjwvYT48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIGNs
YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5
bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IDIwMTItMTIt
MDMgMTY6NDk8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZn
dDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0
OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxz
cGFuIGxhbmc9IlpILUNOIj7mlLbku7bkuro8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6
IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTog
U2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OyAiZXh0IE5hdCBTYWtpbXVyYSIgJmx0Ozwv
dHQ+PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0
eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+PHR0IHN0eWxl
PSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj5zYWtpbXVyYUBnbWFpbC5jb208L3R0Pjwv
YT48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDssICJCcmlhbiBD
YW1wYmVsbCIgJmx0OzwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2Vy
aWY7ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PC90dD48YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j
b20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjog
dW5kZXJsaW5lOyAiPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+YmNh
bXBiZWxsQHBpbmdpZGVudGl0eS5jb208L3R0PjwvYT48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBT
aW1TdW4sIHNlcmlmOyAiPiZndDssICJvYXV0aCIgJmx0OzwvdHQ+PGEgaHJlZj0ibWFpbHRvOm9h
dXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRl
Y29yYXRpb246IHVuZGVybGluZTsgIj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNl
cmlmOyAiPm9hdXRoQGlldGYub3JnPC90dD48L2E+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2lt
U3VuLCBzZXJpZjsgIj4mZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7
ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
Ij4mZ3Q7ICZndDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiI+5oqE6YCBPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQt
ZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1m
YW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iPuS4u+mimDxz
cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC90
dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsg
Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0
Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAm
Z3Q7IFJlOiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIg
aGF2ZSB0byBiZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFz
cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5bGU9ImZv
bnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ0Nv
dXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1
biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBw
YXJ0eSB0b2tlbiBzZXJ2aWNlPzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlm
OyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7
ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz
cDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
Ij4mZ3Q7ICZndDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAi
PiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+
Jmd0OyAmZ3Q7ICZndDsgSGkgTmF0LDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNl
cmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFu
PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxi
cj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7
IFRoZSBjdXJyZW50IHRleHQgZXNzZW50aWFsbHkgc2F5cyB0aGF0IHRoZSBhc3NlcnRpb24gY2Fu
IGVpdGhlciBiZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsg
Jmd0OyAmZ3Q7IGNyZWF0ZWQgYnkgdGhlIGNsaWVudCAoaW4gd2hpY2ggY2FzZSBpdCBpcyBzZWxm
LXNpZ25lZCkgb3IgaXQgY2FuIGJlPC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2lt
U3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OyBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5
ICh3aGljaCBpcyB0aGVuIGNhbGxlZCB0aGUgdGhpcmQgcGFydHk8c3BhbiBjbGFzcz0iQXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZh
bWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OyB0b2tlbiBzZXJ2aWNlKS4gU28s
IHRoaXMgdGhpcmQgcGFydHkgY291bGQgYmUgdGhlIGF1dGhvcml6YXRpb24gc2VydmVyLjxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQg
c3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4g
Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxl
PSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBT
aW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IENpYW88L3R0Pjxicj48dHQgc3R5bGU9ImZv
bnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IEhhbm5lczxzcGFuIGNs
YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5
bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xh
c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJm
b250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdD
b3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1T
dW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBz
ZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7
PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0
OyAmZ3Q7IEZyb206PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjwvdHQ+PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAi
Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZzwvdHQ+PC9hPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlttYWlsdG86
PC90dD48YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh
bmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+PHR0
IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj5vYXV0aC1ib3VuY2VzQGlldGYu
b3JnPC90dD48L2E+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj5dIE9u
IEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsg
Jmd0OyAmZ3Q7IGV4dCBOYXQgU2FraW11cmE8L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5
OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIg
MDMsIDIwMTIgMTA6MzUgQU08L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4s
IHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IFRvOiBCcmlhbiBDYW1wYmVsbDsgb2F1dGg8L3R0Pjxi
cj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7
IFN1YmplY3Q6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3Vl
ciBoYXZlIHRvIGJlPC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJp
ZjsgIj4mZ3Q7ICZndDsgJmd0OyBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRv
a2VuIHNlcnZpY2U/PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0
OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+PC90dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xh
c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHls
ZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgSGkgQnJpYW4s
PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJy
Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDs8
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQg
c3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1p
bHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBT
aW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsg
Ij4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+
Jmd0OyAmZ3Q7ICZndDsgVGhlIGFzc2VydGlvbiBmcmFtZXdvcmsgZGVmaW5lcyB0aGUgSXNzdWVy
IGFzOjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0
Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAm
Z3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+
PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQt
ZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWls
eTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5l
dyc7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj5J
c3N1ZXI8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90
dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+VGhlIHVuaXF1ZSBpZGVu
dGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVkIHRoZTxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFt
aWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTog
U2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7
ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3Bh
biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5
bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFzc2VydGlvbi48c3BhbiBjbGFzcz0iQXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBT
aW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsg
Ij4mbmJzcDs8L3NwYW4+R2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRo
ZSBrZXk8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90
dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsg
Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0
Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5bGU9ImZvbnQtZmFt
aWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIg
TmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFu
PjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5tYXRlcmlh
bCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2lt
U3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+
Jm5ic3A7PC9zcGFuPlRoZSBpc3N1ZXIgbWF5IGJlIGVpdGhlcjxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFt
aWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTog
U2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7
ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3Bh
biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5
bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTogJ0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25z
IGFyZSBzZWxmLWlzc3VlZCkgb3IgYSB0aGlyZCBwYXJ0eTxzcGFuIGNsYXNzPSJBcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5
OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2lt
U3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+
Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBj
bGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5bGU9
ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog
J0NvdXJpZXIgTmV3JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPnRva2VuIHNlcnZpY2UuPHNwYW4gY2xhc3M9IkFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1p
bHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29u
dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBT
aW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3Jzsg
Ij4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+
Jmd0OyAmZ3Q7ICZndDsgSSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8gYmUgZWl0aGVyIHRo
ZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4s
IHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IHRva2VuIHNlcnZpY2UuPHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1m
YW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgQ29uY2VwdHVhbGx5LCBpdCBj
b3VsZCBiZSBhbnkgdG9rZW4gc2VydmljZSAoZnVuY3Rpb25hbGl0eSk8c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250
LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgcmVzaWRpbmdpbiBhbnkgb2Y8c3Bh
biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0
IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OzxzcGFu
IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjx0dCBzdHls
ZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy
dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTog
U2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OyB0aGUgc3Rha2Vob2xkZXJzIChSZXNvdXJj
ZSBPd25lciwgT0F1dGggQ2xpZW50LCBBdXRob3JpemF0aW9uIFNlcnZlciwgb3I8c3BhbiBjbGFz
cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxl
PSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OyBhIHRoaXJkIHBh
cnR5KS48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90
dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsg
Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0
Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250
LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjx0dCBzdHlsZT0iZm9udC1mYW1p
bHk6IFNpbVN1biwgc2VyaWY7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAnQ291cmllciBO
ZXcnOyAiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJp
ZjsgIj4mZ3Q7ICZndDsgJmd0OyBJIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IGNvdWxkIGNsYXJp
Znkgd2h5IGlzIHRoZSBjYXNlLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlm
OyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFuPjxz
cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48
dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNw
YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0
eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5
OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IEJlc3QsPHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1m
YW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48dHQgc3R5bGU9ImZvbnQtZmFtaWx5
OiBTaW1TdW4sIHNlcmlmOyAiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3
JzsgIj4mbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7
ICI+Jmd0OyAmZ3Q7ICZndDsgLS08c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJp
ZjsgIj4mZ3Q7ICZndDsgJmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPHNwYW4gY2xhc3M9IkFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1m
YW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgQ2hhaXJtYW4sIE9wZW5JRCBG
b3VuZGF0aW9uPC90dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsg
Ij4mZ3Q7ICZndDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L3R0PjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJf
YmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+
PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj5odHRwOi8vbmF0LnNha2lt
dXJhLm9yZy88L3R0PjwvYT48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJp
ZjsgIj4mZ3Q7ICZndDsgJmd0OyBAX25hdF9lbjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1T
dW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBz
ZXJpZjsgIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+Jm5ic3A7
PC9zcGFuPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC90
dD48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsg
Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBT
aW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVu
ZGVybGluZTsgIj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPk9BdXRo
QGlldGYub3JnPC90dD48L2E+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2Vy
aWY7ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PC90dD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRl
Y29yYXRpb246IHVuZGVybGluZTsgIj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNl
cmlmOyAiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3R0Pjwv
YT48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDs8
c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC90dD48YnI+
PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0Ozxz
cGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxicj48
dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7PHNw
YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvdHQ+PGJyPjx0
dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAmZ3Q7ICZndDsgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3R0Pjxicj48dHQg
c3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IE9BdXRo
IG1haWxpbmcgbGlzdDwvdHQ+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2Vy
aWY7ICI+Jmd0OyAmZ3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PC90dD48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAi
Pjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+T0F1dGhAaWV0Zi5vcmc8
L3R0PjwvYT48YnI+PHR0IHN0eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7
ICZndDsgJmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48L3R0PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgiIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjog
dW5kZXJsaW5lOyAiPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvdHQ+PC9hPjxicj48dHQg
c3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyAmZ3Q7IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC90dD48YnI+PHR0IHN0
eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgJmd0OyBPQXV0aCBt
YWlsaW5nIGxpc3Q8L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlm
OyAiPiZndDsgJmd0OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i
c3A7PC9zcGFuPjwvdHQ+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9i
bGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj48
dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPk9BdXRoQGlldGYub3JnPC90
dD48L2E+PGJyPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+Jmd0OyAm
Z3Q7ICZndDs8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PC90dD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
IiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVu
ZGVybGluZTsgIj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3R0PjwvYT48YnI+PHR0IHN0
eWxlPSJmb250LWZhbWlseTogU2ltU3VuLCBzZXJpZjsgIj4mZ3Q7ICZndDsgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3R0Pjxicj48dHQgc3R5bGU9ImZv
bnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8
L3R0Pjxicj48dHQgc3R5bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0
OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0Pjxh
IGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xv
cjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+PHR0IHN0eWxlPSJmb250LWZh
bWlseTogU2ltU3VuLCBzZXJpZjsgIj5PQXV0aEBpZXRmLm9yZzwvdHQ+PC9hPjxicj48dHQgc3R5
bGU9ImZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlmOyAiPiZndDsgJmd0OzxzcGFuIGNsYXNzPSJB
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3R0PjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIiBzdHls
ZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjx0dCBzdHlsZT0i
Zm9udC1mYW1pbHk6IFNpbVN1biwgc2VyaWY7ICI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDwvdHQ+PC9hPjx0dCBzdHlsZT0iZm9udC1mYW1pbHk6IFNpbVN1biwg
c2VyaWY7ICI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu
PjwvdHQ+PGJyPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+
PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPk9B
dXRoIG1haWxpbmcgbGlzdDx1PjxzcGFuIHN0eWxlPSJjb2xvcjogYmx1ZTsgIj48YnI+PC9zcGFu
PjwvdT48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPk9BdXRoQGlldGYub3Jn
PC9zcGFuPjwvYT48dT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm
OyBjb2xvcjogYmx1ZTsgIj48YnI+PC9zcGFuPjwvdT48YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9y
OiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWws
IHNhbnMtc2VyaWY7ICI+PGJyPjwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBB
cmlhbCwgc2Fucy1zZXJpZjsgIj48YnI+PC9zcGFuPjxicj48YnI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj4tLTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+TmF0IFNha2ltdXJhICg9bmF0KTwvc3Bhbj48c3Bh
biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+Q2hhaXJtYW4sIE9wZW5JRCBG
b3VuZGF0aW9uPHU+PHNwYW4gc3R5bGU9ImNvbG9yOiBibHVlOyAiPjxicj48L3NwYW4+PC91Pjwv
c3Bhbj48YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIiBz
dHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7ICI+aHR0cDovL25hdC5zYWtpbXVy
YS5vcmcvPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNl
cmlmOyAiPjxicj5AX25hdF9lbjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNw
YWNlIj4mbmJzcDs8L3NwYW4+PGJyPjxicj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs
LCBzYW5zLXNlcmlmOyAiPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8dT48c3BhbiBzdHlsZT0iY29sb3I6IGJs
dWU7ICI+PGJyPjwvc3Bhbj48L3U+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9y
ZyIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1
bmRlcmxpbmU7ICI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsg
Ij5PQXV0aEBpZXRmLm9yZzwvc3Bhbj48L2E+PHU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBB
cmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsdWU7ICI+PGJyPjwvc3Bhbj48L3U+PGEgaHJlZj0i
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxh
bmsiIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7ICI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgIj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyAiPjxicj48YnI+PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbi1yaWdodDogMGluOyBtYXJn
aW4tbGVmdDogMGluOyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiBTaW1TdW4sIHNlcmlm
OyBtYXJnaW4tdG9wOiAwaW47IG1hcmdpbi1ib3R0b206IDAuMDAwMXB0OyAiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9kaXY+PC9kaXY+PC9kaXY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+T0F1dGggbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy
bGluZTsgIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29y
YXRpb246IHVuZGVybGluZTsgIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoPC9hPjxicj48L2Rpdj48L3NwYW4+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48
L2Rpdj48L2JvZHk+PC9odG1sPg==

--_000_7A54FDF5D9104E60BB5F5FB98A4B88E5salesforcecom_--

From zhou.sujing@zte.com.cn  Wed Dec  5 16:46:51 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD5921F8BBC; Wed,  5 Dec 2012 16:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.798
X-Spam-Level: 
X-Spam-Status: No, score=-98.798 tagged_above=-999 required=5 tests=[AWL=1.794, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_26=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpf49m+VHYMA; Wed,  5 Dec 2012 16:46:49 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id AA5B521F8BB6; Wed,  5 Dec 2012 16:46:48 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id DC199126A1D8; Thu,  6 Dec 2012 08:48:30 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 2CE71725579; Thu,  6 Dec 2012 08:35:38 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB60kZxB058470; Thu, 6 Dec 2012 08:46:35 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <254DA4A9-6155-46D8-BCB6-A6A04868FC0E@xmlgrrl.com>
To: Eve Maler 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Thu, 6 Dec 2012 08:46:24 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-06 08:46:37, Serialize complete at 2012-12-06 08:46:37
Content-Type: multipart/alternative; boundary="=_alternative 0004608648257ACC_="
X-MAIL: mse01.zte.com.cn qB60kZxB058470
Cc: "oauth@ietf.org" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Dec 2012 00:46:51 -0000

This is a multipart message in MIME format.
--=_alternative 0004608648257ACC_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

QXMgSSB1bmRlcnN0YW5kLCBSTz1pc3N1ZXIgIGRvZXMgbm90IG1lYW4gUk89QVMuDQpSTyBhcyBh
biBpc3N1ZXIgZ2VuZXJhdGVzIGFzc2VydGlvbiAoaWYgdGhlIGFzc2VydGlvbiBpcyBzaW1pbGFy
IHRvIA0KZGVsZWdhdGlvbiBzdGF0ZW1lbnQgaW4gbXkgdXNlIGNhc2VzKSwNCkFTIGFzIGFuIGFz
c2VydGlvbiB2ZXJpZmllciByZWNlaXZlcyB0aGUgYXNzZXJ0aW9uIGFuZCBjaGVjayBpdHMgdmFs
aWRpdHkuDQoNCg0KDQpvYXV0aC1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDEyLTEyLTA2IDAx
OjM1OjEwOg0KDQo+IEp1c3QgY2hlY2tpbmcgdGhhdCBJIHVuZGVyc3RhbmQ6IElmIHRoZSBSTyA9
PSB0aGUgaXNzdWVyLCB0aGVuIHRoZSANCj4gUk8gPT0gdGhlIEFTLCByaWdodD8gSnVzdCBhcyBp
biBOYXQncyBleGFtcGxlLCB0aGUgdXNlciAob3IgYXQgbGVhc3QNCj4gdGhlIGRldmljZSBwcmVz
ZW50aW5nIGEgdXNlciBhZ2VudCB0byB0aGVtKSA9PSB0aGUgSWRQPyBDb2xvY2F0aW5nIA0KPiB0
aGUgUk8gYW5kIEFTIGZ1bmN0aW9ucyBzaG91bGRuJ3QgYmUgcHJlY2x1ZGVkLCBidXQgSSB3b3Vs
ZCBiZSANCj4gYXdmdWxseSBjb25mdXNlZCBpZiB0aGVyZSB3ZXJlIGFuIFJPL2lzc3VlciBpbiB0
aGUgcGljdHVyZSBhbmQgDQo+ICphbHNvKiBhbiBBUyB0aGF0ICpkb2Vzbid0KiBpc3N1ZSBhc3Nl
cnRpb25zLg0KPiANCj4gRXZlDQo+IA0KPiBPbiA1IERlYyAyMDEyLCBhdCA5OjEzIEFNLCBOYXQg
U2FraW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBJdCBpcyBub3QgT0F1
dGgsIGJ1dCBBdXN0cmlhbiBlSUQgc3lzdGVtIGlzIGFuIGV4YW1wbGUgb2YgUk8gYXMgYW4gDQo+
IGFzc2VydGlvbiBpc3N1ZXIgcGF0dGVybi4gVGhleSBoYXZlIHRoZWlyIG93biBTQU1MIElkUCBv
biB0aGVpciBQQyANCj4gKGF0IGxlYXN0IGEgZmV3IHllYXJzIGFnbykgYW5kIGNvbWJpbmVkIHdp
dGggdGhlIHF1YWxpZmllZCBjZXJ0cyBpbiANCj4gdGhlIHVzZXIncyBzbWFydCBjYXJkIGFuZCBh
bm90aGVyIGZpbGUsIGNyZWF0ZXMgYSBTQU1MIGFzc2VydGlvbiANCj4gd2l0aCBzZWN0b3JhbCBp
ZGVudGlmaWVyIGFuZCBzdXBwbHkgaXQgdG8gb3RoZXIgc3lzdGVtcy4gDQo+IA0KPiBOYXQNCg0K
PiBPbiBXZWQsIERlYyA1LCAyMDEyIGF0IDExOjA1IFBNLCBCcmlhbiBDYW1wYmVsbCANCjxiY2Ft
cGJlbGxAcGluZ2lkZW50aXR5LmNvbQ0KPiA+IHdyb3RlOg0KPiBJIHNheSB0aGF0IGl0J3Mgb25s
eSB0aGVvcmV0aWNhbCBiZWNhdXNlIEkgZG9uJ3QgYmVsaWV2ZSB0aGVyZSBhcmUgDQo+IGFueSBh
Y3R1YWwgZGVwbG95bWVudHMgc3VwcG9ydGluZywgb3IgcGxhbm5pbmcgb24gc3VwcG9ydGluZywg
Uk8gYXMgDQo+IGFuIGFzc2VydGlvbiBpc3N1ZXIuIA0KPiANCg0KPiBPbiBUdWUsIERlYyA0LCAy
MDEyIGF0IDU6MzkgUE0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPiB3cm90ZToNCj4gDQo+IFdo
eSBSTyBhcyBhbiBpc3N1ZXIgaXMgb25seSB0aGVvcmV0aWNhbCB0b2RheT8gDQo+IA0KDQo+IA0K
PiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+IA0KPiAyMDEyLTEy
LTA0IDIzOjQxIA0KPiANCj4g5pS25Lu25Lq6DQo+IA0KPiBOYXQgU2FraW11cmEgPHNha2ltdXJh
QGdtYWlsLmNvbT4gDQo+IA0KPiDmioTpgIENCj4gDQo+IHpob3Uuc3VqaW5nQHp0ZS5jb20uY24s
ICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPiANCj4gDQo+IOS4u+mimA0KPiANCj4g
UmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZl
IHRvIGJlIA0KPiBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZp
Y2U/DQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgaW50ZW50IHdhcyBkZWZpbml0ZWx5IG5vdCB0byBj
b25zdHJhaW4gd2hvL3doYXQgY291bGQgYmUgdGhlIA0KPiBpc3N1ZXIuICBCdXQgYWxzbyB0cnkg
dG8gcHJvdmlkZSANCj4gc29tZSBndWlkYW5jZSBhcm91bmQgdGhlIGNvbW1vbiBjYXNlcyB0aGF0
IGFyZSBhY3R1YWxseSBiZWluZyANCj4gZGVwbG95ZWQgbm93LCB3aGljaCBhcmUgdGhlIGNsaWVu
dCBzZWxmLWlzc3VlZCBhbmQgU1RTIHZhcmlhbnRzLiANCj4gUmVzb3VyY2Ugb3duZXIgYXMgYW4g
aXNzdWVyIGlzIGFuIGludGVyZXN0aW5nIGNhc2UgYnV0IHNlZW1zIG1vc3RseSANCj4gdGhlb3Jl
dGljYWwgYXQgdGhpcyBwb2ludC4NCj4gDQo+IEkgZmVlbCBsaWtlIG1lbnRpb25pbmcgdGhlIHJl
c291cmNlIG93bmVyIHRoZXJlIGluIMKnNS4xIHdvdWxkIGNhdXNlIA0KPiBtb3JlIGNvbmZ1c2lv
biB0aGFuIGFueXRoaW5nIGVsc2UuIEknZCBwcmVmZXIgdG8ganVzdCBzdHJpa2UgdGhlIA0KPiB3
aG9sZSBzZW50ZW5jZSBpbiBxdWVzdGlvbiBhbmQgbWF5YmUgYWRkIHNvbWUgYWRkaXRpb25hbCB0
ZXh0IHRvIMKnMyANCj4gdGhhdCBjbGFyaWZpZXMgdGhhdCB0aGUgaXNzdWVyIGNhbiByZWFsbHkg
YmUgYW55IGVudGl0eSwgaWYgZm9sa3MgDQo+IHRoaW5rIGEgY2hhbmdlIGlzIG5lZWRlZCBoZXJl
PyANCj4gDQo+IA0KPiANCj4gT24gTW9uLCBEZWMgMywgMjAxMiBhdCA5OjIwIFBNLCBOYXQgU2Fr
aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4gd3JvdGU6IA0KDQo+IEFjdHVhbGx5LCAiVGhlIGlz
c3VlciBtYXkgYmUgZWl0aGVyIA0KPiAgICAgICBhbiBPQXV0aCBjbGllbnQgKHdoZW4gYXNzZXJ0
aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9yIGFueSBvdGhlcg0KPiBlbnRpdHksIGUuZy4sICBhIHRo
aXJkIHBhcnR5IA0KPiB0b2tlbiBzZXJ2aWNlLCByZXNvdXJjZSBvd25lci4gIiAgaXMgbm90IHJl
YWxseSBjbGVhbi4gDQo+IA0KPiBPQXV0aCBjbGllbnQgaXMganVzdCBhbm90aGVyIGV4YW1wbGUg
b2YgYW4gaXNzdWVyLiANCj4gDQo+IFNvLCBwZXJoYXBzIHRoZSBzZW50ZW5jZSBjb3VsZCBiZTog
DQo+IA0KPiAiRXhhbXBsZSBvZiBpc3N1ZXJzIGluY2x1ZGUgYW4gT0F1dGggY2xpZW50LCByZXNv
dXJjZSBvd25lciwgYW4gDQo+IGluZGVwZW5kZW50IHRoaXJkIHBhcnR5LiIgDQo+IA0KPiBTbywg
dGhlIGNsYXVzZSBiZWNvbWVzOiANCj4gDQo+ICBJc3N1ZXIgIFRoZSB1bmlxdWUgaWRlbnRpZmll
ciBmb3IgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGUgDQo+ICAgICAgYXNzZXJ0aW9uLiAgR2Vu
ZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSBrZXkgDQo+ICAgICAgbWF0
ZXJpYWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLiANCj4gICAgICAgRXhhbXBsZSBv
ZiBpc3N1ZXJzIGluY2x1ZGUgYW4gT0F1dGggY2xpZW50LCByZXNvdXJjZSBvd25lciwgYW4NCj4g
aW5kZXBlbmRlbnQgdGhpcmQgcGFydHkuIA0KPiANCj4gTmF0IA0KPiANCj4gTmF0IA0KPiANCj4g
T24gVHVlLCBEZWMgNCwgMjAxMiBhdCAxMTo0MCBBTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+
IHdyb3RlOiANCj4gDQo+IA0KPiANCj4gQ2h1Y2sgTW9ydGltb3JlIDxjbW9ydGltb3JlQHNhbGVz
Zm9yY2UuY29tPiDlhpnkuo4gMjAxMi0xMi0wNCAxMDoyNjo1MDogDQo+IA0KPiANCj4gPiBQbGVh
c2UgZmVlbCBmcmVlIHRvIHN1Z2dlc3QgYmV0dGVyIGxhbmd1YWdlLiANCj4gDQo+ID4gDQo+ID4g
SXNzdWVyIHNpbXBseSBhbGxvd3MgdGhlIHRva2VuIHNlcnZpY2UgdG8ga25vdyB3aG8gY3JlYXRl
ZCB0aGUgDQo+ID4gYXNzZXJ0aW9uLCBzbyBpdCBjYW4gbG9vayB0aGVtIHVwIGFuZCBzZWUgaWYg
dGhleSdyZSB0cnVzdGVkLiANCj4gPiBFZmZlY3RpdmVseSB0aGUgc2FtZSBhcyBhbiBJc3N1ZXIg
aW4gU0FNTC4gDQo+IA0KPiBhIGNvbmZsaWN0IDogIlRoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBh
c3NlcnRpb24gaXNzdWVyIiBpbiANCj4gYXNzZXJ0aW9uIGRvY3VtZW50LiANCj4gd2hpbGUgeW91
IHNhaWQgInRva2VuIHNlcnZpY2Uga25vdyB3aG8gY3JlYXRlZCB0aGUgYXNzZXJ0aW9uIiANCj4g
DQo+IEkgd29uZGVyIGlmIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBhY2NlcHRhYmxlOiANCj4gDQo+
ICBJc3N1ZXIgIFRoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIGVudGl0eSB0aGF0IGlzc3Vl
ZCB0aGUgDQo+ICAgICAgYXNzZXJ0aW9uLiAgR2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0eSB0
aGF0IGhvbGRzIHRoZSBrZXkgDQo+ICAgICAgbWF0ZXJpYWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUg
YXNzZXJ0aW9uLiAgVGhlIGlzc3VlciBtYXkgYmUgZWl0aGVyIA0KPiAgICAgICBhbiBPQXV0aCBj
bGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9yIGFueSBvdGhlcg0KPiBl
bnRpdHksIGUuZy4sICBhIHRoaXJkIHBhcnR5IA0KPiB0b2tlbiBzZXJ2aWNlLCByZXNvdXJjZSBv
d25lci4gDQo+IA0KPiANCj4gNi4zLiAgQ2xpZW50IEFjdGluZyBvbiBCZWhhbGYgb2YgYSBVc2Vy
IA0KPiANCj4gVGhlIElzc3VlciBvZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVu
dGl0eSB0aGF0IGlzc3VlZCANCj4gICAgICB0aGUgYXNzZXJ0aW9uIGFzIHJlY29nbml6ZWQgYnkg
dGhlIEF1dGhvcml6YXRpb24gU2VydmVyLiAgSWYgdGhlIA0KPiAgICAgIGFzc2VydGlvbiBpcyBz
ZWxmLWlzc3VlZCwgdGhlIElzc3VlciBTSE9VTEQgYmUgdGhlICJjbGllbnRfaWQiLiANCj4gICAg
ICBJZiB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkgYSBTZWN1cml0eSBUb2tlbiBTZXJ2aWNl
IChTVFMpLCB0aGUgDQo+ICAgICAgSXNzdWVyIFNIT1VMRCBpZGVudGlmeSB0aGUgU1RTIGFzIHJl
Y29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gDQo+ICAgICAgU2VydmVyLklmIHRoZSBhc3Nl
cnRpb24gd2FzIGlzc3VlZCBieSB0aGUgcmVzb3VyY2Ugb3duZXIsIHRoZSANCj4gICAgICBJc3N1
ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSByZXNvdXJjZSBvd25lciBhcyByZWNvZ25pemVkIGJ5IHRo
ZSANCj4gQXV0aG9yaXphdGlvbiANCj4gICAgICBTZXJ2ZXIuIA0KPiANCj4gPiANCj4gPiAtY21v
cnQgDQo+ID4gDQo+ID4gT24gRGVjIDMsIDIwMTIsIGF0IDY6MjMgUE0sIDx6aG91LnN1amluZ0B6
dGUuY29tLmNuPiB3cm90ZTogDQo+ID4gDQo+ID4gDQo+ID4gT2J2aW91c2x5LCBpdCBpcyBub3Qg
c28gY2xlYXIgZnJvbSB0aGUgbGFuZ3VhZ2UgdGhlcmUuIA0KPiA+IA0KPiA+IA0KPiA+IENodWNr
IE1vcnRpbW9yZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbT4g5YaZ5LqOIDIwMTItMTItMDQg
MTA6MTc6MTI6DQo+ID4gDQo+ID4gPiBUaGVyZSdzIG5vIHJlYXNvbiB3aHkgaXQgY2FuJ3QgYmUg
cmVzb3VyY2Ugb3duZXIgdG9kYXkuIA0KPiA+ID4gDQo+ID4gPiBPbiBEZWMgMywgMjAxMiwgYXQg
NjowNiBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IDx6aG91Lg0KPiBzdWppbmdAenRlLmNv
bS5jbg0KPiA+ID4gPiB3cm90ZTogDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gKzEuIA0KPiA+ID4g
QW5kIHdoeSBpdCB3YXMgbm90IGxvb2tlZCBhdCB0aGF0IHRpbWU/IA0KPiA+ID4gDQo+ID4gPiBv
YXV0aC1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDEyLTEyLTA0IDAxOjMwOjU1Og0KPiA+ID4g
DQo+ID4gPiA+IEFjdHVhbGx5LCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aW1lIHRvIHN0YXJ0IGxv
b2tpbmcgYXQgdGhlIA0KcmVzb3Vyc2UNCj4gPiA+ID4gb3duZXIgaXNzdWluZyBhc3NlcnRpb25z
QCAoSW50ZXJlc3RpbmdseSBlbm91Z2gsIEh1aS1MYW4gaGFkIA0KYnJvdWdodA0KPiA+ID4gPiB0
aGlzIHVwIGEgY291cGxlIG9mIHllYXJzIGFnby4pDQo+ID4gPiA+IA0KPiA+ID4gPiBJZ29yDQo+
ID4gPiA+IA0KPiA+ID4gPiBPbiAxMi8zLzIwMTIgMzo1OCBBTSwgTmF0IFNha2ltdXJhIHdyb3Rl
OiANCj4gPiA+ID4gSSBzdXBwb3NlLCB5ZXMuIEkgd2FzIHJlYWRpbmcgaXQgbGlrZSB0aGF0IGFs
bCB0aGUgdGltZS4gDQo+ID4gPiA+IFdoZXRoZXIgaXQgaXMgb3Igbm90LCBpZiBpdCBpcyBzdGls
bCBvaywgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIA0KPiA+IGNsYXJpZnkgaXQuIA0KPiA+ID4gPiBX
b3JkIGxpa2UgInRoaXJkIHBhcnR5IiB0ZW5kcyB0byBiZSBhIGJpdCBvZiBwcm9ibGVtIHdpdGhv
dXQgDQo+ID4gPiBjbGVhcmx5ZGVmaW5pbmcuIA0KPiA+ID4gPiBJIGhhZCBzaW1pbGFyIGV4cGVy
aWVuY2UgaW4gb3RoZXIgZm9yYS4gDQo+ID4gPiA+IA0KPiA+ID4gPiBOYXQgDQo+ID4gPiA+IA0K
PiA+ID4gPiBTZW50IGZyb20gaVBhZCANCj4gPiA+ID4gDQo+ID4gPiA+IDIwMTIvMTIvMDMgMDo1
MuOAgSJ6aG91LnN1amluZ0B6dGUuY29tLmNuIiA8emhvdS5zdWppbmdAenRlLmNvbS5jbj4gDQrj
ga4NCj4gPiA+ID4g44Oh44OD44K744O844K4Og0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBj
b3VsZCBiZSBSZXNvdXJjZSBvd25lcj8gDQo+ID4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+
ID4gPiAiVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykiIDxoYW5uZXMudHNjaG9m
ZW5pZ0Buc24uY29tPiANCj4gPiA+ID4g5Y+R5Lu25Lq6OiAgb2F1dGgtYm91bmNlc0BpZXRmLm9y
ZyANCj4gPiA+ID4gMjAxMi0xMi0wMyAxNjo0OSANCj4gPiA+ID4gDQo+ID4gPiA+IOaUtuS7tuS6
uiANCj4gPiA+ID4gDQo+ID4gPiA+ICJleHQgTmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwu
Y29tPiwgIkJyaWFuIENhbXBiZWxsIiA8DQo+ID4gPiA+IGJjYW1wYmVsbEBwaW5naWRlbnRpdHku
Y29tPiwgIm9hdXRoIiA8b2F1dGhAaWV0Zi5vcmc+IA0KPiA+ID4gPiANCj4gPiA+ID4g5oqE6YCB
IA0KPiA+ID4gPiANCj4gPiA+ID4g5Li76aKYIA0KPiA+ID4gPiANCj4gPiA+ID4gUmU6IFtPQVVU
SC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlIHRvIGJlICAN
Cj4gPiA+ID4gZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNl
PyANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IEhpIE5h
dCwgDQo+ID4gPiA+IA0KPiA+ID4gPiBUaGUgY3VycmVudCB0ZXh0IGVzc2VudGlhbGx5IHNheXMg
dGhhdCB0aGUgYXNzZXJ0aW9uIGNhbiBlaXRoZXIgYmUgDQoNCj4gPiA+ID4gY3JlYXRlZCBieSB0
aGUgY2xpZW50IChpbiB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2lnbmVkKSBvciBpdCBjYW4gDQpi
ZQ0KPiA+ID4gPiBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5ICh3aGljaCBpcyB0aGVuIGNh
bGxlZCB0aGUgdGhpcmQgcGFydHkgDQoNCj4gPiA+ID4gdG9rZW4gc2VydmljZSkuIFNvLCB0aGlz
IHRoaXJkIHBhcnR5IGNvdWxkIGJlIHRoZSBhdXRob3JpemF0aW9uIA0Kc2VydmVyLiANCj4gPiA+
ID4gDQo+ID4gPiA+IENpYW8NCj4gPiA+ID4gSGFubmVzIA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+
ID4gPiA+IEZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2Vz
QGlldGYub3JnXSANCj4gT24gQmVoYWxmIE9mIA0KPiA+ID4gPiBleHQgTmF0IFNha2ltdXJhDQo+
ID4gPiA+IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDMsIDIwMTIgMTA6MzUgQU0NCj4gPiA+ID4g
VG86IEJyaWFuIENhbXBiZWxsOyBvYXV0aA0KPiA+ID4gPiBTdWJqZWN0OiBbT0FVVEgtV0ddIEFz
c2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byANCmJlDQo+ID4gPiA+
IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT8gDQo+ID4g
PiA+IA0KPiA+ID4gPiBIaSBCcmlhbiwgDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gVGhl
IGFzc2VydGlvbiBmcmFtZXdvcmsgZGVmaW5lcyB0aGUgSXNzdWVyIGFzOiANCj4gPiA+ID4gDQo+
ID4gPiA+ICAgIElzc3VlciAgVGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRo
YXQgaXNzdWVkIHRoZSANCj4gPiA+ID4gICAgICAgYXNzZXJ0aW9uLiAgR2VuZXJhbGx5IHRoaXMg
aXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSBrZXkgDQo+ID4gPiA+ICAgICAgIG1hdGVyaWFs
IHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gIFRoZSBpc3N1ZXIgbWF5YmUgDQplaXRo
ZXIgDQo+ID4gPiA+ICAgICAgIGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25zIGFyZSBz
ZWxmLWlzc3VlZCkgb3IgYSANCj4gdGhpcmQgcGFydHkgDQo+ID4gPiA+ICAgICAgIHRva2VuIHNl
cnZpY2UuIA0KPiA+ID4gPiANCj4gPiA+ID4gSSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8g
YmUgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCANCnBhcnR5IA0KPiA+ID4gPiB0b2tlbiBz
ZXJ2aWNlLiANCj4gPiA+ID4gQ29uY2VwdHVhbGx5LCBpdCBjb3VsZCBiZSBhbnkgdG9rZW4gc2Vy
dmljZSAoZnVuY3Rpb25hbGl0eSkgDQo+ID4gPiByZXNpZGluZ2luIGFueSBvZiANCj4gPiA+ID4g
DQo+ID4gPiA+IHRoZSBzdGFrZWhvbGRlcnMgKFJlc291cmNlIE93bmVyLCBPQXV0aCBDbGllbnQs
IEF1dGhvcml6YXRpb24gDQo+IFNlcnZlciwgb3IgDQo+ID4gPiA+IGEgdGhpcmQgcGFydHkpLiAN
Cj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBJIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IGNv
dWxkIGNsYXJpZnkgd2h5IGlzIHRoZSBjYXNlLiANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4g
PiBCZXN0LCANCj4gPiA+ID4gDQo+ID4gPiA+IC0tIA0KPiA+ID4gPiBOYXQgU2FraW11cmEgKD1u
YXQpIA0KPiA+ID4gPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4gPiA+ID4gaHR0cDov
L25hdC5zYWtpbXVyYS5vcmcvDQo+ID4gPiA+IEBfbmF0X2VuIA0KPiA+ID4gPiAgX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gT0F1dGggbWFp
bGluZyBsaXN0DQo+ID4gPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gPiA+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4g
DQo+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+ID4gPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+
ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gPiA+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+
IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gPiBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aCANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRm
Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IA0K
PiANCj4gDQo+IA0KPiAtLSANCj4gTmF0IFNha2ltdXJhICg9bmF0KSANCj4gQ2hhaXJtYW4sIE9w
ZW5JRCBGb3VuZGF0aW9uDQo+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiBAX25hdF9lbiAN
Cj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiANCg0KPiANCj4gDQoNCj4gDQo+IC0t
IA0KPiBOYXQgU2FraW11cmEgKD1uYXQpDQo+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0K
PiBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCj4gQF9uYXRfZW4NCj4gDQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlz
dA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoDQo+IA0KPiANCj4gRXZlIE1hbGVyICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIGh0dHA6Ly93d3cueG1sZ3JybC5jb20vYmxvZw0KPiArMSA0MjUgMzQ1IDY3NTYgICAg
ICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy50d2l0dGVyLmNvbS94bWxncnJsDQoNCj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGgg
bWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K
--=_alternative 0004608648257ACC_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFzIEkgdW5kZXJzdGFuZCwgUk89
aXNzdWVyICZuYnNwO2RvZXMNCm5vdCBtZWFuIFJPPUFTLjwvZm9udD4NCjxicj48Zm9udCBzaXpl
PTIgZmFjZT0ic2Fucy1zZXJpZiI+Uk8gYXMgYW4gaXNzdWVyIGdlbmVyYXRlcyBhc3NlcnRpb24N
CihpZiB0aGUgYXNzZXJ0aW9uIGlzIHNpbWlsYXIgdG8gZGVsZWdhdGlvbiBzdGF0ZW1lbnQgaW4g
bXkgdXNlIGNhc2VzKSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi
PkFTIGFzIGFuIGFzc2VydGlvbiB2ZXJpZmllciByZWNlaXZlcw0KdGhlIGFzc2VydGlvbiBhbmQg
Y2hlY2sgaXRzIHZhbGlkaXR5LjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg5YaZ5LqOIDIwMTItMTItMDYgMDE6MzU6
MTA6PGJyPg0KPGJyPg0KJmd0OyBKdXN0IGNoZWNraW5nIHRoYXQgSSB1bmRlcnN0YW5kOiBJZiB0
aGUgUk8gPT0gdGhlIGlzc3VlciwgdGhlbiB0aGUNCjxicj4NCiZndDsgUk8gPT0gdGhlIEFTLCBy
aWdodD8gSnVzdCBhcyBpbiBOYXQncyBleGFtcGxlLCB0aGUgdXNlciAob3IgYXQgbGVhc3Q8YnI+
DQomZ3Q7IHRoZSBkZXZpY2UgcHJlc2VudGluZyBhIHVzZXIgYWdlbnQgdG8gdGhlbSkgPT0gdGhl
IElkUD8gQ29sb2NhdGluZw0KPGJyPg0KJmd0OyB0aGUgUk8gYW5kIEFTIGZ1bmN0aW9ucyBzaG91
bGRuJ3QgYmUgcHJlY2x1ZGVkLCBidXQgSSB3b3VsZCBiZSA8YnI+DQomZ3Q7IGF3ZnVsbHkgY29u
ZnVzZWQgaWYgdGhlcmUgd2VyZSBhbiBSTy9pc3N1ZXIgaW4gdGhlIHBpY3R1cmUgYW5kIDxicj4N
CiZndDsgKmFsc28qIGFuIEFTIHRoYXQgKmRvZXNuJ3QqIGlzc3VlIGFzc2VydGlvbnMuPC9mb250
PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgRXZlPC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgT24gNSBEZWMgMjAxMiwg
YXQgOToxMyBBTSwgTmF0IFNha2ltdXJhICZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7DQp3cm90
ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBJdCBp
cyBub3QgT0F1dGgsIGJ1dCBBdXN0cmlhbiBlSUQgc3lzdGVtIGlzIGFuIGV4YW1wbGUgb2YgUk8g
YXMgYW4NCjxicj4NCiZndDsgYXNzZXJ0aW9uIGlzc3VlciBwYXR0ZXJuLiBUaGV5IGhhdmUgdGhl
aXIgb3duIFNBTUwgSWRQIG9uIHRoZWlyIFBDDQo8YnI+DQomZ3Q7IChhdCBsZWFzdCBhIGZldyB5
ZWFycyBhZ28pIGFuZCBjb21iaW5lZCB3aXRoIHRoZSBxdWFsaWZpZWQgY2VydHMgaW4NCjxicj4N
CiZndDsgdGhlIHVzZXIncyBzbWFydCBjYXJkIGFuZCBhbm90aGVyIGZpbGUsIGNyZWF0ZXMgYSBT
QU1MIGFzc2VydGlvbiA8YnI+DQomZ3Q7IHdpdGggc2VjdG9yYWwgaWRlbnRpZmllciBhbmQgc3Vw
cGx5IGl0IHRvIG90aGVyIHN5c3RlbXMuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyA8YnI+DQomZ3Q7IE5hdDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz
aXplPTI+Jmd0OyBPbiBXZWQsIERlYyA1LCAyMDEyIGF0IDExOjA1IFBNLCBCcmlhbiBDYW1wYmVs
bA0KJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPGJyPg0KJmd0OyAmZ3Q7IHdyb3RlOjwv
Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJIHNheSB0aGF0IGl0J3Mgb25s
eSB0aGVvcmV0aWNhbCBiZWNhdXNlIEkgZG9uJ3QNCmJlbGlldmUgdGhlcmUgYXJlIDxicj4NCiZn
dDsgYW55IGFjdHVhbCBkZXBsb3ltZW50cyBzdXBwb3J0aW5nLCBvciBwbGFubmluZyBvbiBzdXBw
b3J0aW5nLCBSTyBhcw0KPGJyPg0KJmd0OyBhbiBhc3NlcnRpb24gaXNzdWVyLiA8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7IE9uIFR1ZSwgRGVjIDQsIDIwMTIgYXQgNTozOSBQTSwgJmx0O3po
b3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBXaHkgUk8gYXMgYW4gaXNzdWVyIGlzIG9ubHkgdGhl
b3JldGljYWwgdG9kYXk/IDxicj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm
b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBw
aW5naWRlbnRpdHkuY29tJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgMjAxMi0xMi0wNCAyMzo0MSA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgPGJyPg0KJmd0OyDmlLbku7bkuro8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y
PiZndDsgPGJyPg0KJmd0OyBOYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZndDsg
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg5oqE6YCB
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgemhvdS5z
dWppbmdAenRlLmNvbS5jbiwgJnF1b3Q7b2F1dGhAaWV0Zi5vcmcmcXVvdDsgJmx0O29hdXRoQGll
dGYub3JnJmd0Ow0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N
CiZndDsg5Li76aKYPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N
CiZndDsgUmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3Vl
ciBoYXZlIHRvIGJlIDxicj4NCiZndDsgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0
eSB0b2tlbiBzZXJ2aWNlPzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8
YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBpbnRlbnQgd2Fz
IGRlZmluaXRlbHkgbm90IHRvIGNvbnN0cmFpbiB3aG8vd2hhdCBjb3VsZCBiZSB0aGUgPGJyPg0K
Jmd0OyBpc3N1ZXIuICZuYnNwO0J1dCBhbHNvIHRyeSB0byBwcm92aWRlIDxicj4NCiZndDsgc29t
ZSBndWlkYW5jZSBhcm91bmQgdGhlIGNvbW1vbiBjYXNlcyB0aGF0IGFyZSBhY3R1YWxseSBiZWlu
ZyA8YnI+DQomZ3Q7IGRlcGxveWVkIG5vdywgd2hpY2ggYXJlIHRoZSBjbGllbnQgc2VsZi1pc3N1
ZWQgYW5kIFNUUyB2YXJpYW50cy4gPGJyPg0KJmd0OyBSZXNvdXJjZSBvd25lciBhcyBhbiBpc3N1
ZXIgaXMgYW4gaW50ZXJlc3RpbmcgY2FzZSBidXQgc2VlbXMgbW9zdGx5DQo8YnI+DQomZ3Q7IHRo
ZW9yZXRpY2FsIGF0IHRoaXMgcG9pbnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZmVlbCBsaWtl
IG1lbnRpb25pbmcgdGhlIHJlc291cmNlIG93bmVyIHRoZXJlIGluIMKnNS4xIHdvdWxkIGNhdXNl
DQo8YnI+DQomZ3Q7IG1vcmUgY29uZnVzaW9uIHRoYW4gYW55dGhpbmcgZWxzZS4gSSdkIHByZWZl
ciB0byBqdXN0IHN0cmlrZSB0aGUgPGJyPg0KJmd0OyB3aG9sZSBzZW50ZW5jZSBpbiBxdWVzdGlv
biBhbmQgbWF5YmUgYWRkIHNvbWUgYWRkaXRpb25hbCB0ZXh0IHRvIMKnMw0KPGJyPg0KJmd0OyB0
aGF0IGNsYXJpZmllcyB0aGF0IHRoZSBpc3N1ZXIgY2FuIHJlYWxseSBiZSBhbnkgZW50aXR5LCBp
ZiBmb2xrcw0KPGJyPg0KJmd0OyB0aGluayBhIGNoYW5nZSBpcyBuZWVkZWQgaGVyZT8gPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBNb24sIERlYyAzLCAyMDEy
IGF0IDk6MjAgUE0sIE5hdCBTYWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ow0Kd3Jv
dGU6IDxicj4NCiZndDsgQWN0dWFsbHksICZxdW90O1RoZSBpc3N1ZXIgbWF5IGJlIGVpdGhlciA8
YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3Nl
cnRpb25zIGFyZSBzZWxmLWlzc3VlZCkNCm9yIGFueSBvdGhlcjxicj4NCiZndDsgZW50aXR5LCBl
LmcuLCAmbmJzcDthIHRoaXJkIHBhcnR5IDxicj4NCiZndDsgdG9rZW4gc2VydmljZSwgcmVzb3Vy
Y2Ugb3duZXIuICZxdW90OyAmbmJzcDtpcyBub3QgcmVhbGx5IGNsZWFuLiA8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgT0F1dGggY2xpZW50IGlzIGp1c3QgYW5vdGhlciBleGFtcGxlIG9mIGFuIGlzc3Vl
ci4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvLCBwZXJoYXBzIHRoZSBzZW50ZW5jZSBjb3VsZCBi
ZTogPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZxdW90O0V4YW1wbGUgb2YgaXNzdWVycyBpbmNsdWRl
IGFuIE9BdXRoIGNsaWVudCwgcmVzb3VyY2Ugb3duZXIsDQphbiA8YnI+DQomZ3Q7IGluZGVwZW5k
ZW50IHRoaXJkIHBhcnR5LiZxdW90OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgU28sIHRoZSBjbGF1
c2UgYmVjb21lczogPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwO0lzc3VlciAmbmJzcDtUaGUg
dW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQNCnRoZSA8YnI+DQom
Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXNzZXJ0aW9uLiAmbmJzcDtHZW5lcmFsbHkgdGhpcyBp
cyB0aGUgZW50aXR5DQp0aGF0IGhvbGRzIHRoZSBrZXkgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwO21hdGVyaWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gJm5ic3A7DQo8
YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEV4YW1wbGUgb2YgaXNzdWVycyBpbmNsdWRl
IGFuIE9BdXRoIGNsaWVudCwgcmVzb3VyY2UNCm93bmVyLCBhbjxicj4NCiZndDsgaW5kZXBlbmRl
bnQgdGhpcmQgcGFydHkuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBOYXQgPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IE5hdCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gVHVlLCBEZWMgNCwgMjAxMiBhdCAx
MTo0MCBBTSwgJmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7IHdyb3RlOg0KPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBDaHVjayBNb3J0aW1vcmUgJmx0O2Nt
b3J0aW1vcmVAc2FsZXNmb3JjZS5jb20mZ3Q7IOWGmeS6jiAyMDEyLTEyLTA0DQoxMDoyNjo1MDog
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBQbGVhc2UgZmVlbCBmcmVlIHRv
IHN1Z2dlc3QgYmV0dGVyIGxhbmd1YWdlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgSXNzdWVyIHNpbXBseSBhbGxvd3MgdGhlIHRva2VuIHNlcnZpY2UgdG8ga25v
dyB3aG8gY3JlYXRlZCB0aGUNCjxicj4NCiZndDsgJmd0OyBhc3NlcnRpb24sIHNvIGl0IGNhbiBs
b29rIHRoZW0gdXAgYW5kIHNlZSBpZiB0aGV5J3JlIHRydXN0ZWQuDQombmJzcDsgJm5ic3A7IDxi
cj4NCiZndDsgJmd0OyBFZmZlY3RpdmVseSB0aGUgc2FtZSBhcyBhbiBJc3N1ZXIgaW4gU0FNTC4g
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGEgY29uZmxpY3QgOiAmcXVvdDtUaGUgdG9rZW4gc2Vydmlj
ZSBpcyB0aGUgYXNzZXJ0aW9uIGlzc3VlciZxdW90Ow0KaW4gPGJyPg0KJmd0OyBhc3NlcnRpb24g
ZG9jdW1lbnQuIDxicj4NCiZndDsgd2hpbGUgeW91IHNhaWQgJnF1b3Q7dG9rZW4gc2VydmljZSBr
bm93IHdobyBjcmVhdGVkIHRoZSBhc3NlcnRpb24mcXVvdDsNCjxicj4NCiZndDsgPGJyPg0KJmd0
OyBJIHdvbmRlciBpZiB0aGUgZm9sbG93aW5nIHRleHQgaXMgYWNjZXB0YWJsZTogPGJyPg0KJmd0
OyAmbmJzcDsgPGJyPg0KJmd0OyAmbmJzcDtJc3N1ZXIgJm5ic3A7VGhlIHVuaXF1ZSBpZGVudGlm
aWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVkDQp0aGUgPGJyPg0KJmd0OyAmbmJzcDsgJm5i
c3A7ICZuYnNwO2Fzc2VydGlvbi4gJm5ic3A7R2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0eQ0K
dGhhdCBob2xkcyB0aGUga2V5IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttYXRlcmlh
bCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uICZuYnNwO1RoZQ0KaXNzdWVyIG1heSBi
ZSBlaXRoZXIgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhbiBPQXV0aCBjbGllbnQg
KHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpDQpvciBhbnkgb3RoZXI8YnI+DQomZ3Q7
IGVudGl0eSwgZS5nLiwgJm5ic3A7YSB0aGlyZCBwYXJ0eSA8YnI+DQomZ3Q7IHRva2VuIHNlcnZp
Y2UsIHJlc291cmNlIG93bmVyLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA2LjMu
ICZuYnNwO0NsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGEgVXNlciA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgVGhlIElzc3VlciBvZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVudGl0
eSB0aGF0IGlzc3VlZCA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIGFzc2VydGlv
biBhcyByZWNvZ25pemVkIGJ5IHRoZSBBdXRob3JpemF0aW9uDQpTZXJ2ZXIuICZuYnNwO0lmIHRo
ZSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXNzZXJ0aW9uIGlzIHNlbGYtaXNzdWVk
LCB0aGUgSXNzdWVyIFNIT1VMRCBiZQ0KdGhlICZxdW90O2NsaWVudF9pZCZxdW90Oy4gPGJyPg0K
Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSBh
IFNlY3VyaXR5IFRva2VuDQpTZXJ2aWNlIChTVFMpLCB0aGUgPGJyPg0KJmd0OyAmbmJzcDsgJm5i
c3A7ICZuYnNwO0lzc3VlciBTSE9VTEQgaWRlbnRpZnkgdGhlIFNUUyBhcyByZWNvZ25pemVkIGJ5
DQp0aGUgQXV0aG9yaXphdGlvbiA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2VydmVy
LklmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSB0aGUgcmVzb3VyY2UNCm93bmVyLCB0aGUg
PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lzc3VlciBTSE9VTEQgaWRlbnRpZnkgdGhl
IHJlc291cmNlIG93bmVyIGFzIHJlY29nbml6ZWQNCmJ5IHRoZSA8YnI+DQomZ3Q7IEF1dGhvcml6
YXRpb24gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NlcnZlci4gPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC1jbW9ydCA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IE9uIERlYyAzLCAyMDEyLCBhdCA2OjIzIFBNLCAmbHQ7emhvdS5zdWppbmdA
enRlLmNvbS5jbiZndDsgd3JvdGU6DQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyBPYnZpb3VzbHksIGl0IGlzIG5vdCBzbyBjbGVhciBmcm9tIHRoZSBsYW5n
dWFnZSB0aGVyZS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgQ2h1Y2sgTW9ydGltb3JlICZsdDtjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tJmd0OyDlhpnk
uo4gMjAxMi0xMi0wNA0KMTA6MTc6MTI6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm
Z3Q7IFRoZXJlJ3Mgbm8gcmVhc29uIHdoeSBpdCBjYW4ndCBiZSByZXNvdXJjZSBvd25lciB0b2Rh
eS4NCiZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBPbiBE
ZWMgMywgMjAxMiwgYXQgNjowNiBQTSwgJmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7DQom
bHQ7emhvdS48YnI+DQomZ3Q7IHN1amluZ0B6dGUuY29tLmNuPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyB3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgKzEuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFuZCB3aHkgaXQgd2Fz
IG5vdCBsb29rZWQgYXQgdGhhdCB0aW1lPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgJmd0OyBvYXV0aC1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDEyLTEyLTA0IDAxOjMw
OjU1Ojxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQWN0dWFs
bHksIEkgdGhpbmsgaXQgaXMgYSBnb29kIHRpbWUgdG8gc3RhcnQgbG9va2luZw0KYXQgdGhlIHJl
c291cnNlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBvd25lciBpc3N1aW5nIGFzc2VydGlvbnNA
IChJbnRlcmVzdGluZ2x5IGVub3VnaCwgSHVpLUxhbg0KaGFkIGJyb3VnaHQ8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IHRoaXMgdXAgYSBjb3VwbGUgb2YgeWVhcnMgYWdvLik8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSWdvcjxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiAxMi8zLzIwMTIgMzo1OCBB
TSwgTmF0IFNha2ltdXJhIHdyb3RlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgc3VwcG9z
ZSwgeWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhhdCBhbGwgdGhlDQp0aW1lLiA8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7IFdoZXRoZXIgaXQgaXMgb3Igbm90LCBpZiBpdCBpcyBzdGlsbCBv
aywgaXQgbWlnaHQgYmUNCmJldHRlciB0byA8YnI+DQomZ3Q7ICZndDsgY2xhcmlmeSBpdC4gPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBXb3JkIGxpa2UgJnF1b3Q7dGhpcmQgcGFydHkmcXVvdDsg
dGVuZHMgdG8gYmUgYSBiaXQNCm9mIHByb2JsZW0gd2l0aG91dCA8YnI+DQomZ3Q7ICZndDsgJmd0
OyBjbGVhcmx5ZGVmaW5pbmcuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBoYWQgc2ltaWxh
ciBleHBlcmllbmNlIGluIG90aGVyIGZvcmEuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBOYXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQgZnJvbSBpUGFkIDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAyMDEyLzEyLzAzIDA6NTLjgIEmcXVvdDt6
aG91LnN1amluZ0B6dGUuY29tLmNuJnF1b3Q7DQombHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZn
dDsg44GuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyDjg6Hjg4Pjgrvjg7zjgrg6PGJyPg0KJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7IGNvdWxkIGJlIFJlc291cmNlIG93bmVyPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmcXVvdDtUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9v
KSZxdW90OyAmbHQ7aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbSZndDsNCjxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsg5Y+R5Lu25Lq6OiAmbmJzcDtvYXV0aC1ib3VuY2VzQGlldGYub3JnIDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgMjAxMi0xMi0wMyAxNjo0OSA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg5pS25Lu25Lq6IDxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmcXVvdDtleHQgTmF0IFNha2lt
dXJhJnF1b3Q7ICZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7LA0KJnF1b3Q7QnJpYW4gQ2FtcGJl
bGwmcXVvdDsgJmx0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYmNhbXBiZWxsQHBpbmdpZGVu
dGl0eS5jb20mZ3Q7LCAmcXVvdDtvYXV0aCZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7DQo8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg5oqE6YCB
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyDkuLvp
opggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFJl
OiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXINCmhhdmUg
dG8gYmUgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGVpdGhlciB0aGUg
Y2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT8gPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhp
IE5hdCwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyBUaGUgY3VycmVudCB0ZXh0IGVzc2VudGlhbGx5IHNheXMgdGhhdCB0aGUgYXNzZXJ0
aW9uDQpjYW4gZWl0aGVyIGJlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgY3JlYXRlZCBieSB0
aGUgY2xpZW50IChpbiB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2lnbmVkKQ0Kb3IgaXQgY2FuIGJl
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5ICh3
aGljaCBpcyB0aGVuIGNhbGxlZA0KdGhlIHRoaXJkIHBhcnR5IDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgdG9rZW4gc2VydmljZSkuIFNvLCB0aGlzIHRoaXJkIHBhcnR5IGNvdWxkIGJlIHRoZSBh
dXRob3JpemF0aW9uDQpzZXJ2ZXIuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQ2lhbzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSGFu
bmVzIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbTogb2F1dGgtYm91bmNl
c0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8YnI+DQomZ3Q7IE9u
IEJlaGFsZiBPZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGV4dCBOYXQgU2FraW11cmE8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgRGVjZW1iZXIgMDMsIDIwMTIgMTA6
MzUgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBCcmlhbiBDYW1wYmVsbDsgb2F1dGg8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZy
YW1ld29yayAtIFdoeSBkb2VzDQppc3N1ZXIgaGF2ZSB0byBiZTxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IEhpIEJyaWFuLCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBhc3NlcnRp
b24gZnJhbWV3b3JrIGRlZmluZXMgdGhlIElzc3VlciBhczogPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7SXNzdWVy
ICZuYnNwO1RoZSB1bmlxdWUgaWRlbnRpZmllciBmb3INCnRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQg
dGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYXNzZXJ0
aW9uLiAmbmJzcDtHZW5lcmFsbHkgdGhpcw0KaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSBr
ZXkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBtYXRlcmlh
bCB1c2VkIHRvIGdlbmVyYXRlIHRoZQ0KYXNzZXJ0aW9uLiAmbmJzcDtUaGUgaXNzdWVyIG1heWJl
IGVpdGhlciA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFu
IE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25zDQphcmUgc2VsZi1pc3N1ZWQpIG9yIGEgPGJy
Pg0KJmd0OyB0aGlyZCBwYXJ0eSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7IHRva2VuIHNlcnZpY2UuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgSSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8g
YmUgZWl0aGVyIHRoZSBjbGllbnQNCm9yIGEgdGhpcmQgcGFydHkgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyB0b2tlbiBzZXJ2aWNlLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IENvbmNlcHR1
YWxseSwgaXQgY291bGQgYmUgYW55IHRva2VuIHNlcnZpY2UgKGZ1bmN0aW9uYWxpdHkpDQo8YnI+
DQomZ3Q7ICZndDsgJmd0OyByZXNpZGluZ2luIGFueSBvZiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoZSBzdGFrZWhvbGRlcnMgKFJl
c291cmNlIE93bmVyLCBPQXV0aCBDbGllbnQsIEF1dGhvcml6YXRpb24NCjxicj4NCiZndDsgU2Vy
dmVyLCBvciA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGEgdGhpcmQgcGFydHkpLiA8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgd291bGQgYXBwcmVjaWF0ZSBpZiB5b3UgY291
bGQgY2xhcmlmeSB3aHkgaXMgdGhlDQpjYXNlLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu
YnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7IEJlc3QsIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBOYXQgU2FraW11cmEg
KD1uYXQpIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0
aW9uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEBfbmF0X2VuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQomZ3Q7
ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAm
Z3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0KJmd0OyBOYXQgU2FraW11cmEg
KD1uYXQpIDxicj4NCiZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0KJmd0OyBo
dHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+DQomZ3Q7IEBfbmF0X2VuIDxicj4NCiZndDsgPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IE9BdXRoQGll
dGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgPGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn
dDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IE5hdCBTYWtpbXVyYSAoPW5hdCk8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u
PGJyPg0KJmd0OyBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+DQomZ3Q7IEBfbmF0X2VuPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEV2ZSBNYWxlciAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2h0dHA6
Ly93d3cueG1sZ3JybC5jb20vYmxvZzxicj4NCiZndDsgKzEgNDI1IDM0NSA2NzU2ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyBodHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmw8YnI+DQo8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlz
dDxicj4NCiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQo8L2ZvbnQ+PC90dD4NCg==
--=_alternative 0004608648257ACC_=--

From sakimura@gmail.com  Wed Dec  5 23:50:47 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D81E21F8D81; Wed,  5 Dec 2012 23:50:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.07
X-Spam-Level: 
X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=-1.928,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_26=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT6o3uPurQ8g; Wed,  5 Dec 2012 23:50:45 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E714C21F8D7A; Wed,  5 Dec 2012 23:50:43 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id b47so3793374eek.31 for ; Wed, 05 Dec 2012 23:50:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XMYf0IIZoFWWq/4CYEG5Tc5Se2VDMAAV1flWnj+AcHc=; b=US4OuM/luIRMyeau6FsBOG1ePa7gvMJqpzY43B847PMbKGdD4EoVVxmOqAdqo9JHII VmP0lX+grlWeCzGcQyTknGxsbrF9OAGUXOEUz2LbgjcuJd4BBlMDj4A+7IJGHxmXUH4U aVWTXWE7/G18HoA5XupqDCL4SGyMYaL+U1DaMjTVYEY1+RmnUlPr55Rqbe5n7TVS2GUA HNjkPTc7tYH/Wuy738cav6ihJKy4yQxmjYP1c+CrJk57YPNvuEP2HY0B9xWNkjdayvIW WejDWKJ6o/fZTizDRaj+6bUVIdT0CBkGka6dZIYkkpbXSGw99Ab4HJdqaq5xmQh+t5id 7RrQ==
MIME-Version: 1.0
Received: by 10.14.216.70 with SMTP id f46mr2979699eep.12.1354780243029; Wed, 05 Dec 2012 23:50:43 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Wed, 5 Dec 2012 23:50:42 -0800 (PST)
In-Reply-To: 
References: <254DA4A9-6155-46D8-BCB6-A6A04868FC0E@xmlgrrl.com> 
Date: Thu, 6 Dec 2012 16:50:42 +0900
Message-ID: 
From: Nat Sakimura 
To: zhou.sujing@zte.com.cn
Content-Type: multipart/alternative; boundary=047d7b603c1e226ef004d02a5bbf
Cc: "oauth@ietf.org" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Dec 2012 07:50:47 -0000

--047d7b603c1e226ef004d02a5bbf
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Here, I think it is better to differentiate the entity and function/role.

Authorization Server in OAuth is "kind of" entity.
Its function actually is split into two, or in most cases three.

1. Authentication Endpoint
2. Authorization Endpoint
3. Token Endpoint

Now, "Assertion Verifier" is a function/role. It is performed by 3. Token
Endpoint.
It check the validity, and issues access tokens (which in turn can be
another assertion by the way.)

Authorization Endpoint is another function. It can be located anywhere. In
your case, it is located in what you call as Resource Owner (Browser
plug-in?) In my Self-Issued IdP case, it is issued by the App in the phone
which is called by the custom schema.

This is the reason why I constantly grumble that it is better to speak in
terms of functions rather than entities.
Functions may reside in any entity, and if we talk only in terms of the
entities, the combination will explode.

Nat

On Thu, Dec 6, 2012 at 9:46 AM,  wrote:

>
> As I understand, RO=3Dissuer  does not mean RO=3DAS.
> RO as an issuer generates assertion (if the assertion is similar to
> delegation statement in my use cases),
> AS as an assertion verifier receives the assertion and check its validity=
.
>
>
>
> oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-06 01:35:10:
>
>
> > Just checking that I understand: If the RO =3D=3D the issuer, then the
> > RO =3D=3D the AS, right? Just as in Nat's example, the user (or at leas=
t
> > the device presenting a user agent to them) =3D=3D the IdP? Colocating
> > the RO and AS functions shouldn't be precluded, but I would be
> > awfully confused if there were an RO/issuer in the picture and
> > *also* an AS that *doesn't* issue assertions.
>
> >
> > Eve
> >
> > On 5 Dec 2012, at 9:13 AM, Nat Sakimura  wrote:
> >
> > It is not OAuth, but Austrian eID system is an example of RO as an
> > assertion issuer pattern. They have their own SAML IdP on their PC
> > (at least a few years ago) and combined with the qualified certs in
> > the user's smart card and another file, creates a SAML assertion
> > with sectoral identifier and supply it to other systems.
> >
> > Nat
>
> > On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell <
> bcampbell@pingidentity.com
> > > wrote:
> > I say that it's only theoretical because I don't believe there are
> > any actual deployments supporting, or planning on supporting, RO as
> > an assertion issuer.
> >
>
> > On Tue, Dec 4, 2012 at 5:39 PM,  wrote:
> >
> > Why RO as an issuer is only theoretical today?
> >
>
> >
> > Brian Campbell 
> > 2012-12-04 23:41
> >
> > =CA=D5=BC=FE=C8=CB
> >
> > Nat Sakimura 
> >
> > =B3=AD=CB=CD
> >
> > zhou.sujing@zte.com.cn, "oauth@ietf.org" 
> >
> > =D6=F7=CC=E2
> >
> > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
> > either the client or a third party token service?
> >
> >
> >
> >
> > The intent was definitely not to constrain who/what could be the
> > issuer.  But also try to provide
> > some guidance around the common cases that are actually being
> > deployed now, which are the client self-issued and STS variants.
> > Resource owner as an issuer is an interesting case but seems mostly
> > theoretical at this point.
> >
> > I feel like mentioning the resource owner there in =A1=EC5.1 would caus=
e
> > more confusion than anything else. I'd prefer to just strike the
> > whole sentence in question and maybe add some additional text to =A1=EC=
3
> > that clarifies that the issuer can really be any entity, if folks
> > think a change is needed here?
> >
> >
> >
> > On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura 
> wrote:
> > Actually, "The issuer may be either
> >       an OAuth client (when assertions are self-issued) or any other
> > entity, e.g.,  a third party
> > token service, resource owner. "  is not really clean.
> >
> > OAuth client is just another example of an issuer.
> >
> > So, perhaps the sentence could be:
> >
> > "Example of issuers include an OAuth client, resource owner, an
> > independent third party."
> >
> > So, the clause becomes:
> >
> >  Issuer  The unique identifier for the entity that issued the
> >      assertion.  Generally this is the entity that holds the key
> >      material used to generate the assertion.
> >       Example of issuers include an OAuth client, resource owner, an
> > independent third party.
> >
> > Nat
> >
> > Nat
> >
> > On Tue, Dec 4, 2012 at 11:40 AM,  wrote:
> >
> >
> >
> > Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 10:=
26:50:
> >
> >
> > > Please feel free to suggest better language.
> >
> > >
> > > Issuer simply allows the token service to know who created the
> > > assertion, so it can look them up and see if they're trusted.
> > > Effectively the same as an Issuer in SAML.
> >
> > a conflict : "The token service is the assertion issuer" in
> > assertion document.
> > while you said "token service know who created the assertion"
> >
> > I wonder if the following text is acceptable:
> >
> >  Issuer  The unique identifier for the entity that issued the
> >      assertion.  Generally this is the entity that holds the key
> >      material used to generate the assertion.  The issuer may be either
> >       an OAuth client (when assertions are self-issued) or any other
> > entity, e.g.,  a third party
> > token service, resource owner.
> >
> >
> > 6.3.  Client Acting on Behalf of a User
> >
> > The Issuer of the assertion MUST identify the entity that issued
> >      the assertion as recognized by the Authorization Server.  If the
> >      assertion is self-issued, the Issuer SHOULD be the "client_id".
> >      If the assertion was issued by a Security Token Service (STS), the
> >      Issuer SHOULD identify the STS as recognized by the Authorization
> >      Server.If the assertion was issued by the resource owner, the
> >      Issuer SHOULD identify the resource owner as recognized by the
> > Authorization
> >      Server.
> >
> > >
> > > -cmort
> > >
> > > On Dec 3, 2012, at 6:23 PM,  wrote:
> > >
> > >
> > > Obviously, it is not so clear from the language there.
> > >
> > >
> > > Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 1=
0:17:12:
> > >
> > > > There's no reason why it can't be resource owner today.
> > > >
> > > > On Dec 3, 2012, at 6:06 PM,   > sujing@zte.com.cn
> > > > > wrote:
> > > >
> > > >
> > > > +1.
> > > > And why it was not looked at that time?
> > > >
> > > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:
> > > >
> > > > > Actually, I think it is a good time to start looking at the
> resourse
> > > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had
> brought
> > > > > this up a couple of years ago.)
> > > > >
> > > > > Igor
> > > > >
> > > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:
> > > > > I suppose, yes. I was reading it like that all the time.
> > > > > Whether it is or not, if it is still ok, it might be better to
> > > clarify it.
> > > > > Word like "third party" tends to be a bit of problem without
> > > > clearlydefining.
> > > > > I had similar experience in other fora.
> > > > >
> > > > > Nat
> > > > >
> > > > > Sent from iPad
> > > > >
> > > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn" 
> =A4=CE
> > > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:
> > > >
> > > > >
> > > > > could be Resource owner?
> > > > >
> > > >
> > > > >
> > > > > "Tschofenig, Hannes (NSN - FI/Espoo)" 
> > > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org
> > > > > 2012-12-03 16:49
> > > > >
> > > > > =CA=D5=BC=FE=C8=CB
> > > > >
> > > > > "ext Nat Sakimura" , "Brian Campbell" <
> > > > > bcampbell@pingidentity.com>, "oauth" 
> > > > >
> > > > > =B3=AD=CB=CD
> > > > >
> > > > > =D6=F7=CC=E2
> > > > >
> > > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
>
> > > > > either the client or a third party token service?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Hi Nat,
> > > > >
> > > > > The current text essentially says that the assertion can either b=
e
> > > > > created by the client (in which case it is self-signed) or it can
> be
> > > > > created by some other entity (which is then called the third part=
y
> > > > > token service). So, this third party could be the authorization
> server.
> > > > >
> > > > > Ciao
> > > > > Hannes
> > > > >
> > > > >
> > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
> > On Behalf Of
> > > > > ext Nat Sakimura
> > > > > Sent: Monday, December 03, 2012 10:35 AM
> > > > > To: Brian Campbell; oauth
> > > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have to
> be
> > > > > either the client or a third party token service?
> > > > >
> > > > > Hi Brian,
> > > > >
> > > > >
> > > > > The assertion framework defines the Issuer as:
> > > > >
> > > > >    Issuer  The unique identifier for the entity that issued the
> > > > >       assertion.  Generally this is the entity that holds the key
> > > > >       material used to generate the assertion.  The issuer maybe
> either
> > > > >       an OAuth client (when assertions are self-issued) or a
> > third party
> > > > >       token service.
> > > > >
> > > > > I was wondering why it has to be either the client or a third
> party
> > > > > token service.
> > > > > Conceptually, it could be any token service (functionality)
> > > > residingin any of
> > > > >
> > > > > the stakeholders (Resource Owner, OAuth Client, Authorization
> > Server, or
> > > > > a third party).
> > > > >
> > > > >
> > > > > I would appreciate if you could clarify why is the case.
> > > > >
> > > > >
> > > > > Best,
> > > > >
> > > > > --
> > > > > Nat Sakimura (=3Dnat)
> > > > > Chairman, OpenID Foundation
> > > > > http://nat.sakimura.org/
> > > > > @_nat_en
> > > > >  _______________________________________________
> > > > > OAuth mailing list
> > > > > OAuth@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > OAuth mailing list
> > > > > OAuth@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > > _______________________________________________
> > > > > OAuth mailing list
> > > > > OAuth@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> >
> > --
> > Nat Sakimura (=3Dnat)
> > Chairman, OpenID Foundation
> > http://nat.sakimura.org/
> > @_nat_en
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
>
> >
> >
>
> >
> > --
> > Nat Sakimura (=3Dnat)
> > Chairman, OpenID Foundation
> > http://nat.sakimura.org/
> > @_nat_en
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> > Eve Maler                                  http://www.xmlgrrl.com/blog
> > +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
>



--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b603c1e226ef004d02a5bbf
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable


Here, I think it is better to differentiate the entity and function/ro=
le. 

Authorization Server in OAuth is "k=
ind of" entity. 
Its function actually is split into tw=
o, or in most cases three. 



1. Authentication Endpoint
2. Authorization E=
ndpoint
3. Token Endpoint

Now, "Ass=
ertion Verifier" is a function/role. It is performed by 3. Token Endpo=
int. 


It check the validity, and issues access tokens (which in turn can be =
another assertion by the way.)

Authorization Endpo=
int is another function. It can be located anywhere. In your case, it is lo=
cated in what you call as Resource Owner (Browser plug-in?) In my Self-Issu=
ed IdP case, it is issued by the App in the phone which is called by the cu=
stom schema. 



This is the reason why I constantly grumble that it is =
better to speak in terms of functions rather than entities. 
Functions may reside in any entity, and if we talk only in terms of the en=
tities, the combination will explode. 


Nat

On Thu, Dec 6, =
2012 at 9:46 AM,  <zhou.sujing@zte.com.cn> wrote:



As I understand, RO=3Dissuer  does
not mean RO=3DAS.

RO as an issuer generates assertion
(if the assertion is similar to delegation statement in my use cases),

AS as an assertion verifier receives
the assertion and check its validity.







o=
auth-bounces@ietf.org =D0=B4=D3=DA 2012-12-06 01:35:10:




> Just checking that I understand: If the RO =3D=3D the issuer, then the


> RO =3D=3D the AS, right? Just as in Nat's example, the user (or at=
 least

> the device presenting a user agent to them) =3D=3D the IdP? Colocating


> the RO and AS functions shouldn't be precluded, but I would be 
> awfully confused if there were an RO/issuer in the picture and 

> *also* an AS that *doesn't* issue assertions.


> 

> Eve

> 

> On 5 Dec 2012, at 9:13 AM, Nat Sakimura <sakimura@gmail.com>
wrote:

> 

> It is not OAuth, but Austrian eID system is an example of RO as an


> assertion issuer pattern. They have their own SAML IdP on their PC


> (at least a few years ago) and combined with the qualified certs in


> the user's smart card and another file, creates a SAML assertion <=
br>
> with sectoral identifier and supply it to other systems. 

> 

> Nat



> On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell
<bcampbe=
ll@pingidentity.com

> > wrote:

> I say that it's only theoretical because I don't
believe there are 

> any actual deployments supporting, or planning on supporting, RO as


> an assertion issuer. 

> 



> On Tue, Dec 4, 2012 at 5:39 PM, <zhou.sujing@zte.com.cn>
wrote:

> 

> Why RO as an issuer is only theoretical today? 

> 



> 

> Brian Campbell <bcampbell@pingidentity.com> 

> 2012-12-04 23:41 

> 

> =CA=D5=BC=FE=C8=CB

> 

> Nat Sakimura <sakimura@gmail.com> 

> 

> =B3=AD=CB=CD

> 

> zhou.sujin=
g@zte.com.cn, "oauth@ietf.org" <oauth@ietf.org>


> 

> =D6=F7=CC=E2

> 

> Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be 

> either the client or a third party token service?

> 

> 

> 

> 

> The intent was definitely not to constrain who/what could be the 

> issuer.  But also try to provide 

> some guidance around the common cases that are actually being 

> deployed now, which are the client self-issued and STS variants. 

> Resource owner as an issuer is an interesting case but seems mostly


> theoretical at this point.

> 

> I feel like mentioning the resource owner there in =A1=EC5.1 would cau=
se


> more confusion than anything else. I'd prefer to just strike the <=
br>
> whole sentence in question and maybe add some additional text to =A1=
=EC3


> that clarifies that the issuer can really be any entity, if folks


> think a change is needed here? 

> 

> 

> 

> On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura <sakimura@gmail.com>
wrote: 

> Actually, "The issuer may be either 

>       an OAuth client (when assertions are self-issued)
or any other

> entity, e.g.,  a third party 

> token service, resource owner. "  is not really clean. 

> 

> OAuth client is just another example of an issuer. 

> 

> So, perhaps the sentence could be: 

> 

> "Example of issuers include an OAuth client, resource owner,
an 

> independent third party." 

> 

> So, the clause becomes: 

> 

>  Issuer  The unique identifier for the entity that issued
the 

>      assertion.  Generally this is the entity
that holds the key 

>      material used to generate the assertion.  


>       Example of issuers include an OAuth client, resou=
rce
owner, an

> independent third party. 

> 

> Nat 

> 

> Nat 

> 

> On Tue, Dec 4, 2012 at 11:40 AM, <zhou.sujing@zte.com.cn> wrote:


> 

> 

> 

> Chuck Mortimore <cmortimore@salesforce.com> =D0=B4=D3=DA 2012-12-04
10:26:50: 

> 

> 

> > Please feel free to suggest better language. 

> 

> > 

> > Issuer simply allows the token service to know who created the


> > assertion, so it can look them up and see if they're trusted.
    

> > Effectively the same as an Issuer in SAML. 

> 

> a conflict : "The token service is the assertion issuer"
in 

> assertion document. 

> while you said "token service know who created the assertion"=
;


> 

> I wonder if the following text is acceptable: 

>   

>  Issuer  The unique identifier for the entity that issued
the 

>      assertion.  Generally this is the entity
that holds the key 

>      material used to generate the assertion.  The
issuer may be either 

>       an OAuth client (when assertions are self-issued)
or any other

> entity, e.g.,  a third party 

> token service, resource owner. 

> 

> 

> 6.3.  Client Acting on Behalf of a User 

> 

> The Issuer of the assertion MUST identify the entity that issued 

>      the assertion as recognized by the Authorization
Server.  If the 

>      assertion is self-issued, the Issuer SHOULD be
the "client_id". 

>      If the assertion was issued by a Security Token
Service (STS), the 

>      Issuer SHOULD identify the STS as recognized by
the Authorization 

>      Server.If the assertion was issued by the resource
owner, the 

>      Issuer SHOULD identify the resource owner as recog=
nized
by the 

> Authorization 

>      Server. 

> 

> > 

> > -cmort 

> > 

> > On Dec 3, 2012, at 6:23 PM, <zhou.sujing@zte.com.cn> wrote:


> > 

> > 

> > Obviously, it is not so clear from the language there. 

> > 

> > 

> > Chuck Mortimore <cmortimore@salesforce.com> =D0=B4=D3=DA 2012-12-04
10:17:12:

> > 

> > > There's no reason why it can't be resource owner tod=
ay.
  

> > > 

> > > On Dec 3, 2012, at 6:06 PM, <zhou.sujing@zte.com.cn>
<zhou.

> sujing@zte.com.=
cn

> > > > wrote: 

> > > 

> > > 

> > > +1. 

> > > And why it was not looked at that time? 

> > > 

> > > =
oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:

> > > 

> > > > Actually, I think it is a good time to start looking
at the resourse

> > > > owner issuing assertions@ (Interestingly enough, Hui-La=
n
had brought

> > > > this up a couple of years ago.)

> > > > 

> > > > Igor

> > > > 

> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: 

> > > > I suppose, yes. I was reading it like that all the
time. 

> > > > Whether it is or not, if it is still ok, it might be
better to 

> > clarify it. 

> > > > Word like "third party" tends to be a bit
of problem without 

> > > clearlydefining. 

> > > > I had similar experience in other fora. 

> > > > 

> > > > Nat 

> > > > 

> > > > Sent from iPad 

> > > > 

> > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn"
<zhou.sujing=
@zte.com.cn> =A4=CE

> > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:

> > > 

> > > > 

> > > > could be Resource owner? 

> > > > 

> > > 

> > > > 

> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofen=
ig@nsn.com>


> > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org 

> > > > 2012-12-03 16:49 

> > > > 

> > > > =CA=D5=BC=FE=C8=CB 

> > > > 

> > > > "ext Nat Sakimura" <sakimura@gmail.com>,
"Brian Campbell" <

> > > > bcampbell@pingidentity.com>, "oauth" <oauth@ietf.org>


> > > > 

> > > > =B3=AD=CB=CD 

> > > > 

> > > > =D6=F7=CC=E2 

> > > > 

> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer
have to be     

> > > > either the client or a third party token service? 

> > > > 

> > > > 

> > > > 

> > > > 

> > > > Hi Nat, 

> > > >   

> > > > The current text essentially says that the assertion
can either be 

> > > > created by the client (in which case it is self-signed)
or it can be

> > > > created by some other entity (which is then called
the third party 

> > > > token service). So, this third party could be the autho=
rization
server. 

> > > >   

> > > > Ciao

> > > > Hannes 

> > > >   

> > > >   

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


> On Behalf Of 

> > > > ext Nat Sakimura

> > > > Sent: Monday, December 03, 2012 10:35 AM

> > > > To: Brian Campbell; oauth

> > > > Subject: [OAUTH-WG] Assertion Framework - Why does
issuer have to be

> > > > either the client or a third party token service? 

> > > >   

> > > > Hi Brian, 

> > > >   

> > > >   

> > > > The assertion framework defines the Issuer as: 

> > > >   

> > > >    Issuer  The unique identifier for
the entity that issued the 

> > > >       assertion.  Generally this
is the entity that holds the key 

> > > >       material used to generate the
assertion.  The issuer maybe either 

> > > >       an OAuth client (when assertions
are self-issued) or a 

> third party 

> > > >       token service. 

> > > >   

> > > > I was wondering why it has to be either the client
or a third party 

> > > > token service. 

> > > > Conceptually, it could be any token service (functional=
ity)


> > > residingin any of 

> > > >   

> > > > the stakeholders (Resource Owner, OAuth Client, Authori=
zation


> Server, or 

> > > > a third party). 

> > > >   

> > > >   

> > > > I would appreciate if you could clarify why is the
case. 

> > > >   

> > > >   

> > > > Best, 

> > > >   

> > > > -- 

> > > > Nat Sakimura (=3Dnat) 

> > > > Chairman, OpenID Foundation

> > > > =
http://nat.sakimura.org/

> > > > @_nat_en 

> > > >  _______________________________________________
> > > > OAuth mailing list

> > > > OAu=
th@ietf.org

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

> > > 

> > > > 

> > > > 

> > > > _______________________________________________

> > > > OAuth mailing list

> > > > OAu=
th@ietf.org

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

> > > > _______________________________________________

> > > > OAuth mailing list

> > > > OAu=
th@ietf.org

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

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 

> 

> 

> 

> -- 

> Nat Sakimura (=3Dnat) 

> Chairman, OpenID Foundation

> http://nat.saki=
mura.org/

> @_nat_en 

> 

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 




> 

> 



> 

> -- 

> Nat Sakimura (=3Dnat)

> Chairman, OpenID Foundation

> http://nat.saki=
mura.org/

> @_nat_en

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 

> 

> Eve Maler                
                 http://www.xmlgrrl.com/blog

> +1 425 345 6756             &=
nbsp;  
        http://www.twitter.com/xmlgrrl



> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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






-- 
=
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_=
en




--047d7b603c1e226ef004d02a5bbf--

From zubair.dig@gmail.com  Thu Dec  6 04:32:18 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D50E21F8615 for ; Thu,  6 Dec 2012 04:32: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPxhtIgnu4sS for ; Thu,  6 Dec 2012 04:32:13 -0800 (PST)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C2F5B21F8614 for ; Thu,  6 Dec 2012 04:32:12 -0800 (PST)
Received: by mail-la0-f44.google.com with SMTP id d3so5396066lah.31 for ; Thu, 06 Dec 2012 04:32:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=OPN+ar9DNoAOMApXQL2nrBm0SYYkflJNKjuYY7DCYwU=; b=hnVC1wzcBIQB0acRXDqDGXwhyp6HStiMrIbpkAw60IQKwq0T3q/QHy9bSN6afhyx9Z WFyXV0At5kbz7ZXxwFTFeiyywLspVTmCb0wMzrgp3mF6gmNLdp/+wViIjbSm8pce4A7G yLbelf5NiJbE+gqDakUD6HV/gq1akaVyYphE5pYCZfLO6WqrMKJam8P47UuH8BWOi0Fp cHgmlaIW20nDeiGvotuxhwKo6JcMPMrh+pD1dcStsAkY+YQlXM/XMI4EwZKB4+cexs6c 5fyuFxJ+d2fk462C69tBPBXA5TlmW07B15rLKzenaWjsh6Ss+Aaex6Y1/bH98bMc1sIm hwAQ==
MIME-Version: 1.0
Received: by 10.112.102.135 with SMTP id fo7mr825155lbb.82.1354797131161; Thu, 06 Dec 2012 04:32:11 -0800 (PST)
Received: by 10.112.28.4 with HTTP; Thu, 6 Dec 2012 04:32:10 -0800 (PST)
In-Reply-To: 
References: 
Date: Thu, 6 Dec 2012 17:32:10 +0500
Message-ID: 
From: zubair hasan 
To: oauth@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 49, Issue 48
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Dec 2012 12:32:18 -0000

i want to leave this

From hannes.tschofenig@gmx.net  Mon Dec  3 00:39:27 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F4721F88F6 for ; Mon,  3 Dec 2012 00:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.619
X-Spam-Level: 
X-Spam-Status: No, score=-101.619 tagged_above=-999 required=5 tests=[AWL=0.980, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1fwyCW5Cj71 for ; Mon,  3 Dec 2012 00:39:26 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5C4D521F88E2 for ; Mon,  3 Dec 2012 00:39:25 -0800 (PST)
Received: (qmail invoked by alias); 03 Dec 2012 08:39:20 -0000
Received: from unknown (EHLO [10.255.128.112]) [194.251.119.201] by mail.gmx.net (mp072) with SMTP; 03 Dec 2012 09:39:20 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/k1u0Fd9jkgoP5EeYz/BKIKo4Nw3vlU3f5Ecqaqr 2RxArP6hVxqaxC
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
From: Hannes Tschofenig 
Date: Mon, 3 Dec 2012 10:39:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8E9A3618-B20A-4760-9071-8DDCF471AAA4@gmx.net>
To: ext The IESG , Stephen Farrell 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
X-Mailman-Approved-At: Thu, 06 Dec 2012 07:38:33 -0800
Subject: [OAUTH-WG] Shepherd Write-Up for 
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 03 Dec 2012 08:39:27 -0000

Hi Stephen, Hi IESG secretary,=20

the OAuth working group considers  ready =
for publication. Please advance the document. The shepherd writeup can =
be found below.=20

Ciao
Hannes

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

Writeup for Assertion Framework for OAuth 2.0 =


(1) What type of RFC is being requested (BCP, Proposed Standard, =
Internet Standard, Informational, Experimental, or Historic)? Why is =
this the proper type of RFC? Is this type of RFC indicated in the title =
page header?

The RFC type is 'Standards Track' and the type is indicated in the title =
page. Although the document is architectural in nature it is the =
umbrella document for two other 'Standards Track' specifications that =
extend this document with SAML and JSON specific details.=20

(2) The IESG approval announcement includes a Document Announcement =
Write-Up. Please provide such a Document Announcement Write-Up. Recent =
examples can be found in the "Action" announcements for approved =
documents. The approval announcement contains the following sections:

Technical Summary:

   The Assertion Framework for OAuth 2.0 allows the use of assertions
   in the form of a new client authentication mechanism
   and a new authorization grant type.  Mechanisms are specified for
   transporting assertions during interactions with a token endpoint, as
   well as general processing rules.

   The intent of this specification is to provide a common framework for
   OAuth 2.0 to interwork with other identity systems using assertions,
   and to provide alternative client authentication mechanisms.

   Note that this specification only defines abstract message flows and
   processing rules.  In order to be implementable, companion
   specifications are necessary to provide the corresponding concrete
   instantiations.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was =
there controversy about particular points or were there decisions where =
the consensus was particularly rough?

There was no controversy around this document.=20

Document Quality:

The working group decided to separate the framework for assertion =
handling from instance documents supporting SAML assertion and =
JSON-based encoded tokens. Readers who want to implement the =
functionality also need to consult one of the extension documents, such =
as .=20

Personnel:

The document shepherd is Hannes Tschofenig and the responsible area =
director is Stephen Farrell.=20

(3) Briefly describe the review of this document that was performed by =
the Document Shepherd. If this version of the document is not ready for =
publication, please explain why the document is being forwarded to the =
IESG.

The draft authors believe that this document is ready for publication. =
The document shepherd has reviewed the document and provided detailed =
comments. Those review comments have been taken into account and have =
lead to clarifications regarding the claimed security benefits.  =20

(4) Does the document Shepherd have any concerns about the depth or =
breadth of the reviews that have been performed?

This document has gotten feedback from the working group but certainly =
not to the extend other OAuth working group documents, like the OAuth =
Core specification and the OAuth Bearer Token specification, had =
received. This can be explained by the focused use cases. The ability to =
use assertions in the way described by the document is not needed in =
every deployment.=20

(5) Do portions of the document need review from a particular or from =
broader perspective, e.g., security, operational complexity, AAA, DNS, =
DHCP, XML, or internationalization? If so, describe the review that took =
place.

Additional feedback from the security community would be appreciated. =
Also, it would be helpful to get additional reviews from outside the =
group from people already using assertions to ensure that the use cases =
and the offered security benefits are well understood.

(6) Describe any specific concerns or issues that the Document Shepherd =
has with this document that the Responsible Area Director and/or the =
IESG should be aware of? For example, perhaps he or she is uncomfortable =
with certain parts of the document, or has concerns whether there really =
is a need for it. In any event, if the WG has discussed those issues and =
has indicated that it still wishes to advance the document, detail those =
concerns here.

The shepherd still believes that the document authors could have done a =
better job in explaining the use cases for which the proposed =
functionality are applicable. The concerns have been raised in =
http://www.ietf.org/mail-archive/web/oauth/current/msg09961.html

(7) Has each author confirmed that any and all appropriate IPR =
disclosures required for full conformance with the provisions of BCP 78 =
and BCP 79 have already been filed. If not, explain why?

The shepherd has gotten a confirmation from the authors that no IPR =
disclosures are needed.=20

(8) Has an IPR disclosure been filed that references this document? If =
so, summarize any WG discussion and conclusion regarding the IPR =
disclosures.

No IPR disclosures have been filed.=20

(9) How solid is the WG consensus behind this document? Does it =
represent the strong concurrence of a few individuals, with others being =
silent, or does the WG as a whole understand and agree with it?

Only a subset of working group participants have reviewed the document =
but enough to move forward with the publication.  However, because the =
SAML and JWT Assertion Profiles based on it have been implemented and =
are being used by a number of parties, we have high confidence in the =
sufficiency and accuracy of the document text.

(10) Has anyone threatened an appeal or otherwise indicated extreme =
discontent? If so, please summarise the areas of conflict in separate =
email messages to the Responsible Area Director. (It should be in a =
separate email because this questionnaire is publicly available.)

No appeal or extreme discontent has been raised.=20

(11) Identify any ID nits the Document Shepherd has found in this =
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts =
Checklist). Boilerplate checks are not enough; this check needs to be =
thorough.

The document has been verified and contains no nits.=20

(12) Describe how the document meets any required formal review =
criteria, such as the MIB Doctor, media type, and URI type reviews.

There is no such review necessary.=20

(13) Have all references within this document been identified as either =
normative or informative?

Yes.=20

(14) Are there normative references to documents that are not ready for =
advancement or are otherwise in an unclear state? If such normative =
references exist, what is the plan for their completion?

No.=20

(15) Are there downward normative references references (see RFC 3967)? =
If so, list these downward references to support the Area Director in =
the Last Call procedure.

No, there is no need for a downref.=20

(16) Will publication of this document change the status of any existing =
RFCs? Are those RFCs listed on the title page header, listed in the =
abstract, and discussed in the introduction? If the RFCs are not listed =
in the Abstract and Introduction, explain why, and point to the part of =
the document where the relationship of this document to the other RFCs =
is discussed. If this information is not in the document, explain why =
the WG considers it unnecessary.

The publication of this document does not change the status of other =
RFCs.=20

(17) Describe the Document Shepherd's review of the IANA considerations =
section, especially with regard to its consistency with the body of the =
document. Confirm that all protocol extensions that the document makes =
are associated with the appropriate reservations in IANA registries. =
Confirm that any referenced IANA registries have been clearly =
identified. Confirm that newly created IANA registries include a =
detailed specification of the initial contents for the registry, that =
allocations procedures for future registrations are defined, and a =
reasonable name for the new registry has been suggested (see RFC 5226).

The document adds three values to an existing registry established with =
RFC 6749.=20

(18) List any new IANA registries that require Expert Review for future =
allocations. Provide any public guidance that the IESG would find useful =
in selecting the IANA Experts for these new registries.

The document only adds entries to existing registries and does not =
define any new registries.=20

(19) Describe reviews and automated checks performed by the Document =
Shepherd to validate sections of the document written in a formal =
language, such as XML code, BNF rules, MIB definitions, etc.

There are only snippets for examples and no pseudo code is contained =
that requires validation.=20
=20=

From Jeff.Hodges@KingsMountain.com  Thu Dec  6 08:06:41 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C0421F85EA for ; Thu,  6 Dec 2012 08:06:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level: 
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBFN-pY4JIzq for ; Thu,  6 Dec 2012 08:06:40 -0800 (PST)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 4AF5521F859A for ; Thu,  6 Dec 2012 08:06:40 -0800 (PST)
Received: (qmail 20974 invoked by uid 0); 6 Dec 2012 16:06:18 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 6 Dec 2012 16:06:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=J32l3+TGlhjK9n5rYIrEnbsEi9H/sIAOPZhsYmAvlx4=;  b=AZq3X7tnvUFGqnZedTktQhEjPQ00j02sumngQk8kZfsyr+7lYBSdE/Figa5AjqGlZWkvWe01HtyTfXpUHh/lh+ZefIt9Mf7Q6DuBym/ceVTWng3IsOzuvLdPqAQ62WJ2;
Received: from [216.113.168.128] (port=26266 helo=[10.244.137.210]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Tgdxp-0005qY-MJ; Thu, 06 Dec 2012 09:06:17 -0700
Message-ID: <50C0C278.7050302@KingsMountain.com>
Date: Thu, 06 Dec 2012 08:06:16 -0800
From: =JeffH 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: HTTP State , IETF WebSec WG ,  HTTP Working Group , Apps Discuss , IETF oauth WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: [OAUTH-WG] fyi: IETF conflict review results for draft-secure-cookie-session-protocol
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Dec 2012 16:06:41 -0000

[ I was nosing around and noticed this relatively recent decision, it didn't 
appear to have been fwd'd to these lists. fyi/fwiw... ]


Subject: Results of IETF-conflict review for
	draft-secure-cookie-session-protocol-08
From: The IESG 
Date: Mon, 19 Nov 2012 14:46:52 -0800
To: "Nevil Brownlee" ,
	draft-secure-cookie-session-protocol@tools.ietf.org
Cc: iana@iana.org, The IESG , ietf-announce@ietf.org

The IESG has completed a review of
draft-secure-cookie-session-protocol-08 consistent with RFC5742.


The IESG has no problem with the publication of 'SCS: Secure Cookie
Sessions for HTTP'  as an
Informational RFC.


The IESG has concluded that this work is related to IETF work done in the
websec and httpbis working groups, but this relationship does not prevent
publishing.

The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
http://datatracker.ietf.org/doc/conflict-review-secure-cookie-session-protocol/

A URL of the reviewed Internet Draft is:
http://datatracker.ietf.org/doc/draft-secure-cookie-session-protocol/

The process for such documents is described at
http://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

###

IETF conflict review for draft-secure-cookie-session-protocol
[conflict-review-secure-cookie-session-protocol-00]

https://datatracker.ietf.org/doc/conflict-review-secure-cookie-session-protocol/


Conflict Review State:		Approved No Problem - announcement sent

Shepherding AD: 		Barry Leiba

Last updated:			2012-11-19


Conflict Review for draft-secure-cookie-session-protocol-09

The IESG has concluded that this work is related to IETF work done in the
websec and httpbis working groups, but this relationship does not prevent
publishing.


###

From barryleiba.mailing.lists@gmail.com  Thu Dec  6 11:34:55 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3C921F88C1; Thu,  6 Dec 2012 11:34:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.093
X-Spam-Level: 
X-Spam-Status: No, score=-103.093 tagged_above=-999 required=5 tests=[AWL=-0.116, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf1yeV96Vi7G; Thu,  6 Dec 2012 11:34:55 -0800 (PST)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47D3E21F867A; Thu,  6 Dec 2012 11:34:49 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id y2so5909765lbk.31 for ; Thu, 06 Dec 2012 11:34:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=6hgqy6AxD2R9SZxoPfFAKdFGbY/9J4+Dx5UZdm8Mfqo=; b=w9guA4XFOKSC774g7SX+soD1m+Y6+QRF6mkNXKlBVdISLQvhx9Hihwr00e+plLeDPP yHZR2tTQo0G+zV3FyM7tZu/jQu9cdx1jzjKKCLCoPU4OqwQM3PqqDd0n2rL7zJ36MugA ccWGI3qYiDQoC/bOh+YVlm2u1VmQvsTaJUdbO54KGju5CkNy9mYKgaUF0Ui0519+H4u6 IInq3oMD3sep0OCh+sxvkgSyXmusixHxB0tIu1UzxDyW6GakQEeVI0jl4ZCkAO2KaKi9 o017MtkfpQ72bYWg5x8FqEaQhtDNa6Ak0iYQ8D+GS3/CyLk2EDeLfSIudBKZaEuHGDWL 9P8A==
MIME-Version: 1.0
Received: by 10.112.25.34 with SMTP id z2mr1449204lbf.125.1354822488183; Thu, 06 Dec 2012 11:34:48 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.112.12.166 with HTTP; Thu, 6 Dec 2012 11:34:48 -0800 (PST)
In-Reply-To: <50C0C278.7050302@KingsMountain.com>
References: <50C0C278.7050302@KingsMountain.com>
Date: Thu, 6 Dec 2012 14:34:48 -0500
X-Google-Sender-Auth: OX0NyyE18yghle8XQywQyo6h5PI
Message-ID: 
From: Barry Leiba 
To: "=JeffH" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF oauth WG , IETF WebSec WG , HTTP Working Group , Apps Discuss , HTTP State 
Subject: Re: [OAUTH-WG] fyi: IETF conflict review results for draft-secure-cookie-session-protocol
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Dec 2012 19:34:55 -0000

> [ I was nosing around and noticed this relatively recent decision, it didn't
> appear to have been fwd'd to these lists. fyi/fwiw... ]
...
> The IESG has no problem with the publication of 'SCS: Secure Cookie
> Sessions for HTTP'  as an
> Informational RFC.
>
> The IESG has concluded that this work is related to IETF work done in the
> websec and httpbis working groups, but this relationship does not prevent
> publishing.

Yes, Jeff, and thanks for forwarding this.  To make sure people have
the background...

I announced on 17 Oct to this set of mailing lists that we were
looking for input to the conflict review to be posted to the SAAG
mailing list.  The discussion thread starts here:
http://www.ietf.org/mail-archive/web/saag/current/msg04049.html

On 9 November, I closed the discussion with this message on the SAAG list:
http://www.ietf.org/mail-archive/web/saag/current/msg04164.html

If anyone has any questions about the document, I suggest they contact
the authors directly.  You can do that with the following tools alias:


Barry, App AD

From bcampbell@pingidentity.com  Thu Dec  6 15:04:12 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2BCE21E8039 for ; Thu,  6 Dec 2012 15:04:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level: 
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_26=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306,  URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgZH81U8QDZ3 for ; Thu,  6 Dec 2012 15:04:10 -0800 (PST)
Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id C19BE21F86CE for ; Thu,  6 Dec 2012 15:04:09 -0800 (PST)
Received: from mail-qa0-f70.google.com ([209.85.216.70]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKUMEkaah4mr7ydc7Yy2lZyokurpFI04Mw@postini.com; Thu, 06 Dec 2012 15:04:09 PST
Received: by mail-qa0-f70.google.com with SMTP id hg5so3805045qab.1 for ; Thu, 06 Dec 2012 15:04:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=EYMqf+zjZMaozeys6zyVsIoAZYSuLdgV/YjUe0k+nec=; b=RmP//VPqqw2ajh22BNBr9qROT12p46HSnCUwlJ2geoUlF37th2LNJOwLNrkJsj+hws fmV3z19pT4kWJdHwwOR7zbG98b0Z6s2tIMGFRLZABuSmp8ulsvnJG+lOKcttdXvFj+bk xJ/JgWe4sBBmXOPHNyLLVliLUl5X7Om2CDQz1oGkQXpqBw1nMPUQmmDnKmKg/Qapo5Lo B0b8N2LQT20KGtYprCTKqNzpNisBFKo3kPhievS3IAHILucxOn+fNfTiTWVnTbr2CmsY 1mEuvpcWqp+82oBkVvoypDEs29LUhCy5y9B7dMAGa5W8KIT8ud5J+20Jq04juEzdKI6w NgSg==
Received: by 10.52.37.9 with SMTP id u9mr2296792vdj.83.1354835048716; Thu, 06 Dec 2012 15:04:08 -0800 (PST)
Received: by 10.52.37.9 with SMTP id u9mr2296786vdj.83.1354835048548; Thu, 06 Dec 2012 15:04:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.163.170 with HTTP; Thu, 6 Dec 2012 15:03:38 -0800 (PST)
In-Reply-To: 
References: <254DA4A9-6155-46D8-BCB6-A6A04868FC0E@xmlgrrl.com>  
From: Brian Campbell 
Date: Thu, 6 Dec 2012 16:03:38 -0700
Message-ID: 
To: Nat Sakimura 
Content-Type: multipart/alternative; boundary=20cf307f3a84cc492c04d0371db3
X-Gm-Message-State: ALoCoQnm6lwX2Wiwr77Pt6qk85ZM1BKgGmZCc94Xx2nFN8UpoDNKG1OU5yOpLN5naX5DW6IR+P6/oMNRXjQLHM29Oak8kScCTn+Ke1THyYE39FRBqnEYk17AR9/Hj6J9zOVfFww7Gu1n
Cc: "oauth-bounces@ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 06 Dec 2012 23:04:12 -0000

--20cf307f3a84cc492c04d0371db3
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

So to circle back to the original question/intent of this thread: the
assertion framework spec doesn't intended to constrain who/what can issue
the assertion. It does discuss some considerations for common (in the
authors' view anyway but I stand somewhat corrected by Nat) issuers and
that discussion might have been read as limiting who can issue.

Do folks think it reads as though it does constrain who/what can issue as
assertion for the flow? After rereading parts of it myself, I do think
there's some room for improvement in some of the text. But I don't know how
important it really is.

A question for the chairs or others more versed in the workings of the IETF
- is this document even in a place where changes can be made? The Shepherd
Write-Up for the document was recently sent to the IESG Secretary and I'm
honestly not sure what the protocol is for making changes at this point.






On Thu, Dec 6, 2012 at 12:50 AM, Nat Sakimura  wrote:

> Here, I think it is better to differentiate the entity and function/role.
>
> Authorization Server in OAuth is "kind of" entity.
> Its function actually is split into two, or in most cases three.
>
> 1. Authentication Endpoint
> 2. Authorization Endpoint
> 3. Token Endpoint
>
> Now, "Assertion Verifier" is a function/role. It is performed by 3. Token
> Endpoint.
> It check the validity, and issues access tokens (which in turn can be
> another assertion by the way.)
>
> Authorization Endpoint is another function. It can be located anywhere. I=
n
> your case, it is located in what you call as Resource Owner (Browser
> plug-in?) In my Self-Issued IdP case, it is issued by the App in the phon=
e
> which is called by the custom schema.
>
> This is the reason why I constantly grumble that it is better to speak in
> terms of functions rather than entities.
> Functions may reside in any entity, and if we talk only in terms of the
> entities, the combination will explode.
>
> Nat
>
> On Thu, Dec 6, 2012 at 9:46 AM,  wrote:
>
>>
>> As I understand, RO=3Dissuer  does not mean RO=3DAS.
>> RO as an issuer generates assertion (if the assertion is similar to
>> delegation statement in my use cases),
>> AS as an assertion verifier receives the assertion and check its validit=
y.
>>
>>
>>
>> oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-06 01:35:10:
>>
>>
>> > Just checking that I understand: If the RO =3D=3D the issuer, then the
>> > RO =3D=3D the AS, right? Just as in Nat's example, the user (or at lea=
st
>> > the device presenting a user agent to them) =3D=3D the IdP? Colocating
>> > the RO and AS functions shouldn't be precluded, but I would be
>> > awfully confused if there were an RO/issuer in the picture and
>> > *also* an AS that *doesn't* issue assertions.
>>
>> >
>> > Eve
>> >
>> > On 5 Dec 2012, at 9:13 AM, Nat Sakimura  wrote:
>> >
>> > It is not OAuth, but Austrian eID system is an example of RO as an
>> > assertion issuer pattern. They have their own SAML IdP on their PC
>> > (at least a few years ago) and combined with the qualified certs in
>> > the user's smart card and another file, creates a SAML assertion
>> > with sectoral identifier and supply it to other systems.
>> >
>> > Nat
>>
>> > On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell <
>> bcampbell@pingidentity.com
>> > > wrote:
>> > I say that it's only theoretical because I don't believe there are
>> > any actual deployments supporting, or planning on supporting, RO as
>> > an assertion issuer.
>> >
>>
>> > On Tue, Dec 4, 2012 at 5:39 PM,  wrote:
>> >
>> > Why RO as an issuer is only theoretical today?
>> >
>>
>> >
>> > Brian Campbell 
>> > 2012-12-04 23:41
>> >
>> > =CA=D5=BC=FE=C8=CB
>> >
>> > Nat Sakimura 
>> >
>> > =B3=AD=CB=CD
>> >
>> > zhou.sujing@zte.com.cn, "oauth@ietf.org" 
>> >
>> > =D6=F7=CC=E2
>> >
>> > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
>> > either the client or a third party token service?
>> >
>> >
>> >
>> >
>> > The intent was definitely not to constrain who/what could be the
>> > issuer.  But also try to provide
>> > some guidance around the common cases that are actually being
>> > deployed now, which are the client self-issued and STS variants.
>> > Resource owner as an issuer is an interesting case but seems mostly
>> > theoretical at this point.
>> >
>> > I feel like mentioning the resource owner there in =A1=EC5.1 would cau=
se
>> > more confusion than anything else. I'd prefer to just strike the
>> > whole sentence in question and maybe add some additional text to =A1=
=EC3
>> > that clarifies that the issuer can really be any entity, if folks
>> > think a change is needed here?
>> >
>> >
>> >
>> > On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura 
>> wrote:
>> > Actually, "The issuer may be either
>> >       an OAuth client (when assertions are self-issued) or any other
>> > entity, e.g.,  a third party
>> > token service, resource owner. "  is not really clean.
>> >
>> > OAuth client is just another example of an issuer.
>> >
>> > So, perhaps the sentence could be:
>> >
>> > "Example of issuers include an OAuth client, resource owner, an
>> > independent third party."
>> >
>> > So, the clause becomes:
>> >
>> >  Issuer  The unique identifier for the entity that issued the
>> >      assertion.  Generally this is the entity that holds the key
>> >      material used to generate the assertion.
>> >       Example of issuers include an OAuth client, resource owner, an
>> > independent third party.
>> >
>> > Nat
>> >
>> > Nat
>> >
>> > On Tue, Dec 4, 2012 at 11:40 AM,  wrote:
>> >
>> >
>> >
>> > Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 10=
:26:50:
>> >
>> >
>> > > Please feel free to suggest better language.
>> >
>> > >
>> > > Issuer simply allows the token service to know who created the
>> > > assertion, so it can look them up and see if they're trusted.
>> > > Effectively the same as an Issuer in SAML.
>> >
>> > a conflict : "The token service is the assertion issuer" in
>> > assertion document.
>> > while you said "token service know who created the assertion"
>> >
>> > I wonder if the following text is acceptable:
>> >
>> >  Issuer  The unique identifier for the entity that issued the
>> >      assertion.  Generally this is the entity that holds the key
>> >      material used to generate the assertion.  The issuer may be eithe=
r
>> >       an OAuth client (when assertions are self-issued) or any other
>> > entity, e.g.,  a third party
>> > token service, resource owner.
>> >
>> >
>> > 6.3.  Client Acting on Behalf of a User
>> >
>> > The Issuer of the assertion MUST identify the entity that issued
>> >      the assertion as recognized by the Authorization Server.  If the
>> >      assertion is self-issued, the Issuer SHOULD be the "client_id".
>> >      If the assertion was issued by a Security Token Service (STS), th=
e
>> >      Issuer SHOULD identify the STS as recognized by the Authorization
>> >      Server.If the assertion was issued by the resource owner, the
>> >      Issuer SHOULD identify the resource owner as recognized by the
>> > Authorization
>> >      Server.
>> >
>> > >
>> > > -cmort
>> > >
>> > > On Dec 3, 2012, at 6:23 PM,  wrote:
>> > >
>> > >
>> > > Obviously, it is not so clear from the language there.
>> > >
>> > >
>> > > Chuck Mortimore  =D0=B4=D3=DA 2012-12-04 =
10:17:12:
>> > >
>> > > > There's no reason why it can't be resource owner today.
>> > > >
>> > > > On Dec 3, 2012, at 6:06 PM,  > > sujing@zte.com.cn
>> > > > > wrote:
>> > > >
>> > > >
>> > > > +1.
>> > > > And why it was not looked at that time?
>> > > >
>> > > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:
>> > > >
>> > > > > Actually, I think it is a good time to start looking at the
>> resourse
>> > > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had
>> brought
>> > > > > this up a couple of years ago.)
>> > > > >
>> > > > > Igor
>> > > > >
>> > > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:
>> > > > > I suppose, yes. I was reading it like that all the time.
>> > > > > Whether it is or not, if it is still ok, it might be better to
>> > > clarify it.
>> > > > > Word like "third party" tends to be a bit of problem without
>> > > > clearlydefining.
>> > > > > I had similar experience in other fora.
>> > > > >
>> > > > > Nat
>> > > > >
>> > > > > Sent from iPad
>> > > > >
>> > > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn" 
>> =A4=CE
>> > > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:
>> > > >
>> > > > >
>> > > > > could be Resource owner?
>> > > > >
>> > > >
>> > > > >
>> > > > > "Tschofenig, Hannes (NSN - FI/Espoo)" 
>>
>> > > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org
>> > > > > 2012-12-03 16:49
>> > > > >
>> > > > > =CA=D5=BC=FE=C8=CB
>> > > > >
>> > > > > "ext Nat Sakimura" , "Brian Campbell" <
>> > > > > bcampbell@pingidentity.com>, "oauth" 
>> > > > >
>> > > > > =B3=AD=CB=CD
>> > > > >
>> > > > > =D6=F7=CC=E2
>> > > > >
>> > > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
>>
>> > > > > either the client or a third party token service?
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > Hi Nat,
>> > > > >
>> > > > > The current text essentially says that the assertion can either
>> be
>> > > > > created by the client (in which case it is self-signed) or it ca=
n
>> be
>> > > > > created by some other entity (which is then called the third
>> party
>> > > > > token service). So, this third party could be the authorization
>> server.
>> > > > >
>> > > > > Ciao
>> > > > > Hannes
>> > > > >
>> > > > >
>> > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
>> > On Behalf Of
>> > > > > ext Nat Sakimura
>> > > > > Sent: Monday, December 03, 2012 10:35 AM
>> > > > > To: Brian Campbell; oauth
>> > > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have t=
o
>> be
>> > > > > either the client or a third party token service?
>> > > > >
>> > > > > Hi Brian,
>> > > > >
>> > > > >
>> > > > > The assertion framework defines the Issuer as:
>> > > > >
>> > > > >    Issuer  The unique identifier for the entity that issued the
>> > > > >       assertion.  Generally this is the entity that holds the ke=
y
>> > > > >       material used to generate the assertion.  The issuer maybe
>> either
>> > > > >       an OAuth client (when assertions are self-issued) or a
>> > third party
>> > > > >       token service.
>> > > > >
>> > > > > I was wondering why it has to be either the client or a third
>> party
>> > > > > token service.
>> > > > > Conceptually, it could be any token service (functionality)
>> > > > residingin any of
>> > > > >
>> > > > > the stakeholders (Resource Owner, OAuth Client, Authorization
>> > Server, or
>> > > > > a third party).
>> > > > >
>> > > > >
>> > > > > I would appreciate if you could clarify why is the case.
>> > > > >
>> > > > >
>> > > > > Best,
>> > > > >
>> > > > > --
>> > > > > Nat Sakimura (=3Dnat)
>> > > > > Chairman, OpenID Foundation
>> > > > > http://nat.sakimura.org/
>> > > > > @_nat_en
>> > > > >  _______________________________________________
>> > > > > OAuth mailing list
>> > > > > OAuth@ietf.org
>> > > > > https://www.ietf.org/mailman/listinfo/oauth
>> > > >
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > OAuth mailing list
>> > > > > OAuth@ietf.org
>> > > > > https://www.ietf.org/mailman/listinfo/oauth
>> > > > > _______________________________________________
>> > > > > OAuth mailing list
>> > > > > OAuth@ietf.org
>> > > > > https://www.ietf.org/mailman/listinfo/oauth
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> >
>> >
>> >
>> > --
>> > Nat Sakimura (=3Dnat)
>> > Chairman, OpenID Foundation
>> > http://nat.sakimura.org/
>> > @_nat_en
>> >
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>>
>> >
>> >
>>
>> >
>> > --
>> > Nat Sakimura (=3Dnat)
>> > Chairman, OpenID Foundation
>> > http://nat.sakimura.org/
>> > @_nat_en
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>> >
>> >
>> > Eve Maler                                  http://www.xmlgrrl.com/blog
>> > +1 425 345 6756                         http://www.twitter.com/xmlgrrl
>>
>> > _______________________________________________
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
>
> --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--20cf307f3a84cc492c04d0371db3
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

So to circle back to the original question/intent of this thread: the asser=
tion framework spec doesn't intended to constrain who/what can issue th=
e assertion. It does discuss some considerations for common (in the authors=
' view anyway but I stand somewhat corrected by Nat) issuers and that d=
iscussion might have been read as limiting who can issue. 




Do folks think it reads as though it does constrain who/what can issue =
as assertion for the flow? After rereading parts of it myself, I do think t=
here's some room for improvement in some of the text. But I don't k=
now how important it really is.




A question for the chairs or others more versed in the workings of the =
IETF - is this document even in a place where changes can be made? The Shep=
herd Write-Up for the document was recently sent to the IESG Secretary and =
I'm honestly not sure what the protocol is for making changes at this p=
oint.










On Thu, Dec 6=
, 2012 at 12:50 AM, Nat Sakimura <sakimura@gmail.com> wrote=
:



Here, I think it is better to different=
iate the entity and function/role. 

Authoriza=
tion Server in OAuth is "kind of" entity. 



Its function actually is split into two, or in most cases three. =




1. Authentication Endpoint
2. Authorization E=
ndpoint
3. Token Endpoint

Now, "Ass=
ertion Verifier" is a function/role. It is performed by 3. Token Endpo=
int. 




It check the validity, and issues access tokens (which in turn can be =
another assertion by the way.)

Authorization Endpo=
int is another function. It can be located anywhere. In your case, it is lo=
cated in what you call as Resource Owner (Browser plug-in?) In my Self-Issu=
ed IdP case, it is issued by the App in the phone which is called by the cu=
stom schema. 





This is the reason why I constantly grumble that it is =
better to speak in terms of functions rather than entities. 
Functions may reside in any entity, and if we talk only in terms of the en=
tities, the combination will explode. 





Nat

On Thu, Dec 6, 2012 at 9:46 AM,  <zhou.sujing@zte.com.cn> wrote:






As I understand, RO=3Dissuer  does
not mean RO=3DAS.

RO as an issuer generates assertion
(if the assertion is similar to delegation statement in my use cases),

AS as an assertion verifier receives
the assertion and check its validity.







o=
auth-bounces@ietf.org =D0=B4=D3=DA 2012-12-06 01:35:10:




> Just checking that I understand: If the RO =3D=3D the issuer, then the


> RO =3D=3D the AS, right? Just as in Nat's example, the user (or at=
 least

> the device presenting a user agent to them) =3D=3D the IdP? Colocating


> the RO and AS functions shouldn't be precluded, but I would be 
> awfully confused if there were an RO/issuer in the picture and 

> *also* an AS that *doesn't* issue assertions.


> 

> Eve

> 

> On 5 Dec 2012, at 9:13 AM, Nat Sakimura <sakimura@gmail.com>
wrote:

> 

> It is not OAuth, but Austrian eID system is an example of RO as an


> assertion issuer pattern. They have their own SAML IdP on their PC


> (at least a few years ago) and combined with the qualified certs in


> the user's smart card and another file, creates a SAML assertion <=
br>
> with sectoral identifier and supply it to other systems. 

> 

> Nat



> On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell
<bcampbe=
ll@pingidentity.com

> > wrote:

> I say that it's only theoretical because I don't
believe there are 

> any actual deployments supporting, or planning on supporting, RO as


> an assertion issuer. 

> 



> On Tue, Dec 4, 2012 at 5:39 PM, <zhou.sujing@zte.com.cn>
wrote:

> 

> Why RO as an issuer is only theoretical today? 

> 



> 

> Brian Campbell <bcampbell@pingidentity.com> 

> 2012-12-04 23:41 

> 

> =CA=D5=BC=FE=C8=CB

> 

> Nat Sakimura <sakimura@gmail.com> 

> 

> =B3=AD=CB=CD

> 

> zhou.sujin=
g@zte.com.cn, "oauth@ietf.org" <oauth@ietf.org>


> 

> =D6=F7=CC=E2

> 

> Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be 

> either the client or a third party token service?

> 

> 

> 

> 

> The intent was definitely not to constrain who/what could be the 

> issuer.  But also try to provide 

> some guidance around the common cases that are actually being 

> deployed now, which are the client self-issued and STS variants. 

> Resource owner as an issuer is an interesting case but seems mostly


> theoretical at this point.

> 

> I feel like mentioning the resource owner there in =A1=EC5.1 would cau=
se


> more confusion than anything else. I'd prefer to just strike the <=
br>
> whole sentence in question and maybe add some additional text to =A1=
=EC3


> that clarifies that the issuer can really be any entity, if folks


> think a change is needed here? 

> 

> 

> 

> On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura <sakimura@gmail.com>
wrote: 

> Actually, "The issuer may be either 

>       an OAuth client (when assertions are self-issued)
or any other

> entity, e.g.,  a third party 

> token service, resource owner. "  is not really clean. 

> 

> OAuth client is just another example of an issuer. 

> 

> So, perhaps the sentence could be: 

> 

> "Example of issuers include an OAuth client, resource owner,
an 

> independent third party." 

> 

> So, the clause becomes: 

> 

>  Issuer  The unique identifier for the entity that issued
the 

>      assertion.  Generally this is the entity
that holds the key 

>      material used to generate the assertion.  


>       Example of issuers include an OAuth client, resou=
rce
owner, an

> independent third party. 

> 

> Nat 

> 

> Nat 

> 

> On Tue, Dec 4, 2012 at 11:40 AM, <zhou.sujing@zte.com.cn> wrote:


> 

> 

> 

> Chuck Mortimore <cmortimore@salesforce.com> =D0=B4=D3=DA 2012-12-04
10:26:50: 

> 

> 

> > Please feel free to suggest better language. 

> 

> > 

> > Issuer simply allows the token service to know who created the


> > assertion, so it can look them up and see if they're trusted.
    

> > Effectively the same as an Issuer in SAML. 

> 

> a conflict : "The token service is the assertion issuer"
in 

> assertion document. 

> while you said "token service know who created the assertion"=
;


> 

> I wonder if the following text is acceptable: 

>   

>  Issuer  The unique identifier for the entity that issued
the 

>      assertion.  Generally this is the entity
that holds the key 

>      material used to generate the assertion.  The
issuer may be either 

>       an OAuth client (when assertions are self-issued)
or any other

> entity, e.g.,  a third party 

> token service, resource owner. 

> 

> 

> 6.3.  Client Acting on Behalf of a User 

> 

> The Issuer of the assertion MUST identify the entity that issued 

>      the assertion as recognized by the Authorization
Server.  If the 

>      assertion is self-issued, the Issuer SHOULD be
the "client_id". 

>      If the assertion was issued by a Security Token
Service (STS), the 

>      Issuer SHOULD identify the STS as recognized by
the Authorization 

>      Server.If the assertion was issued by the resource
owner, the 

>      Issuer SHOULD identify the resource owner as recog=
nized
by the 

> Authorization 

>      Server. 

> 

> > 

> > -cmort 

> > 

> > On Dec 3, 2012, at 6:23 PM, <zhou.sujing@zte.com.cn> wrote:


> > 

> > 

> > Obviously, it is not so clear from the language there. 

> > 

> > 

> > Chuck Mortimore <cmortimore@salesforce.com> =D0=B4=D3=DA 2012-12-04
10:17:12:

> > 

> > > There's no reason why it can't be resource owner tod=
ay.
  

> > > 

> > > On Dec 3, 2012, at 6:06 PM, <zhou.sujing@zte.com.cn>
<zhou.

> sujing@zte.com.=
cn

> > > > wrote: 

> > > 

> > > 

> > > +1. 

> > > And why it was not looked at that time? 

> > > 

> > > =
oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:

> > > 

> > > > Actually, I think it is a good time to start looking
at the resourse

> > > > owner issuing assertions@ (Interestingly enough, Hui-La=
n
had brought

> > > > this up a couple of years ago.)

> > > > 

> > > > Igor

> > > > 

> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote: 

> > > > I suppose, yes. I was reading it like that all the
time. 

> > > > Whether it is or not, if it is still ok, it might be
better to 

> > clarify it. 

> > > > Word like "third party" tends to be a bit
of problem without 

> > > clearlydefining. 

> > > > I had similar experience in other fora. 

> > > > 

> > > > Nat 

> > > > 

> > > > Sent from iPad 

> > > > 

> > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn"
<zhou.sujing=
@zte.com.cn> =A4=CE

> > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:

> > > 

> > > > 

> > > > could be Resource owner? 

> > > > 

> > > 

> > > > 

> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofen=
ig@nsn.com>


> > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org 

> > > > 2012-12-03 16:49 

> > > > 

> > > > =CA=D5=BC=FE=C8=CB 

> > > > 

> > > > "ext Nat Sakimura" <sakimura@gmail.com>,
"Brian Campbell" <

> > > > bcampbell@pingidentity.com>, "oauth" <oauth@ietf.org>


> > > > 

> > > > =B3=AD=CB=CD 

> > > > 

> > > > =D6=F7=CC=E2 

> > > > 

> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer
have to be     

> > > > either the client or a third party token service? 

> > > > 

> > > > 

> > > > 

> > > > 

> > > > Hi Nat, 

> > > >   

> > > > The current text essentially says that the assertion
can either be 

> > > > created by the client (in which case it is self-signed)
or it can be

> > > > created by some other entity (which is then called
the third party 

> > > > token service). So, this third party could be the autho=
rization
server. 

> > > >   

> > > > Ciao

> > > > Hannes 

> > > >   

> > > >   

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


> On Behalf Of 

> > > > ext Nat Sakimura

> > > > Sent: Monday, December 03, 2012 10:35 AM

> > > > To: Brian Campbell; oauth

> > > > Subject: [OAUTH-WG] Assertion Framework - Why does
issuer have to be

> > > > either the client or a third party token service? 

> > > >   

> > > > Hi Brian, 

> > > >   

> > > >   

> > > > The assertion framework defines the Issuer as: 

> > > >   

> > > >    Issuer  The unique identifier for
the entity that issued the 

> > > >       assertion.  Generally this
is the entity that holds the key 

> > > >       material used to generate the
assertion.  The issuer maybe either 

> > > >       an OAuth client (when assertions
are self-issued) or a 

> third party 

> > > >       token service. 

> > > >   

> > > > I was wondering why it has to be either the client
or a third party 

> > > > token service. 

> > > > Conceptually, it could be any token service (functional=
ity)


> > > residingin any of 

> > > >   

> > > > the stakeholders (Resource Owner, OAuth Client, Authori=
zation


> Server, or 

> > > > a third party). 

> > > >   

> > > >   

> > > > I would appreciate if you could clarify why is the
case. 

> > > >   

> > > >   

> > > > Best, 

> > > >   

> > > > -- 

> > > > Nat Sakimura (=3Dnat) 

> > > > Chairman, OpenID Foundation

> > > > =
http://nat.sakimura.org/

> > > > @_nat_en 

> > > >  _______________________________________________
> > > > OAuth mailing list

> > > > OAu=
th@ietf.org

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

> > > 

> > > > 

> > > > 

> > > > _______________________________________________

> > > > OAuth mailing list

> > > > OAu=
th@ietf.org

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

> > > > _______________________________________________

> > > > OAuth mailing list

> > > > OAu=
th@ietf.org

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

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 

> 

> 

> 

> -- 

> Nat Sakimura (=3Dnat) 

> Chairman, OpenID Foundation

> http://nat.saki=
mura.org/

> @_nat_en 

> 

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 




> 

> 



> 

> -- 

> Nat Sakimura (=3Dnat)

> Chairman, OpenID Foundation

> http://nat.saki=
mura.org/

> @_nat_en

> 

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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

> 

> 

> Eve Maler                
                 http://www.xmlgrrl.com/blog

> +1 425 345 6756             &=
nbsp;  
        http://www.twitter.com/xmlgrrl



> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org=


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






-- 
=
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_=
en







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--20cf307f3a84cc492c04d0371db3--

From zhou.sujing@zte.com.cn  Thu Dec  6 16:17:27 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A6621F858F; Thu,  6 Dec 2012 16:17:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.023
X-Spam-Level: 
X-Spam-Status: No, score=-99.023 tagged_above=-999 required=5 tests=[AWL=1.570, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_26=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix2AdAc70xRt; Thu,  6 Dec 2012 16:17:25 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E396B21F8587; Thu,  6 Dec 2012 16:17:24 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id DECA91244D2F; Fri,  7 Dec 2012 08:19:07 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 846115F7168; Fri,  7 Dec 2012 08:06:15 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qB70HFI1049804; Fri, 7 Dec 2012 08:17:15 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Brian Campbell 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Fri, 7 Dec 2012 08:17:00 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-07 08:17:14, Serialize complete at 2012-12-07 08:17:14
Content-Type: multipart/alternative; boundary="=_alternative 0001B0F648257ACD_="
X-MAIL: mse01.zte.com.cn qB70HFI1049804
Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Dec 2012 00:17:27 -0000

This is a multipart message in MIME format.
--=_alternative 0001B0F648257ACD_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

QnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPiDlhpnkuo4gMjAxMi0x
Mi0wNyAwNzowMzozODoNCg0KPiBBIHF1ZXN0aW9uIGZvciB0aGUgY2hhaXJzIG9yIG90aGVycyBt
b3JlIHZlcnNlZCBpbiB0aGUgd29ya2luZ3Mgb2YgDQo+IHRoZSBJRVRGIC0gaXMgdGhpcyBkb2N1
bWVudCBldmVuIGluIGEgcGxhY2Ugd2hlcmUgY2hhbmdlcyBjYW4gYmUgDQo+IG1hZGU/IFRoZSBT
aGVwaGVyZCBXcml0ZS1VcCBmb3IgdGhlIGRvY3VtZW50IHdhcyByZWNlbnRseSBzZW50IHRvIA0K
PiB0aGUgSUVTRyBTZWNyZXRhcnkgYW5kIEknbSBob25lc3RseSBub3Qgc3VyZSB3aGF0IHRoZSBw
cm90b2NvbCBpcyANCj4gZm9yIG1ha2luZyBjaGFuZ2VzIGF0IHRoaXMgcG9pbnQuDQpPciB3ZSBj
YW4gc3RhcnQgYSBuZXcgZHJhZnQgZXh0ZW5kaW5nIGFuZCBjbGFyaWZ5aW5nIHRoZSBhc3NlcnRp
b24gDQpkb2N1bWVudCwNCm1vcmUgdXNlIGNhc2VzIGNvdWxkIGJlIGltcGxlbWVudGVkIGJ5IGFz
c2VydGlvbiBtYXkgYmUgaW5jbHVkZWQsIGFuZCANCm90aGVyIHRoaW5ncy4uLg0KDQoNCj4gDQo+
IA0KPiANCg0KPiANCg0KPiBPbiBUaHUsIERlYyA2LCAyMDEyIGF0IDEyOjUwIEFNLCBOYXQgU2Fr
aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4gDQp3cm90ZToNCj4gSGVyZSwgSSB0aGluayBpdCBp
cyBiZXR0ZXIgdG8gZGlmZmVyZW50aWF0ZSB0aGUgZW50aXR5IGFuZCANCmZ1bmN0aW9uL3JvbGUu
IA0KPiANCj4gQXV0aG9yaXphdGlvbiBTZXJ2ZXIgaW4gT0F1dGggaXMgImtpbmQgb2YiIGVudGl0
eS4gDQo+IEl0cyBmdW5jdGlvbiBhY3R1YWxseSBpcyBzcGxpdCBpbnRvIHR3bywgb3IgaW4gbW9z
dCBjYXNlcyB0aHJlZS4gDQo+IA0KPiAxLiBBdXRoZW50aWNhdGlvbiBFbmRwb2ludA0KPiAyLiBB
dXRob3JpemF0aW9uIEVuZHBvaW50DQo+IDMuIFRva2VuIEVuZHBvaW50DQo+IA0KPiBOb3csICJB
c3NlcnRpb24gVmVyaWZpZXIiIGlzIGEgZnVuY3Rpb24vcm9sZS4gSXQgaXMgcGVyZm9ybWVkIGJ5
IDMuIA0KPiBUb2tlbiBFbmRwb2ludC4gDQo+IEl0IGNoZWNrIHRoZSB2YWxpZGl0eSwgYW5kIGlz
c3VlcyBhY2Nlc3MgdG9rZW5zICh3aGljaCBpbiB0dXJuIGNhbiANCj4gYmUgYW5vdGhlciBhc3Nl
cnRpb24gYnkgdGhlIHdheS4pDQo+IA0KPiBBdXRob3JpemF0aW9uIEVuZHBvaW50IGlzIGFub3Ro
ZXIgZnVuY3Rpb24uIEl0IGNhbiBiZSBsb2NhdGVkIA0KPiBhbnl3aGVyZS4gSW4geW91ciBjYXNl
LCBpdCBpcyBsb2NhdGVkIGluIHdoYXQgeW91IGNhbGwgYXMgUmVzb3VyY2UgDQo+IE93bmVyIChC
cm93c2VyIHBsdWctaW4/KSBJbiBteSBTZWxmLUlzc3VlZCBJZFAgY2FzZSwgaXQgaXMgaXNzdWVk
IGJ5DQo+IHRoZSBBcHAgaW4gdGhlIHBob25lIHdoaWNoIGlzIGNhbGxlZCBieSB0aGUgY3VzdG9t
IHNjaGVtYS4gDQo+IA0KPiBUaGlzIGlzIHRoZSByZWFzb24gd2h5IEkgY29uc3RhbnRseSBncnVt
YmxlIHRoYXQgaXQgaXMgYmV0dGVyIHRvIA0KPiBzcGVhayBpbiB0ZXJtcyBvZiBmdW5jdGlvbnMg
cmF0aGVyIHRoYW4gZW50aXRpZXMuIA0KPiBGdW5jdGlvbnMgbWF5IHJlc2lkZSBpbiBhbnkgZW50
aXR5LCBhbmQgaWYgd2UgdGFsayBvbmx5IGluIHRlcm1zIG9mIA0KPiB0aGUgZW50aXRpZXMsIHRo
ZSBjb21iaW5hdGlvbiB3aWxsIGV4cGxvZGUuIA0KPiANCj4gTmF0DQo+IA0KPiBPbiBUaHUsIERl
YyA2LCAyMDEyIGF0IDk6NDYgQU0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPiB3cm90ZToNCj4g
DQo+IEFzIEkgdW5kZXJzdGFuZCwgUk89aXNzdWVyICBkb2VzIG5vdCBtZWFuIFJPPUFTLiANCj4g
Uk8gYXMgYW4gaXNzdWVyIGdlbmVyYXRlcyBhc3NlcnRpb24gKGlmIHRoZSBhc3NlcnRpb24gaXMg
c2ltaWxhciB0byANCj4gZGVsZWdhdGlvbiBzdGF0ZW1lbnQgaW4gbXkgdXNlIGNhc2VzKSwgDQo+
IEFTIGFzIGFuIGFzc2VydGlvbiB2ZXJpZmllciByZWNlaXZlcyB0aGUgYXNzZXJ0aW9uIGFuZCBj
aGVjayBpdHMgDQp2YWxpZGl0eS4gDQo+IA0KPiANCj4gDQo+IG9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmcg5YaZ5LqOIDIwMTItMTItMDYgMDE6MzU6MTA6DQo+IA0KPiANCj4gPiBKdXN0IGNoZWNraW5n
IHRoYXQgSSB1bmRlcnN0YW5kOiBJZiB0aGUgUk8gPT0gdGhlIGlzc3VlciwgdGhlbiB0aGUgDQo+
ID4gUk8gPT0gdGhlIEFTLCByaWdodD8gSnVzdCBhcyBpbiBOYXQncyBleGFtcGxlLCB0aGUgdXNl
ciAob3IgYXQgbGVhc3QNCj4gPiB0aGUgZGV2aWNlIHByZXNlbnRpbmcgYSB1c2VyIGFnZW50IHRv
IHRoZW0pID09IHRoZSBJZFA/IENvbG9jYXRpbmcgDQo+ID4gdGhlIFJPIGFuZCBBUyBmdW5jdGlv
bnMgc2hvdWxkbid0IGJlIHByZWNsdWRlZCwgYnV0IEkgd291bGQgYmUgDQo+ID4gYXdmdWxseSBj
b25mdXNlZCBpZiB0aGVyZSB3ZXJlIGFuIFJPL2lzc3VlciBpbiB0aGUgcGljdHVyZSBhbmQgDQo+
ID4gKmFsc28qIGFuIEFTIHRoYXQgKmRvZXNuJ3QqIGlzc3VlIGFzc2VydGlvbnMuDQo+IA0KPiA+
IA0KPiA+IEV2ZSANCj4gPiANCj4gPiBPbiA1IERlYyAyMDEyLCBhdCA5OjEzIEFNLCBOYXQgU2Fr
aW11cmEgPHNha2ltdXJhQGdtYWlsLmNvbT4gd3JvdGU6IA0KPiA+IA0KPiA+IEl0IGlzIG5vdCBP
QXV0aCwgYnV0IEF1c3RyaWFuIGVJRCBzeXN0ZW0gaXMgYW4gZXhhbXBsZSBvZiBSTyBhcyBhbiAN
Cj4gPiBhc3NlcnRpb24gaXNzdWVyIHBhdHRlcm4uIFRoZXkgaGF2ZSB0aGVpciBvd24gU0FNTCBJ
ZFAgb24gdGhlaXIgUEMgDQo+ID4gKGF0IGxlYXN0IGEgZmV3IHllYXJzIGFnbykgYW5kIGNvbWJp
bmVkIHdpdGggdGhlIHF1YWxpZmllZCBjZXJ0cyBpbiANCj4gPiB0aGUgdXNlcidzIHNtYXJ0IGNh
cmQgYW5kIGFub3RoZXIgZmlsZSwgY3JlYXRlcyBhIFNBTUwgYXNzZXJ0aW9uIA0KPiA+IHdpdGgg
c2VjdG9yYWwgaWRlbnRpZmllciBhbmQgc3VwcGx5IGl0IHRvIG90aGVyIHN5c3RlbXMuIA0KPiA+
IA0KPiA+IE5hdA0KPiANCj4gPiBPbiBXZWQsIERlYyA1LCAyMDEyIGF0IDExOjA1IFBNLCBCcmlh
biBDYW1wYmVsbCANCjxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbQ0KPiA+ID4gd3JvdGU6IA0K
PiA+IEkgc2F5IHRoYXQgaXQncyBvbmx5IHRoZW9yZXRpY2FsIGJlY2F1c2UgSSBkb24ndCBiZWxp
ZXZlIHRoZXJlIGFyZSANCj4gPiBhbnkgYWN0dWFsIGRlcGxveW1lbnRzIHN1cHBvcnRpbmcsIG9y
IHBsYW5uaW5nIG9uIHN1cHBvcnRpbmcsIFJPIGFzIA0KPiA+IGFuIGFzc2VydGlvbiBpc3N1ZXIu
IA0KPiA+IA0KPiANCj4gPiBPbiBUdWUsIERlYyA0LCAyMDEyIGF0IDU6MzkgUE0sIDx6aG91LnN1
amluZ0B6dGUuY29tLmNuPiB3cm90ZTogDQo+ID4gDQo+ID4gV2h5IFJPIGFzIGFuIGlzc3VlciBp
cyBvbmx5IHRoZW9yZXRpY2FsIHRvZGF5PyANCj4gPiANCj4gDQo+ID4gDQo+ID4gQnJpYW4gQ2Ft
cGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPiANCj4gPiAyMDEyLTEyLTA0IDIzOjQx
IA0KPiA+IA0KPiA+IOaUtuS7tuS6uiANCj4gPiANCj4gPiBOYXQgU2FraW11cmEgPHNha2ltdXJh
QGdtYWlsLmNvbT4gDQo+ID4gDQo+ID4g5oqE6YCBIA0KPiA+IA0KPiA+IHpob3Uuc3VqaW5nQHp0
ZS5jb20uY24sICJvYXV0aEBpZXRmLm9yZyIgPG9hdXRoQGlldGYub3JnPiANCj4gPiANCj4gPiDk
uLvpopggDQo+ID4gDQo+ID4gUmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdo
eSBkb2VzIGlzc3VlciBoYXZlIHRvIGJlIA0KPiA+IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhp
cmQgcGFydHkgdG9rZW4gc2VydmljZT8gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gVGhl
IGludGVudCB3YXMgZGVmaW5pdGVseSBub3QgdG8gY29uc3RyYWluIHdoby93aGF0IGNvdWxkIGJl
IHRoZSANCj4gPiBpc3N1ZXIuICBCdXQgYWxzbyB0cnkgdG8gcHJvdmlkZSANCj4gPiBzb21lIGd1
aWRhbmNlIGFyb3VuZCB0aGUgY29tbW9uIGNhc2VzIHRoYXQgYXJlIGFjdHVhbGx5IGJlaW5nIA0K
PiA+IGRlcGxveWVkIG5vdywgd2hpY2ggYXJlIHRoZSBjbGllbnQgc2VsZi1pc3N1ZWQgYW5kIFNU
UyB2YXJpYW50cy4gDQo+ID4gUmVzb3VyY2Ugb3duZXIgYXMgYW4gaXNzdWVyIGlzIGFuIGludGVy
ZXN0aW5nIGNhc2UgYnV0IHNlZW1zIG1vc3RseSANCj4gPiB0aGVvcmV0aWNhbCBhdCB0aGlzIHBv
aW50Lg0KPiA+IA0KPiA+IEkgZmVlbCBsaWtlIG1lbnRpb25pbmcgdGhlIHJlc291cmNlIG93bmVy
IHRoZXJlIGluIMKnNS4xIHdvdWxkIGNhdXNlIA0KPiA+IG1vcmUgY29uZnVzaW9uIHRoYW4gYW55
dGhpbmcgZWxzZS4gSSdkIHByZWZlciB0byBqdXN0IHN0cmlrZSB0aGUgDQo+ID4gd2hvbGUgc2Vu
dGVuY2UgaW4gcXVlc3Rpb24gYW5kIG1heWJlIGFkZCBzb21lIGFkZGl0aW9uYWwgdGV4dCB0byDC
pzMgDQo+ID4gdGhhdCBjbGFyaWZpZXMgdGhhdCB0aGUgaXNzdWVyIGNhbiByZWFsbHkgYmUgYW55
IGVudGl0eSwgaWYgZm9sa3MgDQo+ID4gdGhpbmsgYSBjaGFuZ2UgaXMgbmVlZGVkIGhlcmU/IA0K
PiA+IA0KPiA+IA0KPiA+IA0KPiA+IE9uIE1vbiwgRGVjIDMsIDIwMTIgYXQgOToyMCBQTSwgTmF0
IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+IA0Kd3JvdGU6IA0KPiA+IEFjdHVhbGx5LCAi
VGhlIGlzc3VlciBtYXkgYmUgZWl0aGVyIA0KPiA+ICAgICAgIGFuIE9BdXRoIGNsaWVudCAod2hl
biBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3VlZCkgb3IgYW55IG90aGVyDQo+ID4gZW50aXR5LCBl
LmcuLCAgYSB0aGlyZCBwYXJ0eSANCj4gPiB0b2tlbiBzZXJ2aWNlLCByZXNvdXJjZSBvd25lci4g
IiAgaXMgbm90IHJlYWxseSBjbGVhbi4gDQo+ID4gDQo+ID4gT0F1dGggY2xpZW50IGlzIGp1c3Qg
YW5vdGhlciBleGFtcGxlIG9mIGFuIGlzc3Vlci4gDQo+ID4gDQo+ID4gU28sIHBlcmhhcHMgdGhl
IHNlbnRlbmNlIGNvdWxkIGJlOiANCj4gPiANCj4gPiAiRXhhbXBsZSBvZiBpc3N1ZXJzIGluY2x1
ZGUgYW4gT0F1dGggY2xpZW50LCByZXNvdXJjZSBvd25lciwgYW4gDQo+ID4gaW5kZXBlbmRlbnQg
dGhpcmQgcGFydHkuIiANCj4gPiANCj4gPiBTbywgdGhlIGNsYXVzZSBiZWNvbWVzOiANCj4gPiAN
Cj4gPiAgSXNzdWVyICBUaGUgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBp
c3N1ZWQgdGhlIA0KPiA+ICAgICAgYXNzZXJ0aW9uLiAgR2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVu
dGl0eSB0aGF0IGhvbGRzIHRoZSBrZXkgDQo+ID4gICAgICBtYXRlcmlhbCB1c2VkIHRvIGdlbmVy
YXRlIHRoZSBhc3NlcnRpb24uIA0KPiA+ICAgICAgIEV4YW1wbGUgb2YgaXNzdWVycyBpbmNsdWRl
IGFuIE9BdXRoIGNsaWVudCwgcmVzb3VyY2Ugb3duZXIsIGFuDQo+ID4gaW5kZXBlbmRlbnQgdGhp
cmQgcGFydHkuIA0KPiA+IA0KPiA+IE5hdCANCj4gPiANCj4gPiBOYXQgDQo+ID4gDQo+ID4gT24g
VHVlLCBEZWMgNCwgMjAxMiBhdCAxMTo0MCBBTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IHdy
b3RlOiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBDaHVjayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVA
c2FsZXNmb3JjZS5jb20+IOWGmeS6jiAyMDEyLTEyLTA0IDEwOjI2OjUwOiANCj4gPiANCj4gPiAN
Cj4gPiA+IFBsZWFzZSBmZWVsIGZyZWUgdG8gc3VnZ2VzdCBiZXR0ZXIgbGFuZ3VhZ2UuIA0KPiA+
IA0KPiA+ID4gDQo+ID4gPiBJc3N1ZXIgc2ltcGx5IGFsbG93cyB0aGUgdG9rZW4gc2VydmljZSB0
byBrbm93IHdobyBjcmVhdGVkIHRoZSANCj4gPiA+IGFzc2VydGlvbiwgc28gaXQgY2FuIGxvb2sg
dGhlbSB1cCBhbmQgc2VlIGlmIHRoZXkncmUgdHJ1c3RlZC4gDQo+ID4gPiBFZmZlY3RpdmVseSB0
aGUgc2FtZSBhcyBhbiBJc3N1ZXIgaW4gU0FNTC4gDQo+ID4gDQo+ID4gYSBjb25mbGljdCA6ICJU
aGUgdG9rZW4gc2VydmljZSBpcyB0aGUgYXNzZXJ0aW9uIGlzc3VlciIgaW4gDQo+ID4gYXNzZXJ0
aW9uIGRvY3VtZW50LiANCj4gPiB3aGlsZSB5b3Ugc2FpZCAidG9rZW4gc2VydmljZSBrbm93IHdo
byBjcmVhdGVkIHRoZSBhc3NlcnRpb24iIA0KPiA+IA0KPiA+IEkgd29uZGVyIGlmIHRoZSBmb2xs
b3dpbmcgdGV4dCBpcyBhY2NlcHRhYmxlOiANCj4gPiANCj4gPiAgSXNzdWVyICBUaGUgdW5pcXVl
IGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhlIA0KPiA+ICAgICAgYXNz
ZXJ0aW9uLiAgR2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSBrZXkg
DQo+ID4gICAgICBtYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uICBUaGUg
aXNzdWVyIG1heSBiZSANCmVpdGhlciANCj4gPiAgICAgICBhbiBPQXV0aCBjbGllbnQgKHdoZW4g
YXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9yIGFueSBvdGhlcg0KPiA+IGVudGl0eSwgZS5n
LiwgIGEgdGhpcmQgcGFydHkgDQo+ID4gdG9rZW4gc2VydmljZSwgcmVzb3VyY2Ugb3duZXIuIA0K
PiA+IA0KPiA+IA0KPiA+IDYuMy4gIENsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGEgVXNlciAN
Cj4gPiANCj4gPiBUaGUgSXNzdWVyIG9mIHRoZSBhc3NlcnRpb24gTVVTVCBpZGVudGlmeSB0aGUg
ZW50aXR5IHRoYXQgaXNzdWVkIA0KPiA+ICAgICAgdGhlIGFzc2VydGlvbiBhcyByZWNvZ25pemVk
IGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4gIElmIHRoZSANCj4gPiAgICAgIGFzc2VydGlv
biBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlciBTSE9VTEQgYmUgdGhlICJjbGllbnRfaWQiLiAN
Cj4gPiAgICAgIElmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSBhIFNlY3VyaXR5IFRva2Vu
IFNlcnZpY2UgKFNUUyksIA0KdGhlIA0KPiA+ICAgICAgSXNzdWVyIFNIT1VMRCBpZGVudGlmeSB0
aGUgU1RTIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gDQoNCj4gPiAgICAgIFNl
cnZlci5JZiB0aGUgYXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCB0
aGUgDQo+ID4gICAgICBJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSByZXNvdXJjZSBvd25lciBh
cyByZWNvZ25pemVkIGJ5IHRoZSANCj4gPiBBdXRob3JpemF0aW9uIA0KPiA+ICAgICAgU2VydmVy
LiANCj4gPiANCj4gPiA+IA0KPiA+ID4gLWNtb3J0IA0KPiA+ID4gDQo+ID4gPiBPbiBEZWMgMywg
MjAxMiwgYXQgNjoyMyBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IHdyb3RlOiANCj4gPiA+
IA0KPiA+ID4gDQo+ID4gPiBPYnZpb3VzbHksIGl0IGlzIG5vdCBzbyBjbGVhciBmcm9tIHRoZSBs
YW5ndWFnZSB0aGVyZS4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gQ2h1Y2sgTW9ydGltb3JlIDxj
bW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPiDlhpnkuo4gMjAxMi0xMi0wNCANCjEwOjE3OjEyOg0K
PiA+ID4gDQo+ID4gPiA+IFRoZXJlJ3Mgbm8gcmVhc29uIHdoeSBpdCBjYW4ndCBiZSByZXNvdXJj
ZSBvd25lciB0b2RheS4gDQo+ID4gPiA+IA0KPiA+ID4gPiBPbiBEZWMgMywgMjAxMiwgYXQgNjow
NiBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IDx6aG91Lg0KPiA+IHN1amluZ0B6dGUuY29t
LmNuDQo+ID4gPiA+ID4gd3JvdGU6IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+ICsxLiAN
Cj4gPiA+ID4gQW5kIHdoeSBpdCB3YXMgbm90IGxvb2tlZCBhdCB0aGF0IHRpbWU/IA0KPiA+ID4g
PiANCj4gPiA+ID4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDlhpnkuo4gMjAxMi0xMi0wNCAwMToz
MDo1NToNCj4gPiA+ID4gDQo+ID4gPiA+ID4gQWN0dWFsbHksIEkgdGhpbmsgaXQgaXMgYSBnb29k
IHRpbWUgdG8gc3RhcnQgbG9va2luZyBhdCB0aGUgDQpyZXNvdXJzZQ0KPiA+ID4gPiA+IG93bmVy
IGlzc3VpbmcgYXNzZXJ0aW9uc0AgKEludGVyZXN0aW5nbHkgZW5vdWdoLCBIdWktTGFuIGhhZCAN
CmJyb3VnaHQNCj4gPiA+ID4gPiB0aGlzIHVwIGEgY291cGxlIG9mIHllYXJzIGFnby4pDQo+ID4g
PiA+ID4gDQo+ID4gPiA+ID4gSWdvcg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IE9uIDEyLzMvMjAx
MiAzOjU4IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6IA0KPiA+ID4gPiA+IEkgc3VwcG9zZSwgeWVz
LiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhhdCBhbGwgdGhlIHRpbWUuIA0KPiA+ID4gPiA+IFdo
ZXRoZXIgaXQgaXMgb3Igbm90LCBpZiBpdCBpcyBzdGlsbCBvaywgaXQgbWlnaHQgYmUgYmV0dGVy
IHRvIA0KPiA+ID4gY2xhcmlmeSBpdC4gDQo+ID4gPiA+ID4gV29yZCBsaWtlICJ0aGlyZCBwYXJ0
eSIgdGVuZHMgdG8gYmUgYSBiaXQgb2YgcHJvYmxlbSB3aXRob3V0IA0KPiA+ID4gPiBjbGVhcmx5
ZGVmaW5pbmcuIA0KPiA+ID4gPiA+IEkgaGFkIHNpbWlsYXIgZXhwZXJpZW5jZSBpbiBvdGhlciBm
b3JhLiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBOYXQgDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4g
U2VudCBmcm9tIGlQYWQgDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gMjAxMi8xMi8wMyAwOjUy44CB
Inpob3Uuc3VqaW5nQHp0ZS5jb20uY24iIA0KPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IOOBrg0K
PiA+ID4gPiA+IOODoeODg+OCu+ODvOOCuDoNCj4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+
ID4gY291bGQgYmUgUmVzb3VyY2Ugb3duZXI/IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+
ID4gPiANCj4gPiA+ID4gPiAiVHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykiIA0K
PGhhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20+IA0KPiA+ID4gPiA+IOWPkeS7tuS6ujogIG9hdXRo
LWJvdW5jZXNAaWV0Zi5vcmcgDQo+ID4gPiA+ID4gMjAxMi0xMi0wMyAxNjo0OSANCj4gPiA+ID4g
PiANCj4gPiA+ID4gPiDmlLbku7bkurogDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gImV4dCBOYXQg
U2FraW11cmEiIDxzYWtpbXVyYUBnbWFpbC5jb20+LCAiQnJpYW4gQ2FtcGJlbGwiIDwNCj4gPiA+
ID4gPiBiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4sICJvYXV0aCIgPG9hdXRoQGlldGYub3Jn
PiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiDmioTpgIEgDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4g
5Li76aKYIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IFJlOiBbT0FVVEgtV0ddIEFzc2VydGlvbiBG
cmFtZXdvcmsgLSBXaHkgZG9lcyBpc3N1ZXIgaGF2ZSB0byBiZSAgDQogDQo+ID4gPiA+ID4gZWl0
aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPyANCj4gPiA+ID4g
PiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBIaSBOYXQs
IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IFRoZSBjdXJyZW50IHRleHQgZXNzZW50aWFsbHkgc2F5
cyB0aGF0IHRoZSBhc3NlcnRpb24gY2FuIGVpdGhlciANCmJlIA0KPiA+ID4gPiA+IGNyZWF0ZWQg
YnkgdGhlIGNsaWVudCAoaW4gd2hpY2ggY2FzZSBpdCBpcyBzZWxmLXNpZ25lZCkgb3IgaXQgDQpj
YW4gYmUNCj4gPiA+ID4gPiBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5ICh3aGljaCBpcyB0
aGVuIGNhbGxlZCB0aGUgdGhpcmQgDQpwYXJ0eSANCj4gPiA+ID4gPiB0b2tlbiBzZXJ2aWNlKS4g
U28sIHRoaXMgdGhpcmQgcGFydHkgY291bGQgYmUgdGhlIA0KPiBhdXRob3JpemF0aW9uIHNlcnZl
ci4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gQ2lhbw0KPiA+ID4gPiA+IEhhbm5lcyANCj4gPiA+
ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3Jn
IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10gDQo+ID4gT24gQmVoYWxmIE9mIA0KPiA+
ID4gPiA+IGV4dCBOYXQgU2FraW11cmENCj4gPiA+ID4gPiBTZW50OiBNb25kYXksIERlY2VtYmVy
IDAzLCAyMDEyIDEwOjM1IEFNDQo+ID4gPiA+ID4gVG86IEJyaWFuIENhbXBiZWxsOyBvYXV0aA0K
PiA+ID4gPiA+IFN1YmplY3Q6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBk
b2VzIGlzc3VlciBoYXZlIA0KdG8gYmUNCj4gPiA+ID4gPiBlaXRoZXIgdGhlIGNsaWVudCBvciBh
IHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEhpIEJy
aWFuLCANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBUaGUgYXNzZXJ0aW9uIGZy
YW1ld29yayBkZWZpbmVzIHRoZSBJc3N1ZXIgYXM6IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ICAg
IElzc3VlciAgVGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVk
IHRoZSANCj4gPiA+ID4gPiAgICAgICBhc3NlcnRpb24uICBHZW5lcmFsbHkgdGhpcyBpcyB0aGUg
ZW50aXR5IHRoYXQgaG9sZHMgdGhlIA0Ka2V5IA0KPiA+ID4gPiA+ICAgICAgIG1hdGVyaWFsIHVz
ZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gIFRoZSBpc3N1ZXIgDQo+IG1heWJlIGVpdGhl
ciANCj4gPiA+ID4gPiAgICAgICBhbiBPQXV0aCBjbGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUg
c2VsZi1pc3N1ZWQpIG9yIGEgDQo+ID4gdGhpcmQgcGFydHkgDQo+ID4gPiA+ID4gICAgICAgdG9r
ZW4gc2VydmljZS4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gSSB3YXMgd29uZGVyaW5nIHdoeSBp
dCBoYXMgdG8gYmUgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCANCnBhcnR5IA0KPiA+ID4g
PiA+IHRva2VuIHNlcnZpY2UuIA0KPiA+ID4gPiA+IENvbmNlcHR1YWxseSwgaXQgY291bGQgYmUg
YW55IHRva2VuIHNlcnZpY2UgKGZ1bmN0aW9uYWxpdHkpIA0KPiA+ID4gPiByZXNpZGluZ2luIGFu
eSBvZiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiB0aGUgc3Rha2Vob2xkZXJzIChSZXNvdXJjZSBP
d25lciwgT0F1dGggQ2xpZW50LCBBdXRob3JpemF0aW9uIA0KPiA+IFNlcnZlciwgb3IgDQo+ID4g
PiA+ID4gYSB0aGlyZCBwYXJ0eSkuIA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+
IEkgd291bGQgYXBwcmVjaWF0ZSBpZiB5b3UgY291bGQgY2xhcmlmeSB3aHkgaXMgdGhlIGNhc2Uu
IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEJlc3QsIA0KPiA+ID4gPiA+IA0K
PiA+ID4gPiA+IC0tIA0KPiA+ID4gPiA+IE5hdCBTYWtpbXVyYSAoPW5hdCkgDQo+ID4gPiA+ID4g
Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQo+ID4gPiA+ID4gaHR0cDovL25hdC5zYWtpbXVy
YS5vcmcvDQo+ID4gPiA+ID4gQF9uYXRfZW4gDQo+ID4gPiA+ID4gIF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gT0F1dGggbWFpbGluZyBs
aXN0DQo+ID4gPiA+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4g
PiA+IA0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4gPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gT0F1dGhAaWV0
Zi5vcmcNCj4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoDQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiA+ID4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBPQXV0aEBpZXRm
Lm9yZw0KPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiA+IE9BdXRoQGlldGYub3JnDQo+
ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGggDQo+ID4g
DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiANCj4gPiANCj4gPiANCj4gPiAN
Cj4gPiAtLSANCj4gPiBOYXQgU2FraW11cmEgKD1uYXQpIA0KPiA+IENoYWlybWFuLCBPcGVuSUQg
Rm91bmRhdGlvbg0KPiA+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiA+IEBfbmF0X2VuIA0K
PiA+IA0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gDQo+IA0KPiA+
IA0KPiA+IA0KPiANCj4gPiANCj4gPiAtLSANCj4gPiBOYXQgU2FraW11cmEgKD1uYXQpIA0KPiA+
IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPiA+IGh0dHA6Ly9uYXQuc2FraW11cmEub3Jn
Lw0KPiA+IEBfbmF0X2VuIA0KPiA+IA0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0
Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIA0K
PiA+IA0KPiA+IA0KPiA+IEV2ZSBNYWxlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICBodHRwOi8vd3d3LnhtbGdycmwuY29tL2Jsb2cNCj4gPiArMSA0MjUgMzQ1IDY3NTYgICAgICAg
ICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy50d2l0dGVyLmNvbS94bWxncnJsDQo+IA0KPiA+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1
dGggbWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+IA0KDQo+IA0KPiAtLSANCj4gTmF0IFNha2lt
dXJhICg9bmF0KQ0KPiBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCj4gaHR0cDovL25hdC5z
YWtpbXVyYS5vcmcvDQo+IEBfbmF0X2VuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRo
QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN
Cg0K
--=_alternative 0001B0F648257ACD_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5CcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxs
QHBpbmdpZGVudGl0eS5jb20mZ3Q7DQrlhpnkuo4gMjAxMi0xMi0wNyAwNzowMzozODo8YnI+DQo8
YnI+DQomZ3Q7IEEgcXVlc3Rpb24gZm9yIHRoZSBjaGFpcnMgb3Igb3RoZXJzIG1vcmUgdmVyc2Vk
IGluIHRoZSB3b3JraW5ncyBvZg0KPGJyPg0KJmd0OyB0aGUgSUVURiAtIGlzIHRoaXMgZG9jdW1l
bnQgZXZlbiBpbiBhIHBsYWNlIHdoZXJlIGNoYW5nZXMgY2FuIGJlIDxicj4NCiZndDsgbWFkZT8g
VGhlIFNoZXBoZXJkIFdyaXRlLVVwIGZvciB0aGUgZG9jdW1lbnQgd2FzIHJlY2VudGx5IHNlbnQg
dG8NCjxicj4NCiZndDsgdGhlIElFU0cgU2VjcmV0YXJ5IGFuZCBJJ20gaG9uZXN0bHkgbm90IHN1
cmUgd2hhdCB0aGUgcHJvdG9jb2wgaXMNCjxicj4NCiZndDsgZm9yIG1ha2luZyBjaGFuZ2VzIGF0
IHRoaXMgcG9pbnQuPGJyPg0KT3Igd2UgY2FuIHN0YXJ0IGEgbmV3IGRyYWZ0IGV4dGVuZGluZyBh
bmQgY2xhcmlmeWluZyB0aGUgYXNzZXJ0aW9uIGRvY3VtZW50LDwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPTI+bW9yZSB1c2UgY2FzZXMgY291bGQgYmUgaW1wbGVtZW50ZWQgYnkgYXNz
ZXJ0aW9uIG1heQ0KYmUgaW5jbHVkZWQsIGFuZCBvdGhlciB0aGluZ3MuLi48L2ZvbnQ+PC90dD4N
Cjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQo8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgT24gVGh1LCBEZWMgNiwgMjAx
MiBhdCAxMjo1MCBBTSwgTmF0IFNha2ltdXJhDQombHQ7c2FraW11cmFAZ21haWwuY29tJmd0OyB3
cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSGVyZSwgSSB0aGlu
ayBpdCBpcyBiZXR0ZXIgdG8gZGlmZmVyZW50aWF0ZSB0aGUNCmVudGl0eSBhbmQgZnVuY3Rpb24v
cm9sZS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg
QXV0aG9yaXphdGlvbiBTZXJ2ZXIgaW4gT0F1dGggaXMgJnF1b3Q7a2luZCBvZiZxdW90OyBlbnRp
dHkuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJdHMgZnVuY3Rpb24g
YWN0dWFsbHkgaXMgc3BsaXQgaW50byB0d28sIG9yIGluDQptb3N0IGNhc2VzIHRocmVlLiA8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAxLiBBdXRoZW50
aWNhdGlvbiBFbmRwb2ludDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAy
LiBBdXRob3JpemF0aW9uIEVuZHBvaW50PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDMuIFRva2VuIEVuZHBvaW50PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgTm93LCAmcXVvdDtBc3NlcnRpb24gVmVyaWZpZXImcXVvdDsgaXMg
YSBmdW5jdGlvbi9yb2xlLiBJdCBpcyBwZXJmb3JtZWQNCmJ5IDMuIDxicj4NCiZndDsgVG9rZW4g
RW5kcG9pbnQuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBJdCBjaGVj
ayB0aGUgdmFsaWRpdHksIGFuZCBpc3N1ZXMgYWNjZXNzIHRva2Vucw0KKHdoaWNoIGluIHR1cm4g
Y2FuIDxicj4NCiZndDsgYmUgYW5vdGhlciBhc3NlcnRpb24gYnkgdGhlIHdheS4pPC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQXV0aG9yaXphdGlvbiBF
bmRwb2ludCBpcyBhbm90aGVyIGZ1bmN0aW9uLiBJdCBjYW4gYmUgbG9jYXRlZCA8YnI+DQomZ3Q7
IGFueXdoZXJlLiBJbiB5b3VyIGNhc2UsIGl0IGlzIGxvY2F0ZWQgaW4gd2hhdCB5b3UgY2FsbCBh
cyBSZXNvdXJjZQ0KPGJyPg0KJmd0OyBPd25lciAoQnJvd3NlciBwbHVnLWluPykgSW4gbXkgU2Vs
Zi1Jc3N1ZWQgSWRQIGNhc2UsIGl0IGlzIGlzc3VlZA0KYnk8YnI+DQomZ3Q7IHRoZSBBcHAgaW4g
dGhlIHBob25lIHdoaWNoIGlzIGNhbGxlZCBieSB0aGUgY3VzdG9tIHNjaGVtYS4gPC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhpcyBpcyB0aGUgcmVh
c29uIHdoeSBJIGNvbnN0YW50bHkgZ3J1bWJsZSB0aGF0IGl0IGlzIGJldHRlciB0byA8YnI+DQom
Z3Q7IHNwZWFrIGluIHRlcm1zIG9mIGZ1bmN0aW9ucyByYXRoZXIgdGhhbiBlbnRpdGllcy4gPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEZ1bmN0aW9ucyBtYXkgcmVzaWRl
IGluIGFueSBlbnRpdHksIGFuZCBpZiB3ZQ0KdGFsayBvbmx5IGluIHRlcm1zIG9mIDxicj4NCiZn
dDsgdGhlIGVudGl0aWVzLCB0aGUgY29tYmluYXRpb24gd2lsbCBleHBsb2RlLiA8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBOYXQ8L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBPbiBUaHUsIERlYyA2LCAyMDEy
IGF0IDk6NDYgQU0sICZsdDt6aG91LnN1amluZ0B6dGUuY29tLmNuJmd0OyB3cm90ZTo8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBBcyBJIHVuZGVyc3Rh
bmQsIFJPPWlzc3VlciAmbmJzcDtkb2VzIG5vdCBtZWFuIFJPPUFTLiA8YnI+DQomZ3Q7IFJPIGFz
IGFuIGlzc3VlciBnZW5lcmF0ZXMgYXNzZXJ0aW9uIChpZiB0aGUgYXNzZXJ0aW9uIGlzIHNpbWls
YXIgdG8NCjxicj4NCiZndDsgZGVsZWdhdGlvbiBzdGF0ZW1lbnQgaW4gbXkgdXNlIGNhc2VzKSwg
PGJyPg0KJmd0OyBBUyBhcyBhbiBhc3NlcnRpb24gdmVyaWZpZXIgcmVjZWl2ZXMgdGhlIGFzc2Vy
dGlvbiBhbmQgY2hlY2sgaXRzIHZhbGlkaXR5Lg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgPGJyPg0KJmd0OyBvYXV0aC1ib3VuY2VzQGlldGYub3JnIOWGmeS6jiAyMDEyLTEyLTA2
IDAxOjM1OjEwOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom
Z3Q7IDxicj4NCiZndDsgJmd0OyBKdXN0IGNoZWNraW5nIHRoYXQgSSB1bmRlcnN0YW5kOiBJZiB0
aGUgUk8gPT0gdGhlIGlzc3VlciwgdGhlbg0KdGhlIDxicj4NCiZndDsgJmd0OyBSTyA9PSB0aGUg
QVMsIHJpZ2h0PyBKdXN0IGFzIGluIE5hdCdzIGV4YW1wbGUsIHRoZSB1c2VyIChvciBhdA0KbGVh
c3Q8YnI+DQomZ3Q7ICZndDsgdGhlIGRldmljZSBwcmVzZW50aW5nIGEgdXNlciBhZ2VudCB0byB0
aGVtKSA9PSB0aGUgSWRQPyBDb2xvY2F0aW5nDQo8YnI+DQomZ3Q7ICZndDsgdGhlIFJPIGFuZCBB
UyBmdW5jdGlvbnMgc2hvdWxkbid0IGJlIHByZWNsdWRlZCwgYnV0IEkgd291bGQgYmUNCjxicj4N
CiZndDsgJmd0OyBhd2Z1bGx5IGNvbmZ1c2VkIGlmIHRoZXJlIHdlcmUgYW4gUk8vaXNzdWVyIGlu
IHRoZSBwaWN0dXJlIGFuZA0KPGJyPg0KJmd0OyAmZ3Q7ICphbHNvKiBhbiBBUyB0aGF0ICpkb2Vz
bid0KiBpc3N1ZSBhc3NlcnRpb25zLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEV2ZSA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IE9uIDUgRGVjIDIwMTIsIGF0IDk6MTMgQU0sIE5hdCBTYWtpbXVyYSAm
bHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgSXQgaXMgbm90IE9BdXRoLCBidXQgQXVzdHJpYW4gZUlEIHN5c3RlbSBpcyBhbiBl
eGFtcGxlIG9mIFJPDQphcyBhbiA8YnI+DQomZ3Q7ICZndDsgYXNzZXJ0aW9uIGlzc3VlciBwYXR0
ZXJuLiBUaGV5IGhhdmUgdGhlaXIgb3duIFNBTUwgSWRQIG9uIHRoZWlyDQpQQyA8YnI+DQomZ3Q7
ICZndDsgKGF0IGxlYXN0IGEgZmV3IHllYXJzIGFnbykgYW5kIGNvbWJpbmVkIHdpdGggdGhlIHF1
YWxpZmllZCBjZXJ0cw0KaW4gPGJyPg0KJmd0OyAmZ3Q7IHRoZSB1c2VyJ3Mgc21hcnQgY2FyZCBh
bmQgYW5vdGhlciBmaWxlLCBjcmVhdGVzIGEgU0FNTCBhc3NlcnRpb24NCjxicj4NCiZndDsgJmd0
OyB3aXRoIHNlY3RvcmFsIGlkZW50aWZpZXIgYW5kIHN1cHBseSBpdCB0byBvdGhlciBzeXN0ZW1z
LiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE5hdDxicj4NCiZndDsgPGJyPg0KJmd0
OyAmZ3Q7IE9uIFdlZCwgRGVjIDUsIDIwMTIgYXQgMTE6MDUgUE0sIEJyaWFuIENhbXBiZWxsICZs
dDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxicj4NCiZndDsgJmd0OyAmZ3Q7IHdyb3RlOiA8
YnI+DQomZ3Q7ICZndDsgSSBzYXkgdGhhdCBpdCdzIG9ubHkgdGhlb3JldGljYWwgYmVjYXVzZSBJ
IGRvbid0IGJlbGlldmUgdGhlcmUNCmFyZSA8YnI+DQomZ3Q7ICZndDsgYW55IGFjdHVhbCBkZXBs
b3ltZW50cyBzdXBwb3J0aW5nLCBvciBwbGFubmluZyBvbiBzdXBwb3J0aW5nLA0KUk8gYXMgPGJy
Pg0KJmd0OyAmZ3Q7IGFuIGFzc2VydGlvbiBpc3N1ZXIuIDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7IDxicj4NCiZndDsgJmd0OyBPbiBUdWUsIERlYyA0LCAyMDEyIGF0IDU6MzkgUE0sICZsdDt6
aG91LnN1amluZ0B6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgV2h5IFJPIGFzIGFuIGlzc3VlciBpcyBvbmx5IHRoZW9yZXRpY2FsIHRvZGF5PyA8
YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDsgPGJyPg0K
Jmd0OyAmZ3Q7IDIwMTItMTItMDQgMjM6NDEgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyDmlLbku7bkurogPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBOYXQgU2FraW11cmEg
Jmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyDmioTpgIEgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyB6aG91LnN1amluZ0B6dGUu
Y29tLmNuLCAmcXVvdDtvYXV0aEBpZXRmLm9yZyZxdW90OyAmbHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7
DQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IOS4u+mimCA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IFJlOiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkg
ZG9lcyBpc3N1ZXIgaGF2ZSB0bw0KYmUgPGJyPg0KJmd0OyAmZ3Q7IGVpdGhlciB0aGUgY2xpZW50
IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT8gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm
b250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSBpbnRlbnQgd2FzIGRlZmluaXRlbHkgbm90
IHRvIGNvbnN0cmFpbiB3aG8vd2hhdCBjb3VsZCBiZQ0KdGhlIDxicj4NCiZndDsgJmd0OyBpc3N1
ZXIuICZuYnNwO0J1dCBhbHNvIHRyeSB0byBwcm92aWRlIDxicj4NCiZndDsgJmd0OyBzb21lIGd1
aWRhbmNlIGFyb3VuZCB0aGUgY29tbW9uIGNhc2VzIHRoYXQgYXJlIGFjdHVhbGx5IGJlaW5nDQo8
YnI+DQomZ3Q7ICZndDsgZGVwbG95ZWQgbm93LCB3aGljaCBhcmUgdGhlIGNsaWVudCBzZWxmLWlz
c3VlZCBhbmQgU1RTIHZhcmlhbnRzLg0KPGJyPg0KJmd0OyAmZ3Q7IFJlc291cmNlIG93bmVyIGFz
IGFuIGlzc3VlciBpcyBhbiBpbnRlcmVzdGluZyBjYXNlIGJ1dCBzZWVtcw0KbW9zdGx5IDxicj4N
CiZndDsgJmd0OyB0aGVvcmV0aWNhbCBhdCB0aGlzIHBvaW50Ljxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgSSBmZWVsIGxpa2UgbWVudGlvbmluZyB0aGUgcmVzb3VyY2Ugb3duZXIgdGhl
cmUgaW4gwqc1LjEgd291bGQNCmNhdXNlIDxicj4NCiZndDsgJmd0OyBtb3JlIGNvbmZ1c2lvbiB0
aGFuIGFueXRoaW5nIGVsc2UuIEknZCBwcmVmZXIgdG8ganVzdCBzdHJpa2UNCnRoZSA8YnI+DQom
Z3Q7ICZndDsgd2hvbGUgc2VudGVuY2UgaW4gcXVlc3Rpb24gYW5kIG1heWJlIGFkZCBzb21lIGFk
ZGl0aW9uYWwgdGV4dA0KdG8gwqczIDxicj4NCiZndDsgJmd0OyB0aGF0IGNsYXJpZmllcyB0aGF0
IHRoZSBpc3N1ZXIgY2FuIHJlYWxseSBiZSBhbnkgZW50aXR5LCBpZiBmb2xrcw0KPGJyPg0KJmd0
OyAmZ3Q7IHRoaW5rIGEgY2hhbmdlIGlzIG5lZWRlZCBoZXJlPyA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gTW9uLCBEZWMg
MywgMjAxMiBhdCA5OjIwIFBNLCBOYXQgU2FraW11cmEgJmx0O3Nha2ltdXJhQGdtYWlsLmNvbSZn
dDsNCndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgQWN0dWFsbHksICZxdW90O1RoZSBpc3N1ZXIgbWF5
IGJlIGVpdGhlciA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYW4gT0F1dGgg
Y2xpZW50ICh3aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYtaXNzdWVkKQ0Kb3IgYW55IG90aGVyPGJy
Pg0KJmd0OyAmZ3Q7IGVudGl0eSwgZS5nLiwgJm5ic3A7YSB0aGlyZCBwYXJ0eSA8YnI+DQomZ3Q7
ICZndDsgdG9rZW4gc2VydmljZSwgcmVzb3VyY2Ugb3duZXIuICZxdW90OyAmbmJzcDtpcyBub3Qg
cmVhbGx5IGNsZWFuLg0KPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBPQXV0aCBjbGll
bnQgaXMganVzdCBhbm90aGVyIGV4YW1wbGUgb2YgYW4gaXNzdWVyLiA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IFNvLCBwZXJoYXBzIHRoZSBzZW50ZW5jZSBjb3VsZCBiZTogPGJyPg0K
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmcXVvdDtFeGFtcGxlIG9mIGlzc3VlcnMgaW5jbHVk
ZSBhbiBPQXV0aCBjbGllbnQsIHJlc291cmNlIG93bmVyLA0KYW4gPGJyPg0KJmd0OyAmZ3Q7IGlu
ZGVwZW5kZW50IHRoaXJkIHBhcnR5LiZxdW90OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IFNvLCB0aGUgY2xhdXNlIGJlY29tZXM6IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgJm5ic3A7SXNzdWVyICZuYnNwO1RoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIGVudGl0
eSB0aGF0DQppc3N1ZWQgdGhlIDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2Fz
c2VydGlvbi4gJm5ic3A7R2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVudGl0eQ0KdGhhdCBob2xkcyB0
aGUga2V5IDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO21hdGVyaWFsIHVzZWQg
dG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4NCiZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgRXhhbXBsZSBvZiBpc3N1ZXJzIGluY2x1ZGUgYW4gT0F1dGggY2xpZW50
LA0KcmVzb3VyY2Ugb3duZXIsIGFuPGJyPg0KJmd0OyAmZ3Q7IGluZGVwZW5kZW50IHRoaXJkIHBh
cnR5LiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE5hdCA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IE5hdCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIFR1
ZSwgRGVjIDQsIDIwMTIgYXQgMTE6NDAgQU0sICZsdDt6aG91LnN1amluZ0B6dGUuY29tLmNuJmd0
Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyBDaHVjayBNb3J0aW1vcmUgJmx0O2Ntb3J0aW1vcmVAc2FsZXNmb3Jj
ZS5jb20mZ3Q7IOWGmeS6jiAyMDEyLTEyLTA0DQoxMDoyNjo1MDogPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBQbGVhc2UgZmVlbCBmcmVlIHRvIHN1
Z2dlc3QgYmV0dGVyIGxhbmd1YWdlLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSXNzdWVyIHNpbXBseSBhbGxvd3MgdGhlIHRva2VuIHNl
cnZpY2UgdG8ga25vdyB3aG8gY3JlYXRlZA0KdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFzc2Vy
dGlvbiwgc28gaXQgY2FuIGxvb2sgdGhlbSB1cCBhbmQgc2VlIGlmIHRoZXkncmUgdHJ1c3RlZC4N
CiZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgRWZmZWN0aXZlbHkgdGhlIHNhbWUg
YXMgYW4gSXNzdWVyIGluIFNBTUwuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgYSBj
b25mbGljdCA6ICZxdW90O1RoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVy
JnF1b3Q7DQppbiA8YnI+DQomZ3Q7ICZndDsgYXNzZXJ0aW9uIGRvY3VtZW50LiA8YnI+DQomZ3Q7
ICZndDsgd2hpbGUgeW91IHNhaWQgJnF1b3Q7dG9rZW4gc2VydmljZSBrbm93IHdobyBjcmVhdGVk
IHRoZSBhc3NlcnRpb24mcXVvdDsNCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSB3
b25kZXIgaWYgdGhlIGZvbGxvd2luZyB0ZXh0IGlzIGFjY2VwdGFibGU6IDxicj4NCiZndDsgJmd0
OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO0lzc3VlciAmbmJzcDtUaGUgdW5pcXVlIGlk
ZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdA0KaXNzdWVkIHRoZSA8YnI+DQomZ3Q7ICZndDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDthc3NlcnRpb24uICZuYnNwO0dlbmVyYWxseSB0aGlzIGlzIHRo
ZSBlbnRpdHkNCnRoYXQgaG9sZHMgdGhlIGtleSA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDttYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uDQombmJzcDtU
aGUgaXNzdWVyIG1heSBiZSBlaXRoZXIgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7IGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3VlZCkNCm9y
IGFueSBvdGhlcjxicj4NCiZndDsgJmd0OyBlbnRpdHksIGUuZy4sICZuYnNwO2EgdGhpcmQgcGFy
dHkgPGJyPg0KJmd0OyAmZ3Q7IHRva2VuIHNlcnZpY2UsIHJlc291cmNlIG93bmVyLiA8YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA2LjMuICZuYnNwO0NsaWVu
dCBBY3Rpbmcgb24gQmVoYWxmIG9mIGEgVXNlciA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IFRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbiBNVVNUIGlkZW50aWZ5IHRoZSBlbnRpdHkg
dGhhdCBpc3N1ZWQNCjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBhc3Nl
cnRpb24gYXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9yaXphdGlvbg0KU2VydmVyLiAmbmJzcDtJ
ZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXNzZXJ0aW9uIGlzIHNl
bGYtaXNzdWVkLCB0aGUgSXNzdWVyIFNIT1VMRA0KYmUgdGhlICZxdW90O2NsaWVudF9pZCZxdW90
Oy4gPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SWYgdGhlIGFzc2VydGlvbiB3
YXMgaXNzdWVkIGJ5IGEgU2VjdXJpdHkNClRva2VuIFNlcnZpY2UgKFNUUyksIHRoZSA8YnI+DQom
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSBT
VFMgYXMgcmVjb2duaXplZA0KYnkgdGhlIEF1dGhvcml6YXRpb24gPGJyPg0KJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7U2VydmVyLklmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSB0
aGUNCnJlc291cmNlIG93bmVyLCB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7SXNzdWVyIFNIT1VMRCBpZGVudGlmeSB0aGUgcmVzb3VyY2Ugb3duZXINCmFzIHJlY29nbml6
ZWQgYnkgdGhlIDxicj4NCiZndDsgJmd0OyBBdXRob3JpemF0aW9uIDxicj4NCiZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwO1NlcnZlci4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IC1jbW9ydCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyBPbiBEZWMgMywgMjAxMiwgYXQgNjoyMyBQTSwgJmx0O3pob3Uu
c3VqaW5nQHp0ZS5jb20uY24mZ3Q7DQp3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT2J2aW91c2x5LCBpdCBpcyBub3Qg
c28gY2xlYXIgZnJvbSB0aGUgbGFuZ3VhZ2UgdGhlcmUuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IENodWNrIE1vcnRpbW9yZSAm
bHQ7Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbSZndDsg5YaZ5LqODQoyMDEyLTEyLTA0IDEwOjE3
OjEyOjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlcmUn
cyBubyByZWFzb24gd2h5IGl0IGNhbid0IGJlIHJlc291cmNlIG93bmVyIHRvZGF5Lg0KJm5ic3A7
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiBE
ZWMgMywgMjAxMiwgYXQgNjowNiBQTSwgJmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7DQom
bHQ7emhvdS48YnI+DQomZ3Q7ICZndDsgc3VqaW5nQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgd3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICsxLiA8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7IEFuZCB3aHkgaXQgd2FzIG5vdCBsb29rZWQgYXQgdGhhdCB0aW1lPyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgb2F1dGgt
Ym91bmNlc0BpZXRmLm9yZyDlhpnkuo4gMjAxMi0xMi0wNCAwMTozMDo1NTo8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgSSB0
aGluayBpdCBpcyBhIGdvb2QgdGltZSB0byBzdGFydCBsb29raW5nDQphdCB0aGUgcmVzb3Vyc2U8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgb3duZXIgaXNzdWluZyBhc3NlcnRpb25zQCAo
SW50ZXJlc3RpbmdseSBlbm91Z2gsDQpIdWktTGFuIGhhZCBicm91Z2h0PGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7IHRoaXMgdXAgYSBjb3VwbGUgb2YgeWVhcnMgYWdvLik8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IElnb3I8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7IE9uIDEyLzMvMjAxMiAzOjU4IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyBJIHN1cHBvc2UsIHllcy4gSSB3YXMgcmVhZGluZyBpdCBsaWtl
IHRoYXQgYWxsDQp0aGUgdGltZS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFdoZXRo
ZXIgaXQgaXMgb3Igbm90LCBpZiBpdCBpcyBzdGlsbCBvaywgaXQgbWlnaHQNCmJlIGJldHRlciB0
byA8YnI+DQomZ3Q7ICZndDsgJmd0OyBjbGFyaWZ5IGl0LiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgV29yZCBsaWtlICZxdW90O3RoaXJkIHBhcnR5JnF1b3Q7IHRlbmRzIHRvIGJlDQph
IGJpdCBvZiBwcm9ibGVtIHdpdGhvdXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBjbGVhcmx5
ZGVmaW5pbmcuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBJIGhhZCBzaW1pbGFyIGV4
cGVyaWVuY2UgaW4gb3RoZXIgZm9yYS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBOYXQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBTZW50IGZyb20gaVBhZCA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
IDIwMTIvMTIvMDMgMDo1MuOAgSZxdW90O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mcXVvdDsNCiZs
dDt6aG91LnN1amluZ0B6dGUuY29tLmNuJmd0OyDjga48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZndDsg44Oh44OD44K744O844K4Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBjb3Vs
ZCBiZSBSZXNvdXJjZSBvd25lcj8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmcXVvdDtUc2Nob2ZlbmlnLCBIYW5uZXMgKE5TTiAt
IEZJL0VzcG9vKSZxdW90Ow0KJmx0O2hhbm5lcy50c2Nob2ZlbmlnQG5zbi5jb20mZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyDlj5Hku7bkuro6ICZuYnNwO29hdXRoLWJvdW5jZXNA
aWV0Zi5vcmcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDIwMTItMTItMDMgMTY6NDkg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyDmlLbku7bkurogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmcXVvdDtleHQgTmF0IFNha2ltdXJhJnF1b3Q7ICZsdDtzYWtp
bXVyYUBnbWFpbC5jb20mZ3Q7LA0KJnF1b3Q7QnJpYW4gQ2FtcGJlbGwmcXVvdDsgJmx0Ozxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDss
ICZxdW90O29hdXRoJnF1b3Q7DQombHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7IDxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg5oqE6YCBIDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsg5Li76aKYIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgUmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBk
b2VzDQppc3N1ZXIgaGF2ZSB0byBiZSAmbmJzcDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgJmd0OyBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZp
Y2U/DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEhpIE5hdCwgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgVGhlIGN1cnJlbnQgdGV4dCBlc3NlbnRpYWxseSBzYXlzIHRoYXQgdGhlIGFzc2Vy
dGlvbg0KY2FuIGVpdGhlciBiZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgY3JlYXRl
ZCBieSB0aGUgY2xpZW50IChpbiB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2lnbmVkKQ0Kb3IgaXQg
Y2FuIGJlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNyZWF0ZWQgYnkgc29tZSBvdGhl
ciBlbnRpdHkgKHdoaWNoIGlzIHRoZW4gY2FsbGVkDQp0aGUgdGhpcmQgcGFydHkgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRva2VuIHNlcnZpY2UpLiBTbywgdGhpcyB0aGlyZCBwYXJ0
eSBjb3VsZCBiZQ0KdGhlIDxicj4NCiZndDsgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuIDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7IENpYW88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSGFubmVzIDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgRnJvbTogb2F1dGgtYm91bmNl
c0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddDQo8YnI+DQomZ3Q7ICZn
dDsgT24gQmVoYWxmIE9mIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBleHQgTmF0IFNh
a2ltdXJhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQ6IE1vbmRheSwgRGVjZW1i
ZXIgMDMsIDIwMTIgMTA6MzUgQU08YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVG86IEJy
aWFuIENhbXBiZWxsOyBvYXV0aDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBTdWJqZWN0
OiBbT0FVVEgtV0ddIEFzc2VydGlvbiBGcmFtZXdvcmsgLSBXaHkNCmRvZXMgaXNzdWVyIGhhdmUg
dG8gYmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgZWl0aGVyIHRoZSBjbGllbnQgb3Ig
YSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPw0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSGkgQnJpYW4sIDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIGFzc2VydGlv
biBmcmFtZXdvcmsgZGVmaW5lcyB0aGUgSXNzdWVyIGFzOg0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZu
YnNwO0lzc3VlciAmbmJzcDtUaGUgdW5pcXVlIGlkZW50aWZpZXINCmZvciB0aGUgZW50aXR5IHRo
YXQgaXNzdWVkIHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgYXNzZXJ0aW9uLiAmbmJzcDtHZW5lcmFsbHkNCnRoaXMgaXMgdGhlIGVudGl0eSB0
aGF0IGhvbGRzIHRoZSBrZXkgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbWF0ZXJpYWwNCnVzZWQg
dG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gJm5ic3A7VGhlIGlzc3VlciA8YnI+DQomZ3Q7IG1h
eWJlIGVpdGhlciA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhbiBPQXV0aA0KY2xpZW50ICh3aGVu
IGFzc2VydGlvbnMgYXJlIHNlbGYtaXNzdWVkKSBvciBhIDxicj4NCiZndDsgJmd0OyB0aGlyZCBw
YXJ0eSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
dG9rZW4gc2VydmljZS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8g
YmUgZWl0aGVyIHRoZSBjbGllbnQNCm9yIGEgdGhpcmQgcGFydHkgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IHRva2VuIHNlcnZpY2UuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyBDb25jZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBzZXJ2aWNlIChmdW5jdGlvbmFs
aXR5KQ0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyByZXNpZGluZ2luIGFueSBvZiA8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyB0aGUgc3Rha2Vob2xkZXJzIChSZXNvdXJjZSBPd25lciwgT0F1dGggQ2xpZW50LA0KQXV0
aG9yaXphdGlvbiA8YnI+DQomZ3Q7ICZndDsgU2VydmVyLCBvciA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgYSB0aGlyZCBwYXJ0eSkuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgSSB3b3VsZCBhcHByZWNpYXRlIGlmIHlvdSBjb3VsZCBjbGFy
aWZ5IHdoeSBpcw0KdGhlIGNhc2UuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz
cDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgQmVzdCwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IE5hdCBTYWtpbXVyYSAoPW5hdCkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsgQF9uYXRfZW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwO19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1
dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGggPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZn
dDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAm
Z3Q7IE5hdCBTYWtpbXVyYSAoPW5hdCkgPGJyPg0KJmd0OyAmZ3Q7IENoYWlybWFuLCBPcGVuSUQg
Rm91bmRhdGlvbjxicj4NCiZndDsgJmd0OyBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy88YnI+DQom
Z3Q7ICZndDsgQF9uYXRfZW4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQomZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IE9BdXRoQGll
dGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGg8YnI+DQomZ3Q7ICZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0tIDxicj4NCiZndDsgJmd0OyBOYXQgU2FraW11cmEg
KD1uYXQpIDxicj4NCiZndDsgJmd0OyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQom
Z3Q7ICZndDsgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPGJyPg0KJmd0OyAmZ3Q7IEBfbmF0X2Vu
IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0
PGJyPg0KJmd0OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGggPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgRXZlIE1hbGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL3d3dy54bWxncnJs
LmNvbS9ibG9nPGJyPg0KJmd0OyAmZ3Q7ICsxIDQyNSAzNDUgNjc1NiAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgaHR0cDovL3d3dy50d2l0dGVyLmNvbS94bWxncnJsPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+DQomZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IE9BdXRo
QGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0K
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgLS0gPGJy
Pg0KJmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp
emU9Mj4mZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsgaHR0cDovL25h
dC5zYWtpbXVyYS5vcmcvPGJyPg0KJmd0OyBAX25hdF9lbjwvZm9udD48L3R0Pg0KPGJyPjx0dD48
Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlz
dDxicj4NCiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+DQo8L2ZvbnQ+PC90dD4NCg==
--=_alternative 0001B0F648257ACD_=--

From hannes.tschofenig@gmx.net  Fri Dec  7 02:27:14 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3614221F86A3 for ; Fri,  7 Dec 2012 02:27:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.518
X-Spam-Level: 
X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm9PCqKtRAEc for ; Fri,  7 Dec 2012 02:27:13 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 438EA21F85FC for ; Fri,  7 Dec 2012 02:27:12 -0800 (PST)
Received: (qmail invoked by alias); 07 Dec 2012 10:27:11 -0000
Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.100]) [88.115.216.191] by mail.gmx.net (mp034) with SMTP; 07 Dec 2012 11:27:11 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19UopdZqllUfvWgh1JF3ExXWELi6XOSltU5TlkSDy uYBxQ2eqmSXR3P
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Fri, 7 Dec 2012 12:09:50 +0200
Message-Id: <529BE596-9287-4D20-A6B9-BCD5F6D12169@gmx.net>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Agenda for Conference Call - 14th December, 1pm EST
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Dec 2012 10:27:14 -0000

Hi all,=20

for the conference call next week we are planning to discuss the =
requirements from Section 5 of=20
http://tools.ietf.org/html/draft-tschofenig-oauth-security-00

We will try to explain these requirements in the context of use cases so =
that they are easier to understand.=20

We will distribute the conference bridge details within the next few =
days.

Ciao
Hannes & Derek


From dick.hardt@gmail.com  Fri Dec  7 14:17:43 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BE621F8706 for ; Fri,  7 Dec 2012 14:17:43 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBNJfFKsEknM for ; Fri,  7 Dec 2012 14:17:41 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C11AB21F8B9A for ; Fri,  7 Dec 2012 14:17:41 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id uo1so639173pbc.31 for ; Fri, 07 Dec 2012 14:17:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=A7YXC+8fpUSlfNIvPeeyw4lMweCdZSka0URzyV3ncCI=; b=07Xq6DW2iuzWfTQEmYDL4yTtA6wd8bPTF81ih+hOdj7hYEMmGKZ0dGhtMRkZ66AJq/ KJvYzwejsQGkP45RZk2fxdJ+42Bpcl8Xqz3uk8jiKougbE22WRCY7S50aAWzLdl5FbbL KH8iDr/Eb84wpwRuXFPbN25kbcDRwoAvMHK39t8QjXuq2m1126WynNMihkFggRmhK1Ad CZm2vDeV9LoGqlxm5/Erk9uOIJnH3LmwLylAPDnyb4+xe83u7rqklUy0aNL6HrqX9u3D 30525XIPPNF6WvOU4IlRAYZRJL+ffj+nrNPCfOZnZRm1cUlVeGSC4Yg9MnEGUfv0BsBk oDMg==
Received: by 10.68.248.74 with SMTP id yk10mr19536256pbc.86.1354918661522; Fri, 07 Dec 2012 14:17:41 -0800 (PST)
Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id vo8sm7329038pbc.16.2012.12.07.14.17.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2012 14:17:38 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_D14EC6BD-DA30-4233-AE6B-D88F35D06574"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Dick Hardt 
In-Reply-To: <7A54FDF5-D910-4E60-BB5F-5FB98A4B88E5@salesforce.com>
Date: Fri, 7 Dec 2012 14:17:32 -0800
Message-Id: 
References:    <59E470B10C4630419ED717AC79FCF9A92F1A9015@BLUPRD0411MB436.namprd04.prod.outlook.com> <7A54FDF5-D910-4E60-BB5F-5FB98A4B88E5@salesforce.com>
To: Chuck Mortimore 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Dec 2012 22:17:43 -0000

--Apple-Mail=_D14EC6BD-DA30-4233-AE6B-D88F35D06574
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I am developing an implementation that will exchange a JWE for an Access =
Token.

Issuer will be a third party.

On Dec 5, 2012, at 3:30 PM, Chuck Mortimore  =
wrote:

> Most of the STS style usage I've seen has been using the SAML Bearer =
Token, rather than the JWT Bearer Token flow.   The predominant JWT =
usage I've seen thus far has been for self-issued assertions.   =20
>=20
> That said, the language in question is generalized to Assertion =
use-cases rather than a specific Assertion format.
>=20
> -cmort
>=20
>=20
> On Dec 5, 2012, at 6:48 AM, Lewis Adam-CAL022 wrote:
>=20
>> Hi Brian,
>> =20
>> This is sort of my feeling on the STS as well (theoretical).  Are =
there any real-life examples of obtaining a JWT assertion from an STS =
that can be used for the assertion flow?  And if so then how is it =
obtained?  It cannot be an id_token because that is audience restricted =
to the client.  I guess it could be an access_token with a scope of =
assertion?  But I=E2=80=99ve not seen any discussion of that.  I=E2=80=99v=
e been interested in this flow for a while but the only examples I=E2=80=99=
m aware of are self-issued JWTs.  I=E2=80=99d be very interested in =
knowing real life of examples of clients obtaining a JWT assertion from =
an STS to use as a grant, and the method they use to do that.
>> =20
>> tx
>> adam
>> =20
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of Brian Campbell
>> Sent: Wednesday, December 05, 2012 8:05 AM
>> To: zhou.sujing@zte.com.cn
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to =
be either the client or a third party token service?
>> =20
>> I say that it's only theoretical because I don't believe there are =
any actual deployments supporting, or planning on supporting, RO as an =
assertion issuer.
>> =20
>>=20
>> On Tue, Dec 4, 2012 at 5:39 PM,  wrote:
>>=20
>> Why RO as an issuer is only theoretical today?=20
>>=20
>>=20
>> Brian Campbell 
>> 2012-12-04 23:41
>>=20
>> =E6=94=B6=E4=BB=B6=E4=BA=BA
>> Nat Sakimura 
>> =E6=8A=84=E9=80=81
>> zhou.sujing@zte.com.cn, "oauth@ietf.org" 
>> =E4=B8=BB=E9=A2=98
>> Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be =
either the client or a third party token service?
>> =20
>>=20
>>=20
>>=20
>> The intent was definitely not to constrain who/what could be the =
issuer.  But also try to provide=20
>> some guidance around the common cases that are actually being =
deployed now, which are the client self-issued and STS variants. =
Resource owner as an issuer is an interesting case but seems mostly =
theoretical at this point.
>>=20
>> I feel like mentioning the resource owner there in =C2=A75.1 would =
cause more confusion than anything else. I'd prefer to just strike the =
whole sentence in question and maybe add some additional text to =C2=A73 =
that clarifies that the issuer can really be any entity, if folks think =
a change is needed here?=20
>>=20
>>=20
>>=20
>> On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura  =
wrote:=20
>> Actually, "The issuer may be either=20
>>       an OAuth client (when assertions are self-issued) or any other =
entity, e.g.,  a third party=20
>> token service, resource owner. "  is not really clean.=20
>>=20
>> OAuth client is just another example of an issuer.=20
>>=20
>> So, perhaps the sentence could be:=20
>>=20
>> "Example of issuers include an OAuth client, resource owner, an =
independent third party."=20
>>=20
>> So, the clause becomes:=20
>>=20
>>  Issuer  The unique identifier for the entity that issued the=20
>>      assertion.  Generally this is the entity that holds the key=20
>>      material used to generate the assertion.  =20
>>       Example of issuers include an OAuth client, resource owner, an =
independent third party.=20
>>=20
>> Nat=20
>>=20
>> Nat=20
>>=20
>> On Tue, Dec 4, 2012 at 11:40 AM,  wrote:=20
>>=20
>>=20
>>=20
>> Chuck Mortimore  =E5=86=99=E4=BA=8E =
2012-12-04 10:26:50:=20
>>=20
>>=20
>> > Please feel free to suggest better language.=20
>>=20
>> >=20
>> > Issuer simply allows the token service to know who created the=20
>> > assertion, so it can look them up and see if they're trusted.    =20=

>> > Effectively the same as an Issuer in SAML.=20
>>=20
>> a conflict : "The token service is the assertion issuer" in assertion =
document.=20
>> while you said "token service know who created the assertion"=20
>>=20
>> I wonder if the following text is acceptable:=20
>>  =20
>>  Issuer  The unique identifier for the entity that issued the=20
>>      assertion.  Generally this is the entity that holds the key=20
>>      material used to generate the assertion.  The issuer may be =
either=20
>>       an OAuth client (when assertions are self-issued) or any other =
entity, e.g.,  a third party=20
>> token service, resource owner.=20
>>=20
>>=20
>> 6.3.  Client Acting on Behalf of a User=20
>>=20
>> The Issuer of the assertion MUST identify the entity that issued=20
>>      the assertion as recognized by the Authorization Server.  If the=20=

>>      assertion is self-issued, the Issuer SHOULD be the "client_id".=20=

>>      If the assertion was issued by a Security Token Service (STS), =
the=20
>>      Issuer SHOULD identify the STS as recognized by the =
Authorization=20
>>      Server.If the assertion was issued by the resource owner, the=20
>>      Issuer SHOULD identify the resource owner as recognized by the =
Authorization=20
>>      Server.=20
>>=20
>> >=20
>> > -cmort=20
>> >=20
>> > On Dec 3, 2012, at 6:23 PM,  wrote:=20
>> >=20
>> >=20
>> > Obviously, it is not so clear from the language there.=20
>> >=20
>> >=20
>> > Chuck Mortimore  =E5=86=99=E4=BA=8E =
2012-12-04 10:17:12:
>> >=20
>> > > There's no reason why it can't be resource owner today.  =20
>> > >=20
>> > > On Dec 3, 2012, at 6:06 PM,  =
> > > > wrote:=20
>> > >=20
>> > >=20
>> > > +1.=20
>> > > And why it was not looked at that time?=20
>> > >=20
>> > > oauth-bounces@ietf.org =E5=86=99=E4=BA=8E 2012-12-04 01:30:55:
>> > >=20
>> > > > Actually, I think it is a good time to start looking at the =
resourse
>> > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had =
brought
>> > > > this up a couple of years ago.)
>> > > >=20
>> > > > Igor
>> > > >=20
>> > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:=20
>> > > > I suppose, yes. I was reading it like that all the time.=20
>> > > > Whether it is or not, if it is still ok, it might be better to=20=

>> > clarify it.=20
>> > > > Word like "third party" tends to be a bit of problem without=20
>> > > clearlydefining.=20
>> > > > I had similar experience in other fora.=20
>> > > >=20
>> > > > Nat=20
>> > > >=20
>> > > > Sent from iPad=20
>> > > >=20
>> > > > 2012/12/03 0:52=E3=80=81"zhou.sujing@zte.com.cn" =
 =E3=81=AE
>> > > > =E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:
>> > >=20
>> > > >=20
>> > > > could be Resource owner?=20
>> > > >=20
>> > >=20
>> > > >=20
>> > > > "Tschofenig, Hannes (NSN - FI/Espoo)" =
=20
>> > > > =E5=8F=91=E4=BB=B6=E4=BA=BA:  oauth-bounces@ietf.org=20
>> > > > 2012-12-03 16:49=20
>> > > >=20
>> > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=20
>> > > >=20
>> > > > "ext Nat Sakimura" , "Brian Campbell" <
>> > > > bcampbell@pingidentity.com>, "oauth" =20
>> > > >=20
>> > > > =E6=8A=84=E9=80=81=20
>> > > >=20
>> > > > =E4=B8=BB=E9=A2=98=20
>> > > >=20
>> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be =
   =20
>> > > > either the client or a third party token service?=20
>> > > >=20
>> > > >=20
>> > > >=20
>> > > >=20
>> > > > Hi Nat,=20
>> > > >  =20
>> > > > The current text essentially says that the assertion can either =
be=20
>> > > > created by the client (in which case it is self-signed) or it =
can be
>> > > > created by some other entity (which is then called the third =
party=20
>> > > > token service). So, this third party could be the authorization =
server.=20
>> > > >  =20
>> > > > Ciao
>> > > > Hannes=20
>> > > >  =20
>> > > >  =20
>> > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of=20
>> > > > ext Nat Sakimura
>> > > > Sent: Monday, December 03, 2012 10:35 AM
>> > > > To: Brian Campbell; oauth
>> > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have =
to be
>> > > > either the client or a third party token service?=20
>> > > >  =20
>> > > > Hi Brian,=20
>> > > >  =20
>> > > >  =20
>> > > > The assertion framework defines the Issuer as:=20
>> > > >  =20
>> > > >    Issuer  The unique identifier for the entity that issued the=20=

>> > > >       assertion.  Generally this is the entity that holds the =
key=20
>> > > >       material used to generate the assertion.  The issuer may =
be either=20
>> > > >       an OAuth client (when assertions are self-issued) or a =
third party=20
>> > > >       token service.=20
>> > > >  =20
>> > > > I was wondering why it has to be either the client or a third =
party=20
>> > > > token service.=20
>> > > > Conceptually, it could be any token service (functionality)=20
>> > > residingin any of=20
>> > > >  =20
>> > > > the stakeholders (Resource Owner, OAuth Client, Authorization =
Server, or=20
>> > > > a third party).=20
>> > > >  =20
>> > > >  =20
>> > > > I would appreciate if you could clarify why is the case.=20
>> > > >  =20
>> > > >  =20
>> > > > Best,=20
>> > > >  =20
>> > > > --=20
>> > > > Nat Sakimura (=3Dnat)=20
>> > > > Chairman, OpenID Foundation
>> > > > http://nat.sakimura.org/
>> > > > @_nat_en=20
>> > > >  _______________________________________________
>> > > > OAuth mailing list
>> > > > OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/oauth
>> > >=20
>> > > >=20
>> > > >=20
>> > > > _______________________________________________
>> > > > OAuth mailing list
>> > > > OAuth@ietf.org
>> > > > https://www.ietf.org/mailman/listinfo/oauth
>> > > > _______________________________________________
>> > > > OAuth mailing 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
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>>=20
>> --=20
>> Nat Sakimura (=3Dnat)=20
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>> =20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_D14EC6BD-DA30-4233-AE6B-D88F35D06574
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I am =
developing an implementation that will exchange a JWE for an Access =
Token.

Issuer will be a third =
party.

On Dec 5, 2012, at 3:30 PM, Chuck =
Mortimore <cmortimore@salesforce.com>=
; wrote:

Most of the STS style usage I've seen has been =
using the SAML Bearer Token, rather than the JWT Bearer Token flow. =
  The predominant JWT usage I've seen thus far has been for =
self-issued assertions.    

That said, the =
language in question is generalized to Assertion use-cases rather than a =
specific Assertion =
format.

-cmort

<=
br>
On Dec 5, 2012, at 6:48 AM, Lewis Adam-CAL022 =
wrote:

Hi =
Brian,
This is sort of my =
feeling on the STS as well (theoretical).  Are there any real-life =
examples of obtaining a JWT assertion from an STS that can be used for =
the assertion flow?  And if so then how is it obtained?  It =
cannot be an id_token because that is audience restricted to the =
client.  I guess it could be an access_token with a scope of =
assertion?  But I=E2=80=99ve not seen any discussion of that.  =
I=E2=80=99ve been interested in this flow for a while but the only =
examples I=E2=80=99m aware of are self-issued JWTs.  I=E2=80=99d be =
very interested in knowing real life of examples of clients obtaining a =
JWT assertion from an STS to use as a grant, and the method they use to =
do that.
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Brian =
Campbell
Sent: Wednesday, December 05, =
2012 8:05 AM
To:  oauth@ietf.org
Subject: Re: [OAUTH-WG] Assertion =
Framework - Why does issuer have to be either the client or a third =
party token service?
I say that it's only theoretical because I =
don't believe there are any actual deployments supporting, or planning =
on supporting, RO as an assertion =
issuer.
On Tue, Dec 4, 2012 at 5:39 =
PM, <
Why RO as an issuer is only theoretical today? 

2012-12-04 =
23:41



The intent was definitely not to constrain who/what could =
be the issuer.  But also try to provide 
some guidance around =
the common cases that are actually being deployed now, which are the =
client self-issued and STS variants. Resource owner as an issuer is an =
interesting case but seems mostly theoretical at this point.

I =
feel like mentioning the resource owner there in =C2=A75.1 would cause =
more confusion than anything else. I'd prefer to just strike the whole =
sentence in question and maybe add some additional text to =C2=A73 that =
clarifies that the issuer can really be any entity, if folks think a =
change is needed here? 



On Mon, Dec 3, 2012 at 9:20 =
PM, Nat Sakimura <> wrote: 
Actually, " 
 any other =
entity, e.g.,  a third party 
token =
service. "  is not really clean. 

OAuth =
client is just another example of an issuer. 

So, =
perhaps the sentence could be: 

 

So, =
the clause becomes: 

 Issuer  The =
unique identifier for the entity that issued the 
    =
 assertion.  Generally this is the entity that holds the =
key 
      =
Example of issuers include an OAuth client, resource owner, an =
independent third party. 

Nat 

 

On Tue, Dec 4, 2012 at 11:40 =
AM, <> wrote: 



Chuck Mortimore <> =E5=86=99=E4=BA=8E 2012-12-04 =
10:26:50: 


> Please feel free to suggest =
better language. 

> 
> Issuer simply allows the =
token service to know who created the 
> assertion, so it can look =
them up and see if they're trusted.     
> Effectively the same as an =
Issuer in SAML. 

a conflict : "The token service =
is the assertion issuer" in assertion document. 
while you said "token service =
know who created the assertion" 

I wonder if the following text is =
acceptable:  
 Issuer =
 The unique identifier for the entity that issued the 
    =
 assertion.  Generally this is the entity that holds the =
key 
      an OAuth client (when assertions =
are self-issued) or any other entity, e.g., =
 a third party 
token service, resource owner. 


6.3.  Client Acting on Behalf of a =
User 

The Issuer of the assertion MUST =
identify the entity that issued 
     the assertion as recognized by the =
Authorization Server.  If the 
     assertion is self-issued, the Issuer =
SHOULD be the "client_id". 
     If the assertion was issued by a Security =
Token Service (STS), the 
     Issuer SHOULD identify the STS as =
recognized by the Authorization 
     Server.If the =
assertion was issued by the resource owner, the 
    
      
> -cmort 
> 
> On Dec 3, 2012, at 6:23 PM, =
<> wrote:> 
> 
> Obviously, it is not so =
clear from the language there. 
> 
> 
> Chuck Mortimore <> =E5=86=99=E4=BA=8E 2012-12-04 =
10:17:12:
> 
> > There's no reason why =
it can't be resource owner today.   
> > 
> > On Dec 3, 2012, at 6:06 =
PM, <> <> > > wrote: 
> > 
> > 
> > +1. 
> > And why it was not =
looked at that time? 
> > 
> > oauth-bounces@ietf.org =E5=86=99=E4=BA=8E 2012-12-04 =
01:30:55:
> =
> 
> > > Actually, I think =
it is a good time to start looking at the resourse
> > > owner issuing =
assertions@ (Interestingly enough, Hui-Lan had brought
> > > this up a couple =
of years ago.)
> =
> > 
> > > Igor
> > > 
> > > On 12/3/2012 3:58 =
AM, Nat Sakimura wrote: 
> > > I suppose, yes. I =
was reading it like that all the time. 
> > > Whether it is or =
not, if it is still ok, it might be better to 
> clarify it. 
> > > Word like "third =
party" tends to be a bit of problem without 
> > clearlydefining. 
> > > I had similar =
experience in other fora. 
> > > 
> > > Nat 
> > > 
> > > Sent from =
iPad 
> > > 
> > > 2012/12/03 =
0:52=E3=80=81"zhou.sujing@zte.com.cn" <> =E3=81=AE
> > > =E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:<=
br>> > 
> > > 
> > > could be Resource =
owner? 
> > > 
> > 
> > > 
> > > "Tschofenig, =
Hannes (NSN - FI/Espoo)" <> 
> > > =E5=8F=91=E4=BB=B6=E4=BA=BA:  oauth-bounces@ietf.org 
 
> > > 
> > > =E6=94=B6=E4=BB=B6=E4=BA=BA 
> > > 
> > > "ext Nat Sakimura" =
<sakimura@gmail.com>, "Brian Campbell" =
<
> > =
> >, "oauth" <oauth@ietf.org> 
> > > 
> > > =E6=8A=84=E9=80=81 
> > > 
> > > =E4=B8=BB=E9=A2=98 
> > > 
> > > Re: [OAUTH-WG] =
Assertion Framework - Why does issuer have to be     
> > > either the client =
or a third party token service? 
> > > 
> > > 
> > > 
> > > 
> > > Hi Nat, 
> > >   
> > > The current text =
essentially says that the assertion can either be 
> > > created by the =
client (in which case it is self-signed) or it can be
> > > created by some =
other entity (which is then called the third party 
> > > token service). =
So, this third party could be the authorization server. 
> > >   
> > > Ciao
> > > Hannes 
> > >   
> > >   
> > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of 
> > > ext Nat =
Sakimura
> > =
> Sent: Monday, December 03, 2012 10:35 AM
> > > To: Brian =
Campbell; oauth
> =
> > Subject: [OAUTH-WG] Assertion Framework - Why does issuer have =
to be
> > > =
either the client or a third party token service? 
> > >   
> > > Hi Brian, 
> > >   
> > >   
> > > The assertion =
framework defines the Issuer as: 
> > >   
> > >    Issuer  The unique identifier for the entity that =
issued the 
> > >       assertion.  Generally this is the entity that holds =
the key 
> > >       material used to generate =
the assertion.  The issuer may be either 
> > >       an OAuth client (when =
assertions are self-issued) or a third party 
> > >       token service. 
> > >   
> > > I was wondering =
why it has to be either the client or a third party 
> > > token =
service. 
> > > Conceptually, it =
could be any token service (functionality) 
> > residingin any of 
> > >   
> > > the stakeholders =
(Resource Owner, OAuth Client, Authorization Server, or 
> > > a third =
party). 
> > >   
> > >   
> > > I would appreciate =
if you could clarify why is the case. 
> > >   
> > >   
> > > Best, 
> > >   
> > > -- 
> > > Nat Sakimura =
(=3Dnat) 
> > > Chairman, OpenID =
Foundation
> > =
> http://nat.sakimura.org/
> > > @_nat_en 
> > > > > > OAuth mailing =
list
> > =
>  > > 
> > > 
> > > 
> > > =
_______________________________________________
> > > OAuth mailing =
list
> > =
>  > > > =
_______________________________________________
> > > OAuth mailing =
list
> > =
>  > > =
_______________________________________________
> > OAuth mailing =
list
> >   

OAuth@ietf.org





-- 
Nat Sakimura =
(=3Dnat) 
Chairman, OpenID =
Foundation
http://nat.sakimura.org/
@_nat_en 


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

=

--Apple-Mail=_D14EC6BD-DA30-4233-AE6B-D88F35D06574--

From tonynad@microsoft.com  Fri Dec  7 14:51:59 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539DF21F86C3 for ; Fri,  7 Dec 2012 14:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.534
X-Spam-Level: 
X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYxR1MCYnM+y for ; Fri,  7 Dec 2012 14:51:57 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7651C21F85B2 for ; Fri,  7 Dec 2012 14:51:57 -0800 (PST)
Received: from BY2FFO11FD016.protection.gbl (10.1.15.201) by BY2FFO11HUB033.protection.gbl (10.1.14.117) with Microsoft SMTP Server (TLS) id 15.0.568.11; Fri, 7 Dec 2012 22:51:53 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD016.mail.protection.outlook.com (10.1.14.132) with Microsoft SMTP Server (TLS) id 15.0.568.11 via Frontend Transport; Fri, 7 Dec 2012 22:51:53 +0000
Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 7 Dec 2012 22:51:34 +0000
Received: from mail50-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 7 Dec 2012 22:50:58 +0000
Received: from mail50-tx2 (localhost [127.0.0.1])	by mail50-tx2-R.bigfish.com (Postfix) with ESMTP id DA33E14011D	for ; Fri,  7 Dec 2012 22:50:57 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -26
X-BigFish: PS-26(zzbb2dI98dI9371Ic89bhd6eah936eI1454Ic3f2M1521I1432Ic857hzz1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL6d524h17326ah8275bh8275dh18c673hz32i2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: permerror (mail50-tx2: error in processing during lookup of domain of microsoft.com: Could not find a valid SPF record) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454001)(377424002)(479174001)(24454001)(501624001)(52044001)(51704002)(54094002)(47736001)(33646001)(49866001)(56816002)(76482001)(59766001)(77982001)(4396001)(550184003)(16236675001)(51856001)(47446002)(56776001)(74662001)(46102001)(74502001)(15202345001)(54316002)(53806001)(54356001)(31966008)(4477805001)(16406001)(47976001)(50986001)(5343655001)(5343635001)(42262001)(24736002); DIR:OUT; SFP:; 
Received: from mail50-tx2 (localhost.localdomain [127.0.0.1]) by mail50-tx2 (MessageSwitch) id 1354920653826842_6258; Fri,  7 Dec 2012 22:50:53 +0000 (UTC)
Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.245])	by mail50-tx2.bigfish.com (Postfix) with ESMTP id BA2944200AD; Fri,  7 Dec 2012 22:50:53 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 7 Dec 2012 22:50:49 +0000
Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.245.2; Fri, 7 Dec 2012 22:50:48 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.568.11; Fri, 7 Dec 2012 22:50:43 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.10.207]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.10.225]) with mapi id 15.00.0568.000; Fri, 7 Dec 2012 22:50:43 +0000
From: Anthony Nadalin 
To: Dick Hardt , Chuck Mortimore 
Thread-Topic: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
Thread-Index: AQHN1MjKOofBAVnH7k67f3hHYWL8e5gN8PPA
Date: Fri, 7 Dec 2012 22:50:43 +0000
Message-ID: 
References:    <59E470B10C4630419ED717AC79FCF9A92F1A9015@BLUPRD0411MB436.namprd04.prod.outlook.com> <7A54FDF5-D910-4E60-BB5F-5FB98A4B88E5@salesforce.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.174.168]
x-forefront-prvs: 0688BF9B46
Content-Type: multipart/alternative; boundary="_000_fb726c293bea4abc9aa954746b61b30aBY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%SALESFORCE.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC103.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(501624001)(52044001)(479174001)(51704002)(377424002)(377454001)(24454001)(54094002)(50986001)(15202345001)(31966008)(74662001)(77982001)(4477805001)(53806001)(56816002)(76482001)(33646001)(47976001)(44976002)(51856001)(16236675001)(54316002)(54356001)(46102001)(47446002)(59766001)(74502001)(550184003)(16676001)(49866001)(56776001)(4396001)(6806001)(512874001)(47736001)(5343655001)(5343635001)(42262001)(24736002); DIR:OUT; SFP:; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0688BF9B46
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be	either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 07 Dec 2012 22:51:59 -0000

--_000_fb726c293bea4abc9aa954746b61b30aBY2PR03MB041namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SldFID8NCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEaWNrIEhhcmR0DQpTZW50OiBGcmlkYXksIERlY2Vt
YmVyIDcsIDIwMTIgMjoxOCBQTQ0KVG86IENodWNrIE1vcnRpbW9yZQ0KQ2M6IG9hdXRoQGlldGYu
b3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRv
ZXMgaXNzdWVyIGhhdmUgdG8gYmUgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0
b2tlbiBzZXJ2aWNlPw0KDQpJIGFtIGRldmVsb3BpbmcgYW4gaW1wbGVtZW50YXRpb24gdGhhdCB3
aWxsIGV4Y2hhbmdlIGEgSldFIGZvciBhbiBBY2Nlc3MgVG9rZW4uDQoNCklzc3VlciB3aWxsIGJl
IGEgdGhpcmQgcGFydHkuDQoNCk9uIERlYyA1LCAyMDEyLCBhdCAzOjMwIFBNLCBDaHVjayBNb3J0
aW1vcmUgPGNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208bWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNm
b3JjZS5jb20+PiB3cm90ZToNCg0KDQpNb3N0IG9mIHRoZSBTVFMgc3R5bGUgdXNhZ2UgSSd2ZSBz
ZWVuIGhhcyBiZWVuIHVzaW5nIHRoZSBTQU1MIEJlYXJlciBUb2tlbiwgcmF0aGVyIHRoYW4gdGhl
IEpXVCBCZWFyZXIgVG9rZW4gZmxvdy4gICBUaGUgcHJlZG9taW5hbnQgSldUIHVzYWdlIEkndmUg
c2VlbiB0aHVzIGZhciBoYXMgYmVlbiBmb3Igc2VsZi1pc3N1ZWQgYXNzZXJ0aW9ucy4NCg0KVGhh
dCBzYWlkLCB0aGUgbGFuZ3VhZ2UgaW4gcXVlc3Rpb24gaXMgZ2VuZXJhbGl6ZWQgdG8gQXNzZXJ0
aW9uIHVzZS1jYXNlcyByYXRoZXIgdGhhbiBhIHNwZWNpZmljIEFzc2VydGlvbiBmb3JtYXQuDQoN
Ci1jbW9ydA0KDQoNCk9uIERlYyA1LCAyMDEyLCBhdCA2OjQ4IEFNLCBMZXdpcyBBZGFtLUNBTDAy
MiB3cm90ZToNCg0KDQpIaSBCcmlhbiwNCg0KVGhpcyBpcyBzb3J0IG9mIG15IGZlZWxpbmcgb24g
dGhlIFNUUyBhcyB3ZWxsICh0aGVvcmV0aWNhbCkuICBBcmUgdGhlcmUgYW55IHJlYWwtbGlmZSBl
eGFtcGxlcyBvZiBvYnRhaW5pbmcgYSBKV1QgYXNzZXJ0aW9uIGZyb20gYW4gU1RTIHRoYXQgY2Fu
IGJlIHVzZWQgZm9yIHRoZSBhc3NlcnRpb24gZmxvdz8gIEFuZCBpZiBzbyB0aGVuIGhvdyBpcyBp
dCBvYnRhaW5lZD8gIEl0IGNhbm5vdCBiZSBhbiBpZF90b2tlbiBiZWNhdXNlIHRoYXQgaXMgYXVk
aWVuY2UgcmVzdHJpY3RlZCB0byB0aGUgY2xpZW50LiAgSSBndWVzcyBpdCBjb3VsZCBiZSBhbiBh
Y2Nlc3NfdG9rZW4gd2l0aCBhIHNjb3BlIG9mIGFzc2VydGlvbj8gIEJ1dCBJ4oCZdmUgbm90IHNl
ZW4gYW55IGRpc2N1c3Npb24gb2YgdGhhdC4gIEnigJl2ZSBiZWVuIGludGVyZXN0ZWQgaW4gdGhp
cyBmbG93IGZvciBhIHdoaWxlIGJ1dCB0aGUgb25seSBleGFtcGxlcyBJ4oCZbSBhd2FyZSBvZiBh
cmUgc2VsZi1pc3N1ZWQgSldUcy4gIEnigJlkIGJlIHZlcnkgaW50ZXJlc3RlZCBpbiBrbm93aW5n
IHJlYWwgbGlmZSBvZiBleGFtcGxlcyBvZiBjbGllbnRzIG9idGFpbmluZyBhIEpXVCBhc3NlcnRp
b24gZnJvbSBhbiBTVFMgdG8gdXNlIGFzIGEgZ3JhbnQsIGFuZCB0aGUgbWV0aG9kIHRoZXkgdXNl
IHRvIGRvIHRoYXQuDQoNCnR4DQphZGFtDQoNCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8
bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZzxtYWlsdG86Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVs
bA0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAwNSwgMjAxMiA4OjA1IEFNDQpUbzogemhvdS5z
dWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbj4NCkNjOiBvYXV0
aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW09BVVRILVdH
XSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8gYmUgZWl0aGVy
IHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPw0KDQpJIHNheSB0aGF0
IGl0J3Mgb25seSB0aGVvcmV0aWNhbCBiZWNhdXNlIEkgZG9uJ3QgYmVsaWV2ZSB0aGVyZSBhcmUg
YW55IGFjdHVhbCBkZXBsb3ltZW50cyBzdXBwb3J0aW5nLCBvciBwbGFubmluZyBvbiBzdXBwb3J0
aW5nLCBSTyBhcyBhbiBhc3NlcnRpb24gaXNzdWVyLg0KDQpPbiBUdWUsIERlYyA0LCAyMDEyIGF0
IDU6MzkgUE0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPG1haWx0bzp6aG91LnN1amluZ0B6dGUu
Y29tLmNuPj4gd3JvdGU6DQoNCldoeSBSTyBhcyBhbiBpc3N1ZXIgaXMgb25seSB0aGVvcmV0aWNh
bCB0b2RheT8NCg0KDQpCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208
bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4NCg0KMjAxMi0xMi0wNCAyMzo0MQ0K
DQrmlLbku7bkuroNCg0KTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNh
a2ltdXJhQGdtYWlsLmNvbT4+DQoNCuaKhOmAgQ0KDQp6aG91LnN1amluZ0B6dGUuY29tLmNuPG1h
aWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPiwgIm9hdXRoQGlldGYub3JnPG1haWx0bzpvYXV0
aEBpZXRmLm9yZz4iIDxvYXV0aEBpZXRmLm9yZzxtYWlsdG86b2F1dGhAaWV0Zi5vcmc+Pg0KDQrk
uLvpopgNCg0KUmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlz
c3VlciBoYXZlIHRvIGJlIGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4g
c2VydmljZT8NCg0KDQoNCg0KDQoNCg0KVGhlIGludGVudCB3YXMgZGVmaW5pdGVseSBub3QgdG8g
Y29uc3RyYWluIHdoby93aGF0IGNvdWxkIGJlIHRoZSBpc3N1ZXIuICBCdXQgYWxzbyB0cnkgdG8g
cHJvdmlkZQ0Kc29tZSBndWlkYW5jZSBhcm91bmQgdGhlIGNvbW1vbiBjYXNlcyB0aGF0IGFyZSBh
Y3R1YWxseSBiZWluZyBkZXBsb3llZCBub3csIHdoaWNoIGFyZSB0aGUgY2xpZW50IHNlbGYtaXNz
dWVkIGFuZCBTVFMgdmFyaWFudHMuIFJlc291cmNlIG93bmVyIGFzIGFuIGlzc3VlciBpcyBhbiBp
bnRlcmVzdGluZyBjYXNlIGJ1dCBzZWVtcyBtb3N0bHkgdGhlb3JldGljYWwgYXQgdGhpcyBwb2lu
dC4NCg0KSSBmZWVsIGxpa2UgbWVudGlvbmluZyB0aGUgcmVzb3VyY2Ugb3duZXIgdGhlcmUgaW4g
wqc1LjEgd291bGQgY2F1c2UgbW9yZSBjb25mdXNpb24gdGhhbiBhbnl0aGluZyBlbHNlLiBJJ2Qg
cHJlZmVyIHRvIGp1c3Qgc3RyaWtlIHRoZSB3aG9sZSBzZW50ZW5jZSBpbiBxdWVzdGlvbiBhbmQg
bWF5YmUgYWRkIHNvbWUgYWRkaXRpb25hbCB0ZXh0IHRvIMKnMyB0aGF0IGNsYXJpZmllcyB0aGF0
IHRoZSBpc3N1ZXIgY2FuIHJlYWxseSBiZSBhbnkgZW50aXR5LCBpZiBmb2xrcyB0aGluayBhIGNo
YW5nZSBpcyBuZWVkZWQgaGVyZT8NCg0KDQoNCk9uIE1vbiwgRGVjIDMsIDIwMTIgYXQgOToyMCBQ
TSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb208bWFpbHRvOnNha2ltdXJhQGdtYWls
LmNvbT4+IHdyb3RlOg0KQWN0dWFsbHksICJUaGUgaXNzdWVyIG1heSBiZSBlaXRoZXINCiAgICAg
IGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3VlZCkgb3IgYW55
IG90aGVyIGVudGl0eSwgZS5nLiwgIGEgdGhpcmQgcGFydHkNCnRva2VuIHNlcnZpY2UsIHJlc291
cmNlIG93bmVyLiAiICBpcyBub3QgcmVhbGx5IGNsZWFuLg0KDQpPQXV0aCBjbGllbnQgaXMganVz
dCBhbm90aGVyIGV4YW1wbGUgb2YgYW4gaXNzdWVyLg0KDQpTbywgcGVyaGFwcyB0aGUgc2VudGVu
Y2UgY291bGQgYmU6DQoNCiJFeGFtcGxlIG9mIGlzc3VlcnMgaW5jbHVkZSBhbiBPQXV0aCBjbGll
bnQsIHJlc291cmNlIG93bmVyLCBhbiBpbmRlcGVuZGVudCB0aGlyZCBwYXJ0eS4iDQoNClNvLCB0
aGUgY2xhdXNlIGJlY29tZXM6DQoNCiBJc3N1ZXIgIFRoZSB1bmlxdWUgaWRlbnRpZmllciBmb3Ig
dGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGUNCiAgICAgYXNzZXJ0aW9uLiAgR2VuZXJhbGx5IHRo
aXMgaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSBrZXkNCiAgICAgbWF0ZXJpYWwgdXNlZCB0
byBnZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLg0KICAgICAgRXhhbXBsZSBvZiBpc3N1ZXJzIGluY2x1
ZGUgYW4gT0F1dGggY2xpZW50LCByZXNvdXJjZSBvd25lciwgYW4gaW5kZXBlbmRlbnQgdGhpcmQg
cGFydHkuDQoNCk5hdA0KDQpOYXQNCg0KT24gVHVlLCBEZWMgNCwgMjAxMiBhdCAxMTo0MCBBTSwg
PHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24+PiB3
cm90ZToNCg0KDQoNCkNodWNrIE1vcnRpbW9yZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbTxt
YWlsdG86Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbT4+IOWGmeS6jiAyMDEyLTEyLTA0IDEwOjI2
OjUwOg0KDQoNCj4gUGxlYXNlIGZlZWwgZnJlZSB0byBzdWdnZXN0IGJldHRlciBsYW5ndWFnZS4N
Cg0KPg0KPiBJc3N1ZXIgc2ltcGx5IGFsbG93cyB0aGUgdG9rZW4gc2VydmljZSB0byBrbm93IHdo
byBjcmVhdGVkIHRoZQ0KPiBhc3NlcnRpb24sIHNvIGl0IGNhbiBsb29rIHRoZW0gdXAgYW5kIHNl
ZSBpZiB0aGV5J3JlIHRydXN0ZWQuDQo+IEVmZmVjdGl2ZWx5IHRoZSBzYW1lIGFzIGFuIElzc3Vl
ciBpbiBTQU1MLg0KDQphIGNvbmZsaWN0IDogIlRoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3Nl
cnRpb24gaXNzdWVyIiBpbiBhc3NlcnRpb24gZG9jdW1lbnQuDQp3aGlsZSB5b3Ugc2FpZCAidG9r
ZW4gc2VydmljZSBrbm93IHdobyBjcmVhdGVkIHRoZSBhc3NlcnRpb24iDQoNCkkgd29uZGVyIGlm
IHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBhY2NlcHRhYmxlOg0KDQogSXNzdWVyICBUaGUgdW5pcXVl
IGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhlDQogICAgIGFzc2VydGlv
bi4gIEdlbmVyYWxseSB0aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUga2V5DQogICAg
IG1hdGVyaWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gIFRoZSBpc3N1ZXIgbWF5
IGJlIGVpdGhlcg0KICAgICAgYW4gT0F1dGggY2xpZW50ICh3aGVuIGFzc2VydGlvbnMgYXJlIHNl
bGYtaXNzdWVkKSBvciBhbnkgb3RoZXIgZW50aXR5LCBlLmcuLCAgYSB0aGlyZCBwYXJ0eQ0KdG9r
ZW4gc2VydmljZSwgcmVzb3VyY2Ugb3duZXIuDQoNCg0KNi4zLiAgQ2xpZW50IEFjdGluZyBvbiBC
ZWhhbGYgb2YgYSBVc2VyDQoNClRoZSBJc3N1ZXIgb2YgdGhlIGFzc2VydGlvbiBNVVNUIGlkZW50
aWZ5IHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQNCiAgICAgdGhlIGFzc2VydGlvbiBhcyByZWNvZ25p
emVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4gIElmIHRoZQ0KICAgICBhc3NlcnRpb24g
aXMgc2VsZi1pc3N1ZWQsIHRoZSBJc3N1ZXIgU0hPVUxEIGJlIHRoZSAiY2xpZW50X2lkIi4NCiAg
ICAgSWYgdGhlIGFzc2VydGlvbiB3YXMgaXNzdWVkIGJ5IGEgU2VjdXJpdHkgVG9rZW4gU2Vydmlj
ZSAoU1RTKSwgdGhlDQogICAgIElzc3VlciBTSE9VTEQgaWRlbnRpZnkgdGhlIFNUUyBhcyByZWNv
Z25pemVkIGJ5IHRoZSBBdXRob3JpemF0aW9uDQogICAgIFNlcnZlci5JZiB0aGUgYXNzZXJ0aW9u
IHdhcyBpc3N1ZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCB0aGUNCiAgICAgSXNzdWVyIFNIT1VM
RCBpZGVudGlmeSB0aGUgcmVzb3VyY2Ugb3duZXIgYXMgcmVjb2duaXplZCBieSB0aGUgQXV0aG9y
aXphdGlvbg0KICAgICBTZXJ2ZXIuDQoNCj4NCj4gLWNtb3J0DQo+DQo+IE9uIERlYyAzLCAyMDEy
LCBhdCA2OjIzIFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWppbmdA
enRlLmNvbS5jbj4+IHdyb3RlOg0KPg0KPg0KPiBPYnZpb3VzbHksIGl0IGlzIG5vdCBzbyBjbGVh
ciBmcm9tIHRoZSBsYW5ndWFnZSB0aGVyZS4NCj4NCj4NCj4gQ2h1Y2sgTW9ydGltb3JlIDxjbW9y
dGltb3JlQHNhbGVzZm9yY2UuY29tPG1haWx0bzpjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPj4g
5YaZ5LqOIDIwMTItMTItMDQgMTA6MTc6MTI6DQo+DQo+ID4gVGhlcmUncyBubyByZWFzb24gd2h5
IGl0IGNhbid0IGJlIHJlc291cmNlIG93bmVyIHRvZGF5Lg0KPiA+DQo+ID4gT24gRGVjIDMsIDIw
MTIsIGF0IDY6MDYgUE0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPG1haWx0bzp6aG91LnN1amlu
Z0B6dGUuY29tLmNuPj4gPHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFpbHRvOnpob3Uuc3VqaW5n
QHp0ZS5jb20uY24+DQo+ID4gPiB3cm90ZToNCj4gPg0KPiA+DQo+ID4gKzEuDQo+ID4gQW5kIHdo
eSBpdCB3YXMgbm90IGxvb2tlZCBhdCB0aGF0IHRpbWU/DQo+ID4NCj4gPiBvYXV0aC1ib3VuY2Vz
QGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPiDlhpnkuo4gMjAxMi0xMi0w
NCAwMTozMDo1NToNCj4gPg0KPiA+ID4gQWN0dWFsbHksIEkgdGhpbmsgaXQgaXMgYSBnb29kIHRp
bWUgdG8gc3RhcnQgbG9va2luZyBhdCB0aGUgcmVzb3Vyc2UNCj4gPiA+IG93bmVyIGlzc3Vpbmcg
YXNzZXJ0aW9uc0AgKEludGVyZXN0aW5nbHkgZW5vdWdoLCBIdWktTGFuIGhhZCBicm91Z2h0DQo+
ID4gPiB0aGlzIHVwIGEgY291cGxlIG9mIHllYXJzIGFnby4pDQo+ID4gPg0KPiA+ID4gSWdvcg0K
PiA+ID4NCj4gPiA+IE9uIDEyLzMvMjAxMiAzOjU4IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6DQo+
ID4gPiBJIHN1cHBvc2UsIHllcy4gSSB3YXMgcmVhZGluZyBpdCBsaWtlIHRoYXQgYWxsIHRoZSB0
aW1lLg0KPiA+ID4gV2hldGhlciBpdCBpcyBvciBub3QsIGlmIGl0IGlzIHN0aWxsIG9rLCBpdCBt
aWdodCBiZSBiZXR0ZXIgdG8NCj4gY2xhcmlmeSBpdC4NCj4gPiA+IFdvcmQgbGlrZSAidGhpcmQg
cGFydHkiIHRlbmRzIHRvIGJlIGEgYml0IG9mIHByb2JsZW0gd2l0aG91dA0KPiA+IGNsZWFybHlk
ZWZpbmluZy4NCj4gPiA+IEkgaGFkIHNpbWlsYXIgZXhwZXJpZW5jZSBpbiBvdGhlciBmb3JhLg0K
PiA+ID4NCj4gPiA+IE5hdA0KPiA+ID4NCj4gPiA+IFNlbnQgZnJvbSBpUGFkDQo+ID4gPg0KPiA+
ID4gMjAxMi8xMi8wMyAwOjUy44CBInpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFpbHRvOnpob3Uu
c3VqaW5nQHp0ZS5jb20uY24+IiA8emhvdS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5z
dWppbmdAenRlLmNvbS5jbj4+IOOBrg0KPiA+ID4g44Oh44OD44K744O844K4Og0KPiA+DQo+ID4g
Pg0KPiA+ID4gY291bGQgYmUgUmVzb3VyY2Ugb3duZXI/DQo+ID4gPg0KPiA+DQo+ID4gPg0KPiA+
ID4gIlRzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pIiA8aGFubmVzLnRzY2hvZmVu
aWdAbnNuLmNvbTxtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbT4+DQo+ID4gPiDlj5Hk
u7bkuro6ICBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnPg0KPiA+ID4gMjAxMi0xMi0wMyAxNjo0OQ0KPiA+ID4NCj4gPiA+IOaUtuS7tuS6ug0KPiA+
ID4NCj4gPiA+ICJleHQgTmF0IFNha2ltdXJhIiA8c2FraW11cmFAZ21haWwuY29tPG1haWx0bzpz
YWtpbXVyYUBnbWFpbC5jb20+PiwgIkJyaWFuIENhbXBiZWxsIiA8DQo+ID4gPiBiY2FtcGJlbGxA
cGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiwgIm9h
dXRoIiA8b2F1dGhAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoQGlldGYub3JnPj4NCj4gPiA+DQo+ID4g
PiDmioTpgIENCj4gPiA+DQo+ID4gPiDkuLvpopgNCj4gPiA+DQo+ID4gPiBSZTogW09BVVRILVdH
XSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8gYmUNCj4gPiA+
IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT8NCj4gPiA+
DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBIaSBOYXQsDQo+ID4gPg0KPiA+ID4gVGhlIGN1
cnJlbnQgdGV4dCBlc3NlbnRpYWxseSBzYXlzIHRoYXQgdGhlIGFzc2VydGlvbiBjYW4gZWl0aGVy
IGJlDQo+ID4gPiBjcmVhdGVkIGJ5IHRoZSBjbGllbnQgKGluIHdoaWNoIGNhc2UgaXQgaXMgc2Vs
Zi1zaWduZWQpIG9yIGl0IGNhbiBiZQ0KPiA+ID4gY3JlYXRlZCBieSBzb21lIG90aGVyIGVudGl0
eSAod2hpY2ggaXMgdGhlbiBjYWxsZWQgdGhlIHRoaXJkIHBhcnR5DQo+ID4gPiB0b2tlbiBzZXJ2
aWNlKS4gU28sIHRoaXMgdGhpcmQgcGFydHkgY291bGQgYmUgdGhlIGF1dGhvcml6YXRpb24gc2Vy
dmVyLg0KPiA+ID4NCj4gPiA+IENpYW8NCj4gPiA+IEhhbm5lcw0KPiA+ID4NCj4gPiA+DQo+ID4g
PiBGcm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYu
b3JnPiBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YNCj4gPiA+IGV4dCBOYXQgU2FraW11cmENCj4gPiA+IFNl
bnQ6IE1vbmRheSwgRGVjZW1iZXIgMDMsIDIwMTIgMTA6MzUgQU0NCj4gPiA+IFRvOiBCcmlhbiBD
YW1wYmVsbDsgb2F1dGgNCj4gPiA+IFN1YmplY3Q6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1l
d29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlIHRvIGJlDQo+ID4gPiBlaXRoZXIgdGhlIGNsaWVu
dCBvciBhIHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2U/DQo+ID4gPg0KPiA+ID4gSGkgQnJpYW4s
DQo+ID4gPg0KPiA+ID4NCj4gPiA+IFRoZSBhc3NlcnRpb24gZnJhbWV3b3JrIGRlZmluZXMgdGhl
IElzc3VlciBhczoNCj4gPiA+DQo+ID4gPiAgICBJc3N1ZXIgIFRoZSB1bmlxdWUgaWRlbnRpZmll
ciBmb3IgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGUNCj4gPiA+ICAgICAgIGFzc2VydGlvbi4g
IEdlbmVyYWxseSB0aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUga2V5DQo+ID4gPiAg
ICAgICBtYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uICBUaGUgaXNzdWVy
IG1heSBiZSBlaXRoZXINCj4gPiA+ICAgICAgIGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRp
b25zIGFyZSBzZWxmLWlzc3VlZCkgb3IgYSB0aGlyZCBwYXJ0eQ0KPiA+ID4gICAgICAgdG9rZW4g
c2VydmljZS4NCj4gPiA+DQo+ID4gPiBJIHdhcyB3b25kZXJpbmcgd2h5IGl0IGhhcyB0byBiZSBl
aXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBhcnR5DQo+ID4gPiB0b2tlbiBzZXJ2aWNlLg0K
PiA+ID4gQ29uY2VwdHVhbGx5LCBpdCBjb3VsZCBiZSBhbnkgdG9rZW4gc2VydmljZSAoZnVuY3Rp
b25hbGl0eSkNCj4gPiByZXNpZGluZ2luIGFueSBvZg0KPiA+ID4NCj4gPiA+IHRoZSBzdGFrZWhv
bGRlcnMgKFJlc291cmNlIE93bmVyLCBPQXV0aCBDbGllbnQsIEF1dGhvcml6YXRpb24gU2VydmVy
LCBvcg0KPiA+ID4gYSB0aGlyZCBwYXJ0eSkuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IEkgd291bGQg
YXBwcmVjaWF0ZSBpZiB5b3UgY291bGQgY2xhcmlmeSB3aHkgaXMgdGhlIGNhc2UuDQo+ID4gPg0K
PiA+ID4NCj4gPiA+IEJlc3QsDQo+ID4gPg0KPiA+ID4gLS0NCj4gPiA+IE5hdCBTYWtpbXVyYSAo
PW5hdCkNCj4gPiA+IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPiA+ID4gaHR0cDovL25h
dC5zYWtpbXVyYS5vcmcvDQo+ID4gPiBAX25hdF9lbg0KPiA+ID4gIF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBPQXV0aCBtYWlsaW5nIGxpc3QN
Cj4gPiA+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gPiA+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPg0KPiA+ID4NCj4gPiA+
DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1
dGhAaWV0Zi5vcmc+DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L29hdXRoDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZzxtYWls
dG86T0F1dGhAaWV0Zi5vcmc+DQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZzxtYWls
dG86T0F1dGhAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0
Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0K
DQoNCi0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24N
Cmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0
aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxt
YWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm
Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K

--_000_fb726c293bea4abc9aa954746b61b30aBY2PR03MB041namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug
aHJlZj0ieC1tc2c6Ly80NzkvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQg
MiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3Nl
LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1i
cmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg
NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5v
c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkJv
b2sgQW50aXF1YSI7DQoJcGFub3NlLTE6MiA0IDYgMiA1IDMgNSAzIDMgNDt9DQovKiBTdHlsZSBE
ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K
CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0
Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFu
Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0
ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG
b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv
dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglm
b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnR0DQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLCJzZXJpZiI7fQ0Kc3Bhbi5h
cHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bh
bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk
LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250
LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN
CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw
YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K
PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh
W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9
ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv
dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkpXRSA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWls
dG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RGljayBIYXJk
dDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIERlY2VtYmVyIDcsIDIwMTIgMjoxOCBQTTxicj4N
CjxiPlRvOjwvYj4gQ2h1Y2sgTW9ydGltb3JlPGJyPg0KPGI+Q2M6PC9iPiBvYXV0aEBpZXRmLm9y
Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3Jr
IC0gV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8gYmUgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGly
ZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPkkgYW0gZGV2ZWxvcGluZyBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IHdpbGwg
ZXhjaGFuZ2UgYSBKV0UgZm9yIGFuIEFjY2VzcyBUb2tlbi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzc3VlciB3aWxsIGJlIGEgdGhpcmQgcGFydHkuPG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRGVj
IDUsIDIwMTIsIGF0IDM6MzAgUE0sIENodWNrIE1vcnRpbW9yZSAmbHQ7PGEgaHJlZj0ibWFpbHRv
OmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20iPmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208L2E+
Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5Nb3N0IG9mIHRoZSBTVFMgc3R5bGUgdXNhZ2UgSSd2ZSBzZWVuIGhhcyBiZWVuIHVzaW5nIHRo
ZSBTQU1MIEJlYXJlciBUb2tlbiwgcmF0aGVyIHRoYW4gdGhlIEpXVCBCZWFyZXIgVG9rZW4gZmxv
dy4gJm5ic3A7IFRoZSBwcmVkb21pbmFudCBKV1QgdXNhZ2UgSSd2ZSBzZWVuIHRodXMgZmFyIGhh
cyBiZWVuIGZvciBzZWxmLWlzc3VlZCBhc3NlcnRpb25zLiAmbmJzcDsgJm5ic3A7PG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IHNhaWQsIHRoZSBsYW5n
dWFnZSBpbiBxdWVzdGlvbiBpcyBnZW5lcmFsaXplZCB0byBBc3NlcnRpb24gdXNlLWNhc2VzIHJh
dGhlciB0aGFuIGEgc3BlY2lmaWMgQXNzZXJ0aW9uIGZvcm1hdC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LWNtb3J0PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRGVjIDUs
IDIwMTIsIGF0IDY6NDggQU0sIExld2lzIEFkYW0tQ0FMMDIyIHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv
cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7
c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPkhpIEJyaWFuLDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh
bWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xp
dmUiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEm
cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPlRoaXMgaXMgc29ydCBvZiBteSBm
ZWVsaW5nIG9uIHRoZSBTVFMgYXMgd2VsbCAodGhlb3JldGljYWwpLiZuYnNwOyBBcmUgdGhlcmUg
YW55IHJlYWwtbGlmZSBleGFtcGxlcyBvZiBvYnRhaW5pbmcgYSBKV1QgYXNzZXJ0aW9uIGZyb20g
YW4gU1RTIHRoYXQgY2FuIGJlIHVzZWQgZm9yIHRoZQ0KIGFzc2VydGlvbiBmbG93PyZuYnNwOyBB
bmQgaWYgc28gdGhlbiBob3cgaXMgaXQgb2J0YWluZWQ/Jm5ic3A7IEl0IGNhbm5vdCBiZSBhbiBp
ZF90b2tlbiBiZWNhdXNlIHRoYXQgaXMgYXVkaWVuY2UgcmVzdHJpY3RlZCB0byB0aGUgY2xpZW50
LiZuYnNwOyBJIGd1ZXNzIGl0IGNvdWxkIGJlIGFuIGFjY2Vzc190b2tlbiB3aXRoIGEgc2NvcGUg
b2YgYXNzZXJ0aW9uPyZuYnNwOyBCdXQgSeKAmXZlIG5vdCBzZWVuIGFueSBkaXNjdXNzaW9uIG9m
IHRoYXQuJm5ic3A7IEnigJl2ZSBiZWVuIGludGVyZXN0ZWQNCiBpbiB0aGlzIGZsb3cgZm9yIGEg
d2hpbGUgYnV0IHRoZSBvbmx5IGV4YW1wbGVzIEnigJltIGF3YXJlIG9mIGFyZSBzZWxmLWlzc3Vl
ZCBKV1RzLiZuYnNwOyBJ4oCZZCBiZSB2ZXJ5IGludGVyZXN0ZWQgaW4ga25vd2luZyByZWFsIGxp
ZmUgb2YgZXhhbXBsZXMgb2YgY2xpZW50cyBvYnRhaW5pbmcgYSBKV1QgYXNzZXJ0aW9uIGZyb20g
YW4gU1RTIHRvIHVzZSBhcyBhIGdyYW50LCBhbmQgdGhlIG1ldGhvZCB0aGV5IHVzZSB0byBkbyB0
aGF0Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDss
JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6b2xpdmUiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6U2ltU3VuIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250
LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6
b2xpdmUiPnR4PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Jvb2sgQW50aXF1YSZx
dW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpvbGl2ZSI+YWRhbTwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm
b250LWZhbWlseTomcXVvdDtCb29rIEFudGlxdWEmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s
b3I6b2xpdmUiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2Jv
cmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjppbml0aWFsIj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij48YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw
YW4+W21haWx0bzpvYXV0aC08YSBocmVmPSJtYWlsdG86Ym91bmNlc0BpZXRmLm9yZyI+Ym91bmNl
c0BpZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7
PC9zcGFuPjxiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+Jm5ic3A7PC9zcGFuPjwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPjxzcGFu
IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIERl
Y2VtYmVyIDA1LCAyMDEyIDg6MDUgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp6aG91LnN1amlu
Z0B6dGUuY29tLmNuIj56aG91LnN1amluZ0B6dGUuY29tLmNuPC9hPjxicj4NCjxiPkNjOjwvYj48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i
bWFpbHRvOm9hdXRoQGlldGYub3JnIj5vYXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0
OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6
IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlIHRv
IGJlIGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT88L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
U2ltU3VuIj5JIHNheSB0aGF0IGl0J3Mgb25seSB0aGVvcmV0aWNhbCBiZWNhdXNlIEkgZG9uJ3Qg
YmVsaWV2ZSB0aGVyZSBhcmUgYW55IGFjdHVhbCBkZXBsb3ltZW50cyBzdXBwb3J0aW5nLCBvciBw
bGFubmluZyBvbiBzdXBwb3J0aW5nLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJPDQogYXMgYW4gYXNzZXJ0aW9uIGlzc3Vl
ci48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPk9uIFR1ZSwgRGVjIDQsIDIwMTIgYXQg
NTozOSBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIiB0YXJn
ZXQ9Il9ibGFuayI+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPldoeSBSTyBhcyBhbiBpc3N1ZXIgaXMgb25seSB0aGVvcmV0aWNhbCB0
b2RheT88L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n
PSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+DQo8dHI+DQo8
dGQgd2lkdGg9IjM2JSIgdmFsaWduPSJ0b3AiIHN0eWxlPSJ3aWR0aDozNi4wJTtwYWRkaW5nOi43
NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWls
dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxA
cGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6U2ltU3VuIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+MjAxMi0xMi0wNCAyMzo0MTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6U2ltU3VuIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSI2
MyUiIHZhbGlnbj0idG9wIiBzdHlsZT0id2lkdGg6NjMuMCU7cGFkZGluZzouNzVwdCAuNzVwdCAu
NzVwdCAuNzVwdCI+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNl
bGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAwJSIgc3R5bGU9IndpZHRoOjEwMC4wJSI+DQo8dGJvZHk+
DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0
IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQt
YWxpZ246cmlnaHQiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2Zv
bnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5pS25Lu25Lq6PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43
NXB0IC43NXB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPk5hdCBTYWtpbXVyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWls
LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNha2ltdXJhQGdtYWlsLmNvbTwvYT4mZ3Q7PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv
ZGl2Pg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n
Oi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJy
aWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0i
Zm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpa
SC1DTiI+5oqE6YCBPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5n
Oi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzp6aG91LnN1amluZ0B6dGUu
Y29tLmNuIiB0YXJnZXQ9Il9ibGFuayI+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvYT4sICZxdW90
OzxhIGhyZWY9Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoQGll
dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9hdXRoQGlldGYub3JnIiB0YXJn
ZXQ9Il9ibGFuayI+b2F1dGhAaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8
L3RyPg0KPHRyPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAu
NzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0
ZXh0LWFsaWduOnJpZ2h0Ij48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo3LjVw
dDtmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuS4u+mimDwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L3RkPg0KPHRkIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAu
NzVwdCAuNzVwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij5SZTogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMg
aXNzdWVyIGhhdmUgdG8gYmUgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tl
biBzZXJ2aWNlPzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNp
bVN1biI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8dGFibGUgY2xhc3M9
Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIj4NCjx0Ym9keT4NCjx0
cj4NCjx0ZCB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1
cHQiPjwvdGQ+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43
NXB0IC43NXB0Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+
DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxi
cj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIGludGVudCB3YXMgZGVmaW5pdGVs
eSBub3QgdG8gY29uc3RyYWluIHdoby93aGF0IGNvdWxkIGJlIHRoZSBpc3N1ZXIuICZuYnNwO0J1
dCBhbHNvIHRyeSB0byBwcm92aWRlPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjxicj4NCnNvbWUgZ3VpZGFuY2UgYXJvdW5kIHRoZSBjb21tb24gY2FzZXMg
dGhhdCBhcmUgYWN0dWFsbHkgYmVpbmcgZGVwbG95ZWQgbm93LCB3aGljaCBhcmUgdGhlIGNsaWVu
dCBzZWxmLWlzc3VlZCBhbmQgU1RTIHZhcmlhbnRzLiBSZXNvdXJjZSBvd25lciBhcyBhbiBpc3N1
ZXIgaXMgYW4gaW50ZXJlc3RpbmcgY2FzZSBidXQgc2VlbXMgbW9zdGx5IHRoZW9yZXRpY2FsIGF0
IHRoaXMgcG9pbnQuPGJyPg0KPGJyPg0KSSBmZWVsIGxpa2UgbWVudGlvbmluZyB0aGUgcmVzb3Vy
Y2Ugb3duZXIgdGhlcmUgaW4gwqc1LjEgd291bGQgY2F1c2UgbW9yZSBjb25mdXNpb24gdGhhbiBh
bnl0aGluZyBlbHNlLiBJJ2QgcHJlZmVyIHRvIGp1c3Qgc3RyaWtlIHRoZSB3aG9sZSBzZW50ZW5j
ZSBpbiBxdWVzdGlvbiBhbmQgbWF5YmUgYWRkIHNvbWUgYWRkaXRpb25hbCB0ZXh0IHRvIMKnMyB0
aGF0IGNsYXJpZmllcyB0aGF0IHRoZSBpc3N1ZXIgY2FuIHJlYWxseSBiZSBhbnkgZW50aXR5LA0K
IGlmIGZvbGtzIHRoaW5rIGEgY2hhbmdlIGlzIG5lZWRlZCBoZXJlPzxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5P
biBNb24sIERlYyAzLCAyMDEyIGF0IDk6MjAgUE0sIE5hdCBTYWtpbXVyYSAmbHQ7PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBn
bWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+c2FraW11cmFAZ21haWwuY29tPC9z
cGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsNCiB3cm90ZTo8L3NwYW4+PHNwYW4gY2xhc3M9
ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+
DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPkFjdHVhbGx5LCAmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv
bG9yOiM1MDAwNTAiPlRoZSBpc3N1ZXIgbWF5IGJlIGVpdGhlcjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojNTAwMDUwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+
PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj4mbmJzcDsgJm5ic3A7ICZu
YnNwOyBhbiBPQXV0aCBjbGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9y
PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJj
b2xvcjpyZWQiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+YW55
IG90aGVyIGVudGl0eSwgZS5nLiwgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIy
MjIyIj5hDQogdGhpcmQgcGFydHk8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4N
Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj50b2tlbiBzZXJ2aWNlPC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOnJlZCI+LCByZXNvdXJjZSBvd25lcjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIy
MjIyIj4uICZxdW90OyAmbmJzcDtpcyBub3QgcmVhbGx5IGNsZWFuLjxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OlNpbVN1biI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjIi
Pk9BdXRoIGNsaWVudCBpcyBqdXN0IGFub3RoZXIgZXhhbXBsZSBvZiBhbiBpc3N1ZXIuPHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzIyMjIyMiI+U28sIHBlcmhhcHMgdGhlIHNlbnRlbmNlIGNvdWxkIGJlOjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMy
MjIyMjIiPiZxdW90O0V4YW1wbGUgb2YgaXNzdWVycyBpbmNsdWRlIGFuIE9BdXRoIGNsaWVudCwg
cmVzb3VyY2Ugb3duZXIsIGFuIGluZGVwZW5kZW50IHRoaXJkIHBhcnR5LiZxdW90Ozwvc3Bhbj48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpT
aW1TdW4iPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMjIyMjIyIj5TbywgdGhl
IGNsYXVzZSBiZWNvbWVzOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPGJy
Pg0KPC9zcGFuPiZuYnNwO0lzc3VlciAmbmJzcDtUaGUgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRo
ZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhlPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48YnI+DQombmJz
cDsgJm5ic3A7ICZuYnNwO2Fzc2VydGlvbi4gJm5ic3A7R2VuZXJhbGx5IHRoaXMgaXMgdGhlIGVu
dGl0eSB0aGF0IGhvbGRzIHRoZSBrZXk8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNw
OyAmbmJzcDsgJm5ic3A7bWF0ZXJpYWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNzZXJ0aW9uLiAm
bmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj4mbmJzcDsgJm5ic3A7ICZuYnNwOyBFeGFtcGxlIG9m
IGlzc3VlcnMgaW5jbHVkZSBhbiBPQXV0aCBjbGllbnQsIHJlc291cmNlIG93bmVyLCBhbiBpbmRl
cGVuZGVudCB0aGlyZCBwYXJ0eS48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPGJyPg0K
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij5OYXQ8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzIyMjIyMiI+TmF0PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPGJyPg0KPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij5PbiBUdWUsIERlYyA0LCAyMDEyIGF0IDExOjQwIEFNLCAmbHQ7PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9Im1haWx0bzp6aG91LnN1amlu
Z0B6dGUuY29tLmNuIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx
dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPnpob3Uuc3VqaW5nQHp0ZS5j
b20uY248L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1T
dW4iPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5DaHVjayBNb3J0aW1vcmUgJmx0Ozwvc3Bh
bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9Im1haWx0bzpj
bW9ydGltb3JlQHNhbGVzZm9yY2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHR0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Y21vcnRpbW9yZUBzYWxlc2Zv
cmNlLmNvbTwvc3Bhbj48L3R0PjwvYT48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iWkgtQ04i
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1s
YW5ndWFnZTpaSC1DTiI+5YaZ5LqOPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt
U3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTpTaW1TdW4iPjIwMTItMTItMDQNCiAxMDoyNjo1MDo8L3NwYW4+PC90dD48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpT
aW1TdW4iPjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7IFBsZWFzZSBmZWVsIGZyZWUgdG8gc3Vn
Z2VzdCBiZXR0ZXIgbGFuZ3VhZ2UuPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFu
Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8YnI+DQo8L3Nw
YW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
Jmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFu
Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyBJ
c3N1ZXIgc2ltcGx5IGFsbG93cyB0aGUgdG9rZW4gc2VydmljZSB0byBrbm93IHdobyBjcmVhdGVk
IHRoZTwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFu
Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyBh
c3NlcnRpb24sIHNvIGl0IGNhbiBsb29rIHRoZW0gdXAgYW5kIHNlZSBpZiB0aGV5J3JlIHRydXN0
ZWQuPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+
PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwv
dHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7IEVmZmVjdGl2ZWx5IHRoZSBzYW1lIGFzIGFu
IElzc3VlciBpbiBTQU1MLjwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPmEgY29uZmxpY3Qg
OiAmcXVvdDtUaGUgdG9rZW4gc2VydmljZSBpcyB0aGUgYXNzZXJ0aW9uIGlzc3VlciZxdW90OyBp
biBhc3NlcnRpb24gZG9jdW1lbnQuPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+d2hpbGUgeW91IHNhaWQg
JnF1b3Q7dG9rZW4gc2VydmljZSBrbm93IHdobyBjcmVhdGVkIHRoZSBhc3NlcnRpb24mcXVvdDs8
L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5JIHdvbmRlciBpZiB0aGUgZm9sbG93aW5nIHRl
eHQgaXMgYWNjZXB0YWJsZTo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3Nw
YW4+PGJyPg0KJm5ic3A7SXNzdWVyICZuYnNwO1RoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhl
IGVudGl0eSB0aGF0IGlzc3VlZCB0aGU8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxicj4NCiZuYnNw
OyAmbmJzcDsgJm5ic3A7YXNzZXJ0aW9uLiAmbmJzcDtHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50
aXR5IHRoYXQgaG9sZHMgdGhlIGtleTxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PGJyPg0KJm5ic3A7
ICZuYnNwOyAmbmJzcDttYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uICZu
YnNwO1RoZSBpc3N1ZXIgbWF5IGJlIGVpdGhlcjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPiZuYnNwOyAmbmJzcDsgJm5i
c3A7IGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3VlZCkgb3I8
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iY29sb3I6cmVk
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPmFueSBvdGhlciBl
bnRpdHksIGUuZy4sICZuYnNwOzwvc3Bhbj5hIHRoaXJkIHBhcnR5PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQp0b2tlbiBzZXJ2
aWNlPHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+LCByZXNvdXJjZSBvd25lcjwvc3Bhbj4uPHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4NCjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Ni4zLjwvc3Bh
bj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48
dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0Pjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPkNsaWVudA0K
IEFjdGluZyBvbiBCZWhhbGYgb2YgYSBVc2VyPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
Pjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3Nw
YW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
VGhlIElzc3VlciBvZiB0aGUgYXNzZXJ0aW9uIE1VU1QgaWRlbnRpZnkgdGhlIGVudGl0eSB0aGF0
IGlzc3VlZDwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4m
bmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5i
c3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+
PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwv
dHQ+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
dGhlDQogYXNzZXJ0aW9uIGFzIHJlY29nbml6ZWQgYnkgdGhlIEF1dGhvcml6YXRpb24gU2VydmVy
Ljwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwv
c3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0
Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPklm
DQogdGhlPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJz
cDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90
dD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5h
c3NlcnRpb24NCiBpcyBzZWxmLWlzc3VlZCwgdGhlIElzc3VlciBTSE9VTEQgYmUgdGhlICZxdW90
O2NsaWVudF9pZCZxdW90Oy48L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5i
c3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNw
Ozwvc3Bhbj48L3R0Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPklmDQogdGhlIGFzc2VydGlvbiB3YXMgaXNzdWVkIGJ5IGEgU2VjdXJpdHkgVG9r
ZW4gU2VydmljZSAoU1RTKSwgdGhlPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBw
bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4i
PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m
bmJzcDs8L3NwYW4+PC90dD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6U2ltU3VuIj5Jc3N1ZXINCiBTSE9VTEQgaWRlbnRpZnkgdGhlIFNUUyBhcyByZWNvZ25p
emVkIGJ5IHRoZSBBdXRob3JpemF0aW9uPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0i
YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy
dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T
dW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij4mbmJzcDs8L3NwYW4+PC90dD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U2ltU3VuIj5TZXJ2ZXIuPHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+SWYNCiB0aGUg
YXNzZXJ0aW9uIHdhcyBpc3N1ZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCB0aGU8L3NwYW4+PC9z
cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
U2ltU3VuO2NvbG9yOnJlZCI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtjb2xvcjpyZWQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OlNpbVN1bjtjb2xvcjpyZWQiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2NvbG9yOnJlZCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9
ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U2ltU3VuO2NvbG9yOnJlZCI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6cmVkIj4mbmJzcDs8L3NwYW4+PC90dD48dHQ+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOnJl
ZCI+SXNzdWVyDQogU0hPVUxEIGlkZW50aWZ5IHRoZSByZXNvdXJjZSBvd25lciBhcyByZWNvZ25p
emVkIGJ5IHRoZSBBdXRob3JpemF0aW9uPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOnJlZCI+PGJyPg0KPC9zcGFu
Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpyZWQiPiZuYnNwOzwvc3Bh
bj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtjb2xvcjpyZWQiPiZuYnNwOzwvc3Bh
bj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOnJlZCI+Jm5i
c3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOnJlZCI+Jm5i
c3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6
cmVkIj4mbmJzcDs8L3NwYW4+PC90dD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6U2ltU3VuO2NvbG9yOnJlZCI+U2VydmVyLjwvc3Bhbj48L3R0PjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPGJy
Pg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT
aW1TdW4iPiZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNw
Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9z
cGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4i
PiZndDsgLWNtb3J0PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyBPbiBEZWMgMywgMjAxMiwgYXQgNjoyMyBQ
TSwgJmx0Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhy
ZWY9Im1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIiB0YXJnZXQ9Il9ibGFuayI+PHR0Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+emhvdS5zdWpp
bmdAenRlLmNvbS5jbjwvc3Bhbj48L3R0PjwvYT48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48L3R0
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+
PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPiZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0K
PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T
dW4iPiZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwv
c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFu
Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZn
dDsgT2J2aW91c2x5LCBpdCBpcyBub3Qgc28gY2xlYXIgZnJvbSB0aGUgbGFuZ3VhZ2UgdGhlcmUu
PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7PC9zcGFu
PjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7PC9zcGFuPjwvdHQ+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7IENodWNrIE1vcnRpbW9yZSAm
bHQ7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGEgaHJlZj0i
bWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20iIHRhcmdldD0iX2JsYW5rIj48dHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5jbW9ydGltb3Jl
QHNhbGVzZm9yY2UuY29tPC9zcGFuPjwvdHQ+PC9hPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBsYW5n
PSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21zby1m
YXJlYXN0LWxhbmd1YWdlOlpILUNOIj7lhpnkuo48L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBw
bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+MjAxMi0xMi0wNA0KIDEwOjE3OjEyOjwvc3Bh
bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7PC9z
cGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgVGhl
cmUncyBubyByZWFzb24gd2h5IGl0IGNhbid0IGJlIHJlc291cmNlIG93bmVyIHRvZGF5Ljwvc3Bh
bj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48
dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFu
IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgT24gRGVjIDMsIDIwMTIsIGF0
IDY6MDYgUE0sICZsdDs8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu
Ij48YSBocmVmPSJtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbiIgdGFyZ2V0PSJfYmxhbmsi
Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPnpo
b3Uuc3VqaW5nQHp0ZS5jb20uY248L3NwYW4+PC90dD48L2E+PC9zcGFuPjx0dD48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsNCiAmbHQ7PC9zcGFu
PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGEgaHJlZj0ibWFpbHRvOnpo
b3Uuc3VqaW5nQHp0ZS5jb20uY24iIHRhcmdldD0iX2JsYW5rIj48dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj56aG91LnN1amluZ0B6dGUuY29tLmNu
PC9zcGFuPjwvdHQ+PC9hPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0OyB3cm90ZTo8L3NwYW4+PC90
dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0Ozwvc3Bhbj48L3R0
PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJiM0MzsxLjwvc3Bh
bj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7IEFuZCB3
aHkgaXQgd2FzIG5vdCBsb29rZWQgYXQgdGhhdCB0aW1lPzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9
ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0i
YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OlNpbVN1biI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdl
dD0iX2JsYW5rIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
U2ltU3VuIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvdHQ+PC9hPjwvc3Bhbj48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIGxh
bmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47bXNv
LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuWGmeS6jjwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4yMDEyLTEyLTA0DQogMDE6MzA6NTU6PC9z
cGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0
dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsg
Jmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFu
Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAm
Z3Q7ICZndDsgQWN0dWFsbHksIEkgdGhpbmsgaXQgaXMgYSBnb29kIHRpbWUgdG8gc3RhcnQgbG9v
a2luZyBhdCB0aGUgcmVzb3Vyc2U8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgb3duZXIgaXNzdWluZyBhc3NlcnRpb25z
QCAoSW50ZXJlc3RpbmdseSBlbm91Z2gsIEh1aS1MYW4gaGFkIGJyb3VnaHQ8L3NwYW4+PC90dD48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsg
dGhpcyB1cCBhIGNvdXBsZSBvZiB5ZWFycyBhZ28uKTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0Pjxz
cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgSWdvcjwvc3Bh
bj48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZn
dDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9z
cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+
PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0
OyAmZ3Q7ICZndDsgT24gMTIvMy8yMDEyIDM6NTggQU0sIE5hdCBTYWtpbXVyYSB3cm90ZTo8L3Nw
YW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7
IEkgc3VwcG9zZSwgeWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhhdCBhbGwgdGhlIHRpbWUu
PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsg
Jmd0OyBXaGV0aGVyIGl0IGlzIG9yIG5vdCwgaWYgaXQgaXMgc3RpbGwgb2ssIGl0IG1pZ2h0IGJl
IGJldHRlciB0bzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7
PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3Nw
YW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
Jmd0OyBjbGFyaWZ5IGl0Ljwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+
DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp
bVN1biI+Jmd0OyAmZ3Q7ICZndDsgV29yZCBsaWtlICZxdW90O3RoaXJkIHBhcnR5JnF1b3Q7IHRl
bmRzIHRvIGJlIGEgYml0IG9mIHByb2JsZW0gd2l0aG91dDwvc3Bhbj48L3R0PjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7IGNsZWFybHlkZWZpbmluZy48L3NwYW4+
PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7IEkg
aGFkIHNpbWlsYXIgZXhwZXJpZW5jZSBpbiBvdGhlciBmb3JhLjwvc3Bhbj48L3R0PjxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7IE5hdDwvc3Bhbj48
L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3Nw
YW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7
IFNlbnQgZnJvbSBpUGFkPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4m
bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4N
Cjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt
U3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1
biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48
YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgMjAxMi8xMi8wMyAwOjUyPC9zcGFuPjwvdHQ+PHR0Pjxz
cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T
dW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuOAgTwvc3Bhbj48L3R0Pjx0dD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZxdW90Ozwvc3Bhbj48
L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9Im1haWx0bzp6aG91
LnN1amluZ0B6dGUuY29tLmNuIiB0YXJnZXQ9Il9ibGFuayI+PHR0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+emhvdS5zdWppbmdAenRlLmNvbS5jbjwv
c3Bhbj48L3R0PjwvYT48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+JnF1b3Q7DQogJmx0Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9Im1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNu
IiB0YXJnZXQ9Il9ibGFuayI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OlNpbVN1biI+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvc3Bhbj48L3R0PjwvYT48L3Nw
YW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
Jmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFu
Pjwvc3Bhbj48dHQ+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+44GuPC9zcGFuPjwv
dHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAm
Z3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+
PC9zcGFuPjx0dD48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7jg6Hjg4Pjgrvjg7zj
grg8L3NwYW4+PC90dD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6U2ltU3VuIj46PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+
PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPiZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1
biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48
YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29u
dmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT
aW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1
biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7IGNvdWxkIGJlIFJlc291cmNlIG93bmVyPzwvc3Bh
bj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8
L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0Ozwv
c3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZn
dDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0
OyAmZ3Q7ICZxdW90O1RzY2hvZmVuaWcsIEhhbm5lcyAoTlNOIC0gRkkvRXNwb28pJnF1b3Q7ICZs
dDs8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YSBocmVmPSJt
YWlsdG86aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPmhhbm5lcy50c2No
b2ZlbmlnQG5zbi5jb208L3NwYW4+PC90dD48L2E+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDs8L3NwYW4+PC90dD48c3BhbiBj
bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBs
YW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuO21z
by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7lj5Hku7bkuro8L3NwYW4+PC90dD48dHQ+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj46PC9zcGFuPjwvdHQ+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlNpbVN1biI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U2ltU3VuIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvdHQ+PC9hPjwv
c3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+
DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp
bVN1biI+Jmd0OyAmZ3Q7ICZndDsgMjAxMi0xMi0wMyAxNjo0OTwvc3Bhbj48L3R0PjxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3Bh
biBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7mlLbku7bkuro8L3NwYW4+PC90dD48c3BhbiBj
bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwv
c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFu
Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZn
dDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJz
cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwv
c3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
Ij4mZ3Q7ICZndDsgJmd0OyAmcXVvdDtleHQgTmF0IFNha2ltdXJhJnF1b3Q7ICZsdDs8L3NwYW4+
PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YSBocmVmPSJtYWlsdG86c2Fr
aW11cmFAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+c2FraW11cmFAZ21haWwuY29tPC9zcGFuPjwv
dHQ+PC9hPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6U2ltU3VuIj4mZ3Q7LA0KICZxdW90O0JyaWFuIENhbXBiZWxsJnF1b3Q7ICZsdDs8L3NwYW4+
PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7
ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bh
bj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGEgaHJlZj0ibWFpbHRv
OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+PHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+YmNhbXBiZWxsQHBpbmdp
ZGVudGl0eS5jb208L3NwYW4+PC90dD48L2E+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDssDQogJnF1b3Q7b2F1dGgmcXVvdDsg
Jmx0Ozwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9
Im1haWx0bzpvYXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjx0dD48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPm9hdXRoQGlldGYub3JnPC9zcGFu
PjwvdHQ+PC9hPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6U2ltU3VuIj4mZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxi
cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp
bVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu
Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIGxhbmc9IlpILUNOIiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3Vh
Z2U6WkgtQ04iPuaKhOmAgTwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjtt
c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90
dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFu
PjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0
dD48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7kuLvpopg8L3NwYW4+PC90dD48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNw
Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9z
cGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4i
PiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4m
bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4N
Cjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt
U3VuIj4mZ3Q7ICZndDsgJmd0OyBSZTogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0g
V2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8gYmU8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJz
cDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0
OyAmZ3Q7IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT88
L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAm
Z3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZn
dDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9z
cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+
PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0
OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNw
Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9z
cGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4i
PiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4m
bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4N
Cjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt
U3VuIj4mZ3Q7ICZndDsgJmd0OyBIaSBOYXQsPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpT
aW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0
ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1
biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48
YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgVGhlIGN1cnJlbnQgdGV4dCBlc3NlbnRpYWxseSBzYXlz
IHRoYXQgdGhlIGFzc2VydGlvbiBjYW4gZWl0aGVyIGJlPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9
ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0OyBjcmVhdGVkIGJ5IHRoZSBjbGll
bnQgKGluIHdoaWNoIGNhc2UgaXQgaXMgc2VsZi1zaWduZWQpIG9yIGl0IGNhbiBiZTwvc3Bhbj48
L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsg
Jmd0OyBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5ICh3aGljaCBpcyB0aGVuIGNhbGxlZCB0
aGUgdGhpcmQgcGFydHk8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0K
PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T
dW4iPiZndDsgJmd0OyAmZ3Q7IHRva2VuIHNlcnZpY2UpLiBTbywgdGhpcyB0aGlyZCBwYXJ0eSBj
b3VsZCBiZSB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9
ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2lt
U3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgQ2lhbzwvc3Bhbj48L3R0PjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0OyBIYW5uZXM8L3Nw
YW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7
PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9z
cGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48
L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNs
YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgRnJvbTo8L3NwYW4+PC90
dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGEgaHJlZj0ibWFpbHRvOm9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvdHQ+
PC9hPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3Nw
YW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
W21haWx0bzo8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YSBo
cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC90dD48L2E+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPl0NCiBPbiBCZWhhbGYgT2Y8L3NwYW4+
PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7IGV4
dCBOYXQgU2FraW11cmE8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu
Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAx
MiAxMDozNSBBTTwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxi
cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
U2ltU3VuIj4mZ3Q7ICZndDsgJmd0OyBUbzogQnJpYW4gQ2FtcGJlbGw7IG9hdXRoPC9zcGFuPjwv
dHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAm
Z3Q7IFN1YmplY3Q6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlz
c3VlciBoYXZlIHRvIGJlPC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1
biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQg
cGFydHkgdG9rZW4gc2VydmljZT88L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy
dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T
dW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+
PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJz
cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwv
c3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
Ij4mZ3Q7ICZndDsgJmd0OyBIaSBCcmlhbiw8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNp
bVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxi
cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp
bVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7
PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3Nw
YW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
Jmd0OyAmZ3Q7ICZndDsgVGhlIGFzc2VydGlvbiBmcmFtZXdvcmsgZGVmaW5lcyB0aGUgSXNzdWVy
IGFzOjwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFu
Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAm
Z3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwv
c3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3Nw
YW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7
PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9z
cGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+
PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+SXNzdWVyPC9zcGFuPjwv
dHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0PjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+VGhlDQogdW5pcXVl
IGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQgdGhlPC9zcGFuPjwvdHQ+PHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0
PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp
bVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7
PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6U2ltU3VuIj5hc3NlcnRpb24uPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt
U3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+R2VuZXJhbGx5DQogdGhpcyBpcyB0aGUgZW50aXR5IHRoYXQgaG9s
ZHMgdGhlIGtleTwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7
PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3Nw
YW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJz
cDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90
dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFz
cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+bWF0ZXJpYWwNCiB1c2VkIHRvIGdl
bmVyYXRlIHRoZSBhc3NlcnRpb24uPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt
U3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+VGhlIGlzc3Vlcg0KIG1heSBiZSBlaXRoZXI8L3NwYW4+PC90dD48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwv
dHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJz
cDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpTaW1TdW4iPmFuDQogT0F1dGggY2xpZW50ICh3aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYt
aXNzdWVkKSBvciBhIHRoaXJkIHBhcnR5PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNv
bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1T
dW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZu
YnNwOzwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFu
Pjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48
L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48dHQ+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj50b2tlbg0K
IHNlcnZpY2UuPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8
L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bh
bj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4m
Z3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5i
c3A7PC9zcGFuPjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNw
Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwv
c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0Pjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7
ICZndDsgSSB3YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8gYmUgZWl0aGVyIHRoZSBjbGllbnQg
b3IgYSB0aGlyZCBwYXJ0eTwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+
DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp
bVN1biI+Jmd0OyAmZ3Q7ICZndDsgdG9rZW4gc2VydmljZS48L3NwYW4+PC90dD48c3BhbiBjbGFz
cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7IENvbmNlcHR1YWxseSwgaXQg
Y291bGQgYmUgYW55IHRva2VuIHNlcnZpY2UgKGZ1bmN0aW9uYWxpdHkpPC9zcGFuPjwvdHQ+PHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgcmVzaWRpbmdpbiBhbnkg
b2Y8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0
OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3Nw
YW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFu
PjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0OyB0
aGUgc3Rha2Vob2xkZXJzIChSZXNvdXJjZSBPd25lciwgT0F1dGggQ2xpZW50LCBBdXRob3JpemF0
aW9uIFNlcnZlciwgb3I8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0K
PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T
dW4iPiZndDsgJmd0OyAmZ3Q7IGEgdGhpcmQgcGFydHkpLjwvc3Bhbj48L3R0PjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBj
bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNp
bVN1biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFw
cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxi
cj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
U2ltU3VuIj4mZ3Q7ICZndDsgJmd0OyBJIHdvdWxkIGFwcHJlY2lhdGUgaWYgeW91IGNvdWxkIGNs
YXJpZnkgd2h5IGlzIHRoZSBjYXNlLjwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252
ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp
bVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu
Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw
YWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZu
YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0K
PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T
dW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+
Jm5ic3A7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3Nw
YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48
dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7
ICZndDsgJmd0OyBCZXN0LDwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+
Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+
DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNp
bVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy
dGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1T
dW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
Ij4mbmJzcDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwv
c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFu
Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZn
dDsgJmd0OyAmZ3Q7IC0tPC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z
cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4m
bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4N
Cjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2lt
U3VuIj4mZ3Q7ICZndDsgJmd0OyBOYXQgU2FraW11cmEgKD1uYXQpPC9zcGFuPjwvdHQ+PHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0OyBDaGFpcm1hbiwgT3Bl
bklEIEZvdW5kYXRpb248L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3Vu
Ij48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNp
bVN1biI+PGEgaHJlZj0iaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvIiB0YXJnZXQ9Il9ibGFuayI+
PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+aHR0
cDovL25hdC5zYWtpbXVyYS5vcmcvPC9zcGFuPjwvdHQ+PC9hPjxicj4NCjwvc3Bhbj48dHQ+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsg
Jmd0OyBAX25hdF9lbjwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5i
c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8
L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1
biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4i
PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4m
bmJzcDs8L3NwYW4+PC90dD48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6U2ltU3VuIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzwvc3Bhbj48L3R0PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwv
c3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
Ij4mZ3Q7ICZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8L3NwYW4+PC90dD48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDs8L3NwYW4+PC90
dD48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3Jn
IiB0YXJnZXQ9Il9ibGFuayI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OlNpbVN1biI+T0F1dGhAaWV0Zi5vcmc8L3NwYW4+PC90dD48L2E+PGJyPg0KPC9zcGFu
Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZn
dDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJz
cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js
YW5rIj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3Vu
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvdHQ+
PC9hPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDs8L3NwYW4+PC90dD48c3BhbiBjbGFzcz0iYXBwbGUtY29u
dmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpT
aW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1
biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpT
aW1TdW4iPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0
PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFu
Pjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZn
dDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mbmJz
cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9
Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjx0dD48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPk9BdXRoQGlldGYub3JnPC9zcGFu
PjwvdHQ+PC9hPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48L3R0PjxzcGFuIGNsYXNz
PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6U2ltU3VuIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu
MHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aDwvc3Bhbj48L3R0PjwvYT48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PC90dD48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7ICZndDsgT0F1
dGggbWFpbGluZyBsaXN0PC9zcGFuPjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1
biI+PGJyPg0KPC9zcGFuPjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpTaW1TdW4iPiZndDsgJmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpT
aW1TdW4iPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjx0
dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPk9BdXRo
QGlldGYub3JnPC9zcGFuPjwvdHQ+PC9hPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDsgJmd0Ozwvc3Bhbj48
L3R0PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+PHR0PjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvc3Bhbj48L3R0PjwvYT48YnI+DQo8L3NwYW4+PHR0
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAm
Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFu
PjwvdHQ+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGJyPg0KPC9zcGFuPjx0dD48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZndDsgJmd0
OyBPQXV0aCBtYWlsaW5nIGxpc3Q8L3NwYW4+PC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
U2ltU3VuIj48YnI+DQo8L3NwYW4+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OlNpbVN1biI+Jmd0OyAmZ3Q7PC9zcGFuPjwvdHQ+PHNwYW4gY2xhc3M9ImFwcGxl
LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpT
aW1TdW4iPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjx0
dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPk9BdXRo
QGlldGYub3JnPC9zcGFuPjwvdHQ+PC9hPjxicj4NCjwvc3Bhbj48dHQ+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj4mZ3Q7ICZndDs8L3NwYW4+PC90dD48
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPjx0dD48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC90dD48L2E+PC9zcGFuPjx0dD48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPiZuYnNwOzwvc3Bhbj48L3R0
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQpPQXV0aCBtYWlsaW5nIGxpc3Q8dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+PGJyPg0KPC9z
cGFuPjwvdT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGEgaHJlZj0i
bWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9BdXRoQGll
dGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90
O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PGJyPg0KPC9z
cGFuPjwvdT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj48YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+
PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp
YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS08c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KTmF0IFNh
a2ltdXJhICg9bmF0KTwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U2ltU3VuIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q2hhaXJt
YW4sIE9wZW5JRCBGb3VuZGF0aW9uPHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxicj4NCjwv
c3Bhbj48L3U+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9
Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5odHRw
Oi8vbmF0LnNha2ltdXJhLm9yZy88L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KQF9u
YXRfZW48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6U2ltU3VuIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGgg
bWFpbGluZyBsaXN0PHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxicj4NCjwvc3Bhbj48L3U+
PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4iPjxhIGhyZWY9Im1haWx0bzpP
QXV0aEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PQXV0aEBpZXRmLm9yZzwv
c3Bhbj48L2E+PC9zcGFuPjx1PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxicj4NCjwvc3Bhbj48L3U+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OlNpbVN1biI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6U2ltU3VuIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpTaW1TdW4i
PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVv
dDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+X19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_fb726c293bea4abc9aa954746b61b30aBY2PR03MB041namprd03pro_--

From stephen.farrell@cs.tcd.ie  Mon Dec 10 02:20:44 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A657E21F8E57 for ; Mon, 10 Dec 2012 02:20:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nh49bZANDwk for ; Mon, 10 Dec 2012 02:20:43 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A081C21F8937 for ; Mon, 10 Dec 2012 02:20:43 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7ACB7BE5C; Mon, 10 Dec 2012 10:20:18 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miHSpKjZNrJY; Mon, 10 Dec 2012 10:20:13 +0000 (GMT)
Received: from [IPv6:2001:770:10:203:3518:1c12:ec5f:b43a] (unknown [IPv6:2001:770:10:203:3518:1c12:ec5f:b43a]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CD5F6BE3F; Mon, 10 Dec 2012 10:20:13 +0000 (GMT)
Message-ID: <50C5B75E.80200@cs.tcd.ie>
Date: Mon, 10 Dec 2012 10:20:14 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <3B84788E-05E5-4AE4-B819-458BBBB36664@gmx.net>
In-Reply-To: <3B84788E-05E5-4AE4-B819-458BBBB36664@gmx.net>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Writeup for Assertion Framework for OAuth 2.0 
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Dec 2012 10:20:44 -0000

Hi Hannes, all,

Sorry to have been slow with the AD review here. I've only
a few comments (below) that can be handled as IETF LC
comments. Any changes as a result of the recent thread on
the definition of Issuer can also be done then.

Unless someone tells me to hold off for a new version, I'll
request IETF LC for this later today.

Thanks,
S.

section 3, 2nd para: this says that an Issuer "signs"
assertions, I think you do include MACing as well, right? If
so, better to say so, so maybe s/signs/integrity protects/
would be better? If you are going to stick with "sign" to mean
either digital signature or MAC, then please say so
explicitly.

s3, 3rd para: if assertions MUST be signed, then MUST they
also be verified by RPs? I think you should say.

5.2: "The Audience SHOULD be the URL of the Authorization
Server's Token Endpoint" - are there any issues there with URL
comparisons that need to be specified here? Or is that
something to do for a specific type of assertion? Either way,
might be good to say.


From Adam.Lewis@motorolasolutions.com  Mon Dec 10 06:34:23 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE5121F843A for ; Mon, 10 Dec 2012 06:34:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.434
X-Spam-Level: 
X-Spam-Status: No, score=0.434 tagged_above=-999 required=5 tests=[AWL=-0.299,  BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Itp16aeE8Xh6 for ; Mon, 10 Dec 2012 06:34:22 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCBE21F8427 for ; Mon, 10 Dec 2012 06:34:22 -0800 (PST)
Received: from mail218-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Dec 2012 14:34:21 +0000
Received: from mail218-ch1 (localhost [127.0.0.1])	by mail218-ch1-R.bigfish.com (Postfix) with ESMTP id 43E7830007B	for ; Mon, 10 Dec 2012 14:34:21 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:192.160.210.14; KIP:(null); UIP:(null); IPV:NLI; H:ct11msg02.am.mot-solutions.com; RD:ct11msg02.mot-solutions.com; EFVD:NLI
X-SpamScore: 0
X-BigFish: VPS0(zzd772hzz1de0h1202h1e76h1d1ah1d2ahzzz2fh2a8h683h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h)
Received-SPF: pass (mail218-ch1: domain of motorolasolutions.com designates 192.160.210.14 as permitted sender) client-ip=192.160.210.14; envelope-from=Adam.Lewis@motorolasolutions.com; helo=ct11msg02.am.mot-solutions.com ; olutions.com ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT005.namprd04.prod.outlook.com; R:internal; EFV:INT
Received: from mail218-ch1 (localhost.localdomain [127.0.0.1]) by mail218-ch1 (MessageSwitch) id 1355150059196394_12333; Mon, 10 Dec 2012 14:34:19 +0000 (UTC)
Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.248])	by mail218-ch1.bigfish.com (Postfix) with ESMTP id 2C449220140	for ; Mon, 10 Dec 2012 14:34:19 +0000 (UTC)
Received: from ct11msg02.am.mot-solutions.com (192.160.210.14) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Dec 2012 14:34:18 +0000
Received: from ct11msg02.am.mot-solutions.com (ct11vts02.am.mot.com [10.177.16.160])	by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qBAEgPbR020347	for ; Mon, 10 Dec 2012 09:42:25 -0500 (EST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14])	by ct11msg02.am.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qBAEgP3v020343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)	for ; Mon, 10 Dec 2012 09:42:25 -0500 (EST)
Received: from mail250-va3-R.bigfish.com (10.7.14.249) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.23; Mon, 10 Dec 2012 14:34:17 +0000
Received: from mail250-va3 (localhost [127.0.0.1])	by mail250-va3-R.bigfish.com (Postfix) with ESMTP id 1DC851F000A5	for ; Mon, 10 Dec 2012 14:34:17 +0000 (UTC)
Received: from mail250-va3 (localhost.localdomain [127.0.0.1]) by mail250-va3 (MessageSwitch) id 1355150055725820_24358; Mon, 10 Dec 2012 14:34:15 +0000 (UTC)
Received: from VA3EHSMHS044.bigfish.com (unknown [10.7.14.254])	by mail250-va3.bigfish.com (Postfix) with ESMTP id ACA99C80047	for ; Mon, 10 Dec 2012 14:34:15 +0000 (UTC)
Received: from BY2PRD0411HT005.namprd04.prod.outlook.com (157.56.237.133) by VA3EHSMHS044.bigfish.com (10.7.99.54) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 10 Dec 2012 14:34:15 +0000
Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.29]) by BY2PRD0411HT005.namprd04.prod.outlook.com ([10.255.128.40]) with mapi id 14.16.0245.002; Mon, 10 Dec 2012 14:34:15 +0000
From: Lewis Adam-CAL022 
To: "oauth@ietf.org" 
Thread-Topic: Using structured access_token as grant type in assertion flow
Thread-Index: Ac3W42nKt4Mswah8RDOXfGGOokwy+w==
Date: Mon, 10 Dec 2012 14:34:14 +0000
Message-ID: <59E470B10C4630419ED717AC79FCF9A92F1B2F99@BY2PRD0411MB441.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-puzzleid: {E33158BC-25F8-4093-A947-886E4CA762A7}
x-cr-hashedpuzzle: AMYa CK5N DEu3 DGVR EROV EwzT FCcg FPVQ FWK/ FWlk G4ZP HQMh Irsk JdhD MUn8 NCEa; 1; bwBhAHUAdABoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {E33158BC-25F8-4093-A947-886E4CA762A7}; YQBkAGEAbQAuAGwAZQB3AGkAcwBAAG0AbwB0AG8AcgBvAGwAYQBzAG8AbAB1AHQAaQBvAG4AcwAuAGMAbwBtAA==; Mon, 10 Dec 2012 14:34:08 GMT; VQBzAGkAbgBnACAAcwB0AHIAdQBjAHQAdQByAGUAZAAgAGEAYwBjAGUAcwBzAF8AdABvAGsAZQBuACAAYQBzACAAZwByAGEAbgB0ACAAdAB5AHAAZQAgAGkAbgAgAGEAcwBzAGUAcgB0AGkAbwBuACAAZgBsAG8AdwA=
x-originating-ip: [150.130.141.249]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-CFilter-Loop: Reflected
X-OriginatorOrg: motorolasolutions.com
Subject: [OAUTH-WG] Using structured access_token as grant type in assertion flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Dec 2012 14:34:23 -0000

Hi,

I continue to have an interest in the OAuth assertion profiles for my use c=
ases.  I'm wondering if the idea of performing a first OAuth dance which re=
turns to the client a structured JWT access token (with scope=3DAS for exam=
ple) could then be used as the JWT in an assertion grant type?  So somethin=
g like this (I show the RO credential flow since it is the simplest to draw=
, but same idea for the code flow):


Client		AS
|			|
|---------------->| (authorization request scope=3DAS, grant_type=3DRO pass=
word credentials)
|			|
|<----------------| (token response with access_token scoped to AS)
|			|
|---------------->| (authorization request, scope=3Dxyz, grant_type=3DJWT a=
ssertion as obtained from previous step)
|			|
|<----------------| (token response with access token scoped to xyz)



I suppose there is nothing in theory which should prevent this, but I am wo=
ndering if anybody else has thought of such a usage. =20



From iesg-secretary@ietf.org  Mon Dec 10 10:33:58 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B95C21F8596; Mon, 10 Dec 2012 10:33:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.501
X-Spam-Level: 
X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8k1Yc+26Zqt; Mon, 10 Dec 2012 10:33:57 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE2EF21F8510; Mon, 10 Dec 2012 10:33:57 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.36
Message-ID: <20121210183357.31726.20901.idtracker@ietfa.amsl.com>
Date: Mon, 10 Dec 2012 10:33:57 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] Last Call:  (Assertion Framework	for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 10 Dec 2012 18:33:58 -0000

The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'Assertion Framework for OAuth 2.0'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-12-24. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This specification provides a framework for the use of assertions
   with OAuth 2.0 in the form of a new client authentication mechanism
   and a new authorization grant type.  Mechanisms are specified for
   transporting assertions during interactions with a token endpoint, as
   well as general processing rules.

   The intent of this specification is to provide a common framework for
   OAuth 2.0 to interwork with other identity systems using assertions,
   and to provide alternative client authentication mechanisms.

   Note that this specification only defines abstract message flows and
   processing rules.  In order to be implementable, companion
   specifications are necessary to provide the corresponding concrete
   instantiations.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/


No IPR declarations have been submitted directly on this I-D.



From zhou.sujing@zte.com.cn  Mon Dec 10 17:42:15 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8AA21F86DA; Mon, 10 Dec 2012 17:42:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.986
X-Spam-Level: 
X-Spam-Status: No, score=-98.986 tagged_above=-999 required=5 tests=[AWL=1.184, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_26=0.6, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cMuKwt8rxH7; Mon, 10 Dec 2012 17:42:12 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DB59D21F860F; Mon, 10 Dec 2012 17:42:11 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 62EBD5C2A37; Tue, 11 Dec 2012 09:43:59 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 56851711827; Tue, 11 Dec 2012 09:31:08 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBB1ftYt094985; Tue, 11 Dec 2012 09:41:55 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Brian Campbell , "oauth@ietf.org" , "oauth-bounces@ietf.org" , Nat Sakimura 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Tue, 11 Dec 2012 09:41:51 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-11 09:41:53, Serialize complete at 2012-12-11 09:41:53
Content-Type: multipart/alternative; boundary="=_alternative 0009729D48257AD1_="
X-MAIL: mse02.zte.com.cn qBB1ftYt094985
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Dec 2012 01:42:15 -0000

This is a multipart message in MIME format.
--=_alternative 0009729D48257AD1_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SW4gInNlY3Rpb24gMw0KIFRoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVy
OyBpdHMNCiByb2xlIGlzIHRvIGZ1bGZpbGwgcmVxdWVzdHMgZnJvbSBjbGllbnRzLCB3aGljaCBw
cmVzZW50IHZhcmlvdXMNCiBjcmVkZW50aWFscywgYW5kIG1pbnQgYXNzZXJ0aW9ucyBhcyByZXF1
ZXN0ZWQsIGZpbGwgdGhlbSB3aXRoDQogYXBwcm9wcmlhdGUgaW5mb3JtYXRpb24sIGFuZCBzaWdu
IHRoZW0uIg0KDQoNCkFzIEkgdW5kZXJzdGFuZCwgYW4gYXNzZXJ0aW9uIGdlbmVyYXRlZCBieSBh
IFNUUywgaXMgZG9uZSBmbG9sbG93aW5nIHRoZXNzIA0Kc3RlcHM6DQoxLiBDbGllbnQgcHJlc2Vu
dHMgY3JlZGVudGlhbCBhbmQgcmVxdWVzdHMgYW4gYXNzZXJ0aW9uDQoyLiBTVFMgZ2VuZXJhdGVz
IGFzc2VydGlvbiBhbmQgc2VuZHMgdG8gQ2xpZW50DQpDb3JyZWN0Pw0KDQpJdCBpcyBhbiBpbnRl
cmFjdGl2ZSBwcm9jZXNzLCBidXQgdGhlcmUgYXJlIGNhc2VzIHRoYXQgY3JlZGVudGlhbCBmcm9t
IA0KY2xpZW50IGlzIG5vdCBuZWNlc3NhcnksDQplLmcuIG15IFJPIGlzc3VlciB1c2UgY2FzZToN
CjEuIFJPIGdlbmVyYXRlIGEgZGVsZWdhdGlvbiBzdGF0ZW1lbnQgc3BlY2lmeWluZyBjbGllbnQt
bmFtZSBoYXMgdGhlIHJpZ2h0IA0KdG8gZG8gc29tZXRoaW5nLCBzaWducyBpdCwgc2VuZHMgdG8g
Y2xpZW50Lg0KDQpObyBjbGllbnQgY3JlZGVudGlhbCBpcyBuZWVkZWQsIGFuZCBldmVuIHJlcXVl
c3QgZnJvbSBjbGllbnQgaXMgbm90IA0KbmVlZGVkLg0KDQpBbnkgY29tbWVudHM/IA0KIA0KDQpa
aG91U3VKaW5nMDAxMzI4MzEvdXNlci96dGVfbHRkIOWGmeS6jiAyMDEyLTEyLTA3IDA4OjE3OjAw
Og0KDQo+IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4g5YaZ5LqO
IDIwMTItMTItMDcgMDc6MDM6Mzg6DQo+IA0KPiA+IEEgcXVlc3Rpb24gZm9yIHRoZSBjaGFpcnMg
b3Igb3RoZXJzIG1vcmUgdmVyc2VkIGluIHRoZSB3b3JraW5ncyBvZiANCj4gPiB0aGUgSUVURiAt
IGlzIHRoaXMgZG9jdW1lbnQgZXZlbiBpbiBhIHBsYWNlIHdoZXJlIGNoYW5nZXMgY2FuIGJlIA0K
PiA+IG1hZGU/IFRoZSBTaGVwaGVyZCBXcml0ZS1VcCBmb3IgdGhlIGRvY3VtZW50IHdhcyByZWNl
bnRseSBzZW50IHRvIA0KPiA+IHRoZSBJRVNHIFNlY3JldGFyeSBhbmQgSSdtIGhvbmVzdGx5IG5v
dCBzdXJlIHdoYXQgdGhlIHByb3RvY29sIGlzIA0KPiA+IGZvciBtYWtpbmcgY2hhbmdlcyBhdCB0
aGlzIHBvaW50Lg0KPiBPciB3ZSBjYW4gc3RhcnQgYSBuZXcgZHJhZnQgZXh0ZW5kaW5nIGFuZCBj
bGFyaWZ5aW5nIHRoZSBhc3NlcnRpb24gDQpkb2N1bWVudCwNCj4gbW9yZSB1c2UgY2FzZXMgY291
bGQgYmUgaW1wbGVtZW50ZWQgYnkgYXNzZXJ0aW9uIG1heSBiZSBpbmNsdWRlZCwgDQo+IGFuZCBv
dGhlciB0aGluZ3MuLi4NCj4gDQo+ID4gDQo+ID4gDQo+ID4gDQoNCj4gPiANCg0KPiA+IE9uIFRo
dSwgRGVjIDYsIDIwMTIgYXQgMTI6NTAgQU0sIE5hdCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwu
Y29tPiANCndyb3RlOg0KPiA+IEhlcmUsIEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGRpZmZlcmVu
dGlhdGUgdGhlIGVudGl0eSBhbmQgDQpmdW5jdGlvbi9yb2xlLiANCj4gPiANCj4gPiBBdXRob3Jp
emF0aW9uIFNlcnZlciBpbiBPQXV0aCBpcyAia2luZCBvZiIgZW50aXR5LiANCj4gPiBJdHMgZnVu
Y3Rpb24gYWN0dWFsbHkgaXMgc3BsaXQgaW50byB0d28sIG9yIGluIG1vc3QgY2FzZXMgdGhyZWUu
IA0KPiA+IA0KPiA+IDEuIEF1dGhlbnRpY2F0aW9uIEVuZHBvaW50DQo+ID4gMi4gQXV0aG9yaXph
dGlvbiBFbmRwb2ludA0KPiA+IDMuIFRva2VuIEVuZHBvaW50DQo+ID4gDQo+ID4gTm93LCAiQXNz
ZXJ0aW9uIFZlcmlmaWVyIiBpcyBhIGZ1bmN0aW9uL3JvbGUuIEl0IGlzIHBlcmZvcm1lZCBieSAz
LiANCj4gPiBUb2tlbiBFbmRwb2ludC4gDQo+ID4gSXQgY2hlY2sgdGhlIHZhbGlkaXR5LCBhbmQg
aXNzdWVzIGFjY2VzcyB0b2tlbnMgKHdoaWNoIGluIHR1cm4gY2FuIA0KPiA+IGJlIGFub3RoZXIg
YXNzZXJ0aW9uIGJ5IHRoZSB3YXkuKQ0KPiA+IA0KPiA+IEF1dGhvcml6YXRpb24gRW5kcG9pbnQg
aXMgYW5vdGhlciBmdW5jdGlvbi4gSXQgY2FuIGJlIGxvY2F0ZWQgDQo+ID4gYW55d2hlcmUuIElu
IHlvdXIgY2FzZSwgaXQgaXMgbG9jYXRlZCBpbiB3aGF0IHlvdSBjYWxsIGFzIFJlc291cmNlIA0K
PiA+IE93bmVyIChCcm93c2VyIHBsdWctaW4/KSBJbiBteSBTZWxmLUlzc3VlZCBJZFAgY2FzZSwg
aXQgaXMgaXNzdWVkIGJ5DQo+ID4gdGhlIEFwcCBpbiB0aGUgcGhvbmUgd2hpY2ggaXMgY2FsbGVk
IGJ5IHRoZSBjdXN0b20gc2NoZW1hLiANCj4gPiANCj4gPiBUaGlzIGlzIHRoZSByZWFzb24gd2h5
IEkgY29uc3RhbnRseSBncnVtYmxlIHRoYXQgaXQgaXMgYmV0dGVyIHRvIA0KPiA+IHNwZWFrIGlu
IHRlcm1zIG9mIGZ1bmN0aW9ucyByYXRoZXIgdGhhbiBlbnRpdGllcy4gDQo+ID4gRnVuY3Rpb25z
IG1heSByZXNpZGUgaW4gYW55IGVudGl0eSwgYW5kIGlmIHdlIHRhbGsgb25seSBpbiB0ZXJtcyBv
ZiANCj4gPiB0aGUgZW50aXRpZXMsIHRoZSBjb21iaW5hdGlvbiB3aWxsIGV4cGxvZGUuIA0KPiA+
IA0KPiA+IE5hdA0KPiA+IA0KPiA+IE9uIFRodSwgRGVjIDYsIDIwMTIgYXQgOTo0NiBBTSwgPHpo
b3Uuc3VqaW5nQHp0ZS5jb20uY24+IHdyb3RlOg0KPiA+IA0KPiA+IEFzIEkgdW5kZXJzdGFuZCwg
Uk89aXNzdWVyICBkb2VzIG5vdCBtZWFuIFJPPUFTLiANCj4gPiBSTyBhcyBhbiBpc3N1ZXIgZ2Vu
ZXJhdGVzIGFzc2VydGlvbiAoaWYgdGhlIGFzc2VydGlvbiBpcyBzaW1pbGFyIHRvIA0KPiA+IGRl
bGVnYXRpb24gc3RhdGVtZW50IGluIG15IHVzZSBjYXNlcyksIA0KPiA+IEFTIGFzIGFuIGFzc2Vy
dGlvbiB2ZXJpZmllciByZWNlaXZlcyB0aGUgYXNzZXJ0aW9uIGFuZCBjaGVjayBpdHMgDQp2YWxp
ZGl0eS4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDlhpnk
uo4gMjAxMi0xMi0wNiAwMTozNToxMDoNCj4gPiANCj4gPiANCj4gPiA+IEp1c3QgY2hlY2tpbmcg
dGhhdCBJIHVuZGVyc3RhbmQ6IElmIHRoZSBSTyA9PSB0aGUgaXNzdWVyLCB0aGVuIHRoZSANCj4g
PiA+IFJPID09IHRoZSBBUywgcmlnaHQ/IEp1c3QgYXMgaW4gTmF0J3MgZXhhbXBsZSwgdGhlIHVz
ZXIgKG9yIGF0IGxlYXN0DQo+ID4gPiB0aGUgZGV2aWNlIHByZXNlbnRpbmcgYSB1c2VyIGFnZW50
IHRvIHRoZW0pID09IHRoZSBJZFA/IENvbG9jYXRpbmcgDQo+ID4gPiB0aGUgUk8gYW5kIEFTIGZ1
bmN0aW9ucyBzaG91bGRuJ3QgYmUgcHJlY2x1ZGVkLCBidXQgSSB3b3VsZCBiZSANCj4gPiA+IGF3
ZnVsbHkgY29uZnVzZWQgaWYgdGhlcmUgd2VyZSBhbiBSTy9pc3N1ZXIgaW4gdGhlIHBpY3R1cmUg
YW5kIA0KPiA+ID4gKmFsc28qIGFuIEFTIHRoYXQgKmRvZXNuJ3QqIGlzc3VlIGFzc2VydGlvbnMu
DQo+ID4gDQo+ID4gPiANCj4gPiA+IEV2ZSANCj4gPiA+IA0KPiA+ID4gT24gNSBEZWMgMjAxMiwg
YXQgOToxMyBBTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+IHdyb3RlOiANCj4g
PiA+IA0KPiA+ID4gSXQgaXMgbm90IE9BdXRoLCBidXQgQXVzdHJpYW4gZUlEIHN5c3RlbSBpcyBh
biBleGFtcGxlIG9mIFJPIGFzIGFuIA0KPiA+ID4gYXNzZXJ0aW9uIGlzc3VlciBwYXR0ZXJuLiBU
aGV5IGhhdmUgdGhlaXIgb3duIFNBTUwgSWRQIG9uIHRoZWlyIFBDIA0KPiA+ID4gKGF0IGxlYXN0
IGEgZmV3IHllYXJzIGFnbykgYW5kIGNvbWJpbmVkIHdpdGggdGhlIHF1YWxpZmllZCBjZXJ0cyBp
biANCj4gPiA+IHRoZSB1c2VyJ3Mgc21hcnQgY2FyZCBhbmQgYW5vdGhlciBmaWxlLCBjcmVhdGVz
IGEgU0FNTCBhc3NlcnRpb24gDQo+ID4gPiB3aXRoIHNlY3RvcmFsIGlkZW50aWZpZXIgYW5kIHN1
cHBseSBpdCB0byBvdGhlciBzeXN0ZW1zLiANCj4gPiA+IA0KPiA+ID4gTmF0DQo+ID4gDQo+ID4g
PiBPbiBXZWQsIERlYyA1LCAyMDEyIGF0IDExOjA1IFBNLCBCcmlhbiBDYW1wYmVsbCANCj4gPGJj
YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tDQo+ID4gPiA+IHdyb3RlOiANCj4gPiA+IEkgc2F5IHRo
YXQgaXQncyBvbmx5IHRoZW9yZXRpY2FsIGJlY2F1c2UgSSBkb24ndCBiZWxpZXZlIHRoZXJlIGFy
ZSANCj4gPiA+IGFueSBhY3R1YWwgZGVwbG95bWVudHMgc3VwcG9ydGluZywgb3IgcGxhbm5pbmcg
b24gc3VwcG9ydGluZywgUk8gYXMgDQo+ID4gPiBhbiBhc3NlcnRpb24gaXNzdWVyLiANCj4gPiA+
IA0KPiA+IA0KPiA+ID4gT24gVHVlLCBEZWMgNCwgMjAxMiBhdCA1OjM5IFBNLCA8emhvdS5zdWpp
bmdAenRlLmNvbS5jbj4gd3JvdGU6IA0KPiA+ID4gDQo+ID4gPiBXaHkgUk8gYXMgYW4gaXNzdWVy
IGlzIG9ubHkgdGhlb3JldGljYWwgdG9kYXk/IA0KPiA+ID4gDQo+ID4gDQo+ID4gPiANCj4gPiA+
IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4gDQo+ID4gPiAyMDEy
LTEyLTA0IDIzOjQxIA0KPiA+ID4gDQo+ID4gPiDmlLbku7bkurogDQo+ID4gPiANCj4gPiA+IE5h
dCBTYWtpbXVyYSA8c2FraW11cmFAZ21haWwuY29tPiANCj4gPiA+IA0KPiA+ID4g5oqE6YCBIA0K
PiA+ID4gDQo+ID4gPiB6aG91LnN1amluZ0B6dGUuY29tLmNuLCAib2F1dGhAaWV0Zi5vcmciIDxv
YXV0aEBpZXRmLm9yZz4gDQo+ID4gPiANCj4gPiA+IOS4u+mimCANCj4gPiA+IA0KPiA+ID4gUmU6
IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZlIHRv
IGJlIA0KPiA+ID4gZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2
aWNlPyANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gVGhlIGludGVudCB3
YXMgZGVmaW5pdGVseSBub3QgdG8gY29uc3RyYWluIHdoby93aGF0IGNvdWxkIGJlIHRoZSANCj4g
PiA+IGlzc3Vlci4gIEJ1dCBhbHNvIHRyeSB0byBwcm92aWRlIA0KPiA+ID4gc29tZSBndWlkYW5j
ZSBhcm91bmQgdGhlIGNvbW1vbiBjYXNlcyB0aGF0IGFyZSBhY3R1YWxseSBiZWluZyANCj4gPiA+
IGRlcGxveWVkIG5vdywgd2hpY2ggYXJlIHRoZSBjbGllbnQgc2VsZi1pc3N1ZWQgYW5kIFNUUyB2
YXJpYW50cy4gDQo+ID4gPiBSZXNvdXJjZSBvd25lciBhcyBhbiBpc3N1ZXIgaXMgYW4gaW50ZXJl
c3RpbmcgY2FzZSBidXQgc2VlbXMgbW9zdGx5IA0KPiA+ID4gdGhlb3JldGljYWwgYXQgdGhpcyBw
b2ludC4NCj4gPiA+IA0KPiA+ID4gSSBmZWVsIGxpa2UgbWVudGlvbmluZyB0aGUgcmVzb3VyY2Ug
b3duZXIgdGhlcmUgaW4gwqc1LjEgd291bGQgY2F1c2UgDQo+ID4gPiBtb3JlIGNvbmZ1c2lvbiB0
aGFuIGFueXRoaW5nIGVsc2UuIEknZCBwcmVmZXIgdG8ganVzdCBzdHJpa2UgdGhlIA0KPiA+ID4g
d2hvbGUgc2VudGVuY2UgaW4gcXVlc3Rpb24gYW5kIG1heWJlIGFkZCBzb21lIGFkZGl0aW9uYWwg
dGV4dCB0byDCpzMgDQo+ID4gPiB0aGF0IGNsYXJpZmllcyB0aGF0IHRoZSBpc3N1ZXIgY2FuIHJl
YWxseSBiZSBhbnkgZW50aXR5LCBpZiBmb2xrcyANCj4gPiA+IHRoaW5rIGEgY2hhbmdlIGlzIG5l
ZWRlZCBoZXJlPyANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IE9uIE1vbiwgRGVjIDMs
IDIwMTIgYXQgOToyMCBQTSwgTmF0IFNha2ltdXJhIDxzYWtpbXVyYUBnbWFpbC5jb20+IA0Kd3Jv
dGU6IA0KPiA+ID4gQWN0dWFsbHksICJUaGUgaXNzdWVyIG1heSBiZSBlaXRoZXIgDQo+ID4gPiAg
ICAgICBhbiBPQXV0aCBjbGllbnQgKHdoZW4gYXNzZXJ0aW9ucyBhcmUgc2VsZi1pc3N1ZWQpIG9y
IGFueSBvdGhlcg0KPiA+ID4gZW50aXR5LCBlLmcuLCAgYSB0aGlyZCBwYXJ0eSANCj4gPiA+IHRv
a2VuIHNlcnZpY2UsIHJlc291cmNlIG93bmVyLiAiICBpcyBub3QgcmVhbGx5IGNsZWFuLiANCj4g
PiA+IA0KPiA+ID4gT0F1dGggY2xpZW50IGlzIGp1c3QgYW5vdGhlciBleGFtcGxlIG9mIGFuIGlz
c3Vlci4gDQo+ID4gPiANCj4gPiA+IFNvLCBwZXJoYXBzIHRoZSBzZW50ZW5jZSBjb3VsZCBiZTog
DQo+ID4gPiANCj4gPiA+ICJFeGFtcGxlIG9mIGlzc3VlcnMgaW5jbHVkZSBhbiBPQXV0aCBjbGll
bnQsIHJlc291cmNlIG93bmVyLCBhbiANCj4gPiA+IGluZGVwZW5kZW50IHRoaXJkIHBhcnR5LiIg
DQo+ID4gPiANCj4gPiA+IFNvLCB0aGUgY2xhdXNlIGJlY29tZXM6IA0KPiA+ID4gDQo+ID4gPiAg
SXNzdWVyICBUaGUgdW5pcXVlIGlkZW50aWZpZXIgZm9yIHRoZSBlbnRpdHkgdGhhdCBpc3N1ZWQg
dGhlIA0KPiA+ID4gICAgICBhc3NlcnRpb24uICBHZW5lcmFsbHkgdGhpcyBpcyB0aGUgZW50aXR5
IHRoYXQgaG9sZHMgdGhlIGtleSANCj4gPiA+ICAgICAgbWF0ZXJpYWwgdXNlZCB0byBnZW5lcmF0
ZSB0aGUgYXNzZXJ0aW9uLiANCj4gPiA+ICAgICAgIEV4YW1wbGUgb2YgaXNzdWVycyBpbmNsdWRl
IGFuIE9BdXRoIGNsaWVudCwgcmVzb3VyY2Ugb3duZXIsIGFuDQo+ID4gPiBpbmRlcGVuZGVudCB0
aGlyZCBwYXJ0eS4gDQo+ID4gPiANCj4gPiA+IE5hdCANCj4gPiA+IA0KPiA+ID4gTmF0IA0KPiA+
ID4gDQo+ID4gPiBPbiBUdWUsIERlYyA0LCAyMDEyIGF0IDExOjQwIEFNLCA8emhvdS5zdWppbmdA
enRlLmNvbS5jbj4gd3JvdGU6IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gQ2h1Y2sg
TW9ydGltb3JlIDxjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tPiDlhpnkuo4gMjAxMi0xMi0wNCAN
CjEwOjI2OjUwOiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiA+IFBsZWFzZSBmZWVsIGZyZWUgdG8g
c3VnZ2VzdCBiZXR0ZXIgbGFuZ3VhZ2UuIA0KPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBJc3N1
ZXIgc2ltcGx5IGFsbG93cyB0aGUgdG9rZW4gc2VydmljZSB0byBrbm93IHdobyBjcmVhdGVkIHRo
ZSANCj4gPiA+ID4gYXNzZXJ0aW9uLCBzbyBpdCBjYW4gbG9vayB0aGVtIHVwIGFuZCBzZWUgaWYg
dGhleSdyZSB0cnVzdGVkLiANCj4gPiA+ID4gRWZmZWN0aXZlbHkgdGhlIHNhbWUgYXMgYW4gSXNz
dWVyIGluIFNBTUwuIA0KPiA+ID4gDQo+ID4gPiBhIGNvbmZsaWN0IDogIlRoZSB0b2tlbiBzZXJ2
aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVyIiBpbiANCj4gPiA+IGFzc2VydGlvbiBkb2N1bWVu
dC4gDQo+ID4gPiB3aGlsZSB5b3Ugc2FpZCAidG9rZW4gc2VydmljZSBrbm93IHdobyBjcmVhdGVk
IHRoZSBhc3NlcnRpb24iIA0KPiA+ID4gDQo+ID4gPiBJIHdvbmRlciBpZiB0aGUgZm9sbG93aW5n
IHRleHQgaXMgYWNjZXB0YWJsZTogDQo+ID4gPiANCj4gPiA+ICBJc3N1ZXIgIFRoZSB1bmlxdWUg
aWRlbnRpZmllciBmb3IgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGUgDQo+ID4gPiAgICAgIGFz
c2VydGlvbi4gIEdlbmVyYWxseSB0aGlzIGlzIHRoZSBlbnRpdHkgdGhhdCBob2xkcyB0aGUga2V5
IA0KPiA+ID4gICAgICBtYXRlcmlhbCB1c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uICBU
aGUgaXNzdWVyIG1heSBiZSANCmVpdGhlciANCj4gPiA+ICAgICAgIGFuIE9BdXRoIGNsaWVudCAo
d2hlbiBhc3NlcnRpb25zIGFyZSBzZWxmLWlzc3VlZCkgb3IgYW55IG90aGVyDQo+ID4gPiBlbnRp
dHksIGUuZy4sICBhIHRoaXJkIHBhcnR5IA0KPiA+ID4gdG9rZW4gc2VydmljZSwgcmVzb3VyY2Ug
b3duZXIuIA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IDYuMy4gIENsaWVudCBBY3Rpbmcgb24gQmVo
YWxmIG9mIGEgVXNlciANCj4gPiA+IA0KPiA+ID4gVGhlIElzc3VlciBvZiB0aGUgYXNzZXJ0aW9u
IE1VU1QgaWRlbnRpZnkgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCANCj4gPiA+ICAgICAgdGhlIGFz
c2VydGlvbiBhcyByZWNvZ25pemVkIGJ5IHRoZSBBdXRob3JpemF0aW9uIFNlcnZlci4gIElmIA0K
dGhlIA0KPiA+ID4gICAgICBhc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRoZSBJc3N1ZXIgU0hP
VUxEIGJlIHRoZSAiY2xpZW50X2lkIi4gDQoNCj4gPiA+ICAgICAgSWYgdGhlIGFzc2VydGlvbiB3
YXMgaXNzdWVkIGJ5IGEgU2VjdXJpdHkgVG9rZW4gU2VydmljZSAoU1RTKSwgDQp0aGUgDQo+ID4g
PiAgICAgIElzc3VlciBTSE9VTEQgaWRlbnRpZnkgdGhlIFNUUyBhcyByZWNvZ25pemVkIGJ5IHRo
ZSANCkF1dGhvcml6YXRpb24gDQo+ID4gPiAgICAgIFNlcnZlci5JZiB0aGUgYXNzZXJ0aW9uIHdh
cyBpc3N1ZWQgYnkgdGhlIHJlc291cmNlIG93bmVyLCB0aGUgDQo+ID4gPiAgICAgIElzc3VlciBT
SE9VTEQgaWRlbnRpZnkgdGhlIHJlc291cmNlIG93bmVyIGFzIHJlY29nbml6ZWQgYnkgdGhlIA0K
PiA+ID4gQXV0aG9yaXphdGlvbiANCj4gPiA+ICAgICAgU2VydmVyLiANCj4gPiA+IA0KPiA+ID4g
PiANCj4gPiA+ID4gLWNtb3J0IA0KPiA+ID4gPiANCj4gPiA+ID4gT24gRGVjIDMsIDIwMTIsIGF0
IDY6MjMgUE0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPiB3cm90ZTogDQo+ID4gPiA+IA0KPiA+
ID4gPiANCj4gPiA+ID4gT2J2aW91c2x5LCBpdCBpcyBub3Qgc28gY2xlYXIgZnJvbSB0aGUgbGFu
Z3VhZ2UgdGhlcmUuIA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IENodWNrIE1vcnRpbW9y
ZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbT4g5YaZ5LqOIDIwMTItMTItMDQgDQoxMDoxNzox
MjoNCj4gPiA+ID4gDQo+ID4gPiA+ID4gVGhlcmUncyBubyByZWFzb24gd2h5IGl0IGNhbid0IGJl
IHJlc291cmNlIG93bmVyIHRvZGF5LiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBPbiBEZWMgMywg
MjAxMiwgYXQgNjowNiBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IDx6aG91Lg0KPiA+ID4g
c3VqaW5nQHp0ZS5jb20uY24NCj4gPiA+ID4gPiA+IHdyb3RlOiANCj4gPiA+ID4gPiANCj4gPiA+
ID4gPiANCj4gPiA+ID4gPiArMS4gDQo+ID4gPiA+ID4gQW5kIHdoeSBpdCB3YXMgbm90IGxvb2tl
ZCBhdCB0aGF0IHRpbWU/IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IG9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmcg5YaZ5LqOIDIwMTItMTItMDQgMDE6MzA6NTU6DQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4g
PiBBY3R1YWxseSwgSSB0aGluayBpdCBpcyBhIGdvb2QgdGltZSB0byBzdGFydCBsb29raW5nIGF0
IHRoZSANCnJlc291cnNlDQo+ID4gPiA+ID4gPiBvd25lciBpc3N1aW5nIGFzc2VydGlvbnNAIChJ
bnRlcmVzdGluZ2x5IGVub3VnaCwgSHVpLUxhbiBoYWQgDQpicm91Z2h0DQo+ID4gPiA+ID4gPiB0
aGlzIHVwIGEgY291cGxlIG9mIHllYXJzIGFnby4pDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+
IElnb3INCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gT24gMTIvMy8yMDEyIDM6NTggQU0sIE5h
dCBTYWtpbXVyYSB3cm90ZTogDQo+ID4gPiA+ID4gPiBJIHN1cHBvc2UsIHllcy4gSSB3YXMgcmVh
ZGluZyBpdCBsaWtlIHRoYXQgYWxsIHRoZSB0aW1lLiANCj4gPiA+ID4gPiA+IFdoZXRoZXIgaXQg
aXMgb3Igbm90LCBpZiBpdCBpcyBzdGlsbCBvaywgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIA0KDQo+
ID4gPiA+IGNsYXJpZnkgaXQuIA0KPiA+ID4gPiA+ID4gV29yZCBsaWtlICJ0aGlyZCBwYXJ0eSIg
dGVuZHMgdG8gYmUgYSBiaXQgb2YgcHJvYmxlbSB3aXRob3V0IA0KPiA+ID4gPiA+IGNsZWFybHlk
ZWZpbmluZy4gDQo+ID4gPiA+ID4gPiBJIGhhZCBzaW1pbGFyIGV4cGVyaWVuY2UgaW4gb3RoZXIg
Zm9yYS4gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IE5hdCANCj4gPiA+ID4gPiA+IA0KPiA+
ID4gPiA+ID4gU2VudCBmcm9tIGlQYWQgDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IDIwMTIv
MTIvMDMgMDo1MuOAgSJ6aG91LnN1amluZ0B6dGUuY29tLmNuIiANCjx6aG91LnN1amluZ0B6dGUu
Y29tLmNuPiDjga4NCj4gPiA+ID4gPiA+IOODoeODg+OCu+ODvOOCuDoNCj4gPiA+ID4gPiANCj4g
PiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gY291bGQgYmUgUmVzb3VyY2Ugb3duZXI/IA0KPiA+ID4g
PiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ICJUc2Nob2Zlbmln
LCBIYW5uZXMgKE5TTiAtIEZJL0VzcG9vKSIgDQo8aGFubmVzLnRzY2hvZmVuaWdAbnNuLmNvbT4g
DQo+ID4gPiA+ID4gPiDlj5Hku7bkuro6ICBvYXV0aC1ib3VuY2VzQGlldGYub3JnIA0KPiA+ID4g
PiA+ID4gMjAxMi0xMi0wMyAxNjo0OSANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4g5pS25Lu2
5Lq6IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiAiZXh0IE5hdCBTYWtpbXVyYSIgPHNha2lt
dXJhQGdtYWlsLmNvbT4sICJCcmlhbiBDYW1wYmVsbCIgPA0KPiA+ID4gPiA+ID4gYmNhbXBiZWxs
QHBpbmdpZGVudGl0eS5jb20+LCAib2F1dGgiIDxvYXV0aEBpZXRmLm9yZz4gDQo+ID4gPiA+ID4g
PiANCj4gPiA+ID4gPiA+IOaKhOmAgSANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4g5Li76aKY
IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBSZTogW09BVVRILVdHXSBBc3NlcnRpb24gRnJh
bWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8gDQpiZSANCj4gPiA+ID4gPiA+IGVpdGhl
ciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4gc2VydmljZT8gDQo+ID4gPiA+ID4g
PiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+
IEhpIE5hdCwgDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IFRoZSBjdXJyZW50IHRleHQgZXNz
ZW50aWFsbHkgc2F5cyB0aGF0IHRoZSBhc3NlcnRpb24gY2FuIA0KZWl0aGVyIGJlIA0KPiA+ID4g
PiA+ID4gY3JlYXRlZCBieSB0aGUgY2xpZW50IChpbiB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2ln
bmVkKSBvcml0IA0KY2FuIGJlDQo+ID4gPiA+ID4gPiBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50
aXR5ICh3aGljaCBpcyB0aGVuIGNhbGxlZCB0aGUgdGhpcmQgDQpwYXJ0eSANCj4gPiA+ID4gPiA+
IHRva2VuIHNlcnZpY2UpLiBTbywgdGhpcyB0aGlyZCBwYXJ0eSBjb3VsZCBiZSB0aGUgDQo+ID4g
YXV0aG9yaXphdGlvbiBzZXJ2ZXIuIA0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBDaWFvDQo+
ID4gPiA+ID4gPiBIYW5uZXMgDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+
ID4gRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmddIA0KPiA+ID4gT24gQmVoYWxmIE9mIA0KPiA+ID4gPiA+ID4gZXh0IE5hdCBTYWtpbXVy
YQ0KPiA+ID4gPiA+ID4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAxMiAxMDozNSBBTQ0K
PiA+ID4gPiA+ID4gVG86IEJyaWFuIENhbXBiZWxsOyBvYXV0aA0KPiA+ID4gPiA+ID4gU3ViamVj
dDogW09BVVRILVdHXSBBc3NlcnRpb24gRnJhbWV3b3JrIC0gV2h5IGRvZXMgaXNzdWVyIGhhdmUg
DQp0byBiZQ0KPiA+ID4gPiA+ID4gZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSB0
b2tlbiBzZXJ2aWNlPyANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gSGkgQnJpYW4sIA0KPiA+
ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IFRoZSBhc3NlcnRpb24gZnJhbWV3
b3JrIGRlZmluZXMgdGhlIElzc3VlciBhczogDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ICAg
IElzc3VlciAgVGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5IHRoYXQgaXNzdWVk
IA0KdGhlIA0KPiA+ID4gPiA+ID4gICAgICAgYXNzZXJ0aW9uLiAgR2VuZXJhbGx5IHRoaXMgaXMg
dGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSANCmtleSANCj4gPiA+ID4gPiA+ICAgICAgIG1hdGVy
aWFsIHVzZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4gIFRoZSBpc3N1ZXIgDQo+ID4gbWF5
YmUgZWl0aGVyIA0KPiA+ID4gPiA+ID4gICAgICAgYW4gT0F1dGggY2xpZW50ICh3aGVuIGFzc2Vy
dGlvbnMgYXJlIHNlbGYtaXNzdWVkKSBvciBhIA0KPiA+ID4gdGhpcmQgcGFydHkgDQo+ID4gPiA+
ID4gPiAgICAgICB0b2tlbiBzZXJ2aWNlLiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gSSB3
YXMgd29uZGVyaW5nIHdoeSBpdCBoYXMgdG8gYmUgZWl0aGVyIHRoZSBjbGllbnQgb3IgYSB0aGly
ZCANCnBhcnR5IA0KPiA+ID4gPiA+ID4gdG9rZW4gc2VydmljZS4gDQo+ID4gPiA+ID4gPiBDb25j
ZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBzZXJ2aWNlIChmdW5jdGlvbmFsaXR5KSAN
Cj4gPiA+ID4gPiByZXNpZGluZ2luIGFueSBvZiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4g
dGhlIHN0YWtlaG9sZGVycyAoUmVzb3VyY2UgT3duZXIsIE9BdXRoIENsaWVudCwgQXV0aG9yaXph
dGlvbiANCj4gPiA+IFNlcnZlciwgb3IgDQo+ID4gPiA+ID4gPiBhIHRoaXJkIHBhcnR5KS4gDQo+
ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gSSB3b3VsZCBhcHByZWNpYXRl
IGlmIHlvdSBjb3VsZCBjbGFyaWZ5IHdoeSBpcyB0aGUgY2FzZS4gDQo+ID4gPiA+ID4gPiANCj4g
PiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gQmVzdCwgDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+
IC0tIA0KPiA+ID4gPiA+ID4gTmF0IFNha2ltdXJhICg9bmF0KSANCj4gPiA+ID4gPiA+IENoYWly
bWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KPiA+ID4gPiA+ID4gaHR0cDovL25hdC5zYWtpbXVyYS5v
cmcvDQo+ID4gPiA+ID4gPiBAX25hdF9lbiANCj4gPiA+ID4gPiA+ICBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gPiA+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gPiA+ID4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+
ID4gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4g
PiA+ID4gPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gPiA+ID4gPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gPiA+ID4gPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gT0F1dGggbWFpbGluZyBs
aXN0DQo+ID4gPiA+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gPiA+ID4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+ID4gPiA+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gPiA+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiA+ID4gPiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIA0KPiA+ID4gDQo+ID4gPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+
ID4gPiAtLSANCj4gPiA+IE5hdCBTYWtpbXVyYSAoPW5hdCkgDQo+ID4gPiBDaGFpcm1hbiwgT3Bl
bklEIEZvdW5kYXRpb24NCj4gPiA+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiA+ID4gQF9u
YXRfZW4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4gPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+ID4gT0F1
dGhAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCj4gPiA+IA0KPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiANCj4gPiA+IA0KPiA+ID4g
LS0gDQo+ID4gPiBOYXQgU2FraW11cmEgKD1uYXQpIA0KPiA+ID4gQ2hhaXJtYW4sIE9wZW5JRCBG
b3VuZGF0aW9uDQo+ID4gPiBodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8NCj4gPiA+IEBfbmF0X2Vu
IA0KPiA+ID4gDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZw0K
PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCANCj4gPiA+
IA0KPiA+ID4gDQo+ID4gPiBFdmUgTWFsZXIgaHR0cDovL3d3dy54bWxncnJsLmNvbS9ibG9nDQo+
ID4gPiArMSA0MjUgMzQ1IDY3NTYgaHR0cDovL3d3dy50d2l0dGVyLmNvbS94bWxncnJsDQo+ID4g
DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
PiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+ID4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+IA0KDQo+ID4gDQo+
ID4gLS0gDQo+ID4gTmF0IFNha2ltdXJhICg9bmF0KQ0KPiA+IENoYWlybWFuLCBPcGVuSUQgRm91
bmRhdGlvbg0KPiA+IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KPiA+IEBfbmF0X2VuDQo+ID4g
DQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZw0KPiA+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K
--=_alternative 0009729D48257AD1_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluICZxdW90O3NlY3Rpb24gMzwv
Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7VGhlIHRva2Vu
IHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbg0KaXNzdWVyOyBpdHM8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO3JvbGUgaXMgdG8gZnVsZmlsbCByZXF1ZXN0
cyBmcm9tDQpjbGllbnRzLCB3aGljaCBwcmVzZW50IHZhcmlvdXM8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO2NyZWRlbnRpYWxzLCBhbmQgbWludCBhc3Nl
cnRpb25zDQphcyByZXF1ZXN0ZWQsIGZpbGwgdGhlbSB3aXRoPC9mb250Pg0KPGJyPjxmb250IHNp
emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDthcHByb3ByaWF0ZSBpbmZvcm1hdGlvbiwgYW5k
IHNpZ24NCnRoZW0uJnF1b3Q7PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm
YWNlPSJzYW5zLXNlcmlmIj5BcyBJIHVuZGVyc3RhbmQsIGFuIGFzc2VydGlvbiBnZW5lcmF0ZWQN
CmJ5IGEgU1RTLCBpcyBkb25lIGZsb2xsb3dpbmcgdGhlc3Mgc3RlcHM6PC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBDbGllbnQgcHJlc2VudHMgY3JlZGVudGlh
bCBhbmQgcmVxdWVzdHMNCmFuIGFzc2VydGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj
ZT0ic2Fucy1zZXJpZiI+Mi4gU1RTIGdlbmVyYXRlcyBhc3NlcnRpb24gYW5kIHNlbmRzDQp0byBD
bGllbnQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkNvcnJlY3Q/
PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JdCBpcyBh
biBpbnRlcmFjdGl2ZSBwcm9jZXNzLCBidXQgdGhlcmUNCmFyZSBjYXNlcyB0aGF0IGNyZWRlbnRp
YWwgZnJvbSBjbGllbnQgaXMgbm90IG5lY2Vzc2FyeSw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPmUuZy4gbXkgUk8gaXNzdWVyIHVzZSBjYXNlOjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gUk8gZ2VuZXJhdGUgYSBkZWxlZ2F0
aW9uIHN0YXRlbWVudA0Kc3BlY2lmeWluZyBjbGllbnQtbmFtZSBoYXMgdGhlIHJpZ2h0IHRvIGRv
IHNvbWV0aGluZywgc2lnbnMgaXQsIHNlbmRzIHRvDQpjbGllbnQuPC9mb250Pg0KPGJyPg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5ObyBjbGllbnQgY3JlZGVudGlhbCBpcyBu
ZWVkZWQsIGFuZA0KZXZlbiByZXF1ZXN0IGZyb20gY2xpZW50IGlzIG5vdCBuZWVkZWQuPC9mb250
Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbnkgY29tbWVudHM/
ICZuYnNwOyAmbmJzcDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij4mbmJzcDsgPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+WmhvdVN1SmluZzAw
MTMyODMxL3VzZXIvenRlX2x0ZCDlhpnkuo4gMjAxMi0xMi0wNw0KMDg6MTc6MDA6PGJyPg0KPGJy
Pg0KJmd0OyBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7
IOWGmeS6jiAyMDEyLTEyLTA3DQowNzowMzozODo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBB
IHF1ZXN0aW9uIGZvciB0aGUgY2hhaXJzIG9yIG90aGVycyBtb3JlIHZlcnNlZCBpbiB0aGUgd29y
a2luZ3MNCm9mIDxicj4NCiZndDsgJmd0OyB0aGUgSUVURiAtIGlzIHRoaXMgZG9jdW1lbnQgZXZl
biBpbiBhIHBsYWNlIHdoZXJlIGNoYW5nZXMgY2FuDQpiZSA8YnI+DQomZ3Q7ICZndDsgbWFkZT8g
VGhlIFNoZXBoZXJkIFdyaXRlLVVwIGZvciB0aGUgZG9jdW1lbnQgd2FzIHJlY2VudGx5IHNlbnQN
CnRvIDxicj4NCiZndDsgJmd0OyB0aGUgSUVTRyBTZWNyZXRhcnkgYW5kIEknbSBob25lc3RseSBu
b3Qgc3VyZSB3aGF0IHRoZSBwcm90b2NvbA0KaXMgPGJyPg0KJmd0OyAmZ3Q7IGZvciBtYWtpbmcg
Y2hhbmdlcyBhdCB0aGlzIHBvaW50Ljxicj4NCiZndDsgT3Igd2UgY2FuIHN0YXJ0IGEgbmV3IGRy
YWZ0IGV4dGVuZGluZyBhbmQgY2xhcmlmeWluZyB0aGUgYXNzZXJ0aW9uDQpkb2N1bWVudCw8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgbW9yZSB1c2UgY2FzZXMgY291bGQg
YmUgaW1wbGVtZW50ZWQgYnkgYXNzZXJ0aW9uDQptYXkgYmUgaW5jbHVkZWQsIDxicj4NCiZndDsg
YW5kIG90aGVyIHRoaW5ncy4uLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0
OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQo8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQo8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyBPbiBUaHUsIERlYyA2LCAyMDEy
IGF0IDEyOjUwIEFNLCBOYXQgU2FraW11cmENCiZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7IHdy
b3RlOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IEhlcmUsIEkg
dGhpbmsgaXQgaXMgYmV0dGVyIHRvIGRpZmZlcmVudGlhdGUNCnRoZSBlbnRpdHkgYW5kIGZ1bmN0
aW9uL3JvbGUuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyBBdXRob3JpemF0aW9uIFNlcnZlciBpbiBPQXV0aCBpcyAmcXVvdDtraW5k
IG9mJnF1b3Q7IGVudGl0eS4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0
OyAmZ3Q7IEl0cyBmdW5jdGlvbiBhY3R1YWxseSBpcyBzcGxpdCBpbnRvIHR3bywNCm9yIGluIG1v
c3QgY2FzZXMgdGhyZWUuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAxLiBBdXRoZW50aWNhdGlvbiBFbmRwb2ludDwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDIuIEF1dGhvcml6YXRpb24gRW5kcG9p
bnQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyAzLiBUb2tlbiBF
bmRwb2ludDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyBOb3csICZxdW90O0Fzc2VydGlvbiBWZXJpZmllciZxdW90OyBpcyBhIGZ1bmN0
aW9uL3JvbGUuIEl0IGlzDQpwZXJmb3JtZWQgYnkgMy4gPGJyPg0KJmd0OyAmZ3Q7IFRva2VuIEVu
ZHBvaW50LiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyBJdCBj
aGVjayB0aGUgdmFsaWRpdHksIGFuZCBpc3N1ZXMgYWNjZXNzDQp0b2tlbnMgKHdoaWNoIGluIHR1
cm4gY2FuIDxicj4NCiZndDsgJmd0OyBiZSBhbm90aGVyIGFzc2VydGlvbiBieSB0aGUgd2F5Lik8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgQXV0aG9yaXphdGlvbiBFbmRwb2ludCBpcyBhbm90aGVyIGZ1bmN0aW9uLiBJdCBjYW4gYmUg
bG9jYXRlZA0KPGJyPg0KJmd0OyAmZ3Q7IGFueXdoZXJlLiBJbiB5b3VyIGNhc2UsIGl0IGlzIGxv
Y2F0ZWQgaW4gd2hhdCB5b3UgY2FsbCBhcyBSZXNvdXJjZQ0KPGJyPg0KJmd0OyAmZ3Q7IE93bmVy
IChCcm93c2VyIHBsdWctaW4/KSBJbiBteSBTZWxmLUlzc3VlZCBJZFAgY2FzZSwgaXQgaXMgaXNz
dWVkDQpieTxicj4NCiZndDsgJmd0OyB0aGUgQXBwIGluIHRoZSBwaG9uZSB3aGljaCBpcyBjYWxs
ZWQgYnkgdGhlIGN1c3RvbSBzY2hlbWEuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl
PTI+Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGlzIGlzIHRoZSByZWFzb24gd2h5IEkgY29u
c3RhbnRseSBncnVtYmxlIHRoYXQgaXQgaXMgYmV0dGVyDQp0byA8YnI+DQomZ3Q7ICZndDsgc3Bl
YWsgaW4gdGVybXMgb2YgZnVuY3Rpb25zIHJhdGhlciB0aGFuIGVudGl0aWVzLiA8L2ZvbnQ+PC90
dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyBGdW5jdGlvbnMgbWF5IHJlc2lkZSBp
biBhbnkgZW50aXR5LCBhbmQNCmlmIHdlIHRhbGsgb25seSBpbiB0ZXJtcyBvZiA8YnI+DQomZ3Q7
ICZndDsgdGhlIGVudGl0aWVzLCB0aGUgY29tYmluYXRpb24gd2lsbCBleHBsb2RlLiA8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTmF0
PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IE9uIFRodSwgRGVjIDYsIDIwMTIgYXQgOTo0NiBBTSwgJmx0O3pob3Uuc3VqaW5nQHp0ZS5j
b20uY24mZ3Q7DQp3cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgQXMgSSB1bmRlcnN0YW5kLCBSTz1pc3N1ZXIgJm5ic3A7ZG9l
cyBub3QgbWVhbiBSTz1BUy4gPGJyPg0KJmd0OyAmZ3Q7IFJPIGFzIGFuIGlzc3VlciBnZW5lcmF0
ZXMgYXNzZXJ0aW9uIChpZiB0aGUgYXNzZXJ0aW9uIGlzIHNpbWlsYXINCnRvIDxicj4NCiZndDsg
Jmd0OyBkZWxlZ2F0aW9uIHN0YXRlbWVudCBpbiBteSB1c2UgY2FzZXMpLCA8YnI+DQomZ3Q7ICZn
dDsgQVMgYXMgYW4gYXNzZXJ0aW9uIHZlcmlmaWVyIHJlY2VpdmVzIHRoZSBhc3NlcnRpb24gYW5k
IGNoZWNrDQppdHMgdmFsaWRpdHkuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBvYXV0aC1ib3VuY2VzQGlldGYub3JnIOWGmeS6
jiAyMDEyLTEyLTA2IDAxOjM1OjEwOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBKdXN0IGNoZWNr
aW5nIHRoYXQgSSB1bmRlcnN0YW5kOiBJZiB0aGUgUk8gPT0gdGhlIGlzc3VlciwNCnRoZW4gdGhl
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFJPID09IHRoZSBBUywgcmlnaHQ/IEp1c3QgYXMgaW4gTmF0
J3MgZXhhbXBsZSwgdGhlIHVzZXINCihvciBhdCBsZWFzdDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRo
ZSBkZXZpY2UgcHJlc2VudGluZyBhIHVzZXIgYWdlbnQgdG8gdGhlbSkgPT0gdGhlIElkUD8NCkNv
bG9jYXRpbmcgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIFJPIGFuZCBBUyBmdW5jdGlvbnMgc2hv
dWxkbid0IGJlIHByZWNsdWRlZCwgYnV0IEkgd291bGQNCmJlIDxicj4NCiZndDsgJmd0OyAmZ3Q7
IGF3ZnVsbHkgY29uZnVzZWQgaWYgdGhlcmUgd2VyZSBhbiBSTy9pc3N1ZXIgaW4gdGhlIHBpY3R1
cmUNCmFuZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAqYWxzbyogYW4gQVMgdGhhdCAqZG9lc24ndCog
aXNzdWUgYXNzZXJ0aW9ucy48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBFdmUgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT24gNSBEZWMgMjAxMiwgYXQgOTox
MyBBTSwgTmF0IFNha2ltdXJhICZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7DQp3cm90ZTogPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgSXQgaXMgbm90IE9BdXRoLCBi
dXQgQXVzdHJpYW4gZUlEIHN5c3RlbSBpcyBhbiBleGFtcGxlIG9mDQpSTyBhcyBhbiA8YnI+DQom
Z3Q7ICZndDsgJmd0OyBhc3NlcnRpb24gaXNzdWVyIHBhdHRlcm4uIFRoZXkgaGF2ZSB0aGVpciBv
d24gU0FNTCBJZFAgb24NCnRoZWlyIFBDIDxicj4NCiZndDsgJmd0OyAmZ3Q7IChhdCBsZWFzdCBh
IGZldyB5ZWFycyBhZ28pIGFuZCBjb21iaW5lZCB3aXRoIHRoZSBxdWFsaWZpZWQNCmNlcnRzIGlu
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZSB1c2VyJ3Mgc21hcnQgY2FyZCBhbmQgYW5vdGhlciBm
aWxlLCBjcmVhdGVzIGEgU0FNTCBhc3NlcnRpb24NCjxicj4NCiZndDsgJmd0OyAmZ3Q7IHdpdGgg
c2VjdG9yYWwgaWRlbnRpZmllciBhbmQgc3VwcGx5IGl0IHRvIG90aGVyIHN5c3RlbXMuDQo8YnI+
DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBOYXQ8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgT24gV2VkLCBEZWMgNSwgMjAxMiBhdCAxMTowNSBQTSwgQnJp
YW4gQ2FtcGJlbGwgPGJyPg0KJmd0OyAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdyb3RlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHNheSB0
aGF0IGl0J3Mgb25seSB0aGVvcmV0aWNhbCBiZWNhdXNlIEkgZG9uJ3QgYmVsaWV2ZQ0KdGhlcmUg
YXJlIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFueSBhY3R1YWwgZGVwbG95bWVudHMgc3VwcG9ydGlu
Zywgb3IgcGxhbm5pbmcgb24gc3VwcG9ydGluZywNClJPIGFzIDxicj4NCiZndDsgJmd0OyAmZ3Q7
IGFuIGFzc2VydGlvbiBpc3N1ZXIuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBPbiBUdWUsIERlYyA0LCAyMDEyIGF0IDU6MzkgUE0sICZs
dDt6aG91LnN1amluZ0B6dGUuY29tLmNuJmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFdoeSBSTyBhcyBhbiBpc3N1ZXIgaXMgb25seSB0aGVvcmV0
aWNhbCB0b2RheT8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEJyaWFuIENhbXBiZWxsICZsdDtiY2Ft
cGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgMjAxMi0xMi0w
NCAyMzo0MSA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyDmlLbku7bk
urogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgTmF0IFNha2ltdXJh
ICZsdDtzYWtpbXVyYUBnbWFpbC5jb20mZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IOaKhOmAgSA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyB6aG91LnN1amluZ0B6dGUuY29tLmNuLCAmcXVvdDtvYXV0aEBpZXRmLm9yZyZxdW90OyAm
bHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyDkuLvpopggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
UmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeSBkb2VzIGlzc3VlciBoYXZl
DQp0byBiZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJk
IHBhcnR5IHRva2VuIHNlcnZpY2U/IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIGludGVudCB3YXMg
ZGVmaW5pdGVseSBub3QgdG8gY29uc3RyYWluIHdoby93aGF0IGNvdWxkDQpiZSB0aGUgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgaXNzdWVyLiAmbmJzcDtCdXQgYWxzbyB0cnkgdG8gcHJvdmlkZSA8YnI+
DQomZ3Q7ICZndDsgJmd0OyBzb21lIGd1aWRhbmNlIGFyb3VuZCB0aGUgY29tbW9uIGNhc2VzIHRo
YXQgYXJlIGFjdHVhbGx5DQpiZWluZyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBkZXBsb3llZCBub3cs
IHdoaWNoIGFyZSB0aGUgY2xpZW50IHNlbGYtaXNzdWVkIGFuZCBTVFMgdmFyaWFudHMuDQo8YnI+
DQomZ3Q7ICZndDsgJmd0OyBSZXNvdXJjZSBvd25lciBhcyBhbiBpc3N1ZXIgaXMgYW4gaW50ZXJl
c3RpbmcgY2FzZSBidXQgc2VlbXMNCm1vc3RseSA8YnI+DQomZ3Q7ICZndDsgJmd0OyB0aGVvcmV0
aWNhbCBhdCB0aGlzIHBvaW50Ljxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm
Z3Q7IEkgZmVlbCBsaWtlIG1lbnRpb25pbmcgdGhlIHJlc291cmNlIG93bmVyIHRoZXJlIGluIMKn
NS4xDQp3b3VsZCBjYXVzZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBtb3JlIGNvbmZ1c2lvbiB0aGFu
IGFueXRoaW5nIGVsc2UuIEknZCBwcmVmZXIgdG8ganVzdCBzdHJpa2UNCnRoZSA8YnI+DQomZ3Q7
ICZndDsgJmd0OyB3aG9sZSBzZW50ZW5jZSBpbiBxdWVzdGlvbiBhbmQgbWF5YmUgYWRkIHNvbWUg
YWRkaXRpb25hbA0KdGV4dCB0byDCpzMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhhdCBjbGFyaWZp
ZXMgdGhhdCB0aGUgaXNzdWVyIGNhbiByZWFsbHkgYmUgYW55IGVudGl0eSwNCmlmIGZvbGtzIDxi
cj4NCiZndDsgJmd0OyAmZ3Q7IHRoaW5rIGEgY2hhbmdlIGlzIG5lZWRlZCBoZXJlPyA8YnI+DQom
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyBPbiBNb24sIERlYyAzLCAyMDEyIGF0IDk6MjAgUE0sIE5hdCBT
YWtpbXVyYSAmbHQ7c2FraW11cmFAZ21haWwuY29tJmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsgJmd0
OyAmZ3Q7IEFjdHVhbGx5LCAmcXVvdDtUaGUgaXNzdWVyIG1heSBiZSBlaXRoZXIgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYW4gT0F1dGggY2xpZW50ICh3aGVuIGFz
c2VydGlvbnMgYXJlDQpzZWxmLWlzc3VlZCkgb3IgYW55IG90aGVyPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgZW50aXR5LCBlLmcuLCAmbmJzcDthIHRoaXJkIHBhcnR5IDxicj4NCiZndDsgJmd0OyAmZ3Q7
IHRva2VuIHNlcnZpY2UsIHJlc291cmNlIG93bmVyLiAmcXVvdDsgJm5ic3A7aXMgbm90IHJlYWxs
eQ0KY2xlYW4uIDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRo
IGNsaWVudCBpcyBqdXN0IGFub3RoZXIgZXhhbXBsZSBvZiBhbiBpc3N1ZXIuIDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFNvLCBwZXJoYXBzIHRoZSBzZW50ZW5jZSBj
b3VsZCBiZTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJnF1b3Q7
RXhhbXBsZSBvZiBpc3N1ZXJzIGluY2x1ZGUgYW4gT0F1dGggY2xpZW50LCByZXNvdXJjZQ0Kb3du
ZXIsIGFuIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGluZGVwZW5kZW50IHRoaXJkIHBhcnR5LiZxdW90
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBTbywgdGhlIGNsYXVz
ZSBiZWNvbWVzOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJz
cDtJc3N1ZXIgJm5ic3A7VGhlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciB0aGUgZW50aXR5DQp0aGF0
IGlzc3VlZCB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthc3Nl
cnRpb24uICZuYnNwO0dlbmVyYWxseSB0aGlzIGlzIHRoZQ0KZW50aXR5IHRoYXQgaG9sZHMgdGhl
IGtleSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO21hdGVyaWFsIHVz
ZWQgdG8gZ2VuZXJhdGUgdGhlIGFzc2VydGlvbi4NCiZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBFeGFtcGxlIG9mIGlzc3VlcnMgaW5jbHVkZSBhbiBPQXV0
aA0KY2xpZW50LCByZXNvdXJjZSBvd25lciwgYW48YnI+DQomZ3Q7ICZndDsgJmd0OyBpbmRlcGVu
ZGVudCB0aGlyZCBwYXJ0eS4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgTmF0IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE5hdCA8YnI+
DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBPbiBUdWUsIERlYyA0LCAyMDEy
IGF0IDExOjQwIEFNLCAmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDsNCndyb3RlOiA8YnI+
DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBDaHVjayBNb3J0aW1vcmUgJmx0O2Ntb3J0aW1vcmVAc2Fs
ZXNmb3JjZS5jb20mZ3Q7IOWGmeS6jg0KMjAxMi0xMi0wNCAxMDoyNjo1MDogPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBQ
bGVhc2UgZmVlbCBmcmVlIHRvIHN1Z2dlc3QgYmV0dGVyIGxhbmd1YWdlLiA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgSXNzdWVyIHNpbXBseSBhbGxvd3MgdGhlIHRva2VuIHNlcnZpY2UgdG8ga25vdyB3aG8NCmNy
ZWF0ZWQgdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYXNzZXJ0aW9uLCBzbyBpdCBjYW4g
bG9vayB0aGVtIHVwIGFuZCBzZWUgaWYgdGhleSdyZQ0KdHJ1c3RlZC4gJm5ic3A7ICZuYnNwOyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEVmZmVjdGl2ZWx5IHRoZSBzYW1lIGFzIGFuIElzc3Vl
ciBpbiBTQU1MLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBhIGNv
bmZsaWN0IDogJnF1b3Q7VGhlIHRva2VuIHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbiBpc3N1ZXIm
cXVvdDsNCmluIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGFzc2VydGlvbiBkb2N1bWVudC4gPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgd2hpbGUgeW91IHNhaWQgJnF1b3Q7dG9rZW4gc2VydmljZSBrbm93IHdo
byBjcmVhdGVkIHRoZQ0KYXNzZXJ0aW9uJnF1b3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IEkgd29uZGVyIGlmIHRoZSBmb2xsb3dpbmcgdGV4dCBpcyBhY2NlcHRh
YmxlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5i
c3A7SXNzdWVyICZuYnNwO1RoZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgdGhlIGVudGl0eQ0KdGhh
dCBpc3N1ZWQgdGhlIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YXNz
ZXJ0aW9uLiAmbmJzcDtHZW5lcmFsbHkgdGhpcyBpcyB0aGUNCmVudGl0eSB0aGF0IGhvbGRzIHRo
ZSBrZXkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDttYXRlcmlhbCB1
c2VkIHRvIGdlbmVyYXRlIHRoZSBhc3NlcnRpb24uDQombmJzcDtUaGUgaXNzdWVyIG1heSBiZSBl
aXRoZXIgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYW4gT0F1dGgg
Y2xpZW50ICh3aGVuIGFzc2VydGlvbnMgYXJlDQpzZWxmLWlzc3VlZCkgb3IgYW55IG90aGVyPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgZW50aXR5LCBlLmcuLCAmbmJzcDthIHRoaXJkIHBhcnR5IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IHRva2VuIHNlcnZpY2UsIHJlc291cmNlIG93bmVyLiA8YnI+DQomZ3Q7
ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA2LjMu
ICZuYnNwO0NsaWVudCBBY3Rpbmcgb24gQmVoYWxmIG9mIGEgVXNlciA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgSXNzdWVyIG9mIHRoZSBhc3NlcnRpb24gTVVT
VCBpZGVudGlmeSB0aGUgZW50aXR5IHRoYXQNCmlzc3VlZCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwO3RoZSBhc3NlcnRpb24gYXMgcmVjb2duaXplZCBieSB0aGUgQXV0
aG9yaXphdGlvbg0KU2VydmVyLiAmbmJzcDtJZiB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDthc3NlcnRpb24gaXMgc2VsZi1pc3N1ZWQsIHRoZSBJc3N1ZXINClNI
T1VMRCBiZSB0aGUgJnF1b3Q7Y2xpZW50X2lkJnF1b3Q7LiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwO0lmIHRoZSBhc3NlcnRpb24gd2FzIGlzc3VlZCBieSBhIFNlY3Vy
aXR5DQpUb2tlbiBTZXJ2aWNlIChTVFMpLCB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDtJc3N1ZXIgU0hPVUxEIGlkZW50aWZ5IHRoZSBTVFMgYXMgcmVjb2duaXpl
ZA0KYnkgdGhlIEF1dGhvcml6YXRpb24gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDtTZXJ2ZXIuSWYgdGhlIGFzc2VydGlvbiB3YXMgaXNzdWVkIGJ5DQp0aGUgcmVzb3Vy
Y2Ugb3duZXIsIHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO0lz
c3VlciBTSE9VTEQgaWRlbnRpZnkgdGhlIHJlc291cmNlDQpvd25lciBhcyByZWNvZ25pemVkIGJ5
IHRoZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBdXRob3JpemF0aW9uIDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7U2VydmVyLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgLWNtb3J0IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiBEZWMg
MywgMjAxMiwgYXQgNjoyMyBQTSwgJmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mZ3Q7DQp3cm90
ZTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgT2J2aW91c2x5LCBpdCBpcyBub3Qgc28gY2xlYXIgZnJv
bSB0aGUgbGFuZ3VhZ2UgdGhlcmUuDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDaHVjayBNb3J0aW1v
cmUgJmx0O2Ntb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20mZ3Q7IOWGmeS6jg0KMjAxMi0xMi0wNCAx
MDoxNzoxMjo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyBUaGVyZSdzIG5vIHJlYXNvbiB3aHkgaXQgY2FuJ3QgYmUgcmVzb3VyY2Ugb3duZXIN
CnRvZGF5LiAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiBEZWMgMywgMjAxMiwgYXQgNjowNiBQTSwgJmx0O3pob3Uu
c3VqaW5nQHp0ZS5jb20uY24mZ3Q7DQombHQ7emhvdS48YnI+DQomZ3Q7ICZndDsgJmd0OyBzdWpp
bmdAenRlLmNvbS5jbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdyb3RlOiA8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyArMS4gPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IEFuZCB3aHkgaXQgd2FzIG5vdCBsb29rZWQgYXQgdGhhdCB0aW1lPyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg5YaZ5LqOIDIwMTItMTItMDQgMDE6MzA6NTU6PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7IEFjdHVhbGx5LCBJIHRoaW5rIGl0IGlzIGEgZ29vZCB0aW1lIHRvIHN0YXJ0DQpsb29raW5n
IGF0IHRoZSByZXNvdXJzZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG93bmVy
IGlzc3VpbmcgYXNzZXJ0aW9uc0AgKEludGVyZXN0aW5nbHkNCmVub3VnaCwgSHVpLUxhbiBoYWQg
YnJvdWdodDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHRoaXMgdXAgYSBjb3Vw
bGUgb2YgeWVhcnMgYWdvLik8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBJZ29yPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT24gMTIv
My8yMDEyIDM6NTggQU0sIE5hdCBTYWtpbXVyYSB3cm90ZToNCjxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7IEkgc3VwcG9zZSwgeWVzLiBJIHdhcyByZWFkaW5nIGl0IGxpa2UgdGhh
dA0KYWxsIHRoZSB0aW1lLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBXaGV0
aGVyIGl0IGlzIG9yIG5vdCwgaWYgaXQgaXMgc3RpbGwgb2ssDQppdCBtaWdodCBiZSBiZXR0ZXIg
dG8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBjbGFyaWZ5IGl0LiA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyBXb3JkIGxpa2UgJnF1b3Q7dGhpcmQgcGFydHkmcXVvdDsgdGVu
ZHMgdG8NCmJlIGEgYml0IG9mIHByb2JsZW0gd2l0aG91dCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgY2xlYXJseWRlZmluaW5nLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyBJIGhhZCBzaW1pbGFyIGV4cGVyaWVuY2UgaW4gb3RoZXIgZm9yYS4gPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsgTmF0IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNlbnQgZnJvbSBpUGFkIDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDIwMTIv
MTIvMDMgMDo1MuOAgSZxdW90O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mcXVvdDsNCiZsdDt6aG91
LnN1amluZ0B6dGUuY29tLmNuJmd0OyDjga48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyDjg6Hjg4Pjgrvjg7zjgrg6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IGNvdWxkIGJlIFJlc291cmNlIG93bmVyPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsgJnF1b3Q7VHNjaG9mZW5pZywgSGFubmVzIChOU04gLSBGSS9Fc3BvbykmcXVvdDsNCiZsdDto
YW5uZXMudHNjaG9mZW5pZ0Buc24uY29tJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyDlj5Hku7bkuro6ICZuYnNwO29hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgMjAxMi0xMi0wMyAxNjo0OSA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyDmlLbku7bkurogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJnF1b3Q7ZXh0IE5hdCBTYWtpbXVyYSZxdW90OyAm
bHQ7c2FraW11cmFAZ21haWwuY29tJmd0OywNCiZxdW90O0JyaWFuIENhbXBiZWxsJnF1b3Q7ICZs
dDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiY2FtcGJlbGxAcGluZ2lkZW50
aXR5LmNvbSZndDssICZxdW90O29hdXRoJnF1b3Q7DQombHQ7b2F1dGhAaWV0Zi5vcmcmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IOaKhOmAgSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyDkuLvpopggPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
UmU6IFtPQVVUSC1XR10gQXNzZXJ0aW9uIEZyYW1ld29yayAtIFdoeQ0KZG9lcyBpc3N1ZXIgaGF2
ZSB0byBiZSAmbmJzcDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
IGVpdGhlciB0aGUgY2xpZW50IG9yIGEgdGhpcmQgcGFydHkgdG9rZW4NCnNlcnZpY2U/IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7IEhpIE5hdCwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBjdXJyZW50IHRleHQgZXNzZW50
aWFsbHkgc2F5cyB0aGF0IHRoZQ0KYXNzZXJ0aW9uIGNhbiBlaXRoZXIgYmUgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgY3JlYXRlZCBieSB0aGUgY2xpZW50IChpbiB3aGljaCBj
YXNlIGl0IGlzDQpzZWxmLXNpZ25lZCkgb3JpdCBjYW4gYmU8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5ICh3aGljaCBpcyB0aGVu
DQpjYWxsZWQgdGhlIHRoaXJkIHBhcnR5IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7IHRva2VuIHNlcnZpY2UpLiBTbywgdGhpcyB0aGlyZCBwYXJ0eSBjb3VsZA0KYmUgdGhlIDxi
cj4NCiZndDsgJmd0OyBhdXRob3JpemF0aW9uIHNlcnZlci4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
IENpYW88YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBIYW5uZXMgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBG
cm9tOiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y
Z10NCjxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIEJlaGFsZiBPZiA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0OyBleHQgTmF0IFNha2ltdXJhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgU2VudDogTW9uZGF5LCBEZWNlbWJlciAwMywgMjAxMiAxMDozNSBBTTxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRvOiBCcmlhbiBDYW1wYmVsbDsgb2F1dGg8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBbT0FVVEgtV0ddIEFz
c2VydGlvbiBGcmFtZXdvcmsgLQ0KV2h5IGRvZXMgaXNzdWVyIGhhdmUgdG8gYmU8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBlaXRoZXIgdGhlIGNsaWVudCBvciBhIHRoaXJkIHBh
cnR5IHRva2VuDQpzZXJ2aWNlPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
bmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSGkgQnJpYW4sIDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn
dDsgVGhlIGFzc2VydGlvbiBmcmFtZXdvcmsgZGVmaW5lcyB0aGUgSXNzdWVyDQphczogPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtJc3N1ZXIgJm5ic3A7VGhlIHVuaXF1ZSBpZGVu
dGlmaWVyDQpmb3IgdGhlIGVudGl0eSB0aGF0IGlzc3VlZCB0aGUgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYXNzZXJ0aW9uLiAmbmJzcDtH
ZW5lcmFsbHkNCnRoaXMgaXMgdGhlIGVudGl0eSB0aGF0IGhvbGRzIHRoZSBrZXkgPC9mb250Pjwv
dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7ICZuYnNwOw0KbWF0ZXJpYWwgdXNlZCB0byBnZW5lcmF0ZSB0aGUgYXNzZXJ0
aW9uLiAmbmJzcDtUaGUgaXNzdWVyIDxicj4NCiZndDsgJmd0OyBtYXliZSBlaXRoZXIgPC9mb250
PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KYW4gT0F1dGggY2xpZW50ICh3aGVuIGFzc2VydGlvbnMg
YXJlIHNlbGYtaXNzdWVkKSBvciBhIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoaXJkIHBhcnR5IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRv
a2VuIHNlcnZpY2UuIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBJIHdhcyB3b25kZXJpbmcgd2h5IGl0
IGhhcyB0byBiZSBlaXRoZXIgdGhlDQpjbGllbnQgb3IgYSB0aGlyZCBwYXJ0eSA8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0b2tlbiBzZXJ2aWNlLiA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyBDb25jZXB0dWFsbHksIGl0IGNvdWxkIGJlIGFueSB0b2tlbiBz
ZXJ2aWNlDQooZnVuY3Rpb25hbGl0eSkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IHJl
c2lkaW5naW4gYW55IG9mIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNw
OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGUgc3Rha2Vob2xkZXJzIChS
ZXNvdXJjZSBPd25lciwgT0F1dGggQ2xpZW50LA0KQXV0aG9yaXphdGlvbiA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyBTZXJ2ZXIsIG9yIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGEg
dGhpcmQgcGFydHkpLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEkgd291bGQgYXBwcmVjaWF0ZSBpZiB5b3UgY291bGQgY2xh
cmlmeSB3aHkNCmlzIHRoZSBjYXNlLiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEJlc3QsIDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyAtLSA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBOYXQgU2FraW11cmEgKD1u
YXQpIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IENoYWlybWFuLCBPcGVuSUQg
Rm91bmRhdGlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGh0dHA6Ly9uYXQu
c2FraW11cmEub3JnLzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IEBfbmF0X2Vu
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwO19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7ICZndDsgJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7
ICZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBPQXV0aEBp
ZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAtLSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBOYXQgU2FraW11cmEgKD1uYXQpIDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IENoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCiZndDsgJmd0OyAm
Z3Q7IGh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzxicj4NCiZndDsgJmd0OyAmZ3Q7IEBfbmF0X2Vu
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsg
T0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPC9mb250PjwvdHQ+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IC0tIDxicj4NCiZndDsgJmd0OyAmZ3Q7IE5hdCBTYWtpbXVyYSAoPW5h
dCkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgQF9uYXRfZW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZn
dDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyBPQXV0aEBpZXRm
Lm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGggPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgRXZlIE1hbGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL3d3dy54bWxncnJsLmNvbS9i
bG9nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgKzEgNDI1IDM0NSA2NzU2ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBodHRwOi8vd3d3LnR3aXR0ZXIuY29tL3htbGdycmw8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQom
Z3Q7ICZndDsgJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2ZvbnQ+PC90dD4NCjxicj48dHQ+
PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg
c2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS0gPGJyPg0KJmd0OyAmZ3Q7IE5hdCBT
YWtpbXVyYSAoPW5hdCk8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0
OyBDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQomZ3Q7ICZndDsgaHR0cDovL25hdC5z
YWtpbXVyYS5vcmcvPGJyPg0KJmd0OyAmZ3Q7IEBfbmF0X2VuPC9mb250PjwvdHQ+DQo8YnI+PHR0
Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg
Jmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+
DQomZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxi
cj4NCjwvZm9udD48L3R0Pg0K
--=_alternative 0009729D48257AD1_=--

From Michael.Jones@microsoft.com  Mon Dec 10 17:51:48 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C78C21F861D for ; Mon, 10 Dec 2012 17:51:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.182
X-Spam-Level: 
X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=-0.584, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0bldgs9+d3B for ; Mon, 10 Dec 2012 17:51:46 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.29]) by ietfa.amsl.com (Postfix) with ESMTP id F359921F8618 for ; Mon, 10 Dec 2012 17:51:45 -0800 (PST)
Received: from BL2FFO11FD001.protection.gbl (10.173.161.201) by BL2FFO11HUB036.protection.gbl (10.173.161.116) with Microsoft SMTP Server (TLS) id 15.0.578.12; Tue, 11 Dec 2012 01:51:37 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.578.12 via Frontend Transport; Tue, 11 Dec 2012 01:51:36 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Tue, 11 Dec 2012 01:50:59 +0000
From: Mike Jones 
To: prateek mishra , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token
Thread-Index: AQHNvC9kQhzvnbWMhEy+1sKgrGoSHZfefVKAgDSMvtA=
Date: Tue, 11 Dec 2012 01:50:58 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366924D4D@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <7C0172BC-1D34-4C96-9220-0496BF14B262@gmx.net> <509A7B47.8050308@oracle.com>
In-Reply-To: <509A7B47.8050308@oracle.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_4E1F6AAD24975D4BA5B168042967394366924D4DTK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914002)(164054002)(377454001)(33656001)(4396001)(47976001)(47736001)(49866001)(50986001)(16236675001)(76482001)(46102001)(5343635001)(53806001)(54316002)(54356001)(512954001)(51856001)(5343655001)(56776001)(74502001)(15202345001)(56816002)(47446002)(44976002)(31966008)(77982001)(55846006)(16406001)(74662001)(59766001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB036; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 069255B8B8
Subject: Re: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Dec 2012 01:51:48 -0000

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

Thanks for the comments, Prateek.  Replies inline in green...

                                                                -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of p=
rateek mishra
Sent: Wednesday, November 07, 2012 7:16 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token

Hannes - here a couple of comments on the 05 draft -

(i) Section 4 -

[quote]
Note however, that the set of claims that a JWT must contain to be
considered valid is context-dependent and is outside the scope of this spec=
ification. When
used in a security-related context, implementations MUST understand and sup=
port all of the
claims present; otherwise, the JWT MUST be rejected for processing.
[\quote]

I am not sure what is being stated here. I understand the general sense of =
the paragraph but I found the
two sentences to be contradictory. The second sentence is also very strong =
- suppose we find
some private claim in a JWT that the recipient is unable to understand - pe=
rhaps an optional
attribute-value pair - MUST it then reject the token?

The strong language about "MUST understand" mirrors the same language in th=
e JOSE specs.  As you probably know, there's an open issue being discussed =
by the JOSE working group about whether all header fields must be understoo=
d, or whether there will be a mechanism for signaling that some header fiel=
ds may be safely ignored if not understood.  I suspect that if a change is =
made to the JOSE specs in this regard, a similar change might be applied he=
re as well.

(ii) Section 6 -

[quote]


A plaintext

   JWT is a JWS using the "none" JWS "alg" header parameter value

   defined in JSON Web Algorithms (JWA) [JWA]; it is a JWS with an empty

   JWS Signature value.

[\quote]

It is later clarified that by "empty JWS Signature value" the draft means "=
empty string". That could
be added as a parenthetical remark at the end of the sentence. I actually s=
pent some time looking
up the term "empty JWS Signature value" in the JWS specification.

I'll plan to apply this clarification in the next spec release.

Thanks,
prateek


Hi all,



you may have noticed that the JOSE working group had made good progress wit=
h their work and they are getting closer to a WGLC. This is a good point in=
 time for us to review the JWT spec (see http://datatracker.ietf.org/doc/dr=
aft-ietf-oauth-json-web-token/). Please read through it in preparation for =
the meeting.



It would be good to hear who has implemented it and whether there is feedba=
ck on the document. Given the OpenID Connect interoperability tests there s=
eem to be lots of implementations.



We would like to start a WGLC as soon as the WGLC for the JOSE documents  s=
tarts.



Ciao

Hannes



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


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











Thanks for the comments, =
Prateek.  Replies inline
in green…


 <=
/p>

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


 <=
/p>





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

Sent: Wednesday, November 07, 2012 7:16 AM

To: oauth@ietf.org

Subject: Re: [OAUTH-WG] Please review draft-ietf-oauth-json-web-toke=
n






 


Hannes - here a couple of comments on the 05 draft -=
 



(i) Section 4 - 



[quote]

Note however, that the set of claims that a JWT must contain to be

considered valid is context-dependent and is outside the scope of this spec=
ification. When

used in a security-related context, implementations MUST understand and sup=
port all of the

claims present; otherwise, the JWT MUST be rejected for processing.

[\quote]



I am not sure what is being stated here. I understand the general sense of =
the paragraph but I found the


two sentences to be contradictory. The second sentence is also very strong =
- suppose we find

some private claim in a JWT that the recipient is unable to understand - pe=
rhaps an optional


attribute-value pair - MUST it then reject the token?






The strong language about=
 “MUST understand” mirrors the same language in the JOSE specs.=
  As you probably know, there’s an open issue being discussed by=
 the
 JOSE working group about whether all header fields must be understood, or =
whether there will be a mechanism for signaling that some header fields may=
 be safely ignored if not understood.  I suspect that if a change is m=
ade to the JOSE specs in this regard,
 a similar change might be applied here as well.




(ii) Section 6 - 



[quote]






A =
plaintext


&n=
bsp;  JWT is a JWS using the "none" JWS "alg" head=
er parameter value


&n=
bsp;  defined in JSON Web Algorithms (JWA) [JWA]; it is a JWS with an empty=



&n=
bsp;  JWS Signature value.




[\quote]



It is later clarified that by "empty JWS Signature value" the dra=
ft means "empty string". That could

be added as a parenthetical remark at the end of the sentence. I actually s=
pent some time looking

up the term "empty JWS Signature value" in the JWS specification.=







I’ll plan to apply =
this clarification in the next spec release.




Thanks,

prateek






Hi all, 


 


you may have noticed that the JOSE working group had made good progres=
s with their work and they are getting closer to a WGLC. This is a good poi=
nt in time for us to review the JWT spec (see http://datatracker.ietf.org=
/doc/draft-ietf-oauth-json-web-token/). Please read through it in prepa=
ration for the meeting. 


 


It would be good to hear who has implemented it and whether there is f=
eedback on the document. Given the OpenID Connect interoperability tests th=
ere seem to be lots of implementations. 


 


We would like to start a WGLC as soon as the WGLC for the JOSE documen=
ts  starts. 


 


Ciao


Hannes


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


 






--_000_4E1F6AAD24975D4BA5B168042967394366924D4DTK5EX14MBXC283r_--

From Michael.Jones@microsoft.com  Mon Dec 10 18:24:11 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BC921F861D for ; Mon, 10 Dec 2012 18:24:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.137
X-Spam-Level: 
X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsPk9HSXeGgP for ; Mon, 10 Dec 2012 18:24:03 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 86B1021F84F5 for ; Mon, 10 Dec 2012 18:24:02 -0800 (PST)
Received: from BY2FFO11FD012.protection.gbl (10.1.15.204) by BY2FFO11HUB032.protection.gbl (10.1.14.177) with Microsoft SMTP Server (TLS) id 15.0.578.12; Tue, 11 Dec 2012 02:23:59 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.578.12 via Frontend Transport; Tue, 11 Dec 2012 02:23:58 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.240]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Tue, 11 Dec 2012 02:23:55 +0000
From: Mike Jones 
To: Hannes Tschofenig , "oauth@ietf.org WG" 
Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05
Thread-Index: AQHNy0Xxo8GvTywEIUS1okvsvI5A0ZgS7X7g
Date: Tue, 11 Dec 2012 02:23:55 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366924E28@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <0DC3825F-D600-4239-8283-FB7E2CAC4514@gmx.net>
In-Reply-To: <0DC3825F-D600-4239-8283-FB7E2CAC4514@gmx.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_4E1F6AAD24975D4BA5B168042967394366924E28TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(53754002)(51914002)(13464002)(59766001)(77982001)(4396001)(44976002)(47736001)(51856001)(49866001)(47976001)(54356001)(55846006)(53806001)(31966008)(50986001)(16406001)(16236675001)(33656001)(15202345001)(74502001)(47446002)(54316002)(512954001)(56776001)(76482001)(46102001)(5343655001)(5343635001)(56816002)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB032; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 069255B8B8
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Dec 2012 02:24:11 -0000

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

Thanks for the review comments, Hannes.  Replies are inline in green...



                                                                -- Mike



-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H=
annes Tschofenig
Sent: Sunday, November 25, 2012 11:49 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05



Hi all,



I reviewed the document and I have a few questions (see below). I also thin=
k that this document has to wait for the JOSE documents to complete WGLC be=
fore it can be moved forward. It will have to wait anyway in the queue beca=
use of the normative dependency.



Agreed



- Header



In Section 3.1 you have an example of a JWT with an HMAC SHA-256 keyed mess=
age digest.

I would have assumed that the header contains the key id so that the receip=
ient can actually decode it. I am sure you assume it implicitly determines =
it (somehow) but wouldn't it be better practice to additionally include the=
 kid field to make it less ambigious?



I agree that in some contexts, including a Key ID would be important.  That=
 being said, in other contexts, including some OAuth contexts, the key is i=
mplicitly known from context.  For instance, a shared symmetric key may be =
assigned to be used for an OAuth client at client registration time.  In th=
at case, both the client and the server already know what key to use withou=
t needing a Key ID.  The same may true when using public key cryptography w=
ith an issuer that publishes a public key and a relying party that also pub=
lishes a public key.  Here again, the correct keys to be used can be determ=
ined via means external to the token itself.



- Namespace



The document defines a couple of claims. Quite naturally one wants to provi=
de extension points since others will quite likely come up with new claims =
in the near future. The obvious approach would be to use an IANA registry t=
o maintain uniqueness of the labels but without using a namespace declarati=
on concept like XML does.



For some reason that does not seem to be enough to use IANA alone: the docu=
ment introduces three types of claims, namely Reserved Claim Names, Public =
Claim Names, and Private Claim Names



No mechanism is stated how these claims can be differentiated but essential=
ly everything is allowed. Section 2 ("Terminology") says that the claims th=
at are not registered through IANA may be Domain Names, Object Identifiers =
(OIDs), UUIDs, etc.



Later in Section 4.2 it is said that public claims could be a URI, which is=
 again different to what is said in Section 2.



Furthermore, Private Claims (as defined in Section 4.3) do not seem to have=
 the requirement for uniqueness anymore even though Section 4 says that cla=
im names in a JWT have to be unique.



The danger is obviously that two parties define claim names that have diffe=
rent semantic. This will lead to confusion. When claims with the same names=
 are added to a JWT then, per specification, the receiver will have to fail=
.



If people are following the spec and using (IANA) reserved claim names, or =
public claim names (those containing a collision-resistant namespace), then=
 the same names will always have the same semantics.  IANA is used for rese=
rved claim names, where conflicts would otherwise be likely.  IANA is unnec=
essary for public claim names, because the collision-resistant namespace in=
 the claim name prevents duplication.



Do we really need to support claims where uniqueness cannot be guaranteed?



Private claim names are there because in some contexts, the communication i=
s between a fixed or constrained set of parties between whom private agreem=
ents are a perfectly acceptable namespace allocation solution.  Indeed, it =
wouldn't make much sense to register the meanings of claims with IANA that =
will only be used in a closed environment.



Can we decide on a few namespace concepts rather than leaving the list open=
-ended? What are the JOSE guys going to do about this issue?



The same namespace allocation strategy is being used by JOSE.



Btw, is it allowed to use JavaScript reserved keywords as claim names?



Yes



* "Mandatory to Implement"/"Mandatory to Understand"



Section 4 you write:



"

When used in a security-related context,

   implementations MUST understand and support all of the claims

   present; otherwise, the JWT MUST be rejected for processing.

"



In the same paragraph you write:



"

   Note

   however, that the set of claims that a JWT must contain to be

   considered valid is context-dependent and is outside the scope of

   this specification.

"



Wouldn't it also be application context dependent to decide how unknown cla=
ims are dealt with.

I fear that the above statement would lead to the problem that no extension=
s are possible anymore since you cannot be sure that the recipient understa=
nds all the extensions.



(See my reply to Prateek Mishra on the same topic.)



Then, in Section 4.1 you write:



"

The following claim names are reserved.  None of the claims defined

   below are intended to be mandatory, but rather, provide a starting

   point for a set of useful, interoperable claims.

"



What does mandatory mean here? Given the statement you made above all claim=
s must be understood anyway.



Mandatory to use.  I'll plan to clarify this in the next draft.



Almost every claim description contains the following statement: "This clai=
m is OPTIONAL."

What does this mean? Here are a few choices of what it could mean:



* A library does not need to implement it.

 * When an entity receives a JWT with an optional claim it can safely ignor=
e it.

 * When constructing a JWT payload this claim is optional to include.



The intended meaning is "Use of this claim is OPTIONAL."  I'll clarify this=
 in the next draft.



* Data Types



I would suggest to move the two data types (IntDate & StringOrURI) into a s=
eparate Section instead of leaving them in the terminology since you are us=
ing RFC 2119 language there.



This would make for a pretty short section.  I realize that RFC 2119 langua=
ge shouldn't be used in the abstract or introduction, but the RFC 2119 requ=
irements are legitimate constraints on the definitions of these terms.



* MTI Algorithms



You list a number of algorithms that must be implemented, namely "RSA-PKCS1=
-1.5 with 2048 bit keys, AES-128-KW, AES-256-KW, AES-128-CBC, and AES-256-C=
BC". While this may be a good choice for a Web environment I doubt it is us=
eful for other, more constrained use cases.



There are a few ways to deal with this, such as:



-  Avoid a MTI list and use RECOMMENDED language.

 -  State the usage environment and thereby provide an escape clause for ot=
her use cases.

 -  Outsource these algorithsm into a separate document that can be updated=
 independently.



Having a small set of MTI algorithms is part of what makes the spec simple =
and promotes real interoperability.  That being said, per Sean Turner's sug=
gestion, the Required/Recommended/Optional/Deprecated status of algorithms =
can change over time in the IANA algorithms registry, as the changing crypt=
o landscape may require.



* Security Consideration Section



I think the text could be improved. I was hoping to see some text about the=
 plaintext JWS.



I will try to make a suggestion in the next few days.



Sure - that would be good.



* Examples



To me it seems that Appendix A & Appendix B are a copy-and-paste of the tex=
t in http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07.



Maybe it would be better to replace the text with a reference to draft-ietf=
-jose-json-web-signature-07. No need to artificially increase the size of t=
he document.



It's an editorial judgment call.  The example is there so people reading th=
e JWT spec first will get the (correct) sense that "this is pretty simple".=
  If they have to immediately go to another spec just to see an example, my=
 sense is that they'll likely think "this is already getting complicated!".



* References



The references to [JWA], [JWK], and [JWS] are incomplete. [JWS] and [JWK] h=
as to be, IMHO, a normative reference.



I'll plan to address this in the next draft.



[USA15] is not a normative reference, IMHO.



I think it's probably normative because it occurs in the context of RFC 211=
9 language: "Unicode Normalization [USA15] MUST NOT be applied...".



Ciao

Hannes

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

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











Thanks for the review comments, Hannes.  Rep=
lies are inline in green...=



 


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


 


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

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of H=
annes Tschofenig

Sent: Sunday, November 25, 2012 11:49 AM

To: oauth@ietf.org WG

Subject: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05


 


Hi all, 


 


I reviewed the document and I have a few question=
s (see below). I also think that this document has to wait for the JOSE doc=
uments to complete WGLC before it can be moved forward. It will have to wai=
t anyway in the queue because of the
 normative dependency. 


 


Agreed


 


- Header


 


In Section 3.1 you have an example of a JWT with =
an HMAC SHA-256 keyed message digest.



I would have assumed that the header contains the=
 key id so that the receipient can actually decode it. I am sure you assume=
 it implicitly determines it (somehow) but wouldn't it be better practice t=
o additionally include the kid field
 to make it less ambigious? 


 


I agree that in som=
e contexts, including a Key ID would be important.  That being said, i=
n other contexts, including some OAuth contexts, the key is implicitly know=
n from context.  For instance, a shared symmetric
 key may be assigned to be used for an OAuth client at client registration =
time.  In that case, both the client and the server already know what =
key to use without needing a Key ID.  The same may true when using pub=
lic key cryptography with an issuer that publishes
 a public key and a relying party that also publishes a public key.  H=
ere again, the correct keys to be used can be determined via means external=
 to the token itself.


 


- Namespace


 


The document defines a couple of claims. Quite na=
turally one wants to provide extension points since others will quite likel=
y come up with new claims in the near future. The obvious approach would be=
 to use an IANA registry to maintain
 uniqueness of the labels but without using a namespace declaration concept=
 like XML does.



 


For some reason that does not seem to be enough t=
o use IANA alone: the document introduces three types of claims, namely Res=
erved Claim Names, Public Claim Names, and Private Claim Names

 


No mechanism is stated how these claims can be di=
fferentiated but essentially everything is allowed. Section 2 ("Termin=
ology") says that the claims that are not registered through IANA may =
be Domain Names, Object Identifiers (OIDs),
 UUIDs, etc. 


 


Later in Section 4.2 it is said that public claim=
s could be a URI, which is again different to what is said in Section 2.



 


Furthermore, Private Claims (as defined in Sectio=
n 4.3) do not seem to have the requirement for uniqueness anymore even thou=
gh Section 4 says that claim names in a JWT have to be unique.



 


The danger is obviously that two parties define c=
laim names that have different semantic. This will lead to confusion. When =
claims with the same names are added to a JWT then, per specification, the =
receiver will have to fail.



 


If people are follo=
wing the spec and using (IANA) reserved claim names, or public claim names =
(those containing a collision-resistant namespace), then the same names wil=
l always have the same semantics.  IANA
 is used for reserved claim names, where conflicts would otherwise be likel=
y.  IANA is unnecessary for public claim names, because the collision-=
resistant namespace in the claim name prevents duplication.


 


Do we really need to support claims where uniquen=
ess cannot be guaranteed?


 


Private claim names=
 are there because in some contexts, the communication is between a fixed o=
r constrained set of parties between whom private agreements are a perfectl=
y acceptable namespace allocation solution. 
 Indeed, it wouldn’t make much sense to register the meanings of clai=
ms with IANA that will only be used in a closed environment.


 


Can we decide on a few namespace concepts rather =
than leaving the list open-ended? What are the JOSE guys going to do about =
this issue?


 


The same namespace =
allocation strategy is being used by JOSE.


 


Btw, is it allowed to use JavaScript reserved key=
words as claim names?


 


Yes


 


* "Mandatory to Implement"/"Mandat=
ory to Understand"


 


Section 4 you write:


 


"


When used in a security-related context,


   implementations MUST understand and =
support all of the claims


   present; otherwise, the JWT MUST be =
rejected for processing.


"


 


In the same paragraph you write: 


 


"


   Note


   however, that the set of claims that=
 a JWT must contain to be


   considered valid is context-dependen=
t and is outside the scope of


   this specification.


"


 


Wouldn't it also be application context dependent=
 to decide how unknown claims are dealt with.


I fear that the above statement would lead to the=
 problem that no extensions are possible anymore since you cannot be sure t=
hat the recipient understands all the extensions.



 


(See my reply to Pr=
ateek Mishra on the same topic.)


 


Then, in Section 4.1 you write:


 


"


The following claim names are reserved.  Non=
e of the claims defined


   below are intended to be mandatory, =
but rather, provide a starting


   point for a set of useful, interoper=
able claims.


"


 


What does mandatory mean here? Given the statemen=
t you made above all claims must be understood anyway.



 


Mandatory to use.&n=
bsp; I’ll plan to clarify this in the next draft.

 


Almost every claim description contains the follo=
wing statement: "This claim is OPTIONAL."


What does this mean? Here are a few choices of wh=
at it could mean:



 


* A library does not need to implement it. <=
/o:p>


 * When an entity receives a JWT with an opt=
ional claim it can safely ignore it.



 * When constructing a JWT payload this clai=
m is optional to include.



  


The intended meanin=
g is “Use of this claim is OPTIONAL.”  I’ll clarify =
this in the next draft.


 


* Data Types


 


I would suggest to move the two data types (IntDa=
te & StringOrURI) into a separate Section instead of leaving them in th=
e terminology since you are using RFC 2119 language there.



 


This would make for=
 a pretty short section.  I realize that RFC 2119 language shouldnR=
17;t be used in the abstract or introduction, but the RFC 2119 requirements=
 are legitimate constraints on the definitions
 of these terms. 


 


* MTI Algorithms


 


You list a number of algorithms that must be impl=
emented, namely "RSA-PKCS1-1.5 with 2048 bit keys, AES-128-KW, AES-256=
-KW, AES-128-CBC, and AES-256-CBC". While this may be a good choice fo=
r a Web environment I doubt it is useful for
 other, more constrained use cases. 


 


There are a few ways to deal with this, such as: =



 


-  Avoid a MTI list and use RECOMMENDED lang=
uage.  


 -  State the usage environment and the=
reby provide an escape clause for other use cases.



 -  Outsource these algorithsm into a s=
eparate document that can be updated independently.



 


Having a small set =
of MTI algorithms is part of what makes the spec simple and promotes real i=
nteroperability.  That being said, per Sean Turner’s suggestion,=
 the Required/Recommended/Optional/Deprecated status
 of algorithms can change over time in the IANA algorithms registry, as the=
 changing crypto landscape may require.


 


* Security Consideration Section


 


I think the text could be improved. I was hoping =
to see some text about the plaintext JWS.



 


I will try to make a suggestion in the next few d=
ays.  



 


Sure – that w=
ould be good.


 


* Examples


 


To me it seems that Appendix A & Appendix B a=
re a copy-and-paste of the text in
http://tools.ietf.o=
rg/html/draft-ietf-jose-json-web-signature-07.



 


Maybe it would be better to replace the text with=
 a reference to draft-ietf-jose-json-web-signature-07. No need to artificia=
lly increase the size of the document.



 


It’s an edito=
rial judgment call.  The example is there so people reading the JWT sp=
ec first will get the (correct) sense that “this is pretty simpleR=
21;.  If they have to immediately go to another spec just to
 see an example, my sense is that they’ll likely think “this is=
 already getting complicated!”.


 


* References 


 


The references to [JWA], [JWK], and [JWS] are inc=
omplete. [JWS] and [JWK] has to be, IMHO, a normative reference.



 


I’ll plan to =
address this in the next draft.


 


[USA15] is not a normative reference, IMHO. =



 


I think it’s =
probably normative because it occurs in the context of RFC 2119 language: &=
#8220;Unicode Normalization [USA15] MUST NOT be applied…”.=



 


Ciao


Hannes


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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






--_000_4E1F6AAD24975D4BA5B168042967394366924E28TK5EX14MBXC283r_--

From internet-drafts@ietf.org  Tue Dec 11 11:54:46 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27E921F867A; Tue, 11 Dec 2012 11:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLcCN4KwmExJ; Tue, 11 Dec 2012 11:54:46 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3288121F8746; Tue, 11 Dec 2012 11:54:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.36
Message-ID: <20121211195422.8854.81430.idtracker@ietfa.amsl.com>
Date: Tue, 11 Dec 2012 11:54:22 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Dec 2012 19:54:47 -0000

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

	Title           : OAuth Dynamic Client Registration Protocol
	Author(s)       : Justin Richer
                          John Bradley
                          Michael B. Jones
                          Maciej Machulak
	Filename        : draft-ietf-oauth-dyn-reg-03.txt
	Pages           : 20
	Date            : 2012-12-11

Abstract:
   This specification defines an endpoint and protocol for dynamic
   registration of OAuth Clients at an Authorization Server.


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

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

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


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


From jricher@mitre.org  Tue Dec 11 13:55:52 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD5821F850D for ; Tue, 11 Dec 2012 13:55:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.436
X-Spam-Level: 
X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZYOVd+PcNFR for ; Tue, 11 Dec 2012 13:55:51 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id C8C2421E805A for ; Tue, 11 Dec 2012 13:55:50 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C25241F0391 for ; Tue, 11 Dec 2012 16:55:49 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B622B1F0350 for ; Tue, 11 Dec 2012 16:55:49 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 11 Dec 2012 16:55:49 -0500
Message-ID: <50C7AB7B.5070105@mitre.org>
Date: Tue, 11 Dec 2012 16:54:03 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: 
References: <20121211195422.8854.81430.idtracker@ietfa.amsl.com>
In-Reply-To: <20121211195422.8854.81430.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 11 Dec 2012 21:55:52 -0000

New edition of the dynamic registration spec, incorporating comments 
from the community. Key functional changes:

* client_register and client_update requests now return a JSON object of 
the full client
* operations on client_update now allow for three states: leave existing 
value, replace existing value, delete existing value
* clarified various bits of text throughout the document
* forgot to update the change log before uploading the draft ;)

So there's the rough consensus, and to supply working code, I'm working 
on a Java-based implementation of this now and hope to have it up this 
week as part of our Spring Security based OpenID Connect server: 
https://github.com/mitreid-connect/

  -- Justin

On 12/11/2012 02:54 PM, internet-drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>   This draft is a work item of the Web Authorization Protocol Working Group of the IETF.
>
> 	Title           : OAuth Dynamic Client Registration Protocol
> 	Author(s)       : Justin Richer
>                            John Bradley
>                            Michael B. Jones
>                            Maciej Machulak
> 	Filename        : draft-ietf-oauth-dyn-reg-03.txt
> 	Pages           : 20
> 	Date            : 2012-12-11
>
> Abstract:
>     This specification defines an endpoint and protocol for dynamic
>     registration of OAuth Clients at an Authorization Server.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From hannes.tschofenig@gmx.net  Wed Dec 12 02:06:24 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9A021F89AB for ; Wed, 12 Dec 2012 02:06:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWZDj+TSzbz1 for ; Wed, 12 Dec 2012 02:06:23 -0800 (PST)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9D83521F89A8 for ; Wed, 12 Dec 2012 02:06:22 -0800 (PST)
Received: (qmail invoked by alias); 12 Dec 2012 10:06:21 -0000
Received: from dslb-188-107-244-214.pools.arcor-ip.net (EHLO [192.168.178.174]) [188.107.244.214] by mail.gmx.net (mp012) with SMTP; 12 Dec 2012 11:06:21 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/MJWNUYAvM7dNPgHQnEvxL7oJfF7Jue6PqREtw24 avjzw4Vni7amPt
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 12 Dec 2012 11:06:22 +0100
Message-Id: <9025D97F-12E8-4185-B95F-10E186D301F0@gmx.net>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Conference Call next Friday
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 10:06:24 -0000

Nat and John kindly provided a conference bridge for our call next =
Friday.=20
Here is the info:
https://www3.gotomeeting.com/join/695548174

You may need to download a plug-in. The bridge supports screen-sharing, =
VoIP calls and connection via the PSTN.=20

Begin forwarded message:

> From: Derek Atkins 
> Date: December 4, 2012 5:27:38 PM GMT+01:00
> To: oauth@ietf.org
> Subject: [OAUTH-WG] OAUTH Conference Call Dec 14th, 2012 (was Re: =
OAuth WG Virtual Interim Meetings, 11 January 2013 & 21 January 2013)
>=20
> FYI,
>=20
> We will also be holding a conference call on Friday, December 14th at
> 1pm EST.  This call is not an official virtual interim meeting which
> means no decisions can be made, but it is a time where we plan to
> discuss progress and discuss any open issues.
>=20
> We will send out dial-in information ASAP.
>=20
> Thanks,
>=20
> -derek, wg co-chair
>=20
> IESG Secretary  writes:
>=20
>> The OAuth Working Group will hold virtual interim meetings as =
follows:
>>=20
>> * 11th January 2013, 1pm EST
>> * 21st January 2013, 1pm EST
>>=20
>> Agenda and dial-in information will be posted on the OAuth mailing =
list=20
>> (http://www.ietf.org/mail-archive/web/oauth/current/maillist.html) =
prior=20
>> to the meetings.
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>=20
> --=20
>       Derek Atkins                 617-623-3745
>       derek@ihtfp.com             www.ihtfp.com
>       Computer and Internet Security Consultant
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From sakimura@gmail.com  Wed Dec 12 06:53:12 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96C811E80D9 for ; Wed, 12 Dec 2012 06:53:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.334
X-Spam-Level: 
X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=1.264,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S87MIKt6pv+L for ; Wed, 12 Dec 2012 06:53:11 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6751111E80C5 for ; Wed, 12 Dec 2012 06:53:11 -0800 (PST)
Received: by mail-ee0-f44.google.com with SMTP id b47so533032eek.31 for ; Wed, 12 Dec 2012 06:53:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=xT0wH0nb3rFTaU/S1rVrqcZLRAu/P0DO/l4lK4qn5fs=; b=RxJFOrqOCvwM36XaCiXcH/3Yf7N0u2uML6+3irtXj/ahGaV9+RoVq1rmDqXayqQVaz /xQiedYj66bp6pLmHXW4f7ifj5aGTFuV4B16ifdsysF0jY0zGYRqGFcFkB/NNVLUeS2V UYQTzfgsiISDriNoaN2+nMhcCzS+k7R1tQmtQ3xVeF9BdQPT6LSD4+eJezU1AxeIaIPH BdoOh8Fmc2i97AsIFtJj7FQy7U9nTKCjmgGUrgM8OAEmtyYFM+qEXr7g/ar/yWhdpl4H OUyxIvRcV0Ezy8Kve1l1ivdCdV4Zne/jujlQSv+/uhhYvtWLClKpbIfk1QCQi6xXkwe+ M3WA==
MIME-Version: 1.0
Received: by 10.14.214.132 with SMTP id c4mr3416163eep.18.1355323988001; Wed, 12 Dec 2012 06:53:08 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Wed, 12 Dec 2012 06:53:07 -0800 (PST)
In-Reply-To: <20121212144643.27778.98353.idtracker@ietfa.amsl.com>
References: <20121212144643.27778.98353.idtracker@ietfa.amsl.com>
Date: Wed, 12 Dec 2012 23:53:07 +0900
Message-ID: 
From: Nat Sakimura 
To: oauth 
Content-Type: multipart/alternative; boundary=047d7b621df8dc43e804d0a8f44d
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 14:53:13 -0000

--047d7b621df8dc43e804d0a8f44d
Content-Type: text/plain; charset=ISO-8859-1

Hello OAuthers:

I have finally found the time to create the -00 draft for the "Hyperlinked
OAuth" that was discussed and was made into my action item to draft at IETF
85. The name is kind of terrible, so I welcome other name suggestions.

Best,

Nat

---------- Forwarded message ----------
From: 
Date: Wed, Dec 12, 2012 at 11:46 PM
Subject: New Version Notification for draft-sakimura-oauth-meta-00.txt



A new version of I-D, draft-sakimura-oauth-meta-00.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-meta
Revision:        00
Title:           JSON Metadata for OAuth Responses
Creation date:   2012-12-12
WG ID:           Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-00.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-meta
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-meta-00


Abstract:
   This specification defines an extensible metadata member that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed as a member called "_links"
   that is inserted as the top level member in the responses.  It will
   allow the client to learn where the members in the response could be
   used and how, etc.  Since it is just a member, any client that does
   not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to its advantage.




The IETF Secretariat

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

Hello OAuthers:=A0

I have finally found the time to crea=
te the -00 draft for the "Hyperlinked OAuth" that was discussed a=
nd was made into my action item to draft at IETF 85. The name is kind of te=
rrible, so I welcome other name suggestions.=A0



Best,=A0

Nat

---------- Forwarded message ----------
From:  <internet-drafts@ietf.org>

Date: Wed, Dec 12, 2012 at 11:46 PM
Subject: New Version Notification fo=
r draft-sakimura-oauth-meta-00.txt




A new version of I-D, draft-sakimura-oauth-meta-00.txt

has been successfully submitted by Nat Sakimura and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-sakimura-oauth-meta

Revision: =A0 =A0 =A0 =A000

Title: =A0 =A0 =A0 =A0 =A0 JSON Metadata for OAuth Responses

Creation date: =A0 2012-12-12

WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 9

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/in=
ternet-drafts/draft-sakimura-oauth-meta-00.txt

Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dra=
ft-sakimura-oauth-meta

Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-sakimu=
ra-oauth-meta-00





Abstract:

=A0 =A0This specification defines an extensible metadata member that may be=


=A0 =A0inserted into the OAuth 2.0 responses to assist the clients to

=A0 =A0process those responses. =A0It is expressed as a member called "=
;_links"

=A0 =A0that is inserted as the top level member in the responses. =A0It wil=
l

=A0 =A0allow the client to learn where the members in the response could be=


=A0 =A0used and how, etc. =A0Since it is just a member, any client that doe=
s

=A0 =A0not understand this extension should not break and work normally

=A0 =A0while supporting clients can utilize the metadata to its advantage.<=
br>








The IETF Secretariat









--047d7b621df8dc43e804d0a8f44d--

From jricher@mitre.org  Wed Dec 12 09:35:00 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B08421E80EF for ; Wed, 12 Dec 2012 09:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.445
X-Spam-Level: 
X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKBuciFA2zXv for ; Wed, 12 Dec 2012 09:34:59 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6127021E80EC for ; Wed, 12 Dec 2012 09:34:59 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D46474350271 for ; Wed, 12 Dec 2012 12:34:58 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BC0591F08B1 for ; Wed, 12 Dec 2012 12:34:58 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 12 Dec 2012 12:34:58 -0500
Message-ID: <50C8BFD7.5090301@mitre.org>
Date: Wed, 12 Dec 2012 12:33:11 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: 
References: <20121211195422.8854.81430.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.83.31.58]
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-dyn-reg-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 12 Dec 2012 17:35:00 -0000

One more change in there that I forget:

  * added "scope" and "grant_type" registration parameters to let 
clients tell the AS about their intended operations

And our implementation is now uploaded. You can see the actual 
processing endpoint code here:

https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/blob/master/openid-connect-server/src/main/java/org/mitre/openid/connect/web/ClientDynamicRegistrationEndpoint.java

  -- Justin

On 12/11/2012 04:54 PM, Justin Richer wrote:
> New edition of the dynamic registration spec, incorporating comments 
> from the community. Key functional changes:
>
> * client_register and client_update requests now return a JSON object 
> of the full client
> * operations on client_update now allow for three states: leave 
> existing value, replace existing value, delete existing value
> * clarified various bits of text throughout the document
> * forgot to update the change log before uploading the draft ;)
>
> So there's the rough consensus, and to supply working code, I'm 
> working on a Java-based implementation of this now and hope to have it 
> up this week as part of our Spring Security based OpenID Connect 
> server: https://github.com/mitreid-connect/
>
>  -- Justin
>
> On 12/11/2012 02:54 PM, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts 
>> directories.
>>   This draft is a work item of the Web Authorization Protocol Working 
>> Group of the IETF.
>>
>>     Title           : OAuth Dynamic Client Registration Protocol
>>     Author(s)       : Justin Richer
>>                            John Bradley
>>                            Michael B. Jones
>>                            Maciej Machulak
>>     Filename        : draft-ietf-oauth-dyn-reg-03.txt
>>     Pages           : 20
>>     Date            : 2012-12-11
>>
>> Abstract:
>>     This specification defines an endpoint and protocol for dynamic
>>     registration of OAuth Clients at an Authorization Server.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-dyn-reg-03
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


From sakimura@gmail.com  Wed Dec 12 19:14:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A1621F8858 for ; Wed, 12 Dec 2012 19:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.064
X-Spam-Level: 
X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=0.534,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buEtEfsKEJIN for ; Wed, 12 Dec 2012 19:14:33 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4AA021F87FA for ; Wed, 12 Dec 2012 19:14:32 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id b25so1258371qca.31 for ; Wed, 12 Dec 2012 19:14:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=mkb/W/6rei2nry4cy10Q7puJlue3KTcCz1+BDEmCT4I=; b=qA/nhOk3ePMxFxP1oIr5LP7PIKQD3jV877yXvqnYdhHE9rU1tgPb7110Jt2SflWPHy pvfaGhPOuziPAnADyisnx115CODIeetL/zRY9WzHxm2+QVL9R6rL96cFrM1WhqfQBk3v tE3NcoFTiPP52qxMhKHIoxqB8jBK7QAo29nxuG4Us6k3ASYYCoNIPb0aaMClDmieyh5p TMo3pe1YagxXabWRwKLfYEptb9P3Hl61x90pqzuxCMXddBcbSJRMRK3A5EgxJ1+8dZjq jcTHSxYfC7OHEKIm8QTzUhGUv3v+MYYq92JYd5L28dBdh3DozmB4NwI8ynDIdIoNoHrz gwGw==
MIME-Version: 1.0
Received: by 10.49.48.45 with SMTP id i13mr158136qen.48.1355368472130; Wed, 12 Dec 2012 19:14:32 -0800 (PST)
Received: by 10.229.194.32 with HTTP; Wed, 12 Dec 2012 19:14:31 -0800 (PST)
In-Reply-To: 
References: <20121212144643.27778.98353.idtracker@ietfa.amsl.com> 
Date: Thu, 13 Dec 2012 12:14:31 +0900
Message-ID: 
From: Nat Sakimura 
To: oauth 
Content-Type: multipart/alternative; boundary=047d7b67896452363004d0b350c5
Subject: Re: [OAUTH-WG] New Version Notification for draft-sakimura-oauth-meta-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Dec 2012 03:14:35 -0000

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

There were several formatting issues and typos that I did not correct
before submitting -00.

Funnily, the tools.ietf.org refuses accepting it saying that there is nits
with idnits 2.12.14. It goes fine with idnits 2.12.13 and
tools.ietf.orgprovides only 2.12.13 for us right now so I cannot
debug.

So here is the text for -01. Please use this version instead of -00. -00
looks kind of ok in XML Mind, but rendered txt version sometimes does not
make sense due to the way xrefs are rendered.

Cheers,

Nat



Network Working Group                                   N. Sakimura, Ed.
Internet-Draft                                 Nomura Research Institute
Intended status: Standards Track                       December 12, 2012
Expires: June 15, 2013


                   JSON Metadata for OAuth Responses
                      draft-sakimura-oauth-meta-01

Abstract

   This specification defines an extensible metadata member that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed as a member called "_links"
   that is inserted as the top level member in the responses.  It will
   allow the client to learn where the members in the response could be
   used and how, etc.  Since it is just a member, any client that does
   not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to its advantage.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 15, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Sakimura                  Expires June 15, 2013                 [Page 1]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  JSON Meta Object  . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  _links Member . . . . . . . . . . . . . . . . . . . . . . . 4
       3.1.1.  href  . . . . . . . . . . . . . . . . . . . . . . . . . 4
       3.1.2.  method  . . . . . . . . . . . . . . . . . . . . . . . . 5
       3.1.3.  params  . . . . . . . . . . . . . . . . . . . . . . . . 5
       3.1.4.  content-type  . . . . . . . . . . . . . . . . . . . . . 5
       3.1.5.  Authorize . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Application to the OAuth 2.0 Token Endpoint Responses . . . . . 5
     4.1.  Successful Responses  . . . . . . . . . . . . . . . . . . . 5
       4.1.1.  self  . . . . . . . . . . . . . . . . . . . . . . . . . 6
       4.1.2.  describedby . . . . . . . . . . . . . . . . . . . . . . 6
       4.1.3.  Protected Resources . . . . . . . . . . . . . . . . . . 6
     4.2.  Error Responses . . . . . . . . . . . . . . . . . . . . . . 7
       4.2.1.  self  . . . . . . . . . . . . . . . . . . . . . . . . . 7
       4.2.2.  describedby . . . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
     5.1.  Link Type Registration  . . . . . . . . . . . . . . . . . . 7
       5.1.1.  OAuth 2 Registrations . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
     6.1.  href tampering  . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informational References  . . . . . . . . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

















Sakimura                  Expires June 15, 2013                 [Page 2]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


1.  Introduction

   Although OAuth 2.0 [RFC6749] has been known for its REST
   friendliness, OAuth itself is not RESTful, as it heavily relies on
   out-of-band information to drive the interactions.  This situation
   can be eased by hypertext-enabling the JSON responses through the
   introduction of a member that represents such hypertext and other
   metadata.  To achieve this, this specification introduces a top level
   member "_links" that represents various link relationships and other
   metadata.


2.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


3.  JSON Meta Object

   A JSON Meta Object uses the format described in [RFC4627] and is
   intended to be inserted into a JSON document to express some of the
   metadata associated with it as "_links" member.

   The value of the "_links" member is a JSON object that expresses link
   relationships ("rel"), which in turn holds an object with "href" and
   other members or an array of such objects.

   Following non-normative schematic example should help envisage what
   it would look like.  (Note: line-wraps are for display purpose only.)




















Sakimura                  Expires June 15, 2013                 [Page 3]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


         {
           "_links":{
             "self":{"href":"https://example.com/token?code=3D123"},
             "http://openid.net/specs/connect/1.0/#userinfo_ep":[
               {
                 "href":"https://example.com/user/{user_id}",
                 "method":"GET",
                 "Authorize":"{token_type} {access_token}"
               },
               {
                 "href":"https://example.com/user/{user_id}",
                 "method":"POST",
                 "Authorize":"{token_type} {access_token}",
                 "params":[
                   "name","birthday"
                 ]
               }
           },
           "token_type":"Bearer",
           "access_token":"aCeSsToKen"
         }

   Here, we have "_links" member that expresses various "relations" such
   as "self" and "http://openid.net/specs/connect/1.0/#userinfo_ep".
   Each relationships has either a link relations object or an array of
   link relations objects as its value.  The link relations objects
   holds various members such as "href".  They are explained in the next
   section.

3.1.  _links Member

   "_links" member holds exactly one object that contains the following
   members with relation as the "string" defined in [RFC4627].  The
   "string" SHOULD be a link relation type that is either defined in the
   IANA registry defined in Web Linking [RFC5988] or a URI that
   describes the relation.

   Each relation member holds exactly one object or one array, whose
   elements are objects.  Each object has following members, which are
   all optional.

3.1.1.  href

   The value of the "href" member is a URI Template [RFC6570] that the
   relation points to.  The values for template parameters SHOULD be
   taken from the value of the top-level members in the including JSON
   object whose "string" matches the template variable name.




Sakimura                  Expires June 15, 2013                 [Page 4]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


3.1.2.  method

   The value of the "method" member is the HTTP method defined in
   Hypertext Transfer Protocol -- HTTP/1.1 [RFC2616] that can be used to
   the URL described in the "href". e.g., GET, POST, PUT, DELETE.

3.1.3.  params

   The "params" member describes the parameters to be sent to the URL
   expressed in "href".  The "value" is an array of "pairs" whose string
   corresponds to the parameter names of the parameters that are to be
   sent to the URL.  The "value" of the "pair" is an "object" with
   following "members" .  All "members" are optional.

   required  Boolean. true or false.  Indicates whether this parameter
      is required to be sent with the request.

   description  String.  A human readable description of the variable.

3.1.4.  content-type

   The content-type to be used when the parameters are sent to the URL.

   [todo] Locate the proper reference and name for content transfer
   encodings.

   e.g., "application/x-www-form-urlencoded", "multipart/form-data",
   "application/json".

3.1.5.  Authorize

   The HTTP Authorize header defined in Hypertext Transfer Protocol --
   HTTP/1.1 [RFC2616] to be used when accessing the resource identified
   by href.  It is templated in exactly the same syntax as in URI
   Template [RFC6570] except that it is applied to the Authorization
   request header than the URI.


4.  Application to the OAuth 2.0 Token Endpoint Responses

   To create the Section 3 should be used in the token endpoint
   responses of the OAuth 2.0 Authorization Framework [RFC6749],
   following relations SHOULD be included.

4.1.  Successful Responses

   In the case of the Successful Response described in section 5.1. of
   [RFC6749], the following member SHOULD be present in the value of the



Sakimura                  Expires June 15, 2013                 [Page 5]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   "_links" member described in _links Member (Section 3.1) of this
   specification.

4.1.1.  self

   An object with the following members.

   href  REQUIRED.  The URI that resulted in this response.

4.1.2.  describedby

   An object with the following members.

   href  REQUIRED.  The value is one of the following URIs:
      "http://tools.ietf.org/html/rfc6749#section-4.1.4",
      "http://tools.ietf.org/html/rfc6749#section-4.3.3",
      "http://tools.ietf.org/html/rfc6749#section-4.4.3".

4.1.3.  Protected Resources

   Each protected resources MUST provide a unique Relation Name by
   either registering to the Link Relation Type Registry defined in
   section 6.2 of [RFC5988] or providing an absolute URI that provides a
   collision registant name.  The value is an array of objects that has
   the following members.

   href  REQUIRED.  The URI template that describes the request to the
      resource as described in href (Section 3.1.1).

   method  OPTIONAL.  HTTP request method to be used as described in
      method (Section 3.1.2).  Defaults to "GET".  Semantics of the HTTP
      methods in this case SHOULD map as follows: "GET" means reading
      the resource.  "POST" means creating or updating the resource with
      supplied parameters in "params" member below.  "DELETE" means
      deleting the corresponding resource.  "PUT" means the complete
      replacement of the resource by the body of the request.  The
      resource MUST support "GET" method.  The support of other methods
      are OPTIONAL.

   params  OPTIONAL.  Parameters to be sent as described in params
      (Section 3.1.3).

   content-type  OPTIONAL.  As described in content-type
      (Section 3.1.4).







Sakimura                  Expires June 15, 2013                 [Page 6]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   Authorize  OPTIONAL.  HTTP Authorization header to be sent when
      accessing the resource.  This is described in Authorize
      (Section 3.1.5).  If this member is not available, then the client
      SHOULD access the expanded "href" value to obtain the
      Authorization header response to learn what authorization scheme
      it should use.

4.2.  Error Responses

   In the case of the Error Response described in section 5.2. of
   [RFC6749], the folloing member SHOULD be present.

4.2.1.  self

   An object with the following members.

   href  REQUIRED.  The URI that resulted in this response.

4.2.2.  describedby

   An object with the following members.

   href  REQUIRED.  The value is
      "http://tools.ietf.org/html/rfc6749#section-5.2".


5.  IANA Considerations

5.1.  Link Type Registration

   Pursuant to [RFC5988], the following link type registrations [[will
   be]] registered by mail to link-relations@ietf.org.

5.1.1.  OAuth 2 Registrations

   The secition 3 of the OAuth 2.0 Authorization Framework [RFC6749]
   defines two endpoints that may be discovered through this
   specification.  These are the user Authorization Endpoint and the
   Token Endpoint.

5.1.1.1.  Authorization Endpoint

   o  Relation Name: oauth2-authorize

   o  Descritpion: An OAuth 2.0 Authorization Endpoint specified in
      section 3.1 of [RFC6749]





Sakimura                  Expires June 15, 2013                 [Page 7]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   o  Reference: [RFC6749]

5.1.1.2.  Token Endpoint

   o  Relation Name: oauth2-token

   o  Description: An OAuth 2.0 Token Endpoint specified in section 3.2
      of [RFC6749].

   o  Refeence: [RFC6749]


6.  Security Considerations

6.1.  href tampering

   Unless integrity protected channel is used, an attacker may be able
   to tamper the value of the href thereby causing the receiver of the
   JSON response to send a request to the URL under the attacker's
   control with potentially confidential information contained in the
   parameters.  To mitigate this risk, an integrity protected channel
   such as TLS protected channel should be used.


7.  Acknowledgements

   This specification borrows heavily from [HAL].  The Link type
   registration is taken from [oauth-lrdd].

   [todo]


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 2010.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570, March 2012.




Sakimura                  Expires June 15, 2013                 [Page 8]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, October 2012.

8.2.  Informational References

   [HAL]      Kelly, M., "JSON Hypermedia API Language", 07 2012.

   [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

   [oauth-lrdd]
              Mills, W., "Link Type Registrations for OAuth 2",
              October 2012.


Author's Address

   Nat Sakimura (editor)
   Nomura Research Institute

   Email: sakimura@gmail.com






























Sakimura                  Expires June 15, 2013                 [Page 9]

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

There were several formatting issues and typos that I did not correct befor=
e submitting -00.=A0

Funnily, the tools.ietf.org refuses accepting it saying that there is ni=
ts with=A0idnits 2.12.14. It goes fine=
 with idnits 2.12.13 and tools.ietf.org provides only 2.12.13 for us right now so I cannot debug.=A0


So here is the text for -01.=A0Please use this ve=
rsion instead of -00. -00 looks kind of ok in XML Mind, but rendered txt ve=
rsion sometimes does not make sense due to the way xrefs are rendered. 



Cheers, 

Na=
t




Network Working Group                                   N. Sakimura, Ed.
Internet-Draft                                 Nomura Research Institute
Intended status: Standards Track                       December 12, 2012
Expires: June 15, 2013


                   JSON Metadata for OAuth Responses
                      draft-sakimura-oauth-meta-01

Abstract

   This specification defines an extensible metadata member that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed as a member called "_link=
s"
   that is inserted as the top level member in the responses.  It will
   allow the client to learn where the members in the response could be
   used and how, etc.  Since it is just a member, any client that does
   not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to its advantage.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at htt=
p://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 15, 2013.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.or=
g/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must



Sakimura                  Expires June 15, 2013                 [Page 1]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  JSON Meta Object  . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  _links Member . . . . . . . . . . . . . . . . . . . . . . . 4
       3.1.1.  href  . . . . . . . . . . . . . . . . . . . . . . . . . 4
       3.1.2.  method  . . . . . . . . . . . . . . . . . . . . . . . . 5
       3.1.3.  params  . . . . . . . . . . . . . . . . . . . . . . . . 5
       3.1.4.  content-type  . . . . . . . . . . . . . . . . . . . . . 5
       3.1.5.  Authorize . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Application to the OAuth 2.0 Token Endpoint Responses . . . . . 5
     4.1.  Successful Responses  . . . . . . . . . . . . . . . . . . . 5
       4.1.1.  self  . . . . . . . . . . . . . . . . . . . . . . . . . 6
       4.1.2.  describedby . . . . . . . . . . . . . . . . . . . . . . 6
       4.1.3.  Protected Resources . . . . . . . . . . . . . . . . . . 6
     4.2.  Error Responses . . . . . . . . . . . . . . . . . . . . . . 7
       4.2.1.  self  . . . . . . . . . . . . . . . . . . . . . . . . . 7
       4.2.2.  describedby . . . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
     5.1.  Link Type Registration  . . . . . . . . . . . . . . . . . . 7
       5.1.1.  OAuth 2 Registrations . . . . . . . . . . . . . . . . . 7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
     6.1.  href tampering  . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informational References  . . . . . . . . . . . . . . . . . 9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . =
9

















Sakimura                  Expires June 15, 2013                 [Page 2]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


1.  Introduction

   Although OAuth 2.0 [RFC6749] has been known for its REST
   friendliness, OAuth itself is not RESTful, as it heavily relies on
   out-of-band information to drive the interactions.  This situation
   can be eased by hypertext-enabling the JSON responses through the
   introduction of a member that represents such hypertext and other
   metadata.  To achieve this, this specification introduces a top level
   member "_links" that represents various link relationships and=
 other
   metadata.


2.  Requirements

   The key words "MUST", "MUST NOT", "REQUIRED&quo=
t;, "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", &qu=
ot;MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


3.  JSON Meta Object

   A JSON Meta Object uses the format described in [RFC4627] and is
   intended to be inserted into a JSON document to express some of the
   metadata associated with it as "_links" member.

   The value of the "_links" member is a JSON object that express=
es link
   relationships ("rel"), which in turn holds an object with &quo=
t;href" and
   other members or an array of such objects.

   Following non-normative schematic example should help envisage what
   it would look like.  (Note: line-wraps are for display purpose only.)




















Sakimura                  Expires June 15, 2013                 [Page 3]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


         {
           "_links":{
             "self":{"href":"https://example.com/token?code=3D123"}=
,
             "http://openid.net/specs/connect/1.0/#userinfo_ep":[
               {
                 "href":"https://example.com/user/{user_id}",
                 "method":"GET",
                 "Authorize":"{token_type} {access_token}&qu=
ot;
               },
               {
                 "href":"https://example.com/user/{user_id}",
                 "method":"POST",
                 "Authorize":"{token_type} {access_token}&qu=
ot;,
                 "params":[
                   "name","birthday"
                 ]
               }
           },
           "token_type":"Bearer",
           "access_token":"aCeSsToKen"
         }

   Here, we have "_links" member that expresses various "rel=
ations" such
   as "self" and "http://openid.net/specs/connect/1.0/#userinfo_ep&quo=
t;.
   Each relationships has either a link relations object or an array of
   link relations objects as its value.  The link relations objects
   holds various members such as "href".  They are explained in t=
he next
   section.

3.1.  _links Member

   "_links" member holds exactly one object that contains the fol=
lowing
   members with relation as the "string" defined in [RFC4627].  T=
he
   "string" SHOULD be a link relation type that is either defined=
 in the
   IANA registry defined in Web Linking [RFC5988] or a URI that
   describes the relation.

   Each relation member holds exactly one object or one array, whose
   elements are objects.  Each object has following members, which are
   all optional.

3.1.1.  href

   The value of the "href" member is a URI Template [RFC6570] tha=
t the
   relation points to.  The values for template parameters SHOULD be
   taken from the value of the top-level members in the including JSON
   object whose "string" matches the template variable name.




Sakimura                  Expires June 15, 2013                 [Page 4]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


3.1.2.  method

   The value of the "method" member is the HTTP method defined in
   Hypertext Transfer Protocol -- HTTP/1.1 [RFC2616] that can be used to
   the URL described in the "href". e.g., GET, POST, PUT, DELETE.

3.1.3.  params

   The "params" member describes the parameters to be sent to the=
 URL
   expressed in "href".  The "value" is an array of &qu=
ot;pairs" whose string
   corresponds to the parameter names of the parameters that are to be
   sent to the URL.  The "value" of the "pair" is an &q=
uot;object" with
   following "members" .  All "members" are optional.

   required  Boolean. true or false.  Indicates whether this parameter
      is required to be sent with the request.

   description  String.  A human readable description of the variable.

3.1.4.  content-type

   The content-type to be used when the parameters are sent to the URL.

   [todo] Locate the proper reference and name for content transfer
   encodings.

   e.g., "application/x-www-form-urlencoded", "multipart/for=
m-data",
   "application/json".

3.1.5.  Authorize

   The HTTP Authorize header defined in Hypertext Transfer Protocol --
   HTTP/1.1 [RFC2616] to be used when accessing the resource identified
   by href.  It is templated in exactly the same syntax as in URI
   Template [RFC6570] except that it is applied to the Authorization
   request header than the URI.


4.  Application to the OAuth 2.0 Token Endpoint Responses

   To create the Section 3 should be used in the token endpoint
   responses of the OAuth 2.0 Authorization Framework [RFC6749],
   following relations SHOULD be included.

4.1.  Successful Responses

   In the case of the Successful Response described in section 5.1. of
   [RFC6749], the following member SHOULD be present in the value of the



Sakimura                  Expires June 15, 2013                 [Page 5]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   "_links" member described in _links Member (Section 3.1) of th=
is
   specification.

4.1.1.  self

   An object with the following members.

   href  REQUIRED.  The URI that resulted in this response.

4.1.2.  describedby

   An object with the following members.

   href  REQUIRED.  The value is one of the following URIs:
      "ht=
tp://tools.ietf.org/html/rfc6749#section-4.1.4",
      "ht=
tp://tools.ietf.org/html/rfc6749#section-4.3.3",
      "ht=
tp://tools.ietf.org/html/rfc6749#section-4.4.3".

4.1.3.  Protected Resources

   Each protected resources MUST provide a unique Relation Name by
   either registering to the Link Relation Type Registry defined in
   section 6.2 of [RFC5988] or providing an absolute URI that provides a
   collision registant name.  The value is an array of objects that has
   the following members.

   href  REQUIRED.  The URI template that describes the request to the
      resource as described in href (Section 3.1.1).

   method  OPTIONAL.  HTTP request method to be used as described in
      method (Section 3.1.2).  Defaults to "GET".  Semantics of t=
he HTTP
      methods in this case SHOULD map as follows: "GET" means rea=
ding
      the resource.  "POST" means creating or updating the resour=
ce with
      supplied parameters in "params" member below.  "DELETE=
" means
      deleting the corresponding resource.  "PUT" means the compl=
ete
      replacement of the resource by the body of the request.  The
      resource MUST support "GET" method.  The support of other m=
ethods
      are OPTIONAL.

   params  OPTIONAL.  Parameters to be sent as described in params
      (Section 3.1.3).

   content-type  OPTIONAL.  As described in content-type
      (Section 3.1.4).







Sakimura                  Expires June 15, 2013                 [Page 6]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   Authorize  OPTIONAL.  HTTP Authorization header to be sent when
      accessing the resource.  This is described in Authorize
      (Section 3.1.5).  If this member is not available, then the client
      SHOULD access the expanded "href" value to obtain the
      Authorization header response to learn what authorization scheme
      it should use.

4.2.  Error Responses

   In the case of the Error Response described in section 5.2. of
   [RFC6749], the folloing member SHOULD be present.

4.2.1.  self

   An object with the following members.

   href  REQUIRED.  The URI that resulted in this response.

4.2.2.  describedby

   An object with the following members.

   href  REQUIRED.  The value is
      "http=
://tools.ietf.org/html/rfc6749#section-5.2".


5.  IANA Considerations

5.1.  Link Type Registration

   Pursuant to [RFC5988], the following link type registrations [[will
   be]] registered by mail to li=
nk-relations@ietf.org.

5.1.1.  OAuth 2 Registrations

   The secition 3 of the OAuth 2.0 Authorization Framework [RFC6749]
   defines two endpoints that may be discovered through this
   specification.  These are the user Authorization Endpoint and the
   Token Endpoint.

5.1.1.1.  Authorization Endpoint

   o  Relation Name: oauth2-authorize

   o  Descritpion: An OAuth 2.0 Authorization Endpoint specified in
      section 3.1 of [RFC6749]





Sakimura                  Expires June 15, 2013                 [Page 7]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   o  Reference: [RFC6749]

5.1.1.2.  Token Endpoint

   o  Relation Name: oauth2-token

   o  Description: An OAuth 2.0 Token Endpoint specified in section 3.2
      of [RFC6749].

   o  Refeence: [RFC6749]


6.  Security Considerations

6.1.  href tampering

   Unless integrity protected channel is used, an attacker may be able
   to tamper the value of the href thereby causing the receiver of the
   JSON response to send a request to the URL under the attacker's
   control with potentially confidential information contained in the
   parameters.  To mitigate this risk, an integrity protected channel
   such as TLS protected channel should be used.


7.  Acknowledgements

   This specification borrows heavily from [HAL].  The Link type
   registration is taken from [oauth-lrdd].

   [todo]


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC5988]  Nottingham, M., "Web Linking", RFC 5988, October 20=
10.

   [RFC6570]  Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
              and D. Orchard, "URI Template", RFC 6570, March 201=
2.




Sakimura                  Expires June 15, 2013                 [Page 8]
=0C
Internet-Draft                 OAuth-Meta                  December 2012


   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, October 2012.

8.2.  Informational References

   [HAL]      Kelly, M., "JSON Hypermedia API Language", 07 2012.

   [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

   [oauth-lrdd]
              Mills, W., "Link Type Registrations for OAuth 2",
              October 2012.


Author's Address

   Nat Sakimura (editor)
   Nomura Research Institute

   Email: sakimura@gmail.com






























Sakimura                  Expires June 15, 2013                 [Page 9]
=0C






--047d7b67896452363004d0b350c5--

From zhou.sujing@zte.com.cn  Wed Dec 12 23:05:15 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E8021F8436; Wed, 12 Dec 2012 23:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.006
X-Spam-Level: 
X-Spam-Status: No, score=-98.006 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45,  USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWFeQNwtEW8J; Wed, 12 Dec 2012 23:05:14 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id E891521F88A9; Wed, 12 Dec 2012 23:05:13 -0800 (PST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id A5A2F13BCF28; Thu, 13 Dec 2012 15:06:54 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBD74kYV092049; Thu, 13 Dec 2012 15:04:46 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <20121210183357.31726.20901.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Thu, 13 Dec 2012 15:04:37 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-13 15:04:41, Serialize complete at 2012-12-13 15:04:41
Content-Type: multipart/alternative; boundary="=_alternative 0027025648257AD3_="
X-MAIL: mse02.zte.com.cn qBD74kYV092049
Cc: oauth@ietf.org, IETF-Announce , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Dec 2012 07:05:15 -0000

This is a multipart message in MIME format.
--=_alternative 0027025648257AD3_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SW4gInNlY3Rpb24gMw0KIFRoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVy
OyBpdHMNCiByb2xlIGlzIHRvIGZ1bGZpbGwgcmVxdWVzdHMgZnJvbSBjbGllbnRzLCB3aGljaCBw
cmVzZW50IHZhcmlvdXMNCiBjcmVkZW50aWFscywgYW5kIG1pbnQgYXNzZXJ0aW9ucyBhcyByZXF1
ZXN0ZWQsIGZpbGwgdGhlbSB3aXRoDQogYXBwcm9wcmlhdGUgaW5mb3JtYXRpb24sIGFuZCBzaWdu
IHRoZW0uIg0KDQoNCkFzIEkgdW5kZXJzdGFuZCwgYW4gYXNzZXJ0aW9uIGdlbmVyYXRlZCBieSBh
IFNUUywgaXMgZG9uZSBmbG9sbG93aW5nIHRoZXNzIA0Kc3RlcHM6DQoxLiBDbGllbnQgcHJlc2Vu
dHMgY3JlZGVudGlhbCBhbmQgcmVxdWVzdHMgYW4gYXNzZXJ0aW9uDQoyLiBTVFMgZ2VuZXJhdGVz
IGFzc2VydGlvbiBhbmQgc2VuZHMgdG8gQ2xpZW50DQpDb3JyZWN0Pw0KDQpUaGF0IG1heSByZXN0
cmljdCB0aGUgdXNlIGNhc2VzIHRoYXQgdGhpcyBhc3NlcnRpb24gZnJhbWV3b3JrIGNvdWxkIA0K
c3VwcG9ydCwNCmlzIGl0IGEgbXVzdD8NCg0KDQoNCg0Kb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQ
tNPaIDIwMTItMTItMTEgMDI6MzM6NTc6DQoNCj4gDQo+IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBh
IHJlcXVlc3QgZnJvbSB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV0cNCj4gKG9hdXRo
KSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiAtICdBc3NlcnRpb24gRnJh
bWV3b3JrIGZvciBPQXV0aCAyLjAnDQo+ICAgPGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0w
OC50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+IA0KPiBUaGUgSUVTRyBwbGFucyB0byBtYWtl
IGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMNCj4gZmluYWwg
Y29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRz
IHRvIHRoZQ0KPiBpZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxMi0xMi0yNC4gRXhj
ZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IA0KYmUNCj4gc2VudCB0byBpZXNnQGlldGYub3JnIGlu
c3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KPiBiZWdpbm5pbmcgb2Yg
dGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCj4gDQo+IEFic3Ry
YWN0DQo+IA0KPiANCj4gICAgVGhpcyBzcGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEgZnJhbWV3b3Jr
IGZvciB0aGUgdXNlIG9mIGFzc2VydGlvbnMNCj4gICAgd2l0aCBPQXV0aCAyLjAgaW4gdGhlIGZv
cm0gb2YgYSBuZXcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbQ0KPiAgICBhbmQgYSBu
ZXcgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlLiAgTWVjaGFuaXNtcyBhcmUgc3BlY2lmaWVkIGZv
cg0KPiAgICB0cmFuc3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zIHdpdGgg
YSB0b2tlbiBlbmRwb2ludCwgYXMNCj4gICAgd2VsbCBhcyBnZW5lcmFsIHByb2Nlc3NpbmcgcnVs
ZXMuDQo+IA0KPiAgICBUaGUgaW50ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92
aWRlIGEgY29tbW9uIGZyYW1ld29yayBmb3INCj4gICAgT0F1dGggMi4wIHRvIGludGVyd29yayB3
aXRoIG90aGVyIGlkZW50aXR5IHN5c3RlbXMgdXNpbmcgYXNzZXJ0aW9ucywNCj4gICAgYW5kIHRv
IHByb3ZpZGUgYWx0ZXJuYXRpdmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuDQo+
IA0KPiAgICBOb3RlIHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lcyBhYnN0cmFj
dCBtZXNzYWdlIGZsb3dzIGFuZA0KPiAgICBwcm9jZXNzaW5nIHJ1bGVzLiAgSW4gb3JkZXIgdG8g
YmUgaW1wbGVtZW50YWJsZSwgY29tcGFuaW9uDQo+ICAgIHNwZWNpZmljYXRpb25zIGFyZSBuZWNl
c3NhcnkgdG8gcHJvdmlkZSB0aGUgY29ycmVzcG9uZGluZyBjb25jcmV0ZQ0KPiAgICBpbnN0YW50
aWF0aW9ucy4NCj4gDQo+IA0KPiANCj4gDQo+IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWEN
Cj4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFzc2Vy
dGlvbnMvDQo+IA0KPiBJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+IGh0dHA6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zL2Jh
bGxvdC8NCj4gDQo+IA0KPiBObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQg
ZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGll
dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K
--=_alternative 0027025648257AD3_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yPkluICZxdW90O3NlY3Rpb24gMzwvZm9udD4NCjxicj48Zm9udCBz
aXplPTI+Jm5ic3A7VGhlIHRva2VuIHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbiBpc3N1ZXI7IGl0
czwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+Jm5ic3A7cm9sZSBpcyB0byBmdWxmaWxsIHJlcXVl
c3RzIGZyb20gY2xpZW50cywgd2hpY2gNCnByZXNlbnQgdmFyaW91czwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTI+Jm5ic3A7Y3JlZGVudGlhbHMsIGFuZCBtaW50IGFzc2VydGlvbnMgYXMgcmVxdWVz
dGVkLCBmaWxsDQp0aGVtIHdpdGg8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPiZuYnNwO2FwcHJv
cHJpYXRlIGluZm9ybWF0aW9uLCBhbmQgc2lnbiB0aGVtLiZxdW90OzwvZm9udD4NCjxicj4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTI+QXMgSSB1bmRlcnN0YW5kLCBhbiBhc3NlcnRpb24gZ2VuZXJh
dGVkIGJ5IGEgU1RTLCBpcyBkb25lDQpmbG9sbG93aW5nIHRoZXNzIHN0ZXBzOjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPTI+MS4gQ2xpZW50IHByZXNlbnRzIGNyZWRlbnRpYWwgYW5kIHJlcXVlc3Rz
IGFuIGFzc2VydGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+Mi4gU1RTIGdlbmVyYXRlcyBh
c3NlcnRpb24gYW5kIHNlbmRzIHRvIENsaWVudDwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+Q29y
cmVjdD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPlRoYXQgbWF5IHJlc3RyaWN0IHRo
ZSB1c2UgY2FzZXMgdGhhdCB0aGlzIGFzc2VydGlvbiBmcmFtZXdvcmsNCmNvdWxkIHN1cHBvcnQs
PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj5pcyBpdCBhIG11c3Q/PC9mb250Pg0KPGJyPg0KPGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+b2F1dGgtYm91bmNlc0BpZXRmLm9y
ZyDQtNPaIDIwMTItMTItMTEgMDI6MzM6NTc6PGJyPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRo
ZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgV2ViIEF1dGhvcml6YXRpb24g
UHJvdG9jb2wNCldHPGJyPg0KJmd0OyAob2F1dGgpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcg
ZG9jdW1lbnQ6PGJyPg0KJmd0OyAtICdBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAn
PGJyPg0KJmd0OyAmbmJzcDsgJmx0O2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wOC50eHQm
Z3Q7IGFzIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBJRVNHIHBs
YW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0
czxicj4NCiZndDsgZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1
YnN0YW50aXZlIGNvbW1lbnRzIHRvDQp0aGU8YnI+DQomZ3Q7IGlldGZAaWV0Zi5vcmcgbWFpbGlu
ZyBsaXN0cyBieSAyMDEyLTEyLTI0LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cw0KbWF5IGJlPGJy
Pg0KJmd0OyBzZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBs
ZWFzZSByZXRhaW4gdGhlPGJyPg0KJmd0OyBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0
byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q8
YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBzcGVjaWZp
Y2F0aW9uIHByb3ZpZGVzIGEgZnJhbWV3b3JrIGZvciB0aGUgdXNlIG9mDQphc3NlcnRpb25zPGJy
Pg0KJmd0OyAmbmJzcDsgJm5ic3A7d2l0aCBPQXV0aCAyLjAgaW4gdGhlIGZvcm0gb2YgYSBuZXcg
Y2xpZW50IGF1dGhlbnRpY2F0aW9uDQptZWNoYW5pc208YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDth
bmQgYSBuZXcgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlLiAmbmJzcDtNZWNoYW5pc21zDQphcmUg
c3BlY2lmaWVkIGZvcjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RyYW5zcG9ydGluZyBhc3NlcnRp
b25zIGR1cmluZyBpbnRlcmFjdGlvbnMgd2l0aCBhIHRva2VuDQplbmRwb2ludCwgYXM8YnI+DQom
Z3Q7ICZuYnNwOyAmbmJzcDt3ZWxsIGFzIGdlbmVyYWwgcHJvY2Vzc2luZyBydWxlcy48YnI+DQom
Z3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1RoZSBpbnRlbnQgb2YgdGhpcyBzcGVjaWZpY2F0
aW9uIGlzIHRvIHByb3ZpZGUgYSBjb21tb24NCmZyYW1ld29yayBmb3I8YnI+DQomZ3Q7ICZuYnNw
OyAmbmJzcDtPQXV0aCAyLjAgdG8gaW50ZXJ3b3JrIHdpdGggb3RoZXIgaWRlbnRpdHkgc3lzdGVt
cyB1c2luZw0KYXNzZXJ0aW9ucyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDthbmQgdG8gcHJvdmlk
ZSBhbHRlcm5hdGl2ZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtcy48YnI+DQomZ3Q7
IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO05vdGUgdGhhdCB0aGlzIHNwZWNpZmljYXRpb24gb25s
eSBkZWZpbmVzIGFic3RyYWN0IG1lc3NhZ2UNCmZsb3dzIGFuZDxicj4NCiZndDsgJm5ic3A7ICZu
YnNwO3Byb2Nlc3NpbmcgcnVsZXMuICZuYnNwO0luIG9yZGVyIHRvIGJlIGltcGxlbWVudGFibGUs
DQpjb21wYW5pb248YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtzcGVjaWZpY2F0aW9ucyBhcmUgbmVj
ZXNzYXJ5IHRvIHByb3ZpZGUgdGhlIGNvcnJlc3BvbmRpbmcNCmNvbmNyZXRlPGJyPg0KJmd0OyAm
bmJzcDsgJm5ic3A7aW5zdGFudGlhdGlvbnMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWE8YnI+
DQomZ3Q7IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1h
c3NlcnRpb25zLzxicj4NCiZndDsgPGJyPg0KJmd0OyBJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRy
YWNrZWQgdmlhPGJyPg0KJmd0OyBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0
LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy9iYWxsb3QvPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N
CiZndDsgTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9u
IHRoaXMgSS1ELjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5n
IGxpc3Q8YnI+DQomZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KPC9mb250PjwvdHQ+DQo=
--=_alternative 0027025648257AD3_=--

From cmortimore@salesforce.com  Thu Dec 13 08:39:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5D7121F8632; Thu, 13 Dec 2012 08:39:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.387
X-Spam-Level: 
X-Spam-Status: No, score=-6.387 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL-jCTmNCXM3; Thu, 13 Dec 2012 08:39:07 -0800 (PST)
Received: from exprod8og105.obsmtp.com (exprod8og105.obsmtp.com [64.18.3.90]) by ietfa.amsl.com (Postfix) with SMTP id 89FF221F842E; Thu, 13 Dec 2012 08:38:57 -0800 (PST)
Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob105.postini.com ([64.18.7.12]) with SMTP ID DSNKUMoEobZLe6y9WxEbreao9cdHU/8IKJsP@postini.com; Thu, 13 Dec 2012 08:38:57 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 13 Dec 2012 08:38:57 -0800
From: Chuck Mortimore 
To: "" 
Date: Thu, 13 Dec 2012 08:39:03 -0800
Thread-Topic: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
Thread-Index: Ac3ZUFglm1XeEJjNTj674/khdZLxdw==
Message-ID: <18F98790-E67A-44AD-83C6-51118716C9DA@salesforce.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_18F98790E67A44AD83C651118716C9DAsalesforcecom_"
MIME-Version: 1.0
Cc: "oauth-bounces@ietf.org" , "ietf@ietf.org" , IETF-Announce , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Dec 2012 16:39:08 -0000

--_000_18F98790E67A44AD83C651118716C9DAsalesforcecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIGxhbmd1YWdlIGlzIHNpbXBseSBtZWFudCB0byBoZWxwIGlsbHVzdHJhdGUgaG93IHRoZSBm
cmFtZXdvcmsgbWlnaHQgYmUgdXNlZC4gICBIb3cgZG8geW91IHRoaW5rIGl0IHdpbGwgcmVzdHJp
Y3QgdXNhZ2U/ICAgSG93IGNvdWxkIGl0IGJlIGltcHJvdmVkPw0KDQotY21vcnQNCg0KT24gRGVj
IDEyLCAyMDEyLCBhdCAxMTowNCBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFpbHRvOnpo
b3Uuc3VqaW5nQHp0ZS5jb20uY24+PiB3cm90ZToNCg0KDQpJbiAic2VjdGlvbiAzDQogVGhlIHRv
a2VuIHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbiBpc3N1ZXI7IGl0cw0KIHJvbGUgaXMgdG8gZnVs
ZmlsbCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoIHByZXNlbnQgdmFyaW91cw0KIGNyZWRl
bnRpYWxzLCBhbmQgbWludCBhc3NlcnRpb25zIGFzIHJlcXVlc3RlZCwgZmlsbCB0aGVtIHdpdGgN
CiBhcHByb3ByaWF0ZSBpbmZvcm1hdGlvbiwgYW5kIHNpZ24gdGhlbS4iDQoNCg0KQXMgSSB1bmRl
cnN0YW5kLCBhbiBhc3NlcnRpb24gZ2VuZXJhdGVkIGJ5IGEgU1RTLCBpcyBkb25lIGZsb2xsb3dp
bmcgdGhlc3Mgc3RlcHM6DQoxLiBDbGllbnQgcHJlc2VudHMgY3JlZGVudGlhbCBhbmQgcmVxdWVz
dHMgYW4gYXNzZXJ0aW9uDQoyLiBTVFMgZ2VuZXJhdGVzIGFzc2VydGlvbiBhbmQgc2VuZHMgdG8g
Q2xpZW50DQpDb3JyZWN0Pw0KDQpUaGF0IG1heSByZXN0cmljdCB0aGUgdXNlIGNhc2VzIHRoYXQg
dGhpcyBhc3NlcnRpb24gZnJhbWV3b3JrIGNvdWxkIHN1cHBvcnQsDQppcyBpdCBhIG11c3Q/DQoN
Cg0KDQoNCm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmc+IOWGmeS6jiAyMDEyLTEyLTExIDAyOjMzOjU3Og0KDQo+DQo+IFRoZSBJRVNHIGhhcyByZWNl
aXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJvdG9jb2wgV0cNCj4g
KG9hdXRoKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiAtICdBc3NlcnRp
b24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAnDQo+ICAgPGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0
aW9ucy0wOC50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+DQo+IFRoZSBJRVNHIHBsYW5zIHRv
IG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cw0KPiBm
aW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29t
bWVudHMgdG8gdGhlDQo+IGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZAaWV0Zi5vcmc+IG1haWxp
bmcgbGlzdHMgYnkgMjAxMi0xMi0yNC4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5IGJlDQo+
IHNlbnQgdG8gaWVzZ0BpZXRmLm9yZzxtYWlsdG86aWVzZ0BpZXRmLm9yZz4gaW5zdGVhZC4gSW4g
ZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4gdGhlDQo+IGJlZ2lubmluZyBvZiB0aGUgU3ViamVj
dCBsaW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLg0KPg0KPiBBYnN0cmFjdA0KPg0KPg0K
PiAgICBUaGlzIHNwZWNpZmljYXRpb24gcHJvdmlkZXMgYSBmcmFtZXdvcmsgZm9yIHRoZSB1c2Ug
b2YgYXNzZXJ0aW9ucw0KPiAgICB3aXRoIE9BdXRoIDIuMCBpbiB0aGUgZm9ybSBvZiBhIG5ldyBj
bGllbnQgYXV0aGVudGljYXRpb24gbWVjaGFuaXNtDQo+ICAgIGFuZCBhIG5ldyBhdXRob3JpemF0
aW9uIGdyYW50IHR5cGUuICBNZWNoYW5pc21zIGFyZSBzcGVjaWZpZWQgZm9yDQo+ICAgIHRyYW5z
cG9ydGluZyBhc3NlcnRpb25zIGR1cmluZyBpbnRlcmFjdGlvbnMgd2l0aCBhIHRva2VuIGVuZHBv
aW50LCBhcw0KPiAgICB3ZWxsIGFzIGdlbmVyYWwgcHJvY2Vzc2luZyBydWxlcy4NCj4NCj4gICAg
VGhlIGludGVudCBvZiB0aGlzIHNwZWNpZmljYXRpb24gaXMgdG8gcHJvdmlkZSBhIGNvbW1vbiBm
cmFtZXdvcmsgZm9yDQo+ICAgIE9BdXRoIDIuMCB0byBpbnRlcndvcmsgd2l0aCBvdGhlciBpZGVu
dGl0eSBzeXN0ZW1zIHVzaW5nIGFzc2VydGlvbnMsDQo+ICAgIGFuZCB0byBwcm92aWRlIGFsdGVy
bmF0aXZlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zLg0KPg0KPiAgICBOb3RlIHRo
YXQgdGhpcyBzcGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lcyBhYnN0cmFjdCBtZXNzYWdlIGZsb3dz
IGFuZA0KPiAgICBwcm9jZXNzaW5nIHJ1bGVzLiAgSW4gb3JkZXIgdG8gYmUgaW1wbGVtZW50YWJs
ZSwgY29tcGFuaW9uDQo+ICAgIHNwZWNpZmljYXRpb25zIGFyZSBuZWNlc3NhcnkgdG8gcHJvdmlk
ZSB0aGUgY29ycmVzcG9uZGluZyBjb25jcmV0ZQ0KPiAgICBpbnN0YW50aWF0aW9ucy4NCj4NCj4N
Cj4NCj4NCj4gVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KPiBodHRwOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy8NCj4NCj4gSUVTRyBk
aXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy9iYWxsb3QvDQo+DQo+DQo+IE5vIElQ
UiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC4N
Cj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRm
Lm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxp
bmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo=

--_000_18F98790E67A44AD83C651118716C9DAsalesforcecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13
ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z
cGFjZTsgIj48ZGl2PlRoZSBsYW5ndWFnZSBpcyBzaW1wbHkgbWVhbnQgdG8gaGVscCBpbGx1c3Ry
YXRlIGhvdyB0aGUgZnJhbWV3b3JrIG1pZ2h0IGJlIHVzZWQuICZuYnNwOyBIb3cgZG8geW91IHRo
aW5rIGl0IHdpbGwgcmVzdHJpY3QgdXNhZ2U/ICZuYnNwOyBIb3cgY291bGQgaXQgYmUgaW1wcm92
ZWQ/PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tY21vcnQ8L2Rpdj48YnI+PGRpdj48ZGl2Pk9u
IERlYyAxMiwgMjAxMiwgYXQgMTE6MDQgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86emhvdS5zdWpp
bmdAenRlLmNvbS5jbiI+emhvdS5zdWppbmdAenRlLmNvbS5jbjwvYT4mZ3Q7IHdyb3RlOjwvZGl2
PjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+DQo8YnI+PGZvbnQgc2l6ZT0iMiI+SW4gInNlY3Rpb24gMzwvZm9udD4NCjxicj48Zm9u
dCBzaXplPSIyIj4mbmJzcDtUaGUgdG9rZW4gc2VydmljZSBpcyB0aGUgYXNzZXJ0aW9uIGlzc3Vl
cjsgaXRzPC9mb250Pg0KPGJyPjxmb250IHNpemU9IjIiPiZuYnNwO3JvbGUgaXMgdG8gZnVsZmls
bCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoDQpwcmVzZW50IHZhcmlvdXM8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0iMiI+Jm5ic3A7Y3JlZGVudGlhbHMsIGFuZCBtaW50IGFzc2VydGlvbnMg
YXMgcmVxdWVzdGVkLCBmaWxsDQp0aGVtIHdpdGg8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0iMiI+
Jm5ic3A7YXBwcm9wcmlhdGUgaW5mb3JtYXRpb24sIGFuZCBzaWduIHRoZW0uIjwvZm9udD4NCjxi
cj4NCjxicj4NCjxicj48Zm9udCBzaXplPSIyIj5BcyBJIHVuZGVyc3RhbmQsIGFuIGFzc2VydGlv
biBnZW5lcmF0ZWQgYnkgYSBTVFMsIGlzIGRvbmUNCmZsb2xsb3dpbmcgdGhlc3Mgc3RlcHM6PC9m
b250Pg0KPGJyPjxmb250IHNpemU9IjIiPjEuIENsaWVudCBwcmVzZW50cyBjcmVkZW50aWFsIGFu
ZCByZXF1ZXN0cyBhbiBhc3NlcnRpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0iMiI+Mi4gU1RT
IGdlbmVyYXRlcyBhc3NlcnRpb24gYW5kIHNlbmRzIHRvIENsaWVudDwvZm9udD4NCjxicj48Zm9u
dCBzaXplPSIyIj5Db3JyZWN0PzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPSIyIj5UaGF0
IG1heSByZXN0cmljdCB0aGUgdXNlIGNhc2VzIHRoYXQgdGhpcyBhc3NlcnRpb24gZnJhbWV3b3Jr
DQpjb3VsZCBzdXBwb3J0LDwvZm9udD4NCjxicj48Zm9udCBzaXplPSIyIj5pcyBpdCBhIG11c3Q/
PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPSIyIj48
YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZzwvYT4g5YaZ5LqOIDIwMTItMTItMTEgMDI6MzM6NTc6PGJyPg0KPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgV2ViIEF1dGhv
cml6YXRpb24gUHJvdG9jb2wNCldHPGJyPg0KJmd0OyAob2F1dGgpIHRvIGNvbnNpZGVyIHRoZSBm
b2xsb3dpbmcgZG9jdW1lbnQ6PGJyPg0KJmd0OyAtICdBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBP
QXV0aCAyLjAnPGJyPg0KJmd0OyAmbmJzcDsgJmx0O2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9u
cy0wOC50eHQmZ3Q7IGFzIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRo
ZSBJRVNHIHBsYW5zIHRvIG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFu
ZCBzb2xpY2l0czxicj4NCiZndDsgZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFz
ZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvDQp0aGU8YnI+DQomZ3Q7IDxhIGhyZWY9Im1h
aWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9hPiBtYWlsaW5nIGxpc3RzIGJ5IDIw
MTItMTItMjQuIEV4Y2VwdGlvbmFsbHksIGNvbW1lbnRzDQptYXkgYmU8YnI+DQomZ3Q7IHNlbnQg
dG8gPGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+IGluc3Rl
YWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZTxicj4NCiZndDsgYmVnaW5uaW5n
IG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IEFic3RyYWN0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5i
c3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIGZyYW1ld29yayBmb3IgdGhl
IHVzZSBvZg0KYXNzZXJ0aW9uczxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3dpdGggT0F1dGggMi4w
IGluIHRoZSBmb3JtIG9mIGEgbmV3IGNsaWVudCBhdXRoZW50aWNhdGlvbg0KbWVjaGFuaXNtPGJy
Pg0KJmd0OyAmbmJzcDsgJm5ic3A7YW5kIGEgbmV3IGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZS4g
Jm5ic3A7TWVjaGFuaXNtcw0KYXJlIHNwZWNpZmllZCBmb3I8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz
cDt0cmFuc3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zIHdpdGggYSB0b2tl
bg0KZW5kcG9pbnQsIGFzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7d2VsbCBhcyBnZW5lcmFsIHBy
b2Nlc3NpbmcgcnVsZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgaW50
ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRlIGEgY29tbW9uDQpmcmFtZXdv
cmsgZm9yPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7T0F1dGggMi4wIHRvIGludGVyd29yayB3aXRo
IG90aGVyIGlkZW50aXR5IHN5c3RlbXMgdXNpbmcNCmFzc2VydGlvbnMsPGJyPg0KJmd0OyAmbmJz
cDsgJm5ic3A7YW5kIHRvIHByb3ZpZGUgYWx0ZXJuYXRpdmUgY2xpZW50IGF1dGhlbnRpY2F0aW9u
IG1lY2hhbmlzbXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtOb3RlIHRoYXQg
dGhpcyBzcGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lcyBhYnN0cmFjdCBtZXNzYWdlDQpmbG93cyBh
bmQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtwcm9jZXNzaW5nIHJ1bGVzLiAmbmJzcDtJbiBvcmRl
ciB0byBiZSBpbXBsZW1lbnRhYmxlLA0KY29tcGFuaW9uPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7
c3BlY2lmaWNhdGlvbnMgYXJlIG5lY2Vzc2FyeSB0byBwcm92aWRlIHRoZSBjb3JyZXNwb25kaW5n
DQpjb25jcmV0ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2luc3RhbnRpYXRpb25zLjxicj4NCiZn
dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgZmlsZSBj
YW4gYmUgb2J0YWluZWQgdmlhPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy8iPmh0dHA6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLzwvYT48YnI+DQom
Z3Q7IDxicj4NCiZndDsgSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYTxicj4NCiZn
dDsgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9h
dXRoLWFzc2VydGlvbnMvYmFsbG90LyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMvYmFsbG90LzwvYT48YnI+DQomZ3Q7IDxicj4NCiZn
dDsgPGJyPg0KJmd0OyBObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGly
ZWN0bHkgb24gdGhpcyBJLUQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRo
IG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P
QXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vb2F1dGg8L2E+PGJyPg0KPC9mb250PjwvdHQ+DQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj5PQXV0aCBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJl
Zj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj48L2Jsb2NrcXVvdGU+PC9kaXY+
PGJyPjwvYm9keT48L2h0bWw+

--_000_18F98790E67A44AD83C651118716C9DAsalesforcecom_--

From bcampbell@pingidentity.com  Thu Dec 13 12:20:42 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B583D21F8A99 for ; Thu, 13 Dec 2012 12:20:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.182
X-Spam-Level: 
X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_26=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tD5OJ62m5mwv for ; Thu, 13 Dec 2012 12:20:40 -0800 (PST)
Received: from na3sys009aog136.obsmtp.com (na3sys009aog136.obsmtp.com [74.125.149.85]) by ietfa.amsl.com (Postfix) with ESMTP id EB4A321F8A10 for ; Thu, 13 Dec 2012 12:20:39 -0800 (PST)
Received: from mail-qa0-f70.google.com ([209.85.216.70]) (using TLSv1) by na3sys009aob136.postini.com ([74.125.148.12]) with SMTP ID DSNKUMo4lmbPjC5EMUN3kknqwrbolhsXfGSX@postini.com; Thu, 13 Dec 2012 12:20:40 PST
Received: by mail-qa0-f70.google.com with SMTP id hg5so5688772qab.1 for ; Thu, 13 Dec 2012 12:20:37 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=AqdEtiTJWVfbyfp9I40OyLWLo9Mi9SBSXiZZRdhRr48=; b=hE1Bjmr5ld1A2AgwcccEY7oZYwH6D2DYAOC7TfcrlAE+201WDy1lpjiNRnbjfELzQk yRKcYUjGxOtOZpVb7O61A4s6343TiDFAQJNMt7+Jv4biHdlLImfJFrhrzJBHNBxXBCFp mBqB244Ck6OS6qs1QK0X/6DcWNySIdGdyQ4R53yeBkYqaZyTdyWVP8Sm1rbaqDmXL9Vb V1+m5RiLEsRclTOhZyn1NWnQP5eWM9KUPIpkm1KzpEiu5cvM2askFAtcz5t+pi0Ce+KF ls0RsU6E2UNITlnWwZInHRMeoBkB8/qorCjJFlSdzECVE5yTlMzPosQ0I4uMdguQ5e71 t31g==
Received: by 10.52.19.20 with SMTP id a20mr5053084vde.26.1355430037664; Thu, 13 Dec 2012 12:20:37 -0800 (PST)
Received: by 10.52.19.20 with SMTP id a20mr5053063vde.26.1355430037408; Thu, 13 Dec 2012 12:20:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.163.170 with HTTP; Thu, 13 Dec 2012 12:20:07 -0800 (PST)
In-Reply-To: 
References:  
From: Brian Campbell 
Date: Thu, 13 Dec 2012 13:20:07 -0700
Message-ID: 
To: "zhou.sujing@zte.com.cn" 
Content-Type: multipart/alternative; boundary=bcaec5040838e5cc0104d0c1a5f9
X-Gm-Message-State: ALoCoQnzD82Y8K0n7LGtJwnrMa56cg37F174IF+sEHfbmr0riv7GiDLdMfvhFt0rk2/hT7iS13jr0qyezyKyCAVJ7i+0eD/8XXtp/Vp1Ae9ML/JKFoxIWU4sVHtH4vfZjN7FjdZsyxm6
Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be either the client or a third party token service?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 13 Dec 2012 20:20:42 -0000

--bcaec5040838e5cc0104d0c1a5f9
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Those are common steps for obtaining an assertion from an STS but the only
possibly way. The assertion framework document doesn't or shouldn't impose
any requirements or restrictions on how the client obtains an assertion.
Two common ways are discussed as examples but they are by no means indeed
to constrain clients from doing something else.




On Mon, Dec 10, 2012 at 6:41 PM,  wrote:

>
> In "section 3
>  The token service is the assertion issuer; its
>  role is to fulfill requests from clients, which present various
>  credentials, and mint assertions as requested, fill them with
>  appropriate information, and sign them."
>
>
> As I understand, an assertion generated by a STS, is done flollowing thes=
s
> steps:
> 1. Client presents credential and requests an assertion
> 2. STS generates assertion and sends to Client
> Correct?
>
> It is an interactive process, but there are cases that credential from
> client is not necessary,
> e.g. my RO issuer use case:
> 1. RO generate a delegation statement specifying client-name has the righ=
t
> to do something, signs it, sends to client.
>
> No client credential is needed, and even request from client is not neede=
d.
>
> Any comments?
>
>
> ZhouSuJing00132831/user/zte_ltd =D0=B4=D3=DA 2012-12-07 08:17:00:
>
>
> > Brian Campbell  =D0=B4=D3=DA 2012-12-07 07:=
03:38:
> >
> > > A question for the chairs or others more versed in the workings of
> > > the IETF - is this document even in a place where changes can be
> > > made? The Shepherd Write-Up for the document was recently sent to
> > > the IESG Secretary and I'm honestly not sure what the protocol is
> > > for making changes at this point.
> > Or we can start a new draft extending and clarifying the assertion
> document,
>
> > more use cases could be implemented by assertion may be included,
> > and other things...
> >
> > >
> > >
> > >
>
> > >
>
> > > On Thu, Dec 6, 2012 at 12:50 AM, Nat Sakimura 
> wrote:
> > > Here, I think it is better to differentiate the entity and
> function/role.
> > >
> > > Authorization Server in OAuth is "kind of" entity.
> > > Its function actually is split into two, or in most cases three.
> > >
> > > 1. Authentication Endpoint
> > > 2. Authorization Endpoint
> > > 3. Token Endpoint
> > >
> > > Now, "Assertion Verifier" is a function/role. It is performed by 3.
> > > Token Endpoint.
> > > It check the validity, and issues access tokens (which in turn can
> > > be another assertion by the way.)
> > >
> > > Authorization Endpoint is another function. It can be located
> > > anywhere. In your case, it is located in what you call as Resource
> > > Owner (Browser plug-in?) In my Self-Issued IdP case, it is issued by
> > > the App in the phone which is called by the custom schema.
> > >
> > > This is the reason why I constantly grumble that it is better to
> > > speak in terms of functions rather than entities.
> > > Functions may reside in any entity, and if we talk only in terms of
> > > the entities, the combination will explode.
> > >
> > > Nat
> > >
> > > On Thu, Dec 6, 2012 at 9:46 AM,  wrote:
> > >
> > > As I understand, RO=3Dissuer  does not mean RO=3DAS.
> > > RO as an issuer generates assertion (if the assertion is similar to
> > > delegation statement in my use cases),
> > > AS as an assertion verifier receives the assertion and check its
> validity.
> > >
> > >
> > >
> > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-06 01:35:10:
> > >
> > >
> > > > Just checking that I understand: If the RO =3D=3D the issuer, then =
the
> > > > RO =3D=3D the AS, right? Just as in Nat's example, the user (or at =
least
> > > > the device presenting a user agent to them) =3D=3D the IdP? Colocat=
ing
> > > > the RO and AS functions shouldn't be precluded, but I would be
> > > > awfully confused if there were an RO/issuer in the picture and
> > > > *also* an AS that *doesn't* issue assertions.
> > >
> > > >
> > > > Eve
> > > >
> > > > On 5 Dec 2012, at 9:13 AM, Nat Sakimura  wrote:
> > > >
> > > > It is not OAuth, but Austrian eID system is an example of RO as an
> > > > assertion issuer pattern. They have their own SAML IdP on their PC
> > > > (at least a few years ago) and combined with the qualified certs in
> > > > the user's smart card and another file, creates a SAML assertion
> > > > with sectoral identifier and supply it to other systems.
> > > >
> > > > Nat
> > >
> > > > On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell
> >  > > > > wrote:
> > > > I say that it's only theoretical because I don't believe there are
> > > > any actual deployments supporting, or planning on supporting, RO as
> > > > an assertion issuer.
> > > >
> > >
> > > > On Tue, Dec 4, 2012 at 5:39 PM,  wrote:
> > > >
> > > > Why RO as an issuer is only theoretical today?
> > > >
> > >
> > > >
> > > > Brian Campbell 
> > > > 2012-12-04 23:41
> > > >
> > > > =CA=D5=BC=FE=C8=CB
> > > >
> > > > Nat Sakimura 
> > > >
> > > > =B3=AD=CB=CD
> > > >
> > > > zhou.sujing@zte.com.cn, "oauth@ietf.org" 
> > > >
> > > > =D6=F7=CC=E2
> > > >
> > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to be
> > > > either the client or a third party token service?
>
> > > >
> > > >
> > > >
> > > >
> > > > The intent was definitely not to constrain who/what could be the
> > > > issuer.  But also try to provide
> > > > some guidance around the common cases that are actually being
> > > > deployed now, which are the client self-issued and STS variants.
> > > > Resource owner as an issuer is an interesting case but seems mostly
> > > > theoretical at this point.
> > > >
> > > > I feel like mentioning the resource owner there in =A1=EC5.1 would =
cause
> > > > more confusion than anything else. I'd prefer to just strike the
> > > > whole sentence in question and maybe add some additional text to =
=A1=EC3
> > > > that clarifies that the issuer can really be any entity, if folks
> > > > think a change is needed here?
> > > >
> > > >
> > > >
> > > > On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura 
> wrote:
> > > > Actually, "The issuer may be either
> > > >       an OAuth client (when assertions are self-issued) or any othe=
r
> > > > entity, e.g.,  a third party
> > > > token service, resource owner. "  is not really clean.
> > > >
> > > > OAuth client is just another example of an issuer.
> > > >
> > > > So, perhaps the sentence could be:
> > > >
> > > > "Example of issuers include an OAuth client, resource owner, an
> > > > independent third party."
> > > >
> > > > So, the clause becomes:
> > > >
> > > >  Issuer  The unique identifier for the entity that issued the
> > > >      assertion.  Generally this is the entity that holds the key
> > > >      material used to generate the assertion.
> > > >       Example of issuers include an OAuth client, resource owner, a=
n
> > > > independent third party.
> > > >
> > > > Nat
> > > >
> > > > Nat
> > > >
> > > > On Tue, Dec 4, 2012 at 11:40 AM,  wrote:
> > > >
> > > >
> > > >
> > > > Chuck Mortimore  =D0=B4=D3=DA 2012-12-04=
 10:26:50:
> > > >
> > > >
> > > > > Please feel free to suggest better language.
> > > >
> > > > >
> > > > > Issuer simply allows the token service to know who created the
> > > > > assertion, so it can look them up and see if they're trusted.
> > > > > Effectively the same as an Issuer in SAML.
> > > >
> > > > a conflict : "The token service is the assertion issuer" in
> > > > assertion document.
> > > > while you said "token service know who created the assertion"
> > > >
> > > > I wonder if the following text is acceptable:
> > > >
> > > >  Issuer  The unique identifier for the entity that issued the
> > > >      assertion.  Generally this is the entity that holds the key
> > > >      material used to generate the assertion.  The issuer may be
> either
> > > >       an OAuth client (when assertions are self-issued) or any othe=
r
> > > > entity, e.g.,  a third party
> > > > token service, resource owner.
> > > >
> > > >
> > > > 6.3.  Client Acting on Behalf of a User
> > > >
> > > > The Issuer of the assertion MUST identify the entity that issued
> > > >      the assertion as recognized by the Authorization Server.  If
> the
> > > >      assertion is self-issued, the Issuer SHOULD be the "client_id"=
.
> > > >      If the assertion was issued by a Security Token Service (STS),
> the
> > > >      Issuer SHOULD identify the STS as recognized by the
> Authorization
> > > >      Server.If the assertion was issued by the resource owner, the
> > > >      Issuer SHOULD identify the resource owner as recognized by the
> > > > Authorization
> > > >      Server.
> > > >
> > > > >
> > > > > -cmort
> > > > >
> > > > > On Dec 3, 2012, at 6:23 PM,  wrote:
> > > > >
> > > > >
> > > > > Obviously, it is not so clear from the language there.
> > > > >
> > > > >
> > > > > Chuck Mortimore  =D0=B4=D3=DA 2012-12-=
04
> 10:17:12:
> > > > >
> > > > > > There's no reason why it can't be resource owner today.
> > > > > >
> > > > > > On Dec 3, 2012, at 6:06 PM,   > > > sujing@zte.com.cn
> > > > > > > wrote:
> > > > > >
> > > > > >
> > > > > > +1.
> > > > > > And why it was not looked at that time?
> > > > > >
> > > > > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:
> > > > > >
> > > > > > > Actually, I think it is a good time to start looking at the
> resourse
> > > > > > > owner issuing assertions@ (Interestingly enough, Hui-Lan had
> brought
> > > > > > > this up a couple of years ago.)
> > > > > > >
> > > > > > > Igor
> > > > > > >
> > > > > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:
> > > > > > > I suppose, yes. I was reading it like that all the time.
> > > > > > > Whether it is or not, if it is still ok, it might be better t=
o
> > > > > clarify it.
> > > > > > > Word like "third party" tends to be a bit of problem without
> > > > > > clearlydefining.
> > > > > > > I had similar experience in other fora.
> > > > > > >
> > > > > > > Nat
> > > > > > >
> > > > > > > Sent from iPad
> > > > > > >
> > > > > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn" <
> zhou.sujing@zte.com.cn> =A4=CE
> > > > > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:
> > > > > >
> > > > > > >
> > > > > > > could be Resource owner?
> > > > > > >
> > > > > >
> > > > > > >
> > > > > > > "Tschofenig, Hannes (NSN - FI/Espoo)" <
> hannes.tschofenig@nsn.com>
> > > > > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org
> > > > > > > 2012-12-03 16:49
> > > > > > >
> > > > > > > =CA=D5=BC=FE=C8=CB
> > > > > > >
> > > > > > > "ext Nat Sakimura" , "Brian Campbell" <
> > > > > > > bcampbell@pingidentity.com>, "oauth" 
> > > > > > >
> > > > > > > =B3=AD=CB=CD
> > > > > > >
> > > > > > > =D6=F7=CC=E2
> > > > > > >
> > > > > > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have to
> be
> > > > > > > either the client or a third party token service?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hi Nat,
> > > > > > >
> > > > > > > The current text essentially says that the assertion can
> either be
> > > > > > > created by the client (in which case it is self-signed) orit
> can be
>
> > > > > > > created by some other entity (which is then called the third
> party
> > > > > > > token service). So, this third party could be the
> > > authorization server.
> > > > > > >
> > > > > > > Ciao
> > > > > > > Hannes
> > > > > > >
> > > > > > >
> > > > > > > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]
> > > > On Behalf Of
> > > > > > > ext Nat Sakimura
> > > > > > > Sent: Monday, December 03, 2012 10:35 AM
> > > > > > > To: Brian Campbell; oauth
> > > > > > > Subject: [OAUTH-WG] Assertion Framework - Why does issuer hav=
e
> to be
> > > > > > > either the client or a third party token service?
> > > > > > >
> > > > > > > Hi Brian,
> > > > > > >
> > > > > > >
> > > > > > > The assertion framework defines the Issuer as:
> > > > > > >
> > > > > > >    Issuer  The unique identifier for the entity that issued
> the
> > > > > > >       assertion.  Generally this is the entity that holds the
> key
>
> > > > > > >       material used to generate the assertion.  The issuer
> > > maybe either
> > > > > > >       an OAuth client (when assertions are self-issued) or a
> > > > third party
> > > > > > >       token service.
> > > > > > >
> > > > > > > I was wondering why it has to be either the client or a third
> party
> > > > > > > token service.
> > > > > > > Conceptually, it could be any token service (functionality)
> > > > > > residingin any of
> > > > > > >
> > > > > > > the stakeholders (Resource Owner, OAuth Client, Authorization
> > > > Server, or
> > > > > > > a third party).
> > > > > > >
> > > > > > >
> > > > > > > I would appreciate if you could clarify why is the case.
> > > > > > >
> > > > > > >
> > > > > > > Best,
> > > > > > >
> > > > > > > --
> > > > > > > Nat Sakimura (=3Dnat)
> > > > > > > Chairman, OpenID Foundation
> > > > > > > http://nat.sakimura.org/
> > > > > > > @_nat_en
> > > > > > >  _______________________________________________
> > > > > > > OAuth mailing list
> > > > > > > OAuth@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > OAuth mailing list
> > > > > > > OAuth@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > > > > _______________________________________________
> > > > > > > OAuth mailing list
> > > > > > > OAuth@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/oauth
> > > > > > _______________________________________________
> > > > > > OAuth mailing list
> > > > > > OAuth@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Nat Sakimura (=3Dnat)
> > > > Chairman, OpenID Foundation
> > > > http://nat.sakimura.org/
> > > > @_nat_en
> > > >
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > >
> > > >
> > > >
> > >
> > > >
> > > > --
> > > > Nat Sakimura (=3Dnat)
> > > > Chairman, OpenID Foundation
> > > > http://nat.sakimura.org/
> > > > @_nat_en
> > > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
> > > >
> > > >
> > > > Eve Maler
> http://www.xmlgrrl.com/blog
> > > > +1 425 345 6756
> http://www.twitter.com/xmlgrrl
> > >
> > > > _______________________________________________
> > > > OAuth mailing list
> > > > OAuth@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/oauth
>
> > >
>
> > >
> > > --
> > > Nat Sakimura (=3Dnat)
> > > Chairman, OpenID Foundation
> > > http://nat.sakimura.org/
> > > @_nat_en
> > >
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OAuth@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
>

--bcaec5040838e5cc0104d0c1a5f9
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Those are common steps for obtaining an assertion from an STS but the only =
possibly way. The assertion framework document doesn't or shouldn't=
 impose any requirements or restrictions on how the client obtains an asser=
tion. Two common ways are discussed as examples but they are by no means in=
deed to constrain clients from doing something else.






On Mo=
n, Dec 10, 2012 at 6:41 PM,  <zhou.sujing@zte.com.cn> w=
rote:





In "section 3

 The token service is the assertion
issuer; its

 role is to fulfill requests from
clients, which present various

 credentials, and mint assertions
as requested, fill them with

 appropriate information, and sign
them."





As I understand, an assertion generated
by a STS, is done flollowing thess steps:

1. Client presents credential and requests
an assertion

2. STS generates assertion and sends
to Client

Correct?



It is an interactive process, but there
are cases that credential from client is not necessary,

e.g. my RO issuer use case:

1. RO generate a delegation statement
specifying client-name has the right to do something, signs it, sends to
client.



No client credential is needed, and
even request from client is not needed.



Any comments?     

  



ZhouSuJing00132831/user/zte_ltd =D0=B4=D3=DA 2012-12-07
08:17:00:




> Brian Campbell <bcampbell@pingidentity.com> =D0=B4=D3=DA 2012-12-07
07:03:38:

> 

> > A question for the chairs or others more versed in the workings
of 

> > the IETF - is this document even in a place where changes can
be 

> > made? The Shepherd Write-Up for the document was recently sent
to 

> > the IESG Secretary and I'm honestly not sure what the protoco=
l
is 

> > for making changes at this point.

> Or we can start a new draft extending and clarifying the assertion
document,


> more use cases could be implement=
ed by assertion
may be included, 

> and other things...

> 

> > 

> > 

> > 



> > 



> > On Thu, Dec 6, 2012 at 12:50 AM, Nat Sakimura
<sakimura@gmail.=
com> wrote:

> > Here, I think it is better to differentiate
the entity and function/role. 

> > 

> > Authorization Server in OAuth is "kind of" entity.


> > Its function actually is split into two,
or in most cases three. 

> > 

> > 1. Authentication Endpoint

> > 2. Authorization Endpoint

> > 3. Token Endpoint

> > 

> > Now, "Assertion Verifier" is a function/role. It is
performed by 3. 

> > Token Endpoint. 

> > It check the validity, and issues access
tokens (which in turn can 

> > be another assertion by the way.)

> > 

> > Authorization Endpoint is another function. It can be located


> > anywhere. In your case, it is located in what you call as Resourc=
e


> > Owner (Browser plug-in?) In my Self-Issued IdP case, it is issued
by

> > the App in the phone which is called by the custom schema. 

> > 

> > This is the reason why I constantly grumble that it is better
to 

> > speak in terms of functions rather than entities. 

> > Functions may reside in any entity, and
if we talk only in terms of 

> > the entities, the combination will explode. 

> > 

> > Nat

> > 

> > On Thu, Dec 6, 2012 at 9:46 AM, <zhou.sujing@zte.com.cn>
wrote:

> > 

> > As I understand, RO=3Dissuer  does not mean RO=3DAS. 

> > RO as an issuer generates assertion (if the assertion is similar
to 

> > delegation statement in my use cases), 

> > AS as an assertion verifier receives the assertion and check
its validity. 

> > 

> > 

> > 

> > oauth=
-bounces@ietf.org =D0=B4=D3=DA 2012-12-06 01:35:10:

> > 

> > 

> > > Just checking that I understand: If the RO =3D=3D the issuer=
,
then the 

> > > RO =3D=3D the AS, right? Just as in Nat's example, the u=
ser
(or at least

> > > the device presenting a user agent to them) =3D=3D the IdP?
Colocating 

> > > the RO and AS functions shouldn't be precluded, but I wo=
uld
be 

> > > awfully confused if there were an RO/issuer in the picture
and 

> > > *also* an AS that *doesn't* issue assertions.

> > 

> > > 

> > > Eve 

> > > 

> > > On 5 Dec 2012, at 9:13 AM, Nat Sakimura <sakimura@gmail.com>
wrote: 

> > > 

> > > It is not OAuth, but Austrian eID system is an example of
RO as an 

> > > assertion issuer pattern. They have their own SAML IdP on
their PC 

> > > (at least a few years ago) and combined with the qualified
certs in 

> > > the user's smart card and another file, creates a SAML a=
ssertion


> > > with sectoral identifier and supply it to other systems.


> > > 

> > > Nat

> > 

> > > On Wed, Dec 5, 2012 at 11:05 PM, Brian Campbell 

> <bc=
ampbell@pingidentity.com

> > > > wrote: 

> > > I say that it's only theoretical because I don't bel=
ieve
there are 

> > > any actual deployments supporting, or planning on supporting=
,
RO as 

> > > an assertion issuer. 

> > > 

> > 

> > > On Tue, Dec 4, 2012 at 5:39 PM, <zhou.sujing@zte.com.cn>
wrote: 

> > > 

> > > Why RO as an issuer is only theoretical today? 

> > > 

> > 

> > > 

> > > Brian Campbell <bcampbell@pingidentity.com> 

> > > 2012-12-04 23:41 

> > > 

> > > =CA=D5=BC=FE=C8=CB 

> > > 

> > > Nat Sakimura <sakimura@gmail.com> 

> > > 

> > > =B3=AD=CB=CD 

> > > 

> > > =
zhou.sujing@zte.com.cn, "oauth@ietf.org" <oauth@ietf.org>


> > > 

> > > =D6=F7=CC=E2 

> > > 

> > > Re: [OAUTH-WG] Assertion Framework - Why does issuer have
to be 

> > > either the client or a third party token service? 


> > > 

> > > 

> > > 

> > > 

> > > The intent was definitely not to constrain who/what could
be the 

> > > issuer.  But also try to provide 

> > > some guidance around the common cases that are actually
being 

> > > deployed now, which are the client self-issued and STS varia=
nts.


> > > Resource owner as an issuer is an interesting case but seems
mostly 

> > > theoretical at this point.

> > > 

> > > I feel like mentioning the resource owner there in =A1=EC5.1
would cause 

> > > more confusion than anything else. I'd prefer to just st=
rike
the 

> > > whole sentence in question and maybe add some additional
text to =A1=EC3 

> > > that clarifies that the issuer can really be any entity,
if folks 

> > > think a change is needed here? 

> > > 

> > > 

> > > 

> > > On Mon, Dec 3, 2012 at 9:20 PM, Nat Sakimura <sakimura@gmail.com>
wrote: 

> > > Actually, "The issuer may be either 

> > >       an OAuth client (when assertions are
self-issued) or any other

> > > entity, e.g.,  a third party 

> > > token service, resource owner. "  is not really
clean. 

> > > 

> > > OAuth client is just another example of an issuer. 

> > > 

> > > So, perhaps the sentence could be: 

> > > 

> > > "Example of issuers include an OAuth client, resource
owner, an 

> > > independent third party." 

> > > 

> > > So, the clause becomes: 

> > > 

> > >  Issuer  The unique identifier for the entity
that issued the 

> > >      assertion.  Generally this is the
entity that holds the key 

> > >      material used to generate the assertion.
  

> > >       Example of issuers include an OAuth
client, resource owner, an

> > > independent third party. 

> > > 

> > > Nat 

> > > 

> > > Nat 

> > > 

> > > On Tue, Dec 4, 2012 at 11:40 AM, <zhou.sujing@zte.com.cn>
wrote: 

> > > 

> > > 

> > > 

> > > Chuck Mortimore <cmortimore@salesforce.com> =D0=B4=D3=DA
2012-12-04 10:26:50: 

> > > 

> > > 

> > > > Please feel free to suggest better language. 

> > > 

> > > > 

> > > > Issuer simply allows the token service to know who
created the 

> > > > assertion, so it can look them up and see if they'r=
e
trusted.     

> > > > Effectively the same as an Issuer in SAML. 

> > > 

> > > a conflict : "The token service is the assertion issuer=
"
in 

> > > assertion document. 

> > > while you said "token service know who created the
assertion" 

> > > 

> > > I wonder if the following text is acceptable: 

> > >   

> > >  Issuer  The unique identifier for the entity
that issued the 

> > >      assertion.  Generally this is the
entity that holds the key 

> > >      material used to generate the assertion.
 The issuer may be either 

> > >       an OAuth client (when assertions are
self-issued) or any other

> > > entity, e.g.,  a third party 

> > > token service, resource owner. 

> > > 

> > > 

> > > 6.3.  Client Acting on Behalf of a User 

> > > 

> > > The Issuer of the assertion MUST identify the entity that
issued 

> > >      the assertion as recognized by the Autho=
rization
Server.  If the 

> > >      assertion is self-issued, the Issuer
SHOULD be the "client_id". 

> > >      If the assertion was issued by a Securit=
y
Token Service (STS), the 

> > >      Issuer SHOULD identify the STS as recogn=
ized
by the Authorization 

> > >      Server.If the assertion was issued by
the resource owner, the 

> > >      Issuer SHOULD identify the resource
owner as recognized by the 

> > > Authorization 

> > >      Server. 

> > > 

> > > > 

> > > > -cmort 

> > > > 

> > > > On Dec 3, 2012, at 6:23 PM, <zhou.sujing@zte.com.cn>
wrote: 

> > > > 

> > > > 

> > > > Obviously, it is not so clear from the language there.


> > > > 

> > > > 

> > > > Chuck Mortimore <cmortimore@salesforce.com> =D0=B4=D3=DA
2012-12-04 10:17:12:

> > > > 

> > > > > There's no reason why it can't be resource=
 owner
today.   

> > > > > 

> > > > > On Dec 3, 2012, at 6:06 PM, <zhou.sujing@zte.com.cn>
<zhou.

> > > sujin=
g@zte.com.cn

> > > > > > wrote: 

> > > > > 

> > > > > 

> > > > > +1. 

> > > > > And why it was not looked at that time? 

> > > > > 

> > > > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-04 01:30:55:
> > > > > 

> > > > > > Actually, I think it is a good time to start
looking at the resourse

> > > > > > owner issuing assertions@ (Interestingly
enough, Hui-Lan had brought

> > > > > > this up a couple of years ago.)

> > > > > > 

> > > > > > Igor

> > > > > > 

> > > > > > On 12/3/2012 3:58 AM, Nat Sakimura wrote:


> > > > > > I suppose, yes. I was reading it like that
all the time. 

> > > > > > Whether it is or not, if it is still ok,
it might be better to 

> > > > clarify it. 

> > > > > > Word like "third party" tends to
be a bit of problem without 

> > > > > clearlydefining. 

> > > > > > I had similar experience in other fora. 

> > > > > > 

> > > > > > Nat 

> > > > > > 

> > > > > > Sent from iPad 

> > > > > > 

> > > > > > 2012/12/03 0:52=A1=A2"zhou.sujing@zte.com.cn"
<zhou.sujing=
@zte.com.cn> =A4=CE

> > > > > > =A5=E1=A5=C3=A5=BB=A9`=A5=B8:

> > > > > 

> > > > > > 

> > > > > > could be Resource owner? 

> > > > > > 

> > > > > 

> > > > > > 

> > > > > > "Tschofenig, Hannes (NSN - FI/Espoo)&quo=
t;
<hannes.t=
schofenig@nsn.com> 

> > > > > > =B7=A2=BC=FE=C8=CB:  oauth-bounces@ietf.org 

> > > > > > 2012-12-03 16:49 

> > > > > > 

> > > > > > =CA=D5=BC=FE=C8=CB 

> > > > > > 

> > > > > > "ext Nat Sakimura" <sakimura@gmail.com>,
"Brian Campbell" <

> > > > > > bcampbell@pingidentity.com>, "oauth"
<oauth@ietf.org&=
gt; 

> > > > > > 

> > > > > > =B3=AD=CB=CD 

> > > > > > 

> > > > > > =D6=F7=CC=E2 

> > > > > > 

> > > > > > Re: [OAUTH-WG] Assertion Framework - Why
does issuer have to be     

> > > > > > either the client or a third party token
service? 

> > > > > > 

> > > > > > 

> > > > > > 

> > > > > > 

> > > > > > Hi Nat, 

> > > > > >   

> > > > > > The current text essentially says that the
assertion can either be 

> > > > > > created by the client (in which case it is
self-signed) orit can be


> > > > > > created by some other entity (which is then
called the third party 

> > > > > > token service). So, this third party could
be the 

> > authorization server. 

> > > > > >   

> > > > > > Ciao

> > > > > > Hannes 

> > > > > >   

> > > > > >   

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


> > > On Behalf Of 

> > > > > > ext Nat Sakimura

> > > > > > Sent: Monday, December 03, 2012 10:35 AM

> > > > > > To: Brian Campbell; oauth

> > > > > > Subject: [OAUTH-WG] Assertion Framework -
Why does issuer have to be

> > > > > > either the client or a third party token
service? 

> > > > > >   

> > > > > > Hi Brian, 

> > > > > >   

> > > > > >   

> > > > > > The assertion framework defines the Issuer
as: 

> > > > > >   

> > > > > >    Issuer  The unique identifi=
er
for the entity that issued the 

> > > > > >       assertion.  General=
ly
this is the entity that holds the key 


> > > > > >    =
  
material used to generate the assertion.  The issuer 

> > maybe either 

> > > > > >   &=
nbsp;  
an OAuth client (when assertions are self-issued) or a 

> > > third party 

> > > > > >       token service. 

> > > > > >   

> > > > > > I was wondering why it has to be either the
client or a third party 

> > > > > > token service. 

> > > > > > Conceptually, it could be any token service
(functionality) 

> > > > > residingin any of 

> > > > > >   

> > > > > > the stakeholders (Resource Owner, OAuth Clien=
t,
Authorization 

> > > Server, or 

> > > > > > a third party). 

> > > > > >   

> > > > > >   

> > > > > > I would appreciate if you could clarify why
is the case. 

> > > > > >   

> > > > > >   

> > > > > > Best, 

> > > > > >   

> > > > > > -- 

> > > > > > Nat Sakimura (=3Dnat) 

> > > > > > Chairman, OpenID Foundation

> > > > > > http://nat.sakimura.org/

> > > > > > @_nat_en 

> > > > > >  _______________________________________=
________

> > > > > > OAuth mailing list

> > > > > > OAuth@ietf.org

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

> > > > > 

> > > > > > 

> > > > > > 

> > > > > > _____________________________________________=
__

> > > > > > OAuth mailing list

> > > > > > OAuth@ietf.org

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

> > > > > > _____________________________________________=
__

> > > > > > OAuth mailing list

> > > > > > OAuth@ietf.org

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

> > > > > _______________________________________________
> > > > > OAuth mailing list

> > > > > OAuth@ietf.org

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

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> > > 

> > > 

> > > 

> > > 

> > > -- 

> > > Nat Sakimura (=3Dnat) 

> > > Chairman, OpenID Foundation

> > > http:=
//nat.sakimura.org/

> > > @_nat_en 

> > > 

> > > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> > > 

> > 

> > > 

> > > 

> > 

> > > 

> > > -- 

> > > Nat Sakimura (=3Dnat) 

> > > Chairman, OpenID Foundation

> > > http:=
//nat.sakimura.org/

> > > @_nat_en 

> > > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

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

> > > 

> > > 

> > > Eve Maler              
                   http://www.xmlgrrl.com/=
blog

> > > +1 425 345 6756          =
  
            http://www.twitter.com/xmlgrrl

> > 

> > > _______________________________________________

> > > OAuth mailing list

> > > OAuth@ie=
tf.org

> > > https://www.ietf.org/mailman/listinfo/oauth
<=
/tt>

> > 



> > 

> > -- 

> > Nat Sakimura (=3Dnat)

> > Chairman, OpenID Foundation

> > http://nat=
.sakimura.org/

> > @_nat_en

> > 

> > 

> > _______________________________________________

> > OAuth mailing list

> > OAuth@ietf.or=
g

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






--bcaec5040838e5cc0104d0c1a5f9--

From zhou.sujing@zte.com.cn  Thu Dec 13 16:30:22 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B63C21F8BE4; Thu, 13 Dec 2012 16:30:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.364
X-Spam-Level: 
X-Spam-Status: No, score=-98.364 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45,  USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEm+bk7RoK6E; Thu, 13 Dec 2012 16:30:18 -0800 (PST)
Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7C29D21F8BDF; Thu, 13 Dec 2012 16:30:17 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id A50AB125EA; Fri, 14 Dec 2012 08:30:07 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id E7774174C771; Fri, 14 Dec 2012 08:19:15 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBE0U1Do020840; Fri, 14 Dec 2012 08:30:01 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <18F98790-E67A-44AD-83C6-51118716C9DA@salesforce.com>
To: Chuck Mortimore 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Fri, 14 Dec 2012 08:29:47 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-14 08:29:53, Serialize complete at 2012-12-14 08:29:53
Content-Type: multipart/alternative; boundary="=_alternative 0002DDBE48257AD4_="
X-MAIL: mse02.zte.com.cn qBE0U1Do020840
Cc: "oauth-bounces@ietf.org" , "ietf@ietf.org" , IETF-Announce , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 00:30:22 -0000

This is a multipart message in MIME format.
--=_alternative 0002DDBE48257AD4_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

RnJvbSB0aGUgbGFuZ3VhZ2UsIEkgZ290IGFuIGltcHJlc3Npb24gdGhhdCBhc3NlcnRpb24gaXMg
b25seSBnZW5lcmF0ZWQgYnkgDQp0b2tlbiBzZXJ2aWNlIGFmdGVyIGNsaWVudHMgcHJlc2VudGlu
ZyBzb21lIGNyZWRlbnRpYWxzLA0KdGhlcmUgYXJlIG1heSBiZSBzb21lIGNhc2VzIHRoYXQgImFz
c2VydGlvbiIgZG9uJ3QgbmVlZCBjbGllbnQncyANCmNyZWRlbnRpYWwuDQplLmcuLCBSZXNvdXJj
ZSBvd25lciBhcyBhIHRva2VuIHNlcnZpY2UgIGNvdWxkIGdlbmVyYXRlICJhc3NlcnRpb24iIHRv
IGEgDQpjbGllbnQgaGUgdHJ1c3RzLCBidSBzaWduaW5nIGEgc3RhdGVtZW50IHRoYXQgIlRoaXMg
ZGVsZWdhdGlvbiBpcyBnaXZlbiB0byANCmEgY2xpZW50IGNhbGxlZCBjbGluZXQtaWQgDQpmb3Ig
ZG9pbmcgc29tZXRoaW5nIGZvciBtZSIuDQoNCg0KDQoNCkNodWNrIE1vcnRpbW9yZSA8Y21vcnRp
bW9yZUBzYWxlc2ZvcmNlLmNvbT4g0LTT2iAyMDEyLTEyLTE0IDAwOjM5OjAzOg0KDQo+IFRoZSBs
YW5ndWFnZSBpcyBzaW1wbHkgbWVhbnQgdG8gaGVscCBpbGx1c3RyYXRlIGhvdyB0aGUgZnJhbWV3
b3JrIA0KPiBtaWdodCBiZSB1c2VkLiAgIEhvdyBkbyB5b3UgdGhpbmsgaXQgd2lsbCByZXN0cmlj
dCB1c2FnZT8gICBIb3cgDQo+IGNvdWxkIGl0IGJlIGltcHJvdmVkPw0KPiANCj4gLWNtb3J0DQo+
IA0KPiBPbiBEZWMgMTIsIDIwMTIsIGF0IDExOjA0IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5j
bj4gd3JvdGU6DQo+IA0KPiANCj4gSW4gInNlY3Rpb24gMyANCj4gIFRoZSB0b2tlbiBzZXJ2aWNl
IGlzIHRoZSBhc3NlcnRpb24gaXNzdWVyOyBpdHMgDQo+ICByb2xlIGlzIHRvIGZ1bGZpbGwgcmVx
dWVzdHMgZnJvbSBjbGllbnRzLCB3aGljaCBwcmVzZW50IHZhcmlvdXMgDQo+ICBjcmVkZW50aWFs
cywgYW5kIG1pbnQgYXNzZXJ0aW9ucyBhcyByZXF1ZXN0ZWQsIGZpbGwgdGhlbSB3aXRoIA0KPiAg
YXBwcm9wcmlhdGUgaW5mb3JtYXRpb24sIGFuZCBzaWduIHRoZW0uIiANCj4gDQo+IA0KPiBBcyBJ
IHVuZGVyc3RhbmQsIGFuIGFzc2VydGlvbiBnZW5lcmF0ZWQgYnkgYSBTVFMsIGlzIGRvbmUgZmxv
bGxvd2luZw0KPiB0aGVzcyBzdGVwczogDQo+IDEuIENsaWVudCBwcmVzZW50cyBjcmVkZW50aWFs
IGFuZCByZXF1ZXN0cyBhbiBhc3NlcnRpb24gDQo+IDIuIFNUUyBnZW5lcmF0ZXMgYXNzZXJ0aW9u
IGFuZCBzZW5kcyB0byBDbGllbnQgDQo+IENvcnJlY3Q/IA0KPiANCj4gVGhhdCBtYXkgcmVzdHJp
Y3QgdGhlIHVzZSBjYXNlcyB0aGF0IHRoaXMgYXNzZXJ0aW9uIGZyYW1ld29yayBjb3VsZCANCnN1
cHBvcnQsIA0KPiBpcyBpdCBhIG11c3Q/IA0KPiANCj4gDQo+IA0KPiANCj4gb2F1dGgtYm91bmNl
c0BpZXRmLm9yZyDQtNPaIDIwMTItMTItMTEgMDI6MzM6NTc6DQo+IA0KPiA+IA0KPiA+IFRoZSBJ
RVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgV2ViIEF1dGhvcml6YXRpb24gUHJv
dG9jb2wgV0cNCj4gPiAob2F1dGgpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6
DQo+ID4gLSAnQXNzZXJ0aW9uIEZyYW1ld29yayBmb3IgT0F1dGggMi4wJw0KPiA+ICAgPGRyYWZ0
LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wOC50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4g
DQo+ID4gVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3
ZWVrcywgYW5kIHNvbGljaXRzDQo+ID4gZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBs
ZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0KPiA+IGlldGZAaWV0Zi5vcmcg
bWFpbGluZyBsaXN0cyBieSAyMDEyLTEyLTI0LiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkg
DQpiZQ0KPiA+IHNlbnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwg
cGxlYXNlIHJldGFpbiB0aGUNCj4gPiBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBh
bGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCj4gPiANCj4gPiBBYnN0cmFjdA0KPiA+IA0KPiA+IA0K
PiA+ICAgIFRoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIGZyYW1ld29yayBmb3IgdGhlIHVz
ZSBvZiBhc3NlcnRpb25zDQo+ID4gICAgd2l0aCBPQXV0aCAyLjAgaW4gdGhlIGZvcm0gb2YgYSBu
ZXcgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbQ0KPiA+ICAgIGFuZCBhIG5ldyBhdXRo
b3JpemF0aW9uIGdyYW50IHR5cGUuICBNZWNoYW5pc21zIGFyZSBzcGVjaWZpZWQgZm9yDQo+ID4g
ICAgdHJhbnNwb3J0aW5nIGFzc2VydGlvbnMgZHVyaW5nIGludGVyYWN0aW9ucyB3aXRoIGEgdG9r
ZW4gZW5kcG9pbnQsIA0KYXMNCj4gPiAgICB3ZWxsIGFzIGdlbmVyYWwgcHJvY2Vzc2luZyBydWxl
cy4NCj4gPiANCj4gPiAgICBUaGUgaW50ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBw
cm92aWRlIGEgY29tbW9uIGZyYW1ld29yayANCmZvcg0KPiA+ICAgIE9BdXRoIDIuMCB0byBpbnRl
cndvcmsgd2l0aCBvdGhlciBpZGVudGl0eSBzeXN0ZW1zIHVzaW5nIA0KYXNzZXJ0aW9ucywNCj4g
PiAgICBhbmQgdG8gcHJvdmlkZSBhbHRlcm5hdGl2ZSBjbGllbnQgYXV0aGVudGljYXRpb24gbWVj
aGFuaXNtcy4NCj4gPiANCj4gPiAgICBOb3RlIHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIG9ubHkg
ZGVmaW5lcyBhYnN0cmFjdCBtZXNzYWdlIGZsb3dzIA0KYW5kDQo+ID4gICAgcHJvY2Vzc2luZyBy
dWxlcy4gIEluIG9yZGVyIHRvIGJlIGltcGxlbWVudGFibGUsIGNvbXBhbmlvbg0KPiA+ICAgIHNw
ZWNpZmljYXRpb25zIGFyZSBuZWNlc3NhcnkgdG8gcHJvdmlkZSB0aGUgY29ycmVzcG9uZGluZyBj
b25jcmV0ZQ0KPiA+ICAgIGluc3RhbnRpYXRpb25zLg0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0K
PiA+IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCj4gPiBodHRwOi8vZGF0YXRyYWNrZXIu
aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy8NCj4gPiANCj4gPiBJRVNH
IGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+ID4gaHR0cDovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMvYmFsbG90Lw0KPiA+IA0KPiA+
IA0KPiA+IE5vIElQUiBkZWNsYXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBv
biB0aGlzIEktRC4NCj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRoQGll
dGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0
aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aA0K
--=_alternative 0002DDBE48257AD4_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5Gcm9tIHRoZSBsYW5ndWFnZSwgSSBnb3QgYW4gaW1wcmVz
c2lvbiB0aGF0IGFzc2VydGlvbg0KaXMgb25seSBnZW5lcmF0ZWQgYnkgdG9rZW4gc2VydmljZSBh
ZnRlciBjbGllbnRzIHByZXNlbnRpbmcgc29tZSBjcmVkZW50aWFscyw8L2ZvbnQ+PC90dD4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPnRoZXJlIGFyZSBtYXkgYmUgc29tZSBjYXNlcyB0aGF0ICZxdW90
O2Fzc2VydGlvbiZxdW90Ow0KZG9uJ3QgbmVlZCBjbGllbnQncyBjcmVkZW50aWFsLjwvZm9udD48
L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ZS5nLiwgUmVzb3VyY2Ugb3duZXIgYXMgYSB0b2tl
biBzZXJ2aWNlICZuYnNwO2NvdWxkDQpnZW5lcmF0ZSAmcXVvdDthc3NlcnRpb24mcXVvdDsgdG8g
YSBjbGllbnQgaGUgdHJ1c3RzLCBidSBzaWduaW5nIGEgc3RhdGVtZW50DQp0aGF0ICZxdW90O1Ro
aXMgZGVsZWdhdGlvbiBpcyBnaXZlbiB0byBhIGNsaWVudCBjYWxsZWQgY2xpbmV0LWlkIDwvZm9u
dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Zm9yIGRvaW5nIHNvbWV0aGluZyBmb3IgbWUm
cXVvdDsuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj5DaHVjayBNb3J0aW1vcmUgJmx0O2Ntb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20mZ3Q7
DQrQtNPaIDIwMTItMTItMTQgMDA6Mzk6MDM6PGJyPg0KPGJyPg0KJmd0OyBUaGUgbGFuZ3VhZ2Ug
aXMgc2ltcGx5IG1lYW50IHRvIGhlbHAgaWxsdXN0cmF0ZSBob3cgdGhlIGZyYW1ld29yaw0KPGJy
Pg0KJmd0OyBtaWdodCBiZSB1c2VkLiAmbmJzcDsgSG93IGRvIHlvdSB0aGluayBpdCB3aWxsIHJl
c3RyaWN0IHVzYWdlPyAmbmJzcDsNCkhvdyA8YnI+DQomZ3Q7IGNvdWxkIGl0IGJlIGltcHJvdmVk
PzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC1jbW9y
dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IE9uIERl
YyAxMiwgMjAxMiwgYXQgMTE6MDQgUE0sICZsdDt6aG91LnN1amluZ0B6dGUuY29tLmNuJmd0OyB3
cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IEluICZxdW90O3NlY3Rpb24gMyA8YnI+DQomZ3Q7ICZuYnNwO1RoZSB0b2tlbiBz
ZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVyOyBpdHMgPGJyPg0KJmd0OyAmbmJzcDtyb2xl
IGlzIHRvIGZ1bGZpbGwgcmVxdWVzdHMgZnJvbSBjbGllbnRzLCB3aGljaCBwcmVzZW50IHZhcmlv
dXMNCjxicj4NCiZndDsgJm5ic3A7Y3JlZGVudGlhbHMsIGFuZCBtaW50IGFzc2VydGlvbnMgYXMg
cmVxdWVzdGVkLCBmaWxsIHRoZW0gd2l0aA0KPGJyPg0KJmd0OyAmbmJzcDthcHByb3ByaWF0ZSBp
bmZvcm1hdGlvbiwgYW5kIHNpZ24gdGhlbS4mcXVvdDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgQXMgSSB1bmRlcnN0YW5kLCBhbiBhc3NlcnRpb24gZ2VuZXJhdGVkIGJ5IGEgU1RT
LCBpcyBkb25lIGZsb2xsb3dpbmc8YnI+DQomZ3Q7IHRoZXNzIHN0ZXBzOiA8YnI+DQomZ3Q7IDEu
IENsaWVudCBwcmVzZW50cyBjcmVkZW50aWFsIGFuZCByZXF1ZXN0cyBhbiBhc3NlcnRpb24gPGJy
Pg0KJmd0OyAyLiBTVFMgZ2VuZXJhdGVzIGFzc2VydGlvbiBhbmQgc2VuZHMgdG8gQ2xpZW50IDxi
cj4NCiZndDsgQ29ycmVjdD8gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYXQgbWF5IHJlc3RyaWN0
IHRoZSB1c2UgY2FzZXMgdGhhdCB0aGlzIGFzc2VydGlvbiBmcmFtZXdvcmsgY291bGQNCnN1cHBv
cnQsIDxicj4NCiZndDsgaXMgaXQgYSBtdXN0PyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIw
MTItMTItMTEgMDI6MzM6NTc6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3QgZnJvbSB0aGUgV2ViIEF1dGhvcml6
YXRpb24gUHJvdG9jb2wNCldHPGJyPg0KJmd0OyAmZ3Q7IChvYXV0aCkgdG8gY29uc2lkZXIgdGhl
IGZvbGxvd2luZyBkb2N1bWVudDo8YnI+DQomZ3Q7ICZndDsgLSAnQXNzZXJ0aW9uIEZyYW1ld29y
ayBmb3IgT0F1dGggMi4wJzxicj4NCiZndDsgJmd0OyAmbmJzcDsgJmx0O2RyYWZ0LWlldGYtb2F1
dGgtYXNzZXJ0aW9ucy0wOC50eHQmZ3Q7IGFzIFByb3Bvc2VkDQpTdGFuZGFyZDxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGlu
IHRoZSBuZXh0IGZldyB3ZWVrcywgYW5kDQpzb2xpY2l0czxicj4NCiZndDsgJmd0OyBmaW5hbCBj
b21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMN
CnRvIHRoZTxicj4NCiZndDsgJmd0OyBpZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAx
Mi0xMi0yNC4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMNCm1heSBiZTxicj4NCiZndDsgJmd0OyBz
ZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRh
aW4NCnRoZTxicj4NCiZndDsgJmd0OyBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBh
bGxvdyBhdXRvbWF0ZWQgc29ydGluZy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFi
c3RyYWN0PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5i
c3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIGZyYW1ld29yayBmb3IgdGhl
DQp1c2Ugb2YgYXNzZXJ0aW9uczxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7d2l0aCBPQXV0
aCAyLjAgaW4gdGhlIGZvcm0gb2YgYSBuZXcgY2xpZW50IGF1dGhlbnRpY2F0aW9uDQptZWNoYW5p
c208YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2FuZCBhIG5ldyBhdXRob3JpemF0aW9uIGdy
YW50IHR5cGUuICZuYnNwO01lY2hhbmlzbXMNCmFyZSBzcGVjaWZpZWQgZm9yPGJyPg0KJmd0OyAm
Z3Q7ICZuYnNwOyAmbmJzcDt0cmFuc3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rp
b25zIHdpdGgNCmEgdG9rZW4gZW5kcG9pbnQsIGFzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDt3ZWxsIGFzIGdlbmVyYWwgcHJvY2Vzc2luZyBydWxlcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgaW50ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBp
cyB0byBwcm92aWRlIGENCmNvbW1vbiBmcmFtZXdvcmsgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw
OyAmbmJzcDtPQXV0aCAyLjAgdG8gaW50ZXJ3b3JrIHdpdGggb3RoZXIgaWRlbnRpdHkgc3lzdGVt
cw0KdXNpbmcgYXNzZXJ0aW9ucyw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2FuZCB0byBw
cm92aWRlIGFsdGVybmF0aXZlIGNsaWVudCBhdXRoZW50aWNhdGlvbg0KbWVjaGFuaXNtcy48YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtOb3RlIHRoYXQgdGhpcyBz
cGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lcyBhYnN0cmFjdA0KbWVzc2FnZSBmbG93cyBhbmQ8YnI+
DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3Byb2Nlc3NpbmcgcnVsZXMuICZuYnNwO0luIG9yZGVy
IHRvIGJlIGltcGxlbWVudGFibGUsDQpjb21wYW5pb248YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu
YnNwO3NwZWNpZmljYXRpb25zIGFyZSBuZWNlc3NhcnkgdG8gcHJvdmlkZSB0aGUgY29ycmVzcG9u
ZGluZw0KY29uY3JldGU8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2luc3RhbnRpYXRpb25z
Ljxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYTxicj4N
CiZndDsgJmd0OyBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1
dGgtYXNzZXJ0aW9ucy88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IElFU0cgZGlzY3Vz
c2lvbiBjYW4gYmUgdHJhY2tlZCB2aWE8YnI+DQomZ3Q7ICZndDsgaHR0cDovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMvYmFsbG90Lzxicj4NCiZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE5vIElQUiBkZWNsYXJhdGlv
bnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC48YnI+DQomZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxp
c3Q8YnI+DQomZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZndDsgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxp
bmcgbGlzdDxicj4NCiZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2ZvbnQ+PC90dD4NCg==
--=_alternative 0002DDBE48257AD4_=--

From cmortimore@salesforce.com  Thu Dec 13 18:10:12 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A15D21F8C12; Thu, 13 Dec 2012 18:10:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.352
X-Spam-Level: 
X-Spam-Status: No, score=-6.352 tagged_above=-999 required=5 tests=[AWL=-0.176, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4tTAfpdFUjV; Thu, 13 Dec 2012 18:10:11 -0800 (PST)
Received: from exprod8og107.obsmtp.com (exprod8og107.obsmtp.com [64.18.3.94]) by ietfa.amsl.com (Postfix) with SMTP id 0368021F8C11; Thu, 13 Dec 2012 18:10:10 -0800 (PST)
Received: from exsfm-hub5.internal.salesforce.com ([204.14.239.233]) by exprod8ob107.postini.com ([64.18.7.12]) with SMTP ID DSNKUMqKgpnLHvEpxKmtF45GKwMcgcA+zNiB@postini.com; Thu, 13 Dec 2012 18:10:11 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub5.internal.salesforce.com ([10.1.127.5]) with mapi; Thu, 13 Dec 2012 18:10:10 -0800
From: Chuck Mortimore 
To: "zhou.sujing@zte.com.cn" 
Date: Thu, 13 Dec 2012 18:08:34 -0800
Thread-Topic: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
Thread-Index: Ac3ZoCS/nRHUZjSLTxyTa6Lheht76w==
Message-ID: <7CCC0903-4D4C-4F49-A7CA-ECA148935B47@salesforce.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7CCC09034D4C4F49A7CAECA148935B47salesforcecom_"
MIME-Version: 1.0
Cc: "oauth-bounces@ietf.org" , "ietf@ietf.org" , IETF-Announce , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 02:10:12 -0000

--_000_7CCC09034D4C4F49A7CAECA148935B47salesforcecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpPbiBEZWMgMTMsIDIwMTIsIGF0IDQ6MzAgUE0sICJ6aG91LnN1amluZ0B6dGUuY29tLmNuPG1h
aWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPiIgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFp
bHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24+PiB3cm90ZToNCg0KDQpGcm9tIHRoZSBsYW5ndWFn
ZSwgSSBnb3QgYW4gaW1wcmVzc2lvbiB0aGF0IGFzc2VydGlvbiBpcyBvbmx5IGdlbmVyYXRlZCBi
eSB0b2tlbiBzZXJ2aWNlIGFmdGVyIGNsaWVudHMgcHJlc2VudGluZyBzb21lIGNyZWRlbnRpYWxz
LA0KdGhlcmUgYXJlIG1heSBiZSBzb21lIGNhc2VzIHRoYXQgImFzc2VydGlvbiIgZG9uJ3QgbmVl
ZCBjbGllbnQncyBjcmVkZW50aWFsLg0KZS5nLiwgUmVzb3VyY2Ugb3duZXIgYXMgYSB0b2tlbiBz
ZXJ2aWNlICBjb3VsZCBnZW5lcmF0ZSAiYXNzZXJ0aW9uIiB0byBhIGNsaWVudCBoZSB0cnVzdHMs
IGJ1IHNpZ25pbmcgYSBzdGF0ZW1lbnQgdGhhdCAiVGhpcyBkZWxlZ2F0aW9uIGlzIGdpdmVuIHRv
IGEgY2xpZW50IGNhbGxlZCBjbGluZXQtaWQNCmZvciBkb2luZyBzb21ldGhpbmcgZm9yIG1lIi4N
Cg0KU28gaG93IGRvZXMgdGhlIFNUUyB0cnVzdCB0aGUgY2xpZW50PyAgIFByZXN1bWFibHkgaWYg
aXQgaXMgdHJ1c3RlZCBpdCBoYXMgc29tZSBsZXZlbCBvZiBhdXRoZW50aWNhdGlvbiwgeWVzPw0K
DQotY21vcnQNCg0KDQoNCg0KDQpDaHVjayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVAc2FsZXNmb3Jj
ZS5jb208bWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20+PiDlhpnkuo4gMjAxMi0xMi0x
NCAwMDozOTowMzoNCg0KPiBUaGUgbGFuZ3VhZ2UgaXMgc2ltcGx5IG1lYW50IHRvIGhlbHAgaWxs
dXN0cmF0ZSBob3cgdGhlIGZyYW1ld29yaw0KPiBtaWdodCBiZSB1c2VkLiAgIEhvdyBkbyB5b3Ug
dGhpbmsgaXQgd2lsbCByZXN0cmljdCB1c2FnZT8gICBIb3cNCj4gY291bGQgaXQgYmUgaW1wcm92
ZWQ/DQo+DQo+IC1jbW9ydA0KPg0KPiBPbiBEZWMgMTIsIDIwMTIsIGF0IDExOjA0IFBNLCA8emhv
dS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbj4+IHdyb3Rl
Og0KPg0KPg0KPiBJbiAic2VjdGlvbiAzDQo+ICBUaGUgdG9rZW4gc2VydmljZSBpcyB0aGUgYXNz
ZXJ0aW9uIGlzc3VlcjsgaXRzDQo+ICByb2xlIGlzIHRvIGZ1bGZpbGwgcmVxdWVzdHMgZnJvbSBj
bGllbnRzLCB3aGljaCBwcmVzZW50IHZhcmlvdXMNCj4gIGNyZWRlbnRpYWxzLCBhbmQgbWludCBh
c3NlcnRpb25zIGFzIHJlcXVlc3RlZCwgZmlsbCB0aGVtIHdpdGgNCj4gIGFwcHJvcHJpYXRlIGlu
Zm9ybWF0aW9uLCBhbmQgc2lnbiB0aGVtLiINCj4NCj4NCj4gQXMgSSB1bmRlcnN0YW5kLCBhbiBh
c3NlcnRpb24gZ2VuZXJhdGVkIGJ5IGEgU1RTLCBpcyBkb25lIGZsb2xsb3dpbmcNCj4gdGhlc3Mg
c3RlcHM6DQo+IDEuIENsaWVudCBwcmVzZW50cyBjcmVkZW50aWFsIGFuZCByZXF1ZXN0cyBhbiBh
c3NlcnRpb24NCj4gMi4gU1RTIGdlbmVyYXRlcyBhc3NlcnRpb24gYW5kIHNlbmRzIHRvIENsaWVu
dA0KPiBDb3JyZWN0Pw0KPg0KPiBUaGF0IG1heSByZXN0cmljdCB0aGUgdXNlIGNhc2VzIHRoYXQg
dGhpcyBhc3NlcnRpb24gZnJhbWV3b3JrIGNvdWxkIHN1cHBvcnQsDQo+IGlzIGl0IGEgbXVzdD8N
Cj4NCj4NCj4NCj4NCj4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZz4g5YaZ5LqOIDIwMTItMTItMTEgMDI6MzM6NTc6DQo+DQo+ID4NCj4gPiBUaGUg
SUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIFdlYiBBdXRob3JpemF0aW9uIFBy
b3RvY29sIFdHDQo+ID4gKG9hdXRoKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50
Og0KPiA+IC0gJ0Fzc2VydGlvbiBGcmFtZXdvcmsgZm9yIE9BdXRoIDIuMCcNCj4gPiAgIDxkcmFm
dC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDgudHh0PiBhcyBQcm9wb3NlZCBTdGFuZGFyZA0KPiA+
DQo+ID4gVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3
ZWVrcywgYW5kIHNvbGljaXRzDQo+ID4gZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBs
ZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRvIHRoZQ0KPiA+IGlldGZAaWV0Zi5vcmc8
bWFpbHRvOmlldGZAaWV0Zi5vcmc+IG1haWxpbmcgbGlzdHMgYnkgMjAxMi0xMi0yNC4gRXhjZXB0
aW9uYWxseSwgY29tbWVudHMgbWF5IGJlDQo+ID4gc2VudCB0byBpZXNnQGlldGYub3JnPG1haWx0
bzppZXNnQGlldGYub3JnPiBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0
aGUNCj4gPiBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQg
c29ydGluZy4NCj4gPg0KPiA+IEFic3RyYWN0DQo+ID4NCj4gPg0KPiA+ICAgIFRoaXMgc3BlY2lm
aWNhdGlvbiBwcm92aWRlcyBhIGZyYW1ld29yayBmb3IgdGhlIHVzZSBvZiBhc3NlcnRpb25zDQo+
ID4gICAgd2l0aCBPQXV0aCAyLjAgaW4gdGhlIGZvcm0gb2YgYSBuZXcgY2xpZW50IGF1dGhlbnRp
Y2F0aW9uIG1lY2hhbmlzbQ0KPiA+ICAgIGFuZCBhIG5ldyBhdXRob3JpemF0aW9uIGdyYW50IHR5
cGUuICBNZWNoYW5pc21zIGFyZSBzcGVjaWZpZWQgZm9yDQo+ID4gICAgdHJhbnNwb3J0aW5nIGFz
c2VydGlvbnMgZHVyaW5nIGludGVyYWN0aW9ucyB3aXRoIGEgdG9rZW4gZW5kcG9pbnQsIGFzDQo+
ID4gICAgd2VsbCBhcyBnZW5lcmFsIHByb2Nlc3NpbmcgcnVsZXMuDQo+ID4NCj4gPiAgICBUaGUg
aW50ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRlIGEgY29tbW9uIGZyYW1l
d29yayBmb3INCj4gPiAgICBPQXV0aCAyLjAgdG8gaW50ZXJ3b3JrIHdpdGggb3RoZXIgaWRlbnRp
dHkgc3lzdGVtcyB1c2luZyBhc3NlcnRpb25zLA0KPiA+ICAgIGFuZCB0byBwcm92aWRlIGFsdGVy
bmF0aXZlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21zLg0KPiA+DQo+ID4gICAgTm90
ZSB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5IGRlZmluZXMgYWJzdHJhY3QgbWVzc2FnZSBm
bG93cyBhbmQNCj4gPiAgICBwcm9jZXNzaW5nIHJ1bGVzLiAgSW4gb3JkZXIgdG8gYmUgaW1wbGVt
ZW50YWJsZSwgY29tcGFuaW9uDQo+ID4gICAgc3BlY2lmaWNhdGlvbnMgYXJlIG5lY2Vzc2FyeSB0
byBwcm92aWRlIHRoZSBjb3JyZXNwb25kaW5nIGNvbmNyZXRlDQo+ID4gICAgaW5zdGFudGlhdGlv
bnMuDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlh
DQo+ID4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFz
c2VydGlvbnMvDQo+ID4NCj4gPiBJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhDQo+
ID4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFzc2Vy
dGlvbnMvYmFsbG90Lw0KPiA+DQo+ID4NCj4gPiBObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVl
biBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+ID4NCj4gPg0KPiA+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KPiA+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0
DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_7CCC09034D4C4F49A7CAECA148935B47salesforcecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+PGJyPjwvZGl2
PjxkaXY+T24gRGVjIDEzLCAyMDEyLCBhdCA0OjMwIFBNLCAiPGEgaHJlZj0ibWFpbHRvOnpob3Uu
c3VqaW5nQHp0ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L2E+IiAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248
L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+PGRpdj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+RnJvbSB0aGUgbGFuZ3VhZ2UsIEkg
Z290IGFuIGltcHJlc3Npb24gdGhhdCBhc3NlcnRpb24NCmlzIG9ubHkgZ2VuZXJhdGVkIGJ5IHRv
a2VuIHNlcnZpY2UgYWZ0ZXIgY2xpZW50cyBwcmVzZW50aW5nIHNvbWUgY3JlZGVudGlhbHMsPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9IjIiPnRoZXJlIGFyZSBtYXkgYmUgc29tZSBj
YXNlcyB0aGF0ICJhc3NlcnRpb24iDQpkb24ndCBuZWVkIGNsaWVudCdzIGNyZWRlbnRpYWwuPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9IjIiPmUuZy4sIFJlc291cmNlIG93bmVyIGFz
IGEgdG9rZW4gc2VydmljZSAmbmJzcDtjb3VsZA0KZ2VuZXJhdGUgImFzc2VydGlvbiIgdG8gYSBj
bGllbnQgaGUgdHJ1c3RzLCBidSBzaWduaW5nIGEgc3RhdGVtZW50DQp0aGF0ICJUaGlzIGRlbGVn
YXRpb24gaXMgZ2l2ZW4gdG8gYSBjbGllbnQgY2FsbGVkIGNsaW5ldC1pZCA8L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+Zm9yIGRvaW5nIHNvbWV0aGluZyBmb3IgbWUiLjwvZm9u
dD48L3R0Pg0KPGJyPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48ZGl2PlNvIGhv
dyBkb2VzIHRoZSBTVFMgdHJ1c3QgdGhlIGNsaWVudD8gJm5ic3A7IFByZXN1bWFibHkgaWYgaXQg
aXMgdHJ1c3RlZCBpdCBoYXMgc29tZSBsZXZlbCBvZiBhdXRoZW50aWNhdGlvbiwgeWVzPzwvZGl2
PjxkaXY+PGJyPjwvZGl2PjxkaXY+LWNtb3J0PC9kaXY+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNp
dGUiPjxkaXY+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9IjIiPkNodWNr
IE1vcnRpbW9yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20i
PmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208L2E+Jmd0Ow0K5YaZ5LqOIDIwMTItMTItMTQgMDA6
Mzk6MDM6PGJyPg0KPGJyPg0KJmd0OyBUaGUgbGFuZ3VhZ2UgaXMgc2ltcGx5IG1lYW50IHRvIGhl
bHAgaWxsdXN0cmF0ZSBob3cgdGhlIGZyYW1ld29yaw0KPGJyPg0KJmd0OyBtaWdodCBiZSB1c2Vk
LiAmbmJzcDsgSG93IGRvIHlvdSB0aGluayBpdCB3aWxsIHJlc3RyaWN0IHVzYWdlPyAmbmJzcDsN
CkhvdyA8YnI+DQomZ3Q7IGNvdWxkIGl0IGJlIGltcHJvdmVkPzwvZm9udD48L3R0Pg0KPGJyPjx0
dD48Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsgLWNtb3J0PC9mb250PjwvdHQ+DQo8YnI+
PHR0Pjxmb250IHNpemU9IjIiPiZndDsgPGJyPg0KJmd0OyBPbiBEZWMgMTIsIDIwMTIsIGF0IDEx
OjA0IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24iPnpob3Uu
c3VqaW5nQHp0ZS5jb20uY248L2E+Jmd0OyB3cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0iMiI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSW4gInNlY3Rpb24gMyA8YnI+
DQomZ3Q7ICZuYnNwO1RoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVyOyBp
dHMgPGJyPg0KJmd0OyAmbmJzcDtyb2xlIGlzIHRvIGZ1bGZpbGwgcmVxdWVzdHMgZnJvbSBjbGll
bnRzLCB3aGljaCBwcmVzZW50IHZhcmlvdXMNCjxicj4NCiZndDsgJm5ic3A7Y3JlZGVudGlhbHMs
IGFuZCBtaW50IGFzc2VydGlvbnMgYXMgcmVxdWVzdGVkLCBmaWxsIHRoZW0gd2l0aA0KPGJyPg0K
Jmd0OyAmbmJzcDthcHByb3ByaWF0ZSBpbmZvcm1hdGlvbiwgYW5kIHNpZ24gdGhlbS4iIDxicj4N
CiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFzIEkgdW5kZXJzdGFuZCwgYW4gYXNzZXJ0aW9u
IGdlbmVyYXRlZCBieSBhIFNUUywgaXMgZG9uZSBmbG9sbG93aW5nPGJyPg0KJmd0OyB0aGVzcyBz
dGVwczogPGJyPg0KJmd0OyAxLiBDbGllbnQgcHJlc2VudHMgY3JlZGVudGlhbCBhbmQgcmVxdWVz
dHMgYW4gYXNzZXJ0aW9uIDxicj4NCiZndDsgMi4gU1RTIGdlbmVyYXRlcyBhc3NlcnRpb24gYW5k
IHNlbmRzIHRvIENsaWVudCA8YnI+DQomZ3Q7IENvcnJlY3Q/IDxicj4NCiZndDsgPGJyPg0KJmd0
OyBUaGF0IG1heSByZXN0cmljdCB0aGUgdXNlIGNhc2VzIHRoYXQgdGhpcyBhc3NlcnRpb24gZnJh
bWV3b3JrIGNvdWxkDQpzdXBwb3J0LCA8YnI+DQomZ3Q7IGlzIGl0IGEgbXVzdD8gPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxhIGhyZWY9Im1h
aWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiDl
hpnkuo4gMjAxMi0xMi0xMSAwMjozMzo1Nzo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBXZWIg
QXV0aG9yaXphdGlvbiBQcm90b2NvbA0KV0c8YnI+DQomZ3Q7ICZndDsgKG9hdXRoKSB0byBjb25z
aWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Ojxicj4NCiZndDsgJmd0OyAtICdBc3NlcnRpb24g
RnJhbWV3b3JrIGZvciBPQXV0aCAyLjAnPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbHQ7ZHJhZnQt
aWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA4LnR4dCZndDsgYXMgUHJvcG9zZWQNClN0YW5kYXJkPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVj
aXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQNCnNvbGljaXRzPGJyPg0KJmd0OyAmZ3Q7
IGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBj
b21tZW50cw0KdG8gdGhlPGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYu
b3JnIj5pZXRmQGlldGYub3JnPC9hPiBtYWlsaW5nIGxpc3RzIGJ5IDIwMTItMTItMjQuIEV4Y2Vw
dGlvbmFsbHksIGNvbW1lbnRzDQptYXkgYmU8YnI+DQomZ3Q7ICZndDsgc2VudCB0byA8YSBocmVm
PSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4gaW5zdGVhZC4gSW4gZWl0
aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4NCnRoZTxicj4NCiZndDsgJmd0OyBiZWdpbm5pbmcgb2Yg
dGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy48YnI+DQomZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IEFic3RyYWN0PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRl
cyBhIGZyYW1ld29yayBmb3IgdGhlDQp1c2Ugb2YgYXNzZXJ0aW9uczxicj4NCiZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7d2l0aCBPQXV0aCAyLjAgaW4gdGhlIGZvcm0gb2YgYSBuZXcgY2xpZW50IGF1
dGhlbnRpY2F0aW9uDQptZWNoYW5pc208YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2FuZCBh
IG5ldyBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUuICZuYnNwO01lY2hhbmlzbXMNCmFyZSBzcGVj
aWZpZWQgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt0cmFuc3BvcnRpbmcgYXNzZXJ0
aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zIHdpdGgNCmEgdG9rZW4gZW5kcG9pbnQsIGFzPGJyPg0K
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt3ZWxsIGFzIGdlbmVyYWwgcHJvY2Vzc2luZyBydWxlcy48
YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgaW50ZW50IG9m
IHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRlIGENCmNvbW1vbiBmcmFtZXdvcmsgZm9y
PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtPQXV0aCAyLjAgdG8gaW50ZXJ3b3JrIHdpdGgg
b3RoZXIgaWRlbnRpdHkgc3lzdGVtcw0KdXNpbmcgYXNzZXJ0aW9ucyw8YnI+DQomZ3Q7ICZndDsg
Jm5ic3A7ICZuYnNwO2FuZCB0byBwcm92aWRlIGFsdGVybmF0aXZlIGNsaWVudCBhdXRoZW50aWNh
dGlvbg0KbWVjaGFuaXNtcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm
bmJzcDtOb3RlIHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lcyBhYnN0cmFjdA0K
bWVzc2FnZSBmbG93cyBhbmQ8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3Byb2Nlc3Npbmcg
cnVsZXMuICZuYnNwO0luIG9yZGVyIHRvIGJlIGltcGxlbWVudGFibGUsDQpjb21wYW5pb248YnI+
DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3NwZWNpZmljYXRpb25zIGFyZSBuZWNlc3NhcnkgdG8g
cHJvdmlkZSB0aGUgY29ycmVzcG9uZGluZw0KY29uY3JldGU8YnI+DQomZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwO2luc3RhbnRpYXRpb25zLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIGZpbGUgY2Fu
IGJlIG9idGFpbmVkIHZpYTxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy8iPmh0dHA6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLzwvYT48YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IElFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tl
ZCB2aWE8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMvYmFsbG90LyI+aHR0cDovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMvYmFsbG90LzwvYT48
YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBObyBJUFIgZGVj
bGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuPGJyPg0K
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+
T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K
Jmd0OyA8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxi
cj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48L2Zv
bnQ+PC90dD4NCjwvZGl2PjwvYmxvY2txdW90ZT48L2JvZHk+PC9odG1sPg==

--_000_7CCC09034D4C4F49A7CAECA148935B47salesforcecom_--

From zhou.sujing@zte.com.cn  Thu Dec 13 18:27:25 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A91021F8BD2; Thu, 13 Dec 2012 18:27:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.003
X-Spam-Level: 
X-Spam-Status: No, score=-98.003 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45,  USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6bn6MTENeOo; Thu, 13 Dec 2012 18:27:24 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 943DF21F8AD2; Thu, 13 Dec 2012 18:27:23 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 076271243AF0; Fri, 14 Dec 2012 10:29:15 +0800 (CST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 00221724CD2; Fri, 14 Dec 2012 10:16:24 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qBE2R4ei022614; Fri, 14 Dec 2012 10:27:04 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: <7CCC0903-4D4C-4F49-A7CA-ECA148935B47@salesforce.com>
To: Chuck Mortimore 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Fri, 14 Dec 2012 10:26:50 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-14 10:26:57, Serialize complete at 2012-12-14 10:26:57
Content-Type: multipart/alternative; boundary="=_alternative 000D954948257AD4_="
X-MAIL: mse01.zte.com.cn qBE2R4ei022614
Cc: "oauth-bounces@ietf.org" , "ietf@ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 02:27:25 -0000

This is a multipart message in MIME format.
--=_alternative 000D954948257AD4_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SSBhbSBub3Qgc3VyZSBpZiB0aGUgZm9sbG93aW5nIHVzZWNhc2UgDQpodHRwOi8vd3d3LmlldGYu
b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMDIzMy5odG1sDQpjb3VsZCBi
ZSBzdXBwb3J0ZWQgYnkgYXNzZXJ0aW9uIGZyYW1ld29ya6OsDQpXZSBoYXZlIHNvbWUgZGlzY3Vz
c2lvbiBpbiANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJy
ZW50L21zZzEwMjAzLmh0bWwNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9v
YXV0aC9jdXJyZW50L21zZzEwMTk4Lmh0bWwgDQoNCkluIG15IHVzZSBjYXNlIG9yIGluIHNvbWUg
b3RoZXIgY2FzZXMsIGFzc2VydGlvbnMgZG9uJ3QgbmVlZCBjb25maWRlbnRpYWwgDQpwcm90ZWN0
aW9uLCANCmJhc2ljYWxseSBTVFMgZG9uJ3QgaGF2ZSB0byBhdXRoZW50aWNhdGUgYSBjbGllbnQg
YmVmb3JlIGlzc3VlaW5nIA0KImFzc2VydGlvbiIsIGlmIGl0IGNvdWxkIGJlIGNhbGxlZCBhc3Nl
cnRpb24gaGVyZS4NCg0KRXhhbXBsZSxJIHRydXN0IG15IGxheXdlciwgSSBtYXkgaXNzdWUgYW4g
ImFzc2VydGlvbiIgc3RhdGluZyBkZWxlZ2F0aW9uIA0KaW4gYWR2YW5jZSwgYW5kIHNlbmQgdG8g
dGhlIGxhd3llciB3aGVuIGl0IGlzIG5lZWRlZCwNCml0IGNvdWxkIGJlIEkgZ2l2ZSB0aGUgYXNz
ZXJ0aW9uIHRvIGEgZmFsc2UgbGF3eWVyLCBidXQgaXQgZG9lcyBub3QgDQptYXR0ZXIsIGJlY2F1
c2UgdGhlIGxhd3llciBoYXMgdG8gcHJvdmUgaGUga25vd3Mgc29tZSBjcmVkZW50aWFsIA0KY29y
cmVzcG9uZGluZyB0byBoaXMgSUQsDQp3aG8gaXMgZGVsZWdhdGVkIHNvbWUgcmlnaHRzLg0KDQpJ
ZiBhc3NlcnRpb24gZnJhbWV3b3JrIHdhbnQgdG8gc3VwcG9ydCB0aGlzIHVzZSBjYXNlLCB0aGVu
IGdlbmVyYXRpb24gb2YgDQphc3NlcnRpb24gc2hvdWxkIGJlIHJlbGF4ZWQsDQpvdGhlcndpc2Ug
bmV3IHdvcmsgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgdXNlIGNhc2UuDQoNCg0KDQpDaHVj
ayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20+INC009ogMjAxMi0xMi0xNCAx
MDowODozNDoNCg0KPiBPbiBEZWMgMTMsIDIwMTIsIGF0IDQ6MzAgUE0sICJ6aG91LnN1amluZ0B6
dGUuY29tLmNuIiANCjx6aG91LnN1amluZ0B6dGUuY29tLmNuDQo+ID4gd3JvdGU6DQoNCj4gDQo+
IEZyb20gdGhlIGxhbmd1YWdlLCBJIGdvdCBhbiBpbXByZXNzaW9uIHRoYXQgYXNzZXJ0aW9uIGlz
IG9ubHkgDQo+IGdlbmVyYXRlZCBieSB0b2tlbiBzZXJ2aWNlIGFmdGVyIGNsaWVudHMgcHJlc2Vu
dGluZyBzb21lIGNyZWRlbnRpYWxzLCANCj4gdGhlcmUgYXJlIG1heSBiZSBzb21lIGNhc2VzIHRo
YXQgImFzc2VydGlvbiIgZG9uJ3QgbmVlZCBjbGllbnQncyANCmNyZWRlbnRpYWwuIA0KPiBlLmcu
LCBSZXNvdXJjZSBvd25lciBhcyBhIHRva2VuIHNlcnZpY2UgIGNvdWxkIGdlbmVyYXRlICJhc3Nl
cnRpb24iIA0KPiB0byBhIGNsaWVudCBoZSB0cnVzdHMsIGJ1IHNpZ25pbmcgYSBzdGF0ZW1lbnQg
dGhhdCAiVGhpcyBkZWxlZ2F0aW9uIA0KPiBpcyBnaXZlbiB0byBhIGNsaWVudCBjYWxsZWQgY2xp
bmV0LWlkIA0KPiBmb3IgZG9pbmcgc29tZXRoaW5nIGZvciBtZSIuIA0KPiANCj4gU28gaG93IGRv
ZXMgdGhlIFNUUyB0cnVzdCB0aGUgY2xpZW50PyAgIFByZXN1bWFibHkgaWYgaXQgaXMgdHJ1c3Rl
ZCANCj4gaXQgaGFzIHNvbWUgbGV2ZWwgb2YgYXV0aGVudGljYXRpb24sIHllcz8NCj4gDQo+IC1j
bW9ydA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IENodWNrIE1vcnRpbW9yZSA8Y21vcnRpbW9yZUBz
YWxlc2ZvcmNlLmNvbT4g0LTT2iAyMDEyLTEyLTE0IDAwOjM5OjAzOg0KPiANCj4gPiBUaGUgbGFu
Z3VhZ2UgaXMgc2ltcGx5IG1lYW50IHRvIGhlbHAgaWxsdXN0cmF0ZSBob3cgdGhlIGZyYW1ld29y
ayANCj4gPiBtaWdodCBiZSB1c2VkLiAgIEhvdyBkbyB5b3UgdGhpbmsgaXQgd2lsbCByZXN0cmlj
dCB1c2FnZT8gICBIb3cgDQo+ID4gY291bGQgaXQgYmUgaW1wcm92ZWQ/IA0KPiA+IA0KPiA+IC1j
bW9ydCANCj4gPiANCj4gPiBPbiBEZWMgMTIsIDIwMTIsIGF0IDExOjA0IFBNLCA8emhvdS5zdWpp
bmdAenRlLmNvbS5jbj4gd3JvdGU6IA0KPiA+IA0KPiA+IA0KPiA+IEluICJzZWN0aW9uIDMgDQo+
ID4gIFRoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVyOyBpdHMgDQo+ID4g
IHJvbGUgaXMgdG8gZnVsZmlsbCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoIHByZXNlbnQg
dmFyaW91cyANCj4gPiAgY3JlZGVudGlhbHMsIGFuZCBtaW50IGFzc2VydGlvbnMgYXMgcmVxdWVz
dGVkLCBmaWxsIHRoZW0gd2l0aCANCj4gPiAgYXBwcm9wcmlhdGUgaW5mb3JtYXRpb24sIGFuZCBz
aWduIHRoZW0uIiANCj4gPiANCj4gPiANCj4gPiBBcyBJIHVuZGVyc3RhbmQsIGFuIGFzc2VydGlv
biBnZW5lcmF0ZWQgYnkgYSBTVFMsIGlzIGRvbmUgZmxvbGxvd2luZw0KPiA+IHRoZXNzIHN0ZXBz
OiANCj4gPiAxLiBDbGllbnQgcHJlc2VudHMgY3JlZGVudGlhbCBhbmQgcmVxdWVzdHMgYW4gYXNz
ZXJ0aW9uIA0KPiA+IDIuIFNUUyBnZW5lcmF0ZXMgYXNzZXJ0aW9uIGFuZCBzZW5kcyB0byBDbGll
bnQgDQo+ID4gQ29ycmVjdD8gDQo+ID4gDQo+ID4gVGhhdCBtYXkgcmVzdHJpY3QgdGhlIHVzZSBj
YXNlcyB0aGF0IHRoaXMgYXNzZXJ0aW9uIGZyYW1ld29yayANCj4gY291bGQgc3VwcG9ydCwgDQo+
ID4gaXMgaXQgYSBtdXN0PyANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBvYXV0aC1ib3Vu
Y2VzQGlldGYub3JnINC009ogMjAxMi0xMi0xMSAwMjozMzo1NzoNCj4gPiANCj4gPiA+IA0KPiA+
ID4gVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBXZWIgQXV0aG9yaXph
dGlvbiBQcm90b2NvbCANCldHDQo+ID4gPiAob2F1dGgpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dp
bmcgZG9jdW1lbnQ6DQo+ID4gPiAtICdBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAn
DQo+ID4gPiAgIDxkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDgudHh0PiBhcyBQcm9wb3Nl
ZCBTdGFuZGFyZA0KPiA+ID4gDQo+ID4gPiBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNp
b24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgDQpzb2xpY2l0cw0KPiA+ID4gZmluYWwgY29t
bWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRzIHRv
IA0KdGhlDQo+ID4gPiBpZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxMi0xMi0yNC4g
RXhjZXB0aW9uYWxseSwgY29tbWVudHMgDQptYXkgYmUNCj4gPiA+IHNlbnQgdG8gaWVzZ0BpZXRm
Lm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUNCj4gPiA+IGJl
Z2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLg0K
PiA+ID4gDQo+ID4gPiBBYnN0cmFjdA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+ICAgIFRoaXMgc3Bl
Y2lmaWNhdGlvbiBwcm92aWRlcyBhIGZyYW1ld29yayBmb3IgdGhlIHVzZSBvZiBhc3NlcnRpb25z
DQo+ID4gPiAgICB3aXRoIE9BdXRoIDIuMCBpbiB0aGUgZm9ybSBvZiBhIG5ldyBjbGllbnQgYXV0
aGVudGljYXRpb24gDQptZWNoYW5pc20NCj4gPiA+ICAgIGFuZCBhIG5ldyBhdXRob3JpemF0aW9u
IGdyYW50IHR5cGUuICBNZWNoYW5pc21zIGFyZSBzcGVjaWZpZWQgZm9yDQo+ID4gPiAgICB0cmFu
c3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zIHdpdGggYSB0b2tlbiANCmVu
ZHBvaW50LCBhcw0KPiA+ID4gICAgd2VsbCBhcyBnZW5lcmFsIHByb2Nlc3NpbmcgcnVsZXMuDQo+
ID4gPiANCj4gPiA+ICAgIFRoZSBpbnRlbnQgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIHRvIHBy
b3ZpZGUgYSBjb21tb24gZnJhbWV3b3JrIA0KZm9yDQo+ID4gPiAgICBPQXV0aCAyLjAgdG8gaW50
ZXJ3b3JrIHdpdGggb3RoZXIgaWRlbnRpdHkgc3lzdGVtcyB1c2luZyANCmFzc2VydGlvbnMsDQo+
ID4gPiAgICBhbmQgdG8gcHJvdmlkZSBhbHRlcm5hdGl2ZSBjbGllbnQgYXV0aGVudGljYXRpb24g
bWVjaGFuaXNtcy4NCj4gPiA+IA0KPiA+ID4gICAgTm90ZSB0aGF0IHRoaXMgc3BlY2lmaWNhdGlv
biBvbmx5IGRlZmluZXMgYWJzdHJhY3QgbWVzc2FnZSBmbG93cyANCmFuZA0KPiA+ID4gICAgcHJv
Y2Vzc2luZyBydWxlcy4gIEluIG9yZGVyIHRvIGJlIGltcGxlbWVudGFibGUsIGNvbXBhbmlvbg0K
PiA+ID4gICAgc3BlY2lmaWNhdGlvbnMgYXJlIG5lY2Vzc2FyeSB0byBwcm92aWRlIHRoZSBjb3Jy
ZXNwb25kaW5nIA0KY29uY3JldGUNCj4gPiA+ICAgIGluc3RhbnRpYXRpb25zLg0KPiA+ID4gDQo+
ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlh
DQo+ID4gPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgt
YXNzZXJ0aW9ucy8NCj4gPiA+IA0KPiA+ID4gSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2Vk
IHZpYQ0KPiA+ID4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9h
dXRoLWFzc2VydGlvbnMvYmFsbG90Lw0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IE5vIElQUiBkZWNs
YXJhdGlvbnMgaGF2ZSBiZWVuIHN1Ym1pdHRlZCBkaXJlY3RseSBvbiB0aGlzIEktRC4NCj4gPiA+
IA0KPiA+ID4gDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZw0K
PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPiA+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gT0F1dGgg
bWFpbGluZyBsaXN0DQo+ID4gT0F1dGhAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIA0K
--=_alternative 000D954948257AD4_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gbm90IHN1cmUgaWYgdGhl
IGZvbGxvd2luZyB1c2VjYXNlDQombmJzcDtodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2
ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMDIzMy5odG1sPC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBmYWNlPSJzYW5zLXNlcmlmIj5jb3VsZCBiZSBzdXBwb3J0ZWQgYnkgYXNzZXJ0aW9uIGZyYW1l
d29ya6OsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XZSBoYXZl
IHNvbWUgZGlzY3Vzc2lvbiBpbiAmbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9
InNhbnMtc2VyaWYiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9j
dXJyZW50L21zZzEwMjAzLmh0bWw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt
c2VyaWYiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50
L21zZzEwMTk4Lmh0bWwNCjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu
cy1zZXJpZiI+SW4gbXkgdXNlIGNhc2Ugb3IgaW4gc29tZSBvdGhlciBjYXNlcywNCmFzc2VydGlv
bnMgZG9uJ3QgbmVlZCBjb25maWRlbnRpYWwgcHJvdGVjdGlvbiwgPC9mb250Pg0KPGJyPjxmb250
IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5iYXNpY2FsbHkgU1RTIGRvbid0IGhhdmUgdG8gYXV0
aGVudGljYXRlDQphIGNsaWVudCBiZWZvcmUgaXNzdWVpbmcgJnF1b3Q7YXNzZXJ0aW9uJnF1b3Q7
LCBpZiBpdCBjb3VsZCBiZSBjYWxsZWQgYXNzZXJ0aW9uDQpoZXJlLjwvZm9udD4NCjxicj4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+RXhhbXBsZSxJIHRydXN0IG15IGxheXdl
ciwgSSBtYXkgaXNzdWUNCmFuICZxdW90O2Fzc2VydGlvbiZxdW90OyBzdGF0aW5nIGRlbGVnYXRp
b24gaW4gYWR2YW5jZSwgYW5kIHNlbmQgdG8gdGhlDQpsYXd5ZXIgd2hlbiBpdCBpcyBuZWVkZWQs
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pdCBjb3VsZCBiZSBJ
IGdpdmUgdGhlIGFzc2VydGlvbiB0bw0KYSBmYWxzZSBsYXd5ZXIsIGJ1dCBpdCBkb2VzIG5vdCBt
YXR0ZXIsIGJlY2F1c2UgdGhlIGxhd3llciBoYXMgdG8gcHJvdmUNCmhlIGtub3dzIHNvbWUgY3Jl
ZGVudGlhbCBjb3JyZXNwb25kaW5nIHRvIGhpcyBJRCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPndobyBpcyBkZWxlZ2F0ZWQgc29tZSByaWdodHMuPC9mb250Pg0K
PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiBhc3NlcnRpb24gZnJh
bWV3b3JrIHdhbnQgdG8gc3VwcG9ydA0KdGhpcyB1c2UgY2FzZSwgdGhlbiBnZW5lcmF0aW9uIG9m
IGFzc2VydGlvbiBzaG91bGQgYmUgcmVsYXhlZCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh
Y2U9InNhbnMtc2VyaWYiPm90aGVyd2lzZSBuZXcgd29yayBpcyByZXF1aXJlZCB0byBzdXBwb3J0
DQp0aGUgdXNlIGNhc2UuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz
aXplPTI+Q2h1Y2sgTW9ydGltb3JlICZsdDtjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tJmd0Ow0K
0LTT2iAyMDEyLTEyLTE0IDEwOjA4OjM0Ojxicj4NCjxicj4NCiZndDsgT24gRGVjIDEzLCAyMDEy
LCBhdCA0OjMwIFBNLCAmcXVvdDt6aG91LnN1amluZ0B6dGUuY29tLmNuJnF1b3Q7ICZsdDt6aG91
LnN1amluZ0B6dGUuY29tLmNuPGJyPg0KJmd0OyAmZ3Q7IHdyb3RlOjxicj4NCjwvZm9udD48L3R0
Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEZyb20gdGhlIGxhbmd1YWdl
LCBJIGdvdCBhbiBpbXByZXNzaW9uIHRoYXQgYXNzZXJ0aW9uIGlzIG9ubHkgPGJyPg0KJmd0OyBn
ZW5lcmF0ZWQgYnkgdG9rZW4gc2VydmljZSBhZnRlciBjbGllbnRzIHByZXNlbnRpbmcgc29tZSBj
cmVkZW50aWFscywNCjxicj4NCiZndDsgdGhlcmUgYXJlIG1heSBiZSBzb21lIGNhc2VzIHRoYXQg
JnF1b3Q7YXNzZXJ0aW9uJnF1b3Q7IGRvbid0IG5lZWQNCmNsaWVudCdzIGNyZWRlbnRpYWwuIDxi
cj4NCiZndDsgZS5nLiwgUmVzb3VyY2Ugb3duZXIgYXMgYSB0b2tlbiBzZXJ2aWNlICZuYnNwO2Nv
dWxkIGdlbmVyYXRlICZxdW90O2Fzc2VydGlvbiZxdW90Ow0KPGJyPg0KJmd0OyB0byBhIGNsaWVu
dCBoZSB0cnVzdHMsIGJ1IHNpZ25pbmcgYSBzdGF0ZW1lbnQgdGhhdCAmcXVvdDtUaGlzIGRlbGVn
YXRpb24NCjxicj4NCiZndDsgaXMgZ2l2ZW4gdG8gYSBjbGllbnQgY2FsbGVkIGNsaW5ldC1pZCA8
YnI+DQomZ3Q7IGZvciBkb2luZyBzb21ldGhpbmcgZm9yIG1lJnF1b3Q7LiA8L2ZvbnQ+PC90dD4N
Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBTbyBob3cgZG9lcyB0aGUgU1RT
IHRydXN0IHRoZSBjbGllbnQ/ICZuYnNwOyBQcmVzdW1hYmx5IGlmIGl0IGlzIHRydXN0ZWQNCjxi
cj4NCiZndDsgaXQgaGFzIHNvbWUgbGV2ZWwgb2YgYXV0aGVudGljYXRpb24sIHllcz88L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAtY21vcnQ8L2ZvbnQ+
PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENodWNrIE1vcnRpbW9yZSAmbHQ7Y21vcnRp
bW9yZUBzYWxlc2ZvcmNlLmNvbSZndDsg0LTT2iAyMDEyLTEyLTE0DQowMDozOTowMzo8YnI+DQom
Z3Q7IDxicj4NCiZndDsgJmd0OyBUaGUgbGFuZ3VhZ2UgaXMgc2ltcGx5IG1lYW50IHRvIGhlbHAg
aWxsdXN0cmF0ZSBob3cgdGhlIGZyYW1ld29yaw0KPGJyPg0KJmd0OyAmZ3Q7IG1pZ2h0IGJlIHVz
ZWQuICZuYnNwOyBIb3cgZG8geW91IHRoaW5rIGl0IHdpbGwgcmVzdHJpY3QgdXNhZ2U/DQombmJz
cDsgSG93IDxicj4NCiZndDsgJmd0OyBjb3VsZCBpdCBiZSBpbXByb3ZlZD8gPGJyPg0KJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAtY21vcnQgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyBPbiBEZWMgMTIsIDIwMTIsIGF0IDExOjA0IFBNLCAmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5j
biZndDsNCndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyBJbiAmcXVvdDtzZWN0aW9uIDMgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO1RoZSB0b2tlbiBz
ZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVyOyBpdHMgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw
O3JvbGUgaXMgdG8gZnVsZmlsbCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoIHByZXNlbnQN
CnZhcmlvdXMgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO2NyZWRlbnRpYWxzLCBhbmQgbWludCBhc3Nl
cnRpb25zIGFzIHJlcXVlc3RlZCwgZmlsbCB0aGVtDQp3aXRoIDxicj4NCiZndDsgJmd0OyAmbmJz
cDthcHByb3ByaWF0ZSBpbmZvcm1hdGlvbiwgYW5kIHNpZ24gdGhlbS4mcXVvdDsgPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQXMgSSB1bmRlcnN0YW5kLCBh
biBhc3NlcnRpb24gZ2VuZXJhdGVkIGJ5IGEgU1RTLCBpcyBkb25lIGZsb2xsb3dpbmc8YnI+DQom
Z3Q7ICZndDsgdGhlc3Mgc3RlcHM6IDxicj4NCiZndDsgJmd0OyAxLiBDbGllbnQgcHJlc2VudHMg
Y3JlZGVudGlhbCBhbmQgcmVxdWVzdHMgYW4gYXNzZXJ0aW9uIDxicj4NCiZndDsgJmd0OyAyLiBT
VFMgZ2VuZXJhdGVzIGFzc2VydGlvbiBhbmQgc2VuZHMgdG8gQ2xpZW50IDxicj4NCiZndDsgJmd0
OyBDb3JyZWN0PyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoYXQgbWF5IHJlc3Ry
aWN0IHRoZSB1c2UgY2FzZXMgdGhhdCB0aGlzIGFzc2VydGlvbiBmcmFtZXdvcmsNCjxicj4NCiZn
dDsgY291bGQgc3VwcG9ydCwgPGJyPg0KJmd0OyAmZ3Q7IGlzIGl0IGEgbXVzdD8gPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyBvYXV0aC1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMi0xMi0xMSAwMjoz
Mzo1Nzo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBXZWIgQXV0aG9y
aXphdGlvbg0KUHJvdG9jb2wgV0c8YnI+DQomZ3Q7ICZndDsgJmd0OyAob2F1dGgpIHRvIGNvbnNp
ZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgLSAnQXNzZXJ0
aW9uIEZyYW1ld29yayBmb3IgT0F1dGggMi4wJzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAm
bHQ7ZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA4LnR4dCZndDsgYXMgUHJvcG9zZWQNClN0
YW5kYXJkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIElFU0cg
cGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywNCmFuZCBzb2xp
Y2l0czxicj4NCiZndDsgJmd0OyAmZ3Q7IGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQ
bGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21tZW50cw0KdG8gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgaWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTItMTItMjQuIEV4Y2VwdGlvbmFs
bHksDQpjb21tZW50cyBtYXkgYmU8YnI+DQomZ3Q7ICZndDsgJmd0OyBzZW50IHRvIGllc2dAaWV0
Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNhc2UsIHBsZWFzZSByZXRhaW4NCnRoZTxicj4NCiZn
dDsgJmd0OyAmZ3Q7IGJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9t
YXRlZCBzb3J0aW5nLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFi
c3RyYWN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBwcm92aWRlcyBhIGZy
YW1ld29yayBmb3INCnRoZSB1c2Ugb2YgYXNzZXJ0aW9uczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDt3aXRoIE9BdXRoIDIuMCBpbiB0aGUgZm9ybSBvZiBhIG5ldyBjbGllbnQNCmF1
dGhlbnRpY2F0aW9uIG1lY2hhbmlzbTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDth
bmQgYSBuZXcgYXV0aG9yaXphdGlvbiBncmFudCB0eXBlLiAmbmJzcDtNZWNoYW5pc21zDQphcmUg
c3BlY2lmaWVkIGZvcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt0cmFuc3BvcnRp
bmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zDQp3aXRoIGEgdG9rZW4gZW5kcG9pbnQs
IGFzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3dlbGwgYXMgZ2VuZXJhbCBwcm9j
ZXNzaW5nIHJ1bGVzLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDtUaGUgaW50ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0byBwcm92aWRl
DQphIGNvbW1vbiBmcmFtZXdvcmsgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
O09BdXRoIDIuMCB0byBpbnRlcndvcmsgd2l0aCBvdGhlciBpZGVudGl0eQ0Kc3lzdGVtcyB1c2lu
ZyBhc3NlcnRpb25zLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDthbmQgdG8gcHJv
dmlkZSBhbHRlcm5hdGl2ZSBjbGllbnQgYXV0aGVudGljYXRpb24NCm1lY2hhbmlzbXMuPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO05vdGUgdGhh
dCB0aGlzIHNwZWNpZmljYXRpb24gb25seSBkZWZpbmVzIGFic3RyYWN0DQptZXNzYWdlIGZsb3dz
IGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtwcm9jZXNzaW5nIHJ1bGVzLiAm
bmJzcDtJbiBvcmRlciB0byBiZSBpbXBsZW1lbnRhYmxlLA0KY29tcGFuaW9uPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO3NwZWNpZmljYXRpb25zIGFyZSBuZWNlc3NhcnkgdG8gcHJv
dmlkZSB0aGUNCmNvcnJlc3BvbmRpbmcgY29uY3JldGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJz
cDsgJm5ic3A7aW5zdGFudGlhdGlvbnMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgVGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYTxicj4NCiZndDsgJmd0
OyAmZ3Q7IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1h
c3NlcnRpb25zLzxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IElFU0cg
ZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWE8YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRwOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy9iYWxs
b3QvPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5
IG9uIHRoaXMNCkktRC48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZndDsgJmd0OyBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBP
QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7
ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCA8L2ZvbnQ+
PC90dD4NCg==
--=_alternative 000D954948257AD4_=--

From cmortimore@salesforce.com  Thu Dec 13 18:34:21 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38D821F89C6; Thu, 13 Dec 2012 18:34:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.327
X-Spam-Level: 
X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6tBPlC28Aqg; Thu, 13 Dec 2012 18:34:20 -0800 (PST)
Received: from exprod8og114.obsmtp.com (exprod8og114.obsmtp.com [64.18.3.28]) by ietfa.amsl.com (Postfix) with SMTP id 80C6121F8974; Thu, 13 Dec 2012 18:34:20 -0800 (PST)
Received: from exsfm-hub4.internal.salesforce.com ([204.14.239.239]) by exprod8ob114.postini.com ([64.18.7.12]) with SMTP ID DSNKUMqQLBUfMS/fhUq0BBeLMO4SfiMPFjP0@postini.com; Thu, 13 Dec 2012 18:34:20 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub4.internal.salesforce.com ([10.1.127.8]) with mapi; Thu, 13 Dec 2012 18:34:20 -0800
From: Chuck Mortimore 
To: "zhou.sujing@zte.com.cn" 
Date: Thu, 13 Dec 2012 18:34:13 -0800
Thread-Topic: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
Thread-Index: Ac3Zo4Q/pWOl49zpRlOxQ1aeV6bIWg==
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_D6F62E8816564951A206FC6E20EBBAB5salesforcecom_"
MIME-Version: 1.0
Cc: "oauth-bounces@ietf.org" , "ietf@ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 02:34:22 -0000

--_000_D6F62E8816564951A206FC6E20EBBAB5salesforcecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

WW91IHdhbnQgYSBob2xkZXIgb2Yga2V5IHBhdHRlcm4uICBUaGUgZHJhZnQgdG91Y2hlcyBvbiBp
dA0KDQoNCg0KDQoNCiAgIFRoZSBwcm90b2NvbCBwYXJhbWV0ZXJzIGFuZCBwcm9jZXNzaW5nIHJ1
bGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudA0KICAgYXJlIGludGVuZGVkIHRvIHN1cHBvcnQg
YSBjbGllbnQgcHJlc2VudGluZyBhIGJlYXJlciBhc3NlcnRpb24gdG8gYW4NCiAgIGF1dGhvcml6
YXRpb24gc2VydmVyLiAgVGhlIHVzZSBvZiBob2xkZXItb2Yta2V5IGFzc2VydGlvbnMgYXJlIG5v
dA0KICAgcHJlY2x1ZGVkIGJ5IHRoaXMgZG9jdW1lbnQsIGJ1dCBhZGRpdGlvbmFsIHByb3RvY29s
IGRldGFpbHMgd291bGQNCiAgIG5lZWQgdG8gYmUgc3BlY2lmaWVkLg0KDQoNClNvIC0gaWYgeW91
IHdhbnQgdGhpcywgeW91IHNob3VsZCBwdXQgZm9ydGggYSBob2xkZXIgb2Yga2V5IHByb2ZpbGlu
ZyBvZiB0aGlzIGRyYWZ0IGFuZCBzZWUgaWYgdGhlcmUgYXJlIGFueSBpc3N1ZXMuICAgVGhlIG9u
bHkgcHJvZmlsZXMgd2UgaGF2ZSB0aHVzIGZhciBhcmUgc2FtbCBhbmQgand0IGJlYXJlciBhc3Nl
cnRpb25zLg0KDQoNCi0gY21vcnQNCg0KT24gRGVjIDEzLCAyMDEyLCBhdCA2OjI3IFBNLCAiemhv
dS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWppbmdAenRlLmNvbS5jbj4iIDx6aG91
LnN1amluZ0B6dGUuY29tLmNuPG1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPj4gd3JvdGU6
DQoNCg0KSSBhbSBub3Qgc3VyZSBpZiB0aGUgZm9sbG93aW5nIHVzZWNhc2UgIGh0dHA6Ly93d3cu
aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEwMjMzLmh0bWwNCmNv
dWxkIGJlIHN1cHBvcnRlZCBieSBhc3NlcnRpb24gZnJhbWV3b3Jr77yMDQpXZSBoYXZlIHNvbWUg
ZGlzY3Vzc2lvbiBpbg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo
L2N1cnJlbnQvbXNnMTAyMDMuaHRtbA0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv
d2ViL29hdXRoL2N1cnJlbnQvbXNnMTAxOTguaHRtbA0KDQpJbiBteSB1c2UgY2FzZSBvciBpbiBz
b21lIG90aGVyIGNhc2VzLCBhc3NlcnRpb25zIGRvbid0IG5lZWQgY29uZmlkZW50aWFsIHByb3Rl
Y3Rpb24sDQpiYXNpY2FsbHkgU1RTIGRvbid0IGhhdmUgdG8gYXV0aGVudGljYXRlIGEgY2xpZW50
IGJlZm9yZSBpc3N1ZWluZyAiYXNzZXJ0aW9uIiwgaWYgaXQgY291bGQgYmUgY2FsbGVkIGFzc2Vy
dGlvbiBoZXJlLg0KDQpFeGFtcGxlLEkgdHJ1c3QgbXkgbGF5d2VyLCBJIG1heSBpc3N1ZSBhbiAi
YXNzZXJ0aW9uIiBzdGF0aW5nIGRlbGVnYXRpb24gaW4gYWR2YW5jZSwgYW5kIHNlbmQgdG8gdGhl
IGxhd3llciB3aGVuIGl0IGlzIG5lZWRlZCwNCml0IGNvdWxkIGJlIEkgZ2l2ZSB0aGUgYXNzZXJ0
aW9uIHRvIGEgZmFsc2UgbGF3eWVyLCBidXQgaXQgZG9lcyBub3QgbWF0dGVyLCBiZWNhdXNlIHRo
ZSBsYXd5ZXIgaGFzIHRvIHByb3ZlIGhlIGtub3dzIHNvbWUgY3JlZGVudGlhbCBjb3JyZXNwb25k
aW5nIHRvIGhpcyBJRCwNCndobyBpcyBkZWxlZ2F0ZWQgc29tZSByaWdodHMuDQoNCklmIGFzc2Vy
dGlvbiBmcmFtZXdvcmsgd2FudCB0byBzdXBwb3J0IHRoaXMgdXNlIGNhc2UsIHRoZW4gZ2VuZXJh
dGlvbiBvZiBhc3NlcnRpb24gc2hvdWxkIGJlIHJlbGF4ZWQsDQpvdGhlcndpc2UgbmV3IHdvcmsg
aXMgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgdXNlIGNhc2UuDQoNCg0KDQpDaHVjayBNb3J0aW1v
cmUgPGNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208bWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3Jj
ZS5jb20+PiDlhpnkuo4gMjAxMi0xMi0xNCAxMDowODozNDoNCg0KPiBPbiBEZWMgMTMsIDIwMTIs
IGF0IDQ6MzAgUE0sICJ6aG91LnN1amluZ0B6dGUuY29tLmNuPG1haWx0bzp6aG91LnN1amluZ0B6
dGUuY29tLmNuPiIgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY248bWFpbHRvOnpob3Uuc3VqaW5nQHp0
ZS5jb20uY24+DQo+ID4gd3JvdGU6DQoNCj4NCj4gRnJvbSB0aGUgbGFuZ3VhZ2UsIEkgZ290IGFu
IGltcHJlc3Npb24gdGhhdCBhc3NlcnRpb24gaXMgb25seQ0KPiBnZW5lcmF0ZWQgYnkgdG9rZW4g
c2VydmljZSBhZnRlciBjbGllbnRzIHByZXNlbnRpbmcgc29tZSBjcmVkZW50aWFscywNCj4gdGhl
cmUgYXJlIG1heSBiZSBzb21lIGNhc2VzIHRoYXQgImFzc2VydGlvbiIgZG9uJ3QgbmVlZCBjbGll
bnQncyBjcmVkZW50aWFsLg0KPiBlLmcuLCBSZXNvdXJjZSBvd25lciBhcyBhIHRva2VuIHNlcnZp
Y2UgIGNvdWxkIGdlbmVyYXRlICJhc3NlcnRpb24iDQo+IHRvIGEgY2xpZW50IGhlIHRydXN0cywg
YnUgc2lnbmluZyBhIHN0YXRlbWVudCB0aGF0ICJUaGlzIGRlbGVnYXRpb24NCj4gaXMgZ2l2ZW4g
dG8gYSBjbGllbnQgY2FsbGVkIGNsaW5ldC1pZA0KPiBmb3IgZG9pbmcgc29tZXRoaW5nIGZvciBt
ZSIuDQo+DQo+IFNvIGhvdyBkb2VzIHRoZSBTVFMgdHJ1c3QgdGhlIGNsaWVudD8gICBQcmVzdW1h
Ymx5IGlmIGl0IGlzIHRydXN0ZWQNCj4gaXQgaGFzIHNvbWUgbGV2ZWwgb2YgYXV0aGVudGljYXRp
b24sIHllcz8NCj4NCj4gLWNtb3J0DQo+DQo+DQo+DQo+DQo+DQo+IENodWNrIE1vcnRpbW9yZSA8
Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbTxtYWlsdG86Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNv
bT4+IOWGmeS6jiAyMDEyLTEyLTE0IDAwOjM5OjAzOg0KPg0KPiA+IFRoZSBsYW5ndWFnZSBpcyBz
aW1wbHkgbWVhbnQgdG8gaGVscCBpbGx1c3RyYXRlIGhvdyB0aGUgZnJhbWV3b3JrDQo+ID4gbWln
aHQgYmUgdXNlZC4gICBIb3cgZG8geW91IHRoaW5rIGl0IHdpbGwgcmVzdHJpY3QgdXNhZ2U/ICAg
SG93DQo+ID4gY291bGQgaXQgYmUgaW1wcm92ZWQ/DQo+ID4NCj4gPiAtY21vcnQNCj4gPg0KPiA+
IE9uIERlYyAxMiwgMjAxMiwgYXQgMTE6MDQgUE0sIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPG1h
aWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPj4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+IEluICJz
ZWN0aW9uIDMNCj4gPiAgVGhlIHRva2VuIHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbiBpc3N1ZXI7
IGl0cw0KPiA+ICByb2xlIGlzIHRvIGZ1bGZpbGwgcmVxdWVzdHMgZnJvbSBjbGllbnRzLCB3aGlj
aCBwcmVzZW50IHZhcmlvdXMNCj4gPiAgY3JlZGVudGlhbHMsIGFuZCBtaW50IGFzc2VydGlvbnMg
YXMgcmVxdWVzdGVkLCBmaWxsIHRoZW0gd2l0aA0KPiA+ICBhcHByb3ByaWF0ZSBpbmZvcm1hdGlv
biwgYW5kIHNpZ24gdGhlbS4iDQo+ID4NCj4gPg0KPiA+IEFzIEkgdW5kZXJzdGFuZCwgYW4gYXNz
ZXJ0aW9uIGdlbmVyYXRlZCBieSBhIFNUUywgaXMgZG9uZSBmbG9sbG93aW5nDQo+ID4gdGhlc3Mg
c3RlcHM6DQo+ID4gMS4gQ2xpZW50IHByZXNlbnRzIGNyZWRlbnRpYWwgYW5kIHJlcXVlc3RzIGFu
IGFzc2VydGlvbg0KPiA+IDIuIFNUUyBnZW5lcmF0ZXMgYXNzZXJ0aW9uIGFuZCBzZW5kcyB0byBD
bGllbnQNCj4gPiBDb3JyZWN0Pw0KPiA+DQo+ID4gVGhhdCBtYXkgcmVzdHJpY3QgdGhlIHVzZSBj
YXNlcyB0aGF0IHRoaXMgYXNzZXJ0aW9uIGZyYW1ld29yaw0KPiBjb3VsZCBzdXBwb3J0LA0KPiA+
IGlzIGl0IGEgbXVzdD8NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IG9hdXRoLWJvdW5jZXNAaWV0
Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IOWGmeS6jiAyMDEyLTEyLTExIDAy
OjMzOjU3Og0KPiA+DQo+ID4gPg0KPiA+ID4gVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVz
dCBmcm9tIHRoZSBXZWIgQXV0aG9yaXphdGlvbiBQcm90b2NvbCBXRw0KPiA+ID4gKG9hdXRoKSB0
byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiA+ID4gLSAnQXNzZXJ0aW9uIEZy
YW1ld29yayBmb3IgT0F1dGggMi4wJw0KPiA+ID4gICA8ZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRp
b25zLTA4LnR4dD4gYXMgUHJvcG9zZWQgU3RhbmRhcmQNCj4gPiA+DQo+ID4gPiBUaGUgSUVTRyBw
bGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNp
dHMNCj4gPiA+IGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJz
dGFudGl2ZSBjb21tZW50cyB0byB0aGUNCj4gPiA+IGlldGZAaWV0Zi5vcmc8bWFpbHRvOmlldGZA
aWV0Zi5vcmc+IG1haWxpbmcgbGlzdHMgYnkgMjAxMi0xMi0yNC4gRXhjZXB0aW9uYWxseSwgY29t
bWVudHMgbWF5IGJlDQo+ID4gPiBzZW50IHRvIGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0
Zi5vcmc+IGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KPiA+ID4g
YmVnaW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcu
DQo+ID4gPg0KPiA+ID4gQWJzdHJhY3QNCj4gPiA+DQo+ID4gPg0KPiA+ID4gICAgVGhpcyBzcGVj
aWZpY2F0aW9uIHByb3ZpZGVzIGEgZnJhbWV3b3JrIGZvciB0aGUgdXNlIG9mIGFzc2VydGlvbnMN
Cj4gPiA+ICAgIHdpdGggT0F1dGggMi4wIGluIHRoZSBmb3JtIG9mIGEgbmV3IGNsaWVudCBhdXRo
ZW50aWNhdGlvbiBtZWNoYW5pc20NCj4gPiA+ICAgIGFuZCBhIG5ldyBhdXRob3JpemF0aW9uIGdy
YW50IHR5cGUuICBNZWNoYW5pc21zIGFyZSBzcGVjaWZpZWQgZm9yDQo+ID4gPiAgICB0cmFuc3Bv
cnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zIHdpdGggYSB0b2tlbiBlbmRwb2lu
dCwgYXMNCj4gPiA+ICAgIHdlbGwgYXMgZ2VuZXJhbCBwcm9jZXNzaW5nIHJ1bGVzLg0KPiA+ID4N
Cj4gPiA+ICAgIFRoZSBpbnRlbnQgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIHRvIHByb3ZpZGUg
YSBjb21tb24gZnJhbWV3b3JrIGZvcg0KPiA+ID4gICAgT0F1dGggMi4wIHRvIGludGVyd29yayB3
aXRoIG90aGVyIGlkZW50aXR5IHN5c3RlbXMgdXNpbmcgYXNzZXJ0aW9ucywNCj4gPiA+ICAgIGFu
ZCB0byBwcm92aWRlIGFsdGVybmF0aXZlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBtZWNoYW5pc21z
Lg0KPiA+ID4NCj4gPiA+ICAgIE5vdGUgdGhhdCB0aGlzIHNwZWNpZmljYXRpb24gb25seSBkZWZp
bmVzIGFic3RyYWN0IG1lc3NhZ2UgZmxvd3MgYW5kDQo+ID4gPiAgICBwcm9jZXNzaW5nIHJ1bGVz
LiAgSW4gb3JkZXIgdG8gYmUgaW1wbGVtZW50YWJsZSwgY29tcGFuaW9uDQo+ID4gPiAgICBzcGVj
aWZpY2F0aW9ucyBhcmUgbmVjZXNzYXJ5IHRvIHByb3ZpZGUgdGhlIGNvcnJlc3BvbmRpbmcgY29u
Y3JldGUNCj4gPiA+ICAgIGluc3RhbnRpYXRpb25zLg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+
ID4NCj4gPiA+IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWENCj4gPiA+IGh0dHA6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLw0KPiA+ID4N
Cj4gPiA+IElFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWENCj4gPiA+IGh0dHA6Ly9k
YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zL2JhbGxv
dC8NCj4gPiA+DQo+ID4gPg0KPiA+ID4gTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3Vi
bWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gT0F1dGggbWFp
bGluZyBsaXN0DQo+ID4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+
ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBPQXV0aCBt
YWlsaW5nIGxpc3QNCj4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+
ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0K

--_000_D6F62E8816564951A206FC6E20EBBAB5salesforcecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+WW91IHdhbnQg
YSBob2xkZXIgb2Yga2V5IHBhdHRlcm4uICZuYnNwO1RoZSBkcmFmdCB0b3VjaGVzIG9uIGl0PC9k
aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PHByZSBzdHls
ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAiPjxmb250IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFu
IiBmYWNlPSJIZWx2ZXRpY2EiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0i
d2hpdGUtc3BhY2U6IG5vcm1hbDsiPg0KICAgVGhlIHByb3RvY29sIHBhcmFtZXRlcnMgYW5kIHBy
b2Nlc3NpbmcgcnVsZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50DQogICBhcmUgaW50ZW5kZWQg
dG8gc3VwcG9ydCBhIGNsaWVudCBwcmVzZW50aW5nIGEgYmVhcmVyIGFzc2VydGlvbiB0byBhbg0K
ICAgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuICBUaGUgdXNlIG9mIGhvbGRlci1vZi1rZXkgYXNzZXJ0
aW9ucyBhcmUgbm90DQogICBwcmVjbHVkZWQgYnkgdGhpcyBkb2N1bWVudCwgYnV0IGFkZGl0aW9u
YWwgcHJvdG9jb2wgZGV0YWlscyB3b3VsZA0KICAgbmVlZCB0byBiZSBzcGVjaWZpZWQuPC9zcGFu
PjwvZm9udD48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgc3R5bGU9ImZvbnQtZmFtaWx5
OiBUaW1lczsgZm9udC1zaXplOiBtZWRpdW07IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgLXdlYmtp
dC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjkyOTY5KTsgLXdlYmtp
dC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsg
LXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMw
NDY5KTsgIj4NCjwvc3Bhbj48L3ByZT48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogVGltZXM7IGZv
bnQtc2l6ZTogbWVkaXVtOyAtd2Via2l0LXRhcC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2
LCAyNiwgMC4yOTI5NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1
LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiBy
Z2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPjxicj48L2Rpdj48ZGl2PlNvIC0gaWYgeW91
IHdhbnQgdGhpcywgeW91IHNob3VsZCBwdXQgZm9ydGggYSBob2xkZXIgb2Yga2V5IHByb2ZpbGlu
ZyBvZiB0aGlzIGRyYWZ0IGFuZCBzZWUgaWYgdGhlcmUgYXJlIGFueSBpc3N1ZXMuICZuYnNwOyBU
aGUgb25seSBwcm9maWxlcyB3ZSBoYXZlIHRodXMgZmFyIGFyZSBzYW1sIGFuZCBqd3QgYmVhcmVy
IGFzc2VydGlvbnMuICZuYnNwOzwvZGl2PjxkaXY+PGJyPjxicj4tIGNtb3J0PC9kaXY+PGRpdj48
YnI+T24gRGVjIDEzLCAyMDEyLCBhdCA2OjI3IFBNLCAiPGEgaHJlZj0ibWFpbHRvOnpob3Uuc3Vq
aW5nQHp0ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L2E+IiAmbHQ7PGEgaHJlZj0i
bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L2E+
Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+PGRpdj4NCjxicj48Zm9udCBzaXplPSIyIiBmYWNlPSJzYW5zLXNlcmlmIj5JIGFtIG5vdCBz
dXJlIGlmIHRoZSBmb2xsb3dpbmcgdXNlY2FzZQ0KJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5p
ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAyMzMuaHRtbCI+aHR0
cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAyMzMu
aHRtbDwvYT48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+Y291
bGQgYmUgc3VwcG9ydGVkIGJ5IGFzc2VydGlvbiBmcmFtZXdvcmvvvIw8L2ZvbnQ+DQo8YnI+PGZv
bnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+V2UgaGF2ZSBzb21lIGRpc2N1c3Npb24gaW4g
Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2VyaWYiPjxhIGhy
ZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21z
ZzEwMjAzLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9j
dXJyZW50L21zZzEwMjAzLmh0bWw8L2E+PC9mb250Pg0KPGJyPjxmb250IHNpemU9IjIiIGZhY2U9
InNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl
Yi9vYXV0aC9jdXJyZW50L21zZzEwMTk4Lmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h
cmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEwMTk4Lmh0bWw8L2E+DQo8L2ZvbnQ+DQo8YnI+
DQo8YnI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+SW4gbXkgdXNlIGNhc2Ugb3Ig
aW4gc29tZSBvdGhlciBjYXNlcywNCmFzc2VydGlvbnMgZG9uJ3QgbmVlZCBjb25maWRlbnRpYWwg
cHJvdGVjdGlvbiwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2VyaWYi
PmJhc2ljYWxseSBTVFMgZG9uJ3QgaGF2ZSB0byBhdXRoZW50aWNhdGUNCmEgY2xpZW50IGJlZm9y
ZSBpc3N1ZWluZyAiYXNzZXJ0aW9uIiwgaWYgaXQgY291bGQgYmUgY2FsbGVkIGFzc2VydGlvbg0K
aGVyZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJpZiI+
RXhhbXBsZSxJIHRydXN0IG15IGxheXdlciwgSSBtYXkgaXNzdWUNCmFuICJhc3NlcnRpb24iIHN0
YXRpbmcgZGVsZWdhdGlvbiBpbiBhZHZhbmNlLCBhbmQgc2VuZCB0byB0aGUNCmxhd3llciB3aGVu
IGl0IGlzIG5lZWRlZCw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0ic2Fucy1zZXJp
ZiI+aXQgY291bGQgYmUgSSBnaXZlIHRoZSBhc3NlcnRpb24gdG8NCmEgZmFsc2UgbGF3eWVyLCBi
dXQgaXQgZG9lcyBub3QgbWF0dGVyLCBiZWNhdXNlIHRoZSBsYXd5ZXIgaGFzIHRvIHByb3ZlDQpo
ZSBrbm93cyBzb21lIGNyZWRlbnRpYWwgY29ycmVzcG9uZGluZyB0byBoaXMgSUQsPC9mb250Pg0K
PGJyPjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2VyaWYiPndobyBpcyBkZWxlZ2F0ZWQgc29t
ZSByaWdodHMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9IjIiIGZhY2U9InNhbnMtc2Vy
aWYiPklmIGFzc2VydGlvbiBmcmFtZXdvcmsgd2FudCB0byBzdXBwb3J0DQp0aGlzIHVzZSBjYXNl
LCB0aGVuIGdlbmVyYXRpb24gb2YgYXNzZXJ0aW9uIHNob3VsZCBiZSByZWxheGVkLDwvZm9udD4N
Cjxicj48Zm9udCBzaXplPSIyIiBmYWNlPSJzYW5zLXNlcmlmIj5vdGhlcndpc2UgbmV3IHdvcmsg
aXMgcmVxdWlyZWQgdG8gc3VwcG9ydA0KdGhlIHVzZSBjYXNlLjwvZm9udD4NCjxicj4NCjxicj4N
Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+Q2h1Y2sgTW9ydGltb3JlICZsdDs8YSBocmVm
PSJtYWlsdG86Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbSI+Y21vcnRpbW9yZUBzYWxlc2ZvcmNl
LmNvbTwvYT4mZ3Q7DQrlhpnkuo4gMjAxMi0xMi0xNCAxMDowODozNDo8YnI+DQo8YnI+DQomZ3Q7
IE9uIERlYyAxMywgMjAxMiwgYXQgNDozMCBQTSwgIjxhIGhyZWY9Im1haWx0bzp6aG91LnN1amlu
Z0B6dGUuY29tLmNuIj56aG91LnN1amluZ0B6dGUuY29tLmNuPC9hPiIgJmx0OzxhIGhyZWY9Im1h
aWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIj56aG91LnN1amluZ0B6dGUuY29tLmNuPC9hPjxi
cj4NCiZndDsgJmd0OyB3cm90ZTo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0iMiI+Jmd0OyA8YnI+DQomZ3Q7IEZyb20gdGhlIGxhbmd1YWdlLCBJIGdvdCBhbiBpbXByZXNz
aW9uIHRoYXQgYXNzZXJ0aW9uIGlzIG9ubHkgPGJyPg0KJmd0OyBnZW5lcmF0ZWQgYnkgdG9rZW4g
c2VydmljZSBhZnRlciBjbGllbnRzIHByZXNlbnRpbmcgc29tZSBjcmVkZW50aWFscywNCjxicj4N
CiZndDsgdGhlcmUgYXJlIG1heSBiZSBzb21lIGNhc2VzIHRoYXQgImFzc2VydGlvbiIgZG9uJ3Qg
bmVlZA0KY2xpZW50J3MgY3JlZGVudGlhbC4gPGJyPg0KJmd0OyBlLmcuLCBSZXNvdXJjZSBvd25l
ciBhcyBhIHRva2VuIHNlcnZpY2UgJm5ic3A7Y291bGQgZ2VuZXJhdGUgImFzc2VydGlvbiINCjxi
cj4NCiZndDsgdG8gYSBjbGllbnQgaGUgdHJ1c3RzLCBidSBzaWduaW5nIGEgc3RhdGVtZW50IHRo
YXQgIlRoaXMgZGVsZWdhdGlvbg0KPGJyPg0KJmd0OyBpcyBnaXZlbiB0byBhIGNsaWVudCBjYWxs
ZWQgY2xpbmV0LWlkIDxicj4NCiZndDsgZm9yIGRvaW5nIHNvbWV0aGluZyBmb3IgbWUiLiA8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+Jmd0OyA8YnI+DQomZ3Q7IFNvIGhvdyBk
b2VzIHRoZSBTVFMgdHJ1c3QgdGhlIGNsaWVudD8gJm5ic3A7IFByZXN1bWFibHkgaWYgaXQgaXMg
dHJ1c3RlZA0KPGJyPg0KJmd0OyBpdCBoYXMgc29tZSBsZXZlbCBvZiBhdXRoZW50aWNhdGlvbiwg
eWVzPzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsg
LWNtb3J0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9IjIiPiZndDsgPGJyPg0KJmd0
OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENodWNrIE1vcnRp
bW9yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20iPmNtb3J0
aW1vcmVAc2FsZXNmb3JjZS5jb208L2E+Jmd0OyDlhpnkuo4gMjAxMi0xMi0xNA0KMDA6Mzk6MDM6
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIGxhbmd1YWdlIGlzIHNpbXBseSBtZWFudCB0
byBoZWxwIGlsbHVzdHJhdGUgaG93IHRoZSBmcmFtZXdvcmsNCjxicj4NCiZndDsgJmd0OyBtaWdo
dCBiZSB1c2VkLiAmbmJzcDsgSG93IGRvIHlvdSB0aGluayBpdCB3aWxsIHJlc3RyaWN0IHVzYWdl
Pw0KJm5ic3A7IEhvdyA8YnI+DQomZ3Q7ICZndDsgY291bGQgaXQgYmUgaW1wcm92ZWQ/IDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLWNtb3J0IDxicj4NCiZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgT24gRGVjIDEyLCAyMDEyLCBhdCAxMTowNCBQTSwgJmx0OzxhIGhyZWY9Im1haWx0
bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIj56aG91LnN1amluZ0B6dGUuY29tLmNuPC9hPiZndDsN
Cndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJ
biAic2VjdGlvbiAzIDxicj4NCiZndDsgJmd0OyAmbmJzcDtUaGUgdG9rZW4gc2VydmljZSBpcyB0
aGUgYXNzZXJ0aW9uIGlzc3VlcjsgaXRzIDxicj4NCiZndDsgJmd0OyAmbmJzcDtyb2xlIGlzIHRv
IGZ1bGZpbGwgcmVxdWVzdHMgZnJvbSBjbGllbnRzLCB3aGljaCBwcmVzZW50DQp2YXJpb3VzIDxi
cj4NCiZndDsgJmd0OyAmbmJzcDtjcmVkZW50aWFscywgYW5kIG1pbnQgYXNzZXJ0aW9ucyBhcyBy
ZXF1ZXN0ZWQsIGZpbGwgdGhlbQ0Kd2l0aCA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7YXBwcm9wcmlh
dGUgaW5mb3JtYXRpb24sIGFuZCBzaWduIHRoZW0uIiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBcyBJIHVuZGVyc3RhbmQsIGFuIGFzc2VydGlvbiBnZW5l
cmF0ZWQgYnkgYSBTVFMsIGlzIGRvbmUgZmxvbGxvd2luZzxicj4NCiZndDsgJmd0OyB0aGVzcyBz
dGVwczogPGJyPg0KJmd0OyAmZ3Q7IDEuIENsaWVudCBwcmVzZW50cyBjcmVkZW50aWFsIGFuZCBy
ZXF1ZXN0cyBhbiBhc3NlcnRpb24gPGJyPg0KJmd0OyAmZ3Q7IDIuIFNUUyBnZW5lcmF0ZXMgYXNz
ZXJ0aW9uIGFuZCBzZW5kcyB0byBDbGllbnQgPGJyPg0KJmd0OyAmZ3Q7IENvcnJlY3Q/IDxicj4N
CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhhdCBtYXkgcmVzdHJpY3QgdGhlIHVzZSBjYXNl
cyB0aGF0IHRoaXMgYXNzZXJ0aW9uIGZyYW1ld29yaw0KPGJyPg0KJmd0OyBjb3VsZCBzdXBwb3J0
LCA8YnI+DQomZ3Q7ICZndDsgaXMgaXQgYSBtdXN0PyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxh
IGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYu
b3JnPC9hPiDlhpnkuo4gMjAxMi0xMi0xMSAwMjozMzo1Nzo8YnI+DQomZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIElFU0cgaGFzIHJlY2VpdmVk
IGEgcmVxdWVzdCBmcm9tIHRoZSBXZWIgQXV0aG9yaXphdGlvbg0KUHJvdG9jb2wgV0c8YnI+DQom
Z3Q7ICZndDsgJmd0OyAob2F1dGgpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgLSAnQXNzZXJ0aW9uIEZyYW1ld29yayBmb3IgT0F1dGggMi4w
Jzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbHQ7ZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRp
b25zLTA4LnR4dCZndDsgYXMgUHJvcG9zZWQNClN0YW5kYXJkPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRlY2lzaW9uIGlu
IHRoZSBuZXh0IGZldyB3ZWVrcywNCmFuZCBzb2xpY2l0czxicj4NCiZndDsgJmd0OyAmZ3Q7IGZp
bmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBjb21t
ZW50cw0KdG8gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOmlldGZAaWV0
Zi5vcmciPmlldGZAaWV0Zi5vcmc8L2E+IG1haWxpbmcgbGlzdHMgYnkgMjAxMi0xMi0yNC4gRXhj
ZXB0aW9uYWxseSwNCmNvbW1lbnRzIG1heSBiZTxicj4NCiZndDsgJmd0OyAmZ3Q7IHNlbnQgdG8g
PGEgaHJlZj0ibWFpbHRvOmllc2dAaWV0Zi5vcmciPmllc2dAaWV0Zi5vcmc8L2E+IGluc3RlYWQu
IEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluDQp0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBi
ZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy48
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBYnN0cmFjdDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDtUaGlzIHNwZWNpZmljYXRpb24gcHJvdmlkZXMgYSBmcmFtZXdvcmsgZm9yDQp0
aGUgdXNlIG9mIGFzc2VydGlvbnM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7d2l0
aCBPQXV0aCAyLjAgaW4gdGhlIGZvcm0gb2YgYSBuZXcgY2xpZW50DQphdXRoZW50aWNhdGlvbiBt
ZWNoYW5pc208YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7YW5kIGEgbmV3IGF1dGhv
cml6YXRpb24gZ3JhbnQgdHlwZS4gJm5ic3A7TWVjaGFuaXNtcw0KYXJlIHNwZWNpZmllZCBmb3I8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dHJhbnNwb3J0aW5nIGFzc2VydGlvbnMg
ZHVyaW5nIGludGVyYWN0aW9ucw0Kd2l0aCBhIHRva2VuIGVuZHBvaW50LCBhczxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt3ZWxsIGFzIGdlbmVyYWwgcHJvY2Vzc2luZyBydWxlcy48
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7VGhl
IGludGVudCBvZiB0aGlzIHNwZWNpZmljYXRpb24gaXMgdG8gcHJvdmlkZQ0KYSBjb21tb24gZnJh
bWV3b3JrIGZvcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtPQXV0aCAyLjAgdG8g
aW50ZXJ3b3JrIHdpdGggb3RoZXIgaWRlbnRpdHkNCnN5c3RlbXMgdXNpbmcgYXNzZXJ0aW9ucyw8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7YW5kIHRvIHByb3ZpZGUgYWx0ZXJuYXRp
dmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uDQptZWNoYW5pc21zLjxicj4NCiZndDsgJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtOb3RlIHRoYXQgdGhpcyBzcGVjaWZp
Y2F0aW9uIG9ubHkgZGVmaW5lcyBhYnN0cmFjdA0KbWVzc2FnZSBmbG93cyBhbmQ8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cHJvY2Vzc2luZyBydWxlcy4gJm5ic3A7SW4gb3JkZXIg
dG8gYmUgaW1wbGVtZW50YWJsZSwNCmNvbXBhbmlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNw
OyAmbmJzcDtzcGVjaWZpY2F0aW9ucyBhcmUgbmVjZXNzYXJ5IHRvIHByb3ZpZGUgdGhlDQpjb3Jy
ZXNwb25kaW5nIGNvbmNyZXRlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2luc3Rh
bnRpYXRpb25zLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5lZCB2aWE8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVm
PSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0
aW9ucy8iPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1h
c3NlcnRpb25zLzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJ
RVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNrZWQgdmlhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEg
aHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFz
c2VydGlvbnMvYmFsbG90LyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p
ZXRmLW9hdXRoLWFzc2VydGlvbnMvYmFsbG90LzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBObyBJUFIgZGVjbGFyYXRpb25z
IGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcw0KSS1ELjxicj4NCiZndDsgJmd0
OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDsgJmd0
OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn
dDsgJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT4gPC9mb250PjwvdHQ+DQo8L2Rp
dj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4=

--_000_D6F62E8816564951A206FC6E20EBBAB5salesforcecom_--

From zhou.sujing@zte.com.cn  Thu Dec 13 18:40:05 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED7221F8A96; Thu, 13 Dec 2012 18:40:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.7
X-Spam-Level: 
X-Spam-Status: No, score=-97.7 tagged_above=-999 required=5 tests=[AWL=-0.327,  BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ziu89OEbk3vu; Thu, 13 Dec 2012 18:40:04 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 36CDB21F8929; Thu, 13 Dec 2012 18:39:52 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 7C8AA1243DCB; Fri, 14 Dec 2012 10:41:43 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qBE2dXrP046580; Fri, 14 Dec 2012 10:39:33 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Chuck Mortimore 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Fri, 14 Dec 2012 10:39:19 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-14 10:39:26, Serialize complete at 2012-12-14 10:39:26
Content-Type: multipart/alternative; boundary="=_alternative 000EB9D648257AD4_="
X-MAIL: mse01.zte.com.cn qBE2dXrP046580
Cc: "oauth-bounces@ietf.org" , "ietf@ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 02:40:05 -0000

This is a multipart message in MIME format.
--=_alternative 000EB9D648257AD4_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

T2gsIEJ1dCB0aGUgZGVzY3JpcHRpb24gb2YgYXNzZXJ0aW9uIGdlbmVyYXRpb24gaW4gdGhlIGRv
Y3VtZW50IHNob3VsZCBub3QgDQpiZSBsaW1pdGVkIGJ5IGJlYXIgYXNzZXJ0aW9uLCByaWdodD8N
Cg0KDQpDaHVjayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20+INC009ogMjAx
Mi0xMi0xNCAxMDozNDoxMzoNCg0KPiBZb3Ugd2FudCBhIGhvbGRlciBvZiBrZXkgcGF0dGVybi4g
IFRoZSBkcmFmdCB0b3VjaGVzIG9uIGl0DQo+IA0KPiANCj4gICAgVGhlIHByb3RvY29sIHBhcmFt
ZXRlcnMgYW5kIHByb2Nlc3NpbmcgcnVsZXMgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50DQo+ICAg
IGFyZSBpbnRlbmRlZCB0byBzdXBwb3J0IGEgY2xpZW50IHByZXNlbnRpbmcgYSBiZWFyZXIgYXNz
ZXJ0aW9uIHRvIGFuDQo+ICAgIGF1dGhvcml6YXRpb24gc2VydmVyLiAgVGhlIHVzZSBvZiBob2xk
ZXItb2Yta2V5IGFzc2VydGlvbnMgYXJlIG5vdA0KPiAgICBwcmVjbHVkZWQgYnkgdGhpcyBkb2N1
bWVudCwgYnV0IGFkZGl0aW9uYWwgcHJvdG9jb2wgZGV0YWlscyB3b3VsZA0KPiAgICBuZWVkIHRv
IGJlIHNwZWNpZmllZC4NCg0KPiANCj4gU28gLSBpZiB5b3Ugd2FudCB0aGlzLCB5b3Ugc2hvdWxk
IHB1dCBmb3J0aCBhIGhvbGRlciBvZiBrZXkgDQo+IHByb2ZpbGluZyBvZiB0aGlzIGRyYWZ0IGFu
ZCBzZWUgaWYgdGhlcmUgYXJlIGFueSBpc3N1ZXMuICAgVGhlIG9ubHkgDQo+IHByb2ZpbGVzIHdl
IGhhdmUgdGh1cyBmYXIgYXJlIHNhbWwgYW5kIGp3dCBiZWFyZXIgYXNzZXJ0aW9ucy4gDQo+IA0K
PiANCj4gLSBjbW9ydA0KPiANCj4gT24gRGVjIDEzLCAyMDEyLCBhdCA2OjI3IFBNLCAiemhvdS5z
dWppbmdAenRlLmNvbS5jbiIgDQo8emhvdS5zdWppbmdAenRlLmNvbS5jbg0KPiA+IHdyb3RlOg0K
DQo+IA0KPiBJIGFtIG5vdCBzdXJlIGlmIHRoZSBmb2xsb3dpbmcgdXNlY2FzZSAgaHR0cDovL3d3
dy5pZXRmLm9yZy9tYWlsLQ0KPiBhcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEwMjMzLmh0
bWwgDQo+IGNvdWxkIGJlIHN1cHBvcnRlZCBieSBhc3NlcnRpb24gZnJhbWV3b3Jro6wgDQo+IFdl
IGhhdmUgc29tZSBkaXNjdXNzaW9uIGluIA0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj
aGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMDIwMy5odG1sIA0KPiBodHRwOi8vd3d3LmlldGYu
b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMDE5OC5odG1sIA0KPiANCj4g
SW4gbXkgdXNlIGNhc2Ugb3IgaW4gc29tZSBvdGhlciBjYXNlcywgYXNzZXJ0aW9ucyBkb24ndCBu
ZWVkIA0KPiBjb25maWRlbnRpYWwgcHJvdGVjdGlvbiwgDQo+IGJhc2ljYWxseSBTVFMgZG9uJ3Qg
aGF2ZSB0byBhdXRoZW50aWNhdGUgYSBjbGllbnQgYmVmb3JlIGlzc3VlaW5nIA0KPiAiYXNzZXJ0
aW9uIiwgaWYgaXQgY291bGQgYmUgY2FsbGVkIGFzc2VydGlvbiBoZXJlLiANCj4gDQo+IEV4YW1w
bGUsSSB0cnVzdCBteSBsYXl3ZXIsIEkgbWF5IGlzc3VlIGFuICJhc3NlcnRpb24iIHN0YXRpbmcg
DQo+IGRlbGVnYXRpb24gaW4gYWR2YW5jZSwgYW5kIHNlbmQgdG8gdGhlIGxhd3llciB3aGVuIGl0
IGlzIG5lZWRlZCwgDQo+IGl0IGNvdWxkIGJlIEkgZ2l2ZSB0aGUgYXNzZXJ0aW9uIHRvIGEgZmFs
c2UgbGF3eWVyLCBidXQgaXQgZG9lcyBub3QgDQo+IG1hdHRlciwgYmVjYXVzZSB0aGUgbGF3eWVy
IGhhcyB0byBwcm92ZSBoZSBrbm93cyBzb21lIGNyZWRlbnRpYWwgDQo+IGNvcnJlc3BvbmRpbmcg
dG8gaGlzIElELCANCj4gd2hvIGlzIGRlbGVnYXRlZCBzb21lIHJpZ2h0cy4gDQo+IA0KPiBJZiBh
c3NlcnRpb24gZnJhbWV3b3JrIHdhbnQgdG8gc3VwcG9ydCB0aGlzIHVzZSBjYXNlLCB0aGVuIA0K
PiBnZW5lcmF0aW9uIG9mIGFzc2VydGlvbiBzaG91bGQgYmUgcmVsYXhlZCwgDQo+IG90aGVyd2lz
ZSBuZXcgd29yayBpcyByZXF1aXJlZCB0byBzdXBwb3J0IHRoZSB1c2UgY2FzZS4gDQo+IA0KPiAN
Cj4gDQo+IENodWNrIE1vcnRpbW9yZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbT4g0LTT2iAy
MDEyLTEyLTE0IDEwOjA4OjM0Og0KPiANCj4gPiBPbiBEZWMgMTMsIDIwMTIsIGF0IDQ6MzAgUE0s
ICJ6aG91LnN1amluZ0B6dGUuY29tLmNuIiA8emhvdS4NCj4gc3VqaW5nQHp0ZS5jb20uY24NCj4g
PiA+IHdyb3RlOg0KPiANCj4gPiANCj4gPiBGcm9tIHRoZSBsYW5ndWFnZSwgSSBnb3QgYW4gaW1w
cmVzc2lvbiB0aGF0IGFzc2VydGlvbiBpcyBvbmx5IA0KPiA+IGdlbmVyYXRlZCBieSB0b2tlbiBz
ZXJ2aWNlIGFmdGVyIGNsaWVudHMgcHJlc2VudGluZyBzb21lIGNyZWRlbnRpYWxzLCANCj4gPiB0
aGVyZSBhcmUgbWF5IGJlIHNvbWUgY2FzZXMgdGhhdCAiYXNzZXJ0aW9uIiBkb24ndCBuZWVkIGNs
aWVudCdzIA0KPiBjcmVkZW50aWFsLiANCj4gPiBlLmcuLCBSZXNvdXJjZSBvd25lciBhcyBhIHRv
a2VuIHNlcnZpY2UgIGNvdWxkIGdlbmVyYXRlICJhc3NlcnRpb24iIA0KPiA+IHRvIGEgY2xpZW50
IGhlIHRydXN0cywgYnUgc2lnbmluZyBhIHN0YXRlbWVudCB0aGF0ICJUaGlzIGRlbGVnYXRpb24g
DQo+ID4gaXMgZ2l2ZW4gdG8gYSBjbGllbnQgY2FsbGVkIGNsaW5ldC1pZCANCj4gPiBmb3IgZG9p
bmcgc29tZXRoaW5nIGZvciBtZSIuIA0KPiA+IA0KPiA+IFNvIGhvdyBkb2VzIHRoZSBTVFMgdHJ1
c3QgdGhlIGNsaWVudD8gICBQcmVzdW1hYmx5IGlmIGl0IGlzIHRydXN0ZWQgDQo+ID4gaXQgaGFz
IHNvbWUgbGV2ZWwgb2YgYXV0aGVudGljYXRpb24sIHllcz8gDQo+ID4gDQo+ID4gLWNtb3J0IA0K
PiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IENodWNrIE1vcnRpbW9yZSA8Y21vcnRp
bW9yZUBzYWxlc2ZvcmNlLmNvbT4g0LTT2iAyMDEyLTEyLTE0IDAwOjM5OjAzOg0KPiA+IA0KPiA+
ID4gVGhlIGxhbmd1YWdlIGlzIHNpbXBseSBtZWFudCB0byBoZWxwIGlsbHVzdHJhdGUgaG93IHRo
ZSBmcmFtZXdvcmsgDQo+ID4gPiBtaWdodCBiZSB1c2VkLiAgIEhvdyBkbyB5b3UgdGhpbmsgaXQg
d2lsbCByZXN0cmljdCB1c2FnZT8gICBIb3cgDQo+ID4gPiBjb3VsZCBpdCBiZSBpbXByb3ZlZD8g
DQo+ID4gPiANCj4gPiA+IC1jbW9ydCANCj4gPiA+IA0KPiA+ID4gT24gRGVjIDEyLCAyMDEyLCBh
dCAxMTowNCBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IHdyb3RlOiANCj4gPiA+IA0KPiA+
ID4gDQo+ID4gPiBJbiAic2VjdGlvbiAzIA0KPiA+ID4gIFRoZSB0b2tlbiBzZXJ2aWNlIGlzIHRo
ZSBhc3NlcnRpb24gaXNzdWVyOyBpdHMgDQo+ID4gPiAgcm9sZSBpcyB0byBmdWxmaWxsIHJlcXVl
c3RzIGZyb20gY2xpZW50cywgd2hpY2ggcHJlc2VudCB2YXJpb3VzIA0KPiA+ID4gIGNyZWRlbnRp
YWxzLCBhbmQgbWludCBhc3NlcnRpb25zIGFzIHJlcXVlc3RlZCwgZmlsbCB0aGVtIHdpdGggDQo+
ID4gPiAgYXBwcm9wcmlhdGUgaW5mb3JtYXRpb24sIGFuZCBzaWduIHRoZW0uIiANCj4gPiA+IA0K
PiA+ID4gDQo+ID4gPiBBcyBJIHVuZGVyc3RhbmQsIGFuIGFzc2VydGlvbiBnZW5lcmF0ZWQgYnkg
YSBTVFMsIGlzIGRvbmUgZmxvbGxvd2luZw0KPiA+ID4gdGhlc3Mgc3RlcHM6IA0KPiA+ID4gMS4g
Q2xpZW50IHByZXNlbnRzIGNyZWRlbnRpYWwgYW5kIHJlcXVlc3RzIGFuIGFzc2VydGlvbiANCj4g
PiA+IDIuIFNUUyBnZW5lcmF0ZXMgYXNzZXJ0aW9uIGFuZCBzZW5kcyB0byBDbGllbnQgDQo+ID4g
PiBDb3JyZWN0PyANCj4gPiA+IA0KPiA+ID4gVGhhdCBtYXkgcmVzdHJpY3QgdGhlIHVzZSBjYXNl
cyB0aGF0IHRoaXMgYXNzZXJ0aW9uIGZyYW1ld29yayANCj4gPiBjb3VsZCBzdXBwb3J0LCANCj4g
PiA+IGlzIGl0IGEgbXVzdD8gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+
IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTEyLTExIDAyOjMzOjU3Og0KPiA+ID4g
DQo+ID4gPiA+IA0KPiA+ID4gPiBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20g
dGhlIFdlYiBBdXRob3JpemF0aW9uIA0KUHJvdG9jb2wgV0cNCj4gPiA+ID4gKG9hdXRoKSB0byBj
b25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Og0KPiA+ID4gPiAtICdBc3NlcnRpb24gRnJh
bWV3b3JrIGZvciBPQXV0aCAyLjAnDQo+ID4gPiA+ICAgPGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0
aW9ucy0wOC50eHQ+IGFzIFByb3Bvc2VkIFN0YW5kYXJkDQo+ID4gPiA+IA0KPiA+ID4gPiBUaGUg
SUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQg
DQpzb2xpY2l0cw0KPiA+ID4gPiBmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNl
IHNlbmQgc3Vic3RhbnRpdmUgY29tbWVudHMgdG8gDQp0aGUNCj4gPiA+ID4gaWV0ZkBpZXRmLm9y
ZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTItMTItMjQuIEV4Y2VwdGlvbmFsbHksIA0KPiBjb21tZW50
cyBtYXkgYmUNCj4gPiA+ID4gc2VudCB0byBpZXNnQGlldGYub3JnIGluc3RlYWQuIEluIGVpdGhl
ciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KPiA+ID4gPiBiZWdpbm5pbmcgb2YgdGhlIFN1Ympl
Y3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCj4gPiA+ID4gDQo+ID4gPiA+IEFi
c3RyYWN0DQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gICAgVGhpcyBzcGVjaWZpY2F0aW9u
IHByb3ZpZGVzIGEgZnJhbWV3b3JrIGZvciB0aGUgdXNlIG9mIA0KYXNzZXJ0aW9ucw0KPiA+ID4g
PiAgICB3aXRoIE9BdXRoIDIuMCBpbiB0aGUgZm9ybSBvZiBhIG5ldyBjbGllbnQgYXV0aGVudGlj
YXRpb24gDQptZWNoYW5pc20NCj4gPiA+ID4gICAgYW5kIGEgbmV3IGF1dGhvcml6YXRpb24gZ3Jh
bnQgdHlwZS4gIE1lY2hhbmlzbXMgYXJlIHNwZWNpZmllZCANCmZvcg0KPiA+ID4gPiAgICB0cmFu
c3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zIHdpdGggYSB0b2tlbiANCmVu
ZHBvaW50LCBhcw0KPiA+ID4gPiAgICB3ZWxsIGFzIGdlbmVyYWwgcHJvY2Vzc2luZyBydWxlcy4N
Cj4gPiA+ID4gDQo+ID4gPiA+ICAgIFRoZSBpbnRlbnQgb2YgdGhpcyBzcGVjaWZpY2F0aW9uIGlz
IHRvIHByb3ZpZGUgYSBjb21tb24gDQpmcmFtZXdvcmsgZm9yDQo+ID4gPiA+ICAgIE9BdXRoIDIu
MCB0byBpbnRlcndvcmsgd2l0aCBvdGhlciBpZGVudGl0eSBzeXN0ZW1zIHVzaW5nIA0KYXNzZXJ0
aW9ucywNCj4gPiA+ID4gICAgYW5kIHRvIHByb3ZpZGUgYWx0ZXJuYXRpdmUgY2xpZW50IGF1dGhl
bnRpY2F0aW9uIG1lY2hhbmlzbXMuDQo+ID4gPiA+IA0KPiA+ID4gPiAgICBOb3RlIHRoYXQgdGhp
cyBzcGVjaWZpY2F0aW9uIG9ubHkgZGVmaW5lcyBhYnN0cmFjdCBtZXNzYWdlIA0KZmxvd3MgYW5k
DQo+ID4gPiA+ICAgIHByb2Nlc3NpbmcgcnVsZXMuICBJbiBvcmRlciB0byBiZSBpbXBsZW1lbnRh
YmxlLCBjb21wYW5pb24NCj4gPiA+ID4gICAgc3BlY2lmaWNhdGlvbnMgYXJlIG5lY2Vzc2FyeSB0
byBwcm92aWRlIHRoZSBjb3JyZXNwb25kaW5nIA0KY29uY3JldGUNCj4gPiA+ID4gICAgaW5zdGFu
dGlhdGlvbnMuDQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4g
PiBUaGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+ID4gPiA+IGh0dHA6Ly9kYXRhdHJhY2tl
ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLw0KPiA+ID4gPiANCj4g
PiA+ID4gSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPiA+ID4gPiANCmh0dHA6
Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zL2Jh
bGxvdC8NCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBObyBJUFIgZGVjbGFyYXRpb25zIGhh
dmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+ID4gPiA+IA0KPiA+ID4g
PiANCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiA+IE9BdXRoQGlldGYub3JnDQo+
ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4gPiA+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBP
QXV0aCBtYWlsaW5nIGxpc3QNCj4gPiA+IE9BdXRoQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIA0K
--=_alternative 000EB9D648257AD4_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9oLCBCdXQgdGhlIGRlc2NyaXB0
aW9uIG9mIGFzc2VydGlvbg0KZ2VuZXJhdGlvbiBpbiB0aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBi
ZSBsaW1pdGVkIGJ5IGJlYXIgYXNzZXJ0aW9uLCByaWdodD88L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8
YnI+PHR0Pjxmb250IHNpemU9Mj5DaHVjayBNb3J0aW1vcmUgJmx0O2Ntb3J0aW1vcmVAc2FsZXNm
b3JjZS5jb20mZ3Q7DQrQtNPaIDIwMTItMTItMTQgMTA6MzQ6MTM6PGJyPg0KPGJyPg0KJmd0OyBZ
b3Ugd2FudCBhIGhvbGRlciBvZiBrZXkgcGF0dGVybi4gJm5ic3A7VGhlIGRyYWZ0IHRvdWNoZXMg
b24gaXQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgcHJvdG9jb2wgcGFyYW1ldGVycyBhbmQgcHJvY2Vz
c2luZyBydWxlcyBkZWZpbmVkDQppbiB0aGlzIGRvY3VtZW50PGJyPg0KJmd0OyAmbmJzcDsgJm5i
c3A7YXJlIGludGVuZGVkIHRvIHN1cHBvcnQgYSBjbGllbnQgcHJlc2VudGluZyBhIGJlYXJlcg0K
YXNzZXJ0aW9uIHRvIGFuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YXV0aG9yaXphdGlvbiBzZXJ2
ZXIuICZuYnNwO1RoZSB1c2Ugb2YgaG9sZGVyLW9mLWtleQ0KYXNzZXJ0aW9ucyBhcmUgbm90PGJy
Pg0KJmd0OyAmbmJzcDsgJm5ic3A7cHJlY2x1ZGVkIGJ5IHRoaXMgZG9jdW1lbnQsIGJ1dCBhZGRp
dGlvbmFsIHByb3RvY29sIGRldGFpbHMNCndvdWxkPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7bmVl
ZCB0byBiZSBzcGVjaWZpZWQuPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgU28gLSBpZiB5b3Ugd2FudCB0aGlzLCB5b3Ugc2hvdWxkIHB1dCBm
b3J0aCBhIGhvbGRlciBvZiBrZXkgPGJyPg0KJmd0OyBwcm9maWxpbmcgb2YgdGhpcyBkcmFmdCBh
bmQgc2VlIGlmIHRoZXJlIGFyZSBhbnkgaXNzdWVzLiAmbmJzcDsgVGhlDQpvbmx5IDxicj4NCiZn
dDsgcHJvZmlsZXMgd2UgaGF2ZSB0aHVzIGZhciBhcmUgc2FtbCBhbmQgand0IGJlYXJlciBhc3Nl
cnRpb25zLiAmbmJzcDs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IC0gY21vcnQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0yPiZndDsgPGJyPg0KJmd0OyBPbiBEZWMgMTMsIDIwMTIsIGF0IDY6MjcgUE0sICZxdW90O3po
b3Uuc3VqaW5nQHp0ZS5jb20uY24mcXVvdDsgJmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY248YnI+
DQomZ3Q7ICZndDsgd3JvdGU6PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9
Mj4mZ3Q7IDxicj4NCiZndDsgSSBhbSBub3Qgc3VyZSBpZiB0aGUgZm9sbG93aW5nIHVzZWNhc2Ug
Jm5ic3A7aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLTxicj4NCiZndDsgYXJjaGl2ZS93ZWIvb2F1
dGgvY3VycmVudC9tc2cxMDIzMy5odG1sIDxicj4NCiZndDsgY291bGQgYmUgc3VwcG9ydGVkIGJ5
IGFzc2VydGlvbiBmcmFtZXdvcmujrCA8YnI+DQomZ3Q7IFdlIGhhdmUgc29tZSBkaXNjdXNzaW9u
IGluICZuYnNwOyA8YnI+DQomZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl
Yi9vYXV0aC9jdXJyZW50L21zZzEwMjAzLmh0bWwgPGJyPg0KJmd0OyBodHRwOi8vd3d3LmlldGYu
b3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMDE5OC5odG1sIDxicj4NCiZn
dDsgPGJyPg0KJmd0OyBJbiBteSB1c2UgY2FzZSBvciBpbiBzb21lIG90aGVyIGNhc2VzLCBhc3Nl
cnRpb25zIGRvbid0IG5lZWQgPGJyPg0KJmd0OyBjb25maWRlbnRpYWwgcHJvdGVjdGlvbiwgPGJy
Pg0KJmd0OyBiYXNpY2FsbHkgU1RTIGRvbid0IGhhdmUgdG8gYXV0aGVudGljYXRlIGEgY2xpZW50
IGJlZm9yZSBpc3N1ZWluZw0KPGJyPg0KJmd0OyAmcXVvdDthc3NlcnRpb24mcXVvdDssIGlmIGl0
IGNvdWxkIGJlIGNhbGxlZCBhc3NlcnRpb24gaGVyZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEV4
YW1wbGUsSSB0cnVzdCBteSBsYXl3ZXIsIEkgbWF5IGlzc3VlIGFuICZxdW90O2Fzc2VydGlvbiZx
dW90OyBzdGF0aW5nDQo8YnI+DQomZ3Q7IGRlbGVnYXRpb24gaW4gYWR2YW5jZSwgYW5kIHNlbmQg
dG8gdGhlIGxhd3llciB3aGVuIGl0IGlzIG5lZWRlZCwgPGJyPg0KJmd0OyBpdCBjb3VsZCBiZSBJ
IGdpdmUgdGhlIGFzc2VydGlvbiB0byBhIGZhbHNlIGxhd3llciwgYnV0IGl0IGRvZXMgbm90DQo8
YnI+DQomZ3Q7IG1hdHRlciwgYmVjYXVzZSB0aGUgbGF3eWVyIGhhcyB0byBwcm92ZSBoZSBrbm93
cyBzb21lIGNyZWRlbnRpYWwgPGJyPg0KJmd0OyBjb3JyZXNwb25kaW5nIHRvIGhpcyBJRCwgPGJy
Pg0KJmd0OyB3aG8gaXMgZGVsZWdhdGVkIHNvbWUgcmlnaHRzLiA8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgSWYgYXNzZXJ0aW9uIGZyYW1ld29yayB3YW50IHRvIHN1cHBvcnQgdGhpcyB1c2UgY2FzZSwg
dGhlbiA8YnI+DQomZ3Q7IGdlbmVyYXRpb24gb2YgYXNzZXJ0aW9uIHNob3VsZCBiZSByZWxheGVk
LCA8YnI+DQomZ3Q7IG90aGVyd2lzZSBuZXcgd29yayBpcyByZXF1aXJlZCB0byBzdXBwb3J0IHRo
ZSB1c2UgY2FzZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBD
aHVjayBNb3J0aW1vcmUgJmx0O2Ntb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20mZ3Q7INC009ogMjAx
Mi0xMi0xNA0KMTA6MDg6MzQ6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gRGVjIDEzLCAy
MDEyLCBhdCA0OjMwIFBNLCAmcXVvdDt6aG91LnN1amluZ0B6dGUuY29tLmNuJnF1b3Q7DQombHQ7
emhvdS48YnI+DQomZ3Q7IHN1amluZ0B6dGUuY29tLmNuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgd3Jv
dGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEZyb20gdGhlIGxh
bmd1YWdlLCBJIGdvdCBhbiBpbXByZXNzaW9uIHRoYXQgYXNzZXJ0aW9uIGlzIG9ubHkNCjxicj4N
CiZndDsgJmd0OyBnZW5lcmF0ZWQgYnkgdG9rZW4gc2VydmljZSBhZnRlciBjbGllbnRzIHByZXNl
bnRpbmcgc29tZSBjcmVkZW50aWFscywNCjxicj4NCiZndDsgJmd0OyB0aGVyZSBhcmUgbWF5IGJl
IHNvbWUgY2FzZXMgdGhhdCAmcXVvdDthc3NlcnRpb24mcXVvdDsgZG9uJ3QNCm5lZWQgY2xpZW50
J3MgPGJyPg0KJmd0OyBjcmVkZW50aWFsLiA8YnI+DQomZ3Q7ICZndDsgZS5nLiwgUmVzb3VyY2Ug
b3duZXIgYXMgYSB0b2tlbiBzZXJ2aWNlICZuYnNwO2NvdWxkIGdlbmVyYXRlDQomcXVvdDthc3Nl
cnRpb24mcXVvdDsgPGJyPg0KJmd0OyAmZ3Q7IHRvIGEgY2xpZW50IGhlIHRydXN0cywgYnUgc2ln
bmluZyBhIHN0YXRlbWVudCB0aGF0ICZxdW90O1RoaXMNCmRlbGVnYXRpb24gPGJyPg0KJmd0OyAm
Z3Q7IGlzIGdpdmVuIHRvIGEgY2xpZW50IGNhbGxlZCBjbGluZXQtaWQgPGJyPg0KJmd0OyAmZ3Q7
IGZvciBkb2luZyBzb21ldGhpbmcgZm9yIG1lJnF1b3Q7LiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7IFNvIGhvdyBkb2VzIHRoZSBTVFMgdHJ1c3QgdGhlIGNsaWVudD8gJm5ic3A7IFBy
ZXN1bWFibHkgaWYgaXQNCmlzIHRydXN0ZWQgPGJyPg0KJmd0OyAmZ3Q7IGl0IGhhcyBzb21lIGxl
dmVsIG9mIGF1dGhlbnRpY2F0aW9uLCB5ZXM/IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgLWNtb3J0IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IENodWNrIE1v
cnRpbW9yZSAmbHQ7Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbSZndDsg0LTT2iAyMDEyLTEyLTE0
DQowMDozOTowMzo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhlIGxhbmd1
YWdlIGlzIHNpbXBseSBtZWFudCB0byBoZWxwIGlsbHVzdHJhdGUgaG93IHRoZQ0KZnJhbWV3b3Jr
IDxicj4NCiZndDsgJmd0OyAmZ3Q7IG1pZ2h0IGJlIHVzZWQuICZuYnNwOyBIb3cgZG8geW91IHRo
aW5rIGl0IHdpbGwgcmVzdHJpY3QNCnVzYWdlPyAmbmJzcDsgSG93IDxicj4NCiZndDsgJmd0OyAm
Z3Q7IGNvdWxkIGl0IGJlIGltcHJvdmVkPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7
ICZndDsgJmd0OyAtY21vcnQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgT24gRGVjIDEyLCAyMDEyLCBhdCAxMTowNCBQTSwgJmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20u
Y24mZ3Q7DQp3cm90ZTogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSW4gJnF1b3Q7c2VjdGlvbiAzIDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZuYnNwO1RoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24gaXNzdWVyOyBpdHMg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7cm9sZSBpcyB0byBmdWxmaWxsIHJlcXVlc3RzIGZy
b20gY2xpZW50cywgd2hpY2ggcHJlc2VudA0KdmFyaW91cyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
bmJzcDtjcmVkZW50aWFscywgYW5kIG1pbnQgYXNzZXJ0aW9ucyBhcyByZXF1ZXN0ZWQsIGZpbGwN
CnRoZW0gd2l0aCA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDthcHByb3ByaWF0ZSBpbmZvcm1h
dGlvbiwgYW5kIHNpZ24gdGhlbS4mcXVvdDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXMgSSB1bmRlcnN0YW5kLCBhbiBhc3Nl
cnRpb24gZ2VuZXJhdGVkIGJ5IGEgU1RTLCBpcyBkb25lDQpmbG9sbG93aW5nPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgdGhlc3Mgc3RlcHM6IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDEuIENsaWVudCBwcmVz
ZW50cyBjcmVkZW50aWFsIGFuZCByZXF1ZXN0cyBhbiBhc3NlcnRpb24NCjxicj4NCiZndDsgJmd0
OyAmZ3Q7IDIuIFNUUyBnZW5lcmF0ZXMgYXNzZXJ0aW9uIGFuZCBzZW5kcyB0byBDbGllbnQgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgQ29ycmVjdD8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgVGhhdCBtYXkgcmVzdHJpY3QgdGhlIHVzZSBjYXNlcyB0aGF0IHRoaXMgYXNz
ZXJ0aW9uIGZyYW1ld29yaw0KPGJyPg0KJmd0OyAmZ3Q7IGNvdWxkIHN1cHBvcnQsIDxicj4NCiZn
dDsgJmd0OyAmZ3Q7IGlzIGl0IGEgbXVzdD8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgb2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTItMTItMTEg
MDI6MzM6NTc6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBJRVNHIGhhcyByZWNlaXZlZCBhIHJlcXVlc3Qg
ZnJvbSB0aGUgV2ViIEF1dGhvcml6YXRpb24NClByb3RvY29sIFdHPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAob2F1dGgpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyAtICdBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAn
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJmx0O2RyYWZ0LWlldGYtb2F1dGgtYXNz
ZXJ0aW9ucy0wOC50eHQmZ3Q7IGFzDQpQcm9wb3NlZCBTdGFuZGFyZDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgSUVTRyBwbGFucyB0byBtYWtl
IGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLA0KYW5kIHNvbGljaXRzPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgJmd0OyBmaW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNl
bmQgc3Vic3RhbnRpdmUNCmNvbW1lbnRzIHRvIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
aWV0ZkBpZXRmLm9yZyBtYWlsaW5nIGxpc3RzIGJ5IDIwMTItMTItMjQuIEV4Y2VwdGlvbmFsbHks
DQo8YnI+DQomZ3Q7IGNvbW1lbnRzIG1heSBiZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc2Vu
dCB0byBpZXNnQGlldGYub3JnIGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UNCnJldGFp
biB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBs
aW5lIHRvIGFsbG93IGF1dG9tYXRlZCBzb3J0aW5nLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBBYnN0cmFjdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDtUaGlzIHNwZWNpZmljYXRpb24gcHJvdmlkZXMgYSBmcmFtZXdvcmsNCmZvciB0
aGUgdXNlIG9mIGFzc2VydGlvbnM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDt3aXRoIE9BdXRoIDIuMCBpbiB0aGUgZm9ybSBvZiBhIG5ldyBjbGllbnQNCmF1dGhlbnRpY2F0
aW9uIG1lY2hhbmlzbTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2FuZCBh
IG5ldyBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUuICZuYnNwO01lY2hhbmlzbXMNCmFyZSBzcGVj
aWZpZWQgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7dHJhbnNwb3J0
aW5nIGFzc2VydGlvbnMgZHVyaW5nIGludGVyYWN0aW9ucw0Kd2l0aCBhIHRva2VuIGVuZHBvaW50
LCBhczxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3dlbGwgYXMgZ2VuZXJh
bCBwcm9jZXNzaW5nIHJ1bGVzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7VGhlIGludGVudCBvZiB0aGlzIHNwZWNpZmljYXRp
b24gaXMgdG8NCnByb3ZpZGUgYSBjb21tb24gZnJhbWV3b3JrIGZvcjxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO09BdXRoIDIuMCB0byBpbnRlcndvcmsgd2l0aCBvdGhlciBp
ZGVudGl0eQ0Kc3lzdGVtcyB1c2luZyBhc3NlcnRpb25zLDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJm5ic3A7ICZuYnNwO2FuZCB0byBwcm92aWRlIGFsdGVybmF0aXZlIGNsaWVudCBhdXRoZW50
aWNhdGlvbg0KbWVjaGFuaXNtcy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO05vdGUgdGhhdCB0aGlzIHNwZWNpZmljYXRpb24g
b25seSBkZWZpbmVzDQphYnN0cmFjdCBtZXNzYWdlIGZsb3dzIGFuZDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO3Byb2Nlc3NpbmcgcnVsZXMuICZuYnNwO0luIG9yZGVyIHRv
IGJlDQppbXBsZW1lbnRhYmxlLCBjb21wYW5pb248YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZu
YnNwOyAmbmJzcDtzcGVjaWZpY2F0aW9ucyBhcmUgbmVjZXNzYXJ5IHRvIHByb3ZpZGUNCnRoZSBj
b3JyZXNwb25kaW5nIGNvbmNyZXRlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5i
c3A7aW5zdGFudGlhdGlvbnMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IFRoZSBmaWxlIGNhbiBiZSBvYnRhaW5l
ZCB2aWE8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJRVNHIGRpc2N1c3Npb24gY2FuIGJlIHRyYWNr
ZWQgdmlhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v
cmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy9iYWxsb3QvPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5IG9u
DQp0aGlzIEktRC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFp
bGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aDxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgT0F1dGhAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIDwvZm9udD48L3R0Pg0K
--=_alternative 000EB9D648257AD4_=--

From cmortimore@salesforce.com  Thu Dec 13 18:44:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5146921F8B11; Thu, 13 Dec 2012 18:44:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.008
X-Spam-Level: 
X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3HBadGCCl-U; Thu, 13 Dec 2012 18:44:07 -0800 (PST)
Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by ietfa.amsl.com (Postfix) with SMTP id E2ED821F8AF1; Thu, 13 Dec 2012 18:44:06 -0800 (PST)
Received: from exsfm-hub3.internal.salesforce.com ([204.14.239.238]) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKUMqSdqYutAjUgQ2xPzWnQ85OESLVrfk1@postini.com; Thu, 13 Dec 2012 18:44:07 PST
Received: from EXSFM-MB03.internal.salesforce.com ([10.1.127.58]) by exsfm-hub3.internal.salesforce.com ([10.1.127.7]) with mapi; Thu, 13 Dec 2012 18:44:06 -0800
From: Chuck Mortimore 
To: "zhou.sujing@zte.com.cn" 
Date: Thu, 13 Dec 2012 18:44:05 -0800
Thread-Topic: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
Thread-Index: Ac3ZpOJpkTur59oCT1mDawjYT6PI8w==
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_D0292BEDC6D84B569BBE6C280F38BC42salesforcecom_"
MIME-Version: 1.0
Cc: "oauth-bounces@ietf.org" , "ietf@ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 02:44:08 -0000

--_000_D0292BEDC6D84B569BBE6C280F38BC42salesforcecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q29ycmVjdC4gICBUaGF0IHNhaWQgbm8gb25lIGhhcyB5ZXQgcHJvZmlsZWQgaXQgZm9yIGhvbGRl
ciBvZiBrZXkNCg0KLSBjbW9ydA0KDQpPbiBEZWMgMTMsIDIwMTIsIGF0IDY6MzkgUE0sICJ6aG91
LnN1amluZ0B6dGUuY29tLmNuPG1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuPiIgPHpob3Uu
c3VqaW5nQHp0ZS5jb20uY248bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24+PiB3cm90ZToN
Cg0KDQpPaCwgQnV0IHRoZSBkZXNjcmlwdGlvbiBvZiBhc3NlcnRpb24gZ2VuZXJhdGlvbiBpbiB0
aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBsaW1pdGVkIGJ5IGJlYXIgYXNzZXJ0aW9uLCByaWdo
dD8NCg0KDQpDaHVjayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208bWFpbHRv
OmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb20+PiDlhpnkuo4gMjAxMi0xMi0xNCAxMDozNDoxMzoN
Cg0KPiBZb3Ugd2FudCBhIGhvbGRlciBvZiBrZXkgcGF0dGVybi4gIFRoZSBkcmFmdCB0b3VjaGVz
IG9uIGl0DQo+DQo+DQo+ICAgIFRoZSBwcm90b2NvbCBwYXJhbWV0ZXJzIGFuZCBwcm9jZXNzaW5n
IHJ1bGVzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudA0KPiAgICBhcmUgaW50ZW5kZWQgdG8gc3Vw
cG9ydCBhIGNsaWVudCBwcmVzZW50aW5nIGEgYmVhcmVyIGFzc2VydGlvbiB0byBhbg0KPiAgICBh
dXRob3JpemF0aW9uIHNlcnZlci4gIFRoZSB1c2Ugb2YgaG9sZGVyLW9mLWtleSBhc3NlcnRpb25z
IGFyZSBub3QNCj4gICAgcHJlY2x1ZGVkIGJ5IHRoaXMgZG9jdW1lbnQsIGJ1dCBhZGRpdGlvbmFs
IHByb3RvY29sIGRldGFpbHMgd291bGQNCj4gICAgbmVlZCB0byBiZSBzcGVjaWZpZWQuDQoNCj4N
Cj4gU28gLSBpZiB5b3Ugd2FudCB0aGlzLCB5b3Ugc2hvdWxkIHB1dCBmb3J0aCBhIGhvbGRlciBv
ZiBrZXkNCj4gcHJvZmlsaW5nIG9mIHRoaXMgZHJhZnQgYW5kIHNlZSBpZiB0aGVyZSBhcmUgYW55
IGlzc3Vlcy4gICBUaGUgb25seQ0KPiBwcm9maWxlcyB3ZSBoYXZlIHRodXMgZmFyIGFyZSBzYW1s
IGFuZCBqd3QgYmVhcmVyIGFzc2VydGlvbnMuDQo+DQo+DQo+IC0gY21vcnQNCj4NCj4gT24gRGVj
IDEzLCAyMDEyLCBhdCA2OjI3IFBNLCAiemhvdS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhv
dS5zdWppbmdAenRlLmNvbS5jbj4iIDx6aG91LnN1amluZ0B6dGUuY29tLmNuPG1haWx0bzp6aG91
LnN1amluZ0B6dGUuY29tLmNuPg0KPiA+IHdyb3RlOg0KDQo+DQo+IEkgYW0gbm90IHN1cmUgaWYg
dGhlIGZvbGxvd2luZyB1c2VjYXNlICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+IGFyY2hp
dmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAyMzMuaHRtbA0KPiBjb3VsZCBiZSBzdXBwb3J0ZWQg
YnkgYXNzZXJ0aW9uIGZyYW1ld29ya++8jA0KPiBXZSBoYXZlIHNvbWUgZGlzY3Vzc2lvbiBpbg0K
PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cx
MDIwMy5odG1sDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9j
dXJyZW50L21zZzEwMTk4Lmh0bWwNCj4NCj4gSW4gbXkgdXNlIGNhc2Ugb3IgaW4gc29tZSBvdGhl
ciBjYXNlcywgYXNzZXJ0aW9ucyBkb24ndCBuZWVkDQo+IGNvbmZpZGVudGlhbCBwcm90ZWN0aW9u
LA0KPiBiYXNpY2FsbHkgU1RTIGRvbid0IGhhdmUgdG8gYXV0aGVudGljYXRlIGEgY2xpZW50IGJl
Zm9yZSBpc3N1ZWluZw0KPiAiYXNzZXJ0aW9uIiwgaWYgaXQgY291bGQgYmUgY2FsbGVkIGFzc2Vy
dGlvbiBoZXJlLg0KPg0KPiBFeGFtcGxlLEkgdHJ1c3QgbXkgbGF5d2VyLCBJIG1heSBpc3N1ZSBh
biAiYXNzZXJ0aW9uIiBzdGF0aW5nDQo+IGRlbGVnYXRpb24gaW4gYWR2YW5jZSwgYW5kIHNlbmQg
dG8gdGhlIGxhd3llciB3aGVuIGl0IGlzIG5lZWRlZCwNCj4gaXQgY291bGQgYmUgSSBnaXZlIHRo
ZSBhc3NlcnRpb24gdG8gYSBmYWxzZSBsYXd5ZXIsIGJ1dCBpdCBkb2VzIG5vdA0KPiBtYXR0ZXIs
IGJlY2F1c2UgdGhlIGxhd3llciBoYXMgdG8gcHJvdmUgaGUga25vd3Mgc29tZSBjcmVkZW50aWFs
DQo+IGNvcnJlc3BvbmRpbmcgdG8gaGlzIElELA0KPiB3aG8gaXMgZGVsZWdhdGVkIHNvbWUgcmln
aHRzLg0KPg0KPiBJZiBhc3NlcnRpb24gZnJhbWV3b3JrIHdhbnQgdG8gc3VwcG9ydCB0aGlzIHVz
ZSBjYXNlLCB0aGVuDQo+IGdlbmVyYXRpb24gb2YgYXNzZXJ0aW9uIHNob3VsZCBiZSByZWxheGVk
LA0KPiBvdGhlcndpc2UgbmV3IHdvcmsgaXMgcmVxdWlyZWQgdG8gc3VwcG9ydCB0aGUgdXNlIGNh
c2UuDQo+DQo+DQo+DQo+IENodWNrIE1vcnRpbW9yZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNv
bTxtYWlsdG86Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbT4+IOWGmeS6jiAyMDEyLTEyLTE0IDEw
OjA4OjM0Og0KPg0KPiA+IE9uIERlYyAxMywgMjAxMiwgYXQgNDozMCBQTSwgInpob3Uuc3VqaW5n
QHp0ZS5jb20uY248bWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24+IiA8emhvdS4NCj4gc3Vq
aW5nQHp0ZS5jb20uY248bWFpbHRvOnN1amluZ0B6dGUuY29tLmNuPg0KPiA+ID4gd3JvdGU6DQo+
DQo+ID4NCj4gPiBGcm9tIHRoZSBsYW5ndWFnZSwgSSBnb3QgYW4gaW1wcmVzc2lvbiB0aGF0IGFz
c2VydGlvbiBpcyBvbmx5DQo+ID4gZ2VuZXJhdGVkIGJ5IHRva2VuIHNlcnZpY2UgYWZ0ZXIgY2xp
ZW50cyBwcmVzZW50aW5nIHNvbWUgY3JlZGVudGlhbHMsDQo+ID4gdGhlcmUgYXJlIG1heSBiZSBz
b21lIGNhc2VzIHRoYXQgImFzc2VydGlvbiIgZG9uJ3QgbmVlZCBjbGllbnQncw0KPiBjcmVkZW50
aWFsLg0KPiA+IGUuZy4sIFJlc291cmNlIG93bmVyIGFzIGEgdG9rZW4gc2VydmljZSAgY291bGQg
Z2VuZXJhdGUgImFzc2VydGlvbiINCj4gPiB0byBhIGNsaWVudCBoZSB0cnVzdHMsIGJ1IHNpZ25p
bmcgYSBzdGF0ZW1lbnQgdGhhdCAiVGhpcyBkZWxlZ2F0aW9uDQo+ID4gaXMgZ2l2ZW4gdG8gYSBj
bGllbnQgY2FsbGVkIGNsaW5ldC1pZA0KPiA+IGZvciBkb2luZyBzb21ldGhpbmcgZm9yIG1lIi4N
Cj4gPg0KPiA+IFNvIGhvdyBkb2VzIHRoZSBTVFMgdHJ1c3QgdGhlIGNsaWVudD8gICBQcmVzdW1h
Ymx5IGlmIGl0IGlzIHRydXN0ZWQNCj4gPiBpdCBoYXMgc29tZSBsZXZlbCBvZiBhdXRoZW50aWNh
dGlvbiwgeWVzPw0KPiA+DQo+ID4gLWNtb3J0DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+
IENodWNrIE1vcnRpbW9yZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbTxtYWlsdG86Y21vcnRp
bW9yZUBzYWxlc2ZvcmNlLmNvbT4+IOWGmeS6jiAyMDEyLTEyLTE0IDAwOjM5OjAzOg0KPiA+DQo+
ID4gPiBUaGUgbGFuZ3VhZ2UgaXMgc2ltcGx5IG1lYW50IHRvIGhlbHAgaWxsdXN0cmF0ZSBob3cg
dGhlIGZyYW1ld29yaw0KPiA+ID4gbWlnaHQgYmUgdXNlZC4gICBIb3cgZG8geW91IHRoaW5rIGl0
IHdpbGwgcmVzdHJpY3QgdXNhZ2U/ICAgSG93DQo+ID4gPiBjb3VsZCBpdCBiZSBpbXByb3ZlZD8N
Cj4gPiA+DQo+ID4gPiAtY21vcnQNCj4gPiA+DQo+ID4gPiBPbiBEZWMgMTIsIDIwMTIsIGF0IDEx
OjA0IFBNLCA8emhvdS5zdWppbmdAenRlLmNvbS5jbjxtYWlsdG86emhvdS5zdWppbmdAenRlLmNv
bS5jbj4+IHdyb3RlOg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBJbiAic2VjdGlvbiAzDQo+ID4gPiAg
VGhlIHRva2VuIHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbiBpc3N1ZXI7IGl0cw0KPiA+ID4gIHJv
bGUgaXMgdG8gZnVsZmlsbCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoIHByZXNlbnQgdmFy
aW91cw0KPiA+ID4gIGNyZWRlbnRpYWxzLCBhbmQgbWludCBhc3NlcnRpb25zIGFzIHJlcXVlc3Rl
ZCwgZmlsbCB0aGVtIHdpdGgNCj4gPiA+ICBhcHByb3ByaWF0ZSBpbmZvcm1hdGlvbiwgYW5kIHNp
Z24gdGhlbS4iDQo+ID4gPg0KPiA+ID4NCj4gPiA+IEFzIEkgdW5kZXJzdGFuZCwgYW4gYXNzZXJ0
aW9uIGdlbmVyYXRlZCBieSBhIFNUUywgaXMgZG9uZSBmbG9sbG93aW5nDQo+ID4gPiB0aGVzcyBz
dGVwczoNCj4gPiA+IDEuIENsaWVudCBwcmVzZW50cyBjcmVkZW50aWFsIGFuZCByZXF1ZXN0cyBh
biBhc3NlcnRpb24NCj4gPiA+IDIuIFNUUyBnZW5lcmF0ZXMgYXNzZXJ0aW9uIGFuZCBzZW5kcyB0
byBDbGllbnQNCj4gPiA+IENvcnJlY3Q/DQo+ID4gPg0KPiA+ID4gVGhhdCBtYXkgcmVzdHJpY3Qg
dGhlIHVzZSBjYXNlcyB0aGF0IHRoaXMgYXNzZXJ0aW9uIGZyYW1ld29yaw0KPiA+IGNvdWxkIHN1
cHBvcnQsDQo+ID4gPiBpcyBpdCBhIG11c3Q/DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0K
PiA+ID4gb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9y
Zz4g5YaZ5LqOIDIwMTItMTItMTEgMDI6MzM6NTc6DQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPiBU
aGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIFdlYiBBdXRob3JpemF0aW9u
IFByb3RvY29sIFdHDQo+ID4gPiA+IChvYXV0aCkgdG8gY29uc2lkZXIgdGhlIGZvbGxvd2luZyBk
b2N1bWVudDoNCj4gPiA+ID4gLSAnQXNzZXJ0aW9uIEZyYW1ld29yayBmb3IgT0F1dGggMi4wJw0K
PiA+ID4gPiAgIDxkcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMtMDgudHh0PiBhcyBQcm9wb3Nl
ZCBTdGFuZGFyZA0KPiA+ID4gPg0KPiA+ID4gPiBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEgZGVj
aXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQgc29saWNpdHMNCj4gPiA+ID4gZmluYWwg
Y29tbWVudHMgb24gdGhpcyBhY3Rpb24uIFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlIGNvbW1lbnRz
IHRvIHRoZQ0KPiA+ID4gPiBpZXRmQGlldGYub3JnPG1haWx0bzppZXRmQGlldGYub3JnPiBtYWls
aW5nIGxpc3RzIGJ5IDIwMTItMTItMjQuIEV4Y2VwdGlvbmFsbHksDQo+IGNvbW1lbnRzIG1heSBi
ZQ0KPiA+ID4gPiBzZW50IHRvIGllc2dAaWV0Zi5vcmc8bWFpbHRvOmllc2dAaWV0Zi5vcmc+IGlu
c3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2UgcmV0YWluIHRoZQ0KPiA+ID4gPiBiZWdpbm5p
bmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGluZy4NCj4gPiA+
ID4NCj4gPiA+ID4gQWJzdHJhY3QNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4gICAgVGhpcyBz
cGVjaWZpY2F0aW9uIHByb3ZpZGVzIGEgZnJhbWV3b3JrIGZvciB0aGUgdXNlIG9mIGFzc2VydGlv
bnMNCj4gPiA+ID4gICAgd2l0aCBPQXV0aCAyLjAgaW4gdGhlIGZvcm0gb2YgYSBuZXcgY2xpZW50
IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbQ0KPiA+ID4gPiAgICBhbmQgYSBuZXcgYXV0aG9yaXph
dGlvbiBncmFudCB0eXBlLiAgTWVjaGFuaXNtcyBhcmUgc3BlY2lmaWVkIGZvcg0KPiA+ID4gPiAg
ICB0cmFuc3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zIHdpdGggYSB0b2tl
biBlbmRwb2ludCwgYXMNCj4gPiA+ID4gICAgd2VsbCBhcyBnZW5lcmFsIHByb2Nlc3NpbmcgcnVs
ZXMuDQo+ID4gPiA+DQo+ID4gPiA+ICAgIFRoZSBpbnRlbnQgb2YgdGhpcyBzcGVjaWZpY2F0aW9u
IGlzIHRvIHByb3ZpZGUgYSBjb21tb24gZnJhbWV3b3JrIGZvcg0KPiA+ID4gPiAgICBPQXV0aCAy
LjAgdG8gaW50ZXJ3b3JrIHdpdGggb3RoZXIgaWRlbnRpdHkgc3lzdGVtcyB1c2luZyBhc3NlcnRp
b25zLA0KPiA+ID4gPiAgICBhbmQgdG8gcHJvdmlkZSBhbHRlcm5hdGl2ZSBjbGllbnQgYXV0aGVu
dGljYXRpb24gbWVjaGFuaXNtcy4NCj4gPiA+ID4NCj4gPiA+ID4gICAgTm90ZSB0aGF0IHRoaXMg
c3BlY2lmaWNhdGlvbiBvbmx5IGRlZmluZXMgYWJzdHJhY3QgbWVzc2FnZSBmbG93cyBhbmQNCj4g
PiA+ID4gICAgcHJvY2Vzc2luZyBydWxlcy4gIEluIG9yZGVyIHRvIGJlIGltcGxlbWVudGFibGUs
IGNvbXBhbmlvbg0KPiA+ID4gPiAgICBzcGVjaWZpY2F0aW9ucyBhcmUgbmVjZXNzYXJ5IHRvIHBy
b3ZpZGUgdGhlIGNvcnJlc3BvbmRpbmcgY29uY3JldGUNCj4gPiA+ID4gICAgaW5zdGFudGlhdGlv
bnMuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBmaWxl
IGNhbiBiZSBvYnRhaW5lZCB2aWENCj4gPiA+ID4gaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn
L2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMvDQo+ID4gPiA+DQo+ID4gPiA+IElFU0cg
ZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWENCj4gPiA+ID4gaHR0cDovL2RhdGF0cmFja2Vy
LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlvbnMvYmFsbG90Lw0KPiA+ID4g
Pg0KPiA+ID4gPg0KPiA+ID4gPiBObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0
ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+IE9BdXRo
IG1haWxpbmcgbGlzdA0KPiA+ID4gPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v
cmc+DQo+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgN
Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
ID4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiA+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4NCj4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCg==

--_000_D0292BEDC6D84B569BBE6C280F38BC42salesforcecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+Q29ycmVjdC4g
Jm5ic3A7IFRoYXQgc2FpZCBubyBvbmUgaGFzIHlldCBwcm9maWxlZCBpdCBmb3IgaG9sZGVyIG9m
IGtleTxicj48YnI+LSBjbW9ydDwvZGl2PjxkaXY+PGJyPk9uIERlYyAxMywgMjAxMiwgYXQgNjoz
OSBQTSwgIjxhIGhyZWY9Im1haWx0bzp6aG91LnN1amluZ0B6dGUuY29tLmNuIj56aG91LnN1amlu
Z0B6dGUuY29tLmNuPC9hPiIgJmx0OzxhIGhyZWY9Im1haWx0bzp6aG91LnN1amluZ0B6dGUuY29t
LmNuIj56aG91LnN1amluZ0B6dGUuY29tLmNuPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48
ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+DQo8YnI+PGZvbnQgc2l6ZT0i
MiIgZmFjZT0ic2Fucy1zZXJpZiI+T2gsIEJ1dCB0aGUgZGVzY3JpcHRpb24gb2YgYXNzZXJ0aW9u
DQpnZW5lcmF0aW9uIGluIHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGxpbWl0ZWQgYnkgYmVh
ciBhc3NlcnRpb24sIHJpZ2h0PzwvZm9udD4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6
ZT0iMiI+Q2h1Y2sgTW9ydGltb3JlICZsdDs8YSBocmVmPSJtYWlsdG86Y21vcnRpbW9yZUBzYWxl
c2ZvcmNlLmNvbSI+Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbTwvYT4mZ3Q7DQrlhpnkuo4gMjAx
Mi0xMi0xNCAxMDozNDoxMzo8YnI+DQo8YnI+DQomZ3Q7IFlvdSB3YW50IGEgaG9sZGVyIG9mIGtl
eSBwYXR0ZXJuLiAmbmJzcDtUaGUgZHJhZnQgdG91Y2hlcyBvbiBpdDwvZm9udD48L3R0Pg0KPGJy
Pjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5i
c3A7VGhlIHByb3RvY29sIHBhcmFtZXRlcnMgYW5kIHByb2Nlc3NpbmcgcnVsZXMgZGVmaW5lZA0K
aW4gdGhpcyBkb2N1bWVudDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2FyZSBpbnRlbmRlZCB0byBz
dXBwb3J0IGEgY2xpZW50IHByZXNlbnRpbmcgYSBiZWFyZXINCmFzc2VydGlvbiB0byBhbjxicj4N
CiZndDsgJm5ic3A7ICZuYnNwO2F1dGhvcml6YXRpb24gc2VydmVyLiAmbmJzcDtUaGUgdXNlIG9m
IGhvbGRlci1vZi1rZXkNCmFzc2VydGlvbnMgYXJlIG5vdDxicj4NCiZndDsgJm5ic3A7ICZuYnNw
O3ByZWNsdWRlZCBieSB0aGlzIGRvY3VtZW50LCBidXQgYWRkaXRpb25hbCBwcm90b2NvbCBkZXRh
aWxzDQp3b3VsZDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO25lZWQgdG8gYmUgc3BlY2lmaWVkLjxi
cj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsg
U28gLSBpZiB5b3Ugd2FudCB0aGlzLCB5b3Ugc2hvdWxkIHB1dCBmb3J0aCBhIGhvbGRlciBvZiBr
ZXkgPGJyPg0KJmd0OyBwcm9maWxpbmcgb2YgdGhpcyBkcmFmdCBhbmQgc2VlIGlmIHRoZXJlIGFy
ZSBhbnkgaXNzdWVzLiAmbmJzcDsgVGhlDQpvbmx5IDxicj4NCiZndDsgcHJvZmlsZXMgd2UgaGF2
ZSB0aHVzIGZhciBhcmUgc2FtbCBhbmQgand0IGJlYXJlciBhc3NlcnRpb25zLiAmbmJzcDs8L2Zv
bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0iMiI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn
dDsgLSBjbW9ydDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPSIyIj4mZ3Q7IDxicj4N
CiZndDsgT24gRGVjIDEzLCAyMDEyLCBhdCA2OjI3IFBNLCAiPGEgaHJlZj0ibWFpbHRvOnpob3Uu
c3VqaW5nQHp0ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L2E+IiAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248
L2E+PGJyPg0KJmd0OyAmZ3Q7IHdyb3RlOjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPSIyIj4mZ3Q7IDxicj4NCiZndDsgSSBhbSBub3Qgc3VyZSBpZiB0aGUgZm9sbG93aW5n
IHVzZWNhc2UgJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLSI+aHR0cDov
L3d3dy5pZXRmLm9yZy9tYWlsLTwvYT48YnI+DQomZ3Q7IGFyY2hpdmUvd2ViL29hdXRoL2N1cnJl
bnQvbXNnMTAyMzMuaHRtbCA8YnI+DQomZ3Q7IGNvdWxkIGJlIHN1cHBvcnRlZCBieSBhc3NlcnRp
b24gZnJhbWV3b3Jr77yMIDxicj4NCiZndDsgV2UgaGF2ZSBzb21lIGRpc2N1c3Npb24gaW4gJm5i
c3A7IDxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv
d2ViL29hdXRoL2N1cnJlbnQvbXNnMTAyMDMuaHRtbCI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWls
LWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAyMDMuaHRtbDwvYT4gPGJyPg0KJmd0OyA8
YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVu
dC9tc2cxMDE5OC5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1
dGgvY3VycmVudC9tc2cxMDE5OC5odG1sPC9hPiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSW4gbXkg
dXNlIGNhc2Ugb3IgaW4gc29tZSBvdGhlciBjYXNlcywgYXNzZXJ0aW9ucyBkb24ndCBuZWVkIDxi
cj4NCiZndDsgY29uZmlkZW50aWFsIHByb3RlY3Rpb24sIDxicj4NCiZndDsgYmFzaWNhbGx5IFNU
UyBkb24ndCBoYXZlIHRvIGF1dGhlbnRpY2F0ZSBhIGNsaWVudCBiZWZvcmUgaXNzdWVpbmcNCjxi
cj4NCiZndDsgImFzc2VydGlvbiIsIGlmIGl0IGNvdWxkIGJlIGNhbGxlZCBhc3NlcnRpb24gaGVy
ZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEV4YW1wbGUsSSB0cnVzdCBteSBsYXl3ZXIsIEkgbWF5
IGlzc3VlIGFuICJhc3NlcnRpb24iIHN0YXRpbmcNCjxicj4NCiZndDsgZGVsZWdhdGlvbiBpbiBh
ZHZhbmNlLCBhbmQgc2VuZCB0byB0aGUgbGF3eWVyIHdoZW4gaXQgaXMgbmVlZGVkLCA8YnI+DQom
Z3Q7IGl0IGNvdWxkIGJlIEkgZ2l2ZSB0aGUgYXNzZXJ0aW9uIHRvIGEgZmFsc2UgbGF3eWVyLCBi
dXQgaXQgZG9lcyBub3QNCjxicj4NCiZndDsgbWF0dGVyLCBiZWNhdXNlIHRoZSBsYXd5ZXIgaGFz
IHRvIHByb3ZlIGhlIGtub3dzIHNvbWUgY3JlZGVudGlhbCA8YnI+DQomZ3Q7IGNvcnJlc3BvbmRp
bmcgdG8gaGlzIElELCA8YnI+DQomZ3Q7IHdobyBpcyBkZWxlZ2F0ZWQgc29tZSByaWdodHMuIDxi
cj4NCiZndDsgPGJyPg0KJmd0OyBJZiBhc3NlcnRpb24gZnJhbWV3b3JrIHdhbnQgdG8gc3VwcG9y
dCB0aGlzIHVzZSBjYXNlLCB0aGVuIDxicj4NCiZndDsgZ2VuZXJhdGlvbiBvZiBhc3NlcnRpb24g
c2hvdWxkIGJlIHJlbGF4ZWQsIDxicj4NCiZndDsgb3RoZXJ3aXNlIG5ldyB3b3JrIGlzIHJlcXVp
cmVkIHRvIHN1cHBvcnQgdGhlIHVzZSBjYXNlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IENodWNrIE1vcnRpbW9yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNtb3J0
aW1vcmVAc2FsZXNmb3JjZS5jb20iPmNtb3J0aW1vcmVAc2FsZXNmb3JjZS5jb208L2E+Jmd0OyDl
hpnkuo4gMjAxMi0xMi0xNA0KMTA6MDg6MzQ6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24g
RGVjIDEzLCAyMDEyLCBhdCA0OjMwIFBNLCAiPGEgaHJlZj0ibWFpbHRvOnpob3Uuc3VqaW5nQHp0
ZS5jb20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L2E+Ig0KJmx0O3pob3UuPGJyPg0KJmd0
OyA8YSBocmVmPSJtYWlsdG86c3VqaW5nQHp0ZS5jb20uY24iPnN1amluZ0B6dGUuY29tLmNuPC9h
Pjxicj4NCiZndDsgJmd0OyAmZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxi
cj4NCiZndDsgJmd0OyBGcm9tIHRoZSBsYW5ndWFnZSwgSSBnb3QgYW4gaW1wcmVzc2lvbiB0aGF0
IGFzc2VydGlvbiBpcyBvbmx5DQo8YnI+DQomZ3Q7ICZndDsgZ2VuZXJhdGVkIGJ5IHRva2VuIHNl
cnZpY2UgYWZ0ZXIgY2xpZW50cyBwcmVzZW50aW5nIHNvbWUgY3JlZGVudGlhbHMsDQo8YnI+DQom
Z3Q7ICZndDsgdGhlcmUgYXJlIG1heSBiZSBzb21lIGNhc2VzIHRoYXQgImFzc2VydGlvbiIgZG9u
J3QNCm5lZWQgY2xpZW50J3MgPGJyPg0KJmd0OyBjcmVkZW50aWFsLiA8YnI+DQomZ3Q7ICZndDsg
ZS5nLiwgUmVzb3VyY2Ugb3duZXIgYXMgYSB0b2tlbiBzZXJ2aWNlICZuYnNwO2NvdWxkIGdlbmVy
YXRlDQoiYXNzZXJ0aW9uIiA8YnI+DQomZ3Q7ICZndDsgdG8gYSBjbGllbnQgaGUgdHJ1c3RzLCBi
dSBzaWduaW5nIGEgc3RhdGVtZW50IHRoYXQgIlRoaXMNCmRlbGVnYXRpb24gPGJyPg0KJmd0OyAm
Z3Q7IGlzIGdpdmVuIHRvIGEgY2xpZW50IGNhbGxlZCBjbGluZXQtaWQgPGJyPg0KJmd0OyAmZ3Q7
IGZvciBkb2luZyBzb21ldGhpbmcgZm9yIG1lIi4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyBTbyBob3cgZG9lcyB0aGUgU1RTIHRydXN0IHRoZSBjbGllbnQ/ICZuYnNwOyBQcmVzdW1h
Ymx5IGlmIGl0DQppcyB0cnVzdGVkIDxicj4NCiZndDsgJmd0OyBpdCBoYXMgc29tZSBsZXZlbCBv
ZiBhdXRoZW50aWNhdGlvbiwgeWVzPyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC1j
bW9ydCA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+
DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBDaHVjayBNb3J0aW1v
cmUgJmx0OzxhIGhyZWY9Im1haWx0bzpjbW9ydGltb3JlQHNhbGVzZm9yY2UuY29tIj5jbW9ydGlt
b3JlQHNhbGVzZm9yY2UuY29tPC9hPiZndDsg5YaZ5LqOIDIwMTItMTItMTQNCjAwOjM5OjAzOjxi
cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBUaGUgbGFuZ3VhZ2UgaXMgc2ltcGx5
IG1lYW50IHRvIGhlbHAgaWxsdXN0cmF0ZSBob3cgdGhlDQpmcmFtZXdvcmsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgbWlnaHQgYmUgdXNlZC4gJm5ic3A7IEhvdyBkbyB5b3UgdGhpbmsgaXQgd2lsbCBy
ZXN0cmljdA0KdXNhZ2U/ICZuYnNwOyBIb3cgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY291bGQgaXQg
YmUgaW1wcm92ZWQ/IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IC1j
bW9ydCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBPbiBEZWMgMTIs
IDIwMTIsIGF0IDExOjA0IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnpob3Uuc3VqaW5nQHp0ZS5j
b20uY24iPnpob3Uuc3VqaW5nQHp0ZS5jb20uY248L2E+Jmd0Ow0Kd3JvdGU6IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEluICJz
ZWN0aW9uIDMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7VGhlIHRva2VuIHNlcnZpY2UgaXMg
dGhlIGFzc2VydGlvbiBpc3N1ZXI7IGl0cyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDtyb2xl
IGlzIHRvIGZ1bGZpbGwgcmVxdWVzdHMgZnJvbSBjbGllbnRzLCB3aGljaCBwcmVzZW50DQp2YXJp
b3VzIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZuYnNwO2NyZWRlbnRpYWxzLCBhbmQgbWludCBhc3Nl
cnRpb25zIGFzIHJlcXVlc3RlZCwgZmlsbA0KdGhlbSB3aXRoIDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZuYnNwO2FwcHJvcHJpYXRlIGluZm9ybWF0aW9uLCBhbmQgc2lnbiB0aGVtLiIgPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXMg
SSB1bmRlcnN0YW5kLCBhbiBhc3NlcnRpb24gZ2VuZXJhdGVkIGJ5IGEgU1RTLCBpcyBkb25lDQpm
bG9sbG93aW5nPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlc3Mgc3RlcHM6IDxicj4NCiZndDsgJmd0
OyAmZ3Q7IDEuIENsaWVudCBwcmVzZW50cyBjcmVkZW50aWFsIGFuZCByZXF1ZXN0cyBhbiBhc3Nl
cnRpb24NCjxicj4NCiZndDsgJmd0OyAmZ3Q7IDIuIFNUUyBnZW5lcmF0ZXMgYXNzZXJ0aW9uIGFu
ZCBzZW5kcyB0byBDbGllbnQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQ29ycmVjdD8gPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgVGhhdCBtYXkgcmVzdHJpY3QgdGhlIHVz
ZSBjYXNlcyB0aGF0IHRoaXMgYXNzZXJ0aW9uIGZyYW1ld29yaw0KPGJyPg0KJmd0OyAmZ3Q7IGNv
dWxkIHN1cHBvcnQsIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGlzIGl0IGEgbXVzdD8gPGJyPg0KJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IOWGmeS6jiAy
MDEyLTEyLTExIDAyOjMzOjU3Ojxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQg
YSByZXF1ZXN0IGZyb20gdGhlIFdlYiBBdXRob3JpemF0aW9uDQpQcm90b2NvbCBXRzxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgKG9hdXRoKSB0byBjb25zaWRlciB0aGUgZm9sbG93aW5nIGRvY3Vt
ZW50Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgLSAnQXNzZXJ0aW9uIEZyYW1ld29yayBmb3Ig
T0F1dGggMi4wJzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZsdDtkcmFmdC1pZXRm
LW9hdXRoLWFzc2VydGlvbnMtMDgudHh0Jmd0OyBhcw0KUHJvcG9zZWQgU3RhbmRhcmQ8YnI+DQom
Z3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIElFU0cgcGxh
bnMgdG8gbWFrZSBhIGRlY2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywNCmFuZCBzb2xpY2l0
czxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgZmluYWwgY29tbWVudHMgb24gdGhpcyBhY3Rpb24u
IFBsZWFzZSBzZW5kIHN1YnN0YW50aXZlDQpjb21tZW50cyB0byB0aGU8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzppZXRmQGlldGYub3JnIj5pZXRmQGlldGYub3JnPC9h
PiBtYWlsaW5nIGxpc3RzIGJ5IDIwMTItMTItMjQuIEV4Y2VwdGlvbmFsbHksDQo8YnI+DQomZ3Q7
IGNvbW1lbnRzIG1heSBiZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgc2VudCB0byA8YSBocmVm
PSJtYWlsdG86aWVzZ0BpZXRmLm9yZyI+aWVzZ0BpZXRmLm9yZzwvYT4gaW5zdGVhZC4gSW4gZWl0
aGVyIGNhc2UsIHBsZWFzZQ0KcmV0YWluIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgYmVn
aW5uaW5nIG9mIHRoZSBTdWJqZWN0IGxpbmUgdG8gYWxsb3cgYXV0b21hdGVkIHNvcnRpbmcuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IEFic3RyYWN0
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RoaXMgc3BlY2lmaWNhdGlvbiBwcm92
aWRlcyBhIGZyYW1ld29yaw0KZm9yIHRoZSB1c2Ugb2YgYXNzZXJ0aW9uczxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3dpdGggT0F1dGggMi4wIGluIHRoZSBmb3JtIG9mIGEg
bmV3IGNsaWVudA0KYXV0aGVudGljYXRpb24gbWVjaGFuaXNtPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyAmbmJzcDsgJm5ic3A7YW5kIGEgbmV3IGF1dGhvcml6YXRpb24gZ3JhbnQgdHlwZS4gJm5i
c3A7TWVjaGFuaXNtcw0KYXJlIHNwZWNpZmllZCBmb3I8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZuYnNwOyAmbmJzcDt0cmFuc3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25z
DQp3aXRoIGEgdG9rZW4gZW5kcG9pbnQsIGFzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJz
cDsgJm5ic3A7d2VsbCBhcyBnZW5lcmFsIHByb2Nlc3NpbmcgcnVsZXMuPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgaW50
ZW50IG9mIHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0bw0KcHJvdmlkZSBhIGNvbW1vbiBmcmFtZXdv
cmsgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7T0F1dGggMi4wIHRv
IGludGVyd29yayB3aXRoIG90aGVyIGlkZW50aXR5DQpzeXN0ZW1zIHVzaW5nIGFzc2VydGlvbnMs
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7YW5kIHRvIHByb3ZpZGUgYWx0
ZXJuYXRpdmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uDQptZWNoYW5pc21zLjxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7Tm90ZSB0
aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5IGRlZmluZXMNCmFic3RyYWN0IG1lc3NhZ2UgZmxv
d3MgYW5kPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cHJvY2Vzc2luZyBy
dWxlcy4gJm5ic3A7SW4gb3JkZXIgdG8gYmUNCmltcGxlbWVudGFibGUsIGNvbXBhbmlvbjxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3NwZWNpZmljYXRpb25zIGFyZSBuZWNl
c3NhcnkgdG8gcHJvdmlkZQ0KdGhlIGNvcnJlc3BvbmRpbmcgY29uY3JldGU8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtpbnN0YW50aWF0aW9ucy48YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
VGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGEg
aHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9hdXRoLWFz
c2VydGlvbnMvIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1
dGgtYXNzZXJ0aW9ucy88L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IElFU0cgZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWE8YnI+DQomZ3Q7
ICZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zL2JhbGxvdC8iPmh0dHA6Ly9kYXRhdHJhY2tlci5p
ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zL2JhbGxvdC88L2E+PGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRp
cmVjdGx5IG9uDQp0aGlzIEktRC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQom
Z3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0
OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aDwvYT4gPC9mb250PjwvdHQ+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4=

--_000_D0292BEDC6D84B569BBE6C280F38BC42salesforcecom_--

From zhou.sujing@zte.com.cn  Thu Dec 13 18:56:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23F521F899D; Thu, 13 Dec 2012 18:56:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.675
X-Spam-Level: 
X-Spam-Status: No, score=-97.675 tagged_above=-999 required=5 tests=[AWL=-0.302, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nMc3QRJZd+V; Thu, 13 Dec 2012 18:56:31 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0389D21F8929; Thu, 13 Dec 2012 18:56:31 -0800 (PST)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 02B541244005; Fri, 14 Dec 2012 10:58:20 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 12F4F724F17; Fri, 14 Dec 2012 10:45:30 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBE2uBnA046867; Fri, 14 Dec 2012 10:56:11 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Chuck Mortimore 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Fri, 14 Dec 2012 10:55:57 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-14 10:56:04, Serialize complete at 2012-12-14 10:56:04
Content-Type: multipart/alternative; boundary="=_alternative 00103FB948257AD4_="
X-MAIL: mse02.zte.com.cn qBE2uBnA046867
Cc: "oauth-bounces@ietf.org" , "ietf@ietf.org" , "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 02:56:32 -0000

This is a multipart message in MIME format.
--=_alternative 00103FB948257AD4_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

WWVwLCBjb3VsZCBkbyBpdCBzb29uIGxhdGVyLiANCg0KQ3VycmVudGx5LCBJIHN1Z2dlc3QgYSBt
b2RpZmljYXRpb24gZm9yIA0KDQogIlRoZSB0b2tlbiBzZXJ2aWNlIGlzIHRoZSBhc3NlcnRpb24g
aXNzdWVyOyBpdHMgIHJvbGUgaXMgdG8gZnVsZmlsbCANCnJlcXVlc3RzIGZyb20gY2xpZW50cywg
d2hpY2ggcHJlc2VudCB2YXJpb3VzIA0KIGNyZWRlbnRpYWxzLCBhbmQgbWludCBhc3NlcnRpb25z
IGFzIHJlcXVlc3RlZCwgZmlsbCB0aGVtIHdpdGggYXBwcm9wcmlhdGUgDQppbmZvcm1hdGlvbiwg
YW5kIHNpZ24gdGhlbS4iICAoaW4gIHNlY3Rpb24gMyApDQoNCmludG8gDQoNCiAiVGhlIHRva2Vu
IHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbiBpc3N1ZXIsIGl0IGNvdWxkIGJlIGltcGxlbWVudGVk
IGluIA0KYW55IGVudGl0eSBiZXNpZGVzIGNsaWVudCwgZS5nLiwgUmVzb3VyY2UgT3duZXIsIEF1
dGhvcml6YXRpb24gU2VydmVyOyBpdHMgDQogcm9sZSBpcyB0byBmdWxmaWxsIHJlcXVlc3RzIGZy
b20gY2xpZW50cywgd2hpY2ggcHJlc2VudCB2YXJpb3VzIA0KY3JlZGVudGlhbHMsIGFuZCBtaW50
IGFzc2VydGlvbnMgYXMgcmVxdWVzdGVkLCBmaWxsIHRoZW0gd2l0aCAgYXBwcm9wcmlhdGUgDQpp
bmZvcm1hdGlvbiwgYW5kIHNpZ24gdGhlbS4iIA0KDQoNCg0KQ2h1Y2sgTW9ydGltb3JlIDxjbW9y
dGltb3JlQHNhbGVzZm9yY2UuY29tPiDQtNPaIDIwMTItMTItMTQgMTA6NDQ6MDU6DQoNCj4gQ29y
cmVjdC4gICBUaGF0IHNhaWQgbm8gb25lIGhhcyB5ZXQgcHJvZmlsZWQgaXQgZm9yIGhvbGRlciBv
ZiBrZXkNCj4gDQo+IC0gY21vcnQNCj4gDQo+IE9uIERlYyAxMywgMjAxMiwgYXQgNjozOSBQTSwg
Inpob3Uuc3VqaW5nQHp0ZS5jb20uY24iIA0KPHpob3Uuc3VqaW5nQHp0ZS5jb20uY24NCj4gPiB3
cm90ZToNCg0KPiANCj4gT2gsIEJ1dCB0aGUgZGVzY3JpcHRpb24gb2YgYXNzZXJ0aW9uIGdlbmVy
YXRpb24gaW4gdGhlIGRvY3VtZW50IA0KPiBzaG91bGQgbm90IGJlIGxpbWl0ZWQgYnkgYmVhciBh
c3NlcnRpb24sIHJpZ2h0PyANCj4gDQo+IA0KPiBDaHVjayBNb3J0aW1vcmUgPGNtb3J0aW1vcmVA
c2FsZXNmb3JjZS5jb20+INC009ogMjAxMi0xMi0xNCAxMDozNDoxMzoNCj4gDQo+ID4gWW91IHdh
bnQgYSBob2xkZXIgb2Yga2V5IHBhdHRlcm4uICBUaGUgZHJhZnQgdG91Y2hlcyBvbiBpdCANCj4g
PiANCj4gPiANCj4gPiAgICBUaGUgcHJvdG9jb2wgcGFyYW1ldGVycyBhbmQgcHJvY2Vzc2luZyBy
dWxlcyBkZWZpbmVkIGluIHRoaXMgDQpkb2N1bWVudA0KPiA+ICAgIGFyZSBpbnRlbmRlZCB0byBz
dXBwb3J0IGEgY2xpZW50IHByZXNlbnRpbmcgYSBiZWFyZXIgYXNzZXJ0aW9uIHRvIA0KYW4NCj4g
PiAgICBhdXRob3JpemF0aW9uIHNlcnZlci4gIFRoZSB1c2Ugb2YgaG9sZGVyLW9mLWtleSBhc3Nl
cnRpb25zIGFyZSBub3QNCj4gPiAgICBwcmVjbHVkZWQgYnkgdGhpcyBkb2N1bWVudCwgYnV0IGFk
ZGl0aW9uYWwgcHJvdG9jb2wgZGV0YWlscyB3b3VsZA0KPiA+ICAgIG5lZWQgdG8gYmUgc3BlY2lm
aWVkLg0KPiANCj4gPiANCj4gPiBTbyAtIGlmIHlvdSB3YW50IHRoaXMsIHlvdSBzaG91bGQgcHV0
IGZvcnRoIGEgaG9sZGVyIG9mIGtleSANCj4gPiBwcm9maWxpbmcgb2YgdGhpcyBkcmFmdCBhbmQg
c2VlIGlmIHRoZXJlIGFyZSBhbnkgaXNzdWVzLiAgIFRoZSBvbmx5IA0KPiA+IHByb2ZpbGVzIHdl
IGhhdmUgdGh1cyBmYXIgYXJlIHNhbWwgYW5kIGp3dCBiZWFyZXIgYXNzZXJ0aW9ucy4gDQo+ID4g
DQo+ID4gDQo+ID4gLSBjbW9ydCANCj4gPiANCj4gPiBPbiBEZWMgMTMsIDIwMTIsIGF0IDY6Mjcg
UE0sICJ6aG91LnN1amluZ0B6dGUuY29tLmNuIiA8emhvdS4NCj4gc3VqaW5nQHp0ZS5jb20uY24N
Cj4gPiA+IHdyb3RlOg0KPiANCj4gPiANCj4gPiBJIGFtIG5vdCBzdXJlIGlmIHRoZSBmb2xsb3dp
bmcgdXNlY2FzZSAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLQ0KPiA+IGFyY2hpdmUvd2ViL29h
dXRoL2N1cnJlbnQvbXNnMTAyMzMuaHRtbCANCj4gPiBjb3VsZCBiZSBzdXBwb3J0ZWQgYnkgYXNz
ZXJ0aW9uIGZyYW1ld29ya6OsIA0KPiA+IFdlIGhhdmUgc29tZSBkaXNjdXNzaW9uIGluIA0KPiA+
IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEw
MjAzLmh0bWwgDQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRo
L2N1cnJlbnQvbXNnMTAxOTguaHRtbCANCj4gPiANCj4gPiBJbiBteSB1c2UgY2FzZSBvciBpbiBz
b21lIG90aGVyIGNhc2VzLCBhc3NlcnRpb25zIGRvbid0IG5lZWQgDQo+ID4gY29uZmlkZW50aWFs
IHByb3RlY3Rpb24sIA0KPiA+IGJhc2ljYWxseSBTVFMgZG9uJ3QgaGF2ZSB0byBhdXRoZW50aWNh
dGUgYSBjbGllbnQgYmVmb3JlIGlzc3VlaW5nIA0KPiA+ICJhc3NlcnRpb24iLCBpZiBpdCBjb3Vs
ZCBiZSBjYWxsZWQgYXNzZXJ0aW9uIGhlcmUuIA0KPiA+IA0KPiA+IEV4YW1wbGUsSSB0cnVzdCBt
eSBsYXl3ZXIsIEkgbWF5IGlzc3VlIGFuICJhc3NlcnRpb24iIHN0YXRpbmcgDQo+ID4gZGVsZWdh
dGlvbiBpbiBhZHZhbmNlLCBhbmQgc2VuZCB0byB0aGUgbGF3eWVyIHdoZW4gaXQgaXMgbmVlZGVk
LCANCj4gPiBpdCBjb3VsZCBiZSBJIGdpdmUgdGhlIGFzc2VydGlvbiB0byBhIGZhbHNlIGxhd3ll
ciwgYnV0IGl0IGRvZXMgbm90IA0KPiA+IG1hdHRlciwgYmVjYXVzZSB0aGUgbGF3eWVyIGhhcyB0
byBwcm92ZSBoZSBrbm93cyBzb21lIGNyZWRlbnRpYWwgDQo+ID4gY29ycmVzcG9uZGluZyB0byBo
aXMgSUQsIA0KPiA+IHdobyBpcyBkZWxlZ2F0ZWQgc29tZSByaWdodHMuIA0KPiA+IA0KPiA+IElm
IGFzc2VydGlvbiBmcmFtZXdvcmsgd2FudCB0byBzdXBwb3J0IHRoaXMgdXNlIGNhc2UsIHRoZW4g
DQo+ID4gZ2VuZXJhdGlvbiBvZiBhc3NlcnRpb24gc2hvdWxkIGJlIHJlbGF4ZWQsIA0KPiA+IG90
aGVyd2lzZSBuZXcgd29yayBpcyByZXF1aXJlZCB0byBzdXBwb3J0IHRoZSB1c2UgY2FzZS4gDQo+
ID4gDQo+ID4gDQo+ID4gDQo+ID4gQ2h1Y2sgTW9ydGltb3JlIDxjbW9ydGltb3JlQHNhbGVzZm9y
Y2UuY29tPiDQtNPaIDIwMTItMTItMTQgMTA6MDg6MzQ6DQo+ID4gDQo+ID4gPiBPbiBEZWMgMTMs
IDIwMTIsIGF0IDQ6MzAgUE0sICJ6aG91LnN1amluZ0B6dGUuY29tLmNuIiA8emhvdS4NCj4gPiBz
dWppbmdAenRlLmNvbS5jbg0KPiA+ID4gPiB3cm90ZToNCj4gPiANCj4gPiA+IA0KPiA+ID4gRnJv
bSB0aGUgbGFuZ3VhZ2UsIEkgZ290IGFuIGltcHJlc3Npb24gdGhhdCBhc3NlcnRpb24gaXMgb25s
eSANCj4gPiA+IGdlbmVyYXRlZCBieSB0b2tlbiBzZXJ2aWNlIGFmdGVyIGNsaWVudHMgcHJlc2Vu
dGluZyBzb21lIA0KY3JlZGVudGlhbHMsIA0KPiA+ID4gdGhlcmUgYXJlIG1heSBiZSBzb21lIGNh
c2VzIHRoYXQgImFzc2VydGlvbiIgZG9uJ3QgbmVlZCBjbGllbnQncyANCj4gPiBjcmVkZW50aWFs
LiANCj4gPiA+IGUuZy4sIFJlc291cmNlIG93bmVyIGFzIGEgdG9rZW4gc2VydmljZSAgY291bGQg
Z2VuZXJhdGUgImFzc2VydGlvbiIgDQo+ID4gPiB0byBhIGNsaWVudCBoZSB0cnVzdHMsIGJ1IHNp
Z25pbmcgYSBzdGF0ZW1lbnQgdGhhdCAiVGhpcyBkZWxlZ2F0aW9uIA0KPiA+ID4gaXMgZ2l2ZW4g
dG8gYSBjbGllbnQgY2FsbGVkIGNsaW5ldC1pZCANCj4gPiA+IGZvciBkb2luZyBzb21ldGhpbmcg
Zm9yIG1lIi4gDQo+ID4gPiANCj4gPiA+IFNvIGhvdyBkb2VzIHRoZSBTVFMgdHJ1c3QgdGhlIGNs
aWVudD8gICBQcmVzdW1hYmx5IGlmIGl0IGlzIHRydXN0ZWQgDQo+ID4gPiBpdCBoYXMgc29tZSBs
ZXZlbCBvZiBhdXRoZW50aWNhdGlvbiwgeWVzPyANCj4gPiA+IA0KPiA+ID4gLWNtb3J0IA0KPiA+
ID4gDQo+ID4gPiANCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiANCj4gPiA+IENodWNrIE1vcnRpbW9y
ZSA8Y21vcnRpbW9yZUBzYWxlc2ZvcmNlLmNvbT4g0LTT2iAyMDEyLTEyLTE0IA0KMDA6Mzk6MDM6
DQo+ID4gPiANCj4gPiA+ID4gVGhlIGxhbmd1YWdlIGlzIHNpbXBseSBtZWFudCB0byBoZWxwIGls
bHVzdHJhdGUgaG93IHRoZSBmcmFtZXdvcmsgDQo+ID4gPiA+IG1pZ2h0IGJlIHVzZWQuICAgSG93
IGRvIHlvdSB0aGluayBpdCB3aWxsIHJlc3RyaWN0IHVzYWdlPyAgIEhvdyANCj4gPiA+ID4gY291
bGQgaXQgYmUgaW1wcm92ZWQ/IA0KPiA+ID4gPiANCj4gPiA+ID4gLWNtb3J0IA0KPiA+ID4gPiAN
Cj4gPiA+ID4gT24gRGVjIDEyLCAyMDEyLCBhdCAxMTowNCBQTSwgPHpob3Uuc3VqaW5nQHp0ZS5j
b20uY24+IHdyb3RlOiANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiBJbiAic2VjdGlvbiAz
IA0KPiA+ID4gPiAgVGhlIHRva2VuIHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbiBpc3N1ZXI7IGl0
cyANCj4gPiA+ID4gIHJvbGUgaXMgdG8gZnVsZmlsbCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdo
aWNoIHByZXNlbnQgdmFyaW91cyANCj4gPiA+ID4gIGNyZWRlbnRpYWxzLCBhbmQgbWludCBhc3Nl
cnRpb25zIGFzIHJlcXVlc3RlZCwgZmlsbCB0aGVtIHdpdGggDQo+ID4gPiA+ICBhcHByb3ByaWF0
ZSBpbmZvcm1hdGlvbiwgYW5kIHNpZ24gdGhlbS4iIA0KPiA+ID4gPiANCj4gPiA+ID4gDQo+ID4g
PiA+IEFzIEkgdW5kZXJzdGFuZCwgYW4gYXNzZXJ0aW9uIGdlbmVyYXRlZCBieSBhIFNUUywgaXMg
ZG9uZSANCmZsb2xsb3dpbmcNCj4gPiA+ID4gdGhlc3Mgc3RlcHM6IA0KPiA+ID4gPiAxLiBDbGll
bnQgcHJlc2VudHMgY3JlZGVudGlhbCBhbmQgcmVxdWVzdHMgYW4gYXNzZXJ0aW9uIA0KPiA+ID4g
PiAyLiBTVFMgZ2VuZXJhdGVzIGFzc2VydGlvbiBhbmQgc2VuZHMgdG8gQ2xpZW50IA0KPiA+ID4g
PiBDb3JyZWN0PyANCj4gPiA+ID4gDQo+ID4gPiA+IFRoYXQgbWF5IHJlc3RyaWN0IHRoZSB1c2Ug
Y2FzZXMgdGhhdCB0aGlzIGFzc2VydGlvbiBmcmFtZXdvcmsgDQo+ID4gPiBjb3VsZCBzdXBwb3J0
LCANCj4gPiA+ID4gaXMgaXQgYSBtdXN0PyANCj4gPiA+ID4gDQo+ID4gPiA+IA0KPiA+ID4gPiAN
Cj4gPiA+ID4gDQo+ID4gPiA+IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTEyLTEx
IDAyOjMzOjU3Og0KPiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBUaGUgSUVTRyBoYXMg
cmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIFdlYiBBdXRob3JpemF0aW9uIA0KUHJvdG9jb2wg
V0cNCj4gPiA+ID4gPiAob2F1dGgpIHRvIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6
DQo+ID4gPiA+ID4gLSAnQXNzZXJ0aW9uIEZyYW1ld29yayBmb3IgT0F1dGggMi4wJw0KPiA+ID4g
PiA+ICAgPGRyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9ucy0wOC50eHQ+IGFzIFByb3Bvc2VkIFN0
YW5kYXJkDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gVGhlIElFU0cgcGxhbnMgdG8gbWFrZSBhIGRl
Y2lzaW9uIGluIHRoZSBuZXh0IGZldyB3ZWVrcywgYW5kIA0Kc29saWNpdHMNCj4gPiA+ID4gPiBm
aW5hbCBjb21tZW50cyBvbiB0aGlzIGFjdGlvbi4gUGxlYXNlIHNlbmQgc3Vic3RhbnRpdmUgY29t
bWVudHMgDQp0byB0aGUNCj4gPiA+ID4gPiBpZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkg
MjAxMi0xMi0yNC4gRXhjZXB0aW9uYWxseSwgDQo+ID4gY29tbWVudHMgbWF5IGJlDQo+ID4gPiA+
ID4gc2VudCB0byBpZXNnQGlldGYub3JnIGluc3RlYWQuIEluIGVpdGhlciBjYXNlLCBwbGVhc2Ug
cmV0YWluIHRoZQ0KPiA+ID4gPiA+IGJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFs
bG93IGF1dG9tYXRlZCBzb3J0aW5nLg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEFic3RyYWN0DQo+
ID4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gICAgVGhpcyBzcGVjaWZpY2F0aW9uIHBy
b3ZpZGVzIGEgZnJhbWV3b3JrIGZvciB0aGUgdXNlIG9mIA0KYXNzZXJ0aW9ucw0KPiA+ID4gPiA+
ICAgIHdpdGggT0F1dGggMi4wIGluIHRoZSBmb3JtIG9mIGEgbmV3IGNsaWVudCANCmF1dGhlbnRp
Y2F0aW9ubWVjaGFuaXNtDQo+ID4gPiA+ID4gICAgYW5kIGEgbmV3IGF1dGhvcml6YXRpb24gZ3Jh
bnQgdHlwZS4gIE1lY2hhbmlzbXMgYXJlIHNwZWNpZmllZCANCmZvcg0KPiA+ID4gPiA+ICAgIHRy
YW5zcG9ydGluZyBhc3NlcnRpb25zIGR1cmluZyBpbnRlcmFjdGlvbnMgd2l0aCBhIHRva2VuIA0K
PiBlbmRwb2ludCwgYXMNCj4gPiA+ID4gPiAgICB3ZWxsIGFzIGdlbmVyYWwgcHJvY2Vzc2luZyBy
dWxlcy4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiAgICBUaGUgaW50ZW50IG9mIHRoaXMgc3BlY2lm
aWNhdGlvbiBpcyB0byBwcm92aWRlIGEgY29tbW9uIA0KPiBmcmFtZXdvcmsgZm9yDQo+ID4gPiA+
ID4gICAgT0F1dGggMi4wIHRvIGludGVyd29yayB3aXRoIG90aGVyIGlkZW50aXR5IHN5c3RlbXMg
dXNpbmcgDQo+IGFzc2VydGlvbnMsDQo+ID4gPiA+ID4gICAgYW5kIHRvIHByb3ZpZGUgYWx0ZXJu
YXRpdmUgY2xpZW50IGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbXMuDQo+ID4gPiA+ID4gDQo+ID4g
PiA+ID4gICAgTm90ZSB0aGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBvbmx5IGRlZmluZXMgYWJzdHJh
Y3QgDQo+IG1lc3NhZ2UgZmxvd3MgYW5kDQo+ID4gPiA+ID4gICAgcHJvY2Vzc2luZyBydWxlcy4g
IEluIG9yZGVyIHRvIGJlIGltcGxlbWVudGFibGUsIGNvbXBhbmlvbg0KPiA+ID4gPiA+ICAgIHNw
ZWNpZmljYXRpb25zIGFyZSBuZWNlc3NhcnkgdG8gcHJvdmlkZSB0aGUgY29ycmVzcG9uZGluZyAN
CmNvbmNyZXRlDQo+ID4gPiA+ID4gICAgaW5zdGFudGlhdGlvbnMuDQo+ID4gPiA+ID4gDQo+ID4g
PiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gVGhlIGZpbGUgY2FuIGJl
IG9idGFpbmVkIHZpYQ0KPiA+ID4gPiA+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLw0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IElFU0cg
ZGlzY3Vzc2lvbiBjYW4gYmUgdHJhY2tlZCB2aWENCj4gPiA+ID4gPiANCmh0dHA6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zL2JhbGxvdC8NCj4g
PiA+ID4gPiANCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBObyBJUFIgZGVjbGFyYXRpb25zIGhhdmUg
YmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+ID4gPiA+ID4gDQo+ID4gPiA+
ID4gDQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gPiA+ID4gPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiBPQXV0aEBpZXRm
Lm9yZw0KPiA+ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCj4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPiA+ID4gT0F1dGggbWFpbGluZyBsaXN0DQo+ID4gPiA+IE9BdXRoQGlldGYub3JnDQo+
ID4gPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGggDQo=
--=_alternative 00103FB948257AD4_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcCwgY291bGQgZG8gaXQgc29v
biBsYXRlci4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm
Ij5DdXJyZW50bHksIEkgc3VnZ2VzdCBhIG1vZGlmaWNhdGlvbg0KZm9yIDwvZm9udD4NCjxicj4N
Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7JnF1b3Q7VGhlIHRva2Vu
IHNlcnZpY2UgaXMgdGhlDQphc3NlcnRpb24gaXNzdWVyOyBpdHMgJm5ic3A7cm9sZSBpcyB0byBm
dWxmaWxsIHJlcXVlc3RzIGZyb20gY2xpZW50cywgd2hpY2gNCnByZXNlbnQgdmFyaW91cyA8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO2NyZWRlbnRpYWxz
LCBhbmQgbWludCBhc3NlcnRpb25zDQphcyByZXF1ZXN0ZWQsIGZpbGwgdGhlbSB3aXRoICZuYnNw
O2FwcHJvcHJpYXRlIGluZm9ybWF0aW9uLCBhbmQgc2lnbiB0aGVtLiZxdW90Ow0KJm5ic3A7KGlu
ICZuYnNwO3NlY3Rpb24gMyApPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz
YW5zLXNlcmlmIj5pbnRvIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu
cy1zZXJpZiI+Jm5ic3A7JnF1b3Q7VGhlIHRva2VuIHNlcnZpY2UgaXMgdGhlDQphc3NlcnRpb24g
aXNzdWVyLCA8Yj5pdCBjb3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBhbnkgZW50aXR5IGJlc2lkZXMg
Y2xpZW50LA0KZS5nLiwgUmVzb3VyY2UgT3duZXIsIEF1dGhvcml6YXRpb24gU2VydmVyOzwvYj4g
aXRzICZuYnNwO3JvbGUgaXMgdG8gZnVsZmlsbA0KcmVxdWVzdHMgZnJvbSBjbGllbnRzLCA8c3Ry
aWtlPndoaWNoIHByZXNlbnQgdmFyaW91cyAmbmJzcDtjcmVkZW50aWFsczwvc3RyaWtlPiwNCmFu
ZCBtaW50IGFzc2VydGlvbnMgYXMgcmVxdWVzdGVkLCBmaWxsIHRoZW0gd2l0aCAmbmJzcDthcHBy
b3ByaWF0ZSBpbmZvcm1hdGlvbiwNCmFuZCBzaWduIHRoZW0uJnF1b3Q7IDwvZm9udD4NCjxicj4N
Cjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkNodWNrIE1vcnRpbW9yZSAmbHQ7Y21v
cnRpbW9yZUBzYWxlc2ZvcmNlLmNvbSZndDsNCtC009ogMjAxMi0xMi0xNCAxMDo0NDowNTo8YnI+
DQo8YnI+DQomZ3Q7IENvcnJlY3QuICZuYnNwOyBUaGF0IHNhaWQgbm8gb25lIGhhcyB5ZXQgcHJv
ZmlsZWQgaXQgZm9yIGhvbGRlciBvZg0Ka2V5PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0gY21vcnQ8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBPbiBEZWMg
MTMsIDIwMTIsIGF0IDY6MzkgUE0sICZxdW90O3pob3Uuc3VqaW5nQHp0ZS5jb20uY24mcXVvdDsg
Jmx0O3pob3Uuc3VqaW5nQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgd3JvdGU6PGJyPg0KPC9m
b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgT2gsIEJ1dCB0
aGUgZGVzY3JpcHRpb24gb2YgYXNzZXJ0aW9uIGdlbmVyYXRpb24gaW4gdGhlIGRvY3VtZW50IDxi
cj4NCiZndDsgc2hvdWxkIG5vdCBiZSBsaW1pdGVkIGJ5IGJlYXIgYXNzZXJ0aW9uLCByaWdodD8g
PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ2h1Y2sgTW9ydGltb3JlICZsdDtjbW9y
dGltb3JlQHNhbGVzZm9yY2UuY29tJmd0OyDQtNPaIDIwMTItMTItMTQNCjEwOjM0OjEzOjxicj4N
CiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFlvdSB3YW50IGEgaG9sZGVyIG9mIGtleSBwYXR0ZXJuLiAm
bmJzcDtUaGUgZHJhZnQgdG91Y2hlcyBvbg0KaXQgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO1RoZSBwcm90b2NvbCBwYXJhbWV0ZXJz
IGFuZCBwcm9jZXNzaW5nIHJ1bGVzIGRlZmluZWQNCmluIHRoaXMgZG9jdW1lbnQ8YnI+DQomZ3Q7
ICZndDsgJm5ic3A7ICZuYnNwO2FyZSBpbnRlbmRlZCB0byBzdXBwb3J0IGEgY2xpZW50IHByZXNl
bnRpbmcgYSBiZWFyZXINCmFzc2VydGlvbiB0byBhbjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i
c3A7YXV0aG9yaXphdGlvbiBzZXJ2ZXIuICZuYnNwO1RoZSB1c2Ugb2YgaG9sZGVyLW9mLWtleQ0K
YXNzZXJ0aW9ucyBhcmUgbm90PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtwcmVjbHVkZWQg
YnkgdGhpcyBkb2N1bWVudCwgYnV0IGFkZGl0aW9uYWwgcHJvdG9jb2wNCmRldGFpbHMgd291bGQ8
YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO25lZWQgdG8gYmUgc3BlY2lmaWVkLjxicj4NCiZn
dDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTbyAtIGlmIHlvdSB3YW50IHRoaXMs
IHlvdSBzaG91bGQgcHV0IGZvcnRoIGEgaG9sZGVyIG9mIGtleSA8YnI+DQomZ3Q7ICZndDsgcHJv
ZmlsaW5nIG9mIHRoaXMgZHJhZnQgYW5kIHNlZSBpZiB0aGVyZSBhcmUgYW55IGlzc3Vlcy4gJm5i
c3A7DQpUaGUgb25seSA8YnI+DQomZ3Q7ICZndDsgcHJvZmlsZXMgd2UgaGF2ZSB0aHVzIGZhciBh
cmUgc2FtbCBhbmQgand0IGJlYXJlciBhc3NlcnRpb25zLg0KJm5ic3A7IDxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IC0gY21vcnQgPGJyPg0KJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyBPbiBEZWMgMTMsIDIwMTIsIGF0IDY6MjcgUE0sICZxdW90O3pob3Uu
c3VqaW5nQHp0ZS5jb20uY24mcXVvdDsNCiZsdDt6aG91Ljxicj4NCiZndDsgc3VqaW5nQHp0ZS5j
b20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0
OyA8YnI+DQomZ3Q7ICZndDsgSSBhbSBub3Qgc3VyZSBpZiB0aGUgZm9sbG93aW5nIHVzZWNhc2Ug
Jm5ic3A7aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLTxicj4NCiZndDsgJmd0OyBhcmNoaXZlL3dl
Yi9vYXV0aC9jdXJyZW50L21zZzEwMjMzLmh0bWwgPGJyPg0KJmd0OyAmZ3Q7IGNvdWxkIGJlIHN1
cHBvcnRlZCBieSBhc3NlcnRpb24gZnJhbWV3b3Jro6wgPGJyPg0KJmd0OyAmZ3Q7IFdlIGhhdmUg
c29tZSBkaXNjdXNzaW9uIGluICZuYnNwOyA8YnI+DQomZ3Q7ICZndDsgaHR0cDovL3d3dy5pZXRm
Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAyMDMuaHRtbA0KPGJyPg0K
Jmd0OyAmZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJy
ZW50L21zZzEwMTk4Lmh0bWwNCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSW4gbXkg
dXNlIGNhc2Ugb3IgaW4gc29tZSBvdGhlciBjYXNlcywgYXNzZXJ0aW9ucyBkb24ndCBuZWVkDQo8
YnI+DQomZ3Q7ICZndDsgY29uZmlkZW50aWFsIHByb3RlY3Rpb24sIDxicj4NCiZndDsgJmd0OyBi
YXNpY2FsbHkgU1RTIGRvbid0IGhhdmUgdG8gYXV0aGVudGljYXRlIGEgY2xpZW50IGJlZm9yZSBp
c3N1ZWluZw0KPGJyPg0KJmd0OyAmZ3Q7ICZxdW90O2Fzc2VydGlvbiZxdW90OywgaWYgaXQgY291
bGQgYmUgY2FsbGVkIGFzc2VydGlvbiBoZXJlLg0KPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyBFeGFtcGxlLEkgdHJ1c3QgbXkgbGF5d2VyLCBJIG1heSBpc3N1ZSBhbiAmcXVvdDthc3Nl
cnRpb24mcXVvdDsNCnN0YXRpbmcgPGJyPg0KJmd0OyAmZ3Q7IGRlbGVnYXRpb24gaW4gYWR2YW5j
ZSwgYW5kIHNlbmQgdG8gdGhlIGxhd3llciB3aGVuIGl0IGlzIG5lZWRlZCwNCjxicj4NCiZndDsg
Jmd0OyBpdCBjb3VsZCBiZSBJIGdpdmUgdGhlIGFzc2VydGlvbiB0byBhIGZhbHNlIGxhd3llciwg
YnV0IGl0IGRvZXMNCm5vdCA8YnI+DQomZ3Q7ICZndDsgbWF0dGVyLCBiZWNhdXNlIHRoZSBsYXd5
ZXIgaGFzIHRvIHByb3ZlIGhlIGtub3dzIHNvbWUgY3JlZGVudGlhbA0KPGJyPg0KJmd0OyAmZ3Q7
IGNvcnJlc3BvbmRpbmcgdG8gaGlzIElELCA8YnI+DQomZ3Q7ICZndDsgd2hvIGlzIGRlbGVnYXRl
ZCBzb21lIHJpZ2h0cy4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJZiBhc3NlcnRp
b24gZnJhbWV3b3JrIHdhbnQgdG8gc3VwcG9ydCB0aGlzIHVzZSBjYXNlLCB0aGVuIDxicj4NCiZn
dDsgJmd0OyBnZW5lcmF0aW9uIG9mIGFzc2VydGlvbiBzaG91bGQgYmUgcmVsYXhlZCwgPGJyPg0K
Jmd0OyAmZ3Q7IG90aGVyd2lzZSBuZXcgd29yayBpcyByZXF1aXJlZCB0byBzdXBwb3J0IHRoZSB1
c2UgY2FzZS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7IENodWNrIE1vcnRpbW9yZSAmbHQ7Y21vcnRpbW9yZUBzYWxlc2ZvcmNl
LmNvbSZndDsg0LTT2iAyMDEyLTEyLTE0DQoxMDowODozNDo8YnI+DQomZ3Q7ICZndDsgPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgT24gRGVjIDEzLCAyMDEyLCBhdCA0OjMwIFBNLCAmcXVvdDt6aG91LnN1
amluZ0B6dGUuY29tLmNuJnF1b3Q7DQombHQ7emhvdS48YnI+DQomZ3Q7ICZndDsgc3VqaW5nQHp0
ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBGcm9tIHRoZSBsYW5ndWFn
ZSwgSSBnb3QgYW4gaW1wcmVzc2lvbiB0aGF0IGFzc2VydGlvbiBpcw0Kb25seSA8YnI+DQomZ3Q7
ICZndDsgJmd0OyBnZW5lcmF0ZWQgYnkgdG9rZW4gc2VydmljZSBhZnRlciBjbGllbnRzIHByZXNl
bnRpbmcgc29tZQ0KY3JlZGVudGlhbHMsIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHRoZXJlIGFyZSBt
YXkgYmUgc29tZSBjYXNlcyB0aGF0ICZxdW90O2Fzc2VydGlvbiZxdW90OyBkb24ndA0KbmVlZCBj
bGllbnQncyA8YnI+DQomZ3Q7ICZndDsgY3JlZGVudGlhbC4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg
ZS5nLiwgUmVzb3VyY2Ugb3duZXIgYXMgYSB0b2tlbiBzZXJ2aWNlICZuYnNwO2NvdWxkIGdlbmVy
YXRlDQomcXVvdDthc3NlcnRpb24mcXVvdDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdG8gYSBjbGll
bnQgaGUgdHJ1c3RzLCBidSBzaWduaW5nIGEgc3RhdGVtZW50IHRoYXQgJnF1b3Q7VGhpcw0KZGVs
ZWdhdGlvbiA8YnI+DQomZ3Q7ICZndDsgJmd0OyBpcyBnaXZlbiB0byBhIGNsaWVudCBjYWxsZWQg
Y2xpbmV0LWlkIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGZvciBkb2luZyBzb21ldGhpbmcgZm9yIG1l
JnF1b3Q7LiA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBTbyBob3cg
ZG9lcyB0aGUgU1RTIHRydXN0IHRoZSBjbGllbnQ/ICZuYnNwOyBQcmVzdW1hYmx5DQppZiBpdCBp
cyB0cnVzdGVkIDxicj4NCiZndDsgJmd0OyAmZ3Q7IGl0IGhhcyBzb21lIGxldmVsIG9mIGF1dGhl
bnRpY2F0aW9uLCB5ZXM/IDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
IC1jbW9ydCA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQom
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyA8
YnI+DQomZ3Q7ICZndDsgJmd0OyBDaHVjayBNb3J0aW1vcmUgJmx0O2Ntb3J0aW1vcmVAc2FsZXNm
b3JjZS5jb20mZ3Q7INC009oNCjIwMTItMTItMTQgMDA6Mzk6MDM6PGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgbGFuZ3VhZ2UgaXMgc2ltcGx5IG1lYW50
IHRvIGhlbHAgaWxsdXN0cmF0ZSBob3cNCnRoZSBmcmFtZXdvcmsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyBtaWdodCBiZSB1c2VkLiAmbmJzcDsgSG93IGRvIHlvdSB0aGluayBpdCB3aWxsIHJl
c3RyaWN0DQp1c2FnZT8gJm5ic3A7IEhvdyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGNvdWxk
IGl0IGJlIGltcHJvdmVkPyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0
OyAmZ3Q7ICZndDsgLWNtb3J0IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyBPbiBEZWMgMTIsIDIwMTIsIGF0IDExOjA0IFBNLCAmbHQ7emhvdS5zdWpp
bmdAenRlLmNvbS5jbiZndDsNCndyb3RlOiA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4N
CiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBJbiAmcXVvdDtz
ZWN0aW9uIDMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDtUaGUgdG9rZW4gc2Vydmlj
ZSBpcyB0aGUgYXNzZXJ0aW9uIGlzc3VlcjsgaXRzDQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7
ICZuYnNwO3JvbGUgaXMgdG8gZnVsZmlsbCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoDQpw
cmVzZW50IHZhcmlvdXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDtjcmVkZW50aWFs
cywgYW5kIG1pbnQgYXNzZXJ0aW9ucyBhcyByZXF1ZXN0ZWQsDQpmaWxsIHRoZW0gd2l0aCA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwO2FwcHJvcHJpYXRlIGluZm9ybWF0aW9uLCBhbmQg
c2lnbiB0aGVtLiZxdW90Ow0KPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgQXMgSSB1bmRlcnN0YW5kLCBh
biBhc3NlcnRpb24gZ2VuZXJhdGVkIGJ5IGEgU1RTLCBpcw0KZG9uZSBmbG9sbG93aW5nPGJyPg0K
Jmd0OyAmZ3Q7ICZndDsgJmd0OyB0aGVzcyBzdGVwczogPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyAxLiBDbGllbnQgcHJlc2VudHMgY3JlZGVudGlhbCBhbmQgcmVxdWVzdHMgYW4gYXNzZXJ0aW9u
DQo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDIuIFNUUyBnZW5lcmF0ZXMgYXNzZXJ0aW9uIGFu
ZCBzZW5kcyB0byBDbGllbnQgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBDb3JyZWN0PyA8YnI+
DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhhdCBtYXkg
cmVzdHJpY3QgdGhlIHVzZSBjYXNlcyB0aGF0IHRoaXMgYXNzZXJ0aW9uDQpmcmFtZXdvcmsgPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgY291bGQgc3VwcG9ydCwgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyBpcyBpdCBhIG11c3Q/IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7
ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7
ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBvYXV0aC1ib3VuY2VzQGlldGYub3JnINC0
09ogMjAxMi0xMi0xMSAwMjozMzo1Nzo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhl
IElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9tIHRoZSBXZWIgQXV0aG9yaXphdGlvbg0K
UHJvdG9jb2wgV0c8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgKG9hdXRoKSB0byBjb25z
aWRlciB0aGUgZm9sbG93aW5nIGRvY3VtZW50Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyAtICdBc3NlcnRpb24gRnJhbWV3b3JrIGZvciBPQXV0aCAyLjAnPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbHQ7ZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA4LnR4
dCZndDsNCmFzIFByb3Bvc2VkIFN0YW5kYXJkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7
IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgSUVTRyBwbGFucyB0byBtYWtlIGEg
ZGVjaXNpb24gaW4gdGhlIG5leHQNCmZldyB3ZWVrcywgYW5kIHNvbGljaXRzPGJyPg0KJmd0OyAm
Z3Q7ICZndDsgJmd0OyAmZ3Q7IGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ug
c2VuZCBzdWJzdGFudGl2ZQ0KY29tbWVudHMgdG8gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0
OyAmZ3Q7IGlldGZAaWV0Zi5vcmcgbWFpbGluZyBsaXN0cyBieSAyMDEyLTEyLTI0LiBFeGNlcHRp
b25hbGx5LA0KPGJyPg0KJmd0OyAmZ3Q7IGNvbW1lbnRzIG1heSBiZTxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyBzZW50IHRvIGllc2dAaWV0Zi5vcmcgaW5zdGVhZC4gSW4gZWl0aGVyIGNh
c2UsDQpwbGVhc2UgcmV0YWluIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiZWdp
bm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQNCnNvcnRpbmcuPGJy
Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0
OyBBYnN0cmFjdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg
Jmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz
cDtUaGlzIHNwZWNpZmljYXRpb24gcHJvdmlkZXMgYSBmcmFtZXdvcmsNCmZvciB0aGUgdXNlIG9m
IGFzc2VydGlvbnM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3dp
dGggT0F1dGggMi4wIGluIHRoZSBmb3JtIG9mIGEgbmV3DQpjbGllbnQgYXV0aGVudGljYXRpb25t
ZWNoYW5pc208YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2FuZCBh
IG5ldyBhdXRob3JpemF0aW9uIGdyYW50IHR5cGUuDQombmJzcDtNZWNoYW5pc21zIGFyZSBzcGVj
aWZpZWQgZm9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt0cmFu
c3BvcnRpbmcgYXNzZXJ0aW9ucyBkdXJpbmcgaW50ZXJhY3Rpb25zDQp3aXRoIGEgdG9rZW4gPGJy
Pg0KJmd0OyBlbmRwb2ludCwgYXM8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7
ICZuYnNwO3dlbGwgYXMgZ2VuZXJhbCBwcm9jZXNzaW5nIHJ1bGVzLjxicj4NCiZndDsgJmd0OyAm
Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNw
O1RoZSBpbnRlbnQgb2YgdGhpcyBzcGVjaWZpY2F0aW9uDQppcyB0byBwcm92aWRlIGEgY29tbW9u
IDxicj4NCiZndDsgZnJhbWV3b3JrIGZvcjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
bmJzcDsgJm5ic3A7T0F1dGggMi4wIHRvIGludGVyd29yayB3aXRoIG90aGVyDQppZGVudGl0eSBz
eXN0ZW1zIHVzaW5nIDxicj4NCiZndDsgYXNzZXJ0aW9ucyw8YnI+DQomZ3Q7ICZndDsgJmd0OyAm
Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO2FuZCB0byBwcm92aWRlIGFsdGVybmF0aXZlIGNsaWVudA0K
YXV0aGVudGljYXRpb24gbWVjaGFuaXNtcy48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsg
PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtOb3RlIHRoYXQgdGhp
cyBzcGVjaWZpY2F0aW9uIG9ubHkNCmRlZmluZXMgYWJzdHJhY3QgPGJyPg0KJmd0OyBtZXNzYWdl
IGZsb3dzIGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7cHJv
Y2Vzc2luZyBydWxlcy4gJm5ic3A7SW4gb3JkZXINCnRvIGJlIGltcGxlbWVudGFibGUsIGNvbXBh
bmlvbjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7c3BlY2lmaWNh
dGlvbnMgYXJlIG5lY2Vzc2FyeSB0byBwcm92aWRlDQp0aGUgY29ycmVzcG9uZGluZyBjb25jcmV0
ZTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7aW5zdGFudGlhdGlv
bnMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn
dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn
dDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgZmlsZSBjYW4g
YmUgb2J0YWluZWQgdmlhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IGh0dHA6Ly9kYXRh
dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLzxicj4NCiZn
dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgSUVT
RyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg
Jmd0OyBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtb2F1dGgtYXNz
ZXJ0aW9ucy9iYWxsb3QvPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsg
Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgTm8gSVBS
IGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4gc3VibWl0dGVkIGRpcmVjdGx5DQpvbiB0aGlzIEktRC48
YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm
Z3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBP
QXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGhAaWV0
Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0
OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgT0F1dGhA
aWV0Zi5vcmc8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGggPC9mb250PjwvdHQ+DQo=
--=_alternative 00103FB948257AD4_=--

From sakimura@gmail.com  Fri Dec 14 07:03:08 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54F2721F85A6; Fri, 14 Dec 2012 07:03:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.387
X-Spam-Level: 
X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=-1.261, BAYES_00=-2.599, FRT_FOLLOW2=0.422, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJwSOU6+ywNa; Fri, 14 Dec 2012 07:03:07 -0800 (PST)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB4821F85B2; Fri, 14 Dec 2012 07:03:06 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id a1so1367336eaa.31 for ; Fri, 14 Dec 2012 07:03:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type; bh=9f6srO+WaskT2GHpL3jWm/WP6g6wjWYzjvVLYZQ92Lc=; b=GZS6gHSPS06F1fMMB9bNaGipXe6rYP8DoSzJC/dmivbfwQzmoB1uxD9T1zBvferPcx 2iAvGiX9kSSJOv8R7QDIA2JmnSdQYvzslhVg5H4PcSYqFztzJ+vpsSy9ypO9dpJicYKN snWaswf8Eg6evG32YsWrqM1fzIhK4fGJKWcoxjqUoRAcp5kSyJCcov9WWufoG517afax NH+aDhcO2DFVgyq5ehi/Lv1gX0ip5YHHb+wHR08aEJxEaEdLTSiyOe3ACzopctjbX4ei urSpI9RGtgJLQf4ufrAFekNQ7FXICSAOL2TdufkRnyPvGOW7k31PaE+XrJJ5joZRDI7Y tjzg==
Received: by 10.14.214.132 with SMTP id c4mr15764163eep.18.1355497385339; Fri, 14 Dec 2012 07:03:05 -0800 (PST)
References: 
From: Nat Sakimura 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Date: Sat, 15 Dec 2012 00:02:58 +0900
Message-ID: <-5196739590250615087@unknownmsgid>
To: "zhou.sujing@zte.com.cn" 
Content-Type: multipart/alternative; boundary=047d7b621df825ad2504d0d15442
Cc: "oauth@ietf.org" , "oauth-bounces@ietf.org" , "ietf@ietf.org" 
Subject: Re: [OAUTH-WG] Last Call:  (Assertion Framework for OAuth 2.0) to Proposed Standard
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 15:03:08 -0000

--047d7b621df825ad2504d0d15442
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

FYI, I have been writing HoK for JWT/JWS Token by introducing a new claim
'cid'.

=3Dnat via iPhone

Dec 14, 2012 11:56=A1=A2"zhou.sujing@zte.com.cn"  =
=A4=CE=A5=E1=A5=C3=A5=BB=A9`=A5=B8:


Yep, could do it soon later.

Currently, I suggest a modification for

 "The token service is the assertion issuer; its  role is to fulfill
requests from clients, which present various
 credentials, and mint assertions as requested, fill them with  appropriate
information, and sign them."  (in  section 3 )

into

 "The token service is the assertion issuer, *it could be implemented in
any entity besides client, e.g., Resource Owner, Authorization Server;* its
 role is to fulfill requests from clients, which present various
 credentials, and mint assertions as requested, fill them with  appropriate
information, and sign them."



Chuck Mortimore  =D0=B4=D3=DA 2012-12-14 10:44:0=
5:

> Correct.   That said no one has yet profiled it for holder of key
>
> - cmort
>
> On Dec 13, 2012, at 6:39 PM, "zhou.sujing@zte.com.cn" <
zhou.sujing@zte.com.cn
> > wrote:

>
> Oh, But the description of assertion generation in the document
> should not be limited by bear assertion, right?
>
>
> Chuck Mortimore  =D0=B4=D3=DA 2012-12-14 10:34=
:13:
>
> > You want a holder of key pattern.  The draft touches on it
> >
> >
> >    The protocol parameters and processing rules defined in this documen=
t
> >    are intended to support a client presenting a bearer assertion to an
> >    authorization server.  The use of holder-of-key assertions are not
> >    precluded by this document, but additional protocol details would
> >    need to be specified.
>
> >
> > So - if you want this, you should put forth a holder of key
> > profiling of this draft and see if there are any issues.   The only
> > profiles we have thus far are saml and jwt bearer assertions.
> >
> >
> > - cmort
> >
> > On Dec 13, 2012, at 6:27 PM, "zhou.sujing@zte.com.cn"  sujing@zte.com.cn
> > > wrote:
>
> >
> > I am not sure if the following usecase  http://www.ietf.org/mail-
> > archive/web/oauth/current/msg10233.html
> > could be supported by assertion framework=A3=AC
> > We have some discussion in
> > http://www.ietf.org/mail-archive/web/oauth/current/msg10203.html
> > http://www.ietf.org/mail-archive/web/oauth/current/msg10198.html
> >
> > In my use case or in some other cases, assertions don't need
> > confidential protection,
> > basically STS don't have to authenticate a client before issueing
> > "assertion", if it could be called assertion here.
> >
> > Example,I trust my laywer, I may issue an "assertion" stating
> > delegation in advance, and send to the lawyer when it is needed,
> > it could be I give the assertion to a false lawyer, but it does not
> > matter, because the lawyer has to prove he knows some credential
> > corresponding to his ID,
> > who is delegated some rights.
> >
> > If assertion framework want to support this use case, then
> > generation of assertion should be relaxed,
> > otherwise new work is required to support the use case.
> >
> >
> >
> > Chuck Mortimore  =D0=B4=D3=DA 2012-12-14 10:=
08:34:
> >
> > > On Dec 13, 2012, at 4:30 PM, "zhou.sujing@zte.com.cn"  > sujing@zte.com.cn
> > > > wrote:
> >
> > >
> > > From the language, I got an impression that assertion is only
> > > generated by token service after clients presenting some credentials,
> > > there are may be some cases that "assertion" don't need client's
> > credential.
> > > e.g., Resource owner as a token service  could generate "assertion"
> > > to a client he trusts, bu signing a statement that "This delegation
> > > is given to a client called clinet-id
> > > for doing something for me".
> > >
> > > So how does the STS trust the client?   Presumably if it is trusted
> > > it has some level of authentication, yes?
> > >
> > > -cmort
> > >
> > >
> > >
> > >
> > >
> > > Chuck Mortimore  =D0=B4=D3=DA 2012-12-14 0=
0:39:03:
> > >
> > > > The language is simply meant to help illustrate how the framework
> > > > might be used.   How do you think it will restrict usage?   How
> > > > could it be improved?
> > > >
> > > > -cmort
> > > >
> > > > On Dec 12, 2012, at 11:04 PM,  wrote:
> > > >
> > > >
> > > > In "section 3
> > > >  The token service is the assertion issuer; its
> > > >  role is to fulfill requests from clients, which present various
> > > >  credentials, and mint assertions as requested, fill them with
> > > >  appropriate information, and sign them."
> > > >
> > > >
> > > > As I understand, an assertion generated by a STS, is done flollowin=
g
> > > > thess steps:
> > > > 1. Client presents credential and requests an assertion
> > > > 2. STS generates assertion and sends to Client
> > > > Correct?
> > > >
> > > > That may restrict the use cases that this assertion framework
> > > could support,
> > > > is it a must?
> > > >
> > > >
> > > >
> > > >
> > > > oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-11 02:33:57:
> > > >
> > > > >
> > > > > The IESG has received a request from the Web Authorization
Protocol WG
> > > > > (oauth) to consider the following document:
> > > > > - 'Assertion Framework for OAuth 2.0'
> > > > >    as Proposed Standard
> > > > >
> > > > > The IESG plans to make a decision in the next few weeks, and
solicits
> > > > > final comments on this action. Please send substantive comments
to the
> > > > > ietf@ietf.org mailing lists by 2012-12-24. Exceptionally,
> > comments may be
> > > > > sent to iesg@ietf.org instead. In either case, please retain the
> > > > > beginning of the Subject line to allow automated sorting.
> > > > >
> > > > > Abstract
> > > > >
> > > > >
> > > > >    This specification provides a framework for the use of
assertions
> > > > >    with OAuth 2.0 in the form of a new client
authenticationmechanism
> > > > >    and a new authorization grant type.  Mechanisms are specified
for
> > > > >    transporting assertions during interactions with a token
> endpoint, as
> > > > >    well as general processing rules.
> > > > >
> > > > >    The intent of this specification is to provide a common
> framework for
> > > > >    OAuth 2.0 to interwork with other identity systems using
> assertions,
> > > > >    and to provide alternative client authentication mechanisms.
> > > > >
> > > > >    Note that this specification only defines abstract
> message flows and
> > > > >    processing rules.  In order to be implementable, companion
> > > > >    specifications are necessary to provide the corresponding
concrete
> > > > >    instantiations.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The file can be obtained via
> > > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/
> > > > >
> > > > > IESG discussion can be tracked via
> > > > >
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/ballot/
> > > > >
> > > > >
> > > > > No IPR declarations have been submitted directly on this I-D.
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > OAuth mailing 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

--047d7b621df825ad2504d0d15442
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable


FYI, I have been writing HoK for J=
WT/JWS Token by introducing a new claim 'cid'. 

=3Dnat =
via iPhone



Dec 14, 2012 11:56=A1=A2"zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn> =A4=CE=A5=E1=A5=C3=A5=BB=A9`=A5=B8=
:





Yep, could do it soon later. 



Currently, I suggest a modification
for 



 "The token service is the
assertion issuer; its  role is to fulfill requests from clients, which
present various 

 credentials, and mint assertions
as requested, fill them with  appropriate information, and sign them.&=
quot;
 (in  section 3 )



into 



 "The token service is the
assertion issuer, it could be implemented in any entity besides client,
e.g., Resource Owner, Authorization Server; its  role is to fulfil=
l
requests from clients, which present various  credentials,
and mint assertions as requested, fill them with  appropriate informat=
ion,
and sign them." 







Chuck Mortimore <cmortimore@salesforce.com>
=D0=B4=D3=DA 2012-12-14 10:44:05:



> Correct.   That said no one has yet profiled it for holder of
key

> 

> - cmort

> 

> On Dec 13, 2012, at 6:39 PM, "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn

> > wrote:



> 

> Oh, But the description of assertion generation in the document 

> should not be limited by bear assertion, right? 

> 

> 

> Chuck Mortimore <cmort=
imore@salesforce.com> =D0=B4=D3=DA 2012-12-14
10:34:13:

> 

> > You want a holder of key pattern.  The draft touches on
it 

> > 

> > 

> >    The protocol parameters and processing rules defined
in this document

> >    are intended to support a client presenting a bearer
assertion to an

> >    authorization server.  The use of holder-of-key
assertions are not

> >    precluded by this document, but additional protocol
details would

> >    need to be specified.

> 

> > 

> > So - if you want this, you should put forth a holder of key 

> > profiling of this draft and see if there are any issues.  
The only 

> > profiles we have thus far are saml and jwt bearer assertions.
  

> > 

> > 

> > - cmort 

> > 

> > On Dec 13, 2012, at 6:27 PM, "zhou.sujing@zte.com.cn"
<zhou.

> sujing@zte.com.cn

> > > wrote:

> 

> > 

> > I am not sure if the following usecase  http://www.ietf.org/mail-

> > archive/web/oauth/current/msg10233.html 

> > could be supported by assertion framework=A3=AC 

> > We have some discussion in   

> > http://www.ietf.org/mail-archive/web/oauth/current/msg10203.htm=
l


> > http://www.ietf.org/mail-archive/web/oauth/current/msg10198.htm=
l


> > 

> > In my use case or in some other cases, assertions don't need


> > confidential protection, 

> > basically STS don't have to authenticate a client before issu=
eing


> > "assertion", if it could be called assertion here.


> > 

> > Example,I trust my laywer, I may issue an "assertion"
stating 

> > delegation in advance, and send to the lawyer when it is needed,


> > it could be I give the assertion to a false lawyer, but it does
not 

> > matter, because the lawyer has to prove he knows some credential


> > corresponding to his ID, 

> > who is delegated some rights. 

> > 

> > If assertion framework want to support this use case, then 

> > generation of assertion should be relaxed, 

> > otherwise new work is required to support the use case. 

> > 

> > 

> > 

> > Chuck Mortimore <=
cmortimore@salesforce.com> =D0=B4=D3=DA 2012-12-14
10:08:34:

> > 

> > > On Dec 13, 2012, at 4:30 PM, "zhou.sujing@zte.com.cn"
<zhou.

> > sujing@zte.com.cn

> > > > wrote:

> > 

> > > 

> > > From the language, I got an impression that assertion is
only 

> > > generated by token service after clients presenting some
credentials, 

> > > there are may be some cases that "assertion" don&#=
39;t
need client's 

> > credential. 

> > > e.g., Resource owner as a token service  could generate
"assertion" 

> > > to a client he trusts, bu signing a statement that "Thi=
s
delegation 

> > > is given to a client called clinet-id 

> > > for doing something for me". 

> > > 

> > > So how does the STS trust the client?   Presumably
if it is trusted 

> > > it has some level of authentication, yes? 

> > > 

> > > -cmort 

> > > 

> > > 

> > > 

> > > 

> > > 

> > > Chuck Mortimore <cmortimore@salesforce.com> =D0=B4=D3=DA
2012-12-14 00:39:03:

> > > 

> > > > The language is simply meant to help illustrate how
the framework 

> > > > might be used.   How do you think it will restrict
usage?   How 

> > > > could it be improved? 

> > > > 

> > > > -cmort 

> > > > 

> > > > On Dec 12, 2012, at 11:04 PM, <zhou.sujing@zte.com.cn>
wrote: 

> > > > 

> > > > 

> > > > In "section 3 

> > > >  The token service is the assertion issuer; its


> > > >  role is to fulfill requests from clients, which
present various 

> > > >  credentials, and mint assertions as requested,
fill them with 

> > > >  appropriate information, and sign them."


> > > > 

> > > > 

> > > > As I understand, an assertion generated by a STS, is
done flollowing

> > > > thess steps: 

> > > > 1. Client presents credential and requests an assertion


> > > > 2. STS generates assertion and sends to Client 

> > > > Correct? 

> > > > 

> > > > That may restrict the use cases that this assertion
framework 

> > > could support, 

> > > > is it a must? 

> > > > 

> > > > 

> > > > 

> > > > 

> > > > oauth-bounces=
@ietf.org =D0=B4=D3=DA 2012-12-11 02:33:57:

> > > > 

> > > > > 

> > > > > The IESG has received a request from the Web Autho=
rization
Protocol WG

> > > > > (oauth) to consider the following document:

> > > > > - 'Assertion Framework for OAuth 2.0'

> > > > >   <draft-ietf-oauth-assertions-08.txt>
as Proposed Standard

> > > > > 

> > > > > The IESG plans to make a decision in the next
few weeks, and solicits

> > > > > final comments on this action. Please send substan=
tive
comments to the

> > > > > ietf@ietf.org=
 mailing lists by 2012-12-24. Exceptionally,


> > comments may be

> > > > > sent to iesg@ietf=
.org instead. In either case,
please retain the

> > > > > beginning of the Subject line to allow automated
sorting.

> > > > > 

> > > > > Abstract

> > > > > 

> > > > > 

> > > > >    This specification provides a framewo=
rk
for the use of assertions

> > > > >    with OAuth 2.0 in the form of a new
client authenticationmechanism

> > > > >    and a new authorization grant type.
 Mechanisms are specified for

> > > > >    transporting assertions during intera=
ctions
with a token 

> endpoint, as

> > > > >    well as general processing rules.

> > > > > 

> > > > >    The intent of this specification
is to provide a common 

> framework for

> > > > >    OAuth 2.0 to interwork with other
identity systems using 

> assertions,

> > > > >    and to provide alternative client
authentication mechanisms.

> > > > > 

> > > > >    Note that this specification only
defines abstract 

> message flows and

> > > > >    processing rules.  In order
to be implementable, companion

> > > > >    specifications are necessary to provi=
de
the corresponding concrete

> > > > >    instantiations.

> > > > > 

> > > > > 

> > > > > 

> > > > > 

> > > > > The file can be obtained via

> > > > > http://datatracker.ietf.org/doc/draft-ietf-oauth-ass=
ertions/

> > > > > 

> > > > > IESG discussion can be tracked via

> > > > > http://datatracker.ietf.org/doc/draft-ietf-oa=
uth-assertions/ballot/

> > > > > 

> > > > > 

> > > > > No IPR declarations have been submitted directly
on this I-D.

> > > > > 

> > > > > 

> > > > > _______________________________________________
> > > > > OAuth mailing 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
<=
span>OAuth@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org=
/mailman/listinfo/oauth




--047d7b621df825ad2504d0d15442--

From bcampbell@pingidentity.com  Fri Dec 14 13:15:03 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B980D21F8AD5 for ; Fri, 14 Dec 2012 13:15:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.75
X-Spam-Level: 
X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[AWL=1.026,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVQmIyId-h-6 for ; Fri, 14 Dec 2012 13:14:59 -0800 (PST)
Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB5F21F8AFB for ; Fri, 14 Dec 2012 13:14:59 -0800 (PST)
Received: from mail-yh0-f70.google.com ([209.85.213.70]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKUMuW0s8nZf0sbODKoNOAgko4GsKeCqGw@postini.com; Fri, 14 Dec 2012 13:14:59 PST
Received: by mail-yh0-f70.google.com with SMTP id o21so5165079yho.1 for ; Fri, 14 Dec 2012 13:14:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=KCMMFoeeIHfJi5Gu1eYwyHj26Awv6PaXe2Puh5QQiKM=; b=lVEMZ3JDC+q3ezk8P7yDWEpjosnj2uDopQ/1So45clTtHoRYXk/n1Zj6I6jWWRxaQW RgIlANnyJ/xgeI+DzVIC+9Sg0/GkwuxCYd7fe1MBfBCoi+BYrwOJ6cFb873dRg3iJaca fLOB9DWj3CRHm4hwRqudz0Pa9WS0S+VeH7eu1jQNkSRN3n1f/JNCd7Cv6dzHOSBmH4Yb iHjtALtacw7suV4wqY3NqX9IRek9F5TM9JM5p21y7HU82e4tZxI3Pt6lmoq+YCfmyXZQ FC8BU2QrM/YUTfF8jA23jDYf39ClOWRsCw2W/5ujkrie/uGwZMik6ZeA/U8ig90a/twb pBNA==
Received: by 10.52.33.228 with SMTP id u4mr9952891vdi.4.1355519698250; Fri, 14 Dec 2012 13:14:58 -0800 (PST)
Received: by 10.52.33.228 with SMTP id u4mr9952876vdi.4.1355519698096; Fri, 14 Dec 2012 13:14:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.163.170 with HTTP; Fri, 14 Dec 2012 13:14:28 -0800 (PST)
In-Reply-To: <59E470B10C4630419ED717AC79FCF9A92F1B2F99@BY2PRD0411MB441.namprd04.prod.outlook.com>
References: <59E470B10C4630419ED717AC79FCF9A92F1B2F99@BY2PRD0411MB441.namprd04.prod.outlook.com>
From: Brian Campbell 
Date: Fri, 14 Dec 2012 14:14:28 -0700
Message-ID: 
To: Lewis Adam-CAL022 
Content-Type: multipart/alternative; boundary=20cf307d03c217533f04d0d68688
X-Gm-Message-State: ALoCoQmGj+pQiGddghnAJsGvldtJXuyhjwOwJlZPsv38ILPBD+8SS+BaWOmRcAQYkf6LZ5A0rnljkQbfs5xnze4XDq53iGzcf4tarwVimMK/4VqexKhL+K6ajClYix/oW6n7tZRWPioh
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Using structured access_token as grant type in assertion flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 14 Dec 2012 21:15:03 -0000

--20cf307d03c217533f04d0d68688
Content-Type: text/plain; charset=ISO-8859-1

Maybe I'm missing the bigger picture but, if your going back to the same AS
like the diagram shows, why not just request the xyz scope in the initial
request and cut out the middle steps?

More generally I can say I've thought about these kinds of token exchange
cases and they should be possible in theory. In practice I expect getting
everything to work and validate correctly with respect to scopes and
audience values might be a little tricky.


On Mon, Dec 10, 2012 at 7:34 AM, Lewis Adam-CAL022 <
Adam.Lewis@motorolasolutions.com> wrote:

> Hi,
>
> I continue to have an interest in the OAuth assertion profiles for my use
> cases.  I'm wondering if the idea of performing a first OAuth dance which
> returns to the client a structured JWT access token (with scope=AS for
> example) could then be used as the JWT in an assertion grant type?  So
> something like this (I show the RO credential flow since it is the simplest
> to draw, but same idea for the code flow):
>
>
> Client          AS
> |                       |
> |---------------->| (authorization request scope=AS, grant_type=RO
> password credentials)
> |                       |
> |<----------------| (token response with access_token scoped to AS)
> |                       |
> |---------------->| (authorization request, scope=xyz, grant_type=JWT
> assertion as obtained from previous step)
> |                       |
> |<----------------| (token response with access token scoped to xyz)
>
>
>
> I suppose there is nothing in theory which should prevent this, but I am
> wondering if anybody else has thought of such a usage.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

Maybe I'm missing the bigger picture but, if your going back to the sam=
e AS like the diagram shows, why not just request the xyz scope in the init=
ial request and cut out the middle steps?

More generally I can say I=
've thought about these kinds of token exchange cases and they should b=
e possible in theory. In practice I expect getting everything to work and v=
alidate correctly with respect to scopes and audience values might be a lit=
tle tricky.





On Mon, Dec 1=
0, 2012 at 7:34 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolas=
olutions.com> wrote:



Hi,



I continue to have an interest in the OAuth assertion profiles for my use c=
ases. =A0I'm wondering if the idea of performing a first OAuth dance wh=
ich returns to the client a structured JWT access token (with scope=3DAS fo=
r example) could then be used as the JWT in an assertion grant type? =A0So =
something like this (I show the RO credential flow since it is the simplest=
 to draw, but same idea for the code flow):







Client =A0 =A0 =A0 =A0 =A0AS

| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |

|---------------->| (authorization request scope=3DAS, grant_type=3DRO p=
assword credentials)

| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |

|<----------------| (token response with access_token scoped to AS)

| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |

|---------------->| (authorization request, scope=3Dxyz, grant_type=3DJW=
T assertion as obtained from previous step)

| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |

|<----------------| (token response with access token scoped to xyz)







I suppose there is nothing in theory which should prevent this, but I am wo=
ndering if anybody else has thought of such a usage.





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--20cf307d03c217533f04d0d68688--

From sakimura@gmail.com  Fri Dec 14 17:40:05 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD10321F8B67 for ; Fri, 14 Dec 2012 17:40:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.172
X-Spam-Level: 
X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=-1.224, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7oiqquAEIbE for ; Fri, 14 Dec 2012 17:40:05 -0800 (PST)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3E8221F895D for ; Fri, 14 Dec 2012 17:40:04 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id a1so1591878eaa.31 for ; Fri, 14 Dec 2012 17:40:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type; bh=s9scXkULQF/PacuxBWyK/QURIdOubdKaWZSbhjLx9tY=; b=Sd3SCK2FT/RHiM4S4opGB3kqapvl+3WTT9t5nvV6H7X/rGA2kN52MLTOy2v1QPRnSP oSnERQKv44ToApqSXjtjFjpNKZdP0bShhH7mQLRA6KUIo+rKXZYTfEEVkU+UnixvmCoF fkkN1HkxX+zNjUSesEqNylEHNO5eFKBrZNnAkOid/FkqoUzoxEIvWs40+b8wOWQXinch /bSkTSckYKbWASCPR0NchhwCRIHvLX6G/yrIDOUCYGJDUiPPErT93gKd6YT77FB5fHER ECEkQqVIMMyBRUi1NIPnfzprHvB4cTeXIItB1vqMaK1G7ScQTtOOQ+SiQBkAimsUH8WH 4PCw==
Received: by 10.14.3.195 with SMTP id 43mr19499343eeh.36.1355535603856; Fri, 14 Dec 2012 17:40:03 -0800 (PST)
References: <59E470B10C4630419ED717AC79FCF9A92F1B2F99@BY2PRD0411MB441.namprd04.prod.outlook.com> 
From: Nat Sakimura 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Date: Sat, 15 Dec 2012 10:40:03 +0900
Message-ID: <-3958915035989346853@unknownmsgid>
To: Brian Campbell 
Content-Type: multipart/alternative; boundary=047d7b66f23925f5ea04d0da3ab4
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Using structured access_token as grant type in assertion flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 15 Dec 2012 01:40:05 -0000

--047d7b66f23925f5ea04d0da3ab4
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

If I understand correctly, there are multiple devices with clients with the
same client_id involved and you want to revoke individual devices when
needed. You also do not want to store the password.

In a sense, the JWT is working like a device specific password with
distributed verifier. This is a valid and potentially a common pattern.

=nat via iPhone

Dec 15, 2012 6:15$B!"(BBrian Campbell  $B$N%a%C%;!<%8(B:

Maybe I'm missing the bigger picture but, if your going back to the same AS
like the diagram shows, why not just request the xyz scope in the initial
request and cut out the middle steps?

More generally I can say I've thought about these kinds of token exchange
cases and they should be possible in theory. In practice I expect getting
everything to work and validate correctly with respect to scopes and
audience values might be a little tricky.


On Mon, Dec 10, 2012 at 7:34 AM, Lewis Adam-CAL022 <
Adam.Lewis@motorolasolutions.com> wrote:

> Hi,
>
> I continue to have an interest in the OAuth assertion profiles for my use
> cases.  I'm wondering if the idea of performing a first OAuth dance which
> returns to the client a structured JWT access token (with scope=AS for
> example) could then be used as the JWT in an assertion grant type?  So
> something like this (I show the RO credential flow since it is the simplest
> to draw, but same idea for the code flow):
>
>
> Client          AS
> |                       |
> |---------------->| (authorization request scope=AS, grant_type=RO
> password credentials)
> |                       |
> |<----------------| (token response with access_token scoped to AS)
> |                       |
> |---------------->| (authorization request, scope=xyz, grant_type=JWT
> assertion as obtained from previous step)
> |                       |
> |<----------------| (token response with access token scoped to xyz)
>
>
>
> I suppose there is nothing in theory which should prevent this, but I am
> wondering if anybody else has thought of such a usage.
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

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

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


If I understand correctly, there a=
re multiple devices with clients with the same client_id involved and you w=
ant to revoke individual devices when needed. You also do not want to store=
 the password.=C2=A0



In a sense, the JWT is working like a device specific p=
assword with distributed verifier. This is a valid and potentially a common=
 pattern.=C2=A0

=3Dnat via iPhone

Dec 15, 2012 6:15=E3=
=80=81Brian Campbell <bcam=
pbell@pingidentity.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=
=BC=E3=82=B8:


Maybe I'm missing the bigger p=
icture but, if your going back to the same AS like the diagram shows, why n=
ot just request the xyz scope in the initial request and cut out the middle=
 steps?


More generally I can say I've thought about these kinds of token ex=
change cases and they should be possible in theory. In practice I expect ge=
tting everything to work and validate correctly with respect to scopes and =
audience values might be a little tricky.






On Mon, Dec 1=
0, 2012 at 7:34 AM, Lewis Adam-CAL022 <Adam.Lewis@motorolas=
olutions.com> wrote:




Hi,



I continue to have an interest in the OAuth assertion profiles for my use c=
ases. =C2=A0I'm wondering if the idea of performing a first OAuth dance=
 which returns to the client a structured JWT access token (with scope=3DAS=
 for example) could then be used as the JWT in an assertion grant type? =C2=
=A0So something like this (I show the RO credential flow since it is the si=
mplest to draw, but same idea for the code flow):








Client =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0AS

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 |

|---------------->| (authorization request scope=3DAS, grant_type=3DRO p=
assword credentials)

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 |

|<----------------| (token response with access_token scoped to AS)

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 |

|---------------->| (authorization request, scope=3Dxyz, grant_type=3DJW=
T assertion as obtained from previous step)

| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 |

|<----------------| (token response with access token scoped to xyz)







I suppose there is nothing in theory which should prevent this, but I am wo=
ndering if anybody else has thought of such a usage.





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





___________________=
____________________________
OAuth mailing list
<=
span>OAuth@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/oauth">https://www.ietf.org=
/mailman/listinfo/oauth




--047d7b66f23925f5ea04d0da3ab4--

From hannes.tschofenig@gmx.net  Sun Dec 16 11:23:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C31B21F8877 for ; Sun, 16 Dec 2012 11:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.506
X-Spam-Level: 
X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnUAwGuzh5LI for ; Sun, 16 Dec 2012 11:23:30 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 971BB21F8874 for ; Sun, 16 Dec 2012 11:23:30 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Llbtx-1T9sKU1Ts7-00bIIK for ; Sun, 16 Dec 2012 20:23:29 +0100
Received: (qmail invoked by alias); 16 Dec 2012 19:23:29 -0000
Received: from a88-115-211-228.elisa-laajakaista.fi (EHLO [192.168.100.113]) [88.115.211.228] by mail.gmx.net (mp035) with SMTP; 16 Dec 2012 20:23:29 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19z5R0VBIxzIXjSPc7VUqwYpPvMqbEfO2DX0SRc1y GE/zq6R1HT2Flr
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sun, 16 Dec 2012 21:23:27 +0200
Message-Id: 
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Meeting Notes: 14th December 2012 Conference Call
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 16 Dec 2012 19:23:32 -0000

Hi all,=20

here are my notes from the conference call:

---

Date: 14th December 2012

Participants:
 * Derek Atkins
 * Mike Jones
 * Phil Hunt
 * Justin Richer
 * Hannes Tschofenig
 * Thomas Hardjono
 * William Mills

I started the call with a presentation of these slides.=20
http://www.tschofenig.priv.at/OAuth2-Security-14Dec2012.ppt

We had a short discussion about each of these slides.=20

Regarding use case #1 Thomas noted that a channel binding feature may =
give the client/authorization server the ability to detect such a =
scenario.=20
He asked whether it would be useful to add such a feature to the =
protocol.=20

In use case #2 ("unprotected" resource) Bill noted that this is the =
Flickr scenario and Justin suggested that Bill provides more background =
about the motivation for not supporting TLS to the list. This could help =
to better understand why some deployments show reluctance to enable TLS =
support (and therefore need a custom application layer security =
solution).=20

In use case #3 (prevent access token re-use) the conference call =
participants started a discussion about the delegation use cases.

For use case #4 (AS-to-RS relationship anonymity) it was not quite clear =
what the cost of adding support for this functionality is and how it =
interferes with other security features. Needs more investigation.=20

When we started discussing the client instance functionality it became =
clear that this is not necessarily security functionality and should =
therefore be discussed independently. Justin mentioned a draft he =
published some time ago (see =
http://tools.ietf.org/html/draft-richer-oauth-instance-00) and Hannes =
encouraged him to resubmit it. This topic will be discussed =
independently of the security work.=20

The group went a bit overtime already and therefore there was not too =
much time left to discuss the key lifetime topic. It was, however, noted =
that the usage of asymmetric keys may allow larger key lifetime and =
usage of the access token with more than one resource server (since that =
the resource server does not obtain the private key and therefore cannot =
impersonate the client).=20

In general there was fairly good understanding of use cases #1, #2, and =
#3.=20

Action items:
  * Justin will re-submit his "OAuth Client Instance Extension" document=20=

  * Justin to provide a short writeup about the regulatory requirements =
for application layer security.=20
  * Hannes to incorporate a short description about the use cases into =
draft-tschofenig-oauth-security

---=20

Let me know if I missed something. =20

Ciao
Hannes


From hannes.tschofenig@gmx.net  Sun Dec 16 11:30:18 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF8A21F88A2 for ; Sun, 16 Dec 2012 11:30:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.067
X-Spam-Level: 
X-Spam-Status: No, score=-102.067 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzhLXYckxNvN for ; Sun, 16 Dec 2012 11:30:18 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id F3A9E21F88B6 for ; Sun, 16 Dec 2012 11:30:17 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.38]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M68M0-1SvPMC3Ohe-00yDLo for ; Sun, 16 Dec 2012 20:30:14 +0100
Received: (qmail invoked by alias); 16 Dec 2012 19:30:14 -0000
Received: from a88-115-211-228.elisa-laajakaista.fi (EHLO [192.168.100.113]) [88.115.211.228] by mail.gmx.net (mp038) with SMTP; 16 Dec 2012 20:30:14 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19f3LoAXRZfaEH99TVt6uVklHSix3jAdA8HlLYQaq MSJA8EQ931aLYB
From: Hannes Tschofenig 
Content-Type: multipart/alternative; boundary=Apple-Mail-55--578109018
Date: Sun, 16 Dec 2012 21:30:12 +0200
Message-Id: <83DFC39B-404F-44C4-8C4B-6346D573A04C@gmx.net>
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Added Use Cases to 
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 16 Dec 2012 19:30:18 -0000

--Apple-Mail-55--578109018
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all,=20

based on the discussion at the conference call last Friday Phil and I =
have added a short writeup about the use cases.
Here is the relevant part from =
http://tools.ietf.org/html/draft-tschofenig-oauth-security-01
 =20

   6.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     6.1.  Access to an 'Unprotected' Resource  . . . . . . . . . . . 12
     6.2.  Offering Application Layer End-to-End Security . . . . . . 13
     6.3.  Preventing Access Token Re-Use by the Resource Server  . . 13
     6.4.  TLS Channel Binding Support  . . . . . . . . . . . . . . . 14

This draft update was an action item from the last conference call.=20

Let us know if you have comments on the writeup.=20

Ciao
Hannes & Phil


--Apple-Mail-55--578109018
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Hi =
all, 

based on the discussion at the conference =
call last Friday Phil and I have added a short writeup about the use =
cases.
&=
nbsp; 

   6.  Use Cases  . . . . . =
. . . . . . . . . . . . . . . . . . . . . 12
    =
 6.1.  Access to an 'Unprotected' Resource  . . . . . . . =
. . . . 12
     6.2.  Offering =
Application Layer End-to-End Security . . . . . . =
13
     6.3.  Preventing Access Token Re-Use by =
the Resource Server  . . 13
    =
 6.4.  TLS Channel Binding Support  . . . . . . . . . . . =
. . . . 14

This draft update was =
an action item from the last conference =
call. 

Let us know if you have comments on =
the writeup. 

Ciao
Hannes & =
Phil

=

--Apple-Mail-55--578109018--

From hannes.tschofenig@gmx.net  Mon Dec 17 07:21:41 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFE021F8938 for ; Mon, 17 Dec 2012 07:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.495
X-Spam-Level: 
X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGslMB0C+sp5 for ; Mon, 17 Dec 2012 07:21:41 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 633E821F87C7 for ; Mon, 17 Dec 2012 07:21:40 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Lb72N-1THqHK0W8v-00kfuI for ; Mon, 17 Dec 2012 16:21:39 +0100
Received: (qmail invoked by alias); 17 Dec 2012 15:21:38 -0000
Received: from a88-115-211-228.elisa-laajakaista.fi (EHLO [192.168.100.111]) [88.115.211.228] by mail.gmx.net (mp020) with SMTP; 17 Dec 2012 16:21:38 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1+AcuwfyZOAjuk28dcl6y5W7hikHkGX65yYE8Fa4o BkfNsxGT2Wk507
From: Hannes Tschofenig 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 Dec 2012 17:21:36 +0200
Message-Id: 
To: "oauth@ietf.org WG" 
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Subject: [OAUTH-WG] Summary - "Assertion Framework - Why does issuer have to be either the client or a third party token service?"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Dec 2012 15:21:41 -0000

Hi all,=20

I read through the mailing list discussion raised by Nat in this mail to =
the list on the 3rd of December, see =
http://www.ietf.org/mail-archive/web/oauth/current/msg10203.html=20

There were two types of issues:

1) The current text about the issuer (in Section 5.1 of =
 says that the assertion can either =
be created by the client (in which case it is self-signed) or it can be =
created by some other entity.=20

There was, however, the perception that the current text, in the way it =
is worded, creates the impression that third party token services =
excludes entities like the resource owner.=20

2) Some folks had the idea that the resource owner could create the =
assertion and they had a specific use case in mind. While this is not a =
currently deployed scenario (using OAuth technology) there seem to be =
some other deployment (the Austrian eID card deployment was mentioned by =
Nat) that could be re-build with this support in mind.

It seemed that just mentioning that the resource owner could create the =
assertion wouldn't be enough to understand the scenario. A more detailed =
writeup of the envisioned scenario would be needed but has not been =
provided to the mailing list.=20

To me it seems that the best approach would be to do the following: =20

a) to update the text in Section 5.1 as suggested by Nat in his mail =
http://www.ietf.org/mail-archive/web/oauth/current/msg10222.html

This by itself would not lead to any normative text change but may make =
it clear what the intention was.=20

b) to encourage those who care about the use case where the resource =
owner creates the assertion to compile a document and to submit it to =
the group. This would allow us to evaluate whether all the required =
functionality is indeed available.=20

Ciao
Hannes


From Adam.Lewis@motorolasolutions.com  Mon Dec 17 07:39:53 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2641B21F89D3 for ; Mon, 17 Dec 2012 07:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.966
X-Spam-Level: 
X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Gnqz0V8FkdZ for ; Mon, 17 Dec 2012 07:39:50 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7B66F21F8ABB for ; Mon, 17 Dec 2012 07:39:50 -0800 (PST)
Received: from mail15-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE020.bigfish.com (10.236.130.83) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Dec 2012 15:39:49 +0000
Received: from mail15-co9 (localhost [127.0.0.1])	by mail15-co9-R.bigfish.com (Postfix) with ESMTP id CCC952A01BC	for ; Mon, 17 Dec 2012 15:39:49 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:129.188.136.17; KIP:(null); UIP:(null); IPV:NLI; H:il06msg01.mot-solutions.com; RD:none; EFVD:NLI
X-SpamScore: -22
X-BigFish: VPS-22(zz98dI9371Ic85fhd772hzz1de0h1202h1e76h1d1ah1d2ahzz18c673h17326ah8275bh8275dh1033ILz2fh2a8h683h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h1155h)
Received-SPF: pass (mail15-co9: domain of motorolasolutions.com designates 129.188.136.17 as permitted sender) client-ip=129.188.136.17; envelope-from=Adam.Lewis@motorolasolutions.com; helo=il06msg01.mot-solutions.com ; olutions.com ; 
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.237.133; KIP:(null); UIP:(null); (null); H:BY2PRD0411HT003.namprd04.prod.outlook.com; R:internal; EFV:INT
Received: from mail15-co9 (localhost.localdomain [127.0.0.1]) by mail15-co9 (MessageSwitch) id 1355758786371704_30277; Mon, 17 Dec 2012 15:39:46 +0000 (UTC)
Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.230])	by mail15-co9.bigfish.com (Postfix) with ESMTP id 5361320072	for ; Mon, 17 Dec 2012 15:39:46 +0000 (UTC)
Received: from il06msg01.mot-solutions.com (129.188.136.17) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Dec 2012 15:39:42 +0000
Received: from il06msg01.mot-solutions.com (il06vts01.mot.com [129.188.137.141])	by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qBHGYqiR005067	for ; Mon, 17 Dec 2012 10:34:52 -0600 (CST)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185])	by il06msg01.mot-solutions.com (8.14.3/8.14.3) with ESMTP id qBHGYpDi005056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL)	for ; Mon, 17 Dec 2012 10:34:51 -0600 (CST)
Received: from mail153-co1-R.bigfish.com (10.243.78.204) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Mon, 17 Dec 2012 15:39:41 +0000
Received: from mail153-co1 (localhost [127.0.0.1])	by mail153-co1-R.bigfish.com (Postfix) with ESMTP id 3588C800177	for ; Mon, 17 Dec 2012 15:39:41 +0000 (UTC)
Received: from mail153-co1 (localhost.localdomain [127.0.0.1]) by mail153-co1 (MessageSwitch) id 1355758778463304_27155; Mon, 17 Dec 2012 15:39:38 +0000 (UTC)
Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.210])	by mail153-co1.bigfish.com (Postfix) with ESMTP id 61AC1A40069; Mon, 17 Dec 2012 15:39:38 +0000 (UTC)
Received: from BY2PRD0411HT003.namprd04.prod.outlook.com (157.56.237.133) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 17 Dec 2012 15:39:34 +0000
Received: from BY2PRD0411MB441.namprd04.prod.outlook.com ([169.254.5.29]) by BY2PRD0411HT003.namprd04.prod.outlook.com ([10.255.128.38]) with mapi id 14.16.0245.002; Mon, 17 Dec 2012 15:39:33 +0000
From: Lewis Adam-CAL022 
To: Brian Campbell 
Thread-Topic: [OAUTH-WG] Using structured access_token as grant type in assertion flow
Thread-Index: AQHN2kAeMkHiW5STqU2tZnpc6+7sk5gdHggQ
Date: Mon, 17 Dec 2012 15:39:32 +0000
Message-ID: <59E470B10C4630419ED717AC79FCF9A92F1B446F@BY2PRD0411MB441.namprd04.prod.outlook.com>
References: <59E470B10C4630419ED717AC79FCF9A92F1B2F99@BY2PRD0411MB441.namprd04.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [150.130.140.154]
Content-Type: multipart/alternative; boundary="_000_59E470B10C4630419ED717AC79FCF9A92F1B446FBY2PRD0411MB441_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%PINGIDENTITY.COM$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-FOPE-CONNECTOR: Id%1294$Dn%IETF.ORG$RO%2$TLS%3$FQDN%msgate.mot-solutions.com$TlsDn%
X-CFilter-Loop: Reflected
X-OriginatorOrg: motorolasolutions.com
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Using structured access_token as grant type in assertion flow
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 17 Dec 2012 15:39:53 -0000

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

Hi Brian,

Right ... so I suppose looking at that diagram without the background text =
would have been a bit odd :)

In my use case I have an OAuth client that is going to request many access =
tokens, for many different resource servers.  All of these resources server=
s will be protected by the same AS.

(I think this is similar to Google's OAuth in that they have many APIs serv=
ed by many resource servers, which all use the same OAuth authorization end=
point).

My client *could* ask for an access token with enough scopes to cover all t=
he resource server APIs (again, similar for example to the Google OAuth pla=
yground), but this does not meet the assurance levels of my use cases.  RS1=
 has no business possessing an AT that could be used to access protected re=
sources at AS2 and AS2 has no business having the same AT that would allow =
it access protected resource at AS3, and so on.

I have toyed around with the idea making an initial OAuth request with an u=
ber-scope, and then using the refresh token to obtain the down-scoped acces=
s tokens and sending those down-scoped access tokens to the RS's.  But the =
problem I'm running into with this is that my client may not know a priori =
all the RS's it's going to need access tokens for.

So the JWT assertion flow began to look nearly perfect to me.  If you look =
at the diagram again, it should look (very) familiar to something we all gr=
ew up with: Kerberos!  The first exchange is to obtain the TGT, and the sub=
sequent exchange uses the TGT to get a service ticket.  So using this analo=
gy:

Kerberos TGT =3D JWT assertion
Kerberos TGS =3D access token

I can use the JWT assertion obtained in step 1 to request access tokens on =
the fly for resource servers at the client needs to access them, just as th=
e TGT is used to obtain the TGS on-demand.

I think this is totally within the realm of reason.  We will likely prototy=
pe this idea very early next year (Jan/Feb).

-adam

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Friday, December 14, 2012 3:14 PM
To: Lewis Adam-CAL022
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Using structured access_token as grant type in asse=
rtion flow

Maybe I'm missing the bigger picture but, if your going back to the same AS=
 like the diagram shows, why not just request the xyz scope in the initial =
request and cut out the middle steps?

More generally I can say I've thought about these kinds of token exchange c=
ases and they should be possible in theory. In practice I expect getting ev=
erything to work and validate correctly with respect to scopes and audience=
 values might be a little tricky.

On Mon, Dec 10, 2012 at 7:34 AM, Lewis Adam-CAL022 > wrote:
Hi,

I continue to have an interest in the OAuth assertion profiles for my use c=
ases.  I'm wondering if the idea of performing a first OAuth dance which re=
turns to the client a structured JWT access token (with scope=3DAS for exam=
ple) could then be used as the JWT in an assertion grant type?  So somethin=
g like this (I show the RO credential flow since it is the simplest to draw=
, but same idea for the code flow):


Client          AS
|                       |
|---------------->| (authorization request scope=3DAS, grant_type=3DRO pass=
word credentials)
|                       |
|<----------------| (token response with access_token scoped to AS)
|                       |
|---------------->| (authorization request, scope=3Dxyz, grant_type=3DJWT a=
ssertion as obtained from previous step)
|                       |
|<----------------| (token response with access token scoped to xyz)



I suppose there is nothing in theory which should prevent this, but I am wo=
ndering if anybody else has thought of such a usage.


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


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











Hi Brian,=



 

Right … so I suppose =
looking at that diagram without the background text would have been a bit o=
dd :)


 

In my use case I have an OA=
uth client that is going to request many access tokens, for many different =
resource servers.  All of these resources servers will be
 protected by the same AS.  


 

(I think this is similar to=
 Google’s OAuth in that they have many APIs served by many resource s=
ervers, which all use the same OAuth authorization endpoint).


 

My client *could* as=
k for an access token with enough scopes to cover all the resource server A=
PIs (again, similar for example to the Google OAuth playground),
 but this does not meet the assurance levels of my use cases.  RS1 has=
 no business possessing an AT that could be used to access protected resour=
ces at AS2 and AS2 has no business having the same AT that would allow it a=
ccess protected resource at AS3, and
 so on.  


 

I have toyed around with th=
e idea making an initial OAuth request with an uber-scope, and then using t=
he refresh token to obtain the down-scoped access tokens
 and sending those down-scoped access tokens to the RS’s.  But t=
he problem I’m running into with this is that my client may not know =
a priori all the RS’s it’s going to need access tokens for.&nbs=
p;



 

So the JWT assertion flow b=
egan to look nearly perfect to me.  If you look at the diagram again, =
it should look (very) familiar to something we all grew up with:
 Kerberos!  The first exchange is to obtain the TGT, and the subsequen=
t exchange uses the TGT to get a service ticket.  So using this analog=
y:


 

Kerberos TGT =3D JWT assert=
ion


Kerberos TGS =3D access tok=
en


 

I can use the JWT assertion=
 obtained in step 1 to request access tokens on the fly for resource server=
s at the client needs to access them, just as the TGT is
 used to obtain the TGS on-demand.  


 

I think this is totally wit=
hin the realm of reason.  We will likely prototype this idea very earl=
y next year (Jan/Feb).


 

-adam


 



From: Brian Ca=
mpbell [mailto:bcampbell@pingidentity.com]


Sent: Friday, December 14, 2012 3:14 PM

To: Lewis Adam-CAL022

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Using structured access_token as grant type =
in assertion flow




 


Maybe I'm missing the bigger picture but, if your go=
ing back to the same AS like the diagram shows, why not just request the xy=
z scope in the initial request and cut out the middle steps?



More generally I can say I've thought about these kinds of token exchange c=
ases and they should be possible in theory. In practice I expect getting ev=
erything to work and validate correctly with respect to scopes and audience=
 values might be a little tricky.




 




On Mon, Dec 10, 2012 at 7:34 AM, Lewis Adam-CAL022 &=
lt;Ad=
am.Lewis@motorolasolutions.com> wrote:


Hi,



I continue to have an interest in the OAuth assertion profiles for my use c=
ases.  I'm wondering if the idea of performing a first OAuth dance whi=
ch returns to the client a structured JWT access token (with scope=3DAS for=
 example) could then be used as the JWT
 in an assertion grant type?  So something like this (I show the RO cr=
edential flow since it is the simplest to draw, but same idea for the code =
flow):





Client          AS

|                     &nb=
sp; |

|---------------->| (authorization request scope=3DAS, grant_type=3DRO p=
assword credentials)

|                     &nb=
sp; |

|<----------------| (token response with access_token scoped to AS)

|                     &nb=
sp; |

|---------------->| (authorization request, scope=3Dxyz, grant_type=3DJW=
T assertion as obtained from previous step)

|                     &nb=
sp; |

|<----------------| (token response with access token scoped to xyz)







I suppose there is nothing in theory which should prevent this, but I am wo=
ndering if anybody else has thought of such a usage.





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




 








--_000_59E470B10C4630419ED717AC79FCF9A92F1B446FBY2PRD0411MB441_--

From zhou.sujing@zte.com.cn  Mon Dec 17 16:30:00 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE9E21E8039; Mon, 17 Dec 2012 16:30:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.165
X-Spam-Level: 
X-Spam-Status: No, score=-98.165 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjULiMGMqnbE; Mon, 17 Dec 2012 16:29:59 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3DB21E802E; Mon, 17 Dec 2012 16:29:59 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 7D711125581F; Tue, 18 Dec 2012 08:31:52 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qBI0TkPP018862; Tue, 18 Dec 2012 08:29:46 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Hannes Tschofenig 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Tue, 18 Dec 2012 08:29:41 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-18 08:29:42, Serialize complete at 2012-12-18 08:29:42
Content-Type: multipart/alternative; boundary="=_alternative 0002D8A448257AF7_="
X-MAIL: mse01.zte.com.cn qBI0TkPP018862
Cc: "oauth@ietf.org WG" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Summary - "Assertion Framework - Why does issuer have to be either the client or a third party token service?"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Dec 2012 00:30:00 -0000

This is a multipart message in MIME format.
--=_alternative 0002D8A448257AF7_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

b2F1dGgtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTItMTItMTcgMjM6MjE6MzY6DQoNCj4gSGkg
YWxsLCANCj4gDQo+IEkgcmVhZCB0aHJvdWdoIHRoZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiBy
YWlzZWQgYnkgTmF0IGluIHRoaXMgDQo+IG1haWwgdG8gdGhlIGxpc3Qgb24gdGhlIDNyZCBvZiBE
ZWNlbWJlciwgc2VlIGh0dHA6Ly93d3cuaWV0Zi4NCj4gb3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1
dGgvY3VycmVudC9tc2cxMDIwMy5odG1sIA0KPiANCj4gVGhlcmUgd2VyZSB0d28gdHlwZXMgb2Yg
aXNzdWVzOg0KPiANCj4gMSkgVGhlIGN1cnJlbnQgdGV4dCBhYm91dCB0aGUgaXNzdWVyIChpbiBT
ZWN0aW9uIDUuMSBvZiA8ZHJhZnQtaWV0Zi0NCj4gb2F1dGgtYXNzZXJ0aW9ucy0wOC50eHQ+IHNh
eXMgdGhhdCB0aGUgYXNzZXJ0aW9uIGNhbiBlaXRoZXIgYmUgDQo+IGNyZWF0ZWQgYnkgdGhlIGNs
aWVudCAoaW4gd2hpY2ggY2FzZSBpdCBpcyBzZWxmLXNpZ25lZCkgb3IgaXQgY2FuIGJlDQo+IGNy
ZWF0ZWQgYnkgc29tZSBvdGhlciBlbnRpdHkuIA0KPiANCj4gVGhlcmUgd2FzLCBob3dldmVyLCB0
aGUgcGVyY2VwdGlvbiB0aGF0IHRoZSBjdXJyZW50IHRleHQsIGluIHRoZSB3YXkNCj4gaXQgaXMg
d29yZGVkLCBjcmVhdGVzIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhpcmQgcGFydHkgdG9rZW4gc2Vy
dmljZXMNCj4gZXhjbHVkZXMgZW50aXRpZXMgbGlrZSB0aGUgcmVzb3VyY2Ugb3duZXIuIA0KPiAN
Cj4gMikgU29tZSBmb2xrcyBoYWQgdGhlIGlkZWEgdGhhdCB0aGUgcmVzb3VyY2Ugb3duZXIgY291
bGQgY3JlYXRlIHRoZSANCj4gYXNzZXJ0aW9uIGFuZCB0aGV5IGhhZCBhIHNwZWNpZmljIHVzZSBj
YXNlIGluIG1pbmQuIFdoaWxlIHRoaXMgaXMgDQo+IG5vdCBhIGN1cnJlbnRseSBkZXBsb3llZCBz
Y2VuYXJpbyAodXNpbmcgT0F1dGggdGVjaG5vbG9neSkgdGhlcmUgDQo+IHNlZW0gdG8gYmUgc29t
ZSBvdGhlciBkZXBsb3ltZW50ICh0aGUgQXVzdHJpYW4gZUlEIGNhcmQgZGVwbG95bWVudCANCj4g
d2FzIG1lbnRpb25lZCBieSBOYXQpIHRoYXQgY291bGQgYmUgcmUtYnVpbGQgd2l0aCB0aGlzIHN1
cHBvcnQgaW4gbWluZC4NCj4gDQo+IEl0IHNlZW1lZCB0aGF0IGp1c3QgbWVudGlvbmluZyB0aGF0
IHRoZSByZXNvdXJjZSBvd25lciBjb3VsZCBjcmVhdGUgDQo+IHRoZSBhc3NlcnRpb24gd291bGRu
J3QgYmUgZW5vdWdoIHRvIHVuZGVyc3RhbmQgdGhlIHNjZW5hcmlvLiBBIG1vcmUgDQo+IGRldGFp
bGVkIHdyaXRldXAgb2YgdGhlIGVudmlzaW9uZWQgc2NlbmFyaW8gd291bGQgYmUgbmVlZGVkIGJ1
dCBoYXMgDQo+IG5vdCBiZWVuIHByb3ZpZGVkIHRvIHRoZSBtYWlsaW5nIGxpc3QuIA0KPiANCj4g
VG8gbWUgaXQgc2VlbXMgdGhhdCB0aGUgYmVzdCBhcHByb2FjaCB3b3VsZCBiZSB0byBkbyB0aGUg
Zm9sbG93aW5nOiANCj4gDQo+IGEpIHRvIHVwZGF0ZSB0aGUgdGV4dCBpbiBTZWN0aW9uIDUuMSBh
cyBzdWdnZXN0ZWQgYnkgTmF0IGluIGhpcyBtYWlsIA0KPiBodHRwOi8vd3d3LmlldGYub3JnL21h
aWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMDIyMi5odG1sDQoNCk5hdCdzIHN1Z2dl
c3Rpb24gIkV4YW1wbGUgb2YgaXNzdWVycyBpbmNsdWRlIGFuIE9BdXRoIGNsaWVudCwgcmVzb3Vy
Y2UgDQpvd25lciwgYW4gaW5kZXBlbmRlbnQgdGhpcmQgcGFydHkuIg0KdGhlcmUgaXMgc3RpbGwg
YW4gaXNzdWUsICAiaW5kZW5wZW5kZW50IiBmcm9tIHdobz8gIElmICBBUyBiZSBhbiBhc3NlcnRp
b24gDQppc3N1ZXIsIGNvdWxkIEFTIGJlIGNhbGxlZCBpbmRlbnBlbmRlbnQ/IA0KDQoNCj4gVGhp
cyBieSBpdHNlbGYgd291bGQgbm90IGxlYWQgdG8gYW55IG5vcm1hdGl2ZSB0ZXh0IGNoYW5nZSBi
dXQgbWF5IA0KPiBtYWtlIGl0IGNsZWFyIHdoYXQgdGhlIGludGVudGlvbiB3YXMuIA0KPiANCj4g
YikgdG8gZW5jb3VyYWdlIHRob3NlIHdobyBjYXJlIGFib3V0IHRoZSB1c2UgY2FzZSB3aGVyZSB0
aGUgcmVzb3VyY2UNCj4gb3duZXIgY3JlYXRlcyB0aGUgYXNzZXJ0aW9uIHRvIGNvbXBpbGUgYSBk
b2N1bWVudCBhbmQgdG8gc3VibWl0IGl0IA0KPiB0byB0aGUgZ3JvdXAuIFRoaXMgd291bGQgYWxs
b3cgdXMgdG8gZXZhbHVhdGUgd2hldGhlciBhbGwgdGhlIA0KPiByZXF1aXJlZCBmdW5jdGlvbmFs
aXR5IGlzIGluZGVlZCBhdmFpbGFibGUuIA0KPiANCj4gQ2lhbw0KPiBIYW5uZXMNCj4gDQo+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1h
aWxpbmcgbGlzdA0KPiBPQXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoDQoNCg==
--=_alternative 0002D8A448257AF7_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5vYXV0aC1ib3VuY2VzQGlldGYub3JnINC009og
MjAxMi0xMi0xNyAyMzoyMTozNjo8YnI+DQo8YnI+DQomZ3Q7IEhpIGFsbCwgPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IEkgcmVhZCB0aHJvdWdoIHRoZSBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiByYWlz
ZWQgYnkgTmF0IGluIHRoaXMgPGJyPg0KJmd0OyBtYWlsIHRvIHRoZSBsaXN0IG9uIHRoZSAzcmQg
b2YgRGVjZW1iZXIsIHNlZSBodHRwOi8vd3d3LmlldGYuPGJyPg0KJmd0OyBvcmcvbWFpbC1hcmNo
aXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEwMjAzLmh0bWwgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7
IFRoZXJlIHdlcmUgdHdvIHR5cGVzIG9mIGlzc3Vlczo8YnI+DQomZ3Q7IDxicj4NCiZndDsgMSkg
VGhlIGN1cnJlbnQgdGV4dCBhYm91dCB0aGUgaXNzdWVyIChpbiBTZWN0aW9uIDUuMSBvZiAmbHQ7
ZHJhZnQtaWV0Zi08YnI+DQomZ3Q7IG9hdXRoLWFzc2VydGlvbnMtMDgudHh0Jmd0OyBzYXlzIHRo
YXQgdGhlIGFzc2VydGlvbiBjYW4gZWl0aGVyIGJlDQo8YnI+DQomZ3Q7IGNyZWF0ZWQgYnkgdGhl
IGNsaWVudCAoaW4gd2hpY2ggY2FzZSBpdCBpcyBzZWxmLXNpZ25lZCkgb3IgaXQgY2FuDQpiZTxi
cj4NCiZndDsgY3JlYXRlZCBieSBzb21lIG90aGVyIGVudGl0eS4gPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IFRoZXJlIHdhcywgaG93ZXZlciwgdGhlIHBlcmNlcHRpb24gdGhhdCB0aGUgY3VycmVudCB0
ZXh0LCBpbiB0aGUgd2F5PGJyPg0KJmd0OyBpdCBpcyB3b3JkZWQsIGNyZWF0ZXMgdGhlIGltcHJl
c3Npb24gdGhhdCB0aGlyZCBwYXJ0eSB0b2tlbiBzZXJ2aWNlczxicj4NCiZndDsgZXhjbHVkZXMg
ZW50aXRpZXMgbGlrZSB0aGUgcmVzb3VyY2Ugb3duZXIuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAy
KSBTb21lIGZvbGtzIGhhZCB0aGUgaWRlYSB0aGF0IHRoZSByZXNvdXJjZSBvd25lciBjb3VsZCBj
cmVhdGUgdGhlDQo8YnI+DQomZ3Q7IGFzc2VydGlvbiBhbmQgdGhleSBoYWQgYSBzcGVjaWZpYyB1
c2UgY2FzZSBpbiBtaW5kLiBXaGlsZSB0aGlzIGlzDQo8YnI+DQomZ3Q7IG5vdCBhIGN1cnJlbnRs
eSBkZXBsb3llZCBzY2VuYXJpbyAodXNpbmcgT0F1dGggdGVjaG5vbG9neSkgdGhlcmUgPGJyPg0K
Jmd0OyBzZWVtIHRvIGJlIHNvbWUgb3RoZXIgZGVwbG95bWVudCAodGhlIEF1c3RyaWFuIGVJRCBj
YXJkIGRlcGxveW1lbnQNCjxicj4NCiZndDsgd2FzIG1lbnRpb25lZCBieSBOYXQpIHRoYXQgY291
bGQgYmUgcmUtYnVpbGQgd2l0aCB0aGlzIHN1cHBvcnQgaW4NCm1pbmQuPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IEl0IHNlZW1lZCB0aGF0IGp1c3QgbWVudGlvbmluZyB0aGF0IHRoZSByZXNvdXJjZSBv
d25lciBjb3VsZCBjcmVhdGUNCjxicj4NCiZndDsgdGhlIGFzc2VydGlvbiB3b3VsZG4ndCBiZSBl
bm91Z2ggdG8gdW5kZXJzdGFuZCB0aGUgc2NlbmFyaW8uIEEgbW9yZQ0KPGJyPg0KJmd0OyBkZXRh
aWxlZCB3cml0ZXVwIG9mIHRoZSBlbnZpc2lvbmVkIHNjZW5hcmlvIHdvdWxkIGJlIG5lZWRlZCBi
dXQgaGFzDQo8YnI+DQomZ3Q7IG5vdCBiZWVuIHByb3ZpZGVkIHRvIHRoZSBtYWlsaW5nIGxpc3Qu
IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUbyBtZSBpdCBzZWVtcyB0aGF0IHRoZSBiZXN0IGFwcHJv
YWNoIHdvdWxkIGJlIHRvIGRvIHRoZSBmb2xsb3dpbmc6DQombmJzcDs8YnI+DQomZ3Q7IDxicj4N
CiZndDsgYSkgdG8gdXBkYXRlIHRoZSB0ZXh0IGluIFNlY3Rpb24gNS4xIGFzIHN1Z2dlc3RlZCBi
eSBOYXQgaW4gaGlzIG1haWwNCjxicj4NCiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy
Y2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAyMjIuaHRtbDxicj4NCjwvZm9udD48L3R0Pg0K
PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5OYXQncyBzdWdnZXN0aW9uIDwvZm9u
dD48Zm9udCBzaXplPTMgY29sb3I9IzIyMjIyMiBmYWNlPSJBcmlhbCI+JnF1b3Q7RXhhbXBsZQ0K
b2YgaXNzdWVycyBpbmNsdWRlIGFuIE9BdXRoIGNsaWVudCwgcmVzb3VyY2Ugb3duZXIsIGFuIGlu
ZGVwZW5kZW50IHRoaXJkDQpwYXJ0eS4mcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGNv
bG9yPSMyMjIyMjIgZmFjZT0iQXJpYWwiPnRoZXJlIGlzIHN0aWxsIGFuIGlzc3VlLCAmbmJzcDsm
cXVvdDtpbmRlbnBlbmRlbnQmcXVvdDsNCmZyb20gd2hvPyAmbmJzcDtJZiAmbmJzcDtBUyBiZSBh
biBhc3NlcnRpb24gaXNzdWVyLCBjb3VsZCBBUyBiZSBjYWxsZWQNCmluZGVucGVuZGVudD8gJm5i
c3A7PC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBUaGlzIGJ5
IGl0c2VsZiB3b3VsZCBub3QgbGVhZCB0byBhbnkgbm9ybWF0aXZlIHRleHQgY2hhbmdlIGJ1dCBt
YXkNCjxicj4NCiZndDsgbWFrZSBpdCBjbGVhciB3aGF0IHRoZSBpbnRlbnRpb24gd2FzLiA8YnI+
DQomZ3Q7IDxicj4NCiZndDsgYikgdG8gZW5jb3VyYWdlIHRob3NlIHdobyBjYXJlIGFib3V0IHRo
ZSB1c2UgY2FzZSB3aGVyZSB0aGUgcmVzb3VyY2U8YnI+DQomZ3Q7IG93bmVyIGNyZWF0ZXMgdGhl
IGFzc2VydGlvbiB0byBjb21waWxlIGEgZG9jdW1lbnQgYW5kIHRvIHN1Ym1pdCBpdA0KPGJyPg0K
Jmd0OyB0byB0aGUgZ3JvdXAuIFRoaXMgd291bGQgYWxsb3cgdXMgdG8gZXZhbHVhdGUgd2hldGhl
ciBhbGwgdGhlIDxicj4NCiZndDsgcmVxdWlyZWQgZnVuY3Rpb25hbGl0eSBpcyBpbmRlZWQgYXZh
aWxhYmxlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ2lhbzxicj4NCiZndDsgSGFubmVzPGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IE9BdXRoQGlldGYu
b3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PGJyPg0KPC9mb250PjwvdHQ+DQo=
--=_alternative 0002D8A448257AF7_=--

From zhou.sujing@zte.com.cn  Tue Dec 18 00:59:12 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AD021F87BC; Tue, 18 Dec 2012 00:59:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.18
X-Spam-Level: 
X-Spam-Status: No, score=-98.18 tagged_above=-999 required=5 tests=[AWL=0.215,  BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHsOHvP9e91j; Tue, 18 Dec 2012 00:59:12 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id B77BD21F87B2; Tue, 18 Dec 2012 00:59:11 -0800 (PST)
Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 40AAD1292E7D; Tue, 18 Dec 2012 17:01:05 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id qBI8wnhX012511; Tue, 18 Dec 2012 16:58:49 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Hannes Tschofenig 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Tue, 18 Dec 2012 16:58:46 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-18 16:58:46, Serialize complete at 2012-12-18 16:58:46
Content-Type: multipart/alternative; boundary="=_alternative 0031740848257AF7_="
X-MAIL: mse01.zte.com.cn qBI8wnhX012511
Cc: "oauth@ietf.org WG" , oauth-bounces@ietf.org
Subject: Re: [OAUTH-WG] Summary - "Assertion Framework - Why does issuer have to be either the client or a third party token service?"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Dec 2012 08:59:13 -0000

This is a multipart message in MIME format.
--=_alternative 0031740848257AF7_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

SGksDQoNCm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTEyLTE3IDIzOjIxOjM2Og0K
DQo+IEhpIGFsbCwgDQo+IA0KPiBJIHJlYWQgdGhyb3VnaCB0aGUgbWFpbGluZyBsaXN0IGRpc2N1
c3Npb24gcmFpc2VkIGJ5IE5hdCBpbiB0aGlzIA0KPiBtYWlsIHRvIHRoZSBsaXN0IG9uIHRoZSAz
cmQgb2YgRGVjZW1iZXIsIHNlZSBodHRwOi8vd3d3LmlldGYuDQo+IG9yZy9tYWlsLWFyY2hpdmUv
d2ViL29hdXRoL2N1cnJlbnQvbXNnMTAyMDMuaHRtbCANCj4gDQo+IFRoZXJlIHdlcmUgdHdvIHR5
cGVzIG9mIGlzc3VlczoNCj4gDQo+IDEpIFRoZSBjdXJyZW50IHRleHQgYWJvdXQgdGhlIGlzc3Vl
ciAoaW4gU2VjdGlvbiA1LjEgb2YgPGRyYWZ0LWlldGYtDQo+IG9hdXRoLWFzc2VydGlvbnMtMDgu
dHh0PiBzYXlzIHRoYXQgdGhlIGFzc2VydGlvbiBjYW4gZWl0aGVyIGJlIA0KPiBjcmVhdGVkIGJ5
IHRoZSBjbGllbnQgKGluIHdoaWNoIGNhc2UgaXQgaXMgc2VsZi1zaWduZWQpIG9yIGl0IGNhbiBi
ZQ0KPiBjcmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5LiANCj4gDQo+IFRoZXJlIHdhcywgaG93
ZXZlciwgdGhlIHBlcmNlcHRpb24gdGhhdCB0aGUgY3VycmVudCB0ZXh0LCBpbiB0aGUgd2F5DQo+
IGl0IGlzIHdvcmRlZCwgY3JlYXRlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoaXJkIHBhcnR5IHRv
a2VuIHNlcnZpY2VzDQo+IGV4Y2x1ZGVzIGVudGl0aWVzIGxpa2UgdGhlIHJlc291cmNlIG93bmVy
LiANCj4gDQo+IDIpIFNvbWUgZm9sa3MgaGFkIHRoZSBpZGVhIHRoYXQgdGhlIHJlc291cmNlIG93
bmVyIGNvdWxkIGNyZWF0ZSB0aGUgDQo+IGFzc2VydGlvbiBhbmQgdGhleSBoYWQgYSBzcGVjaWZp
YyB1c2UgY2FzZSBpbiBtaW5kLiBXaGlsZSB0aGlzIGlzIA0KPiBub3QgYSBjdXJyZW50bHkgZGVw
bG95ZWQgc2NlbmFyaW8gKHVzaW5nIE9BdXRoIHRlY2hub2xvZ3kpIHRoZXJlIA0KPiBzZWVtIHRv
IGJlIHNvbWUgb3RoZXIgZGVwbG95bWVudCAodGhlIEF1c3RyaWFuIGVJRCBjYXJkIGRlcGxveW1l
bnQgDQo+IHdhcyBtZW50aW9uZWQgYnkgTmF0KSB0aGF0IGNvdWxkIGJlIHJlLWJ1aWxkIHdpdGgg
dGhpcyBzdXBwb3J0IGluIG1pbmQuDQoNCmVJRCBpcyBmb3IgZWdvdmVybm1lbnQuIE1heSBiZSBp
dCBjb3VsZCwgYnV0IHRoZSB1c2UgY2FzZSBpcyBpbiB0aGUgc2NvcGUgDQpvZiBvYXV0aC4gDQoN
Cj4gSXQgc2VlbWVkIHRoYXQganVzdCBtZW50aW9uaW5nIHRoYXQgdGhlIHJlc291cmNlIG93bmVy
IGNvdWxkIGNyZWF0ZSANCj4gdGhlIGFzc2VydGlvbiB3b3VsZG4ndCBiZSBlbm91Z2ggdG8gdW5k
ZXJzdGFuZCB0aGUgc2NlbmFyaW8uIEEgbW9yZSANCj4gZGV0YWlsZWQgd3JpdGV1cCBvZiB0aGUg
ZW52aXNpb25lZCBzY2VuYXJpbyB3b3VsZCBiZSBuZWVkZWQgYnV0IGhhcyANCj4gbm90IGJlZW4g
cHJvdmlkZWQgdG8gdGhlIG1haWxpbmcgbGlzdC4gDQpJIGhhdmUsIGJ1dCBpcyBidXJpZWQgaW4g
dGhlIG1haWxpbmcgbGlzdCwgbm93IEkgYWRkZWQgbW9kaWZpZWQgdXNlY2FzZXMgDQppbnRvIA0K
YSByZS1zdWJtaXR0ZWQgZG9jdW1lbnQuIA0KDQo+IFRvIG1lIGl0IHNlZW1zIHRoYXQgdGhlIGJl
c3QgYXBwcm9hY2ggd291bGQgYmUgdG8gZG8gdGhlIGZvbGxvd2luZzogDQo+IA0KPiBhKSB0byB1
cGRhdGUgdGhlIHRleHQgaW4gU2VjdGlvbiA1LjEgYXMgc3VnZ2VzdGVkIGJ5IE5hdCBpbiBoaXMg
bWFpbCANCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJl
bnQvbXNnMTAyMjIuaHRtbA0KPiANCj4gVGhpcyBieSBpdHNlbGYgd291bGQgbm90IGxlYWQgdG8g
YW55IG5vcm1hdGl2ZSB0ZXh0IGNoYW5nZSBidXQgbWF5IA0KPiBtYWtlIGl0IGNsZWFyIHdoYXQg
dGhlIGludGVudGlvbiB3YXMuIA0KPiANCj4gYikgdG8gZW5jb3VyYWdlIHRob3NlIHdobyBjYXJl
IGFib3V0IHRoZSB1c2UgY2FzZSB3aGVyZSB0aGUgcmVzb3VyY2UNCj4gb3duZXIgY3JlYXRlcyB0
aGUgYXNzZXJ0aW9uIHRvIGNvbXBpbGUgYSBkb2N1bWVudCBhbmQgdG8gc3VibWl0IGl0IA0KPiB0
byB0aGUgZ3JvdXAuIFRoaXMgd291bGQgYWxsb3cgdXMgdG8gZXZhbHVhdGUgd2hldGhlciBhbGwg
dGhlIA0KPiByZXF1aXJlZCBmdW5jdGlvbmFsaXR5IGlzIGluZGVlZCBhdmFpbGFibGUuIA0KDQpJ
IGhhdmUgcmUtc3VibWl0dGVkIGEgcmVsZXZhbnQgZG9jdW1lbnQgDQphdCBodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC16aG91LW9hdXRoLW93bmVyLWF1dGgtMDENCiAgDQoNCj4gDQo+
IENpYW8NCj4gSGFubmVzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmcNCj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQo=
--=_alternative 0031740848257AF7_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi
cj48dHQ+PGZvbnQgc2l6ZT0yPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTEyLTE3
IDIzOjIxOjM2Ojxicj4NCjxicj4NCiZndDsgSGkgYWxsLCA8YnI+DQomZ3Q7IDxicj4NCiZndDsg
SSByZWFkIHRocm91Z2ggdGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIHJhaXNlZCBieSBOYXQg
aW4gdGhpcyA8YnI+DQomZ3Q7IG1haWwgdG8gdGhlIGxpc3Qgb24gdGhlIDNyZCBvZiBEZWNlbWJl
ciwgc2VlIGh0dHA6Ly93d3cuaWV0Zi48YnI+DQomZ3Q7IG9yZy9tYWlsLWFyY2hpdmUvd2ViL29h
dXRoL2N1cnJlbnQvbXNnMTAyMDMuaHRtbCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlcmUgd2Vy
ZSB0d28gdHlwZXMgb2YgaXNzdWVzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAxKSBUaGUgY3VycmVu
dCB0ZXh0IGFib3V0IHRoZSBpc3N1ZXIgKGluIFNlY3Rpb24gNS4xIG9mICZsdDtkcmFmdC1pZXRm
LTxicj4NCiZndDsgb2F1dGgtYXNzZXJ0aW9ucy0wOC50eHQmZ3Q7IHNheXMgdGhhdCB0aGUgYXNz
ZXJ0aW9uIGNhbiBlaXRoZXIgYmUNCjxicj4NCiZndDsgY3JlYXRlZCBieSB0aGUgY2xpZW50IChp
biB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2lnbmVkKSBvciBpdCBjYW4NCmJlPGJyPg0KJmd0OyBj
cmVhdGVkIGJ5IHNvbWUgb3RoZXIgZW50aXR5LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlcmUg
d2FzLCBob3dldmVyLCB0aGUgcGVyY2VwdGlvbiB0aGF0IHRoZSBjdXJyZW50IHRleHQsIGluIHRo
ZSB3YXk8YnI+DQomZ3Q7IGl0IGlzIHdvcmRlZCwgY3JlYXRlcyB0aGUgaW1wcmVzc2lvbiB0aGF0
IHRoaXJkIHBhcnR5IHRva2VuIHNlcnZpY2VzPGJyPg0KJmd0OyBleGNsdWRlcyBlbnRpdGllcyBs
aWtlIHRoZSByZXNvdXJjZSBvd25lci4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIpIFNvbWUgZm9s
a3MgaGFkIHRoZSBpZGVhIHRoYXQgdGhlIHJlc291cmNlIG93bmVyIGNvdWxkIGNyZWF0ZSB0aGUN
Cjxicj4NCiZndDsgYXNzZXJ0aW9uIGFuZCB0aGV5IGhhZCBhIHNwZWNpZmljIHVzZSBjYXNlIGlu
IG1pbmQuIFdoaWxlIHRoaXMgaXMNCjxicj4NCiZndDsgbm90IGEgY3VycmVudGx5IGRlcGxveWVk
IHNjZW5hcmlvICh1c2luZyBPQXV0aCB0ZWNobm9sb2d5KSB0aGVyZSA8YnI+DQomZ3Q7IHNlZW0g
dG8gYmUgc29tZSBvdGhlciBkZXBsb3ltZW50ICh0aGUgQXVzdHJpYW4gZUlEIGNhcmQgZGVwbG95
bWVudA0KPGJyPg0KJmd0OyB3YXMgbWVudGlvbmVkIGJ5IE5hdCkgdGhhdCBjb3VsZCBiZSByZS1i
dWlsZCB3aXRoIHRoaXMgc3VwcG9ydCBpbg0KbWluZC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv
bnQgc2l6ZT0yPjxicj4NCmVJRCBpcyBmb3IgZWdvdmVybm1lbnQuIE1heSBiZSBpdCBjb3VsZCwg
YnV0IHRoZSB1c2UgY2FzZSBpcyBpbiB0aGUgc2NvcGUNCm9mIG9hdXRoLiAmbmJzcDs8YnI+DQo8
L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgSXQgc2VlbWVkIHRoYXQganVz
dCBtZW50aW9uaW5nIHRoYXQgdGhlIHJlc291cmNlDQpvd25lciBjb3VsZCBjcmVhdGUgPGJyPg0K
Jmd0OyB0aGUgYXNzZXJ0aW9uIHdvdWxkbid0IGJlIGVub3VnaCB0byB1bmRlcnN0YW5kIHRoZSBz
Y2VuYXJpby4gQSBtb3JlDQo8YnI+DQomZ3Q7IGRldGFpbGVkIHdyaXRldXAgb2YgdGhlIGVudmlz
aW9uZWQgc2NlbmFyaW8gd291bGQgYmUgbmVlZGVkIGJ1dCBoYXMNCjxicj4NCiZndDsgbm90IGJl
ZW4gcHJvdmlkZWQgdG8gdGhlIG1haWxpbmcgbGlzdC4gPGJyPg0KSSBoYXZlLCBidXQgaXMgYnVy
aWVkIGluIHRoZSBtYWlsaW5nIGxpc3QsIG5vdyBJIGFkZGVkIG1vZGlmaWVkIHVzZWNhc2VzDQpp
bnRvIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+YSByZS1zdWJtaXR0ZWQgZG9j
dW1lbnQuIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBUbyBt
ZSBpdCBzZWVtcyB0aGF0IHRoZSBiZXN0IGFwcHJvYWNoIHdvdWxkIGJlIHRvIGRvIHRoZSBmb2xs
b3dpbmc6DQombmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgYSkgdG8gdXBkYXRlIHRoZSB0ZXh0
IGluIFNlY3Rpb24gNS4xIGFzIHN1Z2dlc3RlZCBieSBOYXQgaW4gaGlzIG1haWwNCjxicj4NCiZn
dDsgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNn
MTAyMjIuaHRtbDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGJ5IGl0c2VsZiB3b3VsZCBub3Qg
bGVhZCB0byBhbnkgbm9ybWF0aXZlIHRleHQgY2hhbmdlIGJ1dCBtYXkNCjxicj4NCiZndDsgbWFr
ZSBpdCBjbGVhciB3aGF0IHRoZSBpbnRlbnRpb24gd2FzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg
YikgdG8gZW5jb3VyYWdlIHRob3NlIHdobyBjYXJlIGFib3V0IHRoZSB1c2UgY2FzZSB3aGVyZSB0
aGUgcmVzb3VyY2U8YnI+DQomZ3Q7IG93bmVyIGNyZWF0ZXMgdGhlIGFzc2VydGlvbiB0byBjb21w
aWxlIGEgZG9jdW1lbnQgYW5kIHRvIHN1Ym1pdCBpdA0KPGJyPg0KJmd0OyB0byB0aGUgZ3JvdXAu
IFRoaXMgd291bGQgYWxsb3cgdXMgdG8gZXZhbHVhdGUgd2hldGhlciBhbGwgdGhlIDxicj4NCiZn
dDsgcmVxdWlyZWQgZnVuY3Rpb25hbGl0eSBpcyBpbmRlZWQgYXZhaWxhYmxlLiA8L2ZvbnQ+PC90
dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgaGF2ZSByZS1zdWJtaXR0ZWQgYSByZWxl
dmFudCBkb2N1bWVudCA8L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTI+YXQgaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhvdS1vYXV0aC1vd25lci1hdXRoLTAxPC9mb250Pg0K
PGJyPjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZn
dDsgQ2lhbzxicj4NCiZndDsgSGFubmVzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWls
aW5nIGxpc3Q8YnI+DQomZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KPC9mb250PjwvdHQ+DQo=
--=_alternative 0031740848257AF7_=--

From bcampbell@pingidentity.com  Tue Dec 18 13:41:37 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDAD21E8039 for ; Tue, 18 Dec 2012 13:41:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.463
X-Spam-Level: 
X-Spam-Status: No, score=-4.463 tagged_above=-999 required=5 tests=[AWL=1.512,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mjx3VkJtqAC6 for ; Tue, 18 Dec 2012 13:41:36 -0800 (PST)
Received: from na3sys009aog137.obsmtp.com (na3sys009aog137.obsmtp.com [74.125.149.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9934C21F86CD for ; Tue, 18 Dec 2012 13:41:36 -0800 (PST)
Received: from mail-qc0-f199.google.com ([209.85.216.199]) (using TLSv1) by na3sys009aob137.postini.com ([74.125.148.12]) with SMTP ID DSNKUNDjEHiD+b6NZsdQvm3Qklzfflwv2vOf@postini.com; Tue, 18 Dec 2012 13:41:36 PST
Received: by mail-qc0-f199.google.com with SMTP id b40so1769252qcq.2 for ; Tue, 18 Dec 2012 13:41:35 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=hr0ypP1NQkZTeu0uv0TqYHfQNUt1AiYlPJiQO//wspw=; b=ItRM1ngiAfj01E283D7R5nqJpb1FFzNp62/kQDkcbrqDnwEm89YxC7usrM/J+3WL21 Lq4OLpqMx9wQ0dz/jbiBDTGlZw1/ztC36qacgeCnSZ65baYyiKOxtjcJoEwv/feqWh8Z ZI/AhqLi2bdPcOKSJszgSKrpcMwyEsxIrJN//lj93x11FoykGo13VDIFAhZ2Pf6V2zFh v1TtCPgwFJuEUAJSERvxKfCtmt+b4cQMEDV0jLN+oqqQiJc/rDBUiaULAU6s9CauhhrS 1b3XxTUTOlAwllhY3XgPDSVIcPcBhVHBzYoJ0/22WzfovsMK6Ymz0yOm+AvsaQpYy1rC CCRQ==
X-Received: by 10.220.141.206 with SMTP id n14mr5432452vcu.64.1355866895545; Tue, 18 Dec 2012 13:41:35 -0800 (PST)
Received: by 10.220.141.206 with SMTP id n14mr5432441vcu.64.1355866895354; Tue, 18 Dec 2012 13:41:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.163.170 with HTTP; Tue, 18 Dec 2012 13:41:05 -0800 (PST)
From: Brian Campbell 
Date: Tue, 18 Dec 2012 14:41:05 -0700
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=f46d042f9d48a90ab304d1275c3a
X-Gm-Message-State: ALoCoQmJRwP9wTNCEVEEK2xMIn1pOt7UNs+R3bxzUB9jd1WW21fOIHI6G+4tdrljd4OPXAVHzwo3EPWcSslOby4hpJDhs4wzMIY0BWJC8OrbqRPO1G/opz9EmB+Y8Pk8AuWxC7A9Kk8x
Subject: [OAUTH-WG] JWT audience claim
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Dec 2012 21:41:37 -0000

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

WG folks,

I'm wondering if the current definition of the "aud" (audience) claim in
JWT [1], which limits the value of the claim to a case sensitive string
containing a StringOrURI value, might not be flexible enough?

In thinking about or discussing various potential applications of JWT, the
possibility of having a token intended for consumption by more than one
entity has come up frequently. One such example would be an AS that is
using JWTs as structured access tokens intended for use at multiple RSs and
wants to audience restrict those access tokens. Doing that with the current
JWT and "aud" claim could be rather awkward in that a single aud value
would need to somehow represent multiple entities, which seems likely to be
done in very application specific ways that would not result in much
interoperability. Scope is potentially applicable in this case but isn't
standardized at that level and wouldn't be useful outside of OAuth specific
applications.

At a high level, I'm proposing that we consider changing the definition of
"aud" to allow for an array of StringOrURI values. And change the
processing requirement such that the thing consuming the claim must
identify itself with [at least] one of the values of the "aud" claim array.
That would allow a JWT AT that's intended for consumption by RS 1, 2 and 3
to be audience restricted like this, "aud": ["RS1", "RS2", "RS3"] and an
individual RS just needs to find itself in one of the values of the claim.

Such a change would add some complexity but I'm beginning to think that
it's a good trade off for the added flexibility it brings. The validation
would be basically the same but just over a list of values rather than
against a single one. We would have to decide whether the case of a single
audience could still be represented as it is now or if everything would
always have to be an array (i.e. "aud": "RS" vs. "aud": ["RS"] ). The
former introduces slightly more complexity to validation but is a nice
optimization for the common case and would preserve compatibility with
existing implementations.

Thoughts, comments, questions, or angry diatribes?

Thanks,
Brian

[1]
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.5

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

WG folks,

I'm wondering if the current definition of the "a=
ud" (audience) claim in JWT [1], which limits the value of the claim t=
o a case sensitive string containing a StringOrURI value, might not be flex=
ible enough?



In thinking about or discussing various potential applications of JWT, =
the possibility of having a token intended for consumption by more than one=
 entity has come up frequently. One such example would be an AS that is usi=
ng JWTs as structured access tokens intended for use at multiple RSs and wa=
nts to audience restrict those access tokens. Doing that with the current J=
WT and "aud" claim could be rather awkward in that a single aud v=
alue would need to somehow represent multiple entities, which seems likely =
to be done in very application specific ways that would not result in much =
interoperability. Scope is potentially applicable in this case but isn'=
t standardized at that level and wouldn't be useful outside of OAuth sp=
ecific applications. =A0 



At a high level, I'm proposing that we consider changing the defini=
tion of "aud" to allow for an array of StringOrURI values. And ch=
ange the processing requirement such that the thing consuming the claim mus=
t identify itself with [at least] one of the values of the "aud" =
claim array. That would allow a JWT AT that's intended for consumption =
by RS 1, 2 and 3 to be audience restricted like this, "aud": [&qu=
ot;RS1", "RS2", "RS3"] and an individual RS just n=
eeds to find itself in one of the values of the claim.



Such a change would add some complexity but I'm beginning to think =
that it's a good trade off for the added flexibility it brings. The val=
idation would be basically the same but just over a list of values rather t=
han against a single one. We would have to decide whether the case of a sin=
gle audience could still be represented as it is now or if everything would=
 always have to be an array (i.e. "aud": "RS" vs. "=
;aud": ["RS"] ). The former introduces slightly more complex=
ity to validation but is a nice optimization for the common case and would =
preserve compatibility with existing implementations. 



Thoughts, comments, questions, or angry diatribes?

Thanks,
Br=
ian

 [1]=A0 http://tools.ietf.org/html/draft-ietf-oauth=
-json-web-token-05#section-4.1.5=A0 



--f46d042f9d48a90ab304d1275c3a--

From ve7jtb@ve7jtb.com  Tue Dec 18 14:14:55 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB77021E8054 for ; Tue, 18 Dec 2012 14:14:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.31
X-Spam-Level: 
X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=0.288,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5p5Racn-0oyG for ; Tue, 18 Dec 2012 14:14:54 -0800 (PST)
Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8A60921E8039 for ; Tue, 18 Dec 2012 14:14:54 -0800 (PST)
Received: by mail-yh0-f42.google.com with SMTP id g71so312873yhg.15 for ; Tue, 18 Dec 2012 14:14:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=fUfhv4+U6qtwjhvxoKc/nPQPx4x86c50ZWJj7kFW2PM=; b=oMhMBg/GlR2Pkf4y8K6jYOdsN9mv1A5y/S5bLTCroszAEk4u5ut6vGcV2emNyS+JnR yB8g38z93SXaQf4MOeGDrlYZWVDKHOvT4ghc42ykXiizW3d2N3pj1acOqVagpH2UWlcB LppSR2+W+HL+vvBq1KH1poeGYusJe+IiQyeeI35fc9dcNIOFLgTlgFmQZYwzO/HoffOD U3EL2S13IQfa45N2JSrzP09htIXqXvDnYhdskZRc9IoR6p7NMnllhtxTUgnGmPFsZRCr 9Fvkalr3anSht/qi6F1nKlGsQzeMM7BCznkcMetN2cx9oWrD6AGGPJUR7xj7/SW7Kn30 0MzQ==
X-Received: by 10.236.74.198 with SMTP id x46mr3602109yhd.72.1355868894045; Tue, 18 Dec 2012 14:14:54 -0800 (PST)
Received: from [192.168.1.211] (190-20-36-100.baf.movistar.cl. [190.20.36.100]) by mx.google.com with ESMTPS id a43sm2869988yhl.0.2012.12.18.14.14.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 14:14:53 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_42B2CD45-61D6-4B66-990D-DA349086AABE"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 18 Dec 2012 19:14:33 -0300
Message-Id: <22543C20-08E2-4587-9EFE-BCC0BC292119@ve7jtb.com>
References: 
To: Brian Campbell 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmaeMq5g+9Rp/qEe6qF2WnOH8EgJlYWw1e1W0EDeh0Fii03EWXLm/qoYTfgcujaoYI/vCQs
Cc: oauth 
Subject: Re: [OAUTH-WG] JWT audience claim
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Dec 2012 22:14:55 -0000

--Apple-Mail=_42B2CD45-61D6-4B66-990D-DA349086AABE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

We probably also need to consider this in light of people like Google =
already adding new JWT claims to specify a secondary audience, though =
there 'cid' Client ID claim is more about who requested the token.

I am not keen on claims that are sometimes a literal and sometimes an =
array, though it works in JSON it can be confusing.

Are you proposing that aud us always an array with one or more values, =
or that it is a literal if it is one value and array if more than one?

The other way to deal with it is having a abstract audience that all the =
recipients recognize.  Though that has its own issues.

Having one way to do it would be better, I just don't have a good =
feeling that it is worth complicating the simple case where there is =
only one audience.

I might be convinced of the utility for aud to be an array if you need =
mopre than one value and leave the single case as a literal.

John B.

On 2012-12-18, at 6:41 PM, Brian Campbell  =
wrote:

> WG folks,
>=20
> I'm wondering if the current definition of the "aud" (audience) claim =
in JWT [1], which limits the value of the claim to a case sensitive =
string containing a StringOrURI value, might not be flexible enough?
>=20
> In thinking about or discussing various potential applications of JWT, =
the possibility of having a token intended for consumption by more than =
one entity has come up frequently. One such example would be an AS that =
is using JWTs as structured access tokens intended for use at multiple =
RSs and wants to audience restrict those access tokens. Doing that with =
the current JWT and "aud" claim could be rather awkward in that a single =
aud value would need to somehow represent multiple entities, which seems =
likely to be done in very application specific ways that would not =
result in much interoperability. Scope is potentially applicable in this =
case but isn't standardized at that level and wouldn't be useful outside =
of OAuth specific applications.  =20
>=20
> At a high level, I'm proposing that we consider changing the =
definition of "aud" to allow for an array of StringOrURI values. And =
change the processing requirement such that the thing consuming the =
claim must identify itself with [at least] one of the values of the =
"aud" claim array. That would allow a JWT AT that's intended for =
consumption by RS 1, 2 and 3 to be audience restricted like this, "aud": =
["RS1", "RS2", "RS3"] and an individual RS just needs to find itself in =
one of the values of the claim.
>=20
> Such a change would add some complexity but I'm beginning to think =
that it's a good trade off for the added flexibility it brings. The =
validation would be basically the same but just over a list of values =
rather than against a single one. We would have to decide whether the =
case of a single audience could still be represented as it is now or if =
everything would always have to be an array (i.e. "aud": "RS" vs. "aud": =
["RS"] ). The former introduces slightly more complexity to validation =
but is a nice optimization for the common case and would preserve =
compatibility with existing implementations.=20
>=20
> Thoughts, comments, questions, or angry diatribes?
>=20
> Thanks,
> Brian
>=20
> [1]  =
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.=
5 =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_42B2CD45-61D6-4B66-990D-DA349086AABE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

We =
probably also need to consider this in light of people like Google =
already adding new JWT claims to specify a secondary audience, though =
there 'cid' Client ID claim is more about who requested the =
token.

I am not keen on claims that are sometimes a =
literal and sometimes an array, though it works in JSON it can be =
confusing.

Are you proposing that aud us always =
an array with one or more values, or that it is a literal if it is one =
value and array if more than one?

The other way =
to deal with it is having a abstract audience that all the recipients =
recognize.  Though that has its own =
issues.

Having one way to do it would be =
better, I just don't have a good feeling that it is worth complicating =
the simple case where there is only one =
audience.

I might be convinced of the utility =
for aud to be an array if you need mopre than one value and leave the =
single case as a literal.

John =
B.

On 2012-12-18, at 6:41 PM, Brian Campbell =
<bcampbell@pingidentity.com&=
gt; wrote:

WG folks,

I'm wondering if the current definition =
of the "aud" (audience) claim in JWT [1], which limits the value of the =
claim to a case sensitive string containing a StringOrURI value, might =
not be flexible enough?



In thinking about or discussing various potential applications of =
JWT, the possibility of having a token intended for consumption by more =
than one entity has come up frequently. One such example would be an AS =
that is using JWTs as structured access tokens intended for use at =
multiple RSs and wants to audience restrict those access tokens. Doing =
that with the current JWT and "aud" claim could be rather awkward in =
that a single aud value would need to somehow represent multiple =
entities, which seems likely to be done in very application specific =
ways that would not result in much interoperability. Scope is =
potentially applicable in this case but isn't standardized at that level =
and wouldn't be useful outside of OAuth specific applications.   =




At a high level, I'm proposing that we consider changing the =
definition of "aud" to allow for an array of StringOrURI values. And =
change the processing requirement such that the thing consuming the =
claim must identify itself with [at least] one of the values of the =
"aud" claim array. That would allow a JWT AT that's intended for =
consumption by RS 1, 2 and 3 to be audience restricted like this, "aud": =
["RS1", "RS2", "RS3"] and an individual RS just needs to find itself in =
one of the values of the claim.



Such a change would add some complexity but I'm beginning to think =
that it's a good trade off for the added flexibility it brings. The =
validation would be basically the same but just over a list of values =
rather than against a single one. We would have to decide whether the =
case of a single audience could still be represented as it is now or if =
everything would always have to be an array (i.e. "aud": "RS" vs. "aud": =
["RS"] ). The former introduces slightly more complexity to validation =
but is a nice optimization for the common case and would preserve =
compatibility with existing implementations. 



Thoughts, comments, questions, or angry =
diatribes?

Thanks,
Brian

 [1]  http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#s=
ection-4.1.5  


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

=

--Apple-Mail=_42B2CD45-61D6-4B66-990D-DA349086AABE--

From bcampbell@pingidentity.com  Tue Dec 18 15:16:58 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE9421E8045 for ; Tue, 18 Dec 2012 15:16:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.616
X-Spam-Level: 
X-Spam-Status: No, score=-4.616 tagged_above=-999 required=5 tests=[AWL=1.361,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovxxTuOe4yGM for ; Tue, 18 Dec 2012 15:16:57 -0800 (PST)
Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5D12221F86EA for ; Tue, 18 Dec 2012 15:16:57 -0800 (PST)
Received: from mail-yh0-f71.google.com ([209.85.213.71]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKUND5aTObj5VvXSZnwMvyyhLI/0u60jP6@postini.com; Tue, 18 Dec 2012 15:16:57 PST
Received: by mail-yh0-f71.google.com with SMTP id j63so1900378yhj.6 for ; Tue, 18 Dec 2012 15:16:56 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=3iLI/4mY5Yb9MirBgJ+34eXHM+DQ/XJIAhAwrkCz5W0=; b=KwnENc/tUUq1v/u8kCptkpu5dM1bj6NrY5P5Xs1odWsG7bP7uzHWmaL/Y7FpllkaXs p9Bga/w7FHyBXfnfScoGsL5rrukARgZ9QxY74oDGwpUiFRj/7GL6ssgDM9Fc5nJcniwM Yk/dUjmIe93V/A25s3AkWwIfZKOX/a7/iuwHngwctFPAA8Ym3JQ3ab3gNhfreuxVDM0S +BlboAm4gWAU+6MhBrF4XFdiHwEsimwq5jiCX3nPna1tAbqoIcog2DkXRr4EtaHMd3L5 hg2qXF59aZkv1D7qog3/HIeWzfK8Y6fCiTL1VveFByPGrQ2uELbD0z0TR25sY09liU5u pxyg==
X-Received: by 10.52.37.9 with SMTP id u9mr5103064vdj.83.1355872616516; Tue, 18 Dec 2012 15:16:56 -0800 (PST)
Received: by 10.52.37.9 with SMTP id u9mr5103059vdj.83.1355872616412; Tue, 18 Dec 2012 15:16:56 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.163.170 with HTTP; Tue, 18 Dec 2012 15:16:26 -0800 (PST)
In-Reply-To: <22543C20-08E2-4587-9EFE-BCC0BC292119@ve7jtb.com>
References:  <22543C20-08E2-4587-9EFE-BCC0BC292119@ve7jtb.com>
From: Brian Campbell 
Date: Tue, 18 Dec 2012 16:16:26 -0700
Message-ID: 
To: John Bradley 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmIdLpfQjpJJpNbaBr/L9wnSYi6q3nRuH3386UrVKanIqs/EFOhj2nKLc5OaYB6dAfP1dd8o8NfeXo78wek5zaFiVTopY2urpQGKgPjg9nIUcL70jHWhSO/yXHM1/gC1IUB0s7s
Cc: oauth 
Subject: Re: [OAUTH-WG] JWT audience claim
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 18 Dec 2012 23:16:58 -0000

Inline...

On Tue, Dec 18, 2012 at 3:14 PM, John Bradley  wrote:
> We probably also need to consider this in light of people like Google
> already adding new JWT claims to specify a secondary audience, though there
> 'cid' Client ID claim is more about who requested the token.

There is a lot of similarity.  When I first heard about the cid claim,
I wondered if they might have used multiple aud values to accomplish
the same thing, if that been readily available in the spec. There are
some subtle differences between the two and I don't fully understand
the reasons for going with that secondary claim name.

> I am not keen on claims that are sometimes a literal and sometimes an array,
> though it works in JSON it can be confusing.
>
> Are you proposing that aud us always an array with one or more values, or
> that it is a literal if it is one value and array if more than one?

I could go either way. But I'd lean towards the latter given all the
considerations.

> The other way to deal with it is having a abstract audience that all the
> recipients recognize.  Though that has its own issues.

Indeed. And is complicated in applications or specifications that
require audience to be a very specific value (OpenID Connect, for
example, dictates that the aud of the id token "MUST be the OAuth 2.0
client_id of the Client.").

> Having one way to do it would be better, I just don't have a good feeling
> that it is worth complicating the simple case where there is only one
> audience.

Fair enough.

> I might be convinced of the utility for aud to be an array if you need mopre
> than one value and leave the single case as a literal.

I think that's where it'll end up, if there's a (rough) consensus to
make a change.

> John B.
>
> On 2012-12-18, at 6:41 PM, Brian Campbell 
> wrote:
>
> WG folks,
>
> I'm wondering if the current definition of the "aud" (audience) claim in JWT
> [1], which limits the value of the claim to a case sensitive string
> containing a StringOrURI value, might not be flexible enough?
>
> In thinking about or discussing various potential applications of JWT, the
> possibility of having a token intended for consumption by more than one
> entity has come up frequently. One such example would be an AS that is using
> JWTs as structured access tokens intended for use at multiple RSs and wants
> to audience restrict those access tokens. Doing that with the current JWT
> and "aud" claim could be rather awkward in that a single aud value would
> need to somehow represent multiple entities, which seems likely to be done
> in very application specific ways that would not result in much
> interoperability. Scope is potentially applicable in this case but isn't
> standardized at that level and wouldn't be useful outside of OAuth specific
> applications.
>
> At a high level, I'm proposing that we consider changing the definition of
> "aud" to allow for an array of StringOrURI values. And change the processing
> requirement such that the thing consuming the claim must identify itself
> with [at least] one of the values of the "aud" claim array. That would allow
> a JWT AT that's intended for consumption by RS 1, 2 and 3 to be audience
> restricted like this, "aud": ["RS1", "RS2", "RS3"] and an individual RS just
> needs to find itself in one of the values of the claim.
>
> Such a change would add some complexity but I'm beginning to think that it's
> a good trade off for the added flexibility it brings. The validation would
> be basically the same but just over a list of values rather than against a
> single one. We would have to decide whether the case of a single audience
> could still be represented as it is now or if everything would always have
> to be an array (i.e. "aud": "RS" vs. "aud": ["RS"] ). The former introduces
> slightly more complexity to validation but is a nice optimization for the
> common case and would preserve compatibility with existing implementations.
>
> Thoughts, comments, questions, or angry diatribes?
>
> Thanks,
> Brian
>
> [1]
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.5
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

From olds@rbcon.com  Tue Dec 18 16:00:37 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EF421E805F for ; Tue, 18 Dec 2012 16:00:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.598
X-Spam-Level: 
X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9tj0AykPXgY for ; Tue, 18 Dec 2012 16:00:36 -0800 (PST)
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5665D21E805D for ; Tue, 18 Dec 2012 16:00:36 -0800 (PST)
Received: by mail-pa0-f50.google.com with SMTP id hz10so891573pad.9 for ; Tue, 18 Dec 2012 16:00:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-gm-message-state; bh=FE/rp2kf1PL53qAPwYvFsKZl8qjF5cY+YJWiFGMEOoE=; b=W694hm9gWq5eya5GiIQ5AUhOSsxPJhRLb4F9uRSxu8QFFAoYzKDxtndHNqAj9xP5b4 Q2X03rGIUwQVl+VuwaQ43PUXkKA3V3Z82Y3Ked+e5eQDoc9+eNpNt3P1pLW7Gmvgq83O hsPi78RLO4sL850tQevYDnDkVSU6IJxHbBSblDh89qWjBkOKiqfnG+dNu7UEI1tsrOfT kO3FdGyixCqOr03UJ51ZDRzqKF1Lv4maEH3rs9x7+OzNGIXl9rfqFO4hKGFReqXAhSTQ rIYcBV5cLA5jKkibJYhSU5mqd7e6vdeBIToV2T7zOsMjNv5qqEZT/rgXrPNKO/SZS5kR iZcg==
X-Received: by 10.68.243.69 with SMTP id ww5mr12088173pbc.45.1355875235979; Tue, 18 Dec 2012 16:00:35 -0800 (PST)
Received: from [10.84.17.246] (75-101-111-130.dedicated.static.sonic.net. [75.101.111.130]) by mx.google.com with ESMTPS id nt5sm1943335pbb.59.2012.12.18.16.00.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 16:00:35 -0800 (PST)
Sender: Dale Olds 
Message-ID: <50D103A2.4090302@vmware.com>
Date: Tue, 18 Dec 2012 16:00:34 -0800
From: Dale Olds 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: oauth@ietf.org
References:  <22543C20-08E2-4587-9EFE-BCC0BC292119@ve7jtb.com>
In-Reply-To: <22543C20-08E2-4587-9EFE-BCC0BC292119@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------010806070504000608050507"
X-Gm-Message-State: ALoCoQnn1RX10zfCGgik1FYVOt2NJUxrScEat84F7vHP+jtqgkG/RTDb7KY+tee71rrxh890zJYp
Subject: Re: [OAUTH-WG] JWT audience claim
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 00:00:37 -0000

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

comments inline:

On 12/18/2012 02:14 PM, John Bradley wrote:
> We probably also need to consider this in light of people like Google 
> already adding new JWT claims to specify a secondary audience, though 
> there 'cid' Client ID claim is more about who requested the token.

In our implementation we produce JWTs with an 'aud' claim that is an 
array of audience identifiers.

>
> I am not keen on claims that are sometimes a literal and sometimes an 
> array, though it works in JSON it can be confusing.
>
> Are you proposing that aud us always an array with one or more values, 
> or that it is a literal if it is one value and array if more than one?
In our usage, it's always an array. While I agree with a single, simple 
data type, I think your last suggested syntax is preferable in this 
case: simple single values and the ability to have arrays when needed.

>
> The other way to deal with it is having a abstract audience that all 
> the recipients recognize.  Though that has its own issues.
>
> Having one way to do it would be better, I just don't have a good 
> feeling that it is worth complicating the simple case where there is 
> only one audience.
>
> I might be convinced of the utility for aud to be an array if you need 
> mopre than one value and leave the single case as a literal.

For better or worse, here's a possible use case:

In our system we have a number of resource servers. We use scope as a 
list of values in the form of .. So for resource servers A, B, 
and C and roles Read, Admin, and Audit, an application could request an 
access token with a scope of "A.Admin B.Audit C.Read". We produce a JWT 
access token which contains"aud":["A","B","C"]. Such a token could be 
presented to each RS which would validate the token and verifies that it 
is in the intended audience list. This approach has been quite useful 
and flexible.

The downside is that we are not forcing complete insulation of the RSs 
from each other. However, in our case some set of the RSs already have a 
relationship with each other such that isolation from each other in the 
token audience is of no benefit. So IMO the value of allowing an array 
of audiences outweighs the downside.

--Dale

>
> John B.
>
> On 2012-12-18, at 6:41 PM, Brian Campbell  > wrote:
>
>> WG folks,
>>
>> I'm wondering if the current definition of the "aud" (audience) claim 
>> in JWT [1], which limits the value of the claim to a case sensitive 
>> string containing a StringOrURI value, might not be flexible enough?
>>
>> In thinking about or discussing various potential applications of 
>> JWT, the possibility of having a token intended for consumption by 
>> more than one entity has come up frequently. One such example would 
>> be an AS that is using JWTs as structured access tokens intended for 
>> use at multiple RSs and wants to audience restrict those access 
>> tokens. Doing that with the current JWT and "aud" claim could be 
>> rather awkward in that a single aud value would need to somehow 
>> represent multiple entities, which seems likely to be done in very 
>> application specific ways that would not result in much 
>> interoperability. Scope is potentially applicable in this case but 
>> isn't standardized at that level and wouldn't be useful outside of 
>> OAuth specific applications.
>>
>> At a high level, I'm proposing that we consider changing the 
>> definition of "aud" to allow for an array of StringOrURI values. And 
>> change the processing requirement such that the thing consuming the 
>> claim must identify itself with [at least] one of the values of the 
>> "aud" claim array. That would allow a JWT AT that's intended for 
>> consumption by RS 1, 2 and 3 to be audience restricted like this, 
>> "aud": ["RS1", "RS2", "RS3"] and an individual RS just needs to find 
>> itself in one of the values of the claim.
>>
>> Such a change would add some complexity but I'm beginning to think 
>> that it's a good trade off for the added flexibility it brings. The 
>> validation would be basically the same but just over a list of values 
>> rather than against a single one. We would have to decide whether the 
>> case of a single audience could still be represented as it is now or 
>> if everything would always have to be an array (i.e. "aud": "RS" vs. 
>> "aud": ["RS"] ). The former introduces slightly more complexity to 
>> validation but is a nice optimization for the common case and would 
>> preserve compatibility with existing implementations.
>>
>> Thoughts, comments, questions, or angry diatribes?
>>
>> Thanks,
>> Brian
>>
>> [1] 
>> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.5 
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    comments inline:

    

    
On 12/18/2012 02:14 PM, John Bradley
      wrote:

    

    

      
      We probably also need to consider this in light of people like
      Google already adding new JWT claims to specify a secondary
      audience, though there 'cid' Client ID claim is more about who
      requested the token.

    

    In our implementation we produce JWTs with an 'aud' claim that is an
    array of audience identifiers. 

    

    

      


      

      
I am not keen on claims that are sometimes a literal and
        sometimes an array, though it works in JSON it can be confusing.

      


      

      
Are you proposing that aud us always an array with one or
        more values, or that it is a literal if it is one value and
        array if more than one?

    

    In our usage, it's always an array. While I agree with a single,
    simple data type, I think your last suggested syntax is preferable
    in this case: simple single values and the ability to have arrays
    when needed.

    

    

      


      

      
The other way to deal with it is having a abstract audience
        that all the recipients recognize.  Though that has its own
        issues.

      


      

      
Having one way to do it would be better, I just don't have a
        good feeling that it is worth complicating the simple case where
        there is only one audience.

      


      

      
I might be convinced of the utility for aud to be an array if
        you need mopre than one value and leave the single case as a
        literal.

    

    

    For better or worse, here's a possible use case: 

    

    In our system we have a number of resource servers. We use scope as
    a list of values in the form of <RS>.<role>. So for
    resource servers A, B, and C and roles Read, Admin, and Audit, an
    application could request an access token with a scope of "A.Admin
    B.Audit C.Read". We produce a JWT access token which
    contains"aud":["A","B","C"]. Such a token could be presented to each
    RS which would validate the token and verifies that it is in the
    intended audience list. This approach has been quite useful and
    flexible. 

    

    The downside is that we are not forcing complete insulation of the
    RSs from each other. However, in our case some set of the RSs
    already have a relationship with each other such that isolation from
    each other in the token audience is of no benefit. So IMO the value
    of allowing an array of audiences outweighs the downside.

    

    --Dale

    

    

      


      

      
John B.

      


        

          
On 2012-12-18, at 6:41 PM, Brian Campbell <bcampbell@pingidentity.com>
            wrote:

          

          
WG folks,

            

            I'm wondering if the current definition of the "aud"
            (audience) claim in JWT [1], which limits the value of the
            claim to a case sensitive string containing a StringOrURI
            value, might not be flexible enough?

            

            In thinking about or discussing various potential
            applications of JWT, the possibility of having a token
            intended for consumption by more than one entity has come up
            frequently. One such example would be an AS that is using
            JWTs as structured access tokens intended for use at
            multiple RSs and wants to audience restrict those access
            tokens. Doing that with the current JWT and "aud" claim
            could be rather awkward in that a single aud value would
            need to somehow represent multiple entities, which seems
            likely to be done in very application specific ways that
            would not result in much interoperability. Scope is
            potentially applicable in this case but isn't standardized
            at that level and wouldn't be useful outside of OAuth
            specific applications.   

            

            At a high level, I'm proposing that we consider changing the
            definition of "aud" to allow for an array of StringOrURI
            values. And change the processing requirement such that the
            thing consuming the claim must identify itself with [at
            least] one of the values of the "aud" claim array. That
            would allow a JWT AT that's intended for consumption by RS
            1, 2 and 3 to be audience restricted like this, "aud":
            ["RS1", "RS2", "RS3"] and an individual RS just needs to
            find itself in one of the values of the claim.

            

            Such a change would add some complexity but I'm beginning to
            think that it's a good trade off for the added flexibility
            it brings. The validation would be basically the same but
            just over a list of values rather than against a single one.
            We would have to decide whether the case of a single
            audience could still be represented as it is now or if
            everything would always have to be an array (i.e. "aud":
            "RS" vs. "aud": ["RS"] ). The former introduces slightly
            more complexity to validation but is a nice optimization for
            the common case and would preserve compatibility with
            existing implementations. 

            

            Thoughts, comments, questions, or angry diatribes?

            

            Thanks,

            Brian

            

            [1]  http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.5 
            

            _______________________________________________

            OAuth mailing list

            OAuth@ietf.org

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

          

        

        

      

      

      

      

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


    

    

  


--------------010806070504000608050507--

From sakimura@gmail.com  Tue Dec 18 18:21:36 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4132D21E8039 for ; Tue, 18 Dec 2012 18:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.886
X-Spam-Level: 
X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.712,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaiHQnkX1aUX for ; Tue, 18 Dec 2012 18:21:34 -0800 (PST)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2340B21E8034 for ; Tue, 18 Dec 2012 18:21:34 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id n41so790085qco.35 for ; Tue, 18 Dec 2012 18:21:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tVw4JvGA0j3lZFwD2uB42t0/anOClE+fmIaf3PkmC/E=; b=HqPRf5BCiTFLfY7FvBPvNkhpbBzSuT84Rowdu+3nhRP+E14PaTcnUo7+/CIzDfKCNM nREltG2qjK2fyzYei/Rx6EtO0PGq4Bez9v+6USoZ5gCotObcsnHvNNaQX05kPMwgYYh5 s5+iR04dFPo+FBoN8onsZoVxk14B8aHlEuPIjTHzb6r8xhq0PnjJ0sN+7082rt2FeNd+ Wv7K1TkCSCuVDjlnJMqC7ub729/UFWrzyMhqsqPj+lsqp6Hqd42wCw2gAbZODNe35zVs EIdu1yAv9E/mMZdY6rfXQW8A9plMHJVx8MPiaTKRSYkIc4BG0C8/5XHSJmwBY1mayi7f hTuA==
MIME-Version: 1.0
Received: by 10.224.177.68 with SMTP id bh4mr1851633qab.63.1355883693531; Tue, 18 Dec 2012 18:21:33 -0800 (PST)
Received: by 10.229.194.32 with HTTP; Tue, 18 Dec 2012 18:21:33 -0800 (PST)
Date: Wed, 19 Dec 2012 11:21:33 +0900
Message-ID: 
From: Nat Sakimura 
To: oauth 
Content-Type: multipart/alternative; boundary=20cf30334dd5e8e3f404d12b4592
Subject: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 02:21:36 -0000

--20cf30334dd5e8e3f404d12b4592
Content-Type: text/plain; charset=ISO-8859-1

In OpenID Connect WG, we have been talking this for sometime.
"cid" claim identifies the entity that the JWT was issued to as a
rightful/licensed user.
Google already uses this in their implementation of id_token of OIDC.

Here is the text proposal. It introduces two new standard claims: "cid" and
"cit".

It would be very useful in creating a HoK drafts as well.


Cheers,


Nat


*4.1.9. "cid" Client Identification Data Claim*
The "cid" (client identification data) claim allows the receiver of
the JWT to identify the entity that the JWT is intended to be used by.
The audience of the JWT MUST be able to identify the client with the
value of this claim.
The "cid" value is a case sensitive string containing a StringOrURI
value.This claim is OPTIONAL. If the entity processing the claim does
not identify the user of the JWT with the identifier in the "cid"
claim value, then the JWT MUST be rejected. The interpretation of the
registered to value is generally application specific.
A typical example of a registered to claim includes following: *
client_id that the audience can use to authenticate and
  identify the client.* A base64url encoded JWK. * A URL that points
to the key material that the audience can use to
  authenticate the user of the JWT.
*4.1.10 "cit" (Client Identification Data claim type)*
The "cit" (Client Identification Data claim type) identifies the type
of the "cid" claim. It is a StringOrURI value. The defined values are
the following:

"client_id" The value of the "cid" claim is the Client ID of the
client that the audience of the JWT is able to use to authenticate the
client.

"jwk" The value of the "cid" claim is a base64url encoded JWK of the
registered client.

"jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of
JSON web signature [JWS].

"x5u" The value of the "cid" claim is the URL that points to the
public key certificate of the registered client. The format of the
content that x5u points to is described in section 4.1.4 of the JSON
Web Signature.


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

In OpenID Connect WG, we have been talking this for sometime.=A0
"=
cid" claim identifies the entity that the JWT was issued to as a right=
ful/licensed user.=A0
Google already uses this in their implement=
ation of id_token of OIDC.=A0



Here is the text proposal. It introduces two new standa=
rd claims: "cid" and "cit".=A0


It would be very useful in creating a HoK drafts as well.=A0


Cheers,=A0


Nat


4.1.9. "cid" Client=
 Identification Data Claim

The "cid" (client iden=
tification data) <=
span class=3D"n">claim allows the receiver=20
of the =
JWT to identify the entity that the JWT is=20
intended to be used by<=
span class=3D"p">. The au=
dience of the JWT MUST be=
=20
able to identify the client with the value of this claim.

The "cid" value is a case sensitive string containing a StringOrURI=
 value.
This claim is OPTIONAL. <=
span class=3D"n">If the e=
ntity processing the claim does not=20
identify the user of the=
 JWT with the identifier in the "cid" claim value,=20
then the JWT MUST be rejected. T=
he interpretation of the registered to=20
value is generally application s=
pecific.

A typical example of a registered to claim includes fol=
lowing:=20
* client_id that the audience<=
/span> can use to authenticate a=
nd=20
  identify the client.
* A bas=
e64url encoded JWK=
.=20
* A URL=
 that points to the key material that the audience can use to=20
  authenticate the user of the JWT.

4.1.10 "cit" (Clien=
t Identification Data claim type)

The "cit" (Client Iden=
tification Data claim type) identifies the type=20
of the "cid" claim. It is a StringOrURI valu=
e. The defined values=20
are the following:

"client_id" The=
 value of the "cid" cl=
aim is the Client ID of the client=20
that the audience of the =
JWT is =
able to use to authenticate the client.

"jwk" The value of the=
 "cid" claim is a base64url encoded JWK<=
/span> of=20
the registered client.

"jku" The value of the=
 "cid" claim is the "jku" defined in 4.1.2 of=20
JSON web signature [JWS].

"x5u" The value of the=
 "cid" claim is the URL that points to the public=20
key certificate of the registere=
d client. The format of the content=20
that x5u points to is described in section 4.1.4 <=
span class=3D"n">of the J=
SON Web Signature<=
span class=3D"p">.



-- 
Nat Sakimura (=3Dnat)
Chairman, =
OpenID Foundation
http://nat.sakimura.org/
@_nat_en





--20cf30334dd5e8e3f404d12b4592--

From sakimura@gmail.com  Tue Dec 18 18:40:06 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0239521E8034 for ; Tue, 18 Dec 2012 18:40:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.945
X-Spam-Level: 
X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[AWL=0.653,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dco8Izf+eqxJ for ; Tue, 18 Dec 2012 18:40:05 -0800 (PST)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id D5F1021F8588 for ; Tue, 18 Dec 2012 18:40:04 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id n41so788542qco.7 for ; Tue, 18 Dec 2012 18:40:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=uGkX1TZHyriPrpkoH0tPvHV5gEA+VQTgNfN7IlnJJA8=; b=bGhW7tEEZqz/9WXpLrUkgNPU0S5KdlGADO8LeOxRkRo+F/HKcZcMi48QJph2sTynRf i4W99TbCR6or6vd0YP6aGq1kR++uilXQ/WDro+pJUQi8ElHSLudG+lIY+FHHKFIgsHFo F4JTQigJKL5L84SmzOD/te6vhesLMoUPA+EEeBt1IP4lRanxpnBfzf90DZYNYgncqtXQ Da7N0d4D97lylFc5QDaYT/raflFqBashjgCXVI9ml78H+lySt/e/VurNgN0tKLZrZpv5 Y3l7EX0vQzF3tKNMbAyv0+dMfHW1695subQwwt8oufB+X1Vno6AuPj5t386io4YFfe8v APfw==
MIME-Version: 1.0
Received: by 10.49.106.71 with SMTP id gs7mr2053211qeb.21.1355884804316; Tue, 18 Dec 2012 18:40:04 -0800 (PST)
Received: by 10.229.194.32 with HTTP; Tue, 18 Dec 2012 18:40:04 -0800 (PST)
In-Reply-To: <20121219023404.26544.32478.idtracker@ietfa.amsl.com>
References: <20121219023404.26544.32478.idtracker@ietfa.amsl.com>
Date: Wed, 19 Dec 2012 11:40:04 +0900
Message-ID: 
From: Nat Sakimura 
To: oauth 
Content-Type: multipart/alternative; boundary=e89a8f921a1e1e1e3604d12b88d1
Subject: [OAUTH-WG] Fwd: New Version Notification for draft-sakimura-oauth-meta-01.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 02:40:06 -0000

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

Just formatting error fix.

Discussion points:

* Should we allow arrays in 3.1.2 method?

Right now, if one wants to specify several method, it needs to have an
entry for each method
even if everything else is the same. Do we want to group them together?

* Do we need 3.1.5 Authorize?

It is just an optimization for non-challenge-response authentication scheme
such as Bearer.
Does the omitting of one round trip for such cases warrant the addition of
this new claim?

* 3.1.4 content-type needs much more tightening up. Now the question is
how.

---------- Forwarded message ----------
From: 
Date: Wed, Dec 19, 2012 at 11:34 AM
Subject: New Version Notification for draft-sakimura-oauth-meta-01.txt
To: sakimura@gmail.com



A new version of I-D, draft-sakimura-oauth-meta-01.txt
has been successfully submitted by Nat Sakimura and posted to the
IETF repository.

Filename:        draft-sakimura-oauth-meta
Revision:        01
Title:           JSON Metadata for OAuth Responses
Creation date:   2012-12-18
WG ID:           Individual Submission
Number of pages: 9
URL:
http://www.ietf.org/internet-drafts/draft-sakimura-oauth-meta-01.txt
Status:          http://datatracker.ietf.org/doc/draft-sakimura-oauth-meta
Htmlized:        http://tools.ietf.org/html/draft-sakimura-oauth-meta-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-sakimura-oauth-meta-01

Abstract:
   This specification defines an extensible metadata member that may be
   inserted into the OAuth 2.0 responses to assist the clients to
   process those responses.  It is expressed as a member called "_links"
   that is inserted as the top level member in the responses.  It will
   allow the client to learn where the members in the response could be
   used and how, etc.  Since it is just a member, any client that does
   not understand this extension should not break and work normally
   while supporting clients can utilize the metadata to its advantage.




The IETF Secretariat




-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

Just formatting error fix.=A0

Discussion points:=A0

* Should we allow arrays in 3.1.2 method?=A0

Right now, if one wants to specify several method, it needs=
 to have an entry for each method=A0


even if everything else is the same. Do we want to group them together=
?=A0

* Do we need 3.1.5 Authorize?=A0
It is just an optimization for non-challenge-response authenti=
cation scheme such as Bearer.=A0


Does the omitting of one round trip for such cases warrant the additio=
n of this new claim?=A0

* 3.1.4 content-type needs=
 much more tightening up. Now the question is how.=A0


---------- Forwarded message ----------
From:  <=
internet-drafts@ietf.org>
Date: Wed, Dec 19, 2012 at 11:34=
 AM

Subject: New Version Notification for draft-sakimura-oauth-meta-01.txt
T=
o: sakimura@gmail.com


=


A new version of I-D, draft-sakimura-oauth-meta-01.txt

has been successfully submitted by Nat Sakimura and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-sakimura-oauth-meta

Revision: =A0 =A0 =A0 =A001

Title: =A0 =A0 =A0 =A0 =A0 JSON Metadata for OAuth Responses

Creation date: =A0 2012-12-18

WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 9

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/in=
ternet-drafts/draft-sakimura-oauth-meta-01.txt

Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dra=
ft-sakimura-oauth-meta

Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-sakimu=
ra-oauth-meta-01

Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff=
?url2=3Ddraft-sakimura-oauth-meta-01



Abstract:

=A0 =A0This specification defines an extensible metadata member that may be=


=A0 =A0inserted into the OAuth 2.0 responses to assist the clients to

=A0 =A0process those responses. =A0It is expressed as a member called "=
;_links"

=A0 =A0that is inserted as the top level member in the responses. =A0It wil=
l

=A0 =A0allow the client to learn where the members in the response could be=


=A0 =A0used and how, etc. =A0Since it is just a member, any client that doe=
s

=A0 =A0not understand this extension should not break and work normally

=A0 =A0while supporting clients can utilize the metadata to its advantage.<=
br>








The IETF Secretariat







-- 
Nat Sakimura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en





--e89a8f921a1e1e1e3604d12b88d1--

From sakimura@gmail.com  Tue Dec 18 18:47:46 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7164621F85A3 for ; Tue, 18 Dec 2012 18:47:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.995
X-Spam-Level: 
X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.603,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZhUzqGHJtMQ for ; Tue, 18 Dec 2012 18:47:45 -0800 (PST)
Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 39B5021F859D for ; Tue, 18 Dec 2012 18:47:45 -0800 (PST)
Received: by mail-qc0-f179.google.com with SMTP id b14so792744qcs.24 for ; Tue, 18 Dec 2012 18:47:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hDeKu92Yw7Pr310FdX1uyxNlc93NE5Hj78KG7DzfisE=; b=lVESljyIbmHZ9gzazA5MS3i9zIvTyRaxjb/IHSg5J9Elp5P3+X+u42K5wBpLku5gjL kMQ5+1ekeCZAvAHSH7bOrN1J96l+vi1zx+ODhdDlFnKDyGZnRz5SDIgObiKoqQTgmQjO 4zuslWNCwMTLwgXPbE5dIVlXbLSalMW/etllb74jBfAJv4ELEbJEqqshhFgu73UUIZTX lCF7FUX67c1TmFTJM0X1MVcaLLHEw3qjG+SIYfDpjYFvMk+CKEsr/yzGKYh5DMBJreVF jzxjSLJyI2TXnFEgszx9Wrnqqc+SkDyZtwe8btFcjx4xPqfhUbvBJ3qUex+u0SGUr4jo tS4g==
MIME-Version: 1.0
Received: by 10.49.96.1 with SMTP id do1mr1992505qeb.26.1355885264602; Tue, 18 Dec 2012 18:47:44 -0800 (PST)
Received: by 10.229.194.32 with HTTP; Tue, 18 Dec 2012 18:47:44 -0800 (PST)
Date: Wed, 19 Dec 2012 11:47:44 +0900
Message-ID: 
From: Nat Sakimura 
To: Justin Richer , oauth 
Content-Type: multipart/alternative; boundary=047d7b6757e08d848a04d12ba360
Subject: [OAUTH-WG] draft-richer-oauth-instance-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 02:47:46 -0000

--047d7b6757e08d848a04d12ba360
Content-Type: text/plain; charset=ISO-8859-1

Justin,

In addition to instance_name and instance_description, I think we need
collision resistant instance_id which can be cryptographically linked to
the instance so that it can actually be authenticated, in a similar manner
to what we do with the self-issued IdP in the OpenID Connect.

My proposal is to create a public-private key pair at the install time and
use the sha256 of the public key as the instance_id.

Note: If the client is going to talk to multiple entities, the instance_id
would have some privacy impact.
We may need to generate the keypair for each entity that the client talks
to.

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

Justin,=A0

In addition to instance_name and instance_des=
cription, I think we need collision resistant instance_id which can be cryp=
tographically linked to the instance so that it can actually be authenticat=
ed, in a similar manner to what we do with the self-issued IdP in the OpenI=
D Connect.=A0



My proposal is to create a public-private key pair at t=
he install time and use the sha256 of the public key as the instance_id. =
=A0

Note: If the client is going to talk to multip=
le entities, the instance_id would have some privacy impact.=A0


We may need to generate the keypair for each entity that the client ta=
lks to.=A0

-- 
Nat Sakimura (=3Dnat)Chairman, OpenID Foundation
http://nat.sakimura.org/

@_nat_en





--047d7b6757e08d848a04d12ba360--

From sakimura@gmail.com  Tue Dec 18 18:49:50 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4E021E8049 for ; Tue, 18 Dec 2012 18:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.038
X-Spam-Level: 
X-Spam-Status: No, score=-3.038 tagged_above=-999 required=5 tests=[AWL=0.560,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLOJZzfft4Ok for ; Tue, 18 Dec 2012 18:49:49 -0800 (PST)
Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6706F21E8034 for ; Tue, 18 Dec 2012 18:49:49 -0800 (PST)
Received: by mail-qc0-f175.google.com with SMTP id j3so795343qcs.6 for ; Tue, 18 Dec 2012 18:49:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ov2PMaMjFFk4kP00oPAkPbPkLTYIUOgCMxZjpK5jqns=; b=J4QPnOjt9aixcDE2cq5zpYvfLOQ1mtd9pWiqrERX19OHMQ+YSwzSg699+W+laJhy9T HhbYZ6UFNdTjNDgH0RT3TmP6EbVyHDpmXOgP5UoD58a3wr5cxxYTAkGVSxUGA+TK2sgk XhaGpGhjoVnpmP01DXc3vC/HYLZV1XlywVz+8JAlWz/yiln7AFNJ3kniymHlOte1yO9i DCwnHdyufAuhH3YccsLiaAg198rHgMkauIqZGp1t1V8l3vPAU15116a9Chv1vZ3Z3md1 FaAr/iap+drlT5n+lvGJGqOoPaMUSEC/1N/disfEmXYb5OL84y82THez9a8WW0Q1TMFm /rBw==
MIME-Version: 1.0
Received: by 10.229.69.102 with SMTP id y38mr420920qci.23.1355885386361; Tue, 18 Dec 2012 18:49:46 -0800 (PST)
Received: by 10.229.194.32 with HTTP; Tue, 18 Dec 2012 18:49:46 -0800 (PST)
In-Reply-To: <22543C20-08E2-4587-9EFE-BCC0BC292119@ve7jtb.com>
References:  <22543C20-08E2-4587-9EFE-BCC0BC292119@ve7jtb.com>
Date: Wed, 19 Dec 2012 11:49:46 +0900
Message-ID: 
From: Nat Sakimura 
To: John Bradley 
Content-Type: multipart/alternative; boundary=00032557e4aecf6aa904d12baa33
Cc: oauth 
Subject: Re: [OAUTH-WG] JWT audience claim
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 02:49:50 -0000

--00032557e4aecf6aa904d12baa33
Content-Type: text/plain; charset=ISO-8859-1

FYI, I have just posted proposed text for 'cid' in a separate thread.

Nat

On Wed, Dec 19, 2012 at 7:14 AM, John Bradley  wrote:

> We probably also need to consider this in light of people like Google
> already adding new JWT claims to specify a secondary audience, though there
> 'cid' Client ID claim is more about who requested the token.
>
> I am not keen on claims that are sometimes a literal and sometimes an
> array, though it works in JSON it can be confusing.
>
> Are you proposing that aud us always an array with one or more values, or
> that it is a literal if it is one value and array if more than one?
>
> The other way to deal with it is having a abstract audience that all the
> recipients recognize.  Though that has its own issues.
>
> Having one way to do it would be better, I just don't have a good feeling
> that it is worth complicating the simple case where there is only one
> audience.
>
> I might be convinced of the utility for aud to be an array if you need
> mopre than one value and leave the single case as a literal.
>
> John B.
>
> On 2012-12-18, at 6:41 PM, Brian Campbell 
> wrote:
>
> WG folks,
>
> I'm wondering if the current definition of the "aud" (audience) claim in
> JWT [1], which limits the value of the claim to a case sensitive string
> containing a StringOrURI value, might not be flexible enough?
>
> In thinking about or discussing various potential applications of JWT, the
> possibility of having a token intended for consumption by more than one
> entity has come up frequently. One such example would be an AS that is
> using JWTs as structured access tokens intended for use at multiple RSs and
> wants to audience restrict those access tokens. Doing that with the current
> JWT and "aud" claim could be rather awkward in that a single aud value
> would need to somehow represent multiple entities, which seems likely to be
> done in very application specific ways that would not result in much
> interoperability. Scope is potentially applicable in this case but isn't
> standardized at that level and wouldn't be useful outside of OAuth specific
> applications.
>
> At a high level, I'm proposing that we consider changing the definition of
> "aud" to allow for an array of StringOrURI values. And change the
> processing requirement such that the thing consuming the claim must
> identify itself with [at least] one of the values of the "aud" claim array.
> That would allow a JWT AT that's intended for consumption by RS 1, 2 and 3
> to be audience restricted like this, "aud": ["RS1", "RS2", "RS3"] and an
> individual RS just needs to find itself in one of the values of the claim.
>
> Such a change would add some complexity but I'm beginning to think that
> it's a good trade off for the added flexibility it brings. The validation
> would be basically the same but just over a list of values rather than
> against a single one. We would have to decide whether the case of a single
> audience could still be represented as it is now or if everything would
> always have to be an array (i.e. "aud": "RS" vs. "aud": ["RS"] ). The
> former introduces slightly more complexity to validation but is a nice
> optimization for the common case and would preserve compatibility with
> existing implementations.
>
> Thoughts, comments, questions, or angry diatribes?
>
> Thanks,
> Brian
>
> [1]
> http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-05#section-4.1.5
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

FYI, I have just posted proposed text for 'cid' in a separate threa=
d.=A0

Nat

On Wed, Dec =
19, 2012 at 7:14 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:=



We proba=
bly also need to consider this in light of people like Google already addin=
g new JWT claims to specify a secondary audience, though there 'cid'=
; Client ID claim is more about who requested the token.


I am not keen on claims that are sometimes a literal and som=
etimes an array, though it works in JSON it can be confusing.
Are you proposing that aud us always an array with one or more =
values, or that it is a literal if it is one value and array if more than o=
ne?



The other way to deal with it is having a abstract audi=
ence that all the recipients recognize. =A0Though that has its own issues.<=
/div>

Having one way to do it would be better, I just do=
n't have a good feeling that it is worth complicating the simple case w=
here there is only one audience.



I might be convinced of the utility for aud to be an ar=
ray if you need mopre than one value and leave the single case as a literal=
.

John B.



On 2012-12-18, at 6:41 PM, Brian Campbell <bcampbell@pingidentity.com> =
wrote:

WG folks,


I'm wondering if the current definition of the "aud" (aud=
ience) claim in JWT [1], which limits the value of the claim to a case sens=
itive string containing a StringOrURI value, might not be flexible enough?<=
br>



In thinking about or discussing various potential applications of JWT, =
the possibility of having a token intended for consumption by more than one=
 entity has come up frequently. One such example would be an AS that is usi=
ng JWTs as structured access tokens intended for use at multiple RSs and wa=
nts to audience restrict those access tokens. Doing that with the current J=
WT and "aud" claim could be rather awkward in that a single aud v=
alue would need to somehow represent multiple entities, which seems likely =
to be done in very application specific ways that would not result in much =
interoperability. Scope is potentially applicable in this case but isn'=
t standardized at that level and wouldn't be useful outside of OAuth sp=
ecific applications. =A0 




At a high level, I'm proposing that we consider changing the defini=
tion of "aud" to allow for an array of StringOrURI values. And ch=
ange the processing requirement such that the thing consuming the claim mus=
t identify itself with [at least] one of the values of the "aud" =
claim array. That would allow a JWT AT that's intended for consumption =
by RS 1, 2 and 3 to be audience restricted like this, "aud": [&qu=
ot;RS1", "RS2", "RS3"] and an individual RS just n=
eeds to find itself in one of the values of the claim.




Such a change would add some complexity but I'm beginning to think =
that it's a good trade off for the added flexibility it brings. The val=
idation would be basically the same but just over a list of values rather t=
han against a single one. We would have to decide whether the case of a sin=
gle audience could still be represented as it is now or if everything would=
 always have to be an array (i.e. "aud": "RS" vs. "=
;aud": ["RS"] ). The former introduces slightly more complex=
ity to validation but is a nice optimization for the common case and would =
preserve compatibility with existing implementations. 




Thoughts, comments, questions, or angry diatribes?

Thanks,
Br=
ian

 [1]=A0 http://tools.ietf.org/htm=
l/draft-ietf-oauth-json-web-token-05#section-4.1.5=A0 




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




____________________________________=
___________

OAuth mailing list

OAuth@ietf.org

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





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
=






--00032557e4aecf6aa904d12baa33--

From bcampbell@pingidentity.com  Wed Dec 19 12:26:38 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CE221F8781 for ; Wed, 19 Dec 2012 12:26:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.514
X-Spam-Level: 
X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcoO28NGklhj for ; Wed, 19 Dec 2012 12:26:38 -0800 (PST)
Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with ESMTP id EA3AB21F8484 for ; Wed, 19 Dec 2012 12:26:37 -0800 (PST)
Received: from mail-qa0-f69.google.com ([209.85.216.69]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUNIi/U+4q3xNbgRJHo1O/hkZZccU4PcV@postini.com; Wed, 19 Dec 2012 12:26:38 PST
Received: by mail-qa0-f69.google.com with SMTP id o19so4616897qap.0 for ; Wed, 19 Dec 2012 12:26:34 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=QAtmVQlImD+PG+N4d1DUm++O0l72cYg1OMJ/Nkpab8A=; b=jupXEMbSsffnjCigR1NyVMNXUW6hbWEi2geY0MZQxAGuCtQ8QiTScbIbKcIYgRyvQY Qdi+M23lXDaBPM+QxHl4ktvtn6aOxEBqV1bVUtx47QLULnssKjvZ3LqJ1weIZPIzLQSb 9mDY/NVJgXvxiDvTGFnhbF1XwbGkECb9SH1q83+Urkk9OVF5Cvf8lsRDgR+D+KoKFipJ lREswIHrmuKtEckRDVkR4Htwg9vNPiWMZUVMSfyGBAHNN7hfs4odq6dZ/uBcEJ+L+/2E mHp1CqRKonXP0mKKfcgC9q4boxxNGUf1MaCXfVCLrDPI7oiWC40V9TempTjP7novMk/2 OKwA==
X-Received: by 10.220.8.195 with SMTP id i3mr10473696vci.44.1355948794748; Wed, 19 Dec 2012 12:26:34 -0800 (PST)
Received: by 10.220.8.195 with SMTP id i3mr10473687vci.44.1355948794613; Wed, 19 Dec 2012 12:26:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.163.170 with HTTP; Wed, 19 Dec 2012 12:26:03 -0800 (PST)
In-Reply-To: 
References:  
From: Brian Campbell 
Date: Wed, 19 Dec 2012 13:26:03 -0700
Message-ID: 
To: "zhou.sujing@zte.com.cn" 
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkc0OJrgyQjgUgQsFlwOiK+MyXhE4LGjym8LIlA88TEixzzOTBxXXfD9bJLGKaDl1kEtOT302Spbqdn+w//qrX/bY4imoAUb8Ph/Wb8OG/Kqvr++yNIDRnUsmsrvPA0txwcfh3f
Cc: "oauth@ietf.org WG" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Summary - "Assertion Framework - Why does issuer have to be either the client or a third party token service?"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 20:26:38 -0000

They are just some examples and shouldn't limit who or what can be the issu=
er.

Maybe just removing that whole sentence that says, "The issuer may be
either an OAuth client (when assertions are self-issued) or a third
party token service.' would be better, if it's causing confusion?

On Mon, Dec 17, 2012 at 5:29 PM,   wrote:
>
>
> oauth-bounces@ietf.org =D0=B4=D3=DA 2012-12-17 23:21:36:
>
>
>> Hi all,
>>
>> I read through the mailing list discussion raised by Nat in this
>> mail to the list on the 3rd of December, see http://www.ietf.
>> org/mail-archive/web/oauth/current/msg10203.html
>>
>> There were two types of issues:
>>
>> 1) The current text about the issuer (in Section 5.1 of > oauth-assertions-08.txt> says that the assertion can either be
>> created by the client (in which case it is self-signed) or it can be
>> created by some other entity.
>>
>> There was, however, the perception that the current text, in the way
>> it is worded, creates the impression that third party token services
>> excludes entities like the resource owner.
>>
>> 2) Some folks had the idea that the resource owner could create the
>> assertion and they had a specific use case in mind. While this is
>> not a currently deployed scenario (using OAuth technology) there
>> seem to be some other deployment (the Austrian eID card deployment
>> was mentioned by Nat) that could be re-build with this support in mind.
>>
>> It seemed that just mentioning that the resource owner could create
>> the assertion wouldn't be enough to understand the scenario. A more
>> detailed writeup of the envisioned scenario would be needed but has
>> not been provided to the mailing list.
>>
>> To me it seems that the best approach would be to do the following:
>>
>> a) to update the text in Section 5.1 as suggested by Nat in his mail
>> http://www.ietf.org/mail-archive/web/oauth/current/msg10222.html
>
> Nat's suggestion "Example of issuers include an OAuth client, resource
> owner, an independent third party."
> there is still an issue,  "indenpendent" from who?  If  AS be an assertio=
n
> issuer, could AS be called indenpendent?
>
>
>> This by itself would not lead to any normative text change but may
>> make it clear what the intention was.
>>
>> b) to encourage those who care about the use case where the resource
>> owner creates the assertion to compile a document and to submit it
>> to the group. This would allow us to evaluate whether all the
>> required functionality is indeed available.
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From Michael.Jones@microsoft.com  Wed Dec 19 13:34:16 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD8A21F8777 for ; Wed, 19 Dec 2012 13:34:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.79
X-Spam-Level: 
X-Spam-Status: No, score=-2.79 tagged_above=-999 required=5 tests=[AWL=-0.192,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLkmOHAywUIM for ; Wed, 19 Dec 2012 13:34:15 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1622D21F85DF for ; Wed, 19 Dec 2012 13:34:14 -0800 (PST)
Received: from BL2FFO11FD004.protection.gbl (10.173.161.200) by BL2FFO11HUB004.protection.gbl (10.173.161.22) with Microsoft SMTP Server (TLS) id 15.0.586.12; Wed, 19 Dec 2012 21:34:12 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD004.mail.protection.outlook.com (10.173.160.104) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Wed, 19 Dec 2012 21:34:12 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 21:33:33 +0000
From: Mike Jones 
To: "oauth@ietf.org WG" 
Thread-Topic: Additional informative references for Assertions draft
Thread-Index: Ac3eMHuqa1y1DpLzQAuxzlI/pXrpUw==
Date: Wed, 19 Dec 2012 21:33:32 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366977847@TK5EX14MBXC283.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.73]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366977847TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(47736001)(44976002)(56816002)(47446002)(5343635001)(31966008)(54316002)(15202345001)(5343655001)(46102001)(53806001)(512954001)(16236675001)(74662001)(33656001)(51856001)(74502001)(50986001)(16406001)(55846006)(49866001)(4396001)(47976001)(59766001)(77982001)(56776001)(54356001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB004; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 070092A9D3
Subject: [OAUTH-WG] Additional informative references for Assertions draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 21:34:16 -0000

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

I'd suggest adding informative references to the OAuth SAML and JWT Profile=
 documents in the Assertions draft.  After this sentence of the Introductio=
n:

In order to be implementable, companion specifications are necessary to pro=
vide the corresponding concrete instantiations.

I'd add the following:

For instance, the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 [draft-i=
etf-oauth-saml2-bearer] defines a concrete instantiation for SAML 2.0 token=
s and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 [draft-ietf-=
oauth-jwt-bearer] defines a concrete instantiation for JWT tokens.

Doing that will help readers find the concrete instances from the abstract =
specification.

                                                            Thanks,
                                                            -- Mike


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











I’d suggest adding informative references to t=
he OAuth SAML and JWT Profile documents in the Assertions draft.  Afte=
r this sentence of the Introduction:


 


In order to=
 be implementable, companion specifications are necessary to provide the co=
rresponding concrete instantiations.


 


I’d add the following:


 


For instanc=
e, the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 [draft-ietf-oauth-s=
aml2-bearer] defines a concrete instantiation for
 SAML 2.0 tokens and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2=
.0 [draft-ietf-oauth-jwt-bearer] defines a concrete instantiation for JWT t=
okens.


 


Doing that will help readers find the concrete insta=
nces from the abstract specification.


 


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


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


 






--_000_4E1F6AAD24975D4BA5B168042967394366977847TK5EX14MBXC283r_--

From jricher@mitre.org  Wed Dec 19 13:44:38 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D6121F87BD for ; Wed, 19 Dec 2012 13:44:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.453
X-Spam-Level: 
X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEuutnPaxn1b for ; Wed, 19 Dec 2012 13:44:37 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D214621F853E for ; Wed, 19 Dec 2012 13:44:23 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 275331F04D9; Wed, 19 Dec 2012 16:44:23 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 1B65A1F04D0; Wed, 19 Dec 2012 16:44:23 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 19 Dec 2012 16:44:22 -0500
Message-ID: <50D234C3.9070508@mitre.org>
Date: Wed, 19 Dec 2012 16:42:27 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Mike Jones 
References: <4E1F6AAD24975D4BA5B168042967394366977847@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366977847@TK5EX14MBXC283.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------040106000502000407030609"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Additional informative references for Assertions draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 21:44:38 -0000

--------------040106000502000407030609
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

+1, cross references are a good thing when documents are split up.

On 12/19/2012 04:33 PM, Mike Jones wrote:
>
> I'd suggest adding informative references to the OAuth SAML and JWT 
> Profile documents in the Assertions draft.  After this sentence of the 
> Introduction:
>
> In order to be implementable, companion specifications are necessary 
> to provide the corresponding concrete instantiations.
>
> I'd add the following:
>
> For instance, the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 
> [draft-ietf-oauth-saml2-bearer] defines a concrete instantiation for 
> SAML 2.0 tokens and JSON Web Token (JWT) Bearer Token Profiles for 
> OAuth 2.0 [draft-ietf-oauth-jwt-bearer] defines a concrete 
> instantiation for JWT tokens.
>
> Doing that will help readers find the concrete instances from the 
> abstract specification.
>
> Thanks,
>
> -- Mike
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    
+1, cross references are a good thing
      when documents are split up.

      

      On 12/19/2012 04:33 PM, Mike Jones wrote:

    

    

      
      
      
      

        
I’d suggest adding informative references
          to the OAuth SAML and JWT Profile documents in the Assertions
          draft.  After this sentence of the Introduction:

        
 

        
In order to be implementable, companion
            specifications are necessary to provide the corresponding
            concrete instantiations.

        
 

        
I’d add the following:

        
 

        
For instance, the SAML 2.0 Bearer Assertion
            Profiles for OAuth 2.0 [draft-ietf-oauth-saml2-bearer]
            defines a concrete instantiation for SAML 2.0 tokens and
            JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
            [draft-ietf-oauth-jwt-bearer] defines a concrete
            instantiation for JWT tokens.

        
 

        
Doing that will help readers find the
          concrete instances from the abstract specification.

        
 

        
                                                           
          Thanks,

        
                                                           
          -- Mike

        
 

      

      

      

      

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


    

    

  


--------------040106000502000407030609--

From Michael.Jones@microsoft.com  Wed Dec 19 14:07:38 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320AA21F857A for ; Wed, 19 Dec 2012 14:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.776
X-Spam-Level: 
X-Spam-Status: No, score=-2.776 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8fNZAV-Z2Myy for ; Wed, 19 Dec 2012 14:07:37 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.27]) by ietfa.amsl.com (Postfix) with ESMTP id 46B2A21F854F for ; Wed, 19 Dec 2012 14:07:28 -0800 (PST)
Received: from BL2FFO11FD014.protection.gbl (10.173.161.204) by BL2FFO11HUB015.protection.gbl (10.173.160.107) with Microsoft SMTP Server (TLS) id 15.0.586.12; Wed, 19 Dec 2012 22:07:20 +0000
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Wed, 19 Dec 2012 22:07:19 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Wed, 19 Dec 2012 22:06:55 +0000
From: Mike Jones 
To: Justin Richer 
Thread-Topic: [OAUTH-WG] Additional informative references for Assertions draft
Thread-Index: Ac3eMHuqa1y1DpLzQAuxzlI/pXrpUwAAUFiAAADV3LA=
Date: Wed, 19 Dec 2012 22:06:54 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436697793D@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B168042967394366977847@TK5EX14MBXC283.redmond.corp.microsoft.com> <50D234C3.9070508@mitre.org>
In-Reply-To: <50D234C3.9070508@mitre.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.74]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436697793DTK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(164054002)(479174001)(24454001)(54316002)(550184003)(16406001)(77982001)(59766001)(46102001)(56776001)(5343635001)(54356001)(44976002)(15202345001)(51856001)(74662001)(53806001)(74502001)(5343655001)(47446002)(76482001)(49866001)(55846006)(56816002)(4396001)(47976001)(47736001)(16236675001)(512954001)(50986001)(31966008)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB015; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 070092A9D3
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Additional informative references for Assertions draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 22:07:38 -0000

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

BTW, the SAML purists would probably point out that I should have written "=
SAML 2.0 assertions" - not "SAML 2.0 tokens" below. :)

From: Justin Richer [mailto:jricher@mitre.org]
Sent: Wednesday, December 19, 2012 1:42 PM
To: Mike Jones
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Additional informative references for Assertions dr=
aft

+1, cross references are a good thing when documents are split up.

On 12/19/2012 04:33 PM, Mike Jones wrote:
I'd suggest adding informative references to the OAuth SAML and JWT Profile=
 documents in the Assertions draft.  After this sentence of the Introductio=
n:

In order to be implementable, companion specifications are necessary to pro=
vide the corresponding concrete instantiations.

I'd add the following:

For instance, the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 [draft-i=
etf-oauth-saml2-bearer] defines a concrete instantiation for SAML 2.0 token=
s and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0 [draft-ietf-=
oauth-jwt-bearer] defines a concrete instantiation for JWT tokens.

Doing that will help readers find the concrete instances from the abstract =
specification.

                                                            Thanks,
                                                            -- Mike





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


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











BTW, the SAML purists =
would probably point out that I should have written “SAML 2.0 asserti=
ons” – not “SAML 2.0 tokens” below.
J


 






From: Justin Richer [mailto:jricher@mitre.org]


Sent: Wednesday, December 19, 2012 1:42 PM

To: Mike Jones

Cc: oauth@ietf.org WG

Subject: Re: [OAUTH-WG] Additional informative references for Assert=
ions draft






 




+1, cross references are a good thing when docum=
ents are split up.



On 12/19/2012 04:33 PM, Mike Jones wrote:






I’d suggest adding informative references to t=
he OAuth SAML and JWT Profile documents in the Assertions draft.  Afte=
r this sentence of the Introduction:


 


In order to=
 be implementable, companion specifications are necessary to provide the co=
rresponding concrete instantiations.


 


I’d add the following:


 


For instanc=
e, the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 [draft-ietf-oauth-s=
aml2-bearer] defines a concrete instantiation for
 SAML 2.0 tokens and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2=
.0 [draft-ietf-oauth-jwt-bearer] defines a concrete instantiation for JWT t=
okens.


 


Doing that will help readers find the concrete insta=
nces from the abstract specification.


 


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


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


 











_______________________________________________


OAuth mailing list


OAuth@ietf.org


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




 






--_000_4E1F6AAD24975D4BA5B16804296739436697793DTK5EX14MBXC283r_--

From bcampbell@pingidentity.com  Wed Dec 19 15:01:40 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C535221F88E3 for ; Wed, 19 Dec 2012 15:01:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.74
X-Spam-Level: 
X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[AWL=1.237,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-Pj4vyHsfwW for ; Wed, 19 Dec 2012 15:01:40 -0800 (PST)
Received: from na3sys009aog138.obsmtp.com (na3sys009aog138.obsmtp.com [74.125.149.19]) by ietfa.amsl.com (Postfix) with ESMTP id 00B0C21F88DB for ; Wed, 19 Dec 2012 15:01:39 -0800 (PST)
Received: from mail-ye0-f200.google.com ([209.85.213.200]) (using TLSv1) by na3sys009aob138.postini.com ([74.125.148.12]) with SMTP ID DSNKUNJHUHeW1s6sqD23rNGpUZ7PIz4rBBFh@postini.com; Wed, 19 Dec 2012 15:01:40 PST
Received: by mail-ye0-f200.google.com with SMTP id r13so3917422yen.3 for ; Wed, 19 Dec 2012 15:01:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=2nQZ252RrAT9h7klzc8ZLUyjnM9LE9aYklxV1zZ7y6s=; b=OH9NwFnI6jg06M19bWhBtUk1u2nh8s0rC6UGmO97i/7UfOX0K1IKnaF2Sjg6mj9NFa peaqt1LDdeT55Q0wT/0t6gQ1gExdeMuAAOjkO3sl6X+FrfqYXJ4EK0mkfsM27hs9J07G lPWTjooEV+ngGrUDPjBFsJ19c9C+2/RPYkeO2/lZ9q1u48E4M+D9zeItwhjcG3X1PAuj vjzLaIGrhb4FJPSvXj/hi40gEhA9cewNSksMIyDyQ5K7azLpobjlFXxo5hJ1R7/DT6of go6wy2Npk8x10Fk7POIVllp+wKEGNDfzr9tzgOhCkcWnmpOivkqRLH2Jt/j/ITUgIV62 XCCQ==
X-Received: by 10.52.37.9 with SMTP id u9mr9882947vdj.83.1355958095998; Wed, 19 Dec 2012 15:01:35 -0800 (PST)
Received: by 10.52.37.9 with SMTP id u9mr9882934vdj.83.1355958095912; Wed, 19 Dec 2012 15:01:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.163.170 with HTTP; Wed, 19 Dec 2012 15:01:04 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697793D@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B168042967394366977847@TK5EX14MBXC283.redmond.corp.microsoft.com> <50D234C3.9070508@mitre.org> <4E1F6AAD24975D4BA5B16804296739436697793D@TK5EX14MBXC283.redmond.corp.microsoft.com>
From: Brian Campbell 
Date: Wed, 19 Dec 2012 16:01:04 -0700
Message-ID: 
To: Mike Jones 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlMEWZQnzao242AKqwtYgVvblAN9YnG4DJscv4HVaYOXVpAoIjfYOU9UFF2kny8QStqz1qp4d0HESyGSVrXq27QFPmdCdHnJ5ar1hgYm0ymPH2ZO4aJlFh5AXvXRylEPuNv0aPW
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] Additional informative references for Assertions draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 19 Dec 2012 23:01:40 -0000

+1 for the references

On Wed, Dec 19, 2012 at 3:06 PM, Mike Jones  w=
rote:
> BTW, the SAML purists would probably point out that I should have written
> =93SAML 2.0 assertions=94 =96 not =93SAML 2.0 tokens=94 below. J
>
>
>
> From: Justin Richer [mailto:jricher@mitre.org]
> Sent: Wednesday, December 19, 2012 1:42 PM
> To: Mike Jones
> Cc: oauth@ietf.org WG
> Subject: Re: [OAUTH-WG] Additional informative references for Assertions
> draft
>
>
>
> +1, cross references are a good thing when documents are split up.
>
> On 12/19/2012 04:33 PM, Mike Jones wrote:
>
> I=92d suggest adding informative references to the OAuth SAML and JWT Pro=
file
> documents in the Assertions draft.  After this sentence of the Introducti=
on:
>
>
>
> In order to be implementable, companion specifications are necessary to
> provide the corresponding concrete instantiations.
>
>
>
> I=92d add the following:
>
>
>
> For instance, the SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
> [draft-ietf-oauth-saml2-bearer] defines a concrete instantiation for SAML
> 2.0 tokens and JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
> [draft-ietf-oauth-jwt-bearer] defines a concrete instantiation for JWT
> tokens.
>
>
>
> Doing that will help readers find the concrete instances from the abstrac=
t
> specification.
>
>
>
>                                                             Thanks,
>
>                                                             -- Mike
>
>
>
>
>
>
> _______________________________________________
>
> OAuth mailing list
>
> OAuth@ietf.org
>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

From Michael.Jones@microsoft.com  Wed Dec 19 16:15:43 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F347121F8A05 for ; Wed, 19 Dec 2012 16:15:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.764
X-Spam-Level: 
X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zb21n5pMYIFV for ; Wed, 19 Dec 2012 16:15:28 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFD321F8887 for ; Wed, 19 Dec 2012 16:15:27 -0800 (PST)
Received: from BY2FFO11FD005.protection.gbl (10.1.15.201) by BY2FFO11HUB019.protection.gbl (10.1.14.178) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 00:15:18 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 00:15:18 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 00:14:56 +0000
From: Mike Jones 
To: =JeffH , IETF oauth WG 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: AQHNzO3gFPMEcqRdxE+2+f2vGdoyFpggrUnA
Date: Thu, 20 Dec 2012 00:14:55 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366979DAD@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <50B53D3E.1000107@KingsMountain.com>
In-Reply-To: <50B53D3E.1000107@KingsMountain.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.74]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366979DADTK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(51704002)(46102001)(54316002)(59766001)(77982001)(56776001)(47976001)(550184003)(512954001)(53806001)(47736001)(55846006)(74502001)(5343645001)(15395725002)(15202345001)(51856001)(4396001)(56816002)(47446002)(76482001)(5343655001)(49866001)(54356001)(5343635001)(16236675001)(44976002)(16297215001)(16406001)(33656001)(50986001)(74662001)(31966008)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB019; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07013D7479
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 00:15:43 -0000

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

Thanks a bunch for the useful review, Jeff!  Responses are inline in green.



                                                                -- Mike



-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =
=3DJeffH
Sent: Tuesday, November 27, 2012 2:23 PM
To: IETF oauth WG
Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05



Hi, at ietf-85 atlanta I agreed to do a review of draft-ietf-oauth-json-web=
-token-05, and so I have some thoughts below. Also, +1 to Hannes' comments.



Overall the spec seems to get its idea across, but is pretty rough. Part of=
 this is due to the language being convoluted, plus some concepts are only =
tacitly described (with clues scattered throughout the spec), and thus it i=
s difficult to understand without multiple passes of this spec as well as [=
JWE] and [JWS].



For example, a JWT appears to be simply either a JWS or a JWE containing a =
JWT Claims Set, but this is not stated until right before section 3.1 (and =
it isn't stated that clearly).



OK, I'll say that earlier and more clearly.



Immediately below are some overall comments, and then below that some detai=
led comments on various portions of the spec.  I'm not addressing everythin=
g I noticed due to time constraints (apologies).



HTH



=3DJeffH

------





JWT terminology:



Some issues seem to me to be caused by defining the JWT to be the base64url=
 encoded JSON  object itself and not having terminology to clearly refer to=
 its unencoded form.



For example, these two JSON objects together apparently comprise a (unencod=
ed) JWT..



      {"typ":"JWT",

       "alg":"HS256"}



This is the JWT Header.  The base64url encoded version is the Encoded JWT H=
eader.



      {"iss":"joe",

       "exp":1300819380,

       "http://example.com/is_root":true}



This is the JWT Claims Set.



..but there's no defined way to refer to them given the spec's terminlogy.



The terms above are already defined in the spec.



Consider terming the above a JWT and its encoded-string form an Encoded JWT=
, and define them separately. And then there'll be similar definitions for =
JWT Header and JWT Claims Set, e.g.,



I disagree with redefining the term "JWT" to not also include the signature=
.  The term "JWT" should continue to refer to the whole thing.



    Encoded JWT   A JWT that has been encoded according to the

       process defined in Section X.



    Encoded JWT Header   The encoded-string form of a JWT Header



    Encoded JWT Claims Set   The encoded-string form of a JWT Claims Set



I'll note that when the JWT is encrypted, a base64url encoded representatio=
n of the JWT Claims Set is never used.  (The encrypted form of them is base=
64url encoded instead.)



    encoded-string form   The result of applying Base64url encoding to an

       input JSON text .



Sometimes he input to the base64url encoding is not JSON - for instance sig=
nature values or encrypted payloads.



    JSON Web Token (JWT)  A JWT comprises a JWT Header and a JWT Claims Set=
. ...



    JWT Header  A JSON object that is a component of a JWT. It denotes the

       cryptographic operations applied to the JWT.  ...



    JWT Claims Set  A JSON object containing a set of claims.  ...



This also gets rid of the use of the "A string representing a JSON object..=
."

which I find confusing and potentially misleading (because it is actually "=
a Base64url encoding of a JSON object").



Aah - I now see that this is the real misunderstanding.  The "string repres=
enting a JSON object" is not the base64url encoded form - it's the string r=
epresentation that's parseable into a JSON object.  For instance, it could =
be a string such as {"alg":"RS256"} - not the base64url encoded version of =
that string.  The reason for the syntactic construction "string representin=
g a JSON object" is that its string representation is distinct from the abs=
tract JSON object itself.  If I insert whitespace after the colon in the st=
ring {"alg":"RS256"} it would parse to an equivalent JSON object but it wou=
ld be a different string representation.  It's the string representation th=
at is actually operated on by the JWT/JWS/JWE operations.



I'll try to make this clearer in the spec.



UTF-8:



UTF-8 is mentioned in lots of places. It could probably be stated once up n=
ear

the beginning of the spec that all the JSON text is UTF-8 encoded, and all =
the

JSON strings are UTF-8 encoded.



I'll see if I can figure out how to do this without introducing ambiguity.



Semantics, profiles and relationship to SAML:



The spec does not define any overall JWT semantics (i.e., what any given JW=
T

/means/). Semantics are only defined in context of each individual Reserved

Claim Name.



Thus any application of JWTs will need to profile the JWT spec: specifying =
the

claim set(s) contents, and the overall semantics of the resultant JWT(s).  =
This

is not explicitly explained in the JWT spec.



Can you suggest some language you'd like to see added about this?



In terms of SAML, Appendix B should refer to SAML assertions rather than sa=
ml

tokens. Also, I'm not sure SAML assertions inherently have more expressivit=
y

than JWTs. They do have more pre-defined structure and semantics.



OK



Syntactically, it seems one can encode pretty much anything in whatever amo=
unt

in a JWT (one can do the same with SAML assertions), and thus theoretically=
 JWTs

could be used to accomplish the same things as SAML assertions.



Semantically, SAML assertions are explicitly statements made by a system en=
tity

about a subject. But by default, a JWT is empty, and has no semantics (this

isn't stated explicitly). All semantics defined in the JWT spec are particu=
lar

to individual reserved claims, but all reserved claims are optional. Thus a=
n

application of JWTs to use cases also apropos for SAML assertions will requ=
ire

arguably more profiling than that needed to apply SAML assertions.



All true.  However once you add an issuer and a principal, then you're back=
 to the JWT being statements made by an entity about a subject.  Again, if =
there is language you believe should be added in that regard, please let me=
 know.  (BTW, one such usage profile is in http://tools.ietf.org/html/draft=
-ietf-oauth-jwt-bearer-03.  Another is in http://openid.net/specs/openid-co=
nnect-messages-1_0.html#id_token.)



The token size & complexity comparison seems nominally fine.



Some detailed-but-rough comments and musings on portions of the spec as I w=
as

reading through it...



> 2. Terminology



terminology is not alphabetised!



No, it's in a top-down descriptive order.  Is there a requirement in IETF s=
pecs that the terminology be alphabetized?



"claim", "claims", "token" should be defined in terminology



I'll add a definition for "claim".  "token" should actually probably become=
 "security token", with a definition of the term.



suggestion:



      Claim:  an assertion of something as a fact. Here, claims are

         name and value pairs, consisting of a Claim Name and a

         Claim Value.





>    JSON Web Token (JWT)



   is jwt always a "string" or is it string (only) when it's been serialize=
d

into one?



It's always the string representation of the serialized parts.



>                    A string representing a set of claims as a JSON

>       object that is digitally signed or MACed and/or encrypted.



   is it more that it's a set of claims encoded as a JSON object

   that is string-serialized?



No, per my earlier comments



   is it /not/ a JWT by definition if it is not ((signed or unmac'd) and/or

encrypted) ?   No, because there are Plaintext JWTs, but they aren't in

terminology (probably should be).



Good catch



   "parts" in JWT definition is unclear

     are "parts" json objects or arrays unto themselves ?



The parts are all base64url encoded values.  I'll review this terminology u=
sage to see if it can be clarified.



   the definition assumes knowledge that's presented later. perhaps needs f=
wd

   reference(s), or perhaps better is to not present as much technical deta=
il

   in the definitions.



I'll review



>    JWT Claims Set



   similar comments as to JSON Web Token (JWT)



   the definition says how it is encoded and encrypted, but not how claims =
are

mapped into a JSON object





should probably be simply:



    JWT Claims Set: A set of claims expressed as a JSON object, where each

       claim is an object member (i.e., a name/value pair). A claim may hav=
e

       a JWT Claims Set as a value.



I'll look into moving the definition in this direction.  What you're missin=
g in the above, though, is the distinction between the string representing =
the JSON object and the abstract JSON object.  We want the former.



>    Claim Name  The name of a member of the JSON object representing a

>       JWT Claims Set.



should probably be simply:



    Claim Name  The name portion of a claim, expressed as a JSON object mem=
ber

       name.





>    Claim Value  The value of a member of the JSON object representing a

>       JWT Claims Set.



should probably be simply:



    Claim Value  The value portion of a claim, expressed as a JSON object m=
ember

       value.



I'll look into moving the definitions in this direction.



> 3. JSON Web Token (JWT) Overview



>    The bytes of the UTF-8 representation of the JWT Claims Set are

>    digitally signed or MACed in the manner described in JSON Web

>    Signature (JWS) [JWS] and/or encrypted in the manner described in

>    JSON Web Encryption (JWE) [JWE].



s/ and/or encrypted / or encrypted and signed /



I think you mean "encrypted and integrity protected" rather than "encrypted=
 and signed", right?



>    The contents of the JWT Header describe the cryptographic operations

>    applied to the JWT Claims Set. If the JWT Header is a JWS Header, the

>    claims are digitally signed or MACed.  If the JWT Header is a JWE

>    Header, the claims are encrypted.



What if a JWT is signed AND encrypted?  Hm, from my looking at JWS and JWE

specs, it seems that in that case one uses JWE because that encompasses bot=
h

encrypt & sign.



No, actually JWE just provides an integrity check - not a signature.  If yo=
u want a signature, you need to use JWS.  They can (and often are) used in =
a nested fashion.



>    A JWT is represented as a JWS or JWE.  The number of parts is

>    dependent upon the representation of the resulting JWS or JWE.



Does the above mean to say..



    A JWT consists of a JWS or JWE object, which in turn conveys the JWT

    Claims Set. In the case of a JWS, the JWT Claims Set is the JWS

    Payload. In the case of a JWE, the JWT Claims Set is the input

    Plaintext.



Yes.  Although this is missing the fact that nested signing/encryption may =
be employed.



> 4. JWT Claims

>

>

>    The JWT Claims Set represents a JSON object whose members are the

>    claims conveyed by the JWT.  The Claim Names within this object MUST

>    be unique; JWTs with duplicate Claim Names MUST be rejected.



does the above mean to say claim names must be unique amongst the set of cl=
aim

names within any given JWT Claims Set ?  If so, that's only implied by the =
above

but should be stated explicitly; as it is, the above is ambiguous.



OK



> 4.2. Public Claim Names

>

>

>    Claim names can be defined at will by those using JWTs.  However, in



s/Claim names/Public claim names/



>    order to prevent collisions, any new claim name SHOULD either be

>    registered in the IANA JSON Web Token Claims registry Section 9.1 or

>    be a URI that contains a Collision Resistant Namespace.





why should a claim name be a URI if I wish to make use of Collision Resista=
nt

Namespaces?  For example, if I simply use say UUIDs as claim names..



      {"iss":"joe",

       "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}



..it will be universally unique provided I minted it appropriately (no URI

syntax is needed).



Fair enough.  I'll try to generalize the language.



> 4.3. Private Claim Names

>

>

>    A producer and consumer of a JWT may agree to any claim name that is

>    not a Reserved Name Section 4.1 or a Public Name Section 4.2.  Unlike

>    Public Names, these private names are subject to collision and should

>    be used with caution.



it seems private claim names are only subject to collision if the implement=
ers

don't make appropriate use of Collision Resistant Namespaces, i.e. they "ca=
n be"

subject to collision.



True



the above two sections use "public" and "private" as distinguishing factors=
, but

it seems to me the distinguishing factor (given how the above is written) i=
s

more whether Collision Resistant Namespaces are employed or not.



Yes, although using a collision resistant namespace effectively makes them =
public, as we're using the term



An implied aspect of public claim names seems to be that it is assumed that=
 they

are publicly listed/documented/leaked, thus the "public" moniker, and hence

ought to be universally unique as a matter of course.



and "private" ones seem to be assumed to be obfuscated to all but the agree=
ing

parties?  Or they are "private" in only the sense that they are created in =
the

context of a private arrangement?



Private in that they are created in the context of a private arrangement.  =
I'll try to clarify this point.  Facebook could define how they're going to=
 use the "id" claim very publicly, and yet it would still be a private clai=
m if not registered with IANA.



>

> 7. Rules for Creating and Validating a JWT

>

>

>    To create a JWT, one MUST perform these steps.  The order of the

>    steps is not significant in cases where there are no dependencies

>    between the inputs and outputs of the steps.

>

>    1.  Create a JWT Claims Set containing the desired claims.  Note that

>        white space is explicitly allowed in the representation and no

>        canonicalization is performed before encoding.



I presume the rationale for allowing white space is that JSON objects are

unordered (and can contain arbitrary whitespace), thus simple buffer-to-buf=
fer

comparisons between serialized objects cannot be reliably performed.  If so=
 this

should be explicitly stated.



Actually, it's to avoid canonicalization.  I'll reread the spec to see if w=
e've stated that clearly or not.



It seems that member/value-by-member/value comparisons must always be done,=
 by

parsing the JSON objects and extracting all members and values, this should=
 be

stated explicitly in the spec.



I found meager jwt comparison instructions at the very end of Section 7. it

should probably be its own subsection. It should probably explicitly say th=
at

JWTs need to be parsed into their constituent components, and the latter mu=
st be

individually examined/compared.



We tried to cover this in the end of section 7, starting with the sentence =
"Processing a JWT inevitably requires comparing known strings to values in =
the token", which says how these comparisons must be performed.  I agree th=
at this should become its own subsection.  I don't understand your remark a=
bout constituent components.  Can you clarify?



>    Comparisons between JSON strings and other Unicode strings MUST be

>    performed as specified below:



this comparison algorithm seems to be attempting to allow for comparison of

UTF-8 encoded JSON strings with other unicode strings in any of the unicode

encoding formats, but only implies that; it should be stated.



Good



>

>    1.  Remove any JSON applied escaping to produce an array of Unicode

>        code points.



I don't think (1) is correct.  A JSON string is by default encoded in UTF-8=
. A

UTF-8 encoded string is not "an array of Unicode code points" (its a sequen=
ce of

code units, which must be decoded into code points), i think a step is miss=
ing

here..



    1.  Remove any JSON escaping from the input JSON string.



    1.a  convert the string into a sequence of unicode code points.



How about "Remove any JSON escaping from the input JSON string and convert =
the string into a sequence of Unicode code points"?



..and then compare code point-by-code point. This overall algorithm /seems/=
 ok,

but I'm not sure, it seems there's rationale that's not expressed, eg for

excluding use of Unicode Normalization [USA15]. Also the alg is incomplete =
in

that it doesn't stipulate converting the "other unicode string" into a sequ=
ence

of code points.



Fair enough



> 10. Security Considerations

>

>

>    All of the security issues faced by any cryptographic application

>    must be faced by a JWT/JWS/JWE/JWK agent.  Among these issues are

>    protecting the user's private key, preventing various attacks, and

>    helping the user avoid mistakes such as inadvertently encrypting a

>    message for the wrong recipient.  The entire list of security

>    considerations is beyond the scope of this document, but some

>    significant concerns are listed here.

>

>    All the security considerations in the JWS specification also apply

>    to JWT, as do the JWE security considerations when encryption is

>    employed.  In particular, the JWS JSON Security Considerations and

>    Unicode Comparison Security Considerations apply equally to the JWT

>    Claims Set in the same manner that they do to the JWS Header.

>



dunno if you can get away with sec cons wholly in other docs, and I'm not s=
ure

it's appropriate given that JWTs are a profile of JWE or JWS.



That was the approach that Sean had suggested.  If there other things you t=
hink we should specifically add, however, please let me know.



above needs editorial polish -- there aren't any  "significant concerns"

actually listed here.



True enough



---

end





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

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











Thanks a bunch for the useful review, Jeff! =
 Responses are inline
in green.


 


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


 


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

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

Sent: Tuesday, November 27, 2012 2:23 PM

To: IETF oauth WG

Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05


 


Hi, at ietf-85 atlanta I agreed to do a review of=
 draft-ietf-oauth-json-web-token-05, and so I have some thoughts below. Als=
o, +1 to Hannes' comments.


 


Overall the spec seems to get its idea across, bu=
t is pretty rough. Part of this is due to the language being convoluted, pl=
us some concepts are only tacitly described (with clues scattered throughou=
t the spec), and thus it is difficult
 to understand without multiple passes of this spec as well as [JWE] and [J=
WS].


 


For example, a JWT appears to be simply either a =
JWS or a JWE containing a JWT Claims Set, but this is not stated until righ=
t before section 3.1 (and it isn't stated that clearly).


 


OK, I’ll say =
that earlier and more clearly.


 


Immediately below are some overall comments, and =
then below that some detailed comments on various portions of the spec.&nbs=
p; I'm not addressing everything I noticed due to time constraints (apologi=
es).


 


HTH


 


=3DJeffH


------


 


 


JWT terminology:


 


Some issues seem to me to be caused by defining t=
he JWT to be the base64url encoded JSON  object itself and not having =
terminology to clearly refer to its unencoded form.


 


For example, these two JSON objects together appa=
rently comprise a (unencoded) JWT..


 


      {"typ":&=
quot;JWT",


       "alg&qu=
ot;:"HS256"}


 


This is the JWT Hea=
der.  The base64url encoded version is the Encoded JWT Header.


 


      {"iss":&=
quot;joe",


       "exp&qu=
ot;:1300819380,


       "http://example.com/is_root":true}

 


This is the JWT Cla=
ims Set.


 


..but there's no defined way to refer to them giv=
en the spec's terminlogy.


 


The terms above are=
 already defined in the spec.


 


Consider terming the above a JWT and its encoded-=
string form an Encoded JWT, and define them separately. And then there'll b=
e similar definitions for JWT Header and JWT Claims Set, e.g.,

 


I disagree with red=
efining the term “JWT” to not also include the signature. =
 The term “JWT” should continue to refer to the whole thing.


 


    Encoded JWT   A JWT =
that has been encoded according to the


       process defi=
ned in Section X.


 


    Encoded JWT Header  =
 The encoded-string form of a JWT Header


 


    Encoded JWT Claims Set &n=
bsp; The encoded-string form of a JWT Claims Set


 


I’ll note tha=
t when the JWT is encrypted, a base64url encoded representation of the JWT =
Claims Set is never used.  (The encrypted form of them is base64url en=
coded instead.)


 


    encoded-string form  =
; The result of applying Base64url encoding to an


       input JSON t=
ext .


 


Sometimes he input =
to the base64url encoding is not JSON – for instance signature values=
 or encrypted payloads.


 


    JSON Web Token (JWT)  A J=
WT comprises a JWT Header and a JWT Claims Set. ...


 


    JWT Header  A JSON object=
 that is a component of a JWT. It denotes the


       cryptographi=
c operations applied to the JWT.  ...


 


    JWT Claims Set  A JSON ob=
ject containing a set of claims.  ...


 


This also gets rid of the use of the "A stri=
ng representing a JSON object..."



which I find confusing and potentially misleading=
 (because it is actually "a Base64url encoding of a JSON object")=
.


 


Aah – I now s=
ee that this is the real misunderstanding.  The “string represen=
ting a JSON object” is not the base64url encoded form – it̵=
7;s the string representation that’s parseable into a JSON object.&nb=
sp; For
 instance, it could be a string such as {“alg”:”RS256R=
21;} – not the base64url encoded version of that string.  The re=
ason for the syntactic construction “string representing a JSON objec=
t” is that its string representation is distinct from the abstract JS=
ON object
 itself.  If I insert whitespace after the colon in the string {“=
;alg”:”RS256”} it would parse to an equivalent JSON objec=
t but it would be a different string representation.  It’s the s=
tring representation that is actually operated on by the JWT/JWS/JWE operat=
ions.


 


I’ll try to m=
ake this clearer in the spec.


 


UTF-8:


 


UTF-8 is mentioned in lots of places. It could pr=
obably be stated once up near



the beginning of the spec that all the JSON text =
is UTF-8 encoded, and all the



JSON strings are UTF-8 encoded.


 


I’ll see if I=
 can figure out how to do this without introducing ambiguity.


 


Semantics, profiles and relationship to SAML:


 


The spec does not define any overall JWT semantic=
s (i.e., what any given JWT



/means/). Semantics are only defined in context o=
f each individual Reserved



Claim Name.


 


Thus any application of JWTs will need to profile=
 the JWT spec: specifying the



claim set(s) contents, and the overall semantics =
of the resultant JWT(s).  This



is not explicitly explained in the JWT spec.=



 


Can you suggest som=
e language you’d like to see added about this?


 


In terms of SAML, Appendix B should refer to SAML=
 assertions rather than saml



tokens. Also, I'm not sure SAML assertions inhere=
ntly have more expressivity



than JWTs. They do have more pre-defined structur=
e and semantics.


 


OK


 


Syntactically, it seems one can encode pretty muc=
h anything in whatever amount



in a JWT (one can do the same with SAML assertion=
s), and thus theoretically JWTs



could be used to accomplish the same things as SA=
ML assertions.


 


Semantically, SAML assertions are explicitly stat=
ements made by a system entity



about a subject. But by default, a JWT is empty, =
and has no semantics (this



isn't stated explicitly). All semantics defined i=
n the JWT spec are particular



to individual reserved claims, but all reserved c=
laims are optional. Thus an



application of JWTs to use cases also apropos for=
 SAML assertions will require



arguably more profiling than that needed to apply=
 SAML assertions.


 


All true.  How=
ever once you add an issuer and a principal, then you’re back to the =
JWT being statements made by an entity about a subject.  Again, if the=
re is language you believe should be added in that regard,
 please let me know.  (BTW, one such usage profile is in 
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.  Anothe=
r is in 
http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)


 


The token size & complexity comparison seems =
nominally fine.


 


Some detailed-but-rough comments and musings on p=
ortions of the spec as I was



reading through it...


 


> 2. Terminology


 


terminology is not alphabetised!


 


No, it’s in a=
 top-down descriptive order.  Is there a requirement in IETF specs tha=
t the terminology be alphabetized?


 


"claim", "claims", "toke=
n" should be defined in terminology


 


I’ll add a de=
finition for “claim”.  “token” should actually=
 probably become “security token”, with a definition of the ter=
m.


 


suggestion:


 


      Claim:  an as=
sertion of something as a fact. Here, claims are


         =
name and value pairs, consisting of a Claim Name and a


         =
Claim Value.


 


 


>    JSON Web Token (JWT)<=
/o:p>


 


   is jwt always a "string" o=
r is it string (only) when it's been serialized



into one?


 


It’s always t=
he string representation of the serialized parts.


 


>       &nb=
sp;            A str=
ing representing a set of claims as a JSON


>       object t=
hat is digitally signed or MACed and/or encrypted.


 


   is it more that it's a set of claims=
 encoded as a JSON object


   that is string-serialized?


 


No, per my earlier =
comments 



 


   is it /not/ a JWT by definition if i=
t is not ((signed or unmac'd) and/or



encrypted) ?   No, because there are Pl=
aintext JWTs, but they aren't in



terminology (probably should be).


 


Good catch


 


   "parts" in JWT definition =
is unclear


     are "parts" js=
on objects or arrays unto themselves ?


 


The parts are all b=
ase64url encoded values.  I’ll review this terminology usage to =
see if it can be clarified.


 


   the definition assumes knowledge tha=
t's presented later. perhaps needs fwd


   reference(s), or perhaps better is t=
o not present as much technical detail


   in the definitions.


 


I’ll review


 


>    JWT Claims Set<=
/p>

 


   similar comments as to JSON Web Toke=
n (JWT)


 


   the definition says how it is encode=
d and encrypted, but not how claims are



mapped into a JSON object


 


 


should probably be simply:


 


    JWT Claims Set: A set of claim=
s expressed as a JSON object, where each


       claim is an =
object member (i.e., a name/value pair). A claim may have


       a JWT Claims=
 Set as a value.


 


I’ll look int=
o moving the definition in this direction.  What you’re missing =
in the above, though, is the distinction between the string representing th=
e JSON object and the abstract JSON object.  We want
 the former.


 


>    Claim Name  The name =
of a member of the JSON object representing a


>       JWT Clai=
ms Set.


 


should probably be simply:


 


    Claim Name  The name port=
ion of a claim, expressed as a JSON object member


       name.


 


 


>    Claim Value  The valu=
e of a member of the JSON object representing a


>       JWT Clai=
ms Set.


 


should probably be simply:


 


    Claim Value  The value po=
rtion of a claim, expressed as a JSON object member


       value.<=
/o:p>


 


I’ll look int=
o moving the definitions in this direction. 



 


> 3. JSON Web Token (JWT) Overview<=
/p>

 


>    The bytes of the UTF-8 rep=
resentation of the JWT Claims Set are


>    digitally signed or MACed =
in the manner described in JSON Web


>    Signature (JWS) [JWS] and/=
or encrypted in the manner described in


>    JSON Web Encryption (JWE) =
[JWE].


 


s/ and/or encrypted / or encrypted and signed /


 


I think you mean &#=
8220;encrypted and integrity protected” rather than “encrypted =
and signed”, right?


 


>    The contents of the JWT He=
ader describe the cryptographic operations


>    applied to the JWT Claims =
Set. If the JWT Header is a JWS Header, the


>    claims are digitally signe=
d or MACed.  If the JWT Header is a JWE


>    Header, the claims are enc=
rypted.


 


What if a JWT is signed AND encrypted?  Hm, =
from my looking at JWS and JWE



specs, it seems that in that case one uses JWE be=
cause that encompasses both



encrypt & sign.


 


No, actually JWE ju=
st provides an integrity check – not a signature.  If you want a=
 signature, you need to use JWS.  They can (and often are) used in a n=
ested fashion.


 


>    A JWT is represented as a =
JWS or JWE.  The number of parts is


>    dependent upon the represe=
ntation of the resulting JWS or JWE.


 


Does the above mean to say..


 


    A JWT consists of a JWS or JWE=
 object, which in turn conveys the JWT


    Claims Set. In the case of a J=
WS, the JWT Claims Set is the JWS


    Payload. In the case of a JWE,=
 the JWT Claims Set is the input


    Plaintext.


 


Yes.  Although=
 this is missing the fact that nested signing/encryption may be employed.


 


> 4. JWT Claims


>


>


>    The JWT Claims Set represe=
nts a JSON object whose members are the


>    claims conveyed by the JWT=
.  The Claim Names within this object MUST


>    be unique; JWTs with dupli=
cate Claim Names MUST be rejected.


 


does the above mean to say claim names must be un=
ique amongst the set of claim



names within any given JWT Claims Set ?  If =
so, that's only implied by the above



but should be stated explicitly; as it is, the ab=
ove is ambiguous.


 


OK


 


> 4.2. Public Claim Names


>


>


>    Claim names can be defined=
 at will by those using JWTs.  However, in


 


s/Claim names/Public claim names/


 


>    order to prevent collision=
s, any new claim name SHOULD either be


>    registered in the IANA JSO=
N Web Token Claims registry Section 9.1 or


>    be a URI that contains a C=
ollision Resistant Namespace.


 


 


why should a claim name be a URI if I wish to mak=
e use of Collision Resistant



Namespaces?  For example, if I simply use sa=
y UUIDs as claim names..


 


      {"iss":&=
quot;joe",


       "3005fa=
05-e76c-4994-bbc9-65b2ace2305c":"foo"}


 


..it will be universally unique provided I minted=
 it appropriately (no URI



syntax is needed).


 


Fair enough.  =
I’ll try to generalize the language.


 


> 4.3. Private Claim Names


>


>


>    A producer and consumer of=
 a JWT may agree to any claim name that is


>    not a Reserved Name Sectio=
n 4.1 or a Public Name Section 4.2.  Unlike


>    Public Names, these privat=
e names are subject to collision and should


>    be used with caution.=



 


it seems private claim names are only subject to =
collision if the implementers



don't make appropriate use of Collision Resistant=
 Namespaces, i.e. they "can be"



subject to collision.


 


True


 


the above two sections use "public" and=
 "private" as distinguishing factors, but



it seems to me the distinguishing factor (given h=
ow the above is written) is



more whether Collision Resistant Namespaces are e=
mployed or not.


 


Yes, although using=
 a collision resistant namespace effectively makes them public, as we’=
;re using the term


 


An implied aspect of public claim names seems to =
be that it is assumed that they



are publicly listed/documented/leaked, thus the &=
quot;public" moniker, and hence



ought to be universally unique as a matter of cou=
rse.


 


and "private" ones seem to be assumed t=
o be obfuscated to all but the agreeing



parties?  Or they are "private" in=
 only the sense that they are created in the



context of a private arrangement?


 


Private in that the=
y are created in the context of a private arrangement.  I’ll try=
 to clarify this point.  Facebook could define how they’re going=
 to use the “id” claim very publicly, and yet it would still
 be a private claim if not registered with IANA.


 


>


> 7. Rules for Creating and Validating a JWT


>


>


>    To create a JWT, one MUST =
perform these steps.  The order of the


>    steps is not significant i=
n cases where there are no dependencies


>    between the inputs and out=
puts of the steps.


>


>    1.  Create a JWT Clai=
ms Set containing the desired claims.  Note that


>        wh=
ite space is explicitly allowed in the representation and no


>        ca=
nonicalization is performed before encoding.


 


I presume the rationale for allowing white space =
is that JSON objects are



unordered (and can contain arbitrary whitespace),=
 thus simple buffer-to-buffer



comparisons between serialized objects cannot be =
reliably performed.  If so this



should be explicitly stated.


 


Actually, it’=
s to avoid canonicalization.  I’ll reread the spec to see if we&=
#8217;ve stated that clearly or not.


 


It seems that member/value-by-member/value compar=
isons must always be done, by



parsing the JSON objects and extracting all membe=
rs and values, this should be



stated explicitly in the spec.


 


I found meager jwt comparison instructions at the=
 very end of Section 7. it



should probably be its own subsection. It should =
probably explicitly say that



JWTs need to be parsed into their constituent com=
ponents, and the latter must be



individually examined/compared.


 


We tried to cover t=
his in the end of section 7, starting with the sentence “Processing a=
 JWT inevitably requires comparing known strings to values in the tokenR=
21;, which says how these comparisons must be performed. 
 I agree that this should become its own subsection.  I don’t un=
derstand your remark about constituent components.  Can you clarify?


 


>    Comparisons between JSON s=
trings and other Unicode strings MUST be


>    performed as specified bel=
ow:


 


this comparison algorithm seems to be attempting =
to allow for comparison of



UTF-8 encoded JSON strings with other unicode str=
ings in any of the unicode



encoding formats, but only implies that; it shoul=
d be stated.


 


Good


 


>


>    1.  Remove any JSON a=
pplied escaping to produce an array of Unicode


>        co=
de points.


 


I don't think (1) is correct.  A JSON string=
 is by default encoded in UTF-8. A



UTF-8 encoded string is not "an array of Uni=
code code points" (its a sequence of



code units, which must be decoded into code point=
s), i think a step is missing



here..


 


    1.  Remove any JSON escap=
ing from the input JSON string.


 


    1.a  convert the string i=
nto a sequence of unicode code points.


 


How about “Re=
move any JSON escaping from the input JSON string and convert the string in=
to a sequence of Unicode code points”?


 


..and then compare code point-by-code point. This=
 overall algorithm /seems/ ok,



but I'm not sure, it seems there's rationale that=
's not expressed, eg for



excluding use of Unicode Normalization [USA15]. A=
lso the alg is incomplete in



that it doesn't stipulate converting the "ot=
her unicode string" into a sequence



of code points.


 


Fair enough


 


> 10. Security Considerations


>


>


>    All of the security issues=
 faced by any cryptographic application


>    must be faced by a JWT/JWS=
/JWE/JWK agent.  Among these issues are


>    protecting the user's priv=
ate key, preventing various attacks, and


>    helping the user avoid mis=
takes such as inadvertently encrypting a


>    message for the wrong reci=
pient.  The entire list of security


>    considerations is beyond t=
he scope of this document, but some


>    significant concerns are l=
isted here.


>


>    All the security considera=
tions in the JWS specification also apply


>    to JWT, as do the JWE secu=
rity considerations when encryption is


>    employed.  In particu=
lar, the JWS JSON Security Considerations and


>    Unicode Comparison Securit=
y Considerations apply equally to the JWT


>    Claims Set in the same man=
ner that they do to the JWS Header.


>


 


dunno if you can get away with sec cons wholly in=
 other docs, and I'm not sure



it's appropriate given that JWTs are a profile of=
 JWE or JWS.


 


That was the approa=
ch that Sean had suggested.  If there other things you think we should=
 specifically add, however, please let me know.


 


above needs editorial polish -- there aren't any&=
nbsp; "significant concerns"



actually listed here.


 


True enough


 


---


end


 


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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






--_000_4E1F6AAD24975D4BA5B168042967394366979DADTK5EX14MBXC283r_--

From zhou.sujing@zte.com.cn  Wed Dec 19 16:33:28 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C9E21F881E; Wed, 19 Dec 2012 16:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.193
X-Spam-Level: 
X-Spam-Status: No, score=-98.193 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWCZXVbbYbFZ; Wed, 19 Dec 2012 16:33:27 -0800 (PST)
Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1384721F8202; Wed, 19 Dec 2012 16:33:27 -0800 (PST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id C5E7C125D1A0; Thu, 20 Dec 2012 08:35:24 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id qBK0X75T094905; Thu, 20 Dec 2012 08:33:07 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn)
In-Reply-To: 
To: Brian Campbell 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: 
From: zhou.sujing@zte.com.cn
Date: Thu, 20 Dec 2012 08:32:56 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-12-20 08:33:00, Serialize complete at 2012-12-20 08:33:00
Content-Type: multipart/alternative; boundary="=_alternative 0003276F48257AF9_="
X-MAIL: mse02.zte.com.cn qBK0X75T094905
Cc: "oauth@ietf.org WG" , "oauth-bounces@ietf.org" 
Subject: Re: [OAUTH-WG] Summary - "Assertion Framework - Why does issuer have to be either the client or a third party token service?"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 00:33:28 -0000

This is a multipart message in MIME format.
--=_alternative 0003276F48257AF9_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

QnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPiDQtNPaIDIwMTItMTIt
MjAgMDQ6MjY6MDM6DQoNCj4gVGhleSBhcmUganVzdCBzb21lIGV4YW1wbGVzIGFuZCBzaG91bGRu
J3QgbGltaXQgd2hvIG9yIHdoYXQgY2FuIGJlIHRoZSANCmlzc3Vlci4NCj4gDQo+IE1heWJlIGp1
c3QgcmVtb3ZpbmcgdGhhdCB3aG9sZSBzZW50ZW5jZSB0aGF0IHNheXMsICJUaGUgaXNzdWVyIG1h
eSBiZQ0KPiBlaXRoZXIgYW4gT0F1dGggY2xpZW50ICh3aGVuIGFzc2VydGlvbnMgYXJlIHNlbGYt
aXNzdWVkKSBvciBhIHRoaXJkDQo+IHBhcnR5IHRva2VuIHNlcnZpY2UuJyB3b3VsZCBiZSBiZXR0
ZXIsIGlmIGl0J3MgY2F1c2luZyBjb25mdXNpb24/DQpJdCBpcyBjYXVzaW5nIGNvbmZ1c2lvbiB3
aGVuIGVudGl0aWVzIGluIHRoZSBvYXV0aCBhcmNoaXRlY3R1cmUgYXJlIA0KaXNzdWVycy4gDQpJ
ZiB0aGUgd2hvbGUgc2VudGVuY2UgaXMgcmVtb3ZlZCwgc2ltaWxhciBzZW50ZW5jZXMgc3RpbGwg
ZXhpc3QgaW4gdGhlIA0KZm9sbG93aW5nIHBhcmFncmFwaHMsDQpjb25mdXNpb24gc3RpbGwgZXhp
c3RzLg0KDQpIb3cgYWJvdXQgYSBtb2RpZmljYXRpb24gZm9yIHNlY3Rpb24gMyANCg0KICJUaGUg
dG9rZW4gc2VydmljZSBpcyB0aGUgYXNzZXJ0aW9uIGlzc3VlcjsgaXRzICByb2xlIGlzIHRvIGZ1
bGZpbGwgDQpyZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoIHByZXNlbnQgdmFyaW91cyANCiBj
cmVkZW50aWFscywgYW5kIG1pbnQgYXNzZXJ0aW9ucyBhcyByZXF1ZXN0ZWQsIGZpbGwgdGhlbSB3
aXRoIGFwcHJvcHJpYXRlIA0KaW5mb3JtYXRpb24sIGFuZCBzaWduIHRoZW0uIiAgKGluICBzZWN0
aW9uIDMgKQ0KaW50byANCiAiVGhlIHRva2VuIHNlcnZpY2UgaXMgdGhlIGFzc2VydGlvbiBpc3N1
ZXIsIGl0IGNvdWxkIGJlIGltcGxlbWVudGVkIGluIA0KYW55IGVudGl0eSBiZXNpZGVzIGNsaWVu
dCwgaW5jbHVkaW5nIFJlc291cmNlIE93bmVyLCBBdXRob3JpemF0aW9uIFNlcnZlcjsgDQppdHMg
IHJvbGUgaXMgdG8gZnVsZmlsbCByZXF1ZXN0cyBmcm9tIGNsaWVudHMsIHdoaWNoIHByZXNlbnQg
dmFyaW91cyANCmNyZWRlbnRpYWxzLCBhbmQgbWludCBhc3NlcnRpb25zIGFzIHJlcXVlc3RlZCwg
ZmlsbCB0aGVtIHdpdGggIGFwcHJvcHJpYXRlIA0KaW5mb3JtYXRpb24sIGFuZCBzaWduIHRoZW0u
IiANCg0KQW5kIG5vIG1vcmUgbm9ybWF0aXZlIHRleHRzIG5lZWQgdG8gYmUgY2hhbmdlZC4gDQoN
Cj4gDQo+IE9uIE1vbiwgRGVjIDE3LCAyMDEyIGF0IDU6MjkgUE0sICA8emhvdS5zdWppbmdAenRl
LmNvbS5jbj4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcg0LTT
2iAyMDEyLTEyLTE3IDIzOjIxOjM2Og0KPiA+DQo+ID4NCj4gPj4gSGkgYWxsLA0KPiA+Pg0KPiA+
PiBJIHJlYWQgdGhyb3VnaCB0aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24gcmFpc2VkIGJ5IE5h
dCBpbiB0aGlzDQo+ID4+IG1haWwgdG8gdGhlIGxpc3Qgb24gdGhlIDNyZCBvZiBEZWNlbWJlciwg
c2VlIGh0dHA6Ly93d3cuaWV0Zi4NCj4gPj4gb3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3Vy
cmVudC9tc2cxMDIwMy5odG1sDQo+ID4+DQo+ID4+IFRoZXJlIHdlcmUgdHdvIHR5cGVzIG9mIGlz
c3VlczoNCj4gPj4NCj4gPj4gMSkgVGhlIGN1cnJlbnQgdGV4dCBhYm91dCB0aGUgaXNzdWVyIChp
biBTZWN0aW9uIDUuMSBvZiA8ZHJhZnQtaWV0Zi0NCj4gPj4gb2F1dGgtYXNzZXJ0aW9ucy0wOC50
eHQ+IHNheXMgdGhhdCB0aGUgYXNzZXJ0aW9uIGNhbiBlaXRoZXIgYmUNCj4gPj4gY3JlYXRlZCBi
eSB0aGUgY2xpZW50IChpbiB3aGljaCBjYXNlIGl0IGlzIHNlbGYtc2lnbmVkKSBvciBpdCBjYW4g
YmUNCj4gPj4gY3JlYXRlZCBieSBzb21lIG90aGVyIGVudGl0eS4NCj4gPj4NCj4gPj4gVGhlcmUg
d2FzLCBob3dldmVyLCB0aGUgcGVyY2VwdGlvbiB0aGF0IHRoZSBjdXJyZW50IHRleHQsIGluIHRo
ZSB3YXkNCj4gPj4gaXQgaXMgd29yZGVkLCBjcmVhdGVzIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhp
cmQgcGFydHkgdG9rZW4gc2VydmljZXMNCj4gPj4gZXhjbHVkZXMgZW50aXRpZXMgbGlrZSB0aGUg
cmVzb3VyY2Ugb3duZXIuDQo+ID4+DQo+ID4+IDIpIFNvbWUgZm9sa3MgaGFkIHRoZSBpZGVhIHRo
YXQgdGhlIHJlc291cmNlIG93bmVyIGNvdWxkIGNyZWF0ZSB0aGUNCj4gPj4gYXNzZXJ0aW9uIGFu
ZCB0aGV5IGhhZCBhIHNwZWNpZmljIHVzZSBjYXNlIGluIG1pbmQuIFdoaWxlIHRoaXMgaXMNCj4g
Pj4gbm90IGEgY3VycmVudGx5IGRlcGxveWVkIHNjZW5hcmlvICh1c2luZyBPQXV0aCB0ZWNobm9s
b2d5KSB0aGVyZQ0KPiA+PiBzZWVtIHRvIGJlIHNvbWUgb3RoZXIgZGVwbG95bWVudCAodGhlIEF1
c3RyaWFuIGVJRCBjYXJkIGRlcGxveW1lbnQNCj4gPj4gd2FzIG1lbnRpb25lZCBieSBOYXQpIHRo
YXQgY291bGQgYmUgcmUtYnVpbGQgd2l0aCB0aGlzIHN1cHBvcnQgaW4gDQptaW5kLg0KPiA+Pg0K
PiA+PiBJdCBzZWVtZWQgdGhhdCBqdXN0IG1lbnRpb25pbmcgdGhhdCB0aGUgcmVzb3VyY2Ugb3du
ZXIgY291bGQgY3JlYXRlDQo+ID4+IHRoZSBhc3NlcnRpb24gd291bGRuJ3QgYmUgZW5vdWdoIHRv
IHVuZGVyc3RhbmQgdGhlIHNjZW5hcmlvLiBBIG1vcmUNCj4gPj4gZGV0YWlsZWQgd3JpdGV1cCBv
ZiB0aGUgZW52aXNpb25lZCBzY2VuYXJpbyB3b3VsZCBiZSBuZWVkZWQgYnV0IGhhcw0KPiA+PiBu
b3QgYmVlbiBwcm92aWRlZCB0byB0aGUgbWFpbGluZyBsaXN0Lg0KPiA+Pg0KPiA+PiBUbyBtZSBp
dCBzZWVtcyB0aGF0IHRoZSBiZXN0IGFwcHJvYWNoIHdvdWxkIGJlIHRvIGRvIHRoZSBmb2xsb3dp
bmc6DQo+ID4+DQo+ID4+IGEpIHRvIHVwZGF0ZSB0aGUgdGV4dCBpbiBTZWN0aW9uIDUuMSBhcyBz
dWdnZXN0ZWQgYnkgTmF0IGluIGhpcyBtYWlsDQo+ID4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFp
bC1hcmNoaXZlL3dlYi9vYXV0aC9jdXJyZW50L21zZzEwMjIyLmh0bWwNCj4gPg0KPiA+IE5hdCdz
IHN1Z2dlc3Rpb24gIkV4YW1wbGUgb2YgaXNzdWVycyBpbmNsdWRlIGFuIE9BdXRoIGNsaWVudCwg
cmVzb3VyY2UNCj4gPiBvd25lciwgYW4gaW5kZXBlbmRlbnQgdGhpcmQgcGFydHkuIg0KPiA+IHRo
ZXJlIGlzIHN0aWxsIGFuIGlzc3VlLCAgImluZGVucGVuZGVudCIgZnJvbSB3aG8/ICBJZiAgQVMg
YmUgYW4gDQphc3NlcnRpb24NCj4gPiBpc3N1ZXIsIGNvdWxkIEFTIGJlIGNhbGxlZCBpbmRlbnBl
bmRlbnQ/DQo+ID4NCj4gPg0KPiA+PiBUaGlzIGJ5IGl0c2VsZiB3b3VsZCBub3QgbGVhZCB0byBh
bnkgbm9ybWF0aXZlIHRleHQgY2hhbmdlIGJ1dCBtYXkNCj4gPj4gbWFrZSBpdCBjbGVhciB3aGF0
IHRoZSBpbnRlbnRpb24gd2FzLg0KPiA+Pg0KPiA+PiBiKSB0byBlbmNvdXJhZ2UgdGhvc2Ugd2hv
IGNhcmUgYWJvdXQgdGhlIHVzZSBjYXNlIHdoZXJlIHRoZSByZXNvdXJjZQ0KPiA+PiBvd25lciBj
cmVhdGVzIHRoZSBhc3NlcnRpb24gdG8gY29tcGlsZSBhIGRvY3VtZW50IGFuZCB0byBzdWJtaXQg
aXQNCj4gPj4gdG8gdGhlIGdyb3VwLiBUaGlzIHdvdWxkIGFsbG93IHVzIHRvIGV2YWx1YXRlIHdo
ZXRoZXIgYWxsIHRoZQ0KPiA+PiByZXF1aXJlZCBmdW5jdGlvbmFsaXR5IGlzIGluZGVlZCBhdmFp
bGFibGUuDQo+ID4+DQo+ID4+IENpYW8NCj4gPj4gSGFubmVzDQo+ID4+DQo+ID4+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IE9BdXRoIG1haWxp
bmcgbGlzdA0KPiA+PiBPQXV0aEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiA+IE9BdXRo
QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KPiA+DQoNCg==
--=_alternative 0003276F48257AF9_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5CcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdp
ZGVudGl0eS5jb20mZ3Q7DQrQtNPaIDIwMTItMTItMjAgMDQ6MjY6MDM6PGJyPg0KPGJyPg0KJmd0
OyBUaGV5IGFyZSBqdXN0IHNvbWUgZXhhbXBsZXMgYW5kIHNob3VsZG4ndCBsaW1pdCB3aG8gb3Ig
d2hhdCBjYW4gYmUNCnRoZSBpc3N1ZXIuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1heWJlIGp1c3Qg
cmVtb3ZpbmcgdGhhdCB3aG9sZSBzZW50ZW5jZSB0aGF0IHNheXMsICZxdW90O1RoZSBpc3N1ZXIN
Cm1heSBiZTxicj4NCiZndDsgZWl0aGVyIGFuIE9BdXRoIGNsaWVudCAod2hlbiBhc3NlcnRpb25z
IGFyZSBzZWxmLWlzc3VlZCkgb3IgYSB0aGlyZDxicj4NCiZndDsgcGFydHkgdG9rZW4gc2Vydmlj
ZS4nIHdvdWxkIGJlIGJldHRlciwgaWYgaXQncyBjYXVzaW5nIGNvbmZ1c2lvbj88YnI+DQpJdCBp
cyBjYXVzaW5nIGNvbmZ1c2lvbiB3aGVuIGVudGl0aWVzIGluIHRoZSBvYXV0aCBhcmNoaXRlY3R1
cmUgYXJlIGlzc3VlcnMuDQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPklmIHRo
ZSB3aG9sZSBzZW50ZW5jZSBpcyByZW1vdmVkLCBzaW1pbGFyIHNlbnRlbmNlcw0Kc3RpbGwgZXhp
c3QgaW4gdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGhzLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u
dCBzaXplPTI+Y29uZnVzaW9uIHN0aWxsIGV4aXN0cy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SG93IGFib3V0IGEgbW9kaWZpY2F0aW9uIGZv
ciBzZWN0aW9uDQozIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z
ZXJpZiI+Jm5ic3A7JnF1b3Q7VGhlIHRva2VuIHNlcnZpY2UgaXMgdGhlDQphc3NlcnRpb24gaXNz
dWVyOyBpdHMgJm5ic3A7cm9sZSBpcyB0byBmdWxmaWxsIHJlcXVlc3RzIGZyb20gY2xpZW50cywg
d2hpY2gNCnByZXNlbnQgdmFyaW91cyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh
bnMtc2VyaWYiPiZuYnNwO2NyZWRlbnRpYWxzLCBhbmQgbWludCBhc3NlcnRpb25zDQphcyByZXF1
ZXN0ZWQsIGZpbGwgdGhlbSB3aXRoICZuYnNwO2FwcHJvcHJpYXRlIGluZm9ybWF0aW9uLCBhbmQg
c2lnbiB0aGVtLiZxdW90Ow0KJm5ic3A7KGluICZuYnNwO3NlY3Rpb24gMyApPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pbnRvIDwvZm9udD4NCjxicj48Zm9udCBz
aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7JnF1b3Q7VGhlIHRva2VuIHNlcnZpY2UgaXMg
dGhlDQphc3NlcnRpb24gaXNzdWVyLCA8Yj5pdCBjb3VsZCBiZSBpbXBsZW1lbnRlZCBpbiBhbnkg
ZW50aXR5IGJlc2lkZXMgY2xpZW50LA0KaW5jbHVkaW5nIFJlc291cmNlIE93bmVyLCBBdXRob3Jp
emF0aW9uIFNlcnZlcjs8L2I+IGl0cyAmbmJzcDtyb2xlIGlzIHRvDQpmdWxmaWxsIHJlcXVlc3Rz
IGZyb20gY2xpZW50cywgPHN0cmlrZT53aGljaCBwcmVzZW50IHZhcmlvdXMgJm5ic3A7Y3JlZGVu
dGlhbHM8L3N0cmlrZT4sDQphbmQgbWludCBhc3NlcnRpb25zIGFzIHJlcXVlc3RlZCwgZmlsbCB0
aGVtIHdpdGggJm5ic3A7YXBwcm9wcmlhdGUgaW5mb3JtYXRpb24sDQphbmQgc2lnbiB0aGVtLiZx
dW90OyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5BbmQgbm8gbW9yZSBub3Jt
YXRpdmUgdGV4dHMgbmVlZCB0byBiZSBjaGFuZ2VkLiA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48
dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBPbiBNb24sIERlYyAxNywgMjAxMiBhdCA1
OjI5IFBNLCAmbmJzcDsmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDsNCndyb3RlOjxicj4N
CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBvYXV0aC1ib3VuY2VzQGll
dGYub3JnINC009ogMjAxMi0xMi0xNyAyMzoyMTozNjo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7
ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0K
Jmd0OyAmZ3Q7Jmd0OyBJIHJlYWQgdGhyb3VnaCB0aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24g
cmFpc2VkIGJ5IE5hdA0KaW4gdGhpczxicj4NCiZndDsgJmd0OyZndDsgbWFpbCB0byB0aGUgbGlz
dCBvbiB0aGUgM3JkIG9mIERlY2VtYmVyLCBzZWUgaHR0cDovL3d3dy5pZXRmLjxicj4NCiZndDsg
Jmd0OyZndDsgb3JnL21haWwtYXJjaGl2ZS93ZWIvb2F1dGgvY3VycmVudC9tc2cxMDIwMy5odG1s
PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGhlcmUgd2VyZSB0d28gdHlw
ZXMgb2YgaXNzdWVzOjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IDEpIFRo
ZSBjdXJyZW50IHRleHQgYWJvdXQgdGhlIGlzc3VlciAoaW4gU2VjdGlvbiA1LjEgb2YgJmx0O2Ry
YWZ0LWlldGYtPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBvYXV0aC1hc3NlcnRpb25zLTA4LnR4dCZndDsg
c2F5cyB0aGF0IHRoZSBhc3NlcnRpb24gY2FuIGVpdGhlcg0KYmU8YnI+DQomZ3Q7ICZndDsmZ3Q7
IGNyZWF0ZWQgYnkgdGhlIGNsaWVudCAoaW4gd2hpY2ggY2FzZSBpdCBpcyBzZWxmLXNpZ25lZCkg
b3INCml0IGNhbiBiZTxicj4NCiZndDsgJmd0OyZndDsgY3JlYXRlZCBieSBzb21lIG90aGVyIGVu
dGl0eS48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGVyZSB3YXMsIGhv
d2V2ZXIsIHRoZSBwZXJjZXB0aW9uIHRoYXQgdGhlIGN1cnJlbnQgdGV4dCwNCmluIHRoZSB3YXk8
YnI+DQomZ3Q7ICZndDsmZ3Q7IGl0IGlzIHdvcmRlZCwgY3JlYXRlcyB0aGUgaW1wcmVzc2lvbiB0
aGF0IHRoaXJkIHBhcnR5IHRva2VuDQpzZXJ2aWNlczxicj4NCiZndDsgJmd0OyZndDsgZXhjbHVk
ZXMgZW50aXRpZXMgbGlrZSB0aGUgcmVzb3VyY2Ugb3duZXIuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxi
cj4NCiZndDsgJmd0OyZndDsgMikgU29tZSBmb2xrcyBoYWQgdGhlIGlkZWEgdGhhdCB0aGUgcmVz
b3VyY2Ugb3duZXIgY291bGQNCmNyZWF0ZSB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGFzc2VydGlv
biBhbmQgdGhleSBoYWQgYSBzcGVjaWZpYyB1c2UgY2FzZSBpbiBtaW5kLiBXaGlsZQ0KdGhpcyBp
czxicj4NCiZndDsgJmd0OyZndDsgbm90IGEgY3VycmVudGx5IGRlcGxveWVkIHNjZW5hcmlvICh1
c2luZyBPQXV0aCB0ZWNobm9sb2d5KQ0KdGhlcmU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNlZW0gdG8g
YmUgc29tZSBvdGhlciBkZXBsb3ltZW50ICh0aGUgQXVzdHJpYW4gZUlEIGNhcmQgZGVwbG95bWVu
dDxicj4NCiZndDsgJmd0OyZndDsgd2FzIG1lbnRpb25lZCBieSBOYXQpIHRoYXQgY291bGQgYmUg
cmUtYnVpbGQgd2l0aCB0aGlzIHN1cHBvcnQNCmluIG1pbmQuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxi
cj4NCiZndDsgJmd0OyZndDsgSXQgc2VlbWVkIHRoYXQganVzdCBtZW50aW9uaW5nIHRoYXQgdGhl
IHJlc291cmNlIG93bmVyIGNvdWxkDQpjcmVhdGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoZSBhc3Nl
cnRpb24gd291bGRuJ3QgYmUgZW5vdWdoIHRvIHVuZGVyc3RhbmQgdGhlIHNjZW5hcmlvLg0KQSBt
b3JlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBkZXRhaWxlZCB3cml0ZXVwIG9mIHRoZSBlbnZpc2lvbmVk
IHNjZW5hcmlvIHdvdWxkIGJlIG5lZWRlZA0KYnV0IGhhczxicj4NCiZndDsgJmd0OyZndDsgbm90
IGJlZW4gcHJvdmlkZWQgdG8gdGhlIG1haWxpbmcgbGlzdC48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJy
Pg0KJmd0OyAmZ3Q7Jmd0OyBUbyBtZSBpdCBzZWVtcyB0aGF0IHRoZSBiZXN0IGFwcHJvYWNoIHdv
dWxkIGJlIHRvIGRvIHRoZQ0KZm9sbG93aW5nOjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7
ICZndDsmZ3Q7IGEpIHRvIHVwZGF0ZSB0aGUgdGV4dCBpbiBTZWN0aW9uIDUuMSBhcyBzdWdnZXN0
ZWQgYnkgTmF0DQppbiBoaXMgbWFpbDxicj4NCiZndDsgJmd0OyZndDsgaHR0cDovL3d3dy5pZXRm
Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL29hdXRoL2N1cnJlbnQvbXNnMTAyMjIuaHRtbDxicj4NCiZn
dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBOYXQncyBzdWdnZXN0aW9uICZxdW90O0V4YW1wbGUgb2Yg
aXNzdWVycyBpbmNsdWRlIGFuIE9BdXRoIGNsaWVudCwNCnJlc291cmNlPGJyPg0KJmd0OyAmZ3Q7
IG93bmVyLCBhbiBpbmRlcGVuZGVudCB0aGlyZCBwYXJ0eS4mcXVvdDs8YnI+DQomZ3Q7ICZndDsg
dGhlcmUgaXMgc3RpbGwgYW4gaXNzdWUsICZuYnNwOyZxdW90O2luZGVucGVuZGVudCZxdW90OyBm
cm9tDQp3aG8/ICZuYnNwO0lmICZuYnNwO0FTIGJlIGFuIGFzc2VydGlvbjxicj4NCiZndDsgJmd0
OyBpc3N1ZXIsIGNvdWxkIEFTIGJlIGNhbGxlZCBpbmRlbnBlbmRlbnQ/PGJyPg0KJmd0OyAmZ3Q7
PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGJ5IGl0c2VsZiB3b3VsZCBu
b3QgbGVhZCB0byBhbnkgbm9ybWF0aXZlIHRleHQgY2hhbmdlDQpidXQgbWF5PGJyPg0KJmd0OyAm
Z3Q7Jmd0OyBtYWtlIGl0IGNsZWFyIHdoYXQgdGhlIGludGVudGlvbiB3YXMuPGJyPg0KJmd0OyAm
Z3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgYikgdG8gZW5jb3VyYWdlIHRob3NlIHdobyBjYXJl
IGFib3V0IHRoZSB1c2UgY2FzZSB3aGVyZSB0aGUNCnJlc291cmNlPGJyPg0KJmd0OyAmZ3Q7Jmd0
OyBvd25lciBjcmVhdGVzIHRoZSBhc3NlcnRpb24gdG8gY29tcGlsZSBhIGRvY3VtZW50IGFuZCB0
bw0Kc3VibWl0IGl0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0byB0aGUgZ3JvdXAuIFRoaXMgd291bGQg
YWxsb3cgdXMgdG8gZXZhbHVhdGUgd2hldGhlciBhbGwNCnRoZTxicj4NCiZndDsgJmd0OyZndDsg
cmVxdWlyZWQgZnVuY3Rpb25hbGl0eSBpcyBpbmRlZWQgYXZhaWxhYmxlLjxicj4NCiZndDsgJmd0
OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IENpYW88YnI+DQomZ3Q7ICZndDsmZ3Q7IEhhbm5lczxi
cj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBPQXV0aCBtYWls
aW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IE9BdXRoQGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7
Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0
OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsg
Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL29hdXRoPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KPC9mb250PjwvdHQ+DQo=
--=_alternative 0003276F48257AF9_=--

From tonynad@microsoft.com  Wed Dec 19 16:42:14 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771BD21F8A43 for ; Wed, 19 Dec 2012 16:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.491
X-Spam-Level: 
X-Spam-Status: No, score=-0.491 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpH1N6oKftyu for ; Wed, 19 Dec 2012 16:42:12 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7B121F8A41 for ; Wed, 19 Dec 2012 16:42:12 -0800 (PST)
Received: from BY2FFO11FD007.protection.gbl (10.1.15.200) by BY2FFO11HUB005.protection.gbl (10.1.14.163) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 00:42:09 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 00:42:09 +0000
Received: from CH1EHSOBE020.bigfish.com (157.54.51.113) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 20 Dec 2012 00:41:51 +0000
Received: from mail201-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Dec 2012 00:40:55 +0000
Received: from mail201-ch1 (localhost [127.0.0.1])	by mail201-ch1-R.bigfish.com (Postfix) with ESMTP id A84AD180253	for ; Thu, 20 Dec 2012 00:40:55 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -16
X-BigFish: PS-16(zz9371Id6eahc85fhzz1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL18c673h17326ah8275bh8275dhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail201-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB041; LANG:en; 
Received: from mail201-ch1 (localhost.localdomain [127.0.0.1]) by mail201-ch1 (MessageSwitch) id 135596405349883_16337; Thu, 20 Dec 2012 00:40:53 +0000 (UTC)
Received: from CH1EHSMHS018.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237])	by mail201-ch1.bigfish.com (Postfix) with ESMTP id 095733A0081;	Thu, 20 Dec 2012 00:40:53 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Dec 2012 00:40:52 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 20 Dec 2012 00:40:52 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 00:40:50 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Thu, 20 Dec 2012 00:40:50 +0000
From: Anthony Nadalin 
To: Nat Sakimura , oauth 
Thread-Topic: [OAUTH-WG] "cid" claim in JWT
Thread-Index: AQHN3Y+xzxEKczxlYkWEdMy9QtTiVJgg2diA
Date: Thu, 20 Dec 2012 00:40:50 +0000
Message-ID: <31476ed163f348a1a1a80e57ee75c1ce@BY2PR03MB041.namprd03.prod.outlook.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.156.132]
Content-Type: multipart/alternative; boundary="_000_31476ed163f348a1a1a80e57ee75c1ceBY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(44976002)(4396001)(15202345001)(74662001)(16676001)(46102001)(50986001)(56776001)(47976001)(56816002)(6806001)(49866001)(74502001)(47736001)(512954001)(5343655001)(51856001)(16236675001)(5343635001)(33646001)(550184003)(76482001)(54316002)(54356001)(53806001)(59766001)(31966008)(47446002)(77982001)(42262001)(24736002)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB005; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07013D7479
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 00:42:14 -0000

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

It seems premature and we should consider this in the bigger context of the=
 "on behalf of"/delegation work that has been started

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of N=
at Sakimura
Sent: Tuesday, December 18, 2012 6:22 PM
To: oauth
Subject: [OAUTH-WG] "cid" claim in JWT

In OpenID Connect WG, we have been talking this for sometime.
"cid" claim identifies the entity that the JWT was issued to as a rightful/=
licensed user.
Google already uses this in their implementation of id_token of OIDC.

Here is the text proposal. It introduces two new standard claims: "cid" and=
 "cit".


It would be very useful in creating a HoK drafts as well.



Cheers,



Nat





4.1.9. "cid" Client Identification Data Claim



The "cid" (client identification data) claim allows the receiver

of the JWT to identify the entity that the JWT is

intended to be used by. The audience of the JWT MUST be

able to identify the client with the value of this claim.



The "cid" value is a case sensitive string containing a StringOrURI value.

This claim is OPTIONAL. If the entity processing the claim does not

identify the user of the JWT with the identifier in the "cid" claim value,

then the JWT MUST be rejected. The interpretation of the registered to

value is generally application specific.



A typical example of a registered to claim includes following:

* client_id that the audience can use to authenticate and

  identify the client.

* A base64url encoded JWK.

* A URL that points to the key material that the audience can use to

  authenticate the user of the JWT.



4.1.10 "cit" (Client Identification Data claim type)



The "cit" (Client Identification Data claim type) identifies the type

of the "cid" claim. It is a StringOrURI value. The defined values

are the following:



"client_id" The value of the "cid" claim is the Client ID of the client

that the audience of the JWT is able to use to authenticate the client.



"jwk" The value of the "cid" claim is a base64url encoded JWK of

the registered client.



"jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of

JSON web signature [JWS].



"x5u" The value of the "cid" claim is the URL that points to the public

key certificate of the registered client. The format of the content

that x5u points to is described in section 4.1.4 of the JSON Web Signature.

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


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











It seems premature and we=
 should consider this in the bigger context of the “on behalf of̶=
1;/delegation work that has been started


 


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

Sent: Tuesday, December 18, 2012 6:22 PM

To: oauth

Subject: [OAUTH-WG] "cid" claim in JWT

 


In OpenID Connect WG, we have been talking this for =
sometime. 




"cid" claim identifies the entity that the=
 JWT was issued to as a rightful/licensed user. 






Google already uses this in their implementation of =
id_token of OIDC. 






 






Here is the text proposal. It introduces two new sta=
ndard claims: "cid" and "cit". 






 







It would be very useful in creating a HoK drafts a=
s well. 



 



Cheers, 



 



Nat



 






 


4.1.9. "cid<=
/span>" Client Identificati=
on Data Claim

 


The "cid" (client identification data) claim allows the receiver 


of the JWT to ide=
ntify the entity <=
span class=3D"n">that the JWT is 


intended to be used by. The audience of th=
e JWT MUST be 


able to identify the client with the value of this claim.


 


The "cid" value is a case sensitive string <=
span class=3D"n">containing a StringOrURI value.=



This claim=
 is OPTIONAL. If the entity processing the claim does not 


identify the user of the JWT with <=
span class=3D"n">the identifier in the "cid" claim value, 


then the <=
span class=3D"n">JWT MUST be rejected. The interpretation of the registered=
 to 


value<=
span style=3D"font-size:9.0pt;color:#333333"> is <=
span class=3D"n">generally application specific.

 


A typical =
example of a registered to claim includes following: 

* client_id that the audience can use to authenticate and 


  identify=
 the client.


* A base64url encoded JWK. 


* A URL that poin=
ts to the key material th=
at the audience can use t=
o 


  authenti=
cate the user of the JWT<=
/span>.


 


4.1.10 "cit" (Client Identifica=
tion Data claim type)


 


The "cit" (Client Identification Data claim type)=
 identifies the type 


of the &qu=
ot;cid" claim. It is=
 a StringOrURI value. The=
 defined values 


are the following:


 


"client_id" The value of the "=
cid" claim is=
 the Client ID of the <=
span class=3D"n">client 


that the <=
span class=3D"n">audience of the JWT is able to us=
e to authenticate =
the client.


 


"jwk&quo=
t; The value of the "cid" claim is a base64url encoded JWK of 


the registered client.


 


"jku&quo=
t; The value of the "cid" claim is the "jku" defined in 4.1.2 of 


JSON web <=
span class=3D"n">signature [JWS].


 


"x5u&quo=
t; The value of the "cid" claim is the URL tha=
t points to the public 

key certificate of the registered client.=
 The format of the conten=
t 


that x5u <=
span class=3D"n">points to is described in =
section 4.1.4 of the JSON Web Si=
gnature.












 




-- 

Nat Sakimura (=3Dnat)




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en




 








--_000_31476ed163f348a1a1a80e57ee75c1ceBY2PR03MB041namprd03pro_--

From ve7jtb@ve7jtb.com  Wed Dec 19 18:25:37 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E5321F89E8 for ; Wed, 19 Dec 2012 18:25:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.327
X-Spam-Level: 
X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7F9hRjei1+z1 for ; Wed, 19 Dec 2012 18:25:36 -0800 (PST)
Received: from mail-yh0-f46.google.com (mail-yh0-f46.google.com [209.85.213.46]) by ietfa.amsl.com (Postfix) with ESMTP id DC79221F87D2 for ; Wed, 19 Dec 2012 18:25:26 -0800 (PST)
Received: by mail-yh0-f46.google.com with SMTP id m54so672895yhm.33 for ; Wed, 19 Dec 2012 18:25:26 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=f8GFi13U+NN/OZq8fGDMlQDqmaKfju22AwTgEipTxBI=; b=L+zQ3L8RV4ZU6GId6pWubblfXiIUOLjMBnl5kwgQmflT2Vss5y3IC3MJlckW1uwRGJ eQ+EFoiZuCXt8utTJW8U5MRTSChBd6+SrAQA0/219ur5/2ardf9YBYMLppXm4c9E1rOW 7uw8qWXznLKaIyxST1lpkYyT4CXqijDsA0AZyQHNHZkgrahqTj2Z9lNTUZJxWiZ1vJ6N XD4wLdt5NzyxVsDi/Xro2XBBB2izBQhspDgfd4XhNDhz3Fc/8hS0C90j+SInfOvr42kr Svz/0fYI0g7DZiImndUjC5dNW57bh39o95T7seq1vVY7rTZCCc8wxWP5nuD1rZOqNY9K OyeA==
X-Received: by 10.236.128.77 with SMTP id e53mr7609484yhi.127.1355970326216; Wed, 19 Dec 2012 18:25:26 -0800 (PST)
Received: from [192.168.1.211] (190-20-21-85.baf.movistar.cl. [190.20.21.85]) by mx.google.com with ESMTPS id d66sm6412043yhe.1.2012.12.19.18.25.21 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 19 Dec 2012 18:25:25 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_99B27F65-04E7-448E-84ED-A4289F501757"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <31476ed163f348a1a1a80e57ee75c1ce@BY2PR03MB041.namprd03.prod.outlook.com>
Date: Wed, 19 Dec 2012 23:25:15 -0300
Message-Id: <7C676625-BB10-485E-80C8-2205CCDF38E2@ve7jtb.com>
References:  <31476ed163f348a1a1a80e57ee75c1ce@BY2PR03MB041.namprd03.prod.outlook.com>
To: Anthony Nadalin 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQlSrPzyIMIFIpTPKzA4boNF08skNWOD2n4RWy1mlGgYU9oVjxy5nzX/yORFfzGMsLaGjpmA
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 02:25:37 -0000

--Apple-Mail=_99B27F65-04E7-448E-84ED-A4289F501757
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I agree, audience who requested it and and who it is requested for are =
all interrelated.

However we do need to set down some standard way of expressing it as =
people are starting to make stuff up on their own that will impact =
interoperability.

If Google starts thawing in cid and clients don't know about it they =
must reject the JWT etc.

John

On 2012-12-19, at 9:40 PM, Anthony Nadalin  =
wrote:

> It seems premature and we should consider this in the bigger context =
of the =93on behalf of=94/delegation work that has been started
> =20
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of Nat Sakimura
> Sent: Tuesday, December 18, 2012 6:22 PM
> To: oauth
> Subject: [OAUTH-WG] "cid" claim in JWT
> =20
> In OpenID Connect WG, we have been talking this for sometime.=20
> "cid" claim identifies the entity that the JWT was issued to as a =
rightful/licensed user.=20
> Google already uses this in their implementation of id_token of OIDC.=20=

> =20
> Here is the text proposal. It introduces two new standard claims: =
"cid" and "cit".=20
> =20
> It would be very useful in creating a HoK drafts as well.=20
> =20
> Cheers,=20
> =20
> Nat
> =20
> =20
> 4.1.9. "cid" Client Identification Data Claim
> =20
> The "cid" (client identification data) claim allows the receiver=20
> of the JWT to identify the entity that the JWT is=20
> intended to be used by. The audience of the JWT MUST be=20
> able to identify the client with the value of this claim.
> =20
> The "cid" value is a case sensitive string containing a StringOrURI =
value.
> This claim is OPTIONAL. If the entity processing the claim does not=20
> identify the user of the JWT with the identifier in the "cid" claim =
value,=20
> then the JWT MUST be rejected. The interpretation of the registered to=20=

> value is generally application specific.
> =20
> A typical example of a registered to claim includes following:=20
> * client_id that the audience can use to authenticate and=20
>   identify the client.
> * A base64url encoded JWK.=20
> * A URL that points to the key material that the audience can use to=20=

>   authenticate the user of the JWT.
> =20
> 4.1.10 "cit" (Client Identification Data claim type)
> =20
> The "cit" (Client Identification Data claim type) identifies the type=20=

> of the "cid" claim. It is a StringOrURI value. The defined values=20
> are the following:
> =20
> "client_id" The value of the "cid" claim is the Client ID of the =
client=20
> that the audience of the JWT is able to use to authenticate the =
client.
> =20
> "jwk" The value of the "cid" claim is a base64url encoded JWK of=20
> the registered client.
> =20
> "jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of=20
> JSON web signature [JWS].
> =20
> "x5u" The value of the "cid" claim is the URL that points to the =
public=20
> key certificate of the registered client. The format of the content=20
> that x5u points to is described in section 4.1.4 of the JSON Web =
Signature.
> =20
> --=20
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_99B27F65-04E7-448E-84ED-A4289F501757
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I agree, audience who requested =
it and and who it is requested for are all =
interrelated.

However we do need to set down some =
standard way of expressing it as people are starting to make stuff up on =
their own that will impact interoperability.

If =
Google starts thawing in cid and clients don't know about it they must =
reject the JWT =
etc.

John

On =
2012-12-19, at 9:40 PM, Anthony Nadalin <tonynad@microsoft.com> =
wrote:

It seems premature and =
we should consider this in the bigger context of the =93on behalf =
of=94/delegation work that has been started
 oauth-bounces@ietf.org =
[mailto:oauth-bounces@ietf.org] On Behalf Of Nat =
Sakimura
Sent: Tuesday, December 18, 2012 =
6:22 PM
To: oauth
Subject: [OAUTH-WG] "cid" claim in =
JWT
In OpenID =
Connect WG, we have been talking this for =
sometime. 
Google already uses this in their implementation of =
id_token of OIDC. 
 
Here =
is the text proposal. It introduces two new standard claims: "cid" and =
"cit". 
It would be very useful in creating a HoK =
drafts as well. 
 
Cheers, 
 
 
4.1.9. "cid" Client Identification Data Claim
 "cid" (client identification data) claim allows the receiver =

of the JWT to identify the entity that the JWT is =

 to be =
used by. The audience of the JWT MUST be =

 to identify =
the client with the value of this claim.
 "cid" value =
is a  sensitive string=
 containing a StringOrURI value.
This claim is OPTIONAL. If the entity processing the claim does not 
identify the user of the JWT with the identifier in the "cid" claim value, 
then the JWT MUST be rejected. The interpretation of the registered to 
value is generally application specific.
A typical example of a registered to claim includes following: =

* client_id that the audience can use to authenticate and 
identify the client.
* A base64url encoded JWK. =

* A URL that points to the key material that the audience can use to =

  authenticate the user of the JWT.
4.1.10 "cit" (Client Identification Data claim type)
 "cit" (Client Identification Data claim type) identifies the type 
of the "cid" claim. It is a StringOrURI value. The defined values =

 the following:
"client_id" The value of the "cid" claim is the Client ID of the client 
that the audience of the JWT is able to use to authenticate the client.
"jwk" The value of the "cid" claim is a base64url encoded JWK of =

 registered client.
"jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of =

 web signature =
[JWS].
"x5u" The value of the "cid" claim is the URL that points to the public =

 certificate of =
the registered client. The format of the content 
that x5u points to is described in section 4.1.4 of the JSON Web Signature.
 
-- 
Nat Sakimura =
(=3Dnat)
Chairman, =
OpenID Foundation
OAuth@ietf.org
https://www.ietf.org/=
mailman/listinfo/oauth

=

--Apple-Mail=_99B27F65-04E7-448E-84ED-A4289F501757--

From Michael.Jones@microsoft.com  Wed Dec 19 19:07:37 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0688B21F89B6 for ; Wed, 19 Dec 2012 19:07:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Level: 
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3PJa4RAN6dt for ; Wed, 19 Dec 2012 19:07:35 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF621F8991 for ; Wed, 19 Dec 2012 19:07:35 -0800 (PST)
Received: from CH1PR03CA011.namprd03.prod.outlook.com (10.255.156.156) by CH1PR03MB599.namprd03.prod.outlook.com (10.255.156.164) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 03:07:33 +0000
Received: from BY2FFO11FD015.protection.gbl (207.46.100.26) by CH1PR03CA011.outlook.com (10.255.156.156) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 03:07:32 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 03:07:32 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 03:07:09 +0000
From: Mike Jones 
To: Anthony Nadalin , John Bradley 
Thread-Topic: [OAUTH-WG] "cid" claim in JWT
Thread-Index: Ac3eXxe1nms0qid0tk+0K29GGMlTVQ==
Date: Thu, 20 Dec 2012 03:07:07 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436697B66F@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436697B66FTK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(24454001)(512874001)(74662001)(55846006)(47446002)(44976002)(74502001)(15202345001)(31966008)(54316002)(33656001)(56776001)(56816002)(47976001)(54356001)(47736001)(4396001)(16406001)(16236675001)(76482001)(50986001)(46102001)(51856001)(77982001)(59766001)(5343655001)(49866001)(550184003)(5343635001)(53806001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:CH1PR03MB599; LANG:en; 
X-OriginatorOrg: testtestdelta.onmicrosoft.com
X-Forefront-PRVS: 07013D7479
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 03:07:37 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436697B66FTK5EX14MBXC283r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSdtIHdpdGggVG9ueSBvbiB0aGlzLiAgVGhpcyBzZWVtcyBwcmVtYXR1cmUgdG8gcHV0IGludG8g
dGhlIEpXVCBzdGFuZGFyZC4gIEFsbCB0aGUgb3RoZXIgSldUIGNsYWltcyBoYXZlIHdlbGwgZXN0
YWJsaXNoZWQgbWVhbmluZ3MgYW5kIGhpc3RvcnkgYmVoaW5kIHRoZW0uICBUaGVzZSBkb24ndC4N
Cg0KSWYgdGhlIGdvYWwgaXMgdG8gYWxsb3cgT3BlbklEIENvbm5lY3QgaW1wbGVtZW50YXRpb25z
IHRvIG5vdCByZWplY3QgdG9rZW5zIHVzaW5nIOKAnGNpZOKAnSwgdGhlcmUgYXJlIGxvdHMgb2Yg
b3RoZXIgd2F5cyB0byBhY2NvbXBsaXNoIHRoaXMgdGhhdCBJIHRoaW5rIHdlIHNob3VsZCBjb25z
aWRlciBmaXJzdC4NCg0KLS0gTWlrZQ0KDQoNCkZyb206IEpvaG4gQnJhZGxleQ0KU2VudDog4oCO
RGVjZW1iZXLigI4g4oCOMTnigI4sIOKAjjIwMTIg4oCONuKAjjrigI4yNeKAjiDigI5QTQ0KVG86
IEFudGhvbnkgTmFkYWxpbg0KQ0M6IG9hdXRoDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSAiY2lk
IiBjbGFpbSBpbiBKV1QNCg0KSSBhZ3JlZSwgYXVkaWVuY2Ugd2hvIHJlcXVlc3RlZCBpdCBhbmQg
YW5kIHdobyBpdCBpcyByZXF1ZXN0ZWQgZm9yIGFyZSBhbGwgaW50ZXJyZWxhdGVkLg0KDQpIb3dl
dmVyIHdlIGRvIG5lZWQgdG8gc2V0IGRvd24gc29tZSBzdGFuZGFyZCB3YXkgb2YgZXhwcmVzc2lu
ZyBpdCBhcyBwZW9wbGUgYXJlIHN0YXJ0aW5nIHRvIG1ha2Ugc3R1ZmYgdXAgb24gdGhlaXIgb3du
IHRoYXQgd2lsbCBpbXBhY3QgaW50ZXJvcGVyYWJpbGl0eS4NCg0KSWYgR29vZ2xlIHN0YXJ0cyB0
aGF3aW5nIGluIGNpZCBhbmQgY2xpZW50cyBkb24ndCBrbm93IGFib3V0IGl0IHRoZXkgbXVzdCBy
ZWplY3QgdGhlIEpXVCBldGMuDQoNCkpvaG4NCg0KT24gMjAxMi0xMi0xOSwgYXQgOTo0MCBQTSwg
QW50aG9ueSBOYWRhbGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWlj
cm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQpJdCBzZWVtcyBwcmVtYXR1cmUgYW5kIHdlIHNob3VsZCBj
b25zaWRlciB0aGlzIGluIHRoZSBiaWdnZXIgY29udGV4dCBvZiB0aGUg4oCcb24gYmVoYWxmIG9m
4oCdL2RlbGVnYXRpb24gd29yayB0aGF0IGhhcyBiZWVuIHN0YXJ0ZWQNCg0KRnJvbTogb2F1dGgt
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpv
YXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxm
IE9mIE5hdCBTYWtpbXVyYQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTgsIDIwMTIgNjoyMiBQ
TQ0KVG86IG9hdXRoDQpTdWJqZWN0OiBbT0FVVEgtV0ddICJjaWQiIGNsYWltIGluIEpXVA0KDQpJ
biBPcGVuSUQgQ29ubmVjdCBXRywgd2UgaGF2ZSBiZWVuIHRhbGtpbmcgdGhpcyBmb3Igc29tZXRp
bWUuDQoiY2lkIiBjbGFpbSBpZGVudGlmaWVzIHRoZSBlbnRpdHkgdGhhdCB0aGUgSldUIHdhcyBp
c3N1ZWQgdG8gYXMgYSByaWdodGZ1bC9saWNlbnNlZCB1c2VyLg0KR29vZ2xlIGFscmVhZHkgdXNl
cyB0aGlzIGluIHRoZWlyIGltcGxlbWVudGF0aW9uIG9mIGlkX3Rva2VuIG9mIE9JREMuDQoNCkhl
cmUgaXMgdGhlIHRleHQgcHJvcG9zYWwuIEl0IGludHJvZHVjZXMgdHdvIG5ldyBzdGFuZGFyZCBj
bGFpbXM6ICJjaWQiIGFuZCAiY2l0Ii4NCg0KSXQgd291bGQgYmUgdmVyeSB1c2VmdWwgaW4gY3Jl
YXRpbmcgYSBIb0sgZHJhZnRzIGFzIHdlbGwuDQoNCkNoZWVycywNCg0KTmF0DQoNCg0KDQoNCjQu
MS45LiAiY2lkIiBDbGllbnQgSWRlbnRpZmljYXRpb24gRGF0YSBDbGFpbQ0KDQoNCg0KVGhlICJj
aWQiIChjbGllbnQgaWRlbnRpZmljYXRpb24gZGF0YSkgY2xhaW0gYWxsb3dzIHRoZSByZWNlaXZl
cg0KDQpvZiB0aGUgSldUIHRvIGlkZW50aWZ5IHRoZSBlbnRpdHkgdGhhdCB0aGUgSldUIGlzDQoN
CmludGVuZGVkIHRvIGJlIHVzZWQgYnkuIFRoZSBhdWRpZW5jZSBvZiB0aGUgSldUIE1VU1QgYmUN
Cg0KYWJsZSB0byBpZGVudGlmeSB0aGUgY2xpZW50IHdpdGggdGhlIHZhbHVlIG9mIHRoaXMgY2xh
aW0uDQoNCg0KDQpUaGUgImNpZCIgdmFsdWUgaXMgYSBjYXNlIHNlbnNpdGl2ZSBzdHJpbmcgY29u
dGFpbmluZyBhIFN0cmluZ09yVVJJIHZhbHVlLg0KDQpUaGlzIGNsYWltIGlzIE9QVElPTkFMLiBJ
ZiB0aGUgZW50aXR5IHByb2Nlc3NpbmcgdGhlIGNsYWltIGRvZXMgbm90DQoNCmlkZW50aWZ5IHRo
ZSB1c2VyIG9mIHRoZSBKV1Qgd2l0aCB0aGUgaWRlbnRpZmllciBpbiB0aGUgImNpZCIgY2xhaW0g
dmFsdWUsDQoNCnRoZW4gdGhlIEpXVCBNVVNUIGJlIHJlamVjdGVkLiBUaGUgaW50ZXJwcmV0YXRp
b24gb2YgdGhlIHJlZ2lzdGVyZWQgdG8NCg0KdmFsdWUgaXMgZ2VuZXJhbGx5IGFwcGxpY2F0aW9u
IHNwZWNpZmljLg0KDQoNCg0KQSB0eXBpY2FsIGV4YW1wbGUgb2YgYSByZWdpc3RlcmVkIHRvIGNs
YWltIGluY2x1ZGVzIGZvbGxvd2luZzoNCg0KKiBjbGllbnRfaWQgdGhhdCB0aGUgYXVkaWVuY2Ug
Y2FuIHVzZSB0byBhdXRoZW50aWNhdGUgYW5kDQoNCiAgaWRlbnRpZnkgdGhlIGNsaWVudC4NCg0K
KiBBIGJhc2U2NHVybCBlbmNvZGVkIEpXSy4NCg0KKiBBIFVSTCB0aGF0IHBvaW50cyB0byB0aGUg
a2V5IG1hdGVyaWFsIHRoYXQgdGhlIGF1ZGllbmNlIGNhbiB1c2UgdG8NCg0KICBhdXRoZW50aWNh
dGUgdGhlIHVzZXIgb2YgdGhlIEpXVC4NCg0KDQoNCjQuMS4xMCAiY2l0IiAoQ2xpZW50IElkZW50
aWZpY2F0aW9uIERhdGEgY2xhaW0gdHlwZSkNCg0KDQoNClRoZSAiY2l0IiAoQ2xpZW50IElkZW50
aWZpY2F0aW9uIERhdGEgY2xhaW0gdHlwZSkgaWRlbnRpZmllcyB0aGUgdHlwZQ0KDQpvZiB0aGUg
ImNpZCIgY2xhaW0uIEl0IGlzIGEgU3RyaW5nT3JVUkkgdmFsdWUuIFRoZSBkZWZpbmVkIHZhbHVl
cw0KDQphcmUgdGhlIGZvbGxvd2luZzoNCg0KDQoNCiJjbGllbnRfaWQiIFRoZSB2YWx1ZSBvZiB0
aGUgImNpZCIgY2xhaW0gaXMgdGhlIENsaWVudCBJRCBvZiB0aGUgY2xpZW50DQoNCnRoYXQgdGhl
IGF1ZGllbmNlIG9mIHRoZSBKV1QgaXMgYWJsZSB0byB1c2UgdG8gYXV0aGVudGljYXRlIHRoZSBj
bGllbnQuDQoNCg0KDQoiandrIiBUaGUgdmFsdWUgb2YgdGhlICJjaWQiIGNsYWltIGlzIGEgYmFz
ZTY0dXJsIGVuY29kZWQgSldLIG9mDQoNCnRoZSByZWdpc3RlcmVkIGNsaWVudC4NCg0KDQoNCiJq
a3UiIFRoZSB2YWx1ZSBvZiB0aGUgImNpZCIgY2xhaW0gaXMgdGhlICJqa3UiIGRlZmluZWQgaW4g
NC4xLjIgb2YNCg0KSlNPTiB3ZWIgc2lnbmF0dXJlIFtKV1NdLg0KDQoNCg0KIng1dSIgVGhlIHZh
bHVlIG9mIHRoZSAiY2lkIiBjbGFpbSBpcyB0aGUgVVJMIHRoYXQgcG9pbnRzIHRvIHRoZSBwdWJs
aWMNCg0Ka2V5IGNlcnRpZmljYXRlIG9mIHRoZSByZWdpc3RlcmVkIGNsaWVudC4gVGhlIGZvcm1h
dCBvZiB0aGUgY29udGVudA0KDQp0aGF0IHg1dSBwb2ludHMgdG8gaXMgZGVzY3JpYmVkIGluIHNl
Y3Rpb24gNC4xLjQgb2YgdGhlIEpTT04gV2ViIFNpZ25hdHVyZS4NCg0KDQotLQ0KTmF0IFNha2lt
dXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2lt
dXJhLm9yZy8NCkBfbmF0X2VuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpP
QXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCg0K

--_000_4E1F6AAD24975D4BA5B16804296739436697B66FTK5EX14MBXC283r_
Content-Type: text/html; charset="utf-8"
Content-ID: <7CED534A08BBC341AA195C297EF0706F@microsoft.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSwmcXVvdDtTZWdvZSBVSSZxdW90OyxNZWlyeW8sJnF1b3Q7TWlj
cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90Oywm
cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O0tobWVyIFVJJnF1b3Q7LCZxdW90O05pcm1h
bGEgVUkmcXVvdDssVHVuZ2EsJnF1b3Q7TGFvIFVJJnF1b3Q7LEVicmltYSxzYW5zLXNlcmlmO2Zv
bnQtc2l6ZToxNnB4OyI+DQo8ZGl2PkknbSB3aXRoIFRvbnkgb24gdGhpcy4mbmJzcDsgVGhpcyBz
ZWVtcyBwcmVtYXR1cmUgdG8gcHV0IGludG8gdGhlIEpXVCBzdGFuZGFyZC4mbmJzcDsgQWxsIHRo
ZSBvdGhlciBKV1QgY2xhaW1zIGhhdmUgd2VsbCBlc3RhYmxpc2hlZCBtZWFuaW5ncyBhbmQgaGlz
dG9yeSBiZWhpbmQgdGhlbS4mbmJzcDsgVGhlc2UgZG9uJ3QuPC9kaXY+DQo8ZGl2PiZuYnNwOzwv
ZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPklmIHRoZSBnb2FsIGlzIHRv
IGFsbG93IE9wZW5JRCBDb25uZWN0IGltcGxlbWVudGF0aW9ucyB0byBub3QgcmVqZWN0IHRva2Vu
cyB1c2luZyZuYnNwO+KAnGNpZOKAnSwgdGhlcmUgYXJlIGxvdHMgb2Ygb3RoZXIgd2F5cyB0byBh
Y2NvbXBsaXNoIHRoaXMgdGhhdCBJIHRoaW5rIHdlIHNob3VsZCBjb25zaWRlciBmaXJzdC48L2Rp
dj4NCjxkaXYgZGF0YS1mb2N1c2Zyb21wb2ludGVyPSJ0cnVlIj4mbmJzcDs8L2Rpdj4NCjxkaXYg
ZGF0YS1mb2N1c2Zyb21wb2ludGVyPSJ0cnVlIj4tLSBNaWtlPC9kaXY+DQo8ZGl2IGRhdGEtZm9j
dXNmcm9tcG9pbnRlcj0idHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2IGRhdGEtZm9jdXNmcm9tcG9p
bnRlcj0idHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItdG9wLWNvbG9yOiBy
Z2IoMjI5LCAyMjksIDIyOSk7IGJvcmRlci10b3Atd2lkdGg6IDJweDsgYm9yZGVyLXRvcC1zdHls
ZTogc29saWQ7Ij4NCjxzdHJvbmc+RnJvbTo8L3N0cm9uZz4mbmJzcDtKb2huIEJyYWRsZXk8YnI+
DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+Jm5ic3A74oCORGVjZW1iZXLigI4g4oCOMTnigI4sIOKA
jjIwMTIg4oCONuKAjjrigI4yNeKAjiDigI5QTTxicj4NCjxzdHJvbmc+VG86PC9zdHJvbmc+Jm5i
c3A7QW50aG9ueSBOYWRhbGluPGJyPg0KPHN0cm9uZz5DQzo8L3N0cm9uZz4mbmJzcDtvYXV0aDxi
cj4NCjxzdHJvbmc+U3ViamVjdDo8L3N0cm9uZz4mbmJzcDtSZTogW09BVVRILVdHXSAmcXVvdDtj
aWQmcXVvdDsgY2xhaW0gaW4gSldUPGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KSSBh
Z3JlZSwgYXVkaWVuY2Ugd2hvIHJlcXVlc3RlZCBpdCBhbmQgYW5kIHdobyBpdCBpcyByZXF1ZXN0
ZWQgZm9yIGFyZSBhbGwgaW50ZXJyZWxhdGVkLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SG93
ZXZlciB3ZSBkbyBuZWVkIHRvIHNldCBkb3duIHNvbWUgc3RhbmRhcmQgd2F5IG9mIGV4cHJlc3Np
bmcgaXQgYXMgcGVvcGxlIGFyZSBzdGFydGluZyB0byBtYWtlIHN0dWZmIHVwIG9uIHRoZWlyIG93
biB0aGF0IHdpbGwgaW1wYWN0IGludGVyb3BlcmFiaWxpdHkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5JZiBHb29nbGUgc3RhcnRzIHRoYXdpbmcgaW4gY2lkIGFuZCBjbGllbnRzIGRv
bid0IGtub3cgYWJvdXQgaXQgdGhleSBtdXN0IHJlamVjdCB0aGUgSldUIGV0Yy48L2Rpdj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkpvaG48L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdj4NCjxkaXY+
T24gMjAxMi0xMi0xOSwgYXQgOTo0MCBQTSwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJt
YWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0
OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8
YmxvY2txdW90ZT4NCjxkaXYgbGFuZz0iRU4tVVMiIHN0eWxlPSJ0ZXh0LXRyYW5zZm9ybTogbm9u
ZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29yZC1zcGFjaW5n
OiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IG9ycGhhbnM6IDI7IHdpZG93czogMjsiPg0KPGRp
diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7
IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6
ZTogMTJwdDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZh
bWlseTogQ2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7Ij5JdCBzZWVtcyBwcmVt
YXR1cmUgYW5kIHdlIHNob3VsZCBjb25zaWRlciB0aGlzIGluIHRoZSBiaWdnZXIgY29udGV4dCBv
ZiB0aGUg4oCcb24gYmVoYWxmIG9m4oCdL2RlbGVnYXRpb24gd29yayB0aGF0IGhhcyBiZWVuIHN0
YXJ0ZWQ8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250
LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEy
cHQ7Ij4NCjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io
MzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6
IDExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9hPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsg
Zm9udC1zaXplOiAxMnB0OyI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks
c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7Ij48c3Bh
biBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp
bHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmciPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+DQog
W21haWx0bzpvYXV0aC08YSBocmVmPSJtYWlsdG86Ym91bmNlc0BpZXRmLm9yZyI+Ym91bmNlc0Bp
ZXRmLm9yZzwvYT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu
YnNwOzwvc3Bhbj48L2I+TmF0IFNha2ltdXJhPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9
IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlR1ZXNkYXksIERlY2VtYmVyIDE4
LCAyMDEyIDY6MjIgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl
ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm9hdXRoPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xh
c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPltPQVVUSC1XR10gJnF1b3Q7
Y2lkJnF1b3Q7IGNsYWltIGluIEpXVDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog
MGluIDBpbiAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy
aWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl
cmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCkluIE9wZW5JRCBDb25uZWN0IFdHLCB3ZSBoYXZlIGJl
ZW4gdGFsa2luZyB0aGlzIGZvciBzb21ldGltZS4mbmJzcDs8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJv
bWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCiZxdW90O2NpZCZxdW90OyBjbGFp
bSBpZGVudGlmaWVzIHRoZSBlbnRpdHkgdGhhdCB0aGUgSldUIHdhcyBpc3N1ZWQgdG8gYXMgYSBy
aWdodGZ1bC9saWNlbnNlZCB1c2VyLiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQpHb29nbGUgYWxyZWFkeSB1c2Vz
IHRoaXMgaW4gdGhlaXIgaW1wbGVtZW50YXRpb24gb2YgaWRfdG9rZW4gb2YgT0lEQy4mbmJzcDs8
L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGZv
bnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTog
MTJwdDsiPg0KJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46
IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl
cmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCkhlcmUgaXMgdGhlIHRleHQgcHJvcG9zYWwuIEl0IGlu
dHJvZHVjZXMgdHdvIG5ldyBzdGFuZGFyZCBjbGFpbXM6ICZxdW90O2NpZCZxdW90OyBhbmQgJnF1
b3Q7Y2l0JnF1b3Q7LiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFy
Z2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQombmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGxpbmUtaGVpZ2h0OiAxNXB0OyBmb250
LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEy
cHQ7IC1tcy13b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyI+
DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6IEFyaWFs
LHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+SXQgd291bGQgYmUgdmVyeSB1c2VmdWwg
aW4gY3JlYXRpbmcgYSBIb0sgZHJhZnRzIGFzIHdlbGwuJm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRp
diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgbGluZS1oZWlnaHQ6IDE1cHQ7IGZvbnQtZmFt
aWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsg
LW1zLXdvcmQtd3JhcDogYnJlYWstd29yZDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7Ij4NCjxz
cGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogQXJpYWwsc2Fu
cy1zZXJpZjsgZm9udC1zaXplOiAxMC41cHQ7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBsaW5lLWhlaWdodDogMTVwdDsgZm9udC1mYW1pbHk6
ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyAtbXMt
d29yZC13cmFwOiBicmVhay13b3JkOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsiPg0KPHNwYW4g
c3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNl
cmlmOyBmb250LXNpemU6IDEwLjVwdDsiPkNoZWVycywmbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2
IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBsaW5lLWhlaWdodDogMTVwdDsgZm9udC1mYW1p
bHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyAt
bXMtd29yZC13cmFwOiBicmVhay13b3JkOyBiYWNrZ3JvdW5kLWNvbG9yOiB3aGl0ZTsiPg0KPHNw
YW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiBBcmlhbCxzYW5z
LXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5
bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGxpbmUtaGVpZ2h0OiAxNXB0OyBmb250LWZhbWlseTog
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7IC1tcy13
b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IGJhY2tncm91bmQtY29sb3I6IHdoaXRlOyI+DQo8c3BhbiBz
dHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2Vy
aWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+TmF0PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy
Z2luOiAwaW4gMGluIDBwdDsgbGluZS1oZWlnaHQ6IDE1cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsgLW1zLXdvcmQtd3Jh
cDogYnJlYWstd29yZDsgYmFja2dyb3VuZC1jb2xvcjogd2hpdGU7Ij4NCjxzcGFuIHN0eWxlPSJj
b2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjsgZm9u
dC1zaXplOiAxMC41cHQ7Ij4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i
cGFkZGluZzogN3B0IDlwdDsgYm9yZGVyOiAxcHQgc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBi
YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij4NCjxwcmUgc3R5bGU9Im1hcmdp
bjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1p
bHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IC1tcy1vdmVyZmxv
dy14OiBhdXRvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3BhbiBz
dHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4mbmJzcDs8L3Nw
YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAw
aW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozsg
Zm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48
Yj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij40
PHNwYW4gY2xhc3M9InAiPi48L3NwYW4+MTxzcGFuIGNsYXNzPSJwIj4uPC9zcGFuPjk8c3BhbiBj
bGFzcz0icCI+Ljwvc3Bhbj4gJnF1b3Q7PHNwYW4gY2xhc3M9Im4iPmNpZDwvc3Bhbj4mcXVvdDsg
PHNwYW4gY2xhc3M9Im4iPkNsaWVudDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPklkZW50aWZpY2F0
aW9uPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+RGF0YTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPkNs
YWltPC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7
IGZvbnQtc2l6ZTogOXB0OyI+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1
b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjog
cmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7
IGZvbnQtc2l6ZTogOXB0OyI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
OiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWls
eTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1j
b2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gY2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJj
b2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPlRoZTwvc3Bhbj48L3NwYW4+
PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+ICZx
dW90OzxzcGFuIGNsYXNzPSJuIj5jaWQ8L3NwYW4+JnF1b3Q7IDxzcGFuIGNsYXNzPSJwIj4oPC9z
cGFuPjxzcGFuIGNsYXNzPSJuIj5jbGllbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5pZGVudGlm
aWNhdGlvbjwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmRhdGE8L3NwYW4+PHNwYW4gY2xhc3M9InAi
Pik8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5jbGFpbTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmFs
bG93czwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRoZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnJl
Y2VpdmVyPC9zcGFuPiA8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g
Ni43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtD
b3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io
MjQ1LCAyNDUsIDI0NSk7Ij48c3BhbiBjbGFzcz0ibiI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io
NTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+b2Y8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl
PSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiA8c3BhbiBjbGFzcz0i
biI+dGhlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+SldUPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+
dG88L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5pZGVudGlmeTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4i
PnRoZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmVudGl0eTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4i
PnRoYXQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5K
V1Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5pczwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBz
dHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNr
OyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsg
YmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gY2xhc3M9Im4iPjxz
cGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPmludGVu
ZGVkPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9u
dC1zaXplOiA5cHQ7Ij4gPHNwYW4gY2xhc3M9Im4iPnRvPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+
YmU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj51c2VkPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+Ynk8
L3NwYW4+PHNwYW4gY2xhc3M9InAiPi48L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5UaGU8L3NwYW4+
IDxzcGFuIGNsYXNzPSJuIj5hdWRpZW5jZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPm9mPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibiI+dGhlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+SldUPC9zcGFuPiA8
c3BhbiBjbGFzcz0ibiI+TVVTVDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmJlPC9zcGFuPiA8L3Nw
YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAw
aW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozsg
Zm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48
c3BhbiBjbGFzcz0ibiI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQt
c2l6ZTogOXB0OyI+YWJsZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEs
IDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+IDxzcGFuIGNsYXNzPSJuIj50bzwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im4iPmlkZW50aWZ5PC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dGhlPC9zcGFuPiA8
c3BhbiBjbGFzcz0ibiI+Y2xpZW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+d2l0aDwvc3Bhbj4g
PHNwYW4gY2xhc3M9Im4iPnRoZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnZhbHVlPC9zcGFuPiA8
c3BhbiBjbGFzcz0ibiI+b2Y8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50aGlzPC9zcGFuPiA8c3Bh
biBjbGFzcz0ibiI+Y2xhaW08L3NwYW4+PHNwYW4gY2xhc3M9InAiPi48L3NwYW4+PC9zcGFuPjwv
cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBi
b3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQt
c2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4g
c3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+Jm5ic3A7PC9z
cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzog
MGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7
IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+
PHNwYW4gY2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250
LXNpemU6IDlwdDsiPlRoZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEs
IDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+ICZxdW90OzxzcGFuIGNsYXNzPSJuIj5jaWQ8L3Nw
YW4+JnF1b3Q7IDxzcGFuIGNsYXNzPSJuIj52YWx1ZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmlz
PC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+YTwvc3Bhbj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJrIj48
c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCA2NCwgMTI4KTsgZm9udC1zaXplOiA5cHQ7Ij5jYXNl
PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1z
aXplOiA5cHQ7Ij4gPHNwYW4gY2xhc3M9Im4iPnNlbnNpdGl2ZTwvc3Bhbj4gPHNwYW4gY2xhc3M9
Im4iPnN0cmluZzwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmNvbnRhaW5pbmc8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj5hPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+U3RyaW5nT3JVUkk8L3NwYW4+IDxz
cGFuIGNsYXNzPSJuIj52YWx1ZTwvc3Bhbj48c3BhbiBjbGFzcz0icCI+Ljwvc3Bhbj48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47
IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9u
dC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3Bh
biBjbGFzcz0ibiI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6
ZTogOXB0OyI+VGhpczwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUx
LCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+IDxzcGFuIGNsYXNzPSJuIj5jbGFpbTwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im4iPmlzPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+T1BUSU9OQUw8L3NwYW4+PHNw
YW4gY2xhc3M9InAiPi48L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5JZjwvc3Bhbj4gPHNwYW4gY2xh
c3M9Im4iPnRoZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmVudGl0eTwvc3Bhbj4gPHNwYW4gY2xh
c3M9Im4iPnByb2Nlc3Npbmc8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj5jbGFpbTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmRvZXM8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj5ub3Q8L3NwYW4+IDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjog
MGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6
ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29s
b3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuIGNsYXNzPSJuIj48c3BhbiBzdHlsZT0iY29s
b3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij5pZGVudGlmeTwvc3Bhbj48L3Nw
YW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+
IDxzcGFuIGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj51c2VyPC9zcGFuPiA8
c3BhbiBjbGFzcz0ibiI+b2Y8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj5KV1Q8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj53aXRoPC9zcGFuPiA8c3BhbiBj
bGFzcz0ibiI+dGhlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+aWRlbnRpZmllcjwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im4iPmluPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dGhlPC9zcGFuPiAmcXVvdDs8
c3BhbiBjbGFzcz0ibiI+Y2lkPC9zcGFuPiZxdW90OyA8c3BhbiBjbGFzcz0ibiI+Y2xhaW08L3Nw
YW4+IDxzcGFuIGNsYXNzPSJuIj52YWx1ZTwvc3Bhbj48c3BhbiBjbGFzcz0icCI+LDwvc3Bhbj4g
PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGlu
ZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVv
dDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUp
OyI+PHNwYW4gY2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBm
b250LXNpemU6IDlwdDsiPnRoZW48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiA8c3BhbiBjbGFzcz0ibiI+dGhlPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibiI+SldUPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+TVVTVDwvc3Bhbj4g
PHNwYW4gY2xhc3M9Im4iPmJlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+cmVqZWN0ZWQ8L3NwYW4+
PHNwYW4gY2xhc3M9InAiPi48L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5UaGU8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj5pbnRlcnByZXRhdGlvbjwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPm9mPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibiI+dGhlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+cmVnaXN0ZXJlZDwv
c3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRvPC9zcGFuPiA8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZv
bnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNr
Z3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3BhbiBjbGFzcz0ibiI+PHNwYW4g
c3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+dmFsdWU8L3Nw
YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6
IDlwdDsiPiA8c3BhbiBjbGFzcz0ibiI+aXM8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5nZW5lcmFs
bHk8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5hcHBsaWNhdGlvbjwvc3Bhbj4gPHNwYW4gY2xhc3M9
Im4iPnNwZWNpZmljPC9zcGFuPjxzcGFuIGNsYXNzPSJwIj4uPC9zcGFuPjwvc3Bhbj48L3ByZT4N
CjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVy
OiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6
IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuIHN0eWxl
PSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiZuYnNwOzwvc3Bhbj48
L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsg
Ym9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250
LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFu
IGNsYXNzPSJuIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXpl
OiA5cHQ7Ij5BPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUx
KTsgZm9udC1zaXplOiA5cHQ7Ij4gPHNwYW4gY2xhc3M9Im4iPnR5cGljYWw8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj5leGFtcGxlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+b2Y8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj5hPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+cmVnaXN0ZXJlZDwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im4iPnRvPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+Y2xhaW08L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj5pbmNsdWRlczwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmZvbGxvd2luZzwvc3Bh
bj48c3BhbiBjbGFzcz0icCI+Ojwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy
Z2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZh
bWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3Vu
ZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gY2xhc3M9Im8iPjxzcGFuIHN0eWxl
PSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPio8L3NwYW4+PC9zcGFu
PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiA8
c3BhbiBjbGFzcz0ibiI+Y2xpZW50X2lkPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dGhhdDwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im4iPnRoZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmF1ZGllbmNlPC9z
cGFuPiA8c3BhbiBjbGFzcz0ibiI+Y2FuPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dXNlPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibiI+dG88L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5hdXRoZW50aWNhdGU8
L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5hbmQ8L3NwYW4+IDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsg
Zm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJh
Y2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjog
cmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNz
PSJuIj5pZGVudGlmeTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRoZTwvc3Bhbj4gPHNwYW4gY2xh
c3M9Im4iPmNsaWVudDwvc3Bhbj48c3BhbiBjbGFzcz0icCI+Ljwvc3Bhbj48L3NwYW4+PC9wcmU+
DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRl
cjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXpl
OiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3BhbiBjbGFz
cz0ibyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0
OyI+Kjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZv
bnQtc2l6ZTogOXB0OyI+IDxzcGFuIGNsYXNzPSJuIj5BPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+
YmFzZTY0dXJsPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+ZW5jb2RlZDwvc3Bhbj4gPHNwYW4gY2xh
c3M9Im4iPkpXSzwvc3Bhbj48c3BhbiBjbGFzcz0icCI+Ljwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6
IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTog
MTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gY2xhc3M9
Im8iPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsi
Pio8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250
LXNpemU6IDlwdDsiPiA8c3BhbiBjbGFzcz0ibiI+QTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPlVS
TDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRoYXQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5wb2lu
dHM8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50bzwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRoZTwv
c3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmtleTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPm1hdGVyaWFs
PC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dGhhdDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRoZTwv
c3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmF1ZGllbmNlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+Y2Fu
PC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dXNlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dG88L3Nw
YW4+IDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBh
ZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwg
MjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlw
dDsiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJuIj5hdXRoZW50aWNhdGU8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj51c2VyPC9zcGFuPiA8c3BhbiBj
bGFzcz0ibiI+b2Y8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFuIGNsYXNz
PSJuIj5KV1Q8L3NwYW4+PHNwYW4gY2xhc3M9InAiPi48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJs
YWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBw
dDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gc3R5bGU9ImNv
bG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+Jm5ic3A7PC9zcGFuPjwvcHJl
Pg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3Jk
ZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6
ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PGI+PHNwYW4g
c3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+NDxzcGFuIGNs
YXNzPSJwIj4uPC9zcGFuPjE8c3BhbiBjbGFzcz0icCI+Ljwvc3Bhbj4xMCAmcXVvdDs8c3BhbiBj
bGFzcz0ibiI+Y2l0PC9zcGFuPiZxdW90OyA8c3BhbiBjbGFzcz0icCI+KDwvc3Bhbj48c3BhbiBj
bGFzcz0ibiI+Q2xpZW50PC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+SWRlbnRpZmljYXRpb248L3Nw
YW4+IDxzcGFuIGNsYXNzPSJuIj5EYXRhPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+Y2xhaW08L3Nw
YW4+IDxzcGFuIGNsYXNzPSJuIj50eXBlPC9zcGFuPjxzcGFuIGNsYXNzPSJwIj4pPC9zcGFuPjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTog
OXB0OyI+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsg
cGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBO
ZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1
LCAyNDUpOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTog
OXB0OyI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYu
NzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291
cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0
NSwgMjQ1LCAyNDUpOyI+PHNwYW4gY2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUx
LCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPlRoZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9
ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+ICZxdW90OzxzcGFuIGNs
YXNzPSJuIj5jaXQ8L3NwYW4+JnF1b3Q7IDxzcGFuIGNsYXNzPSJwIj4oPC9zcGFuPjxzcGFuIGNs
YXNzPSJuIj5DbGllbnQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5JZGVudGlmaWNhdGlvbjwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im4iPkRhdGE8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5jbGFpbTwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im4iPnR5cGU8L3NwYW4+PHNwYW4gY2xhc3M9InAiPik8L3NwYW4+IDxz
cGFuIGNsYXNzPSJuIj5pZGVudGlmaWVzPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dGhlPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibiI+dHlwZTwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i
bWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250
LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dy
b3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gY2xhc3M9Im4iPjxzcGFuIHN0
eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPm9mPC9zcGFuPjwv
c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7
Ij4gPHNwYW4gY2xhc3M9Im4iPnRoZTwvc3Bhbj4gJnF1b3Q7PHNwYW4gY2xhc3M9Im4iPmNpZDwv
c3Bhbj4mcXVvdDsgPHNwYW4gY2xhc3M9Im4iPmNsYWltPC9zcGFuPjxzcGFuIGNsYXNzPSJwIj4u
PC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+SXQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5pczwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im4iPmE8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5TdHJpbmdPclVSSTwv
c3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnZhbHVlPC9zcGFuPjxzcGFuIGNsYXNzPSJwIj4uPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibiI+VGhlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+ZGVmaW5lZDwvc3Bh
bj4gPHNwYW4gY2xhc3M9Im4iPnZhbHVlczwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBm
b250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFj
a2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gY2xhc3M9Im4iPjxzcGFu
IHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPmFyZTwvc3Bh
bj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTog
OXB0OyI+IDxzcGFuIGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5mb2xsb3dp
bmc8L3NwYW4+PHNwYW4gY2xhc3M9InAiPjo8L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls
ZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBm
b250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFj
a2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiBy
Z2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJs
YWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBw
dDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gc3R5bGU9ImNv
bG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+JnF1b3Q7PHNwYW4gY2xhc3M9
Im4iPmNsaWVudF9pZDwvc3Bhbj4mcXVvdDsgPHNwYW4gY2xhc3M9Im4iPlRoZTwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im4iPnZhbHVlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+b2Y8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj50aGU8L3NwYW4+ICZxdW90OzxzcGFuIGNsYXNzPSJuIj5jaWQ8L3NwYW4+JnF1
b3Q7IDxzcGFuIGNsYXNzPSJuIj5jbGFpbTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmlzPC9zcGFu
PiA8c3BhbiBjbGFzcz0ibiI+dGhlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+Q2xpZW50PC9zcGFu
PiA8c3BhbiBjbGFzcz0ibiI+SUQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5vZjwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im4iPnRoZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmNsaWVudDwvc3Bhbj4gPC9z
cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzog
MGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7
IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+
PHNwYW4gY2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250
LXNpemU6IDlwdDsiPnRoYXQ8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUx
LCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiA8c3BhbiBjbGFzcz0ibiI+dGhlPC9zcGFuPiA8
c3BhbiBjbGFzcz0ibiI+YXVkaWVuY2U8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5vZjwvc3Bhbj4g
PHNwYW4gY2xhc3M9Im4iPnRoZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPkpXVDwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im4iPmlzPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+YWJsZTwvc3Bhbj4gPHNwYW4g
Y2xhc3M9Im4iPnRvPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dXNlPC9zcGFuPiA8c3BhbiBjbGFz
cz0ibiI+dG88L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5hdXRoZW50aWNhdGU8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5jbGllbnQ8L3NwYW4+PHNwYW4g
Y2xhc3M9InAiPi48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1
b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjog
cmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7
IGZvbnQtc2l6ZTogOXB0OyI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
OiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWls
eTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1j
b2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUx
LCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+JnF1b3Q7PHNwYW4gY2xhc3M9Im4iPmp3azwvc3Bhbj4m
cXVvdDsgPHNwYW4gY2xhc3M9Im4iPlRoZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnZhbHVlPC9z
cGFuPiA8c3BhbiBjbGFzcz0ibiI+b2Y8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50aGU8L3NwYW4+
ICZxdW90OzxzcGFuIGNsYXNzPSJuIj5jaWQ8L3NwYW4+JnF1b3Q7IDxzcGFuIGNsYXNzPSJuIj5j
bGFpbTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmlzPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+YTwv
c3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmJhc2U2NHVybDwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmVu
Y29kZWQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5KV0s8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5v
Zjwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVw
dDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmll
ciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwg
MjQ1LCAyNDUpOyI+PHNwYW4gY2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1
MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPnRoZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNv
bG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+IDxzcGFuIGNsYXNzPSJuIj5y
ZWdpc3RlcmVkPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+Y2xpZW50PC9zcGFuPjxzcGFuIGNsYXNz
PSJwIj4uPC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2
Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigy
NDUsIDI0NSwgMjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250
LXNpemU6IDlwdDsiPiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGlu
IDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZx
dW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6
IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEp
OyBmb250LXNpemU6IDlwdDsiPiZxdW90OzxzcGFuIGNsYXNzPSJuIj5qa3U8L3NwYW4+JnF1b3Q7
IDxzcGFuIGNsYXNzPSJuIj5UaGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj52YWx1ZTwvc3Bhbj4g
PHNwYW4gY2xhc3M9Im4iPm9mPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dGhlPC9zcGFuPiAmcXVv
dDs8c3BhbiBjbGFzcz0ibiI+Y2lkPC9zcGFuPiZxdW90OyA8c3BhbiBjbGFzcz0ibiI+Y2xhaW08
L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5pczwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRoZTwvc3Bh
bj4gJnF1b3Q7PHNwYW4gY2xhc3M9Im4iPmprdTwvc3Bhbj4mcXVvdDsgPHNwYW4gY2xhc3M9Im4i
PmRlZmluZWQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5pbjwvc3Bhbj4gNDxzcGFuIGNsYXNzPSJw
Ij4uPC9zcGFuPjE8c3BhbiBjbGFzcz0icCI+Ljwvc3Bhbj4yIDxzcGFuIGNsYXNzPSJuIj5vZjwv
c3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsg
cGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBO
ZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1
LCAyNDUpOyI+PHNwYW4gY2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwg
NTEpOyBmb250LXNpemU6IDlwdDsiPkpTT048L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv
cjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiA8c3BhbiBjbGFzcz0ibiI+d2Vi
PC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+c2lnbmF0dXJlPC9zcGFuPiA8c3BhbiBjbGFzcz0icCI+
Wzwvc3Bhbj48c3BhbiBjbGFzcz0ibiI+SldTPC9zcGFuPjxzcGFuIGNsYXNzPSJwIj5dLjwvc3Bh
bj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRk
aW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZx
dW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0
NSk7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7
Ij4mbmJzcDs8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0
OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVy
IE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAy
NDUsIDI0NSk7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXpl
OiA5cHQ7Ij4mcXVvdDs8c3BhbiBjbGFzcz0ibiI+eDV1PC9zcGFuPiZxdW90OyA8c3BhbiBjbGFz
cz0ibiI+VGhlPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dmFsdWU8L3NwYW4+IDxzcGFuIGNsYXNz
PSJuIj5vZjwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRoZTwvc3Bhbj4gJnF1b3Q7PHNwYW4gY2xh
c3M9Im4iPmNpZDwvc3Bhbj4mcXVvdDsgPHNwYW4gY2xhc3M9Im4iPmNsYWltPC9zcGFuPiA8c3Bh
biBjbGFzcz0ibiI+aXM8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFuIGNs
YXNzPSJuIj5VUkw8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50aGF0PC9zcGFuPiA8c3BhbiBjbGFz
cz0ibiI+cG9pbnRzPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+dG88L3NwYW4+IDxzcGFuIGNsYXNz
PSJuIj50aGU8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5wdWJsaWM8L3NwYW4+IDwvc3Bhbj48L3By
ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9y
ZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNp
emU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuIGNs
YXNzPSJuIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5
cHQ7Ij5rZXk8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEp
OyBmb250LXNpemU6IDlwdDsiPiA8c3BhbiBjbGFzcz0ibiI+Y2VydGlmaWNhdGU8L3NwYW4+IDxz
cGFuIGNsYXNzPSJuIj5vZjwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRoZTwvc3Bhbj4gPHNwYW4g
Y2xhc3M9Im4iPnJlZ2lzdGVyZWQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5jbGllbnQ8L3NwYW4+
PHNwYW4gY2xhc3M9InAiPi48L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5UaGU8L3NwYW4+IDxzcGFu
IGNsYXNzPSJuIj5mb3JtYXQ8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5vZjwvc3Bhbj4gPHNwYW4g
Y2xhc3M9Im4iPnRoZTwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPmNvbnRlbnQ8L3NwYW4+IDwvc3Bh
bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBp
bjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBm
b250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxz
cGFuIGNsYXNzPSJuIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1z
aXplOiA5cHQ7Ij50aGF0PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwg
NTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4gPHNwYW4gY2xhc3M9Im4iPng1dTwvc3Bhbj4gPHNw
YW4gY2xhc3M9Im4iPnBvaW50czwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnRvPC9zcGFuPiA8c3Bh
biBjbGFzcz0ibiI+aXM8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj5kZXNjcmliZWQ8L3NwYW4+IDxz
cGFuIGNsYXNzPSJuIj5pbjwvc3Bhbj4gPHNwYW4gY2xhc3M9Im4iPnNlY3Rpb248L3NwYW4+IDQ8
c3BhbiBjbGFzcz0icCI+Ljwvc3Bhbj4xPHNwYW4gY2xhc3M9InAiPi48L3NwYW4+NCA8c3BhbiBj
bGFzcz0ibiI+b2Y8L3NwYW4+IDxzcGFuIGNsYXNzPSJuIj50aGU8L3NwYW4+IDxzcGFuIGNsYXNz
PSJuIj5KU09OPC9zcGFuPiA8c3BhbiBjbGFzcz0ibiI+V2ViPC9zcGFuPiA8c3BhbiBjbGFzcz0i
biI+U2lnbmF0dXJlPC9zcGFuPjxzcGFuIGNsYXNzPSJwIj4uPC9zcGFuPjwvc3Bhbj48L3ByZT4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu
OiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz
ZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQombmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHls
ZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21h
biZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQotLTxzcGFuIGNsYXNzPSJBcHBsZS1j
b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpPC9k
aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6
ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQpD
aGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBzdHlsZT0iY29sb3I6IHB1cnBsZTsg
dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9y
Zy8iPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjwvZGl2Pg0KPC9k
aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCiZuYnNwOzwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRv
Ok9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
Cjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_4E1F6AAD24975D4BA5B16804296739436697B66FTK5EX14MBXC283r_--

From sakimura@gmail.com  Wed Dec 19 21:32:13 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3D21F88E8 for ; Wed, 19 Dec 2012 21:32:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.076
X-Spam-Level: 
X-Spam-Status: No, score=-3.076 tagged_above=-999 required=5 tests=[AWL=0.522,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bsqQCUd7pV3 for ; Wed, 19 Dec 2012 21:32:11 -0800 (PST)
Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id E963F21F88A2 for ; Wed, 19 Dec 2012 21:32:10 -0800 (PST)
Received: by mail-ea0-f172.google.com with SMTP id a1so1175750eaa.3 for ; Wed, 19 Dec 2012 21:32:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jyTn7ohLdvyYssoKUeCvvrATfOwERBUNnR8Ng6UOatU=; b=K7jltXmGomMgFzf0qLKAIvDbKGUXw7v2X28raXmm/JRoy5wXP6GBhOkysF++AmppIT BlNt6o2s289In4kY/G6pSsRfM00MSlnvyzBE9aNwY9a1cT4+C1Cv2if29QYUtvb1NCED RhZ5TjHw7PmCNXn4DTGiIw9SjIeuMzG4e9a6FZQklPlIAc93ewh+c7pSOgoPezNTPCWU hvLH/lFyIPQIVCc3zCTdvqguCPKvtgLj2s77Q4iAOA1ayM7YwN8JUJrJQopt/W+JnS2v OlMKqSchAQUymT4ODXZmt8q78cbl7ia9ZJBJL1aAmW2gG6CeGaEgTuPMZ0N1GhkQMzlg f+Kw==
MIME-Version: 1.0
Received: by 10.14.174.132 with SMTP id x4mr19922046eel.39.1355981529814; Wed, 19 Dec 2012 21:32:09 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Wed, 19 Dec 2012 21:32:09 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697B66F@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739436697B66F@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Thu, 20 Dec 2012 14:32:09 +0900
Message-ID: 
From: Nat Sakimura 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=047d7b621de26814e504d1420df0
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 05:32:13 -0000

--047d7b621de26814e504d1420df0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I obviously disagree - if I did agree, I did not send it to the list to
start with :-)

"cid" (or in my original proposal, "reg") has a very clear and established
meaning.
The parallel examples abounds in our daily life.

It has very little to do with On-behalf-of.
It is not a delegation statement.

"cid" is there to indicate to whom it was issued to.
The entity who was issued this "token" is eligible to use it at the
entities indicated by "aud".

Example in our real life are like:

- Airline boarding pass
- Registered instruments (bond / share)
- Monthly train pass
- Disneyland annual passport
 etc. etc.

Please do not mix it up with a delegation statement like on-behalf-of,
which is much less well defined.

Nat



On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones w=
rote:

>  I'm with Tony on this.  This seems premature to put into the JWT
> standard.  All the other JWT claims have well established meanings and
> history behind them.  These don't.
>
> If the goal is to allow OpenID Connect implementations to not reject
> tokens using =93cid=94, there are lots of other ways to accomplish this t=
hat I
> think we should consider first.
>
> -- Mike
>
>
>  *From:* John Bradley
> *Sent:* December 19, 2012 6:25 PM
> *To:* Anthony Nadalin
> *CC:* oauth
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT
>
> I agree, audience who requested it and and who it is requested for are al=
l
> interrelated.
>
>  However we do need to set down some standard way of expressing it as
> people are starting to make stuff up on their own that will impact
> interoperability.
>
>  If Google starts thawing in cid and clients don't know about it they
> must reject the JWT etc.
>
>  John
>
>  On 2012-12-19, at 9:40 PM, Anthony Nadalin  wrote=
:
>
>   It seems premature and we should consider this in the bigger context of
> the =93on behalf of=94/delegation work that has been started
>
>  *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On
> Behalf Of *Nat Sakimura
> *Sent:* Tuesday, December 18, 2012 6:22 PM
> *To:* oauth
> *Subject:* [OAUTH-WG] "cid" claim in JWT
>
>  In OpenID Connect WG, we have been talking this for sometime.
>  "cid" claim identifies the entity that the JWT was issued to as a
> rightful/licensed user.
>   Google already uses this in their implementation of id_token of OIDC.
>
>   Here is the text proposal. It introduces two new standard claims: "cid"
> and "cit".
>
>   It would be very useful in creating a HoK drafts as well.
>
>  Cheers,
>
>  Nat
>
>
>
>
> *4.1.9. "cid" Client Identification Data Claim*
>
>
>
> The "cid" (client identification data) claim allows the receiver
>
> of the JWT to identify the entity that the JWT is
>
> intended to be used by. The audience of the JWT MUST be
>
> able to identify the client with the value of this claim.
>
>
>
> The "cid" value is a case sensitive string containing a StringOrURI value=
.
>
> This claim is OPTIONAL. If the entity processing the claim does not
>
> identify the user of the JWT with the identifier in the "cid" claim value=
,
>
> then the JWT MUST be rejected. The interpretation of the registered to
>
> value is generally application specific.
>
>
>
> A typical example of a registered to claim includes following:
>
> * client_id that the audience can use to authenticate and
>
>   identify the client.
>
> * A base64url encoded JWK.
>
> * A URL that points to the key material that the audience can use to
>
>   authenticate the user of the JWT.
>
>
>
> *4.1.10 "cit" (Client Identification Data claim type)*
>
>
>
> The "cit" (Client Identification Data claim type) identifies the type
>
> of the "cid" claim. It is a StringOrURI value. The defined values
>
> are the following:
>
>
>
> "client_id" The value of the "cid" claim is the Client ID of the client
>
> that the audience of the JWT is able to use to authenticate the client.
>
>
>
> "jwk" The value of the "cid" claim is a base64url encoded JWK of
>
> the registered client.
>
>
>
> "jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of
>
> JSON web signature [JWS].
>
>
>
> "x5u" The value of the "cid" claim is the URL that points to the public
>
> key certificate of the registered client. The format of the content
>
> that x5u points to is described in section 4.1.4 of the JSON Web Signatur=
e.
>
>
>  --
> Nat Sakimura (=3Dnat)
>  Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>  _______________________________________________
> OAuth mailing 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
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b621de26814e504d1420df0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I obviously disagree - if I did agree, I did not send it to the list to sta=
rt with :-)

"cid" (or in my original proposal,=
 "reg") has a very clear and established meaning.=A0
Th=
e parallel examples abounds in our daily life.=A0



It has very little to do with On-behalf-of.=A0
It is not a delegation statement.=A0

"cid&q=
uot; is there to indicate to whom it was issued to.=A0
The entity=
 who was issued this "token" is eligible to use it at the=A0

entities indicated by "aud".=A0

Exa=
mple in our real life are like:=A0

- Airline board=
ing pass
- Registered instruments (bond / share)=A0
- M=
onthly train pass


- Disneyland annual passport
=A0etc. etc.=A0

<=
/div>
Please do not mix it up with a delegation statement like on-behal=
f-of,=A0
which is much less well defined.=A0

=


Nat



On Thu, Dec=
 20, 2012 at 12:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:












I'm with Tony on this.=A0 This seems premature to put into the JWT=
 standard.=A0 All the other JWT claims have well established meanings and h=
istory behind them.=A0 These don't.


=A0


If the goal is to allow OpenID Connect implementations to not reject t=
okens using=A0=93cid=94, there are lots of other ways to accomplish this th=
at I think we should consider first.


=A0


-- Mike


=A0


=A0



From:=A0John Bradley

Sent:=A0December 19, 2012 6:25 PM

To:=A0Anthony Nadalin

CC:=A0oauth

Subject:=A0Re: [OAUTH-WG] "cid" claim in JWT




=A0

I agree, audience who requested it and and who it is requested for are all =
interrelated.






However we do need to set down some standard way of expressing it as p=
eople are starting to make stuff up on their own that will impact interoper=
ability.







If Google starts thawing in cid and clients don't know about it th=
ey must reject the JWT etc.







John







On 2012-12-19, at 9:40 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:










It seems premature and we should consider this in the bigger contex=
t of the =93on behalf of=94/delegation work that has been started




From:=
=A0oauth=
-bounces@ietf.org
 [mailto:oauth-bounces@ietf.org]=A0On Behalf Of=A0Nat Sakimura

Sent:=A0Tuesday, December 18, 2012 6:22 PM

To:=A0oauth

Subject:=A0[OAUTH-WG] "cid" claim in JWT



=A0



In OpenID Connect WG, we have been talking this for sometime.=A0





"cid" claim identifies the entity that the JWT was issued to as a=
 rightful/licensed user.=A0







Google already uses this in their implementation of id_token of OIDC.=A0






=A0







Here is the text proposal. It introduces two new standard claims: "cid=
" and "cit".=A0







=A0







It would be very useful in creating a HoK drafts as well.=A0<=
/div>


=A0



Cheers,=A0



=A0



Nat



=A0






=A0


=
4.1.9. "cid" Client Identification Data Claim



=A0


The "cid" =
(client identification data) claim allows the =
receiver 



of the JWT to identify the entity that the JWT is 



intended=
 to be=
 used by. The audience of the JWT MUST be 



able to identi=
fy the client with the<=
/span> value of this claim.



=A0


The "cid" =
value is a case sensitive string=
 containing a StringOrURI valu=
e.



This claim is<=
/span> OPTIONAL. If the=
 entity processing the claim does not 



identify=
 the u=
ser of the JWT with the identifier in the "cid" claim value=
, 



then the JWT MUST be rejected.=
 The interpretation of the registered to 



value is gener=
ally application specific.



=A0


A typical exam=
ple of a registered to<=
/span> claim includes following: 



* client_id th=
at the audience can use=
 to authenticate and <=
/pre>


=A0=A0identify =
the client.



* A base64url<=
/span> encoded JWK. 



* A URL=
 that points to the key material that the audience can use to =




=A0=A0authenticate the user of the JWT.



=A0


=
4.1.10 "cit" (Client Identification Data claim type)



=A0


The "cit" =
(Client Identification Data claim type) identifies the type 



of the "c=
id" claim. It is a StringOrURI value. The defined values 



are the follow=
ing:



=A0


"client_id=
" The value of the=
 "cid" claim is the<=
/span> Client ID of the=
 client 



that the audie=
nce of the JWT is able to use to =
authenticate the client.



=A0


"jwk"=
 The value of the "=
;cid" claim is a <=
span>base64url encoded JWK of=
 



the registered client.



=A0


"jku"=
 The value of the "=
;cid" claim is the=
 "jku" defined in 4.=
1.2 of 



JSON web signa=
ture [JWS].



=A0


"x5u"=
 The value of the "=
;cid" claim is the=
 URL that points to the public 



key certificate of the registered client. The format of the<=
/span> content 



that x5u point=
s to is described in section 4.1.4 of <=
span>the JSON Web Signature.














=A0





--=A0

Nat Sakimura (=3Dnat)





Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en





=A0





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en




--047d7b621de26814e504d1420df0--

From sakimura@gmail.com  Wed Dec 19 21:38:55 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B0921F8480 for ; Wed, 19 Dec 2012 21:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.108
X-Spam-Level: 
X-Spam-Status: No, score=-3.108 tagged_above=-999 required=5 tests=[AWL=0.490,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gf9Tr++dugkz for ; Wed, 19 Dec 2012 21:38:53 -0800 (PST)
Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2E69921F8479 for ; Wed, 19 Dec 2012 21:38:52 -0800 (PST)
Received: by mail-ea0-f179.google.com with SMTP id i12so1130969eaa.10 for ; Wed, 19 Dec 2012 21:38:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7a7MzXsNVLxWEJopL7N9EFm99BZhcImgCiPbOGv39XE=; b=h5ETh+E9rSWb1ag+aT6aY4/itdr9TTbvNGDgnSY4bLqjMBlPxgyxWmdRkdyGtYGh5i 5u92GkCcE0aCaRyacem5epPmn5bgM4d9IsW+KpeTevrru8+AftxQ7fts9IOPB3tB6Ybv pVUZx9G0w6o0xhMi3No6BizgZ70fWPG21WrjLkb3AAnMoGB/DDF8ThxrvCBhtfs4KLSk LQ+hpenWJpV5F+nhtL2pL2ydIm4960bSB3eL4HXPPCq4lWdX1v14gPiyqtNfAsLect5M 0jU75bdfYCddPWEiQRXoibaom4I7inPFf576HjzDbwgDfZ7CRNxIvdHZ7WaPM3blnEeI h/Ag==
MIME-Version: 1.0
Received: by 10.14.206.197 with SMTP id l45mr20477985eeo.17.1355981931197; Wed, 19 Dec 2012 21:38:51 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Wed, 19 Dec 2012 21:38:51 -0800 (PST)
In-Reply-To: <7C676625-BB10-485E-80C8-2205CCDF38E2@ve7jtb.com>
References:  <31476ed163f348a1a1a80e57ee75c1ce@BY2PR03MB041.namprd03.prod.outlook.com> <7C676625-BB10-485E-80C8-2205CCDF38E2@ve7jtb.com>
Date: Thu, 20 Dec 2012 14:38:51 +0900
Message-ID: 
From: Nat Sakimura 
To: John Bradley 
Content-Type: multipart/alternative; boundary=047d7b34413c54b59104d14225e3
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 05:38:55 -0000

--047d7b34413c54b59104d14225e3
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Thu, Dec 20, 2012 at 11:25 AM, John Bradley  wrote:

> I agree, audience who requested it and and who it is requested for are al=
l
> interrelated.
>

Bringing in such application or protocol specific semantics to the level of
JWT does not seem to be a good idea to me.

What I am proposing is just the claim that identifies who is the eligible
user of the token.
It is independent of request or where it can be used.
It is an abstract notion which application protocols can utilize.


>
> However we do need to set down some standard way of expressing it as
> people are starting to make stuff up on their own that will impact
> interoperability.
>
> If Google starts thawing in cid and clients don't know about it they must
> reject the JWT etc.
>
> John
>
> On 2012-12-19, at 9:40 PM, Anthony Nadalin  wrote:
>
> It seems premature and we should consider this in the bigger context of
> the =93on behalf of=94/delegation work that has been started****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Tuesday, December 18, 2012 6:22 PM
> *To:* oauth
> *Subject:* [OAUTH-WG] "cid" claim in JWT****
> ** **
> In OpenID Connect WG, we have been talking this for sometime. ****
> "cid" claim identifies the entity that the JWT was issued to as a
> rightful/licensed user. ****
> Google already uses this in their implementation of id_token of OIDC. ***=
*
> ** **
> Here is the text proposal. It introduces two new standard claims: "cid"
> and "cit". ****
> ** **
> It would be very useful in creating a HoK drafts as well. ****
>
> Cheers, ****
>
> Nat****
>
>
>
>
> *4.1.9. "cid" Client Identification Data Claim*****
>
>
>
> The "cid" (client identification data) claim allows the receiver ****
>
> of the JWT to identify the entity that the JWT is ****
>
> intended to be used by. The audience of the JWT MUST be ****
>
> able to identify the client with the value of this claim.****
>
>
>
> The "cid" value is a case sensitive string containing a StringOrURI value=
.****
>
> This claim is OPTIONAL. If the entity processing the claim does not ****
>
> identify the user of the JWT with the identifier in the "cid" claim value=
, ****
>
> then the JWT MUST be rejected. The interpretation of the registered to **=
**
>
> value is generally application specific.****
>
>
>
> A typical example of a registered to claim includes following: ****
>
> * client_id that the audience can use to authenticate and ****
>
>   identify the client.****
>
> * A base64url encoded JWK. ****
>
> * A URL that points to the key material that the audience can use to ****
>
>   authenticate the user of the JWT.****
>
>
>
> *4.1.10 "cit" (Client Identification Data claim type)*****
>
>
>
> The "cit" (Client Identification Data claim type) identifies the type ***=
*
>
> of the "cid" claim. It is a StringOrURI value. The defined values ****
>
> are the following:****
>
>
>
> "client_id" The value of the "cid" claim is the Client ID of the client *=
***
>
> that the audience of the JWT is able to use to authenticate the client.**=
**
>
>
>
> "jwk" The value of the "cid" claim is a base64url encoded JWK of ****
>
> the registered client.****
>
>
>
> "jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of ****
>
> JSON web signature [JWS].****
>
>
>
> "x5u" The value of the "cid" claim is the URL that points to the public *=
***
>
> key certificate of the registered client. The format of the content ****
>
> that x5u points to is described in section 4.1.4 of the JSON Web Signatur=
e.****
>
> ** **
> --
> Nat Sakimura (=3Dnat)****
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
> ** **
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>


--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b34413c54b59104d14225e3
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable



On Thu, Dec 20, 2012 at 11:25 AM, John B=
radley <ve7jtb@ve7jtb.com> wrote:


I agree, audience who requested it and =
and who it is requested for are all interrelated.
Bringing in such application or protocol specific semantics to=
 the level of JWT does not seem to be a good idea to me.=A0



What I am proposing is just the claim that identifies w=
ho is the eligible user of the token.=A0
It is independent of req=
uest or where it can be used.=A0
It is an abstract notion which a=
pplication protocols can utilize.=A0


=A0

However we do need to set down some standard way =
of expressing it as people are starting to make stuff up on their own that =
will impact interoperability.



If Google starts thawing in cid and clients don't k=
now about it they must reject the JWT etc.

John

On 2012-12-19, at 9:40 PM, Ant=
hony Nadalin <tonynad@microsoft.com> wrote:




It seems prematu=
re and we should consider this in the bigger context of the =93on behalf of=
=94/delegation work that has been started



From:=A0oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org]=A0On Behalf Of=A0Nat Sakimura

Sent:=A0Tuesday, December 18, 2012 6:22 PM
To:=A0oauth
Subject:=A0[OAUTH-WG] "c=
id" claim in JWT

=A0
In OpenID Connect WG, we have=
 been talking this for sometime.=A0

"cid" claim identifies the entity that the JWT was issued to as a=
 rightful/licensed user.=A0

Google already uses this in their implementation of id_token of OIDC.=A0=

=A0
<=
/div>

Here is the text proposal. It introduces two ne=
w standard claims: "cid" and "cit".=A0

=A0

It would be very useful in creating a HoK drafts as well.=A0<=
u>

=A0

Cheers,=A0

=A0

Nat

=A0


=A0
4.1=
.9. "cid" Client Identification Data Claim


=A0


The "cid" (client iden=
tification data) claim =
allows the receiver <=
/pre>

of=
 the JWT to identify the entity that the JWT is 


intended to be used by. The audience of th=
e JWT MUST be <=
/span>


able to identify the client with the value of this claim.


=A0


The "cid" value is a case sensit=
ive string containing a StringOrURI value.

This claim is OPTIONAL. <=
span>If the entity processing=
 the claim does not =



identify the user of the =
JWT with the identifier=
 in the "cid" claim<=
/span> value, 


then the JWT MUST be rejected. The interpretation of the registered to =



value is generally application s=
pecific.


=A0


A =
typical example of a registered to claim includes following: 


* =
client_id that the audience can use to authenticate and 


=A0=A0identify the client.<=
/span>


* =
A base64url encoded JWK=
. 


* =
A URL that points to the key material th=
at the audience can use=
 to 


=A0=A0authenticate the user of the JWT.


=A0


4.1.10 "cit" (=
Client Identification Data claim type)


=A0


The "cit" (Client Iden=
tification Data claim type) identifies the type <=
/u>


of=
 the "cid" claim. It is a StringOrURI value. The defined values 


are the following:


=A0


"client_id" The value <=
span>of the "cid" claim is the Client ID <=
span>of the client 

that the audience of the =
JWT is able to us=
e to authenticate the c=
lient.


=A0


"jwk" The value o=
f the "cid" claim <=
span>is a base64url encoded <=
span>JWK of 


the registered client.


=A0


"jku" The value o=
f the "cid" claim <=
span>is the "jku" defined<=
/span> in 4.1.2 of <=
/u>


JSON web signature [JWS].


=A0


"x5u" The value o=
f the "cid" claim <=
span>is the URL that po=
ints to the public =



key certificate of the registere=
d client. The format of the content 


that x5u points to is described in section 4.1.4 of the JSON Web<=
/span> Signature.


=A0
<=
/div>

--=A0
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/

@_nat_en
=A0<=
/div>
______________________________________________=
_

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






-- 
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/

@_nat_en


--047d7b34413c54b59104d14225e3--

From Michael.Jones@microsoft.com  Wed Dec 19 22:07:25 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3876121F8848 for ; Wed, 19 Dec 2012 22:07: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=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Q8fRtJfGtpQ for ; Wed, 19 Dec 2012 22:07:21 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 857E321F8853 for ; Wed, 19 Dec 2012 22:07:15 -0800 (PST)
Received: from BL2FFO11FD005.protection.gbl (10.173.161.203) by BL2FFO11HUB005.protection.gbl (10.173.160.225) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 06:07:06 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 06:07:06 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 06:07:02 +0000
From: Mike Jones 
To: Nat Sakimura 
Thread-Topic: [OAUTH-WG] "cid" claim in JWT
Thread-Index: Ac3eeDoQnms0qid0tk+0K29GGMlTVQ==
Date: Thu, 20 Dec 2012 06:07:01 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436697EF82TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(24454001)(53806001)(54316002)(44976002)(56776001)(1411001)(15202345001)(512874001)(74662001)(31966008)(54356001)(76482001)(47446002)(550184003)(74502001)(56816002)(5343635001)(47736001)(46102001)(16236675001)(33656001)(5343655001)(59766001)(50986001)(77982001)(4396001)(16406001)(51856001)(47976001)(55846006)(49866001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB005; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07013D7479
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 06:07:25 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436697EF82TK5EX14MBXC283r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hhdCB3b3VsZCB0aGUgaXNzLCBwcm4sIGF1ZCwgYW5kIGNpZCB2YWx1ZXMgcmVwcmVzZW50IGlu
IHRoZSBib2FyZGluZyBwYXNzIGV4YW1wbGU/DQoNCi0tIE1pa2UNCg0KRnJvbTogTmF0IFNha2lt
dXJhDQpTZW50OiDigI5EZWNlbWJlcuKAjiDigI4xOeKAjiwg4oCOMjAxMiDigI454oCOOuKAjjMy
4oCOIOKAjlBNDQpUbzogTWlrZSBKb25lcw0KQ0M6IEFudGhvbnkgTmFkYWxpbiwgSm9obiBCcmFk
bGV5LCBvYXV0aA0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gImNpZCIgY2xhaW0gaW4gSldUDQoN
Ckkgb2J2aW91c2x5IGRpc2FncmVlIC0gaWYgSSBkaWQgYWdyZWUsIEkgZGlkIG5vdCBzZW5kIGl0
IHRvIHRoZSBsaXN0IHRvIHN0YXJ0IHdpdGggOi0pDQoNCiJjaWQiIChvciBpbiBteSBvcmlnaW5h
bCBwcm9wb3NhbCwgInJlZyIpIGhhcyBhIHZlcnkgY2xlYXIgYW5kIGVzdGFibGlzaGVkIG1lYW5p
bmcuDQpUaGUgcGFyYWxsZWwgZXhhbXBsZXMgYWJvdW5kcyBpbiBvdXIgZGFpbHkgbGlmZS4NCg0K
SXQgaGFzIHZlcnkgbGl0dGxlIHRvIGRvIHdpdGggT24tYmVoYWxmLW9mLg0KSXQgaXMgbm90IGEg
ZGVsZWdhdGlvbiBzdGF0ZW1lbnQuDQoNCiJjaWQiIGlzIHRoZXJlIHRvIGluZGljYXRlIHRvIHdo
b20gaXQgd2FzIGlzc3VlZCB0by4NClRoZSBlbnRpdHkgd2hvIHdhcyBpc3N1ZWQgdGhpcyAidG9r
ZW4iIGlzIGVsaWdpYmxlIHRvIHVzZSBpdCBhdCB0aGUNCmVudGl0aWVzIGluZGljYXRlZCBieSAi
YXVkIi4NCg0KRXhhbXBsZSBpbiBvdXIgcmVhbCBsaWZlIGFyZSBsaWtlOg0KDQotIEFpcmxpbmUg
Ym9hcmRpbmcgcGFzcw0KLSBSZWdpc3RlcmVkIGluc3RydW1lbnRzIChib25kIC8gc2hhcmUpDQot
IE1vbnRobHkgdHJhaW4gcGFzcw0KLSBEaXNuZXlsYW5kIGFubnVhbCBwYXNzcG9ydA0KIGV0Yy4g
ZXRjLg0KDQpQbGVhc2UgZG8gbm90IG1peCBpdCB1cCB3aXRoIGEgZGVsZWdhdGlvbiBzdGF0ZW1l
bnQgbGlrZSBvbi1iZWhhbGYtb2YsDQp3aGljaCBpcyBtdWNoIGxlc3Mgd2VsbCBkZWZpbmVkLg0K
DQpOYXQNCg0KDQoNCk9uIFRodSwgRGVjIDIwLCAyMDEyIGF0IDEyOjA3IFBNLCBNaWtlIEpvbmVz
IDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuSm9uZXNAbWljcm9z
b2Z0LmNvbT4+IHdyb3RlOg0KSSdtIHdpdGggVG9ueSBvbiB0aGlzLiAgVGhpcyBzZWVtcyBwcmVt
YXR1cmUgdG8gcHV0IGludG8gdGhlIEpXVCBzdGFuZGFyZC4gIEFsbCB0aGUgb3RoZXIgSldUIGNs
YWltcyBoYXZlIHdlbGwgZXN0YWJsaXNoZWQgbWVhbmluZ3MgYW5kIGhpc3RvcnkgYmVoaW5kIHRo
ZW0uICBUaGVzZSBkb24ndC4NCg0KSWYgdGhlIGdvYWwgaXMgdG8gYWxsb3cgT3BlbklEIENvbm5l
Y3QgaW1wbGVtZW50YXRpb25zIHRvIG5vdCByZWplY3QgdG9rZW5zIHVzaW5nIOKAnGNpZOKAnSwg
dGhlcmUgYXJlIGxvdHMgb2Ygb3RoZXIgd2F5cyB0byBhY2NvbXBsaXNoIHRoaXMgdGhhdCBJIHRo
aW5rIHdlIHNob3VsZCBjb25zaWRlciBmaXJzdC4NCg0KLS0gTWlrZQ0KDQoNCkZyb206IEpvaG4g
QnJhZGxleQ0KU2VudDogRGVjZW1iZXIgMTksIDIwMTIgNjoyNSBQTQ0KVG86IEFudGhvbnkgTmFk
YWxpbg0KQ0M6IG9hdXRoDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSAiY2lkIiBjbGFpbSBpbiBK
V1QNCg0KSSBhZ3JlZSwgYXVkaWVuY2Ugd2hvIHJlcXVlc3RlZCBpdCBhbmQgYW5kIHdobyBpdCBp
cyByZXF1ZXN0ZWQgZm9yIGFyZSBhbGwgaW50ZXJyZWxhdGVkLg0KDQpIb3dldmVyIHdlIGRvIG5l
ZWQgdG8gc2V0IGRvd24gc29tZSBzdGFuZGFyZCB3YXkgb2YgZXhwcmVzc2luZyBpdCBhcyBwZW9w
bGUgYXJlIHN0YXJ0aW5nIHRvIG1ha2Ugc3R1ZmYgdXAgb24gdGhlaXIgb3duIHRoYXQgd2lsbCBp
bXBhY3QgaW50ZXJvcGVyYWJpbGl0eS4NCg0KSWYgR29vZ2xlIHN0YXJ0cyB0aGF3aW5nIGluIGNp
ZCBhbmQgY2xpZW50cyBkb24ndCBrbm93IGFib3V0IGl0IHRoZXkgbXVzdCByZWplY3QgdGhlIEpX
VCBldGMuDQoNCkpvaG4NCg0KT24gMjAxMi0xMi0xOSwgYXQgOTo0MCBQTSwgQW50aG9ueSBOYWRh
bGluIDx0b255bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+
IHdyb3RlOg0KDQpJdCBzZWVtcyBwcmVtYXR1cmUgYW5kIHdlIHNob3VsZCBjb25zaWRlciB0aGlz
IGluIHRoZSBiaWdnZXIgY29udGV4dCBvZiB0aGUg4oCcb24gYmVoYWxmIG9m4oCdL2RlbGVnYXRp
b24gd29yayB0aGF0IGhhcyBiZWVuIHN0YXJ0ZWQNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRm
Lm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC08bWFpbHRv
Om9hdXRoLT5ib3VuY2VzQGlldGYub3JnPG1haWx0bzpib3VuY2VzQGlldGYub3JnPl0gT24gQmVo
YWxmIE9mIE5hdCBTYWtpbXVyYQ0KU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMTgsIDIwMTIgNjoy
MiBQTQ0KVG86IG9hdXRoDQpTdWJqZWN0OiBbT0FVVEgtV0ddICJjaWQiIGNsYWltIGluIEpXVA0K
DQpJbiBPcGVuSUQgQ29ubmVjdCBXRywgd2UgaGF2ZSBiZWVuIHRhbGtpbmcgdGhpcyBmb3Igc29t
ZXRpbWUuDQoiY2lkIiBjbGFpbSBpZGVudGlmaWVzIHRoZSBlbnRpdHkgdGhhdCB0aGUgSldUIHdh
cyBpc3N1ZWQgdG8gYXMgYSByaWdodGZ1bC9saWNlbnNlZCB1c2VyLg0KR29vZ2xlIGFscmVhZHkg
dXNlcyB0aGlzIGluIHRoZWlyIGltcGxlbWVudGF0aW9uIG9mIGlkX3Rva2VuIG9mIE9JREMuDQoN
CkhlcmUgaXMgdGhlIHRleHQgcHJvcG9zYWwuIEl0IGludHJvZHVjZXMgdHdvIG5ldyBzdGFuZGFy
ZCBjbGFpbXM6ICJjaWQiIGFuZCAiY2l0Ii4NCg0KSXQgd291bGQgYmUgdmVyeSB1c2VmdWwgaW4g
Y3JlYXRpbmcgYSBIb0sgZHJhZnRzIGFzIHdlbGwuDQoNCkNoZWVycywNCg0KTmF0DQoNCg0KDQoN
CjQuMS45LiAiY2lkIiBDbGllbnQgSWRlbnRpZmljYXRpb24gRGF0YSBDbGFpbQ0KDQoNCg0KVGhl
ICJjaWQiIChjbGllbnQgaWRlbnRpZmljYXRpb24gZGF0YSkgY2xhaW0gYWxsb3dzIHRoZSByZWNl
aXZlcg0KDQpvZiB0aGUgSldUIHRvIGlkZW50aWZ5IHRoZSBlbnRpdHkgdGhhdCB0aGUgSldUIGlz
DQoNCmludGVuZGVkIHRvIGJlIHVzZWQgYnkuIFRoZSBhdWRpZW5jZSBvZiB0aGUgSldUIE1VU1Qg
YmUNCg0KYWJsZSB0byBpZGVudGlmeSB0aGUgY2xpZW50IHdpdGggdGhlIHZhbHVlIG9mIHRoaXMg
Y2xhaW0uDQoNCg0KDQpUaGUgImNpZCIgdmFsdWUgaXMgYSBjYXNlIHNlbnNpdGl2ZSBzdHJpbmcg
Y29udGFpbmluZyBhIFN0cmluZ09yVVJJIHZhbHVlLg0KDQpUaGlzIGNsYWltIGlzIE9QVElPTkFM
LiBJZiB0aGUgZW50aXR5IHByb2Nlc3NpbmcgdGhlIGNsYWltIGRvZXMgbm90DQoNCmlkZW50aWZ5
IHRoZSB1c2VyIG9mIHRoZSBKV1Qgd2l0aCB0aGUgaWRlbnRpZmllciBpbiB0aGUgImNpZCIgY2xh
aW0gdmFsdWUsDQoNCnRoZW4gdGhlIEpXVCBNVVNUIGJlIHJlamVjdGVkLiBUaGUgaW50ZXJwcmV0
YXRpb24gb2YgdGhlIHJlZ2lzdGVyZWQgdG8NCg0KdmFsdWUgaXMgZ2VuZXJhbGx5IGFwcGxpY2F0
aW9uIHNwZWNpZmljLg0KDQoNCg0KQSB0eXBpY2FsIGV4YW1wbGUgb2YgYSByZWdpc3RlcmVkIHRv
IGNsYWltIGluY2x1ZGVzIGZvbGxvd2luZzoNCg0KKiBjbGllbnRfaWQgdGhhdCB0aGUgYXVkaWVu
Y2UgY2FuIHVzZSB0byBhdXRoZW50aWNhdGUgYW5kDQoNCiAgaWRlbnRpZnkgdGhlIGNsaWVudC4N
Cg0KKiBBIGJhc2U2NHVybCBlbmNvZGVkIEpXSy4NCg0KKiBBIFVSTCB0aGF0IHBvaW50cyB0byB0
aGUga2V5IG1hdGVyaWFsIHRoYXQgdGhlIGF1ZGllbmNlIGNhbiB1c2UgdG8NCg0KICBhdXRoZW50
aWNhdGUgdGhlIHVzZXIgb2YgdGhlIEpXVC4NCg0KDQoNCjQuMS4xMCAiY2l0IiAoQ2xpZW50IElk
ZW50aWZpY2F0aW9uIERhdGEgY2xhaW0gdHlwZSkNCg0KDQoNClRoZSAiY2l0IiAoQ2xpZW50IElk
ZW50aWZpY2F0aW9uIERhdGEgY2xhaW0gdHlwZSkgaWRlbnRpZmllcyB0aGUgdHlwZQ0KDQpvZiB0
aGUgImNpZCIgY2xhaW0uIEl0IGlzIGEgU3RyaW5nT3JVUkkgdmFsdWUuIFRoZSBkZWZpbmVkIHZh
bHVlcw0KDQphcmUgdGhlIGZvbGxvd2luZzoNCg0KDQoNCiJjbGllbnRfaWQiIFRoZSB2YWx1ZSBv
ZiB0aGUgImNpZCIgY2xhaW0gaXMgdGhlIENsaWVudCBJRCBvZiB0aGUgY2xpZW50DQoNCnRoYXQg
dGhlIGF1ZGllbmNlIG9mIHRoZSBKV1QgaXMgYWJsZSB0byB1c2UgdG8gYXV0aGVudGljYXRlIHRo
ZSBjbGllbnQuDQoNCg0KDQoiandrIiBUaGUgdmFsdWUgb2YgdGhlICJjaWQiIGNsYWltIGlzIGEg
YmFzZTY0dXJsIGVuY29kZWQgSldLIG9mDQoNCnRoZSByZWdpc3RlcmVkIGNsaWVudC4NCg0KDQoN
CiJqa3UiIFRoZSB2YWx1ZSBvZiB0aGUgImNpZCIgY2xhaW0gaXMgdGhlICJqa3UiIGRlZmluZWQg
aW4gNC4xLjIgb2YNCg0KSlNPTiB3ZWIgc2lnbmF0dXJlIFtKV1NdLg0KDQoNCg0KIng1dSIgVGhl
IHZhbHVlIG9mIHRoZSAiY2lkIiBjbGFpbSBpcyB0aGUgVVJMIHRoYXQgcG9pbnRzIHRvIHRoZSBw
dWJsaWMNCg0Ka2V5IGNlcnRpZmljYXRlIG9mIHRoZSByZWdpc3RlcmVkIGNsaWVudC4gVGhlIGZv
cm1hdCBvZiB0aGUgY29udGVudA0KDQp0aGF0IHg1dSBwb2ludHMgdG8gaXMgZGVzY3JpYmVkIGlu
IHNlY3Rpb24gNC4xLjQgb2YgdGhlIEpTT04gV2ViIFNpZ25hdHVyZS4NCg0KDQotLQ0KTmF0IFNh
a2ltdXJhICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNh
a2ltdXJhLm9yZy8NCkBfbmF0X2VuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0
bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5v
cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQoN
Ci0tDQpOYXQgU2FraW11cmEgKD1uYXQpDQpDaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb24NCmh0
dHA6Ly9uYXQuc2FraW11cmEub3JnLw0KQF9uYXRfZW4NCg==

--_000_4E1F6AAD24975D4BA5B16804296739436697EF82TK5EX14MBXC283r_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSwmcXVvdDtTZWdvZSBVSSZxdW90OyxNZWlyeW8sJnF1b3Q7TWlj
cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90Oywm
cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O0tobWVyIFVJJnF1b3Q7LCZxdW90O05pcm1h
bGEgVUkmcXVvdDssVHVuZ2EsJnF1b3Q7TGFvIFVJJnF1b3Q7LEVicmltYSxzYW5zLXNlcmlmO2Zv
bnQtc2l6ZToxNnB4OyI+DQo8ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSI+V2hhdCB3
b3VsZCB0aGUgaXNzLCBwcm4sIGF1ZCwgYW5kIGNpZCB2YWx1ZXMgcmVwcmVzZW50IGluIHRoZSBi
b2FyZGluZyBwYXNzIGV4YW1wbGU/PC9kaXY+DQo8ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0i
dHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSI+LS0g
TWlrZTwvZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPiZuYnNwOzwvZGl2
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyOSwgMjI5LCAyMjkpOyBib3Jk
ZXItdG9wLXdpZHRoOiAycHg7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyIgZGF0YS1mb2N1c2Zy
b21wb2ludGVyPSJ0cnVlIj4NCjxzdHJvbmc+RnJvbTo8L3N0cm9uZz4mbmJzcDtOYXQgU2FraW11
cmE8YnI+DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+Jm5ic3A74oCORGVjZW1iZXLigI4g4oCOMTni
gI4sIOKAjjIwMTIg4oCOOeKAjjrigI4zMuKAjiDigI5QTTxicj4NCjxzdHJvbmc+VG86PC9zdHJv
bmc+Jm5ic3A7TWlrZSBKb25lczxicj4NCjxzdHJvbmc+Q0M6PC9zdHJvbmc+Jm5ic3A7QW50aG9u
eSBOYWRhbGluLCBKb2huIEJyYWRsZXksIG9hdXRoPGJyPg0KPHN0cm9uZz5TdWJqZWN0Ojwvc3Ry
b25nPiZuYnNwO1JlOiBbT0FVVEgtV0ddICZxdW90O2NpZCZxdW90OyBjbGFpbSBpbiBKV1Q8YnI+
DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQpJIG9idmlvdXNseSBkaXNhZ3JlZSAtIGlmIEkg
ZGlkIGFncmVlLCBJIGRpZCBub3Qgc2VuZCBpdCB0byB0aGUgbGlzdCB0byBzdGFydCB3aXRoIDot
KQ0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+JnF1b3Q7Y2lkJnF1b3Q7IChvciBpbiBteSBvcmln
aW5hbCBwcm9wb3NhbCwgJnF1b3Q7cmVnJnF1b3Q7KSBoYXMgYSB2ZXJ5IGNsZWFyIGFuZCBlc3Rh
Ymxpc2hlZCBtZWFuaW5nLiZuYnNwOzwvZGl2Pg0KPGRpdj5UaGUgcGFyYWxsZWwgZXhhbXBsZXMg
YWJvdW5kcyBpbiBvdXIgZGFpbHkgbGlmZS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+
DQo8ZGl2Pkl0IGhhcyB2ZXJ5IGxpdHRsZSB0byBkbyB3aXRoIE9uLWJlaGFsZi1vZi4mbmJzcDs8
L2Rpdj4NCjxkaXY+SXQgaXMgbm90IGEgZGVsZWdhdGlvbiBzdGF0ZW1lbnQuJm5ic3A7PC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4mcXVvdDtjaWQmcXVvdDsgaXMgdGhlcmUgdG8gaW5k
aWNhdGUgdG8gd2hvbSBpdCB3YXMgaXNzdWVkIHRvLiZuYnNwOzwvZGl2Pg0KPGRpdiBkYXRhLWZv
Y3VzZnJvbXBvaW50ZXI9InRydWUiPlRoZSBlbnRpdHkgd2hvIHdhcyBpc3N1ZWQgdGhpcyAmcXVv
dDt0b2tlbiZxdW90OyBpcyBlbGlnaWJsZSB0byB1c2UgaXQgYXQgdGhlJm5ic3A7PC9kaXY+DQo8
ZGl2PmVudGl0aWVzIGluZGljYXRlZCBieSAmcXVvdDthdWQmcXVvdDsuJm5ic3A7PC9kaXY+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5FeGFtcGxlIGluIG91ciByZWFsIGxpZmUgYXJlIGxpa2U6
Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIEFpcmxpbmUgYm9hcmRpbmcg
cGFzczwvZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPi0gUmVnaXN0ZXJl
ZCBpbnN0cnVtZW50cyAoYm9uZCAvIHNoYXJlKSZuYnNwOzwvZGl2Pg0KPGRpdj4tIE1vbnRobHkg
dHJhaW4gcGFzczwvZGl2Pg0KPGRpdj4tIERpc25leWxhbmQgYW5udWFsIHBhc3Nwb3J0PC9kaXY+
DQo8ZGl2PiZuYnNwO2V0Yy4gZXRjLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk
aXY+UGxlYXNlIGRvIG5vdCBtaXggaXQgdXAgd2l0aCBhIGRlbGVnYXRpb24gc3RhdGVtZW50IGxp
a2Ugb24tYmVoYWxmLW9mLCZuYnNwOzwvZGl2Pg0KPGRpdj53aGljaCBpcyBtdWNoIGxlc3Mgd2Vs
bCBkZWZpbmVkLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TmF0PC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9x
dW90ZSI+T24gVGh1LCBEZWMgMjAsIDIwMTIgYXQgMTI6MDcgUE0sIE1pa2UgSm9uZXMgPHNwYW4g
ZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5j
b20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+
DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHgg
MHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQs
IDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNv
bGlkOyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksJnF1b3Q7U2Vn
b2UgVUkmcXVvdDssTWVpcnlvLCZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OywmcXVvdDtN
aWNyb3NvZnQgSmhlbmdIZWkgVUkmcXVvdDssJnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90OywmcXVv
dDtLaG1lciBVSSZxdW90OywmcXVvdDtOaXJtYWxhIFVJJnF1b3Q7LFR1bmdhLCZxdW90O0xhbyBV
SSZxdW90OyxFYnJpbWEsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNnB4OyI+DQo8ZGl2PkknbSB3
aXRoIFRvbnkgb24gdGhpcy4mbmJzcDsgVGhpcyBzZWVtcyBwcmVtYXR1cmUgdG8gcHV0IGludG8g
dGhlIEpXVCBzdGFuZGFyZC4mbmJzcDsgQWxsIHRoZSBvdGhlciBKV1QgY2xhaW1zIGhhdmUgd2Vs
bCBlc3RhYmxpc2hlZCBtZWFuaW5ncyBhbmQgaGlzdG9yeSBiZWhpbmQgdGhlbS4mbmJzcDsgVGhl
c2UgZG9uJ3QuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JZiB0aGUgZ29hbCBpcyB0
byBhbGxvdyBPcGVuSUQgQ29ubmVjdCBpbXBsZW1lbnRhdGlvbnMgdG8gbm90IHJlamVjdCB0b2tl
bnMgdXNpbmcmbmJzcDvigJxjaWTigJ0sIHRoZXJlIGFyZSBsb3RzIG9mIG90aGVyIHdheXMgdG8g
YWNjb21wbGlzaCB0aGlzIHRoYXQgSSB0aGluayB3ZSBzaG91bGQgY29uc2lkZXIgZmlyc3QuPC9k
aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4tLSBNaWtlPC9kaXY+DQo8ZGl2PiZuYnNwOzwv
ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci10b3AtY29sb3I6IHJn
YigyMjksIDIyOSwgMjI5KTsgYm9yZGVyLXRvcC13aWR0aDogMnB4OyBib3JkZXItdG9wLXN0eWxl
OiBzb2xpZDsiPg0KPHN0cm9uZz5Gcm9tOjwvc3Ryb25nPiZuYnNwO0pvaG4gQnJhZGxleTxicj4N
CjxzdHJvbmc+U2VudDo8L3N0cm9uZz4mbmJzcDtEZWNlbWJlciAxOSwgMjAxMiA2OjI1IFBNPGJy
Pg0KPHN0cm9uZz5Ubzo8L3N0cm9uZz4mbmJzcDtBbnRob255IE5hZGFsaW48YnI+DQo8c3Ryb25n
PkNDOjwvc3Ryb25nPiZuYnNwO29hdXRoPGJyPg0KPHN0cm9uZz5TdWJqZWN0Ojwvc3Ryb25nPiZu
YnNwO1JlOiBbT0FVVEgtV0ddICZxdW90O2NpZCZxdW90OyBjbGFpbSBpbiBKV1Q8YnI+DQo8L2Rp
dj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KSSBhZ3JlZSwg
YXVkaWVuY2Ugd2hvIHJlcXVlc3RlZCBpdCBhbmQgYW5kIHdobyBpdCBpcyByZXF1ZXN0ZWQgZm9y
IGFyZSBhbGwgaW50ZXJyZWxhdGVkLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SG93ZXZlciB3
ZSBkbyBuZWVkIHRvIHNldCBkb3duIHNvbWUgc3RhbmRhcmQgd2F5IG9mIGV4cHJlc3NpbmcgaXQg
YXMgcGVvcGxlIGFyZSBzdGFydGluZyB0byBtYWtlIHN0dWZmIHVwIG9uIHRoZWlyIG93biB0aGF0
IHdpbGwgaW1wYWN0IGludGVyb3BlcmFiaWxpdHkuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PGRpdj5JZiBHb29nbGUgc3RhcnRzIHRoYXdpbmcgaW4gY2lkIGFuZCBjbGllbnRzIGRvbid0IGtu
b3cgYWJvdXQgaXQgdGhleSBtdXN0IHJlamVjdCB0aGUgSldUIGV0Yy48L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2PkpvaG48L2Rpdj4NCjxkaXY+PGJyPg0KPGRpdj4NCjxkaXY+T24gMjAx
Mi0xMi0xOSwgYXQgOTo0MCBQTSwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86
dG9ueW5hZEBtaWNyb3NvZnQuY29tIj50b255bmFkQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90
ZTo8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlPg0KPGRpdiBsYW5nPSJFTi1VUyIgc3R5bGU9InRl
eHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9y
bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPg0KPGRpdj4NCjxk
aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPHNwYW4gc3R5bGU9ImNv
bG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNlcmlmOyBm
b250LXNpemU6IDExcHQ7Ij5JdCBzZWVtcyBwcmVtYXR1cmUgYW5kIHdlIHNob3VsZCBjb25zaWRl
ciB0aGlzIGluIHRoZSBiaWdnZXIgY29udGV4dCBvZiB0aGUg4oCcb24gYmVoYWxmIG9m4oCdL2Rl
bGVnYXRpb24gd29yayB0aGF0IGhhcyBiZWVuIHN0YXJ0ZWQ8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJv
bWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjxhIG5hbWU9IjEzYmI2NDdmODFk
NWZhMjFfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEy
NSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPiZu
YnNwOzwvc3Bhbj48L2E+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBm
b250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6
IDEycHQ7Ij4NCjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNlcmlm
OyBmb250LXNpemU6IDExcHQ7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiBDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuPiZuYnNwOzwv
c3Bhbj48YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNl
c0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtIj5vYXV0aC08L2E+
PGEgaHJlZj0ibWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmciPmJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxz
cGFuPiZuYnNwOzwvc3Bhbj48Yj5Pbg0KIEJlaGFsZiBPZjxzcGFuPiZuYnNwOzwvc3Bhbj48L2I+
TmF0IFNha2ltdXJhPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4+Jm5ic3A7PC9zcGFuPlR1ZXNkYXks
IERlY2VtYmVyIDE4LCAyMDEyIDY6MjIgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4+Jm5ic3A7PC9z
cGFuPm9hdXRoPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4+Jm5ic3A7PC9zcGFuPltPQVVUSC1X
R10gJnF1b3Q7Y2lkJnF1b3Q7IGNsYWltIGluIEpXVDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9
Im1hcmdpbjogMGluIDBpbiAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFu
JnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCkluIE9wZW5JRCBDb25uZWN0IFdHLCB3
ZSBoYXZlIGJlZW4gdGFsa2luZyB0aGlzIGZvciBzb21ldGltZS4mbmJzcDs8L2Rpdj4NCjxkaXY+
DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGlt
ZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCiZxdW90O2NpZCZx
dW90OyBjbGFpbSBpZGVudGlmaWVzIHRoZSBlbnRpdHkgdGhhdCB0aGUgSldUIHdhcyBpc3N1ZWQg
dG8gYXMgYSByaWdodGZ1bC9saWNlbnNlZCB1c2VyLiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1Rp
bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQpHb29nbGUgYWxy
ZWFkeSB1c2VzIHRoaXMgaW4gdGhlaXIgaW1wbGVtZW50YXRpb24gb2YgaWRfdG9rZW4gb2YgT0lE
Qy4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp
biAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZv
bnQtc2l6ZTogMTJwdDsiPg0KJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl
PSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFu
JnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCkhlcmUgaXMgdGhlIHRleHQgcHJvcG9z
YWwuIEl0IGludHJvZHVjZXMgdHdvIG5ldyBzdGFuZGFyZCBjbGFpbXM6ICZxdW90O2NpZCZxdW90
OyBhbmQgJnF1b3Q7Y2l0JnF1b3Q7LiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQombmJzcDs8L2Rpdj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGxpbmUtaGVpZ2h0OiAx
NXB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250
LXNpemU6IDEycHQ7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250
LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMC41cHQ7Ij5JdCB3b3VsZCBi
ZSB2ZXJ5IHVzZWZ1bCBpbiBjcmVhdGluZyBhIEhvSyBkcmFmdHMgYXMgd2VsbC4mbmJzcDs8L3Nw
YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBsaW5lLWhlaWdodDog
MTVwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9u
dC1zaXplOiAxMnB0OyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9u
dC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+Jm5ic3A7PC9z
cGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgbGluZS1oZWlnaHQ6
IDE1cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZv
bnQtc2l6ZTogMTJwdDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZv
bnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsiPkNoZWVycywm
bmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBsaW5l
LWhlaWdodDogMTVwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz
ZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEs
IDUxKTsgZm9udC1mYW1pbHk6IEFyaWFsLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+
Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBwdDsgbGlu
ZS1oZWlnaHQ6IDE1cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss
c2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUx
LCA1MSk7IGZvbnQtZmFtaWx5OiBBcmlhbCxzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsi
Pk5hdDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGxpbmUt
aGVpZ2h0OiAxNXB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl
cmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwg
NTEpOyBmb250LWZhbWlseTogQXJpYWwsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMC41cHQ7Ij4m
bmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZzogN3B0IDlwdDsg
Ym9yZGVyOiAxcHQgc29saWQgcmdiKDIwNCwgMjA0LCAyMDQpOyBiYWNrZ3JvdW5kLWNvbG9yOiBy
Z2IoMjQ1LCAyNDUsIDI0NSk7Ij4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7
IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0
NSwgMjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6
IDlwdDsiPiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2
Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigy
NDUsIDI0NSwgMjQ1KTsiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBm
b250LXNpemU6IDlwdDsiPjQ8c3Bhbj4uPC9zcGFuPjE8c3Bhbj4uPC9zcGFuPjk8c3Bhbj4uPC9z
cGFuPiAmcXVvdDs8c3Bhbj5jaWQ8L3NwYW4+JnF1b3Q7IDxzcGFuPkNsaWVudDwvc3Bhbj4gPHNw
YW4+SWRlbnRpZmljYXRpb248L3NwYW4+IDxzcGFuPkRhdGE8L3NwYW4+IDxzcGFuPkNsYWltPC9z
cGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQt
c2l6ZTogOXB0OyI+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYu
NzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291
cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0
NSwgMjQ1LCAyNDUpOyI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQt
c2l6ZTogOXB0OyI+Jm5ic3A7PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1
b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjog
cmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUx
LCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+VGhlPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s
b3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4gJnF1b3Q7PHNwYW4+Y2lkPC9z
cGFuPiZxdW90OyA8c3Bhbj4oPC9zcGFuPjxzcGFuPmNsaWVudDwvc3Bhbj4gPHNwYW4+aWRlbnRp
ZmljYXRpb248L3NwYW4+IDxzcGFuPmRhdGE8L3NwYW4+PHNwYW4+KTwvc3Bhbj4gPHNwYW4+Y2xh
aW08L3NwYW4+IDxzcGFuPmFsbG93czwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFuPiA8c3Bhbj5yZWNl
aXZlcjwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYu
NzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291
cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0
NSwgMjQ1LCAyNDUpOyI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7
IGZvbnQtc2l6ZTogOXB0OyI+b2Y8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi
KDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiA8c3Bhbj50aGU8L3NwYW4+IDxzcGFuPkpX
VDwvc3Bhbj4gPHNwYW4+dG88L3NwYW4+IDxzcGFuPmlkZW50aWZ5PC9zcGFuPiA8c3Bhbj50aGU8
L3NwYW4+IDxzcGFuPmVudGl0eTwvc3Bhbj4gPHNwYW4+dGhhdDwvc3Bhbj4gPHNwYW4+dGhlPC9z
cGFuPiA8c3Bhbj5KV1Q8L3NwYW4+IDxzcGFuPmlzPC9zcGFuPiA8L3NwYW4+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxh
Y2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0
OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3Bhbj48c3BhbiBzdHls
ZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij5pbnRlbmRlZDwvc3Bh
bj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTog
OXB0OyI+IDxzcGFuPnRvPC9zcGFuPiA8c3Bhbj5iZTwvc3Bhbj4gPHNwYW4+dXNlZDwvc3Bhbj4g
PHNwYW4+Ynk8L3NwYW4+PHNwYW4+Ljwvc3Bhbj4gPHNwYW4+VGhlPC9zcGFuPiA8c3Bhbj5hdWRp
ZW5jZTwvc3Bhbj4gPHNwYW4+b2Y8L3NwYW4+IDxzcGFuPnRoZTwvc3Bhbj4gPHNwYW4+SldUPC9z
cGFuPiA8c3Bhbj5NVVNUPC9zcGFuPiA8c3Bhbj5iZTwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHBy
ZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJs
YWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBw
dDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4+PHNwYW4gc3R5
bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+YWJsZTwvc3Bhbj48
L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0
OyI+IDxzcGFuPnRvPC9zcGFuPiA8c3Bhbj5pZGVudGlmeTwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFu
PiA8c3Bhbj5jbGllbnQ8L3NwYW4+IDxzcGFuPndpdGg8L3NwYW4+IDxzcGFuPnRoZTwvc3Bhbj4g
PHNwYW4+dmFsdWU8L3NwYW4+IDxzcGFuPm9mPC9zcGFuPiA8c3Bhbj50aGlzPC9zcGFuPiA8c3Bh
bj5jbGFpbTwvc3Bhbj48c3Bhbj4uPC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1m
YW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91
bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUx
LCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsg
Zm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJh
Y2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuPjxzcGFuIHN0eWxlPSJj
b2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPlRoZTwvc3Bhbj48L3NwYW4+
PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+ICZx
dW90OzxzcGFuPmNpZDwvc3Bhbj4mcXVvdDsgPHNwYW4+dmFsdWU8L3NwYW4+IDxzcGFuPmlzPC9z
cGFuPiA8c3Bhbj5hPC9zcGFuPiA8L3NwYW4+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io
MCwgNjQsIDEyOCk7IGZvbnQtc2l6ZTogOXB0OyI+Y2FzZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5
bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+IDxzcGFuPnNlbnNp
dGl2ZTwvc3Bhbj4gPHNwYW4+c3RyaW5nPC9zcGFuPiA8c3Bhbj5jb250YWluaW5nPC9zcGFuPiA8
c3Bhbj5hPC9zcGFuPiA8c3Bhbj5TdHJpbmdPclVSSTwvc3Bhbj4gPHNwYW4+dmFsdWU8L3NwYW4+
PHNwYW4+Ljwvc3Bhbj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g
Ni43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtD
b3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2Io
MjQ1LCAyNDUsIDI0NSk7Ij48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUx
KTsgZm9udC1zaXplOiA5cHQ7Ij5UaGlzPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6
IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4gPHNwYW4+Y2xhaW08L3NwYW4+IDxz
cGFuPmlzPC9zcGFuPiA8c3Bhbj5PUFRJT05BTDwvc3Bhbj48c3Bhbj4uPC9zcGFuPiA8c3Bhbj5J
Zjwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFuPiA8c3Bhbj5lbnRpdHk8L3NwYW4+IDxzcGFuPnByb2Nl
c3Npbmc8L3NwYW4+IDxzcGFuPnRoZTwvc3Bhbj4gPHNwYW4+Y2xhaW08L3NwYW4+IDxzcGFuPmRv
ZXM8L3NwYW4+IDxzcGFuPm5vdDwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy
Z2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZh
bWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3Vu
ZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiBy
Z2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+aWRlbnRpZnk8L3NwYW4+PC9zcGFuPjxz
cGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiA8c3Bh
bj50aGU8L3NwYW4+IDxzcGFuPnVzZXI8L3NwYW4+IDxzcGFuPm9mPC9zcGFuPiA8c3Bhbj50aGU8
L3NwYW4+IDxzcGFuPkpXVDwvc3Bhbj4gPHNwYW4+d2l0aDwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFu
PiA8c3Bhbj5pZGVudGlmaWVyPC9zcGFuPiA8c3Bhbj5pbjwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFu
PiAmcXVvdDs8c3Bhbj5jaWQ8L3NwYW4+JnF1b3Q7IDxzcGFuPmNsYWltPC9zcGFuPiA8c3Bhbj52
YWx1ZTwvc3Bhbj48c3Bhbj4sPC9zcGFuPiA8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn
aW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFt
aWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5k
LWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJn
Yig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij50aGVuPC9zcGFuPjwvc3Bhbj48c3BhbiBz
dHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4gPHNwYW4+dGhl
PC9zcGFuPiA8c3Bhbj5KV1Q8L3NwYW4+IDxzcGFuPk1VU1Q8L3NwYW4+IDxzcGFuPmJlPC9zcGFu
PiA8c3Bhbj5yZWplY3RlZDwvc3Bhbj48c3Bhbj4uPC9zcGFuPiA8c3Bhbj5UaGU8L3NwYW4+IDxz
cGFuPmludGVycHJldGF0aW9uPC9zcGFuPiA8c3Bhbj5vZjwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFu
PiA8c3Bhbj5yZWdpc3RlcmVkPC9zcGFuPiA8c3Bhbj50bzwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0K
PHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6
IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTog
MTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4+PHNwYW4g
c3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+dmFsdWU8L3Nw
YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6
IDlwdDsiPiA8c3Bhbj5pczwvc3Bhbj4gPHNwYW4+Z2VuZXJhbGx5PC9zcGFuPiA8c3Bhbj5hcHBs
aWNhdGlvbjwvc3Bhbj4gPHNwYW4+c3BlY2lmaWM8L3NwYW4+PHNwYW4+Ljwvc3Bhbj48L3NwYW4+
PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47
IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9u
dC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3Bh
biBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4mbmJzcDs8
L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5n
OiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90
OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7
Ij48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5
cHQ7Ij5BPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsg
Zm9udC1zaXplOiA5cHQ7Ij4gPHNwYW4+dHlwaWNhbDwvc3Bhbj4gPHNwYW4+ZXhhbXBsZTwvc3Bh
bj4gPHNwYW4+b2Y8L3NwYW4+IDxzcGFuPmE8L3NwYW4+IDxzcGFuPnJlZ2lzdGVyZWQ8L3NwYW4+
IDxzcGFuPnRvPC9zcGFuPiA8c3Bhbj5jbGFpbTwvc3Bhbj4gPHNwYW4+aW5jbHVkZXM8L3NwYW4+
IDxzcGFuPmZvbGxvd2luZzwvc3Bhbj48c3Bhbj46PC9zcGFuPiA8L3NwYW4+PC9wcmU+DQo8cHJl
IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxh
Y2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0
OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3Bhbj48c3BhbiBzdHls
ZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4qPC9zcGFuPjwvc3Bh
bj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4g
PHNwYW4+Y2xpZW50X2lkPC9zcGFuPiA8c3Bhbj50aGF0PC9zcGFuPiA8c3Bhbj50aGU8L3NwYW4+
IDxzcGFuPmF1ZGllbmNlPC9zcGFuPiA8c3Bhbj5jYW48L3NwYW4+IDxzcGFuPnVzZTwvc3Bhbj4g
PHNwYW4+dG88L3NwYW4+IDxzcGFuPmF1dGhlbnRpY2F0ZTwvc3Bhbj4gPHNwYW4+YW5kPC9zcGFu
PiA8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRk
aW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZx
dW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0
NSk7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7
Ij4mbmJzcDsmbmJzcDs8c3Bhbj5pZGVudGlmeTwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFuPiA8c3Bh
bj5jbGllbnQ8L3NwYW4+PHNwYW4+Ljwvc3Bhbj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQt
ZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3Jv
dW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6
IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4qPC9zcGFuPjwvc3Bhbj48c3BhbiBz
dHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4gPHNwYW4+QTwv
c3Bhbj4gPHNwYW4+YmFzZTY0dXJsPC9zcGFuPiA8c3Bhbj5lbmNvZGVkPC9zcGFuPiA8c3Bhbj5K
V0s8L3NwYW4+PHNwYW4+Ljwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu
OiAwaW4gMGluIDYuNzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWls
eTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1j
b2xvcjogcmdiKDI0NSwgMjQ1LCAyNDUpOyI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io
NTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+Kjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9
ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+IDxzcGFuPkE8L3NwYW4+
IDxzcGFuPlVSTDwvc3Bhbj4gPHNwYW4+dGhhdDwvc3Bhbj4gPHNwYW4+cG9pbnRzPC9zcGFuPiA8
c3Bhbj50bzwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFuPiA8c3Bhbj5rZXk8L3NwYW4+IDxzcGFuPm1h
dGVyaWFsPC9zcGFuPiA8c3Bhbj50aGF0PC9zcGFuPiA8c3Bhbj50aGU8L3NwYW4+IDxzcGFuPmF1
ZGllbmNlPC9zcGFuPiA8c3Bhbj5jYW48L3NwYW4+IDxzcGFuPnVzZTwvc3Bhbj4gPHNwYW4+dG88
L3NwYW4+IDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7
IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIg
TmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0
NSwgMjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6
IDlwdDsiPiZuYnNwOyZuYnNwOzxzcGFuPmF1dGhlbnRpY2F0ZTwvc3Bhbj4gPHNwYW4+dGhlPC9z
cGFuPiA8c3Bhbj51c2VyPC9zcGFuPiA8c3Bhbj5vZjwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFuPiA8
c3Bhbj5KV1Q8L3NwYW4+PHNwYW4+Ljwvc3Bhbj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt
YXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQt
ZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3Jv
dW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1
MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4mbmJzcDs8L3NwYW4+PC9wcmU+DQo8cHJlIHN0
eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7
IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBi
YWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0NSk7Ij48Yj48c3BhbiBzdHlsZT0iY29s
b3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij40PHNwYW4+Ljwvc3Bhbj4xPHNw
YW4+Ljwvc3Bhbj4xMCAmcXVvdDs8c3Bhbj5jaXQ8L3NwYW4+JnF1b3Q7IDxzcGFuPig8L3NwYW4+
PHNwYW4+Q2xpZW50PC9zcGFuPiA8c3Bhbj5JZGVudGlmaWNhdGlvbjwvc3Bhbj4gPHNwYW4+RGF0
YTwvc3Bhbj4gPHNwYW4+Y2xhaW08L3NwYW4+IDxzcGFuPnR5cGU8L3NwYW4+PHNwYW4+KTwvc3Bh
bj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNp
emU6IDlwdDsiPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1
cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJp
ZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUs
IDI0NSwgMjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNp
emU6IDlwdDsiPiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBp
biA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90
O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJn
YigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwg
NTEpOyBmb250LXNpemU6IDlwdDsiPlRoZTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y
OiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+ICZxdW90OzxzcGFuPmNpdDwvc3Bh
bj4mcXVvdDsgPHNwYW4+KDwvc3Bhbj48c3Bhbj5DbGllbnQ8L3NwYW4+IDxzcGFuPklkZW50aWZp
Y2F0aW9uPC9zcGFuPiA8c3Bhbj5EYXRhPC9zcGFuPiA8c3Bhbj5jbGFpbTwvc3Bhbj4gPHNwYW4+
dHlwZTwvc3Bhbj48c3Bhbj4pPC9zcGFuPiA8c3Bhbj5pZGVudGlmaWVzPC9zcGFuPiA8c3Bhbj50
aGU8L3NwYW4+IDxzcGFuPnR5cGU8L3NwYW4+IDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1m
YW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91
bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjog
cmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPm9mPC9zcGFuPjwvc3Bhbj48c3BhbiBz
dHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4gPHNwYW4+dGhl
PC9zcGFuPiAmcXVvdDs8c3Bhbj5jaWQ8L3NwYW4+JnF1b3Q7IDxzcGFuPmNsYWltPC9zcGFuPjxz
cGFuPi48L3NwYW4+IDxzcGFuPkl0PC9zcGFuPiA8c3Bhbj5pczwvc3Bhbj4gPHNwYW4+YTwvc3Bh
bj4gPHNwYW4+U3RyaW5nT3JVUkk8L3NwYW4+IDxzcGFuPnZhbHVlPC9zcGFuPjxzcGFuPi48L3Nw
YW4+IDxzcGFuPlRoZTwvc3Bhbj4gPHNwYW4+ZGVmaW5lZDwvc3Bhbj4gPHNwYW4+dmFsdWVzPC9z
cGFuPiA8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBw
YWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5l
dyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUs
IDI0NSk7Ij48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1z
aXplOiA5cHQ7Ij5hcmU8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1
MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiA8c3Bhbj50aGU8L3NwYW4+IDxzcGFuPmZvbGxvd2lu
Zzwvc3Bhbj48c3Bhbj46PC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjog
MGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6
ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29s
b3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwg
NTEpOyBmb250LXNpemU6IDlwdDsiPiZuYnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h
cmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1m
YW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91
bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUx
LCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiZxdW90OzxzcGFuPmNsaWVudF9pZDwvc3Bhbj4m
cXVvdDsgPHNwYW4+VGhlPC9zcGFuPiA8c3Bhbj52YWx1ZTwvc3Bhbj4gPHNwYW4+b2Y8L3NwYW4+
IDxzcGFuPnRoZTwvc3Bhbj4gJnF1b3Q7PHNwYW4+Y2lkPC9zcGFuPiZxdW90OyA8c3Bhbj5jbGFp
bTwvc3Bhbj4gPHNwYW4+aXM8L3NwYW4+IDxzcGFuPnRoZTwvc3Bhbj4gPHNwYW4+Q2xpZW50PC9z
cGFuPiA8c3Bhbj5JRDwvc3Bhbj4gPHNwYW4+b2Y8L3NwYW4+IDxzcGFuPnRoZTwvc3Bhbj4gPHNw
YW4+Y2xpZW50PC9zcGFuPiA8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAw
aW4gNi43NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVv
dDtDb3VyaWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiBy
Z2IoMjQ1LCAyNDUsIDI0NSk7Ij48c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEs
IDUxKTsgZm9udC1zaXplOiA5cHQ7Ij50aGF0PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s
b3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7Ij4gPHNwYW4+dGhlPC9zcGFuPiA8
c3Bhbj5hdWRpZW5jZTwvc3Bhbj4gPHNwYW4+b2Y8L3NwYW4+IDxzcGFuPnRoZTwvc3Bhbj4gPHNw
YW4+SldUPC9zcGFuPiA8c3Bhbj5pczwvc3Bhbj4gPHNwYW4+YWJsZTwvc3Bhbj4gPHNwYW4+dG88
L3NwYW4+IDxzcGFuPnVzZTwvc3Bhbj4gPHNwYW4+dG88L3NwYW4+IDxzcGFuPmF1dGhlbnRpY2F0
ZTwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFuPiA8c3Bhbj5jbGllbnQ8L3NwYW4+PHNwYW4+Ljwvc3Bh
bj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBwYWRk
aW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZx
dW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUsIDI0
NSk7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5cHQ7
Ij4mbmJzcDs8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0
OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVy
IE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAy
NDUsIDI0NSk7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXpl
OiA5cHQ7Ij4mcXVvdDs8c3Bhbj5qd2s8L3NwYW4+JnF1b3Q7IDxzcGFuPlRoZTwvc3Bhbj4gPHNw
YW4+dmFsdWU8L3NwYW4+IDxzcGFuPm9mPC9zcGFuPiA8c3Bhbj50aGU8L3NwYW4+ICZxdW90Ozxz
cGFuPmNpZDwvc3Bhbj4mcXVvdDsgPHNwYW4+Y2xhaW08L3NwYW4+IDxzcGFuPmlzPC9zcGFuPiA8
c3Bhbj5hPC9zcGFuPiA8c3Bhbj5iYXNlNjR1cmw8L3NwYW4+IDxzcGFuPmVuY29kZWQ8L3NwYW4+
IDxzcGFuPkpXSzwvc3Bhbj4gPHNwYW4+b2Y8L3NwYW4+IDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5
bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsg
Zm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJh
Y2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsiPjxzcGFuPjxzcGFuIHN0eWxlPSJj
b2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPnRoZTwvc3Bhbj48L3NwYW4+
PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+IDxz
cGFuPnJlZ2lzdGVyZWQ8L3NwYW4+IDxzcGFuPmNsaWVudDwvc3Bhbj48c3Bhbj4uPC9zcGFuPjwv
c3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBhZGRpbmc6
IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwgMjQ1KTsi
PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiZu
YnNwOzwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2Ljc1cHQ7IHBh
ZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNDUsIDI0NSwg
MjQ1KTsiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlw
dDsiPiZxdW90OzxzcGFuPmprdTwvc3Bhbj4mcXVvdDsgPHNwYW4+VGhlPC9zcGFuPiA8c3Bhbj52
YWx1ZTwvc3Bhbj4gPHNwYW4+b2Y8L3NwYW4+IDxzcGFuPnRoZTwvc3Bhbj4gJnF1b3Q7PHNwYW4+
Y2lkPC9zcGFuPiZxdW90OyA8c3Bhbj5jbGFpbTwvc3Bhbj4gPHNwYW4+aXM8L3NwYW4+IDxzcGFu
PnRoZTwvc3Bhbj4gJnF1b3Q7PHNwYW4+amt1PC9zcGFuPiZxdW90OyA8c3Bhbj5kZWZpbmVkPC9z
cGFuPiA8c3Bhbj5pbjwvc3Bhbj4gNDxzcGFuPi48L3NwYW4+MTxzcGFuPi48L3NwYW4+MiA8c3Bh
bj5vZjwvc3Bhbj4gPC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDYu
NzVwdDsgcGFkZGluZzogMGluOyBib3JkZXI6IGJsYWNrOyBmb250LWZhbWlseTogJnF1b3Q7Q291
cmllciBOZXcmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0
NSwgMjQ1LCAyNDUpOyI+PHNwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7
IGZvbnQtc2l6ZTogOXB0OyI+SlNPTjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiBy
Z2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+IDxzcGFuPndlYjwvc3Bhbj4gPHNwYW4+
c2lnbmF0dXJlPC9zcGFuPiA8c3Bhbj5bPC9zcGFuPjxzcGFuPkpXUzwvc3Bhbj48c3Bhbj5dLjwv
c3Bhbj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43NXB0OyBw
YWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5l
dyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1LCAyNDUs
IDI0NSk7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1zaXplOiA5
cHQ7Ij4mbmJzcDs8L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gNi43
NXB0OyBwYWRkaW5nOiAwaW47IGJvcmRlcjogYmxhY2s7IGZvbnQtZmFtaWx5OiAmcXVvdDtDb3Vy
aWVyIE5ldyZxdW90OzsgZm9udC1zaXplOiAxMHB0OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjQ1
LCAyNDUsIDI0NSk7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig1MSwgNTEsIDUxKTsgZm9udC1z
aXplOiA5cHQ7Ij4mcXVvdDs8c3Bhbj54NXU8L3NwYW4+JnF1b3Q7IDxzcGFuPlRoZTwvc3Bhbj4g
PHNwYW4+dmFsdWU8L3NwYW4+IDxzcGFuPm9mPC9zcGFuPiA8c3Bhbj50aGU8L3NwYW4+ICZxdW90
OzxzcGFuPmNpZDwvc3Bhbj4mcXVvdDsgPHNwYW4+Y2xhaW08L3NwYW4+IDxzcGFuPmlzPC9zcGFu
PiA8c3Bhbj50aGU8L3NwYW4+IDxzcGFuPlVSTDwvc3Bhbj4gPHNwYW4+dGhhdDwvc3Bhbj4gPHNw
YW4+cG9pbnRzPC9zcGFuPiA8c3Bhbj50bzwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFuPiA8c3Bhbj5w
dWJsaWM8L3NwYW4+IDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2
Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigy
NDUsIDI0NSwgMjQ1KTsiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEp
OyBmb250LXNpemU6IDlwdDsiPmtleTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiBy
Z2IoNTEsIDUxLCA1MSk7IGZvbnQtc2l6ZTogOXB0OyI+IDxzcGFuPmNlcnRpZmljYXRlPC9zcGFu
PiA8c3Bhbj5vZjwvc3Bhbj4gPHNwYW4+dGhlPC9zcGFuPiA8c3Bhbj5yZWdpc3RlcmVkPC9zcGFu
PiA8c3Bhbj5jbGllbnQ8L3NwYW4+PHNwYW4+Ljwvc3Bhbj4gPHNwYW4+VGhlPC9zcGFuPiA8c3Bh
bj5mb3JtYXQ8L3NwYW4+IDxzcGFuPm9mPC9zcGFuPiA8c3Bhbj50aGU8L3NwYW4+IDxzcGFuPmNv
bnRlbnQ8L3NwYW4+IDwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGluIDBpbiA2
Ljc1cHQ7IHBhZGRpbmc6IDBpbjsgYm9yZGVyOiBibGFjazsgZm9udC1mYW1pbHk6ICZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigy
NDUsIDI0NSwgMjQ1KTsiPjxzcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDUxLCA1MSwgNTEp
OyBmb250LXNpemU6IDlwdDsiPnRoYXQ8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjog
cmdiKDUxLCA1MSwgNTEpOyBmb250LXNpemU6IDlwdDsiPiA8c3Bhbj54NXU8L3NwYW4+IDxzcGFu
PnBvaW50czwvc3Bhbj4gPHNwYW4+dG88L3NwYW4+IDxzcGFuPmlzPC9zcGFuPiA8c3Bhbj5kZXNj
cmliZWQ8L3NwYW4+IDxzcGFuPmluPC9zcGFuPiA8c3Bhbj5zZWN0aW9uPC9zcGFuPiA0PHNwYW4+
Ljwvc3Bhbj4xPHNwYW4+Ljwvc3Bhbj40IDxzcGFuPm9mPC9zcGFuPiA8c3Bhbj50aGU8L3NwYW4+
IDxzcGFuPkpTT048L3NwYW4+IDxzcGFuPldlYjwvc3Bhbj4gPHNwYW4+U2lnbmF0dXJlPC9zcGFu
PjxzcGFuPi48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTog
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCiZu
YnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250
LWZhbWlseTogJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEy
cHQ7Ij4NCi0tPHNwYW4+Jm5ic3A7PC9zcGFuPjxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCk8L2Rp
dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMHB0OyBmb250LWZhbWlseTog
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCkNo
YWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0
ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3Jn
LyI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPC9kaXY+DQo8L2Rp
dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KJm5ic3A7PC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86
T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N
Cjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h
aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0
Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aDwv
YT48YnI+DQo8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjxiciBjbGVhcj0iYWxs
Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQotLSA8YnI+DQpOYXQgU2FraW11cmEgKD1uYXQpDQo8ZGl2
PkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2Fr
aW11cmEub3JnLyI+aHR0cDovL25hdC5zYWtpbXVyYS5vcmcvPC9hPjxicj4NCkBfbmF0X2VuPC9k
aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_4E1F6AAD24975D4BA5B16804296739436697EF82TK5EX14MBXC283r_--

From sakimura@gmail.com  Wed Dec 19 22:12:31 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC4E21F8667 for ; Wed, 19 Dec 2012 22:12:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.837
X-Spam-Level: 
X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.161,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgJbSHaqaCEf for ; Wed, 19 Dec 2012 22:12:26 -0800 (PST)
Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by ietfa.amsl.com (Postfix) with ESMTP id D4C3B21F89A3 for ; Wed, 19 Dec 2012 22:12:23 -0800 (PST)
Received: by mail-ea0-f181.google.com with SMTP id k14so1187174eaa.40 for ; Wed, 19 Dec 2012 22:12:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zrOy95D0aMpV4277qYBjfn+8DgjWfBtE27CitMoYFww=; b=ASbaBdLpYosjkaLaSTUGDadYFse7W+hjItjWTYncKuqwCH2GLqEC0qBaek5PNYa/vI pxJ1cbiot/ayCrVQQxXeiu9ogDKnzonqHF9riDfVSdRwdQp+zdtTX5iiszRUp0JftfCw D8dEyZTcIIHhDvhQ5J4+Gs2icOHHISiptF0+lk8QDBT9y/l0gilFW82GL6TEKLPr2vtq DUT9P0VVJwNWseoad6JexBZ3ulN/v/LO3Vq0bdWrcXfTfPOSfAoC1jfiInufmGc8uyvx UcgSzD8ZvhEMdd9AVeP7nfLkne+hiZHpJCsIiFQb0FlfGrejX+5mQJ3uzX5CMoI+4hiQ bVhg==
MIME-Version: 1.0
Received: by 10.14.206.197 with SMTP id l45mr20717666eeo.17.1355983942543; Wed, 19 Dec 2012 22:12:22 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Wed, 19 Dec 2012 22:12:22 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394366979DAD@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <50B53D3E.1000107@KingsMountain.com> <4E1F6AAD24975D4BA5B168042967394366979DAD@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Thu, 20 Dec 2012 15:12:22 +0900
Message-ID: 
From: Nat Sakimura 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=047d7b34413c3769c904d1429d2e
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 06:12:31 -0000

--047d7b34413c3769c904d1429d2e
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Thanks.

Just a few things:

1. Sign+Encrypt

Sign+Encrypt is useful when you want the signed JWT as a proof of consent
to sign.
It can also exist after being decrypted.
If you just want integrity protection, use JWE.

2. Alphabetization of the terminology

That's one way of organizing it.
Another way of organizing it is to lay them out in a semantic order,
where the preceding definition cannot use the terms defined later.
It is a good way to make sure the consistency, and I probably like this way
better.

Of the definition themselves, I agree it still lacks bunch of terms that
needs to be defined,
and needs tightening up.

Best,

Nat


On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones wr=
ote:

>  Thanks a bunch for the useful review, Jeff!  Responses are inline in
> green.****
>
> ** **
>
>                                                                 -- Mike**=
*
> *
>
> ** **
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
> =3DJeffH
> Sent: Tuesday, November 27, 2012 2:23 PM
> To: IETF oauth WG
> Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>
> ** **
>
> Hi, at ietf-85 atlanta I agreed to do a review of
> draft-ietf-oauth-json-web-token-05, and so I have some thoughts below.
> Also, +1 to Hannes' comments.****
>
> ** **
>
> Overall the spec seems to get its idea across, but is pretty rough. Part
> of this is due to the language being convoluted, plus some concepts are
> only tacitly described (with clues scattered throughout the spec), and th=
us
> it is difficult to understand without multiple passes of this spec as wel=
l
> as [JWE] and [JWS].****
>
> ** **
>
> For example, a JWT appears to be simply either a JWS or a JWE containing =
a
> JWT Claims Set, but this is not stated until right before section 3.1 (an=
d
> it isn't stated that clearly).****
>
> ** **
>
> OK, I=92ll say that earlier and more clearly.****
>
> ** **
>
> Immediately below are some overall comments, and then below that some
> detailed comments on various portions of the spec.  I'm not addressing
> everything I noticed due to time constraints (apologies).****
>
> ** **
>
> HTH****
>
> ** **
>
> =3DJeffH****
>
> ------****
>
> ** **
>
> ** **
>
> JWT terminology:****
>
> ** **
>
> Some issues seem to me to be caused by defining the JWT to be the
> base64url encoded JSON  object itself and not having terminology to clear=
ly
> refer to its unencoded form.****
>
> ** **
>
> For example, these two JSON objects together apparently comprise a
> (unencoded) JWT..****
>
> ** **
>
>       {"typ":"JWT",****
>
>        "alg":"HS256"}****
>
> ** **
>
> This is the JWT Header.  The base64url encoded version is the Encoded JWT
> Header.****
>
> ** **
>
>       {"iss":"joe",****
>
>        "exp":1300819380,****
>
>        "http://example.com/is_root":true}****
>
> ** **
>
> This is the JWT Claims Set.****
>
> ** **
>
> ..but there's no defined way to refer to them given the spec's terminlogy=
.
> ****
>
> ** **
>
> The terms above are already defined in the spec.****
>
> ** **
>
> Consider terming the above a JWT and its encoded-string form an Encoded
> JWT, and define them separately. And then there'll be similar definitions
> for JWT Header and JWT Claims Set, e.g.,****
>
> ** **
>
> I disagree with redefining the term =93JWT=94 to not also include the
> signature.  The term =93JWT=94 should continue to refer to the whole thin=
g.***
> *
>
> ** **
>
>     Encoded JWT   A JWT that has been encoded according to the****
>
>        process defined in Section X.****
>
> ** **
>
>     Encoded JWT Header   The encoded-string form of a JWT Header****
>
> ** **
>
>     Encoded JWT Claims Set   The encoded-string form of a JWT Claims Set*=
*
> **
>
> ** **
>
> I=92ll note that when the JWT is encrypted, a base64url encoded
> representation of the JWT Claims Set is never used.  (The encrypted form =
of
> them is base64url encoded instead.)****
>
> ** **
>
>     encoded-string form   The result of applying Base64url encoding to an=
*
> ***
>
>        input JSON text .****
>
> ** **
>
> Sometimes he input to the base64url encoding is not JSON =96 for instance
> signature values or encrypted payloads.****
>
> ** **
>
>     JSON Web Token (JWT)  A JWT comprises a JWT Header and a JWT Claims
> Set. ...****
>
> ** **
>
>     JWT Header  A JSON object that is a component of a JWT. It denotes th=
e
> ****
>
>        cryptographic operations applied to the JWT.  ...****
>
> ** **
>
>     JWT Claims Set  A JSON object containing a set of claims.  ...****
>
> ** **
>
> This also gets rid of the use of the "A string representing a JSON
> object..." ****
>
> which I find confusing and potentially misleading (because it is actually
> "a Base64url encoding of a JSON object").****
>
> ** **
>
> Aah =96 I now see that this is the real misunderstanding.  The =93string
> representing a JSON object=94 is not the base64url encoded form =96 it=92=
s the
> string representation that=92s parseable into a JSON object.  For instanc=
e,
> it could be a string such as {=93alg=94:=94RS256=94} =96 not the base64ur=
l encoded
> version of that string.  The reason for the syntactic construction =93str=
ing
> representing a JSON object=94 is that its string representation is distin=
ct
> from the abstract JSON object itself.  If I insert whitespace after the
> colon in the string {=93alg=94:=94RS256=94} it would parse to an equivale=
nt JSON
> object but it would be a different string representation.  It=92s the str=
ing
> representation that is actually operated on by the JWT/JWS/JWE operations=
.
> ****
>
> ** **
>
> I=92ll try to make this clearer in the spec.****
>
> ** **
>
> UTF-8:****
>
> ** **
>
> UTF-8 is mentioned in lots of places. It could probably be stated once up
> near ****
>
> the beginning of the spec that all the JSON text is UTF-8 encoded, and al=
l
> the ****
>
> JSON strings are UTF-8 encoded.****
>
> ** **
>
> I=92ll see if I can figure out how to do this without introducing ambigui=
ty.
> ****
>
> ** **
>
> Semantics, profiles and relationship to SAML:****
>
> ** **
>
> The spec does not define any overall JWT semantics (i.e., what any given
> JWT ****
>
> /means/). Semantics are only defined in context of each individual
> Reserved ****
>
> Claim Name.****
>
> ** **
>
> Thus any application of JWTs will need to profile the JWT spec: specifyin=
g
> the ****
>
> claim set(s) contents, and the overall semantics of the resultant JWT(s).
> This ****
>
> is not explicitly explained in the JWT spec.****
>
> ** **
>
> Can you suggest some language you=92d like to see added about this?****
>
> ** **
>
> In terms of SAML, Appendix B should refer to SAML assertions rather than
> saml ****
>
> tokens. Also, I'm not sure SAML assertions inherently have more
> expressivity ****
>
> than JWTs. They do have more pre-defined structure and semantics.****
>
> ** **
>
> OK****
>
> ** **
>
> Syntactically, it seems one can encode pretty much anything in whatever
> amount ****
>
> in a JWT (one can do the same with SAML assertions), and thus
> theoretically JWTs ****
>
> could be used to accomplish the same things as SAML assertions.****
>
> ** **
>
> Semantically, SAML assertions are explicitly statements made by a system
> entity ****
>
> about a subject. But by default, a JWT is empty, and has no semantics
> (this ****
>
> isn't stated explicitly). All semantics defined in the JWT spec are
> particular ****
>
> to individual reserved claims, but all reserved claims are optional. Thus
> an ****
>
> application of JWTs to use cases also apropos for SAML assertions will
> require ****
>
> arguably more profiling than that needed to apply SAML assertions.****
>
> ** **
>
> All true.  However once you add an issuer and a principal, then you=92re
> back to the JWT being statements made by an entity about a subject.  Agai=
n,
> if there is language you believe should be added in that regard, please l=
et
> me know.  (BTW, one such usage profile is in
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.  Another is in
> http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)****
>
> ** **
>
> The token size & complexity comparison seems nominally fine.****
>
> ** **
>
> Some detailed-but-rough comments and musings on portions of the spec as I
> was ****
>
> reading through it...****
>
> ** **
>
> > 2. Terminology****
>
> ** **
>
> terminology is not alphabetised!****
>
> ** **
>
> No, it=92s in a top-down descriptive order.  Is there a requirement in IE=
TF
> specs that the terminology be alphabetized?****
>
> ** **
>
> "claim", "claims", "token" should be defined in terminology****
>
> ** **
>
> I=92ll add a definition for =93claim=94.  =93token=94 should actually pro=
bably
> become =93security token=94, with a definition of the term.****
>
> ** **
>
> suggestion:****
>
> ** **
>
>       Claim:  an assertion of something as a fact. Here, claims are****
>
>          name and value pairs, consisting of a Claim Name and a****
>
>          Claim Value.****
>
> ** **
>
> ** **
>
> >    JSON Web Token (JWT)****
>
> ** **
>
>    is jwt always a "string" or is it string (only) when it's been
> serialized ****
>
> into one?****
>
> ** **
>
> It=92s always the string representation of the serialized parts.****
>
> ** **
>
> >                    A string representing a set of claims as a JSON****
>
> >       object that is digitally signed or MACed and/or encrypted.****
>
> ** **
>
>    is it more that it's a set of claims encoded as a JSON object****
>
>    that is string-serialized?****
>
> ** **
>
> No, per my earlier comments ** **
>
> ** **
>
>    is it /not/ a JWT by definition if it is not ((signed or unmac'd)
> and/or ****
>
> encrypted) ?   No, because there are Plaintext JWTs, but they aren't in *=
*
> **
>
> terminology (probably should be).****
>
> ** **
>
> Good catch****
>
> ** **
>
>    "parts" in JWT definition is unclear****
>
>      are "parts" json objects or arrays unto themselves ?****
>
> ** **
>
> The parts are all base64url encoded values.  I=92ll review this terminolo=
gy
> usage to see if it can be clarified.****
>
> ** **
>
>    the definition assumes knowledge that's presented later. perhaps needs
> fwd****
>
>    reference(s), or perhaps better is to not present as much technical
> detail****
>
>    in the definitions.****
>
> ** **
>
> I=92ll review****
>
> ** **
>
> >    JWT Claims Set****
>
> ** **
>
>    similar comments as to JSON Web Token (JWT)****
>
> ** **
>
>    the definition says how it is encoded and encrypted, but not how claim=
s
> are ****
>
> mapped into a JSON object****
>
> ** **
>
> ** **
>
> should probably be simply:****
>
> ** **
>
>     JWT Claims Set: A set of claims expressed as a JSON object, where eac=
h
> ****
>
>        claim is an object member (i.e., a name/value pair). A claim may
> have****
>
>        a JWT Claims Set as a value.****
>
> ** **
>
> I=92ll look into moving the definition in this direction.  What you=92re
> missing in the above, though, is the distinction between the string
> representing the JSON object and the abstract JSON object.  We want the
> former.****
>
> ** **
>
> >    Claim Name  The name of a member of the JSON object representing a**=
*
> *
>
> >       JWT Claims Set.****
>
> ** **
>
> should probably be simply:****
>
> ** **
>
>     Claim Name  The name portion of a claim, expressed as a JSON object
> member****
>
>        name.****
>
> ** **
>
> ** **
>
> >    Claim Value  The value of a member of the JSON object representing a=
*
> ***
>
> >       JWT Claims Set.****
>
> ** **
>
> should probably be simply:****
>
> ** **
>
>     Claim Value  The value portion of a claim, expressed as a JSON object
> member****
>
>        value.****
>
> ** **
>
> I=92ll look into moving the definitions in this direction.  ****
>
> ** **
>
> > 3. JSON Web Token (JWT) Overview****
>
> ** **
>
> >    The bytes of the UTF-8 representation of the JWT Claims Set are****
>
> >    digitally signed or MACed in the manner described in JSON Web****
>
> >    Signature (JWS) [JWS] and/or encrypted in the manner described in***=
*
>
> >    JSON Web Encryption (JWE) [JWE].****
>
> ** **
>
> s/ and/or encrypted / or encrypted and signed /****
>
> ** **
>
> I think you mean =93encrypted and integrity protected=94 rather than
> =93encrypted and signed=94, right?****
>
> ** **
>
> >    The contents of the JWT Header describe the cryptographic operations=
*
> ***
>
> >    applied to the JWT Claims Set. If the JWT Header is a JWS Header, th=
e
> ****
>
> >    claims are digitally signed or MACed.  If the JWT Header is a JWE***=
*
>
> >    Header, the claims are encrypted.****
>
> ** **
>
> What if a JWT is signed AND encrypted?  Hm, from my looking at JWS and JW=
E
> ****
>
> specs, it seems that in that case one uses JWE because that encompasses
> both ****
>
> encrypt & sign.****
>
> ** **
>
> No, actually JWE just provides an integrity check =96 not a signature.  I=
f
> you want a signature, you need to use JWS.  They can (and often are) used
> in a nested fashion.****
>
> ** **
>
> >    A JWT is represented as a JWS or JWE.  The number of parts is****
>
> >    dependent upon the representation of the resulting JWS or JWE.****
>
> ** **
>
> Does the above mean to say..****
>
> ** **
>
>     A JWT consists of a JWS or JWE object, which in turn conveys the JWT*=
*
> **
>
>     Claims Set. In the case of a JWS, the JWT Claims Set is the JWS****
>
>     Payload. In the case of a JWE, the JWT Claims Set is the input****
>
>     Plaintext.****
>
> ** **
>
> Yes.  Although this is missing the fact that nested signing/encryption ma=
y
> be employed.****
>
> ** **
>
> > 4. JWT Claims****
>
> >****
>
> >****
>
> >    The JWT Claims Set represents a JSON object whose members are the***=
*
>
> >    claims conveyed by the JWT.  The Claim Names within this object MUST=
*
> ***
>
> >    be unique; JWTs with duplicate Claim Names MUST be rejected.****
>
> ** **
>
> does the above mean to say claim names must be unique amongst the set of
> claim ****
>
> names within any given JWT Claims Set ?  If so, that's only implied by th=
e
> above ****
>
> but should be stated explicitly; as it is, the above is ambiguous.****
>
> ** **
>
> OK****
>
> ** **
>
> > 4.2. Public Claim Names****
>
> >****
>
> >****
>
> >    Claim names can be defined at will by those using JWTs.  However, in=
*
> ***
>
> ** **
>
> s/Claim names/Public claim names/****
>
> ** **
>
> >    order to prevent collisions, any new claim name SHOULD either be****
>
> >    registered in the IANA JSON Web Token Claims registry Section 9.1 or=
*
> ***
>
> >    be a URI that contains a Collision Resistant Namespace.****
>
> ** **
>
> ** **
>
> why should a claim name be a URI if I wish to make use of Collision
> Resistant ****
>
> Namespaces?  For example, if I simply use say UUIDs as claim names..****
>
> ** **
>
>       {"iss":"joe",****
>
>        "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}****
>
> ** **
>
> ..it will be universally unique provided I minted it appropriately (no UR=
I
> ****
>
> syntax is needed).****
>
> ** **
>
> Fair enough.  I=92ll try to generalize the language.****
>
> ** **
>
> > 4.3. Private Claim Names****
>
> >****
>
> >****
>
> >    A producer and consumer of a JWT may agree to any claim name that is=
*
> ***
>
> >    not a Reserved Name Section 4.1 or a Public Name Section 4.2.  Unlik=
e
> ****
>
> >    Public Names, these private names are subject to collision and shoul=
d
> ****
>
> >    be used with caution.****
>
> ** **
>
> it seems private claim names are only subject to collision if the
> implementers ****
>
> don't make appropriate use of Collision Resistant Namespaces, i.e. they
> "can be" ****
>
> subject to collision.****
>
> ** **
>
> True****
>
> ** **
>
> the above two sections use "public" and "private" as distinguishing
> factors, but ****
>
> it seems to me the distinguishing factor (given how the above is written)
> is ****
>
> more whether Collision Resistant Namespaces are employed or not.****
>
> ** **
>
> Yes, although using a collision resistant namespace effectively makes the=
m
> public, as we=92re using the term****
>
> ** **
>
> An implied aspect of public claim names seems to be that it is assumed
> that they ****
>
> are publicly listed/documented/leaked, thus the "public" moniker, and
> hence ****
>
> ought to be universally unique as a matter of course.****
>
> ** **
>
> and "private" ones seem to be assumed to be obfuscated to all but the
> agreeing ****
>
> parties?  Or they are "private" in only the sense that they are created i=
n
> the ****
>
> context of a private arrangement?****
>
> ** **
>
> Private in that they are created in the context of a private arrangement.
> I=92ll try to clarify this point.  Facebook could define how they=92re go=
ing to
> use the =93id=94 claim very publicly, and yet it would still be a private=
 claim
> if not registered with IANA.****
>
> ** **
>
> >****
>
> > 7. Rules for Creating and Validating a JWT****
>
> >****
>
> >****
>
> >    To create a JWT, one MUST perform these steps.  The order of the****
>
> >    steps is not significant in cases where there are no dependencies***=
*
>
> >    between the inputs and outputs of the steps.****
>
> >****
>
> >    1.  Create a JWT Claims Set containing the desired claims.  Note tha=
t
> ****
>
> >        white space is explicitly allowed in the representation and no**=
*
> *
>
> >        canonicalization is performed before encoding.****
>
> ** **
>
> I presume the rationale for allowing white space is that JSON objects are
> ****
>
> unordered (and can contain arbitrary whitespace), thus simple
> buffer-to-buffer ****
>
> comparisons between serialized objects cannot be reliably performed.  If
> so this ****
>
> should be explicitly stated.****
>
> ** **
>
> Actually, it=92s to avoid canonicalization.  I=92ll reread the spec to se=
e if
> we=92ve stated that clearly or not.****
>
> ** **
>
> It seems that member/value-by-member/value comparisons must always be
> done, by ****
>
> parsing the JSON objects and extracting all members and values, this
> should be ****
>
> stated explicitly in the spec.****
>
> ** **
>
> I found meager jwt comparison instructions at the very end of Section 7.
> it ****
>
> should probably be its own subsection. It should probably explicitly say
> that ****
>
> JWTs need to be parsed into their constituent components, and the latter
> must be ****
>
> individually examined/compared.****
>
> ** **
>
> We tried to cover this in the end of section 7, starting with the sentenc=
e
> =93Processing a JWT inevitably requires comparing known strings to values=
 in
> the token=94, which says how these comparisons must be performed.  I agre=
e
> that this should become its own subsection.  I don=92t understand your re=
mark
> about constituent components.  Can you clarify?****
>
> ** **
>
> >    Comparisons between JSON strings and other Unicode strings MUST be**=
*
> *
>
> >    performed as specified below:****
>
> ** **
>
> this comparison algorithm seems to be attempting to allow for comparison
> of ****
>
> UTF-8 encoded JSON strings with other unicode strings in any of the
> unicode ****
>
> encoding formats, but only implies that; it should be stated.****
>
> ** **
>
> Good****
>
> ** **
>
> >****
>
> >    1.  Remove any JSON applied escaping to produce an array of Unicode*=
*
> **
>
> >        code points.****
>
> ** **
>
> I don't think (1) is correct.  A JSON string is by default encoded in
> UTF-8. A ****
>
> UTF-8 encoded string is not "an array of Unicode code points" (its a
> sequence of ****
>
> code units, which must be decoded into code points), i think a step is
> missing ****
>
> here..****
>
> ** **
>
>     1.  Remove any JSON escaping from the input JSON string.****
>
> ** **
>
>     1.a  convert the string into a sequence of unicode code points.****
>
> ** **
>
> How about =93Remove any JSON escaping from the input JSON string and conv=
ert
> the string into a sequence of Unicode code points=94?****
>
> ** **
>
> ..and then compare code point-by-code point. This overall algorithm
> /seems/ ok, ****
>
> but I'm not sure, it seems there's rationale that's not expressed, eg for
> ****
>
> excluding use of Unicode Normalization [USA15]. Also the alg is incomplet=
e
> in ****
>
> that it doesn't stipulate converting the "other unicode string" into a
> sequence ****
>
> of code points.****
>
> ** **
>
> Fair enough****
>
> ** **
>
> > 10. Security Considerations****
>
> >****
>
> >****
>
> >    All of the security issues faced by any cryptographic application***=
*
>
> >    must be faced by a JWT/JWS/JWE/JWK agent.  Among these issues are***=
*
>
> >    protecting the user's private key, preventing various attacks, and**=
*
> *
>
> >    helping the user avoid mistakes such as inadvertently encrypting a**=
*
> *
>
> >    message for the wrong recipient.  The entire list of security****
>
> >    considerations is beyond the scope of this document, but some****
>
> >    significant concerns are listed here.****
>
> >****
>
> >    All the security considerations in the JWS specification also apply*=
*
> **
>
> >    to JWT, as do the JWE security considerations when encryption is****
>
> >    employed.  In particular, the JWS JSON Security Considerations and**=
*
> *
>
> >    Unicode Comparison Security Considerations apply equally to the JWT*=
*
> **
>
> >    Claims Set in the same manner that they do to the JWS Header.****
>
> >****
>
> ** **
>
> dunno if you can get away with sec cons wholly in other docs, and I'm not
> sure ****
>
> it's appropriate given that JWTs are a profile of JWE or JWS.****
>
> ** **
>
> That was the approach that Sean had suggested.  If there other things you
> think we should specifically add, however, please let me know.****
>
> ** **
>
> above needs editorial polish -- there aren't any  "significant concerns" =
*
> ***
>
> actually listed here.****
>
> ** **
>
> True enough****
>
> ** **
>
> ---****
>
> end****
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> OAuth mailing 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
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b34413c3769c904d1429d2e
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Thanks.=A0

Just a few things:=A0

1. Sign+Encrypt



If you just want integrity protection, use JWE.=A0

2. Alphabetization of the terminology

That&#=
39;s one way of organizing it.=A0
Another way of organizing it is=
 to lay them out in a semantic order,=A0


where the preceding definition cannot use the terms defined later.=A0<=
/div>
It is a good way to make sure the consistency, and I probably lik=
e this way better.=A0

Of the definition themselves=
, I agree it still lacks bunch of terms that needs to be defined,=A0


and needs tightening up.=A0

Best,=A0

Nat


On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:













Thanks a bunch for the useful review, Jeff!=A0 Responses are inline
in green.


=A0


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=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


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

From: oauth-bou=
nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =3DJeffH

Sent: Tuesday, November 27, 2012 2:23 PM

To: IETF oauth WG

Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05


=A0


Hi, at ietf-85 atlanta I agreed to do a review of draft-ietf-oauth-json-=
web-token-05, and so I have some thoughts below. Also, +1 to Hannes' co=
mments.


=A0


Overall the spec seems to get its idea across, but is pretty rough. Part=
 of this is due to the language being convoluted, plus some concepts are on=
ly tacitly described (with clues scattered throughout the spec), and thus i=
t is difficult
 to understand without multiple passes of this spec as well as [JWE] and [J=
WS].


=A0


For example, a JWT appears to be simply either a JWS or a JWE containing=
 a JWT Claims Set, but this is not stated until right before section 3.1 (a=
nd it isn't stated that clearly).


=A0


OK, I=92ll say that earlier and more=
 clearly.


=A0


Immediately below are some overall comments, and then below that some de=
tailed comments on various portions of the spec.=A0 I'm not addressing =
everything I noticed due to time constraints (apologies).



=A0


HTH


=A0


=3DJeffH


------


=A0


=A0


JWT terminology:


=A0


Some issues seem to me to be caused by defining the JWT to be the base64=
url encoded JSON=A0 object itself and not having terminology to clearly ref=
er to its unencoded form.


=A0


For example, these two JSON objects together apparently comprise a (unen=
coded) JWT..


=A0


=A0=A0=A0=A0=A0 {"typ":"JWT",


=A0=A0=A0=A0=A0=A0 "alg":"HS256"}


=A0


This is the JWT Header.=A0 The base6=
4url encoded version is the Encoded JWT Header.


=A0


=A0=A0=A0=A0=A0 {"iss":"joe",


=A0=A0=A0=A0=A0=A0 "exp":1300819380,


=A0=A0=A0=A0=A0=A0 "http://ex=
ample.com/is_root":true}


=A0


This is the JWT Claims Set.


=A0


..but there's no defined way to refer to them given the spec's t=
erminlogy.


=A0


The terms above are already defined =
in the spec.


=A0


Consider terming the above a JWT and its encoded-string form an Encoded =
JWT, and define them separately. And then there'll be similar definitio=
ns for JWT Header and JWT Claims Set, e.g.,


=A0


I disagree with redefining the term =
=93JWT=94 to not also include the signature.=A0 The term =93JWT=94 should c=
ontinue to refer to the whole thing.


=A0


=A0=A0=A0 Encoded JWT=A0=A0 A JWT that has been encoded according to the=



=A0=A0=A0=A0 =A0=A0process defined in Section X.


=A0


=A0=A0=A0 Encoded JWT Header=A0=A0 The encoded-string form of a JWT Head=
er


=A0


=A0=A0=A0 Encoded JWT Claims Set=A0=A0 The encoded-string form of a JWT =
Claims Set


=A0


I=92ll note that when the JWT is enc=
rypted, a base64url encoded representation of the JWT Claims Set is never u=
sed.=A0 (The encrypted form of them is base64url encoded instead.)




=A0


=A0=A0=A0 encoded-string form=A0=A0 The result of applying Base64url enc=
oding to an


=A0=A0=A0=A0=A0=A0 input JSON text .


=A0


Sometimes he input to the base64url =
encoding is not JSON =96 for instance signature values or encrypted payload=
s.


=A0


=A0=A0=A0 JSON Web Token (JWT)=A0 A JWT comprises a JWT Header and a JWT=
 Claims Set. ...


=A0


=A0=A0=A0 JWT Header=A0 A JSON object that is a component of a JWT. It d=
enotes the


=A0=A0=A0=A0=A0=A0 cryptographic operations applied to the JWT.=A0 ...


=A0


=A0=A0=A0 JWT Claims Set=A0 A JSON object containing a set of claims.=A0=
 ...


=A0


This also gets rid of the use of the "A string representing a JSON =
object..."



which I find confusing and potentially misleading (because it is actuall=
y "a Base64url encoding of a JSON object").


=A0


Aah =96 I now see that this is the r=
eal misunderstanding.=A0 The =93string representing a JSON object=94 is not=
 the base64url encoded form =96 it=92s the string representation that=92s p=
arseable into a JSON object.=A0 For
 instance, it could be a string such as {=93alg=94:=94RS256=94} =96 not the=
 base64url encoded version of that string.=A0 The reason for the syntactic =
construction =93string representing a JSON object=94 is that its string rep=
resentation is distinct from the abstract JSON object
 itself.=A0 If I insert whitespace after the colon in the string {=93alg=94=
:=94RS256=94} it would parse to an equivalent JSON object but it would be a=
 different string representation.=A0 It=92s the string representation that =
is actually operated on by the JWT/JWS/JWE operations.=




=A0


I=92ll try to make this clearer in the spe=
c.


=A0


UTF-8:


=A0


UTF-8 is mentioned in lots of places. It could probably be stated once u=
p near



the beginning of the spec that all the JSON text is UTF-8 encoded, and a=
ll the



JSON strings are UTF-8 encoded.


=A0


I=92ll see if I can figure out how t=
o do this without introducing ambiguity.


=A0


Semantics, profiles and relationship to SAML:


=A0


The spec does not define any overall JWT semantics (i.e., what any given=
 JWT



/means/). Semantics are only defined in context of each individual Reser=
ved



Claim Name.


=A0


Thus any application of JWTs will need to profile the JWT spec: specifyi=
ng the



claim set(s) contents, and the overall semantics of the resultant JWT(s)=
.=A0 This



is not explicitly explained in the JWT spec.


=A0


Can you suggest some language you=92=
d like to see added about this?
=



=A0


In terms of SAML, Appendix B should refer to SAML assertions rather than=
 saml



tokens. Also, I'm not sure SAML assertions inherently have more expr=
essivity



than JWTs. They do have more pre-defined structure and semantics.=



=A0


OK


=A0


Syntactically, it seems one can encode pretty much anything in whatever =
amount



in a JWT (one can do the same with SAML assertions), and thus theoretica=
lly JWTs



could be used to accomplish the same things as SAML assertions.


=A0


Semantically, SAML assertions are explicitly statements made by a system=
 entity



about a subject. But by default, a JWT is empty, and has no semantics (t=
his



isn't stated explicitly). All semantics defined in the JWT spec are =
particular



to individual reserved claims, but all reserved claims are optional. Thu=
s an



application of JWTs to use cases also apropos for SAML assertions will r=
equire



arguably more profiling than that needed to apply SAML assertions.


=A0


All true.=A0 However once you add an=
 issuer and a principal, then you=92re back to the JWT being statements mad=
e by an entity about a subject.=A0 Again, if there is language you believe =
should be added in that regard,
 please let me know.=A0 (BTW, one such usage profile is in 
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.=A0 Another i=
s in 
http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)<=
/u>


=A0


The token size & complexity comparison seems nominally fine.<=
u>


=A0


Some detailed-but-rough comments and musings on portions of the spec as =
I was



reading through it...


=A0


> 2. Terminology


=A0


terminology is not alphabetised!


=A0


No, it=92s in a top-down descriptive=
 order.=A0 Is there a requirement in IETF specs that the terminology be alp=
habetized?


=A0


"claim", "claims", "token" should be defin=
ed in terminology


=A0


I=92ll add a definition for =93claim=
=94.=A0 =93token=94 should actually probably become =93security token=94, w=
ith a definition of the term.


=A0


suggestion:


=A0


=A0=A0=A0=A0=A0 Claim:=A0 an assertion of something as a fact. Here, cla=
ims are


=A0=A0=A0=A0=A0=A0=A0=A0 name and value pairs, consisting of a Claim Nam=
e and a


=A0=A0=A0=A0=A0=A0=A0=A0 Claim Value.


=A0


=A0


>=A0=A0=A0 JSON Web Token (JWT)


=A0


=A0=A0 is jwt always a "string" or is it string (only) when it=
's been serialized



into one?


=A0


It=92s always the string representat=
ion of the serialized parts.


=A0


>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 A string r=
epresenting a set of claims as a JSON


>=A0=A0=A0=A0=A0=A0 object that is digitally signed or MACed and/or e=
ncrypted.


=A0


=A0=A0 is it more that it's a set of claims encoded as a JSON object=



=A0=A0 that is string-serialized?


=A0


No, per my earlier comments 



=A0


=A0=A0 is it /not/ a JWT by definition if it is not ((signed or unmac=
9;d) and/or



encrypted) ?=A0=A0 No, because there are Plaintext JWTs, but they aren&#=
39;t in



terminology (probably should be).


=A0


Good catch
<=
div class=3D"im">

=A0


=A0=A0 "parts" in JWT definition is unclear


=A0=A0=A0=A0 are "parts" json objects or arrays unto themselve=
s ?


=A0


The parts are all base64url encoded =
values.=A0 I=92ll review this terminology usage to see if it can be clarifi=
ed.


=A0


=A0=A0 the definition assumes knowledge that's presented later. perh=
aps needs fwd


=A0=A0 reference(s), or perhaps better is to not present as much technic=
al detail


=A0=A0 in the definitions.


=A0


I=92ll review


=A0


>=A0=A0=A0 JWT Claims Set


=A0


=A0=A0 similar comments as to JSON Web Token (JWT)


=A0


=A0=A0 the definition says how it is encoded and encrypted, but not how =
claims are



mapped into a JSON object


=A0


=A0


should probably be simply:


=A0


=A0=A0=A0 JWT Claims Set: A set of claims expressed as a JSON object, wh=
ere each


=A0=A0=A0=A0=A0=A0 claim is an object member (i.e., a name/value pair). =
A claim may have


=A0=A0=A0=A0=A0=A0 a JWT Claims Set as a value.


=A0


I=92ll look into moving the definiti=
on in this direction.=A0 What you=92re missing in the above, though, is the=
 distinction between the string representing the JSON object and the abstra=
ct JSON object.=A0 We want
 the former.


=A0


>=A0=A0=A0 Claim Name=A0 The name of a member of the JSON object repr=
esenting a


>=A0=A0=A0=A0=A0=A0 JWT Claims Set.


=A0


should probably be simply:


=A0


=A0=A0=A0 Claim Name=A0 The name portion of a claim, expressed as a JSON=
 object member


=A0=A0=A0=A0=A0=A0 name.


=A0


=A0


>=A0=A0=A0 Claim Value=A0 The value of a member of the JSON object re=
presenting a


>=A0=A0=A0=A0=A0=A0 JWT Claims Set.


=A0


should probably be simply:


=A0


=A0=A0=A0 Claim Value=A0 The value portion of a claim, expressed as a JS=
ON object member


=A0=A0=A0=A0=A0=A0 value.


=A0


I=92ll look into moving the definiti=
ons in this direction.=A0



=A0


> 3. JSON Web Token (JWT) Overview


=A0


>=A0=A0=A0 The bytes of the UTF-8 representation of the JWT Claims Se=
t are


>=A0=A0=A0 digitally signed or MACed in the manner described in JSON =
Web


>=A0=A0=A0 Signature (JWS) [JWS] and/or encrypted in the manner descr=
ibed in


>=A0=A0=A0 JSON Web Encryption (JWE) [JWE].


=A0


s/ and/or encrypted / or encrypted and signed /


=A0


I think you mean =93encrypted and in=
tegrity protected=94 rather than =93encrypted and signed=94, right?<=
u>


=A0


>=A0=A0=A0 The contents of the JWT Header describe the cryptographic =
operations


>=A0=A0=A0 applied to the JWT Claims Set. If the JWT Header is a JWS =
Header, the


>=A0=A0=A0 claims are digitally signed or MACed.=A0 If the JWT Header=
 is a JWE


>=A0=A0=A0 Header, the claims are encrypted.


=A0


What if a JWT is signed AND encrypted?=A0 Hm, from my looking at JWS and=
 JWE



specs, it seems that in that case one uses JWE because that encompasses =
both



encrypt & sign.


=A0


No, actually JWE just provides an in=
tegrity check =96 not a signature.=A0 If you want a signature, you need to =
use JWS.=A0 They can (and often are) used in a nested fashion.




=A0


>=A0=A0=A0 A JWT is represented as a JWS or JWE.=A0 The number of par=
ts is


>=A0=A0=A0 dependent upon the representation of the resulting JWS or =
JWE.


=A0


Does the above mean to say..


=A0


=A0=A0=A0 A JWT consists of a JWS or JWE object, which in turn conveys t=
he JWT


=A0=A0=A0 Claims Set. In the case of a JWS, the JWT Claims Set is the JW=
S


=A0=A0=A0 Payload. In the case of a JWE, the JWT Claims Set is the input=



=A0=A0=A0 Plaintext.


=A0


Yes.=A0 Although this is missing the=
 fact that nested signing/encryption may be employed.<=
/p>


=A0


> 4. JWT Claims


>


>


>=A0=A0=A0 The JWT Claims Set represents a JSON object whose members =
are the


>=A0=A0=A0 claims conveyed by the JWT.=A0 The Claim Names within this=
 object MUST


>=A0=A0=A0 be unique; JWTs with duplicate Claim Names MUST be rejecte=
d.


=A0


does the above mean to say claim names must be unique amongst the set of=
 claim



names within any given JWT Claims Set ?=A0 If so, that's only implie=
d by the above



but should be stated explicitly; as it is, the above is ambiguous.


=A0


OK


=A0


> 4.2. Public Claim Names


>


>


>=A0=A0=A0 Claim names can be defined at will by those using JWTs.=A0=
 However, in


=A0


s/Claim names/Public claim names/


=A0


>=A0=A0=A0 order to prevent collisions, any new claim name SHOULD eit=
her be


>=A0=A0=A0 registered in the IANA JSON Web Token Claims registry Sect=
ion 9.1 or


>=A0=A0=A0 be a URI that contains a Collision Resistant Namespace.=



=A0


=A0


why should a claim name be a URI if I wish to make use of Collision Resi=
stant



Namespaces?=A0 For example, if I simply use say UUIDs as claim names..


=A0


=A0=A0=A0=A0=A0 {"iss":"joe",


=A0=A0=A0=A0=A0=A0 "3005fa05-e76c-4994-bbc9-65b2ace2305c":&quo=
t;foo"}


=A0


..it will be universally unique provided I minted it appropriately (no U=
RI



syntax is needed).


=A0


Fair enough.=A0 I=92ll try to genera=
lize the language.


=A0


> 4.3. Private Claim Names


>


>


>=A0=A0=A0 A producer and consumer of a JWT may agree to any claim na=
me that is


>=A0=A0=A0 not a Reserved Name Section 4.1 or a Public Name Section 4=
.2.=A0 Unlike


>=A0=A0=A0 Public Names, these private names are subject to collision=
 and should


>=A0=A0=A0 be used with caution.


=A0


it seems private claim names are only subject to collision if the implem=
enters



don't make appropriate use of Collision Resistant Namespaces, i.e. t=
hey "can be"



subject to collision.


=A0


True


=A0


the above two sections use "public" and "private" as=
 distinguishing factors, but



it seems to me the distinguishing factor (given how the above is written=
) is



more whether Collision Resistant Namespaces are employed or not.<=
u>


=A0


Yes, although using a collision resi=
stant namespace effectively makes them public, as we=92re using the term=



=A0


An implied aspect of public claim names seems to be that it is assumed t=
hat they



are publicly listed/documented/leaked, thus the "public" monik=
er, and hence



ought to be universally unique as a matter of course.


=A0


and "private" ones seem to be assumed to be obfuscated to all =
but the agreeing



parties?=A0 Or they are "private" in only the sense that they =
are created in the



context of a private arrangement?


=A0


Private in that they are created in =
the context of a private arrangement.=A0 I=92ll try to clarify this point.=
=A0 Facebook could define how they=92re going to use the =93id=94 claim ver=
y publicly, and yet it would still
 be a private claim if not registered with IANA.


=A0


>


> 7. Rules for Creating and Validating a JWT


>


>


>=A0=A0=A0 To create a JWT, one MUST perform these steps.=A0 The orde=
r of the


>=A0=A0=A0 steps is not significant in cases where there are no depen=
dencies


>=A0=A0=A0 between the inputs and outputs of the steps.=



>


>=A0=A0=A0 1.=A0 Create a JWT Claims Set containing the desired claim=
s.=A0 Note that


>=A0=A0=A0=A0=A0=A0=A0 white space is explicitly allowed in the repre=
sentation and no


>=A0=A0=A0=A0=A0=A0=A0 canonicalization is performed before encoding.=



=A0


I presume the rationale for allowing white space is that JSON objects ar=
e



unordered (and can contain arbitrary whitespace), thus simple buffer-to-=
buffer



comparisons between serialized objects cannot be reliably performed.=A0 =
If so this



should be explicitly stated.


=A0


Actually, it=92s to avoid canonicali=
zation.=A0 I=92ll reread the spec to see if we=92ve stated that clearly or =
not.


=A0


It seems that member/value-by-member/value comparisons must always be do=
ne, by



parsing the JSON objects and extracting all members and values, this sho=
uld be



stated explicitly in the spec.


=A0


I found meager jwt comparison instructions at the very end of Section 7.=
 it



should probably be its own subsection. It should probably explicitly say=
 that



JWTs need to be parsed into their constituent components, and the latter=
 must be



individually examined/compared.


=A0


We tried to cover this in the end of=
 section 7, starting with the sentence =93Processing a JWT inevitably requi=
res comparing known strings to values in the token=94, which says how these=
 comparisons must be performed.=A0
 I agree that this should become its own subsection.=A0 I don=92t understan=
d your remark about constituent components.=A0 Can you clarify?


=A0


>=A0=A0=A0 Comparisons between JSON strings and other Unicode strings=
 MUST be


>=A0=A0=A0 performed as specified below:


=A0


this comparison algorithm seems to be attempting to allow for comparison=
 of



UTF-8 encoded JSON strings with other unicode strings in any of the unic=
ode



encoding formats, but only implies that; it should be stated.<=
/u>


=A0


Good


=A0


>


>=A0=A0=A0 1.=A0 Remove any JSON applied escaping to produce an array=
 of Unicode


>=A0=A0=A0=A0=A0=A0=A0 code points.


=A0


I don't think (1) is correct.=A0 A JSON string is by default encoded=
 in UTF-8. A



UTF-8 encoded string is not "an array of Unicode code points" =
(its a sequence of



code units, which must be decoded into code points), i think a step is m=
issing



here..


=A0


=A0=A0=A0 1.=A0 Remove any JSON escaping from the input JSON string.<=
/u>


=A0


=A0=A0=A0 1.a=A0 convert the string into a sequence of unicode code poin=
ts.


=A0


How about =93Remove any JSON escapin=
g from the input JSON string and convert the string into a sequence of Unic=
ode code points=94?


=A0


..and then compare code point-by-code point. This overall algorithm /see=
ms/ ok,



but I'm not sure, it seems there's rationale that's not expr=
essed, eg for



excluding use of Unicode Normalization [USA15]. Also the alg is incomple=
te in



that it doesn't stipulate converting the "other unicode string&=
quot; into a sequence



of code points.


=A0


Fair enough
=



=A0


> 10. Security Considerations


>


>


>=A0=A0=A0 All of the security issues faced by any cryptographic appl=
ication


>=A0=A0=A0 must be faced by a JWT/JWS/JWE/JWK agent.=A0 Among these i=
ssues are


>=A0=A0=A0 protecting the user's private key, preventing various =
attacks, and


>=A0=A0=A0 helping the user avoid mistakes such as inadvertently encr=
ypting a


>=A0=A0 =A0message for the wrong recipient.=A0 The entire list of sec=
urity


>=A0=A0=A0 considerations is beyond the scope of this document, but s=
ome


>=A0=A0=A0 significant concerns are listed here.


>


>=A0=A0=A0 All the security considerations in the JWS specification a=
lso apply


>=A0 =A0=A0to JWT, as do the JWE security considerations when encrypt=
ion is


>=A0=A0=A0 employed.=A0 In particular, the JWS JSON Security Consider=
ations and


>=A0=A0=A0 Unicode Comparison Security Considerations apply equally t=
o the JWT


>=A0=A0=A0 Claims Set in the same manner that they do to the JWS Head=
er.


>


=A0


dunno if you can get away with sec cons wholly in other docs, and I'=
m not sure



it's appropriate given that JWTs are a profile of JWE or JWS.=



=A0


That was the approach that Sean had =
suggested.=A0 If there other things you think we should specifically add, h=
owever, please let me know.


=A0


above needs editorial polish -- there aren't any=A0 "significan=
t concerns"



actually listed here.


=A0


True enough
=



=A0


---


end


=A0


=A0


_______________________________________________


OAuth mailing list


OAuth@ietf.org

https://www.ietf.or=
g/mailman/listinfo/oauth







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en




--047d7b34413c3769c904d1429d2e--

From sakimura@gmail.com  Wed Dec 19 23:42:53 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46EB21F8A85 for ; Wed, 19 Dec 2012 23:42:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.646
X-Spam-Level: 
X-Spam-Status: No, score=-0.646 tagged_above=-999 required=5 tests=[AWL=-2.048, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faIaUkTniyc2 for ; Wed, 19 Dec 2012 23:42:52 -0800 (PST)
Received: from mail-ea0-f175.google.com (mail-ea0-f175.google.com [209.85.215.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9B21021F8A83 for ; Wed, 19 Dec 2012 23:42:51 -0800 (PST)
Received: by mail-ea0-f175.google.com with SMTP id h11so1174098eaa.20 for ; Wed, 19 Dec 2012 23:42:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LvUzFEB+zkqeUoUuLifvzyNnaY2MvHIk6/DDDVA8FlI=; b=V4cZW72jubhmsnY1YG9IPilq7r56ZZD79qCG8FOkndq6cCfW9uMY/Nph8i0jiBHmFe poZMl75zZG7yfGPagUJCVGOdcOkDXqPSNU1l3DLu0/hnIaL+FAORmLexlqHbTNitpEc/ jBdmVb4JJJrXQH0AlD6YAJKYdHqM4ir6fsaHaEV2G3wJHo2krVz3fLI3Z/5RHEHZ+YUU uU13O8YL80V3XVQxJj8LGNY0pM9TvxGifwNb0BXucBsotnXEY3lbCcKqOsHPrsEHjtWD Y1Q+/+ZClsT2q9cfXyCDEaLkAzIVm/luLpNMynMzLMtcSp3Jki9kYT+mNoGhwh/zC7Hy Vgpw==
MIME-Version: 1.0
Received: by 10.14.206.197 with SMTP id l45mr21369099eeo.17.1355989370416; Wed, 19 Dec 2012 23:42:50 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Wed, 19 Dec 2012 23:42:50 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Thu, 20 Dec 2012 16:42:50 +0900
Message-ID: 
From: Nat Sakimura 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=047d7b34413cbe2ee504d143e08a
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 07:42:53 -0000

--047d7b34413cbe2ee504d143e08a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

As "prn" is way under-defined [1], there can be two interpretations for
"prn".

Considering that "subject" is not a defined term (=3D dictionary term), and
interpreting a boarding pass as:

"Japan Airlines authorizes JL002 to accept passenger John Smith at the Gate
B22 provided safety and other requirements are met between the boarding
time (14:30) and 10 minutes before the departure time (15:10)"

then:

iss: Japan Airlines
prn: JL002 (the flight number)
cid: John Smith (the passenger, who uses the boarding pass)
aud: Gate B22 (Gate assigned to JL002)
nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9

Alternatively, if we interpret the boarding pass as:

"Japan Airlines authorizes John Smith to board JL002 at the Gate B22
provided safety and other requirements are met the boarding time (14:30)
and 10 minutes before the departure time (15:10)""

iss: Japan Airlines
prn: John Smith
cid: John Smith
aud: Gate B22 (Gate assigned to JL002)
nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9

This interpretation has lost some information while encoding into JWT, so
prior one may be more appropriate.

Either way, as "prn" lacks exact semantics, what goes into it is subject to
interpretation while "cid" is very clearly defined.

Let me give another example.

An entitlement that says: "John Smith is allowed to activate the system
when Mary White presents this token (#1234) to the System A" that is issued
by the "ABC Corp"

iss: ABC Corp.
jti: #1234
prn: John Smith
cid: Mary White
aud: System A

Note: this is not delegation nor on-behalf-of.

More webby example: "John Smith authorizes photo print service A to access
photo archive service B for John Smith's photo #123 until 2013-04-01 for
the sum of $100."

iss: John Smith's Authorization Server
prn: John Smith's photo #123
cid: Photo print service A
aud: photo archive service B
exp: 2013-04-01

Nat

[1]  4.1.6 "prn" defines its value as what identifies:

"the subject of the JWT"


This can be expanded by replacing "JWT" with its definition as

"the subject of the string consisting of multiple parts, the first being
> the Encoded JWT Header, plus additional parts depending upon the contents
> of the header, with the parts being separated by period ('.') characters,
> and each part containing base64url encoded content."


Further, expanding "JWT Header", it will become

"the subject of the string consisting of multiple parts, the first being
> the string representing a JSON object that describes the cryptographic
> operations applied to the string, plus additional parts depending upon
> the contents of the header, with the parts being separated by period ('.'=
)
> characters, and each part containing base64url encoded content."


To me, it is not clear what it means.


On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones wr=
ote:

>  What would the iss, prn, aud, and cid values represent in the boarding
> pass example?
>
> -- Mike
>
>  *From:* Nat Sakimura
> *Sent:* December 19, 2012 9:32 PM
> *To:* Mike Jones
> *CC:* Anthony Nadalin, John Bradley, oauth
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT
>
> I obviously disagree - if I did agree, I did not send it to the list to
> start with :-)
>
>  "cid" (or in my original proposal, "reg") has a very clear and
> established meaning.
> The parallel examples abounds in our daily life.
>
>  It has very little to do with On-behalf-of.
> It is not a delegation statement.
>
>  "cid" is there to indicate to whom it was issued to.
> The entity who was issued this "token" is eligible to use it at the
> entities indicated by "aud".
>
>  Example in our real life are like:
>
>  - Airline boarding pass
> - Registered instruments (bond / share)
> - Monthly train pass
> - Disneyland annual passport
>  etc. etc.
>
>  Please do not mix it up with a delegation statement like on-behalf-of,
> which is much less well defined.
>
>  Nat
>
>
>
> On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones wrote:
>
>>  I'm with Tony on this.  This seems premature to put into the JWT
>> standard.  All the other JWT claims have well established meanings and
>> history behind them.  These don't.
>>
>> If the goal is to allow OpenID Connect implementations to not reject
>> tokens using =93cid=94, there are lots of other ways to accomplish this =
that I
>> think we should consider first.
>>
>> -- Mike
>>
>>
>>  *From:* John Bradley
>> *Sent:* December 19, 2012 6:25 PM
>> *To:* Anthony Nadalin
>> *CC:* oauth
>> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT
>>
>> I agree, audience who requested it and and who it is requested for are
>> all interrelated.
>>
>>  However we do need to set down some standard way of expressing it as
>> people are starting to make stuff up on their own that will impact
>> interoperability.
>>
>>  If Google starts thawing in cid and clients don't know about it they
>> must reject the JWT etc.
>>
>>  John
>>
>>  On 2012-12-19, at 9:40 PM, Anthony Nadalin 
>> wrote:
>>
>>   It seems premature and we should consider this in the bigger context
>> of the =93on behalf of=94/delegation work that has been started
>>
>>  *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On
>> Behalf Of *Nat Sakimura
>> *Sent:* Tuesday, December 18, 2012 6:22 PM
>> *To:* oauth
>> *Subject:* [OAUTH-WG] "cid" claim in JWT
>>
>>  In OpenID Connect WG, we have been talking this for sometime.
>>  "cid" claim identifies the entity that the JWT was issued to as a
>> rightful/licensed user.
>>   Google already uses this in their implementation of id_token of OIDC.
>>
>>   Here is the text proposal. It introduces two new standard claims:
>> "cid" and "cit".
>>
>>   It would be very useful in creating a HoK drafts as well.
>>
>>  Cheers,
>>
>>  Nat
>>
>>
>>
>>
>> *4.1.9. "cid" Client Identification Data Claim*
>>
>>
>>
>> The "cid" (client identification data) claim allows the receiver
>>
>> of the JWT to identify the entity that the JWT is
>>
>> intended to be used by. The audience of the JWT MUST be
>>
>> able to identify the client with the value of this claim.
>>
>>
>>
>> The "cid" value is a case sensitive string containing a StringOrURI valu=
e.
>>
>> This claim is OPTIONAL. If the entity processing the claim does not
>>
>> identify the user of the JWT with the identifier in the "cid" claim valu=
e,
>>
>> then the JWT MUST be rejected. The interpretation of the registered to
>>
>> value is generally application specific.
>>
>>
>>
>> A typical example of a registered to claim includes following:
>>
>> * client_id that the audience can use to authenticate and
>>
>>   identify the client.
>>
>> * A base64url encoded JWK.
>>
>> * A URL that points to the key material that the audience can use to
>>
>>   authenticate the user of the JWT.
>>
>>
>>
>> *4.1.10 "cit" (Client Identification Data claim type)*
>>
>>
>>
>> The "cit" (Client Identification Data claim type) identifies the type
>>
>> of the "cid" claim. It is a StringOrURI value. The defined values
>>
>> are the following:
>>
>>
>>
>> "client_id" The value of the "cid" claim is the Client ID of the client
>>
>> that the audience of the JWT is able to use to authenticate the client.
>>
>>
>>
>> "jwk" The value of the "cid" claim is a base64url encoded JWK of
>>
>> the registered client.
>>
>>
>>
>> "jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of
>>
>> JSON web signature [JWS].
>>
>>
>>
>> "x5u" The value of the "cid" claim is the URL that points to the public
>>
>> key certificate of the registered client. The format of the content
>>
>> that x5u points to is described in section 4.1.4 of the JSON Web Signatu=
re.
>>
>>
>>  --
>> Nat Sakimura (=3Dnat)
>>  Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>>  _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
>
>  --
> Nat Sakimura (=3Dnat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>



--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b34413cbe2ee504d143e08a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


As "prn" is way under-defined [1], there can be two int=
erpretations for "prn".=A0

Considering t=
hat "subject" is not a defined term (=3D dictionary term), and in=
terpreting a boarding pass as:



"Japan Airlines authorizes JL002 to accept passeng=
er John Smith at the Gate B22 provided safety and other requirements are me=
t between the boarding time (14:30) and 10 minutes before the departure tim=
e (15:10)"=A0



then:=A0

iss: Japan Airlines
pr=
n: JL002 (the flight number)
cid: John Smith (the passenger, who =
uses the boarding pass)
aud:=A0Gate B22 (Gate assigned to JL002)<=
/div>

nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9
<=
div>
Alternatively, if we interpret the boarding pass as:=A0<=
/div>

"Japan Airlines authorizes John Smith to boar=
d JL002 at the Gate B22 provided safety and other requirements are met=A0th=
e boarding time (14:30) and 10 minutes before the departure time (15:10)&qu=
ot;"



iss: Japan Airlines
prn: John Smith
cid: John Smith
aud: Gate B22 (Gate assigned to JL002)
nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9



This interpretation has lost some information while enc=
oding into JWT, so prior one may be more appropriate.=A0

Either way, as "prn" lacks exact semantics, what goes into=
 it is subject to interpretation while "cid" is very clearly defi=
ned.=A0



Let me give another example.=A0

An entitlement that says: "John Smith is allowed to activate the sys=
tem when Mary White presents this token (#1234) to the System A" that =
is issued by the "ABC Corp"



iss: ABC Corp.=A0
jti: #1234
prn: J=
ohn Smith
cid: Mary White
aud: System A

<=
/div>
Note: this is not delegation nor on-behalf-of.=A0

<=
/div>

More webby example: "John Smith authorizes photo print service A =
to access photo archive service B for John Smith's photo #123 until 201=
3-04-01 for the sum of $100."

iss: John Smith=
's Authorization Server


prn: John Smith's photo #123
cid: Photo print service A<=
/div>
aud: photo archive service B
exp: 2013-04-01
=

Nat

[1] =A04.1.6 "prn" de=
fines its value as what identifies:




"the subject of the JWT"=A0

This can be expanded by replacing=A0"JWT" with its definiti=
on as=A0


"the subject of the string consisting of multiple parts, the first bei=
ng the Encoded JWT Header, plus additional parts depending upon the content=
s of the header, with the parts being separated by period ('.') cha=
racters, and each part containing base64url encoded content."


Further, expanding "JWT Header", it will beco=
me=A0


"the subject of the string consisting of multiple parts, the fir=
st being the=A0string representing a JSON object that describes the =
cryptographic operations applied to the string, plus additional parts=
 depending upon the contents of the header, with the parts being separated =
by period ('.') characters, and each part containing base64url enco=
ded content."



To me, it is not clear what it means.=A0


On Thu, Dec 20=
, 2012 at 3:07 PM, Mike Jones <Michael.Jones@microsoft.com&g=
t; wrote:












What would the iss, prn, aud, and cid values represent in the boarding=
 pass example?


=A0


-- Mike


=A0



From:=A0Nat Sakimura

Sent:=A0December 19, 2012 9:32 PM

To:=A0Mike Jones

CC:=A0Anthony Nadalin, John Bradley, oauth

Subject:=A0Re: [OAUTH-WG] "cid" claim in JWT




=A0

I obviously disagree - if I did agree, I did not send it to the list to sta=
rt with :-)






"cid" (or in my original proposal, "reg") has a ve=
ry clear and established meaning.=A0


The parallel examples abounds in our daily life.=A0







It has very little to do with On-behalf-of.=A0


It is not a delegation statement.=A0







"cid" is there to indicate to whom it was issued to.=A0

The entity who was issued this "token" is eligible to use it=
 at the=A0


entities indicated by "aud".=A0







Example in our real life are like:=A0







- Airline boarding pass


- Registered instruments (bond / share)=A0


- Monthly train pass


- Disneyland annual passport


=A0etc. etc.=A0







Please do not mix it up with a delegation statement like on-behalf-of,=
=A0


which is much less well defined.=A0







Nat












On Thu, Dec 20, 2012 at 1=
2:07 PM, Mike Jones 
<Michae=
l.Jones@microsoft.com> wrote:










I'm with Tony on this.=A0 This seems premature to put into the JWT=
 standard.=A0 All the other JWT claims have well established meanings and h=
istory behind them.=A0 These don't.


=A0


If the goal is to allow OpenID Connect implementations to not reject t=
okens using=A0=93cid=94, there are lots of other ways to accomplish this th=
at I think we should consider first.


=A0


-- Mike


=A0


=A0



From:=A0John Bradley

Sent:=A0December 19, 2012 6:25 PM

To:=A0Anthony Nadalin

CC:=A0oauth


Subject:=A0Re: [OAUTH-WG] "cid" clai=
m in JWT








=A0

I agree, audience who requested it and and who it is requested for are all =
interrelated.






However we do need to set down some stand=
ard way of expressing it as people are starting to make stuff up on their o=
wn that will impact interoperability.







If Google starts thawing in cid and clients don't know about it th=
ey must reject the JWT etc.







John







On 2012-12-19, at 9:40 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:










It seems premature and we should consider this in the bigger contex=
t of the =93on behalf of=94/delegation work that has been started




From:=
=A0oauth=
-bounces@ietf.org [mailto:o=
auth-bounces@ietf=
.org]=A0On
 Behalf Of=A0Nat Sakimura

Sent:=A0Tuesday, December 18, 2012 6:22 PM

To:=A0oauth

Subject:=A0[OAUTH-WG] "cid" claim in JWT



=A0



In OpenID Connect WG, we have been talking this for sometime.=A0





"cid" claim identifies the entity that the JWT was issued to as a=
 rightful/licensed user.=A0







Google already uses this in their implementation of id_token of OIDC.=A0






=A0







Here is the text proposal. It introduces two new standard claims: "cid=
" and "cit".=A0







=A0







It would be very useful in creating a HoK drafts as well.=A0<=
/div>


=A0



Cheers,=A0



=A0



Nat



=A0






=A0


=
4.1.9. "cid" Client Identification Data Claim



=A0


The "cid" =
(client identification data) claim allows the =
receiver 



of the JWT to identify the entity that the JWT is 



intended=
 to be=
 used by. The audience of the JWT MUST be 



able to identi=
fy the client with the<=
/span> value of this claim.



=A0


The "cid" =
value is a case sensitive string=
 containing a StringOrURI valu=
e.



This claim is<=
/span> OPTIONAL. If the=
 entity processing the claim does not 



identify=
 the u=
ser of the JWT with the identifier in the "cid" claim value=
, 



then the JWT MUST be rejected.=
 The interpretation of the registered to 



value is gener=
ally application specific.



=A0


A typical exam=
ple of a registered to<=
/span> claim includes following: 



* client_id th=
at the audience can use=
 to authenticate and <=
/pre>


=A0=A0identify =
the client.



* A base64url<=
/span> encoded JWK. 



* A URL=
 that points to the key material that the audience can use to =




=A0=A0authenticate the user of the JWT.



=A0


=
4.1.10 "cit" (Client Identification Data claim type)



=A0


The "cit" =
(Client Identification Data claim type) identifies the type 



of the "c=
id" claim. It is a StringOrURI value. The defined values 



are the follow=
ing:



=A0


"client_id=
" The value of the=
 "cid" claim is the<=
/span> Client ID of the=
 client 



that the audie=
nce of the JWT is able to use to =
authenticate the client.



=A0


"jwk"=
 The value of the "=
;cid" claim is a <=
span>base64url encoded JWK of=
 



the registered client.



=A0


"jku"=
 The value of the "=
;cid" claim is the=
 "jku" defined in 4.=
1.2 of 



JSON web signa=
ture [JWS].



=A0


"x5u"=
 The value of the "=
;cid" claim is the=
 URL that points to the public 



key certificate of the registered client. The format of the<=
/span> content 



that x5u point=
s to is described in section 4.1.4 of <=
span>the JSON Web Signature.














=A0





--=A0

Nat Sakimura (=3Dnat)





Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en





=A0





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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



















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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
















-- 

Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en












-- 
Nat Sakimura=
 (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en




--047d7b34413cbe2ee504d143e08a--

From Michael.Jones@microsoft.com  Thu Dec 20 08:23:16 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFDA21F87AD for ; Thu, 20 Dec 2012 08:23:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.245
X-Spam-Level: 
X-Spam-Status: No, score=-0.245 tagged_above=-999 required=5 tests=[AWL=-2.647, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrsnMBOk8T1Z for ; Thu, 20 Dec 2012 08:23:11 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1B221F874B for ; Thu, 20 Dec 2012 08:23:04 -0800 (PST)
Received: from BL2PR03CA012.namprd03.prod.outlook.com (10.255.109.29) by BL2PR03MB616.namprd03.prod.outlook.com (10.255.109.41) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 16:22:55 +0000
Received: from BY2FFO11FD013.protection.gbl (207.46.100.31) by BL2PR03CA012.outlook.com (10.255.109.29) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 16:22:54 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 16:22:54 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.50]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Thu, 20 Dec 2012 16:22:18 +0000
From: Mike Jones 
To: Nat Sakimura 
Thread-Topic: [OAUTH-WG] "cid" claim in JWT
Thread-Index: Ac3eeDoQnms0qid0tk+0K29GGMlTVQADWJcAABH2AUA=
Date: Thu, 20 Dec 2012 16:22:17 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436697FA11@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.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.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436697FA11TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(377454001)(24454001)(74502001)(5343655001)(44976002)(16406001)(74662001)(33656001)(31966008)(16236675001)(77982001)(5343635001)(47446002)(59766001)(15202345001)(550184003)(55846006)(551984001)(46102001)(47976001)(512954001)(76482001)(4396001)(56816002)(49866001)(1411001)(47736001)(56776001)(50986001)(54356001)(54316002)(53806001)(51856001)(404934002)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB616; LANG:en; 
X-OriginatorOrg: testtestdelta.onmicrosoft.com
X-Forefront-PRVS: 07013D7479
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 16:23:17 -0000

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

This was discussed on the OpenID Connect call this morning.  Our sense was =
that "Authorized Party" was actually a more general description of the conc=
ept than Client ID.  Justin Richer pointed out that at that point, there wo=
uld be claims defined for representing all four potential parties in an OAu=
th interaction.  Connect plans to define the optional "azp" (Authorized Par=
ty) claim to let people experiment with it.  There wasn't a sense that it's=
 necessary to add to the JWT spec itself at this time.

As for the proposed "cid" (Client Identification Data claim type) claim, ou=
r sense was that that is more related to proof of possession, and can be di=
scussed in that context.

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, December 19, 2012 11:43 PM
To: Mike Jones
Cc: Anthony Nadalin; John Bradley; oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

As "prn" is way under-defined [1], there can be two interpretations for "pr=
n".

Considering that "subject" is not a defined term (=3D dictionary term), and=
 interpreting a boarding pass as:

"Japan Airlines authorizes JL002 to accept passenger John Smith at the Gate=
 B22 provided safety and other requirements are met between the boarding ti=
me (14:30) and 10 minutes before the departure time (15:10)"

then:

iss: Japan Airlines
prn: JL002 (the flight number)
cid: John Smith (the passenger, who uses the boarding pass)
aud: Gate B22 (Gate assigned to JL002)
nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9

Alternatively, if we interpret the boarding pass as:

"Japan Airlines authorizes John Smith to board JL002 at the Gate B22 provid=
ed safety and other requirements are met the boarding time (14:30) and 10 m=
inutes before the departure time (15:10)""

iss: Japan Airlines
prn: John Smith
cid: John Smith
aud: Gate B22 (Gate assigned to JL002)
nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9

This interpretation has lost some information while encoding into JWT, so p=
rior one may be more appropriate.

Either way, as "prn" lacks exact semantics, what goes into it is subject to=
 interpretation while "cid" is very clearly defined.

Let me give another example.

An entitlement that says: "John Smith is allowed to activate the system whe=
n Mary White presents this token (#1234) to the System A" that is issued by=
 the "ABC Corp"

iss: ABC Corp.
jti: #1234
prn: John Smith
cid: Mary White
aud: System A

Note: this is not delegation nor on-behalf-of.

More webby example: "John Smith authorizes photo print service A to access =
photo archive service B for John Smith's photo #123 until 2013-04-01 for th=
e sum of $100."

iss: John Smith's Authorization Server
prn: John Smith's photo #123
cid: Photo print service A
aud: photo archive service B
exp: 2013-04-01

Nat

[1]  4.1.6 "prn" defines its value as what identifies:

"the subject of the JWT"

This can be expanded by replacing "JWT" with its definition as

"the subject of the string consisting of multiple parts, the first being th=
e Encoded JWT Header, plus additional parts depending upon the contents of =
the header, with the parts being separated by period ('.') characters, and =
each part containing base64url encoded content."

Further, expanding "JWT Header", it will become

"the subject of the string consisting of multiple parts, the first being th=
e string representing a JSON object that describes the cryptographic operat=
ions applied to the string, plus additional parts depending upon the conten=
ts of the header, with the parts being separated by period ('.') characters=
, and each part containing base64url encoded content."

To me, it is not clear what it means.


On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones > wrote:
What would the iss, prn, aud, and cid values represent in the boarding pass=
 example?

-- Mike

From: Nat Sakimura
Sent: December 19, 2012 9:32 PM
To: Mike Jones
CC: Anthony Nadalin, John Bradley, oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

I obviously disagree - if I did agree, I did not send it to the list to sta=
rt with :-)

"cid" (or in my original proposal, "reg") has a very clear and established =
meaning.
The parallel examples abounds in our daily life.

It has very little to do with On-behalf-of.
It is not a delegation statement.

"cid" is there to indicate to whom it was issued to.
The entity who was issued this "token" is eligible to use it at the
entities indicated by "aud".

Example in our real life are like:

- Airline boarding pass
- Registered instruments (bond / share)
- Monthly train pass
- Disneyland annual passport
 etc. etc.

Please do not mix it up with a delegation statement like on-behalf-of,
which is much less well defined.

Nat


On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones > wrote:
I'm with Tony on this.  This seems premature to put into the JWT standard. =
 All the other JWT claims have well established meanings and history behind=
 them.  These don't.

If the goal is to allow OpenID Connect implementations to not reject tokens=
 using "cid", there are lots of other ways to accomplish this that I think =
we should consider first.

-- Mike


From: John Bradley
Sent: December 19, 2012 6:25 PM
To: Anthony Nadalin
CC: oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

I agree, audience who requested it and and who it is requested for are all =
interrelated.

However we do need to set down some standard way of expressing it as people=
 are starting to make stuff up on their own that will impact interoperabili=
ty.

If Google starts thawing in cid and clients don't know about it they must r=
eject the JWT etc.

John

On 2012-12-19, at 9:40 PM, Anthony Nadalin > wrote:

It seems premature and we should consider this in the bigger context of the=
 "on behalf of"/delegation work that has been started

From: oauth-bounces@ietf.org [mailto:oauth-<=
mailto:oauth->bounces@ietf.org] On Behalf Of Nat S=
akimura
Sent: Tuesday, December 18, 2012 6:22 PM
To: oauth
Subject: [OAUTH-WG] "cid" claim in JWT

In OpenID Connect WG, we have been talking this for sometime.
"cid" claim identifies the entity that the JWT was issued to as a rightful/=
licensed user.
Google already uses this in their implementation of id_token of OIDC.

Here is the text proposal. It introduces two new standard claims: "cid" and=
 "cit".

It would be very useful in creating a HoK drafts as well.

Cheers,

Nat




4.1.9. "cid" Client Identification Data Claim



The "cid" (client identification data) claim allows the receiver

of the JWT to identify the entity that the JWT is

intended to be used by. The audience of the JWT MUST be

able to identify the client with the value of this claim.



The "cid" value is a case sensitive string containing a StringOrURI value.

This claim is OPTIONAL. If the entity processing the claim does not

identify the user of the JWT with the identifier in the "cid" claim value,

then the JWT MUST be rejected. The interpretation of the registered to

value is generally application specific.



A typical example of a registered to claim includes following:

* client_id that the audience can use to authenticate and

  identify the client.

* A base64url encoded JWK.

* A URL that points to the key material that the audience can use to

  authenticate the user of the JWT.



4.1.10 "cit" (Client Identification Data claim type)



The "cit" (Client Identification Data claim type) identifies the type

of the "cid" claim. It is a StringOrURI value. The defined values

are the following:



"client_id" The value of the "cid" claim is the Client ID of the client

that the audience of the JWT is able to use to authenticate the client.



"jwk" The value of the "cid" claim is a base64url encoded JWK of

the registered client.



"jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of

JSON web signature [JWS].



"x5u" The value of the "cid" claim is the URL that points to the public

key certificate of the registered client. The format of the content

that x5u points to is described in section 4.1.4 of the JSON Web Signature.

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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











This was discussed on the=
 OpenID Connect call this morning.  Our sense was that “Authoriz=
ed Party” was actually a more general description of the concept than
 Client ID.  Justin Richer pointed out that at that point, there would=
 be claims defined for representing all four potential parties in an OAuth =
interaction.  Connect plans to define the optional “azp” (=
Authorized Party) claim to let people experiment with
 it.  There wasn’t a sense that it’s necessary to add to t=
he JWT spec itself at this time.


 <=
/p>

As for the proposed ̶=
0;cid” (Client Identification Data claim type) claim, our sense was t=
hat that is more related to proof of possession, and can be discussed
 in that context.


 <=
/p>

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


 <=
/p>

From: Nat Saki=
mura [mailto:sakimura@gmail.com]


Sent: Wednesday, December 19, 2012 11:43 PM

To: Mike Jones

Cc: Anthony Nadalin; John Bradley; oauth

Subject: Re: [OAUTH-WG] "cid" claim in JWT


 






As "prn" is way under-defined [1], there c=
an be two interpretations for "prn". 






 






Considering that "subject" is not a define=
d term (=3D dictionary term), and interpreting a boarding pass as:






 






"Japan Airlines authorizes JL002 to accept pass=
enger John Smith at the Gate B22 provided safety and other requirements are=
 met between the boarding time (14:30) and 10 minutes before the departure =
time (15:10)" 






 






then: 






 




iss: Japan Airlines




prn: JL002 (the flight number)






cid: John Smith (the passenger, who uses the boardin=
g pass)






aud: Gate B22 (Gate assigned to JL002)








nbf: 2012-12-31T14:30+9






exp: 2012-12-31T15:00+9






 






Alternatively, if we interpret the boarding pass as:=
 






 






"Japan Airlines authorizes John Smith to board =
JL002 at the Gate B22 provided safety and other requirements are met t=
he boarding time (14:30) and 10 minutes before the departure time (15:10)&q=
uot;"






 






iss: Japan Airlines






prn: John Smith






cid: John Smith






aud: Gate B22 (Gate assigned to JL002)







nbf: 2012-12-31T14:30+9






exp: 2012-12-31T15:00+9








 






This interpretation has lost some information while =
encoding into JWT, so prior one may be more appropriate. 





 






Either way, as "prn" lacks exact semantics=
, what goes into it is subject to interpretation while "cid" is v=
ery clearly defined. 






 






Let me give another example. 






 






An entitlement that says: "John Smith is allowe=
d to activate the system when Mary White presents this token (#1234) to the=
 System A" that is issued by the "ABC Corp"






 






iss: ABC Corp. 






jti: #1234






prn: John Smith






cid: Mary White






aud: System A






 






Note: this is not delegation nor on-behalf-of. =







 






More webby example: "John Smith authorizes phot=
o print service A to access photo archive service B for John Smith's photo =
#123 until 2013-04-01 for the sum of $100."






 






iss: John Smith's Authorization Server





prn: John Smith's photo #123






cid: Photo print service A






aud: photo archive service B






exp: 2013-04-01






 






Nat






 






[1]  4.1.6 "prn" defines its value as=
 what identifies:






 










"the subject of the JW=
T" 










 





This can be expanded by rep=
lacing "JWT" with its definition as <=
/p>





 





"the subject of the st=
ring consisting of multiple parts, the first being the Encoded JWT Header, =
plus additional parts depending upon the contents of the header,
 with the parts being separated by period ('.') characters, and each part c=
ontaining base64url encoded content."






 





Further, expanding "JW=
T Header", it will become 






 





"the subject of the st=
ring consisting of multiple parts, the first being the string represen=
ting a JSON object that describes the cryptographic operations applied
 to the string, plus additional parts depending upon the contents of the he=
ader, with the parts being separated by period ('.') characters, and each p=
art containing base64url encoded content."






 





To me, it is not clear what=
 it means. 








 







 




On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones <Michael.Jones@=
microsoft.com> wrote:








What would the iss, prn, aud, and cid values represent i=
n the boarding pass example?






 






-- Mike






 






From: Nat Sakimura

Sent: December 19, 2012 9:32 PM

To: Mike Jones

CC: Anthony Nadalin, John Bradley, oauth

Subject: Re: [OAUTH-WG] "cid" claim in J=
WT










 




I obviously disagree - if I did agree, I did not send it=
 to the list to start with :-)





 






"cid" (or in my original proposal, "reg&q=
uot;) has a very clear and established meaning. 






The parallel examples abounds in our daily life. 






 






It has very little to do with On-behalf-of. 






It is not a delegation statement. 






 






"cid" is there to indicate to whom it was issu=
ed to. 






The entity who was issued this "token" is elig=
ible to use it at the 






entities indicated by "aud". <=
/span>






 






Example in our real life are like: 






 






- Airline boarding pass






- Registered instruments (bond / share) =







- Monthly train pass






- Disneyland annual passport






 etc. etc. 






 






Please do not mix it up with a delegation statement like=
 on-behalf-of, 






which is much less well defined. =







 






Nat






 










 <=
/p>







On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:


















I'm with Tony on this.  This seems premature to put=
 into the JWT standard.  All the other JWT claims have well establishe=
d meanings and history behind them.  These don't.





 






If the goal is to allow OpenID Connect implementations t=
o not reject tokens using “cid”, there are lots of other w=
ays to accomplish this that I think we should consider first.






 






-- Mike






 






 














From: John Bradley

Sent: December 19, 2012 6:25 PM

To: Anthony Nadalin

CC: oauth






Subject: Re: [OAUTH-WG] "c=
id" claim in JWT












 




I agree, audience who requested it and and who it is req=
uested for are all interrelated.





 












However we do need to set down some standard way of expr=
essing it as people are starting to make stuff up on their own that will im=
pact interoperability.






 






If Google starts thawing in cid and clients don't know a=
bout it they must reject the JWT etc.






 






John






 






On 2012-12-19, at 9:40 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:






 








It seems premature and we=
 should consider this in the bigger context of the “on behalf of̶=
1;/delegation work that has been started







From: <=
a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ie=
tf.org [mailto:oauth-bounces@ietf.org]&n=
bsp;On
 Behalf Of Nat Sakimura

Sent: Tuesday, December 18, 2012 6:22 PM

To: oauth

Subject: [OAUTH-WG] "cid" claim in JWT






 






In OpenID Connect WG, we have been talking this for =
sometime. 








"cid" claim identifies the entity that the=
 JWT was issued to as a rightful/licensed user. 










Google already uses this in their implementation of =
id_token of OIDC. 










 










Here is the text proposal. It introduces two new sta=
ndard claims: "cid" and "cit". 










 












 


4.1.9. "cid" Client Identificatio=
n Data Claim


 


The "cid" (client identification dat=
a) claim allows the receiver 


of the JWT to identify the entity that the JWT=
 is 


intended to be used by. The audience of the JW=
T MUST be 


able to identify the client with the value of =
this claim.


 


The "cid" value is a case sensitive string containing a StringOrURI value.


This claim is OPTIONAL. If the entity processi=
ng the claim does not 


identify the user of the JWT with the identifi=
er in the "cid" claim value, 


then the JWT MUST be rejected. The interpretat=
ion of the registered to 


value is generally application specific.


 


A typical example of a registered to claim inc=
ludes following: 


* client_id that the audience can use to authe=
nticate and 


  identify the client.


* A base64url encoded JWK. <=
/pre>

* A URL that points to the key material that t=
he audience can use to 


  authenticate the user of the JWT.<=
/span>


 


4.1.10 "cit" (Client Identificati=
on Data claim type)


 


The "cit" (Client Identification Dat=
a claim type) identifies the type 


of the "cid" claim. It is a StringOr=
URI value. The defined values 


are the following:


 


"client_id" The value of the "c=
id" claim is the Client ID of the client 


that the audience of the JWT is able to use to=
 authenticate the client.


 


"jwk" The value of the "cid&quo=
t; claim is a base64url encoded JWK of 


the registered client.


 


"jku" The value of the "cid&quo=
t; claim is the "jku" defined in 4.1.2 of 

JSON web signature [JWS].

 


"x5u" The value of the "cid&quo=
t; claim is the URL that points to the public 


key certificate of the registered client. The =
format of the content 


that x5u points to is described in section 4.1=
.4 of the JSON Web Signature.














 








-- 

Nat Sakimura (=3Dnat)








Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en








 








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








 






















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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






















 




-- 

Nat Sakimura (=3Dnat) 




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en






















 




-- 

Nat Sakimura (=3Dnat)




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en








--_000_4E1F6AAD24975D4BA5B16804296739436697FA11TK5EX14MBXC283r_--

From tonynad@microsoft.com  Thu Dec 20 08:43:23 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C8121F892D for ; Thu, 20 Dec 2012 08:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.034
X-Spam-Level: ***
X-Spam-Status: No, score=3.034 tagged_above=-999 required=5 tests=[AWL=-2.500,  BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+6a0oPDyaA1 for ; Thu, 20 Dec 2012 08:43:17 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id EED6921F8923 for ; Thu, 20 Dec 2012 08:43:16 -0800 (PST)
Received: from BL2FFO11FD006.protection.gbl (10.173.161.204) by BL2FFO11HUB020.protection.gbl (10.173.160.112) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 16:43:13 +0000
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 20 Dec 2012 16:43:13 +0000
Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 20 Dec 2012 16:42:47 +0000
Received: from mail199-ch1-R.bigfish.com (10.43.68.253) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Thu, 20 Dec 2012 16:39:30 +0000
Received: from mail199-ch1 (localhost [127.0.0.1])	by mail199-ch1-R.bigfish.com (Postfix) with ESMTP id F2E433403F3	for ; Thu, 20 Dec 2012 16:39:29 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -15
X-BigFish: PS-15(zz98dId79eh9371Id6eah936eIc85fh9e2dkzz1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dh18c673h8275bhz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail199-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB044; LANG:en; 
Received: from mail199-ch1 (localhost.localdomain [127.0.0.1]) by mail199-ch1 (MessageSwitch) id 1356021567554072_17998; Thu, 20 Dec 2012 16:39:27 +0000 (UTC)
Received: from CH1EHSMHS012.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241])	by mail199-ch1.bigfish.com (Postfix) with ESMTP id 7AC4F4600B9;	Thu, 20 Dec 2012 16:39:27 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS012.bigfish.com (10.43.70.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 20 Dec 2012 16:39:26 +0000
Received: from BY2PR03MB044.namprd03.prod.outlook.com (10.255.241.148) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 20 Dec 2012 16:39:25 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB044.namprd03.prod.outlook.com (10.255.241.148) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 20 Dec 2012 16:39:09 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Thu, 20 Dec 2012 16:39:09 +0000
From: Anthony Nadalin 
To: Nat Sakimura , Mike Jones 
Thread-Topic: [OAUTH-WG] "cid" claim in JWT
Thread-Index: Ac3eeDoQzxEKczxlYkWEdMy9QtTiVAADWJcAABKonvA=
Date: Thu, 20 Dec 2012 16:39:08 +0000
Message-ID: <5f9e7e4fc15c470caf10ad3ef1643b6d@BY2PR03MB041.namprd03.prod.outlook.com>
References: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.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: [50.46.126.7]
Content-Type: multipart/alternative; boundary="_000_5f9e7e4fc15c470caf10ad3ef1643b6dBY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC101.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC101.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(24454001)(50986001)(49866001)(47736001)(47976001)(6806001)(4396001)(54356001)(56816002)(76482001)(53806001)(551984001)(59766001)(33646001)(77982001)(46102001)(54316002)(5343655001)(47446002)(16676001)(56776001)(16236675001)(550184003)(15202345001)(74502001)(51856001)(44976002)(74662001)(5343635001)(31966008)(512954001)(42262001)(404934002)(24736002)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB020; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07013D7479
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 16:43:23 -0000

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

I can't see how you think PRN is way under defined when SUB is not

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, December 19, 2012 11:43 PM
To: Mike Jones
Cc: Anthony Nadalin; John Bradley; oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

As "prn" is way under-defined [1], there can be two interpretations for "pr=
n".

Considering that "subject" is not a defined term (=3D dictionary term), and=
 interpreting a boarding pass as:

"Japan Airlines authorizes JL002 to accept passenger John Smith at the Gate=
 B22 provided safety and other requirements are met between the boarding ti=
me (14:30) and 10 minutes before the departure time (15:10)"

then:

iss: Japan Airlines
prn: JL002 (the flight number)
cid: John Smith (the passenger, who uses the boarding pass)
aud: Gate B22 (Gate assigned to JL002)
nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9

Alternatively, if we interpret the boarding pass as:

"Japan Airlines authorizes John Smith to board JL002 at the Gate B22 provid=
ed safety and other requirements are met the boarding time (14:30) and 10 m=
inutes before the departure time (15:10)""

iss: Japan Airlines
prn: John Smith
cid: John Smith
aud: Gate B22 (Gate assigned to JL002)
nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9

This interpretation has lost some information while encoding into JWT, so p=
rior one may be more appropriate.

Either way, as "prn" lacks exact semantics, what goes into it is subject to=
 interpretation while "cid" is very clearly defined.

Let me give another example.

An entitlement that says: "John Smith is allowed to activate the system whe=
n Mary White presents this token (#1234) to the System A" that is issued by=
 the "ABC Corp"

iss: ABC Corp.
jti: #1234
prn: John Smith
cid: Mary White
aud: System A

Note: this is not delegation nor on-behalf-of.

More webby example: "John Smith authorizes photo print service A to access =
photo archive service B for John Smith's photo #123 until 2013-04-01 for th=
e sum of $100."

iss: John Smith's Authorization Server
prn: John Smith's photo #123
cid: Photo print service A
aud: photo archive service B
exp: 2013-04-01

Nat

[1]  4.1.6 "prn" defines its value as what identifies:

"the subject of the JWT"

This can be expanded by replacing "JWT" with its definition as

"the subject of the string consisting of multiple parts, the first being th=
e Encoded JWT Header, plus additional parts depending upon the contents of =
the header, with the parts being separated by period ('.') characters, and =
each part containing base64url encoded content."

Further, expanding "JWT Header", it will become

"the subject of the string consisting of multiple parts, the first being th=
e string representing a JSON object that describes the cryptographic operat=
ions applied to the string, plus additional parts depending upon the conten=
ts of the header, with the parts being separated by period ('.') characters=
, and each part containing base64url encoded content."

To me, it is not clear what it means.


On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones > wrote:
What would the iss, prn, aud, and cid values represent in the boarding pass=
 example?

-- Mike

From: Nat Sakimura
Sent: December 19, 2012 9:32 PM
To: Mike Jones
CC: Anthony Nadalin, John Bradley, oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

I obviously disagree - if I did agree, I did not send it to the list to sta=
rt with :-)

"cid" (or in my original proposal, "reg") has a very clear and established =
meaning.
The parallel examples abounds in our daily life.

It has very little to do with On-behalf-of.
It is not a delegation statement.

"cid" is there to indicate to whom it was issued to.
The entity who was issued this "token" is eligible to use it at the
entities indicated by "aud".

Example in our real life are like:

- Airline boarding pass
- Registered instruments (bond / share)
- Monthly train pass
- Disneyland annual passport
 etc. etc.

Please do not mix it up with a delegation statement like on-behalf-of,
which is much less well defined.

Nat


On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones > wrote:
I'm with Tony on this.  This seems premature to put into the JWT standard. =
 All the other JWT claims have well established meanings and history behind=
 them.  These don't.

If the goal is to allow OpenID Connect implementations to not reject tokens=
 using "cid", there are lots of other ways to accomplish this that I think =
we should consider first.

-- Mike


From: John Bradley
Sent: December 19, 2012 6:25 PM
To: Anthony Nadalin
CC: oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

I agree, audience who requested it and and who it is requested for are all =
interrelated.

However we do need to set down some standard way of expressing it as people=
 are starting to make stuff up on their own that will impact interoperabili=
ty.

If Google starts thawing in cid and clients don't know about it they must r=
eject the JWT etc.

John

On 2012-12-19, at 9:40 PM, Anthony Nadalin > wrote:

It seems premature and we should consider this in the bigger context of the=
 "on behalf of"/delegation work that has been started

From: oauth-bounces@ietf.org [mailto:oauth-<=
mailto:oauth->bounces@ietf.org] On Behalf Of Nat S=
akimura
Sent: Tuesday, December 18, 2012 6:22 PM
To: oauth
Subject: [OAUTH-WG] "cid" claim in JWT

In OpenID Connect WG, we have been talking this for sometime.
"cid" claim identifies the entity that the JWT was issued to as a rightful/=
licensed user.
Google already uses this in their implementation of id_token of OIDC.

Here is the text proposal. It introduces two new standard claims: "cid" and=
 "cit".

It would be very useful in creating a HoK drafts as well.

Cheers,

Nat




4.1.9. "cid" Client Identification Data Claim



The "cid" (client identification data) claim allows the receiver

of the JWT to identify the entity that the JWT is

intended to be used by. The audience of the JWT MUST be

able to identify the client with the value of this claim.



The "cid" value is a case sensitive string containing a StringOrURI value.

This claim is OPTIONAL. If the entity processing the claim does not

identify the user of the JWT with the identifier in the "cid" claim value,

then the JWT MUST be rejected. The interpretation of the registered to

value is generally application specific.



A typical example of a registered to claim includes following:

* client_id that the audience can use to authenticate and

  identify the client.

* A base64url encoded JWK.

* A URL that points to the key material that the audience can use to

  authenticate the user of the JWT.



4.1.10 "cit" (Client Identification Data claim type)



The "cit" (Client Identification Data claim type) identifies the type

of the "cid" claim. It is a StringOrURI value. The defined values

are the following:



"client_id" The value of the "cid" claim is the Client ID of the client

that the audience of the JWT is able to use to authenticate the client.



"jwk" The value of the "cid" claim is a base64url encoded JWK of

the registered client.



"jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of

JSON web signature [JWS].



"x5u" The value of the "cid" claim is the URL that points to the public

key certificate of the registered client. The format of the content

that x5u points to is described in section 4.1.4 of the JSON Web Signature.

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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











I can’t see how you=
 think PRN is way under defined when SUB is not


 


From: Nat Sa=
kimura [mailto:sakimura@gmail.com]


Sent: Wednesday, December 19, 2012 11:43 PM

To: Mike Jones

Cc: Anthony Nadalin; John Bradley; oauth

Subject: Re: [OAUTH-WG] "cid" claim in JWT


 






As "prn" is way under-defined [1], there c=
an be two interpretations for "prn". 






 






Considering that "subject" is not a define=
d term (=3D dictionary term), and interpreting a boarding pass as:






 






"Japan Airlines authorizes JL002 to accept pass=
enger John Smith at the Gate B22 provided safety and other requirements are=
 met between the boarding time (14:30) and 10 minutes before the departure =
time (15:10)" 






 






then: 






 




iss: Japan Airlines




prn: JL002 (the flight number)






cid: John Smith (the passenger, who uses the boardin=
g pass)






aud: Gate B22 (Gate assigned to JL002)








nbf: 2012-12-31T14:30+9






exp: 2012-12-31T15:00+9






 






Alternatively, if we interpret the boarding pass as:=
 






 






"Japan Airlines authorizes John Smith to board =
JL002 at the Gate B22 provided safety and other requirements are met t=
he boarding time (14:30) and 10 minutes before the departure time (15:10)&q=
uot;"






 






iss: Japan Airlines






prn: John Smith






cid: John Smith






aud: Gate B22 (Gate assigned to JL002)







nbf: 2012-12-31T14:30+9






exp: 2012-12-31T15:00+9








 






This interpretation has lost some information while =
encoding into JWT, so prior one may be more appropriate. 





 






Either way, as "prn" lacks exact semantics=
, what goes into it is subject to interpretation while "cid" is v=
ery clearly defined. 






 






Let me give another example. 






 






An entitlement that says: "John Smith is allowe=
d to activate the system when Mary White presents this token (#1234) to the=
 System A" that is issued by the "ABC Corp"






 






iss: ABC Corp. 






jti: #1234






prn: John Smith






cid: Mary White






aud: System A






 






Note: this is not delegation nor on-behalf-of. =







 






More webby example: "John Smith authorizes phot=
o print service A to access photo archive service B for John Smith's photo =
#123 until 2013-04-01 for the sum of $100."






 






iss: John Smith's Authorization Server





prn: John Smith's photo #123






cid: Photo print service A






aud: photo archive service B






exp: 2013-04-01






 






Nat






 






[1]  4.1.6 "prn" defines its value as=
 what identifies:






 










"the subject of the JW=
T" 










 





This can be expanded by rep=
lacing "JWT" with its definition as <=
/p>





 





"the subject of the st=
ring consisting of multiple parts, the first being the Encoded JWT Header, =
plus additional parts depending upon the contents of the header,
 with the parts being separated by period ('.') characters, and each part c=
ontaining base64url encoded content."






 





Further, expanding "JW=
T Header", it will become 






 





"the subject of the st=
ring consisting of multiple parts, the first being the string represen=
ting a JSON object that describes the cryptographic operations applied
 to the string, plus additional parts depending upon the contents of the he=
ader, with the parts being separated by period ('.') characters, and each p=
art containing base64url encoded content."






 





To me, it is not clear what=
 it means. 








 







 




On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones <Michael.Jones@=
microsoft.com> wrote:










What would the iss, prn, aud, and cid values represent i=
n the boarding pass example?






 






-- Mike






 






From: Nat Sakimura

Sent: December 19, 2012 9:32 PM

To: Mike Jones

CC: Anthony Nadalin, John Bradley, oauth

Subject: Re: [OAUTH-WG] "cid" claim in J=
WT










 




I obviously disagree - if I did agree, I did not send it=
 to the list to start with :-)





 






"cid" (or in my original proposal, "reg&q=
uot;) has a very clear and established meaning. 






The parallel examples abounds in our daily life. 






 






It has very little to do with On-behalf-of. 






It is not a delegation statement. 






 






"cid" is there to indicate to whom it was issu=
ed to. 






The entity who was issued this "token" is elig=
ible to use it at the 






entities indicated by "aud". <=
/span>






 






Example in our real life are like: 






 






- Airline boarding pass






- Registered instruments (bond / share) =







- Monthly train pass






- Disneyland annual passport






 etc. etc. 






 






Please do not mix it up with a delegation statement like=
 on-behalf-of, 






which is much less well defined. =







 






Nat






 










 <=
/p>







On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:


















I'm with Tony on this.  This seems premature to put=
 into the JWT standard.  All the other JWT claims have well establishe=
d meanings and history behind them.  These don't.





 






If the goal is to allow OpenID Connect implementations t=
o not reject tokens using “cid”, there are lots of other w=
ays to accomplish this that I think we should consider first.






 






-- Mike






 






 














From: John Bradley

Sent: December 19, 2012 6:25 PM

To: Anthony Nadalin

CC: oauth






Subject: Re: [OAUTH-WG] "c=
id" claim in JWT












 




I agree, audience who requested it and and who it is req=
uested for are all interrelated.





 












However we do need to set down some standard way of expr=
essing it as people are starting to make stuff up on their own that will im=
pact interoperability.






 






If Google starts thawing in cid and clients don't know a=
bout it they must reject the JWT etc.






 






John






 






On 2012-12-19, at 9:40 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:




 










It seems premature and we=
 should consider this in the bigger context of the “on behalf of̶=
1;/delegation work that has been started







From: <=
a href=3D"mailto:oauth-bounces@ietf.org" target=3D"_blank">oauth-bounces@ie=
tf.org [mailto:oauth-bounces@ietf.org]&n=
bsp;On
 Behalf Of Nat Sakimura

Sent: Tuesday, December 18, 2012 6:22 PM

To: oauth

Subject: [OAUTH-WG] "cid" claim in JWT






 






In OpenID Connect WG, we have been talking this for =
sometime. 








"cid" claim identifies the entity that the=
 JWT was issued to as a rightful/licensed user. 










Google already uses this in their implementation of =
id_token of OIDC. 










 










Here is the text proposal. It introduces two new sta=
ndard claims: "cid" and "cit". 










 












 


4.1.9. "cid" Client Identificatio=
n Data Claim


 


The "cid" (client identification dat=
a) claim allows the receiver 


of the JWT to identify the entity that the JWT=
 is 


intended to be used by. The audience of the JW=
T MUST be 


able to identify the client with the value of =
this claim.


 


The "cid" value is a case sensitive string containing a StringOrURI value.


This claim is OPTIONAL. If the entity processi=
ng the claim does not 


identify the user of the JWT with the identifi=
er in the "cid" claim value, 


then the JWT MUST be rejected. The interpretat=
ion of the registered to 


value is generally application specific.


 


A typical example of a registered to claim inc=
ludes following: 


* client_id that the audience can use to authe=
nticate and 


  identify the client.


* A base64url encoded JWK. <=
/pre>

* A URL that points to the key material that t=
he audience can use to 


  authenticate the user of the JWT.<=
/span>


 


4.1.10 "cit" (Client Identificati=
on Data claim type)


 


The "cit" (Client Identification Dat=
a claim type) identifies the type 


of the "cid" claim. It is a StringOr=
URI value. The defined values 


are the following:


 


"client_id" The value of the "c=
id" claim is the Client ID of the client 


that the audience of the JWT is able to use to=
 authenticate the client.


 


"jwk" The value of the "cid&quo=
t; claim is a base64url encoded JWK of 


the registered client.


 


"jku" The value of the "cid&quo=
t; claim is the "jku" defined in 4.1.2 of 

JSON web signature [JWS].

 


"x5u" The value of the "cid&quo=
t; claim is the URL that points to the public 


key certificate of the registered client. The =
format of the content 


that x5u points to is described in section 4.1=
.4 of the JSON Web Signature.














 








-- 

Nat Sakimura (=3Dnat)








Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en








 








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








 





















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





















 




-- 

Nat Sakimura (=3Dnat) 




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en






















 




-- 

Nat Sakimura (=3Dnat)




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en








--_000_5f9e7e4fc15c470caf10ad3ef1643b6dBY2PR03MB041namprd03pro_--

From jricher@mitre.org  Thu Dec 20 10:20:23 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9123621F88DD for ; Thu, 20 Dec 2012 10:20:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.461
X-Spam-Level: 
X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.137,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9Q0Oxma+sGU for ; Thu, 20 Dec 2012 10:20:22 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id A09D121F88DC for ; Thu, 20 Dec 2012 10:20:22 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E8CD43501FD; Thu, 20 Dec 2012 13:20:22 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id ED62B1F0AB5; Thu, 20 Dec 2012 13:20:21 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 20 Dec 2012 13:20:21 -0500
Message-ID: <50D35671.5020906@mitre.org>
Date: Thu, 20 Dec 2012 13:18:25 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Nat Sakimura 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060204060501050703070802"
X-Originating-IP: [129.83.31.58]
Cc: oauth 
Subject: Re: [OAUTH-WG] draft-richer-oauth-instance-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 18:20:23 -0000

--------------060204060501050703070802
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I would be fine with a machine-readable "instance_id" parameter to be 
paired with the human-readable items that are in there today. However, 
since this is a value that goes to the Authorization Endpoint and 
therefore goes through the browser, it MUST always be treated as 
self-asserted by the client. As such, I don't see how it can be used as 
a security-related parameter. The client_id and redirect_uri can be used 
in this regard because they are registered and paired with other 
security mechanisms like a client_secret or equivalent. The instance_ 
parameters are, by their very definition, not provided at registration 
time.

That's not to say it's without utility - browser identifier strings are 
generally useful to servers and JS apps even though as an end user you 
can send basically whatever you want there.

  -- Justin

On 12/18/2012 09:47 PM, Nat Sakimura wrote:
> Justin,
>
> In addition to instance_name and instance_description, I think we need 
> collision resistant instance_id which can be cryptographically linked 
> to the instance so that it can actually be authenticated, in a similar 
> manner to what we do with the self-issued IdP in the OpenID Connect.
>
> My proposal is to create a public-private key pair at the install time 
> and use the sha256 of the public key as the instance_id.
>
> Note: If the client is going to talk to multiple entities, the 
> instance_id would have some privacy impact.
> We may need to generate the keypair for each entity that the client 
> talks to.
>
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>


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


  
    
  
  
    
I would be fine with a machine-readable
      "instance_id" parameter to be paired with the human-readable items
      that are in there today. However, since this is a value that goes
      to the Authorization Endpoint and therefore goes through the
      browser, it MUST always be treated as self-asserted by the client.
      As such, I don't see how it can be used as a security-related
      parameter. The client_id and redirect_uri can be used in this
      regard because they are registered and paired with other security
      mechanisms like a client_secret or equivalent. The instance_
      parameters are, by their very definition, not provided at
      registration time. 

      

      That's not to say it's without utility - browser identifier
      strings are generally useful to servers and JS apps even though as
      an end user you can send basically whatever you want there.

      

       -- Justin

      

      On 12/18/2012 09:47 PM, Nat Sakimura wrote:

    

    

      
      Justin, 
      


      

      
In addition to instance_name and instance_description, I
        think we need collision resistant instance_id which can be
        cryptographically linked to the instance so that it can actually
        be authenticated, in a similar manner to what we do with the
        self-issued IdP in the OpenID Connect. 

      


      

      
My proposal is to create a public-private key pair at the
        install time and use the sha256 of the public key as the
        instance_id.  

      


      

      
Note: If the client is going to talk to multiple entities,
        the instance_id would have some privacy impact. 

      
We may need to generate the keypair for each entity that the
        client talks to. 

        


        

        -- 

        Nat Sakimura (=nat)
        
Chairman, OpenID Foundation

          http://nat.sakimura.org/

          @_nat_en

        

      

    

    

  


--------------060204060501050703070802--

From sberyozkin@gmail.com  Thu Dec 20 13:49:21 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841BE21F8996 for ; Thu, 20 Dec 2012 13:49:21 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2bRfcXfd2io for ; Thu, 20 Dec 2012 13:49:20 -0800 (PST)
Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by ietfa.amsl.com (Postfix) with ESMTP id 75DE221F8994 for ; Thu, 20 Dec 2012 13:49:20 -0800 (PST)
Received: by mail-ea0-f178.google.com with SMTP id k11so1621142eaa.37 for ; Thu, 20 Dec 2012 13:49:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=KGhTfLWWp3FDnE+lI0k62V1hjslBSRq+KHG+ws1aLsQ=; b=mCG3w6w0GLfuFwK0U9TMkSB9kicGklxzgJGFa8m4dQcGgSR7E9PM4KWfksGzZfVie7 a5UNtdCBOopDYY/6zThRVrJHaJPapyQP+dxzoJZluhLdU0Q4Q1ODf2xgCwl3YFHdaVDY QQfmWL3oXiKuwIhShsAcHuDsHPDa5Dic8XxyQCpPL0dLdpWgrYCv+qX7Et7XzuK3cdwf RRdugBRNee3LCCAcUpAMMB/XDxAFydny/T0oPBUiFKdD7ofr8H3r2AB2/GM4jDTLDcTm tIiaNvaXxeb82k0WVN47ECWjtOjso3S0CrMs2XRqnCV0EgZpAGKkiF+IxNps2YJ56blf ogpg==
X-Received: by 10.14.225.194 with SMTP id z42mr26375702eep.22.1356040158126; Thu, 20 Dec 2012 13:49:18 -0800 (PST)
Received: from [192.168.2.5] ([89.100.190.113]) by mx.google.com with ESMTPS id z8sm17818777eeo.11.2012.12.20.13.49.16 (version=SSLv3 cipher=OTHER); Thu, 20 Dec 2012 13:49:17 -0800 (PST)
Message-ID: <50D387DB.4080608@gmail.com>
Date: Thu, 20 Dec 2012 21:49:15 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: "" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 20 Dec 2012 21:49:21 -0000

Hi Hannes, others,

I'd like to understand what is the difference between HOTK Symmetric [1] 
and MAC [2].

I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK 
Symmetric text can support MAC.

My main question at the moment: does HOTK (Symmetric) offer an 
alternative to MAC or is HOTK actually a higher-level token scheme which 
can support different types of tokens ?

thanks, Sergey

[1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02

From sakimura@gmail.com  Thu Dec 20 16:59:18 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0783121E8034 for ; Thu, 20 Dec 2012 16:59:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.038
X-Spam-Level: 
X-Spam-Status: No, score=-3.038 tagged_above=-999 required=5 tests=[AWL=0.560,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7kO8E7xY+pQ for ; Thu, 20 Dec 2012 16:59:17 -0800 (PST)
Received: from mail-ea0-f180.google.com (mail-ea0-f180.google.com [209.85.215.180]) by ietfa.amsl.com (Postfix) with ESMTP id C5F0121F8732 for ; Thu, 20 Dec 2012 16:59:16 -0800 (PST)
Received: by mail-ea0-f180.google.com with SMTP id f13so1535853eai.25 for ; Thu, 20 Dec 2012 16:59:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oHz3tRAAORVcgKT0lWk76R6olEBOLNoee6Fk2GLmCNU=; b=HN1KWejLSJw5l1GlvB0yOJStOQnNYy7WLV+XU1V/x2stlLokgJzZy78HzSAkQCpt/f KyNvIO8puwiCmMFuyy0RJkb6LIkoznzPbDi2LYMmbk8WfbbQ7MwPrN998E5diWgGR3vA kFPqMV8PBxpfOw8xqfir0sQpFagD30J+whJG6DjS6XFRqkYcb+3nUCvCWZoI6nq69zZl Wr5aQkMfrKWtXRZqfH/6mr1lMpjuB8uYTFtfbaSVq+6X+FyVVT4gyB0PP3i1+qGBDxbE FgnDX33JCZ3InRXHFIwC7WiTRARB8UGmZKu6ko5Nae8mAF+ltj381Z8WBpqRjpbNrIzU sn1Q==
MIME-Version: 1.0
Received: by 10.14.174.132 with SMTP id x4mr26972167eel.39.1356051555959; Thu, 20 Dec 2012 16:59:15 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Thu, 20 Dec 2012 16:59:15 -0800 (PST)
In-Reply-To: <50D35671.5020906@mitre.org>
References:  <50D35671.5020906@mitre.org>
Date: Fri, 21 Dec 2012 09:59:15 +0900
Message-ID: 
From: Nat Sakimura 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b621de24a435904d1525bc3
Cc: oauth 
Subject: Re: [OAUTH-WG] draft-richer-oauth-instance-00
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 00:59:18 -0000

--047d7b621de24a435904d1525bc3
Content-Type: text/plain; charset=ISO-8859-1

For plain OAuth, it would just be a self asserted identifier. (For the time
being.)

Once request object gets in, the situation changes, and for OpenID Connect,
the situation obviously is different.
In these cases, you can sign the request, and for OpenID Connect, the
response may be encrypted.

Nat

On Fri, Dec 21, 2012 at 3:18 AM, Justin Richer  wrote:

>  I would be fine with a machine-readable "instance_id" parameter to be
> paired with the human-readable items that are in there today. However,
> since this is a value that goes to the Authorization Endpoint and therefore
> goes through the browser, it MUST always be treated as self-asserted by the
> client. As such, I don't see how it can be used as a security-related
> parameter. The client_id and redirect_uri can be used in this regard
> because they are registered and paired with other security mechanisms like
> a client_secret or equivalent. The instance_ parameters are, by their very
> definition, not provided at registration time.
>
> That's not to say it's without utility - browser identifier strings are
> generally useful to servers and JS apps even though as an end user you can
> send basically whatever you want there.
>
>  -- Justin
>
>
> On 12/18/2012 09:47 PM, Nat Sakimura wrote:
>
> Justin,
>
>  In addition to instance_name and instance_description, I think we need
> collision resistant instance_id which can be cryptographically linked to
> the instance so that it can actually be authenticated, in a similar manner
> to what we do with the self-issued IdP in the OpenID Connect.
>
>  My proposal is to create a public-private key pair at the install time
> and use the sha256 of the public key as the instance_id.
>
>  Note: If the client is going to talk to multiple entities, the
> instance_id would have some privacy impact.
> We may need to generate the keypair for each entity that the client talks
> to.
>
>  --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

For plain OAuth, it would just be a self asserted identifier. (For the time=
 being.)=A0

Once request object gets in, the situation c=
hanges, and for OpenID Connect, the situation obviously is different.=A0

In these cases, you can sign the request, and for OpenID Connect, the =
response may be encrypted.=A0

Nat

On Fri, Dec 21, 2012 at 3:18 AM, Justin Richer <jricher=
@mitre.org> wrote:



 =20
   =20
 =20
  

    
I would be fine with a machine-readable
      "instance_id" parameter to be paired with the human-readabl=
e items
      that are in there today. However, since this is a value that goes
      to the Authorization Endpoint and therefore goes through the
      browser, it MUST always be treated as self-asserted by the client.
      As such, I don't see how it can be used as a security-related
      parameter. The client_id and redirect_uri can be used in this
      regard because they are registered and paired with other security
      mechanisms like a client_secret or equivalent. The instance_
      parameters are, by their very definition, not provided at
      registration time. 

      

      That's not to say it's without utility - browser identifier
      strings are generally useful to servers and JS apps even though as
      an end user you can send basically whatever you want there.

      

      =A0-- Justin


      

      On 12/18/2012 09:47 PM, Nat Sakimura wrote:

    

    

     =20
      Justin,=A0
      


      

      
In addition to instance_name and instance_description, I
        think we need collision resistant instance_id which can be
        cryptographically linked to the instance so that it can actually
        be authenticated, in a similar manner to what we do with the
        self-issued IdP in the OpenID Connect.=A0

      


      

      
My proposal is to create a public-private key pair at the
        install time and use the sha256 of the public key as the
        instance_id. =A0

      


      

      
Note: If the client is going to talk to multiple entities,
        the instance_id would have some privacy impact.=A0

      
We may need to generate the keypair for each entity that the
        client talks to.=A0

        


        

        -- 

        Nat Sakimura (=3Dnat)
        
Chairman, OpenID Foundation

          http://nat=
.sakimura.org/

          @_nat_en

        

      

    

    

  






-- 
Nat Sakimura=
 (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en




--047d7b621de24a435904d1525bc3--

From wmills_92105@yahoo.com  Thu Dec 20 21:30:11 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2044421E803C for ; Thu, 20 Dec 2012 21:30:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.184
X-Spam-Level: 
X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHbwWNO6e+Pk for ; Thu, 20 Dec 2012 21:30:10 -0800 (PST)
Received: from nm8.bullet.mail.bf1.yahoo.com (nm8.bullet.mail.bf1.yahoo.com [98.139.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 582E421E802E for ; Thu, 20 Dec 2012 21:30:10 -0800 (PST)
Received: from [98.139.212.150] by nm8.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 05:30:09 -0000
Received: from [98.139.212.195] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 05:30:09 -0000
Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 05:30:09 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 791791.30658.bm@omp1004.mail.bf1.yahoo.com
Received: (qmail 33840 invoked by uid 60001); 21 Dec 2012 05:30:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356067808; bh=hluB9nnFMB73zPDDVdshvs8xP97wrAJYKQofL5lfZrI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=V1tcoVwMz7BXxJ0+Phct2TUuGso7KTN2KEP02dHyqmydczvvZ9/48jxYuz4spHVk8zTKQ23WOxz8VbZPBlfdCgZpmXG8K5SBHfmpqRHQrsZ7lY2xbM70OKCTBw1L12M6GzUtoDPi41Xl6362a5N/EuBihi+oP98jcJmwYJbSDBw=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=FB0LDCB0XV5KNM78sBhe/C5sPz+SGc5DTjXhdYJo50g/UsnrfWaphlL5l1rYK0ue2pZk66HJRWQ/Ug71p6a74MkufQjp1ps1kOTuYZtPElBDJebdw2Q2KzfmZCg1ShAuvotn3M+uQB2tuCT2KjJ/Xz2LfExkNREr7h7XyJ73ptU=;
X-YMail-OSG: _qCL_BwVM1kD.E6AF7Sq6bsATPIYvPq3EIqCaradA5ZeP4m qoyICdu6F8O9H4lvdLB1PXzYWETqd1vL5QXi_BeL3sUpkXDic1cb_Cedu1.H rIoh8NvToG.spHc9loN3hrMYv5qIy3zPx2uc0xnHqjDeCmO0y51PH5Rlr5yT q3O7X_w4EpTt3sClZZkJNlELBjoLaCBpWg1k7OQ16DcDgq2TCj_G7yh_HQJV t3DVG.CC.hkj0ytZatV5a52wY6a1u9np8pr2KDU9A1oCjclvr4imhW4KV4cx jippBWkwS9Hj0Ofe3V8Cehjit8VROee9Y.sfgWg5pTYdNyWRPE_l0WyjjjlA AnOjXKBb6jnJYfTX2SXU2.OO66I.LWXuHlQJVgrQ8Uyv6DM.ogn69GY1Bpdr 3QXtUejO2A5cTBhF_XDZYfpExmwLl4cI1O7W2.1a1E.Y5zvzl7Fh9qXGKS.z u9Z8GOj8YoRIwKXTUFB8nF494R1dcYnTk7rZTHtBvqOC1MgCPR_wFBiOneGP _oXq57U.DvbdgD9_U_hLe
Received: from [99.31.212.42] by web31810.mail.mud.yahoo.com via HTTP; Thu, 20 Dec 2012 21:30:08 PST
X-Rocket-MIMEInfo: 001.001, TUFDIGFuZCBIT1RLIGRlc2NyaWJlIGRpZmZlcmVudCBwcm9wZXJ0aWVzIG9mIGEgdG9rZW4sIGFuZCBjb3VsZCBib3RoIGJlIHVzZWQgaW4gdGhlIHNhbWUgdG9rZW4uIMKgTUFDIHNwZWNpZmllcyBhIGJhc2ljIGZvcm1hdCBmb3IgYSBzaWduZWQgdG9rZW4gcGF5bG9hZCBhbmQgdHJhbnNhY3Rpb24uIMKgSE9USyBkZWZpbmVzIHBhcnQgb2YgYSB0b2tlbiBwYXlsb2FkLiDCoEhPVEsgcGF5bG9hZCBjYW4gYmUgY2FycmllZCBpbiBhIE1BQyB0b2tlbi4KCi1iaWxsCgoKX19fX19fX19fX19fX19fX19fX19fX18BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.129.483
References: <50D387DB.4080608@gmail.com>
Message-ID: <1356067808.32663.YahooMailNeo@web31810.mail.mud.yahoo.com>
Date: Thu, 20 Dec 2012 21:30:08 -0800 (PST)
From: William Mills 
To: Sergey Beryozkin , "" 
In-Reply-To: <50D387DB.4080608@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1935884094-435479364-1356067808=:32663"
Subject: Re: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 05:30:11 -0000

--1935884094-435479364-1356067808=:32663
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

MAC and HOTK describe different properties of a token, and could both be us=
ed in the same token. =A0MAC specifies a basic format for a signed token pa=
yload and transaction. =A0HOTK defines part of a token payload. =A0HOTK pay=
load can be carried in a MAC token.=0A=0A-bill=0A=0A=0A____________________=
____________=0A From: Sergey Beryozkin =0ATo: ""  =0ASent: Thursday, December 20, 2012 1:49 PM=
=0ASubject: [OAUTH-WG] Few questions about HOTK=0A =0AHi Hannes, others,=0A=
=0AI'd like to understand what is the difference between HOTK Symmetric [1]=
 and MAC [2].=0A=0AI'm reading about HOTK Symmetric and JWS profile and it =
seems like HOTK Symmetric text can support MAC.=0A=0AMy main question at th=
e moment: does HOTK (Symmetric) offer an alternative to MAC or is HOTK actu=
ally a higher-level token scheme which can support different types of token=
s ?=0A=0Athanks, Sergey=0A=0A[1] http://tools.ietf.org/html/draft-tschofeni=
g-oauth-hotk-01=0A[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-m=
ac-02=0A_______________________________________________=0AOAuth mailing lis=
t=0AOAuth@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/oauth
--1935884094-435479364-1356067808=:32663
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


MAC =
and HOTK describe different properties of a token, and could both be used i=
n the same token.  MAC specifies a basic format for a signed token pay=
load and transaction.  HOTK defines part of a token payload.  HOT=
K payload can be carried in a MAC token.

-bill

  
  
  <=
span style=3D"font-weight:bold;">From: Sergey Beryozkin
 <sberyozkin@gmail.com>
 To:=
 "<oauth@ietf.org>" <oauth@ietf.org> 
 Sent: Thursday, December 20, 2012 1:=
49 PM
 Subject: [OAUTH-=
WG] Few questions about HOTK
  
 
=0AHi Hannes, others,
I'd like to understand what is the difference between HOTK Symmetric =
[1] and MAC [2].

I'm reading about HOTK Symmetric and JWS profile an=
d it seems like HOTK Symmetric text can support MAC.

My main questio=
n at the moment: does HOTK (Symmetric) offer an alternative to MAC or is HO=
TK actually a higher-level token scheme which can support different types o=
f tokens ?

thanks, Sergey

[1] http://tools.ietf.org/html/draf=
t-tschofenig-oauth-hotk-01
[2] http://tools.ietf.org/html/draft-ietf-oau=
th-v2-http-mac-02
_______________________________________________
OAu=
th mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut=
h


 
 
  
--1935884094-435479364-1356067808=:32663--

From hannes.tschofenig@gmx.net  Fri Dec 21 02:43:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9B321F84D1 for ; Fri, 21 Dec 2012 02:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.98
X-Spam-Level: 
X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPVBbnZ4Ih4B for ; Fri, 21 Dec 2012 02:43:35 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id C78F921F8A8C for ; Fri, 21 Dec 2012 02:43:34 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.37]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M2rpw-1SurFz2P5y-00scxl for ; Fri, 21 Dec 2012 11:43:33 +0100
Received: (qmail 1101 invoked by uid 0); 21 Dec 2012 10:43:33 -0000
Received: from 213.162.68.139 by www023.gmx.net with HTTP; Fri, 21 Dec 2012 11:43:32 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
Date: Fri, 21 Dec 2012 11:43:32 +0100
From: "Hannes Tschofenig" 
In-Reply-To: <50D387DB.4080608@gmail.com>
Message-ID: <20121221104332.258510@gmx.net>
MIME-Version: 1.0
References: <50D387DB.4080608@gmail.com>
To: Sergey Beryozkin , oauth@ietf.org
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX18h1FsAQzQhnAvv0rOiQUjGIJR2FEOyhQXchwuJrX g9VB7DqGIKyIOPDQBl1BCZ3lZDcobNBgB1kw== 
Content-Transfer-Encoding: 8bit
X-GMX-UID: A1imcJ8FeSEqQZIAqXUh8kx+IGRvb0Cq
Subject: Re: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 10:43:35 -0000

Hi Sergey,

in draft version -01 of draft-tschofenig-oauth-hotk we also included an example description of how to support symmetric keys since draft version -00 only provided support for asymmetric keys. There are essentially three ways for proof of possession of the keying material supported in that document, namely: (a) asymmetric keys, (b) JWS using symmetric keys, and (c) MAC tokens.

The symmetric key approach using JWS addresses a number of the requirements listed in draft-tschofenig-oauth-security-01, including

 - unique key naming (based on the JWS kid)
 - algorithm indication (based on features provided by JWS) but not negotiation
 - replay protection (based on features provided by JWS)
 - key scoping based on features inherited from JWT
 - resource owner identity confidentiality (based on JWT)
 - keyed message digest computation based on JWS (which is much easier for implementers than the canonicalization approach).

The question about key transport from the Authorization Server to the Resource Server (via JWE) is only raised and not solved. 

Ciao
Hannes

-------- Original-Nachricht --------
> Datum: Thu, 20 Dec 2012 21:49:15 +0000
> Von: Sergey Beryozkin 
> An: "" 
> Betreff: [OAUTH-WG] Few questions about HOTK

> Hi Hannes, others,
> 
> I'd like to understand what is the difference between HOTK Symmetric [1] 
> and MAC [2].
> 
> I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK 
> Symmetric text can support MAC.
> 
> My main question at the moment: does HOTK (Symmetric) offer an 
> alternative to MAC or is HOTK actually a higher-level token scheme which 
> can support different types of tokens ?
> 
> thanks, Sergey
> 
> [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sberyozkin@gmail.com  Fri Dec 21 03:15:50 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D0121F8837 for ; Fri, 21 Dec 2012 03:15: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=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iyAauekO84g for ; Fri, 21 Dec 2012 03:15:44 -0800 (PST)
Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9A36F21F87E7 for ; Fri, 21 Dec 2012 03:15:43 -0800 (PST)
Received: by mail-la0-f51.google.com with SMTP id e4so4734114lag.24 for ; Fri, 21 Dec 2012 03:15:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=LRMHifQirEijvLX4K6SjaG9zG1hf7C4/OmccLTJPr/8=; b=Pxxi5zMTeiXnUQePbLjdKN17LAB+OBM7FqmS4OF5av6ITgDQW/8hrEWE9nT/aECrH6 j+FuCe/t0J3cfIuwpPd/73rFFtAb6psmS0Z2zGgAOZdToXsdxT5d+ZMYpAFRKWFScCnv +aAjJ12Whszj9nosXek3RgPEwrMH7orG7mpEqtR1PT6JDLaeQB3l50Vft+k7Dj0P7vlH sTM3sdDBYeZ9O+g7vB8GLQSpAuJLj+ssKz9iRQvHyhrQZ+Hg7Gokchlu/efyak4jnwcZ 07Zf5j14+dO1s9JQESwN3BfLMaMuZFrGobSRWxyqa+KbpXiC9TgxD4n2OoTYGB3aY/8f gvzA==
X-Received: by 10.112.27.33 with SMTP id q1mr5260280lbg.78.1356088542141; Fri, 21 Dec 2012 03:15:42 -0800 (PST)
Received: from [10.36.224.146] ([217.173.99.61]) by mx.google.com with ESMTPS id lr20sm4484849lab.17.2012.12.21.03.15.40 (version=SSLv3 cipher=OTHER); Fri, 21 Dec 2012 03:15:40 -0800 (PST)
Message-ID: <50D444DB.4000003@gmail.com>
Date: Fri, 21 Dec 2012 11:15:39 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: William Mills 
References: <50D387DB.4080608@gmail.com> <1356067808.32663.YahooMailNeo@web31810.mail.mud.yahoo.com>
In-Reply-To: <1356067808.32663.YahooMailNeo@web31810.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 11:15:50 -0000

On 21/12/12 05:30, William Mills wrote:
> MAC and HOTK describe different properties of a token, and could both be
> used in the same token. MAC specifies a basic format for a signed token
> payload and transaction. HOTK defines part of a token payload. HOTK
> payload can be carried in a MAC token.

Speaking of MAC, are you referring to
"mac" parameter within MAC Authorization payload representing a HOTK 
property ?

Cheers, Sergey

>
> -bill
>
> ------------------------------------------------------------------------
> *From:* Sergey Beryozkin 
> *To:* "" 
> *Sent:* Thursday, December 20, 2012 1:49 PM
> *Subject:* [OAUTH-WG] Few questions about HOTK
>
> Hi Hannes, others,
>
> I'd like to understand what is the difference between HOTK Symmetric [1]
> and MAC [2].
>
> I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK
> Symmetric text can support MAC.
>
> My main question at the moment: does HOTK (Symmetric) offer an
> alternative to MAC or is HOTK actually a higher-level token scheme which
> can support different types of tokens ?
>
> thanks, Sergey
>
> [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth
>
>

From sberyozkin@gmail.com  Fri Dec 21 03:30:01 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B3B21F85E8 for ; Fri, 21 Dec 2012 03:30:01 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EvTo+TILN6z for ; Fri, 21 Dec 2012 03:30:00 -0800 (PST)
Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by ietfa.amsl.com (Postfix) with ESMTP id 312E721F851B for ; Fri, 21 Dec 2012 03:30:00 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id p5so4747714lag.5 for ; Fri, 21 Dec 2012 03:29:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2r4fUl8Lm0UDjd01mPyYeksMikL9LJJcVgwJKpcy8Bk=; b=T7Tfl2nk09rgUFDv2TZOaRBw10kJWqlRyVKkPoAuHmxyOYYdU7q6lbn5+MyIObGy9f yVzsVeAwCjL/sRxPg/oVmdr/VCNvM+j8exfjTYeCSdT7yadc9gEv9WI226J9Yfb+Zokt BlvXhkfVvIWQljjn0hBTJ735yZCnqvcm12lGRCOfzKESEN+Hce3cUnj7HI+AKJ9+MXGB AmFKZRudM1T1cCUPAtb6PiKoFKbijr3jPZZZz8rn7mQrOFM/++KhP9/VYKdGIQd0EMLO jrgb/YiIYFHP47dFkyYdHobsAyj1P0nZiqADnx5OJ42zbkqcL1uUTbds9R2lJYEAbZv2 2G+g==
X-Received: by 10.112.26.70 with SMTP id j6mr3490633lbg.55.1356089399021; Fri, 21 Dec 2012 03:29:59 -0800 (PST)
Received: from [10.36.224.146] ([217.173.99.61]) by mx.google.com with ESMTPS id fb1sm4472688lbb.15.2012.12.21.03.29.56 (version=SSLv3 cipher=OTHER); Fri, 21 Dec 2012 03:29:57 -0800 (PST)
Message-ID: <50D44833.2030100@gmail.com>
Date: Fri, 21 Dec 2012 11:29:55 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Hannes Tschofenig 
References: <50D387DB.4080608@gmail.com> <20121221104332.258510@gmx.net>
In-Reply-To: <20121221104332.258510@gmx.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 11:30:01 -0000

Hi Hannes
On 21/12/12 10:43, Hannes Tschofenig wrote:
> Hi Sergey,
>
> in draft version -01 of draft-tschofenig-oauth-hotk we also included an example description of how to support symmetric keys since draft version -00 only provided support for asymmetric keys. There are essentially three ways for proof of possession of the keying material supported in that document, namely: (a) asymmetric keys, (b) JWS using symmetric keys, and (c) MAC tokens.
>
> The symmetric key approach using JWS addresses a number of the requirements listed in draft-tschofenig-oauth-security-01, including
>
>   - unique key naming (based on the JWS kid)
>   - algorithm indication (based on features provided by JWS) but not negotiation
>   - replay protection (based on features provided by JWS)
>   - key scoping based on features inherited from JWT
>   - resource owner identity confidentiality (based on JWT)
>   - keyed message digest computation based on JWS (which is much easier for implementers than the canonicalization approach).
>
> The question about key transport from the Authorization Server to the Resource Server (via JWE) is only raised and not solved.

I think I'm getting your earlier point now that HOTK and MAC are not 
equal in what they can offer, the concepts are somewhat orthogonal.

As far as MAC & HOTK are concerned, would be right to say that MAC offers:
- unique key naming (based on the MAC key id returned to the client)
- some support around replay protection based on Authorization MAC nonce 
& timestamp attributes
- key scoping ? (MAC attributes are bound to an access token which will 
expire)
- algorithm indication (ex, hmac-sha-1)

Note I'm not trying to prove MAC may be at the same level as JWS with 
respect to a number of HOTK properties that can be supported or the 
security requirements that can be met, rather I'd like to grasp what 
exactly MAC offers with respect to the HOTK discussion :-)

Cheers, Sergey

>
> Ciao
> Hannes
>
> -------- Original-Nachricht --------
>> Datum: Thu, 20 Dec 2012 21:49:15 +0000
>> Von: Sergey Beryozkin
>> An: ""
>> Betreff: [OAUTH-WG] Few questions about HOTK
>
>> Hi Hannes, others,
>>
>> I'd like to understand what is the difference between HOTK Symmetric [1]
>> and MAC [2].
>>
>> I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK
>> Symmetric text can support MAC.
>>
>> My main question at the moment: does HOTK (Symmetric) offer an
>> alternative to MAC or is HOTK actually a higher-level token scheme which
>> can support different types of tokens ?
>>
>> thanks, Sergey
>>
>> [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
>> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth

From wmills_92105@yahoo.com  Fri Dec 21 07:52:23 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B8121F85C3 for ; Fri, 21 Dec 2012 07:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.391
X-Spam-Level: 
X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=1.207,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Cu-UjxhgUdR for ; Fri, 21 Dec 2012 07:52:18 -0800 (PST)
Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with ESMTP id 76C1421F8775 for ; Fri, 21 Dec 2012 07:52:07 -0800 (PST)
Received: from [98.139.212.153] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 15:52:03 -0000
Received: from [98.139.212.240] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 15:52:03 -0000
Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 15:52:03 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 496142.16983.bm@omp1049.mail.bf1.yahoo.com
Received: (qmail 75935 invoked by uid 60001); 21 Dec 2012 15:52:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356105122; bh=Ilgf4Dza7eR3SxMvoET2SxpHZsQvX3f/ZoyYSgQxD4Y=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=hzWlMgt6vYgbbcrhS+y2IAi8qBNp+5J4J7taSzXudUyNex0Zm08K/EF9P/xWTXWFwsyyKmIi7WVhH2BujXKXUVFGtjGeXCd7kBt30gVjINouELodZnOfXJrqStQtuiopgIXqo5XuvJ3Fn7QncGH6hay7oUegXzfyuHHOHP15Kwo=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=L95feIlzMU+MmHVUmWkQzRv4r+kSgEfGrVAVNz7QZpcvVR/fTipCkrPt2dshPPHYVgxU5cJG3RBGh/GsF5whKOpVrluf0OYiOAo6de7ShfPasdwF7tsnUDhpT5EwxfwMGoe4lflx7ZqJQziD02KDYPpu3yiE/j/E+Ytk/eRUmmM=;
X-YMail-OSG: Q4JOkwIVM1mtJJv7TEht7Xa9muHvlYZO9GAgEI69l1qD7HN ebXWtGGjlsL7LrHI1LfUjIhjjLy.fm7laBiRaWy.v0sEetfYF_P0k_ozrCy3 wBNpzROwSY4wT5fwhGPIGJZCZA1rLRqHQp6Q7CkLBsOKRORSz_UmY1uApc3q FUDixFSSdn6PlXnaN0XstPRXkoQe.jeq2QEludguoql7kLu5KAf3F6H_r9gf vdS9C5H4cYxZGPG_BgRadYq.AAEkNuECpAYIlqd5hNlLYa3q9BYQYrUzeVrA 6IQiOL08gR5lYN9GD98KUXF.LAttjxKE7h_Bo3sIDkjohRxemsQdCyt5ndJO tiDu0jBVTZQGqnBFCD7m88kx2NeYQUXgD3tYPOO1zkA5oh8jNDM7EvgTqpPq nHApayIWqNzhiJYhQ1LYRLVsMSVM_FL2Uw_9qN59a1Q6o7xtsXM1q7Ym9PHA XDWimsxsNCIokpA2wTuDu3NfygMRR4D0RVIxJFyM1Iog7.u5lZJgumBfky.S 9yE1sZ6KttmWy_k9FJ70t
Received: from [99.31.212.42] by web31801.mail.mud.yahoo.com via HTTP; Fri, 21 Dec 2012 07:52:02 PST
X-Rocket-MIMEInfo: 001.001, SSB3YW50IHRvIGFyZ3VlIHRvIGNoYW5nZSB0aGF0LiDCoEkgdGhpbmsgdGhleSBzaG91bGQgYmUgc2VwYXJhdGUgYW5kIHRoYXQgdGhlIGZ1bGwgdG9rZW4gdHlwZSBkZWZpbml0aXVvbiBzaG91bGQgYmUgcmVtb3ZlZCwgZGVmaW5pbmcgb25seSB0aGUga2V5IGFzc2VydGlvbi4gwqBBTlkgdG9rZW4gdGhhdCBuZWVkcyBzaWduaW5nIGJ5IHRoZSBjbGllbnQgY291bGQgYmUgYW4gSE9LIHRva2VuLgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiBGcm9tOiAiemhvdS5zdWppbmdAenRlLmNvbS4BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.129.483
References: <1356067808.32663.YahooMailNeo@web31810.mail.mud.yahoo.com> 
Message-ID: <1356105122.60536.YahooMailNeo@web31801.mail.mud.yahoo.com>
Date: Fri, 21 Dec 2012 07:52:02 -0800 (PST)
From: William Mills 
To: "zhou.sujing@zte.com.cn" 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-368338466-1162671464-1356105122=:60536"
Cc: O Auth WG , SergeyBeryozkin 
Subject: Re: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 15:52:24 -0000

---368338466-1162671464-1356105122=:60536
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I want to argue to change that. =C2=A0I think they should be separate and t=
hat the full token type definitiuon should be removed, defining only the ke=
y assertion. =C2=A0ANY token that needs signing by the client could be an H=
OK token.=0A=0A=0A________________________________=0A From: "zhou.sujing@zt=
e.com.cn" =0ATo: William Mills  =0ACc: "" ; SergeyBeryo=
zkin  =0ASent: Thursday, December 20, 2012 11:46 PM=
=0ASubject: Re: Re: [OAUTH-WG] Few questions about HOTK=0A =0A=0A=0Aoauth-b=
ounces@ietf.org =E5=86=99=E4=BA=8E 2012-12-21 13:30:08:=0A=0A> MAC and HOTK=
 describe different properties of a token, and could =0A> both be used in t=
he same token. =C2=A0MAC specifies a basic format=0Afor a =0A> signed token=
 payload and transaction. =C2=A0HOTK defines part of a=0Atoken =0A> payload=
. =C2=A0HOTK payload can be carried in a MAC token. =0A> =0A> -bill =0A=0AH=
OTK and MAC are different token types, how can they=0Abe used in the same t=
oken? =0AWhat whould the token type be then?  =0A=0AMAC and HOTK-SK are rea=
lly very similar, they are=0Aactually alternative solutions to each other. =
 =0AThe meaning is HOTK is more high level.  =0A> =0A> From: Sergey Beryozk=
in =0A> To: ""  =0A> =
Sent: Thursday, December 20, 2012 1:49 PM=0A> Subject: [OAUTH-WG] Few quest=
ions about HOTK =0A> =0A> Hi Hannes, others,=0A> =0A> I'd like to understan=
d what is the difference between HOTK Symmetric=0A> [1] and MAC [2].=0A> =
=0A> I'm reading about HOTK Symmetric and JWS profile and it seems like =0A=
> HOTK Symmetric text can support MAC.=0A> =0A> My main question at the mom=
ent: does HOTK (Symmetric) offer an =0A> alternative to MAC or is HOTK actu=
ally a higher-level token scheme =0A> which can support different types of =
tokens ?=0A> =0A> thanks, Sergey=0A> =0A> [1] http://tools.ietf.org/html/dr=
aft-tschofenig-oauth-hotk-01=0A> [2] http://tools.ietf.org/html/draft-ietf-=
oauth-v2-http-mac-02=0A> _______________________________________________=0A=
> OAuth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/li=
stinfo/oauth=0A> =0A> _______________________________________________=0A> O=
Auth mailing list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listi=
nfo/oauth
---368338466-1162671464-1356105122=:60536
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

  
---368338466-1162671464-1356105122=:60536--

From wmills_92105@yahoo.com  Fri Dec 21 07:55:05 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8021F86C3 for ; Fri, 21 Dec 2012 07:55:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level: 
X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[AWL=0.603,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTizi1-ymfHi for ; Fri, 21 Dec 2012 07:55:03 -0800 (PST)
Received: from nm14.bullet.mail.bf1.yahoo.com (nm14.bullet.mail.bf1.yahoo.com [98.139.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 41F6221F870A for ; Fri, 21 Dec 2012 07:55:00 -0800 (PST)
Received: from [98.139.212.152] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 15:54:55 -0000
Received: from [98.139.212.214] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 15:54:55 -0000
Received: from [127.0.0.1] by omp1023.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 15:54:55 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 673248.69124.bm@omp1023.mail.bf1.yahoo.com
Received: (qmail 21600 invoked by uid 60001); 21 Dec 2012 15:54:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356105295; bh=d7JpGtOJAMoCDE+iWXavzydxVBAdIF7BWvbaXhGrTOE=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=ADHK5ee4uoniogHG2TMPVbGTJL4g8ZMjQZ/D6V81l1PKKUP7d1IMQw715JPBR7Pd74koMUY0IyLMNYx400AzaY05JUHkA/GLW0v9ERXNL7PETqjcVPZoIwiwupV2CYAJHHZ+wnMg720XI5BeRYGeijeh0OKbHqCMclMsmOFwtcc=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1PYMHH2+qjjYsClD85eYbriOxNvs15/69oKKd38LRx/SexGSdilB/mREiUF/4xvx4GAN5pcgbLz4RciAqt8r3hIF0LdzBVTRaLYa3NNq8yPj8rsYpkzN8AwbEV4jzFYcCzAKj7I+/KaViDGSb9Q/1nPpdE6QOKKlmsdzmcx9pYs=;
X-YMail-OSG: P.kwvIkVM1l8.9LVIlfhE43VRunxEguTHdPcekEEG2x2j6E buyk0Yn.iiqoXNF3D_drhv399tfRYUW5uLJyMGAPTfc0rnJbJiLPXsZ1MPhq Ld5NweN7xcoz73SK6nsHIaJCq2.2cdg8qTl3AnxsOusTjs4e7sUPB5Gy.Uf_ QghaJ6lf8rgKQa4LAgMyhg9qWMJ5UN_jzKzLUc12ppuzC7DOERkE1sQpal7O URVS9jnlPLw4YnS0Os3V7NV.NMxBnwLkEtIft.wFa1QKP6..a9Q_Azf5VyUe b9RdPn4OXBps05zzorz63YRsXGeBf8gBQB232FECRmXeCqm.j39awFpsNqd1 2CUSy0hcLQ1ynBgFSSqfKvxKXazQ2lPeWJfOlQaCiN.CI5o5X9.zvyf1OLFp ZYhfwll1igbYpbgM1TFWUwnWMgZZJRau0eZ0JqsUXLc3d7AdZ486F3t.Vrk0 eDq7lXlcS8pkPLBIW3GvPOqlG6CoH0v2jZX3awkQ8GcQMfx1b9f4bGWwXbXd vDt6RmtJfpfGET6MMK3M-
Received: from [99.31.212.42] by web31805.mail.mud.yahoo.com via HTTP; Fri, 21 Dec 2012 07:54:54 PST
X-Rocket-MIMEInfo: 001.001, Tm8sIE1BQyBhcyBJJ20gdXNpbmcgaXQgaXMgYSBNQUMgdG9rZW4gcGVywqBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXYyLWh0dHAtbWFjLTAyCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KIEZyb206IFNlcmdleSBCZXJ5b3praW4gPHNiZXJ5b3praW5AZ21haWwuY29tPgpUbzogV2lsbGlhbSBNaWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbT4gCkNjOiAiPG9hdXRoQGlldGYub3JnPiIgPG9hdXRoQGlldGYub3JnPiAKU2VudDogRnJpZGF5LCBEZWNlbWIBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.129.483
References: <50D387DB.4080608@gmail.com> <1356067808.32663.YahooMailNeo@web31810.mail.mud.yahoo.com> <50D444DB.4000003@gmail.com>
Message-ID: <1356105294.799.YahooMailNeo@web31805.mail.mud.yahoo.com>
Date: Fri, 21 Dec 2012 07:54:54 -0800 (PST)
From: William Mills 
To: Sergey Beryozkin 
In-Reply-To: <50D444DB.4000003@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-551393103-1994963244-1356105294=:799"
Cc: "" 
Subject: Re: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 15:55:06 -0000

---551393103-1994963244-1356105294=:799
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

No, MAC as I'm using it is a MAC token per=A0http://tools.ietf.org/html/dra=
ft-ietf-oauth-v2-http-mac-02=0A=0A=0A________________________________=0A Fr=
om: Sergey Beryozkin =0ATo: William Mills  =0ACc: ""  =0ASent: Friday, D=
ecember 21, 2012 3:15 AM=0ASubject: Re: [OAUTH-WG] Few questions about HOTK=
=0A =0AOn 21/12/12 05:30, William Mills wrote:=0A> MAC and HOTK describe di=
fferent properties of a token, and could both be=0A> used in the same token=
. MAC specifies a basic format for a signed token=0A> payload and transacti=
on. HOTK defines part of a token payload. HOTK=0A> payload can be carried i=
n a MAC token.=0A=0ASpeaking of MAC, are you referring to=0A"mac" parameter=
 within MAC Authorization payload representing a HOTK =0Aproperty ?=0A=0ACh=
eers, Sergey=0A=0A>=0A> -bill=0A>=0A> -------------------------------------=
-----------------------------------=0A> *From:* Sergey Beryozkin =0A> *To:* "" =0A> *Sent:* Thur=
sday, December 20, 2012 1:49 PM=0A> *Subject:* [OAUTH-WG] Few questions abo=
ut HOTK=0A>=0A> Hi Hannes, others,=0A>=0A> I'd like to understand what is t=
he difference between HOTK Symmetric [1]=0A> and MAC [2].=0A>=0A> I'm readi=
ng about HOTK Symmetric and JWS profile and it seems like HOTK=0A> Symmetri=
c text can support MAC.=0A>=0A> My main question at the moment: does HOTK (=
Symmetric) offer an=0A> alternative to MAC or is HOTK actually a higher-lev=
el token scheme which=0A> can support different types of tokens ?=0A>=0A> t=
hanks, Sergey=0A>=0A> [1] http://tools.ietf.org/html/draft-tschofenig-oauth=
-hotk-01=0A> [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02=
=0A> _______________________________________________=0A> OAuth mailing list=
=0A> OAuth@ietf.org =0A> https://www.ietf.org/mailma=
n/listinfo/oauth=0A>=0A>
---551393103-1994963244-1356105294=:799
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


No, MAC as I'm using it is a MAC token per http://tools.ietf.org/htm=
l/draft-ietf-oauth-v2-http-mac-02

  
 
 
  
  From:<=
/b> Sergey Beryozkin <sberyozkin@gmail.com>
 To: William Mills <wmills_92105@yahoo.com>=
; 
Cc: "<oauth@ietf.=
org>" <oauth@ietf.org> 
 =
Sent: Friday, December 21, 2012 3:15 AM
 Subject: Re: [OAUTH-WG] Few questions about HOTK
  
 
=0AOn 21/12/12 05:30, William Mills wrote:
> MAC and =
HOTK describe different properties of a token, and could both be
> us=
ed in the same token. MAC specifies a basic format for a signed token
&g=
t; payload and transaction. HOTK defines part of a token payload. HOTK
&=
gt; payload can be carried in a MAC token.

Speaking of MAC, are you =
referring to
"mac" parameter within MAC Authorization payload representi=
ng a HOTK 
property ?

Cheers, Sergey

>
> -bill>
> -------------------------------------------------------------=
-----------
> *From:* Sergey Beryozkin <sberyozkin@gmail.com<=
/a>>
> *To:* "<oauth@ietf.org>" <oauth@ietf.org>
> *Se=
nt:* Thursday, December
 20, 2012 1:49 PM
> *Subject:* [OAUTH-WG] Few questions about HOTK>
> Hi Hannes, others,
>
> I'd like to understand wha=
t is the difference between HOTK Symmetric [1]
> and MAC [2].
>=

> I'm reading about HOTK Symmetric and JWS profile and it seems like=
 HOTK
> Symmetric text can support MAC.
>
> My main quest=
ion at the moment: does HOTK (Symmetric) offer an
> alternative to MA=
C or is HOTK actually a higher-level token scheme which
> can support=
 different types of tokens ?
>
> thanks, Sergey
>
>=
 [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
> [2] =
http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
> ________=
_______________________________________
> OAuth mailing list
> =
OAuth@i=
etf.org <mailto:OAuth@ietf.org>
> https://www.i=
etf.org/mailman/listinfo/oauth
>
>


 
   

---551393103-1994963244-1356105294=:799--

From sberyozkin@gmail.com  Fri Dec 21 08:00:04 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACCC21F8712 for ; Fri, 21 Dec 2012 08:00:04 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5fBXaIP3VVI for ; Fri, 21 Dec 2012 08:00:03 -0800 (PST)
Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) by ietfa.amsl.com (Postfix) with ESMTP id F169921F86C3 for ; Fri, 21 Dec 2012 08:00:02 -0800 (PST)
Received: by mail-bk0-f49.google.com with SMTP id jm19so2527765bkc.36 for ; Fri, 21 Dec 2012 08:00:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VENBG2N2YUZuaQX+jclSINFSFBOeeoypnFdU0+3/cBQ=; b=BBBWUGXM2V21qsLvkd3q5JzYMyrps/cQFI7ss2wHY/RcnML9b9segt4Q8R6zNt0sn6 RGDNSmtXfsJCocLAxOJNgOA25gpYp1+vu+Rft4KobeNT5RIYFsRrmzmVXu0CtYcxsawc iU6I6cTVba/0U2fw71Jfz7lWx45PmDd5DLxHKPKvO5xSA5IM0cqSIn8r2wKV0LK8l6Zk yXadVX0OG1aVydL91hRBLpS+yyG3Nqzz9wIfSeEMswGe9RAiA81RnblFRgD5TViFutQ4 c3FrHEQjj5pjAooI5GJiifitJiOLeoKUGlsbJ5ELHrArm+3xjhb9yyDbK/cj0jsZnN9l aamw==
X-Received: by 10.204.147.67 with SMTP id k3mr6544717bkv.117.1356105602043; Fri, 21 Dec 2012 08:00:02 -0800 (PST)
Received: from [10.36.224.146] ([217.173.99.61]) by mx.google.com with ESMTPS id l17sm10499462bkw.12.2012.12.21.08.00.00 (version=SSLv3 cipher=OTHER); Fri, 21 Dec 2012 08:00:01 -0800 (PST)
Message-ID: <50D4877F.5090301@gmail.com>
Date: Fri, 21 Dec 2012 15:59:59 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: William Mills 
References: <50D387DB.4080608@gmail.com> <1356067808.32663.YahooMailNeo@web31810.mail.mud.yahoo.com> <50D444DB.4000003@gmail.com> <1356105294.799.YahooMailNeo@web31805.mail.mud.yahoo.com>
In-Reply-To: <1356105294.799.YahooMailNeo@web31805.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 16:00:04 -0000

On 21/12/12 15:54, William Mills wrote:
> No, MAC as I'm using it is a MAC token per
> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02

Sure, what do you mean though when saying
"HOTK payload can be carried in a MAC token." ?

I'm presuming you have in mind the parameters as defined in the draft, 
and specifically I thought it was the 'mac' attribute which is 
effectively a HOTK payload, possibly alongside few other Authorization 
MAC scheme attributes ?

Sergey

>
> ------------------------------------------------------------------------
> *From:* Sergey Beryozkin 
> *To:* William Mills 
> *Cc:* "" 
> *Sent:* Friday, December 21, 2012 3:15 AM
> *Subject:* Re: [OAUTH-WG] Few questions about HOTK
>
> On 21/12/12 05:30, William Mills wrote:
>  > MAC and HOTK describe different properties of a token, and could both be
>  > used in the same token. MAC specifies a basic format for a signed token
>  > payload and transaction. HOTK defines part of a token payload. HOTK
>  > payload can be carried in a MAC token.
>
> Speaking of MAC, are you referring to
> "mac" parameter within MAC Authorization payload representing a HOTK
> property ?
>
> Cheers, Sergey
>
>  >
>  > -bill
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Sergey Beryozkin  >
>  > *To:* ">"  >
>  > *Sent:* Thursday, December 20, 2012 1:49 PM
>  > *Subject:* [OAUTH-WG] Few questions about HOTK
>  >
>  > Hi Hannes, others,
>  >
>  > I'd like to understand what is the difference between HOTK Symmetric [1]
>  > and MAC [2].
>  >
>  > I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK
>  > Symmetric text can support MAC.
>  >
>  > My main question at the moment: does HOTK (Symmetric) offer an
>  > alternative to MAC or is HOTK actually a higher-level token scheme which
>  > can support different types of tokens ?
>  >
>  > thanks, Sergey
>  >
>  > [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
>  > [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
>  > _______________________________________________
>  > OAuth mailing list
>  > OAuth@ietf.org   >
>  > https://www.ietf.org/mailman/listinfo/oauth
>  >
>  >
>
>


From wmills_92105@yahoo.com  Fri Dec 21 08:32:58 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95CC21F87FD for ; Fri, 21 Dec 2012 08:32:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level: 
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qCxuFc3rJGki for ; Fri, 21 Dec 2012 08:32:58 -0800 (PST)
Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with ESMTP id B957F21F87F4 for ; Fri, 21 Dec 2012 08:32:57 -0800 (PST)
Received: from [98.139.212.151] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 16:32:57 -0000
Received: from [98.139.212.216] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 16:32:57 -0000
Received: from [127.0.0.1] by omp1025.mail.bf1.yahoo.com with NNFMP; 21 Dec 2012 16:32:57 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 37713.70975.bm@omp1025.mail.bf1.yahoo.com
Received: (qmail 12809 invoked by uid 60001); 21 Dec 2012 16:32:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356107576; bh=OlHEosJABPOMFJjJiZ/LXjQTgt0d7cS1kuJ/Ghttbz8=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=E/H88FKpg1wQWUf4dDxnV71kesO443DHWsFfOxMxWuJNOJ+jn9vpVqBjT4PZqHBaR0gzgPOz0jwRsBCchp/szNKxzG/SuSZllLWkXXDEc8vLCSP4wvDhB2dwlD1cyTLVcDS1xhYWiy109liaLlmQewWBaRWEDgCCPuVH7Bm/jQ4=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TgvHcyyIcUhM24Pg1WX3YRZFFyP2ioRGGtShtfcf7aroBRWDf1aGRjWGLDl+u1sa7Js2fPd6HO8qsaQAbGQje7wu7ms8z88zWa0hA+U5oxCOe+Mo+Mr4PzF0238RnWEcwT7HMR/OUFYaznAAghp3gxCUJZ+JBP7o9Cn7pTfSOVw=;
X-YMail-OSG: Hrkp9pMVM1m3ljmMtADsTg6mAGevRgeI119SWVdFN3q7nQk CSfX0vDhqDA9gIdqSvqtVULfZsK.Sy3.qxxs7TwuH5wHHz4DHtTbX3nU8ub1 hj_Vieh2L1e2uaKc8Mj0L4dpCb2AaKHYTmt7yeQ.7zplNRzLX3JTWdDtCwMy KDoDJmqoevLD9wg8ETTWj5KgA_ApD4ZPccI43q6qN2_Wnh8RwuxE4BuzZ.YP K5ciMr9vGZagwuM.BCkJC52L6tRFzQosdDZhPt_rPeCNhSOqGywY4dqYnb5z lHf2TaddA8OfoFLgm36EMaHWWYZC7xmp5zWsNVqdXnGERJxVAWMKUtwRSWYr nQuOi8hmpb8cES7OWibTuwaNzHFilDDufSDOW5ctzIecxhUDg2znxiiNrgLN R8abyX1a4QMfP1QbFsaExWeyu0RWGRODf5mma8QZ8ulWVhWvSbdSMbHH3Stl _9xNRSQiOCFLuk_QBKJ5CzccEyVlHpwQv.ZZu34a0VKC6m8evdz.fsZraq6V npyotrUtc8aa0ikST12bZ
Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Fri, 21 Dec 2012 08:32:56 PST
X-Rocket-MIMEInfo: 001.001, SSB3b3VsZCBmaW5kIHVzaW5nIGEgIm1hYyIgYXR0cmlidXRlIGluc2lkZSBhIE1BQyB0b2tlbiBjb25mdXNpbmcuIMKgSW5zaWRlIGEgTUFDIHRva2VuIG9yIGFueSBvdGhlciBjbGllbnQgc2lnbmVkIHRoaW5nIEknZCBwcm9iYWJseSBjYWxsIHRoZSBrZXlpbmcgYXNzZXJ0aW9uIGluc2lkZSAia2V5IiwgYW5kIG1ha2UgdGhlIHBheWxvYWQgb2YgdGhhdCBkZWZpbmVkIGJ5IHRva2VuIHR5cGUgc2luY2Ugc29tZSB0aGluZ3MgbGlrZSBFQyBoYXZlIG1vcmUgdGhhbiBvbmUgdmFsdWUgaW4gdGhlIGtleWluZyABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.129.483
References: <50D387DB.4080608@gmail.com> <1356067808.32663.YahooMailNeo@web31810.mail.mud.yahoo.com> <50D444DB.4000003@gmail.com> <1356105294.799.YahooMailNeo@web31805.mail.mud.yahoo.com> <50D4877F.5090301@gmail.com>
Message-ID: <1356107576.97442.YahooMailNeo@web31811.mail.mud.yahoo.com>
Date: Fri, 21 Dec 2012 08:32:56 -0800 (PST)
From: William Mills 
To: Sergey Beryozkin 
In-Reply-To: <50D4877F.5090301@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="764183289-1192844529-1356107576=:97442"
Cc: "" 
Subject: Re: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 16:32:58 -0000

--764183289-1192844529-1356107576=:97442
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

I would find using a "mac" attribute inside a MAC token confusing. =A0Insid=
e a MAC token or any other client signed thing I'd probably call the keying=
 assertion inside "key", and make the payload of that defined by token type=
 since some things like EC have more than one value in the keying informati=
on.=0A=0A=0A________________________________=0A From: Sergey Beryozkin =0ATo: William Mills  =0ACc: ""  =0ASent: Friday, December 21, 2012 7:59 AM=
=0ASubject: Re: [OAUTH-WG] Few questions about HOTK=0A =0AOn 21/12/12 15:54=
, William Mills wrote:=0A> No, MAC as I'm using it is a MAC token per=0A> h=
ttp://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02=0A=0ASure, what d=
o you mean though when saying=0A"HOTK payload can be carried in a MAC token=
." ?=0A=0AI'm presuming you have in mind the parameters as defined in the d=
raft, =0Aand specifically I thought it was the 'mac' attribute which is =0A=
effectively a HOTK payload, possibly alongside few other Authorization =0AM=
AC scheme attributes ?=0A=0ASergey=0A=0A>=0A> -----------------------------=
-------------------------------------------=0A> *From:* Sergey Beryozkin =0A> *To:* William Mills =0A> *=
Cc:* "" =0A> *Sent:* Friday, December 21, 2=
012 3:15 AM=0A> *Subject:* Re: [OAUTH-WG] Few questions about HOTK=0A>=0A> =
On 21/12/12 05:30, William Mills wrote:=0A>=A0 > MAC and HOTK describe diff=
erent properties of a token, and could both be=0A>=A0 > used in the same to=
ken. MAC specifies a basic format for a signed token=0A>=A0 > payload and t=
ransaction. HOTK defines part of a token payload. HOTK=0A>=A0 > payload can=
 be carried in a MAC token.=0A>=0A> Speaking of MAC, are you referring to=
=0A> "mac" parameter within MAC Authorization payload representing a HOTK=
=0A> property ?=0A>=0A> Cheers, Sergey=0A>=0A>=A0 >=0A>=A0 > -bill=0A>=A0 >=
=0A>=A0 > -----------------------------------------------------------------=
-------=0A>=A0 > *From:* Sergey Beryozkin  >=0A>=A0 > *To:* ">"  >=0A>=A0 > *Sent:* Thursd=
ay, December 20, 2012 1:49 PM=0A>=A0 > *Subject:* [OAUTH-WG] Few questions =
about HOTK=0A>=A0 >=0A>=A0 > Hi Hannes, others,=0A>=A0 >=0A>=A0 > I'd like =
to understand what is the difference between HOTK Symmetric [1]=0A>=A0 > an=
d MAC [2].=0A>=A0 >=0A>=A0 > I'm reading about HOTK Symmetric and JWS profi=
le and it seems like HOTK=0A>=A0 > Symmetric text can support MAC.=0A>=A0 >=
=0A>=A0 > My main question at the moment: does HOTK (Symmetric) offer an=0A=
>=A0 > alternative to MAC or is HOTK actually a higher-level token scheme w=
hich=0A>=A0 > can support different types of tokens ?=0A>=A0 >=0A>=A0 > tha=
nks, Sergey=0A>=A0 >=0A>=A0 > [1] http://tools.ietf.org/html/draft-tschofen=
ig-oauth-hotk-01=0A>=A0 > [2] http://tools.ietf.org/html/draft-ietf-oauth-v=
2-http-mac-02=0A>=A0 > _______________________________________________=0A>=
=A0 > OAuth mailing list=0A>=A0 > OAuth@ietf.org   >=0A>=A0 > https://www.ietf=
.org/mailman/listinfo/oauth=0A>=A0 >=0A>=A0 >=0A>=0A>
--764183289-1192844529-1356107576=:97442
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


I would find using a "mac" attribute inside a MAC token confusing.  =
Inside a MAC token or any other client signed thing I'd probably call the k=
eying assertion inside "key", and make the payload of that defined by token=
 type since some things like EC have more than one value in the keying info=
rmation.

  
 
 
  
  <=
b>From: Sergey Beryozkin <s=
beryozkin@gmail.com>
 To: William Mills <wmills_92105@yahoo.com> 
Cc: "<oauth@ietf.org>" <oauth@ietf.org> 
=
 Sent: Friday, December 21=
, 2012 7:59 AM
 Subject: Re: [OAUTH-WG] Few questions about HOTK
  
 
=0AOn 21/1=
2/12 15:54, William Mills wrote:
> No, MAC as I'm using it is a MAC t=
oken per
> http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02=


Sure, what do you mean though when saying
"HOTK payload can be c=
arried in a MAC token." ?

I'm presuming you have in mind the paramet=
ers as defined in the draft, 
and specifically I thought it was the 'mac=
' attribute which is 
effectively a HOTK payload, possibly alongside few=
 other Authorization 
MAC scheme attributes ?

Sergey

><=
br>> -------------------------------------------------------------------=
-----
> *From:* Sergey Beryozkin <sberyozkin@gmail.com>=
;
> *To:* William Mills <wmills_92105@yahoo.com>> *Cc:* "<oauth@ietf.org>" <oauth@ietf.org>=

> *Sent:* Friday, December 21, 2012 3:15 AM
> *Subject:* Re: [=
OAUTH-WG] Few questions about HOTK
>
> On 21/12/12 05:30, Willi=
am Mills wrote:
>  > MAC and HOTK describe different properti=
es of a token, and could both be
>  > used in the same token.=
 MAC specifies a basic format for a signed token
>  > payload=
 and transaction. HOTK defines part of a token payload. HOTK
>  =
> payload can be carried in a MAC token.
>
> Speaking of MAC=
, are you referring to
> "mac" parameter within MAC Authorization pay=
load representing a HOTK
> property ?
>
> Cheers, Sergey<=
br>>
>  >
>  > -bill
>  >
&=
gt;  >
 ------------------------------------------------------------------------>  > *From:* Sergey Beryozkin <sberyozkin@gmail.com
> <mailto:sberyozkin@gmail.com>>
>  &g=
t; *To:* "<oauth@ietf.org <mailto:oauth@ietf.org>>" <oauth@ietf.org> <mailto:oauth@ietf.org>>
>  > *Sent:* Thursday, =
December 20, 2012 1:49 PM
>  > *Subject:* [OAUTH-WG] Few ques=
tions about HOTK
>  >
>  > Hi Hannes, others,> 
 >
>  > I'd like to understand what is the difference betw=
een HOTK Symmetric [1]
>  > and MAC [2].
>  >>  > I'm reading about HOTK Symmetric and JWS profile and it s=
eems like HOTK
>  > Symmetric text can support MAC.
>&n=
bsp; >
>  > My main question at the moment: does HOTK (Sym=
metric) offer an
>  > alternative to MAC or is HOTK actually =
a higher-level token scheme which
>  > can support different =
types of tokens ?
>  >
>  > thanks, Sergey
&=
gt;  >
>  > [1] http://tools.ietf.org/html/draft-tsch=
ofenig-oauth-hotk-01
>  > [2] http://tools.ietf=
.org/html/draft-ietf-oauth-v2-http-mac-02
>  > __________=
_____________________________________
>  > OAuth mailing
 list
>  > OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:=
OAuth@i=
etf.org
> <mailto:OAuth@ietf.org>>
>  > https:=
//www.ietf.org/mailman/listinfo/oauth
>  >
>  =
>
>
>



 
 
  

--764183289-1192844529-1356107576=:97442--

From sakimura@gmail.com  Fri Dec 21 09:08:39 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A1321F85C6 for ; Fri, 21 Dec 2012 09:08:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.466
X-Spam-Level: 
X-Spam-Status: No, score=-0.466 tagged_above=-999 required=5 tests=[AWL=-1.868, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVRRj4g0Ufb2 for ; Fri, 21 Dec 2012 09:08:37 -0800 (PST)
Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by ietfa.amsl.com (Postfix) with ESMTP id AC89021F85A4 for ; Fri, 21 Dec 2012 09:08:36 -0800 (PST)
Received: by mail-ee0-f52.google.com with SMTP id d17so2506573eek.39 for ; Fri, 21 Dec 2012 09:08:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HLbPW8K59Gdy2xUF24zH0E6sH98QRKsY3nlZ8dIdvR8=; b=CN7kpkHXgMioJQMi9D89Rg3DcQKF+tjTOBovaW62xWOrLcQF2ABxgDwGcE18gpFaMg 7E9jvFx9jeCq3kYJmf6rL83vt5edHQc1HmTgE+CcvUPfSZ1zSTesWOR3FDE3HV1hegM+ i7/8p6BDPx8RgDJvzbaPOEcTXs2RvOpA023za4kn7zWgACadwsTUtAcJzUBBDIKq54++ fWObYtuEjF4h9VyKQFUAVlJnveFiuqxjdkicd4BLalxtgtPSh6Sm9YEAUFVrN7MsYlkA uaxdtgo8pn7GJj3WzKQqy5Va1zQdZBtfQEafrww/jXXNwNO8pAMmsxNLEJgMApC5CW2v K+Qg==
MIME-Version: 1.0
Received: by 10.14.206.197 with SMTP id l45mr33500586eeo.17.1356109715730; Fri, 21 Dec 2012 09:08:35 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Fri, 21 Dec 2012 09:08:35 -0800 (PST)
In-Reply-To: <5f9e7e4fc15c470caf10ad3ef1643b6d@BY2PR03MB041.namprd03.prod.outlook.com>
References: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.redmond.corp.microsoft.com>  <5f9e7e4fc15c470caf10ad3ef1643b6d@BY2PR03MB041.namprd03.prod.outlook.com>
Date: Sat, 22 Dec 2012 02:08:35 +0900
Message-ID: 
From: Nat Sakimura 
To: Anthony Nadalin 
Content-Type: multipart/alternative; boundary=047d7b34413ce1f19c04d15fe5a5
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 17:08:39 -0000

--047d7b34413ce1f19c04d15fe5a5
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

SUB is totally undefined, if I remember correctly.

Nat

On Fri, Dec 21, 2012 at 1:39 AM, Anthony Nadalin wro=
te:

>  I can=92t see how you think PRN is way under defined when SUB is not****
>
> ** **
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com]
> *Sent:* Wednesday, December 19, 2012 11:43 PM
> *To:* Mike Jones
> *Cc:* Anthony Nadalin; John Bradley; oauth
>
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT****
>
> ** **
>
> As "prn" is way under-defined [1], there can be two interpretations for
> "prn". ****
>
> ** **
>
> Considering that "subject" is not a defined term (=3D dictionary term), a=
nd
> interpreting a boarding pass as:****
>
> ** **
>
> "Japan Airlines authorizes JL002 to accept passenger John Smith at the
> Gate B22 provided safety and other requirements are met between the
> boarding time (14:30) and 10 minutes before the departure time (15:10)" *=
*
> **
>
> ** **
>
> then: ****
>
> ** **
>
> iss: Japan Airlines****
>
> prn: JL002 (the flight number)****
>
> cid: John Smith (the passenger, who uses the boarding pass)****
>
> aud: Gate B22 (Gate assigned to JL002)****
>
> nbf: 2012-12-31T14:30+9****
>
> exp: 2012-12-31T15:00+9****
>
> ** **
>
> Alternatively, if we interpret the boarding pass as: ****
>
> ** **
>
> "Japan Airlines authorizes John Smith to board JL002 at the Gate B22
> provided safety and other requirements are met the boarding time (14:30)
> and 10 minutes before the departure time (15:10)""****
>
> ** **
>
> iss: Japan Airlines****
>
> prn: John Smith****
>
> cid: John Smith****
>
> aud: Gate B22 (Gate assigned to JL002)****
>
> nbf: 2012-12-31T14:30+9****
>
> exp: 2012-12-31T15:00+9****
>
> ** **
>
> This interpretation has lost some information while encoding into JWT, so
> prior one may be more appropriate. ****
>
> ** **
>
> Either way, as "prn" lacks exact semantics, what goes into it is subject
> to interpretation while "cid" is very clearly defined. ****
>
> ** **
>
> Let me give another example. ****
>
> ** **
>
> An entitlement that says: "John Smith is allowed to activate the system
> when Mary White presents this token (#1234) to the System A" that is issu=
ed
> by the "ABC Corp"****
>
> ** **
>
> iss: ABC Corp. ****
>
> jti: #1234****
>
> prn: John Smith****
>
> cid: Mary White****
>
> aud: System A****
>
> ** **
>
> Note: this is not delegation nor on-behalf-of. ****
>
> ** **
>
> More webby example: "John Smith authorizes photo print service A to acces=
s
> photo archive service B for John Smith's photo #123 until 2013-04-01 for
> the sum of $100."****
>
> ** **
>
> iss: John Smith's Authorization Server****
>
> prn: John Smith's photo #123****
>
> cid: Photo print service A****
>
> aud: photo archive service B****
>
> exp: 2013-04-01****
>
> ** **
>
> Nat****
>
> ** **
>
> [1]  4.1.6 "prn" defines its value as what identifies:****
>
> ** **
>
> "the subject of the JWT" ****
>
>   ** **
>
> This can be expanded by replacing "JWT" with its definition as ****
>
> ** **
>
> "the subject of the string consisting of multiple parts, the first being
> the Encoded JWT Header, plus additional parts depending upon the contents
> of the header, with the parts being separated by period ('.') characters,
> and each part containing base64url encoded content."****
>
>  ** **
>
> Further, expanding "JWT Header", it will become ****
>
> ** **
>
> "the subject of the string consisting of multiple parts, the first being
> the string representing a JSON object that describes the cryptographic
> operations applied to the string, plus additional parts depending upon th=
e
> contents of the header, with the parts being separated by period ('.')
> characters, and each part containing base64url encoded content."****
>
>  ** **
>
> To me, it is not clear what it means. ****
>
> ** **
>
> ** **
>
> On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones 
> wrote:****
>
>   What would the iss, prn, aud, and cid values represent in the boarding
> pass example?****
>
>  ****
>
> -- Mike****
>
>  ****
>
> *From:* Nat Sakimura
> *Sent:* December 19, 2012 9:32 PM
> *To:* Mike Jones
> *CC:* Anthony Nadalin, John Bradley, oauth
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT****
>
>  ****
>
> I obviously disagree - if I did agree, I did not send it to the list to
> start with :-) ****
>
> ** **
>
> "cid" (or in my original proposal, "reg") has a very clear and establishe=
d
> meaning. ****
>
> The parallel examples abounds in our daily life. ****
>
> ** **
>
> It has very little to do with On-behalf-of. ****
>
> It is not a delegation statement. ****
>
> ** **
>
> "cid" is there to indicate to whom it was issued to. ****
>
> The entity who was issued this "token" is eligible to use it at the ****
>
> entities indicated by "aud". ****
>
> ** **
>
> Example in our real life are like: ****
>
> ** **
>
> - Airline boarding pass****
>
> - Registered instruments (bond / share) ****
>
> - Monthly train pass****
>
> - Disneyland annual passport****
>
>  etc. etc. ****
>
> ** **
>
> Please do not mix it up with a delegation statement like on-behalf-of, **=
*
> *
>
> which is much less well defined. ****
>
> ** **
>
> Nat****
>
> ** **
>
> ** **
>
> On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones 
> wrote:****
>
>    I'm with Tony on this.  This seems premature to put into the JWT
> standard.  All the other JWT claims have well established meanings and
> history behind them.  These don't.****
>
>  ****
>
> If the goal is to allow OpenID Connect implementations to not reject
> tokens using =93cid=94, there are lots of other ways to accomplish this t=
hat I
> think we should consider first.****
>
>  ****
>
> -- Mike****
>
>  ****
>
>  ****
>
> *From:* John Bradley
> *Sent:* December 19, 2012 6:25 PM
> *To:* Anthony Nadalin
> *CC:* oauth****
>
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT****
>
>  ****
>
> I agree, audience who requested it and and who it is requested for are al=
l
> interrelated. ****
>
> ** **
>
> However we do need to set down some standard way of expressing it as
> people are starting to make stuff up on their own that will impact
> interoperability.****
>
> ** **
>
> If Google starts thawing in cid and clients don't know about it they must
> reject the JWT etc.****
>
> ** **
>
> John****
>
> ** **
>
> On 2012-12-19, at 9:40 PM, Anthony Nadalin  wrote:=
*
> ***
>
> ** **
>
>   It seems premature and we should consider this in the bigger context of
> the =93on behalf of=94/delegation work that has been started****
>
>  ****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Tuesday, December 18, 2012 6:22 PM
> *To:* oauth
> *Subject:* [OAUTH-WG] "cid" claim in JWT****
>
>  ****
>
> In OpenID Connect WG, we have been talking this for sometime. ****
>
> "cid" claim identifies the entity that the JWT was issued to as a
> rightful/licensed user. ****
>
> Google already uses this in their implementation of id_token of OIDC. ***=
*
>
>  ****
>
> Here is the text proposal. It introduces two new standard claims: "cid"
> and "cit". ****
>
>  ****
>
> It would be very useful in creating a HoK drafts as well. ****
>
>  ****
>
> Cheers, ****
>
>  ****
>
> Nat****
>
>  ****
>
>  ****
>
> *4.1.9. "cid" Client Identification Data Claim*****
>
>  ****
>
> The "cid" (client identification data) claim allows the receiver ****
>
> of the JWT to identify the entity that the JWT is ****
>
> intended to be used by. The audience of the JWT MUST be ****
>
> able to identify the client with the value of this claim.****
>
>  ****
>
> The "cid" value is a case sensitive string containing a StringOrURI value=
.****
>
> This claim is OPTIONAL. If the entity processing the claim does not ****
>
> identify the user of the JWT with the identifier in the "cid" claim value=
, ****
>
> then the JWT MUST be rejected. The interpretation of the registered to **=
**
>
> value is generally application specific.****
>
>  ****
>
> A typical example of a registered to claim includes following: ****
>
> * client_id that the audience can use to authenticate and ****
>
>   identify the client.****
>
> * A base64url encoded JWK. ****
>
> * A URL that points to the key material that the audience can use to ****
>
>   authenticate the user of the JWT.****
>
>  ****
>
> *4.1.10 "cit" (Client Identification Data claim type)*****
>
>  ****
>
> The "cit" (Client Identification Data claim type) identifies the type ***=
*
>
> of the "cid" claim. It is a StringOrURI value. The defined values ****
>
> are the following:****
>
>  ****
>
> "client_id" The value of the "cid" claim is the Client ID of the client *=
***
>
> that the audience of the JWT is able to use to authenticate the client.**=
**
>
>  ****
>
> "jwk" The value of the "cid" claim is a base64url encoded JWK of ****
>
> the registered client.****
>
>  ****
>
> "jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of ****
>
> JSON web signature [JWS].****
>
>  ****
>
> "x5u" The value of the "cid" claim is the URL that points to the public *=
***
>
> key certificate of the registered client. The format of the content ****
>
> that x5u points to is described in section 4.1.4 of the JSON Web Signatur=
e.****
>
>     ****
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>  ****
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=3Dnat) ****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>



--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b34413ce1f19c04d15fe5a5
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

SUB is totally undefined, if I remember correctly.=A0

Na=
t

On Fri, Dec 21, 2012 at 1:39 AM, Anthon=
y Nadalin <tonynad@microsoft.com> wrote:













I can=92t see how you thi=
nk PRN is way under defined when SUB is not


=A0


From: Nat Sa=
kimura [mailto:saki=
mura@gmail.com]


Sent: Wednesday, December 19, 2012 11:43 PM

To: Mike Jones


Cc: Anthony Nadalin; John Bradley; oauth


Subject: Re: [OAUTH-WG] "cid" claim in JWT


=A0






As "prn" is way under-defined [1], there c=
an be two interpretations for "prn".=A0






=A0






Considering that "subject" is not a define=
d term (=3D dictionary term), and interpreting a boarding pass as:






=A0






"Japan Airlines authorizes JL002 to accept pass=
enger John Smith at the Gate B22 provided safety and other requirements are=
 met between the boarding time (14:30) and 10 minutes before the departure =
time (15:10)"=A0







=A0






then:=A0






=A0




iss: Japan Airlines




prn: JL002 (the flight number)






cid: John Smith (the passenger, who uses the boardin=
g pass)






aud:=A0Gate B22 (Gate assigned to JL002)








nbf: 2012-12-31T14:30+9






exp: 2012-12-31T15:00+9






=A0






Alternatively, if we interpret the boarding pass as:=
=A0






=A0






"Japan Airlines authorizes John Smith to board =
JL002 at the Gate B22 provided safety and other requirements are met=A0the =
boarding time (14:30) and 10 minutes before the departure time (15:10)"=
;"







=A0






iss: Japan Airlines






prn: John Smith






cid: John Smith






aud: Gate B22 (Gate assigned to JL002)=









nbf: 2012-12-31T14:30+9






exp: 2012-12-31T15:00+9








=A0






This interpretation has lost some information while =
encoding into JWT, so prior one may be more appropriate.=A0





=A0






Either way, as "prn" lacks exact semantics=
, what goes into it is subject to interpretation while "cid" is v=
ery clearly defined.=A0






=A0






Let me give another example.=A0






=A0






An entitlement that says: "John Smith is allowe=
d to activate the system when Mary White presents this token (#1234) to the=
 System A" that is issued by the "ABC Corp"






=A0






iss: ABC Corp.=A0






jti: #1234






prn: John Smith






cid: Mary White






aud: System A






=A0






Note: this is not delegation nor on-behalf-of.=A0=







=A0






More webby example: "John Smith authorizes phot=
o print service A to access photo archive service B for John Smith's ph=
oto #123 until 2013-04-01 for the sum of $100."






=A0






iss: John Smith's Authorization Server=







prn: John Smith's photo #123






cid: Photo print service A






aud: photo archive service B






exp: 2013-04-01






=A0






Nat






=A0






[1] =A04.1.6 "prn" defines its value as wh=
at identifies:






=A0










"the subject of the JW=
T"=A0










=A0





This can be expanded by rep=
lacing=A0"JWT" with its definition as=A0






=A0





"the subject of the st=
ring consisting of multiple parts, the first being the Encoded JWT Header, =
plus additional parts depending upon the contents of the header,
 with the parts being separated by period ('.') characters, and eac=
h part containing base64url encoded content."






=A0





Further, expanding "JW=
T Header", it will become=A0






=A0





"the subject of the st=
ring consisting of multiple parts, the first being the=A0string representin=
g a JSON object that describes the cryptographic operations applied
 to the string, plus additional parts depending upon the contents of the he=
ader, with the parts being separated by period ('.') characters, an=
d each part containing base64url encoded content."







=A0





To me, it is not clear what=
 it means.=A0








=A0







=A0




On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones <Michael.Jones@=
microsoft.com> wrote:










What would the iss, prn, aud, and cid values represent i=
n the boarding pass example?






=A0






-- Mike






=A0






From:=A0Nat Sakimura

Sent:=A0December 19, 2012 9:32 PM

To:=A0Mike Jones

CC:=A0Anthony Nadalin, John Bradley, oauth

Subject:=A0Re: [OAUTH-WG] "cid" claim in JWT<=
u>










=A0




I obviously disagree - if I did agree, I did not send it=
 to the list to start with :-)





=A0






"cid" (or in my original proposal, "reg&q=
uot;) has a very clear and established meaning.=A0






The parallel examples abounds in our daily life.=A0






=A0






It has very little to do with On-behalf-of.=A0=







It is not a delegation statement.=A0






=A0






"cid" is there to indicate to whom it was issu=
ed to.=A0






The entity who was issued this "token" is elig=
ible to use it at the=A0






entities indicated by "aud".=A0<=
/span>






=A0






Example in our real life are like:=A0






=A0






- Airline boarding pass






- Registered instruments (bond / share)=A0=







- Monthly train pass






- Disneyland annual passport






=A0etc. etc.=A0






=A0






Please do not mix it up with a delegation statement like=
 on-behalf-of,=A0






which is much less well defined.=A0=







=A0






Nat






=A0










=A0<=
/p>







On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones <Michael.Jones@mic=
rosoft.com> wrote:



















I'm with Tony on this.=A0 This seems premature to pu=
t into the JWT standard.=A0 All the other JWT claims have well established =
meanings and history behind them.=A0 These don't.<=
/p>






=A0






If the goal is to allow OpenID Connect implementations t=
o not reject tokens using=A0=93cid=94, there are lots of other ways to acco=
mplish this that I think we should consider first.







=A0






-- Mike






=A0






=A0














From:=A0John Bradley

Sent:=A0December 19, 2012 6:25 PM

To:=A0Anthony Nadalin

CC:=A0oauth






Subject:=A0Re: [OAUTH-WG] "cid&=
quot; claim in JWT













=A0




I agree, audience who requested it and and who it is req=
uested for are all interrelated.





=A0












However we do need to set down some standard way of expr=
essing it as people are starting to make stuff up on their own that will im=
pact interoperability.







=A0






If Google starts thawing in cid and clients don't kn=
ow about it they must reject the JWT etc.






=A0






John






=A0






On 2012-12-19, at 9:40 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:





=A0










It seems premature and we=
 should consider this in the bigger context of the =93on behalf of=94/deleg=
ation work that has been started








From:=A0oauth-bounces@ietf.=
org [mailto:oauth-bounces@ietf.org]=A0On
 Behalf Of=A0Nat Sakimura

Sent:=A0Tuesday, December 18, 2012 6:22 PM

To:=A0oauth

Subject:=A0[OAUTH-WG] "cid" claim in JWT<=
/u>






=A0






In OpenID Connect WG, we have been talking this for =
sometime.=A0








"cid" claim identifies the entity that the=
 JWT was issued to as a rightful/licensed user.=A0










Google already uses this in their implementation of =
id_token of OIDC.=A0










=A0










Here is the text proposal. It introduces two new sta=
ndard claims: "cid" and "cit".=A0










=A0












=A0


4.1.9. "cid" Client Identificatio=
n Data Claim


=A0


The "cid" (client identification dat=
a) claim allows the receiver 


of the JWT to identify the entity that the JWT=
 is 


intended to be used by. The audience of the JW=
T MUST be 


able to identify the client with the value of =
this claim.


=A0


The "cid" value is a case sensitive string containing a StringOrURI value.



This claim is OPTIONAL. If the entity processi=
ng the claim does not 


identify the user of the JWT with the identifi=
er in the "cid" claim value, 


then the JWT MUST be rejected. The interpretat=
ion of the registered to 


value is generally application specific.


=A0


A typical example of a registered to claim inc=
ludes following: 


* client_id that the audience can use to authe=
nticate and 


=A0=A0identify the client.


* A base64url encoded JWK. 


* A URL that points to the key material that t=
he audience can use to 


=A0=A0authenticate the user of the JWT.=



=A0


4.1.10 "cit" (Client Identificati=
on Data claim type)


=A0


The "cit" (Client Identification Dat=
a claim type) identifies the type 


of the "cid" claim. It is a StringOr=
URI value. The defined values 


are the following:


=A0


"client_id" The value of the "c=
id" claim is the Client ID of the client 


that the audience of the JWT is able to use to=
 authenticate the client.


=A0


"jwk" The value of the "cid&quo=
t; claim is a base64url encoded JWK of 


the registered client.

=A0


"jku" The value of the "cid&quo=
t; claim is the "jku" defined in 4.1.2 of 


JSON web signature [JWS].=



=A0


"x5u" The value of the "cid&quo=
t; claim is the URL that points to the public 


key certificate of the registered client. The =
format of the content 


that x5u points to is described in section 4.1=
.4 of the JSON Web Signature.














=A0








--=A0

Nat Sakimura (=3Dnat)








Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en








=A0








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








=A0






















_______________________________________________

OAuth mailing list

OAuth@ietf.org

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























=A0




-- 

Nat Sakimura (=3Dnat) 




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en
























=A0




-- 

Nat Sakimura (=3Dnat)




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en










-- 
Nat Sakimura=
 (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--047d7b34413ce1f19c04d15fe5a5--

From sberyozkin@gmail.com  Fri Dec 21 13:27:24 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7421F85FE for ; Fri, 21 Dec 2012 13:27:24 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k+sP4Jvju0a for ; Fri, 21 Dec 2012 13:27:24 -0800 (PST)
Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by ietfa.amsl.com (Postfix) with ESMTP id 896D021F858C for ; Fri, 21 Dec 2012 13:27:23 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id 15so2407175wgd.16 for ; Fri, 21 Dec 2012 13:27:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=zoeKWUiib+fvI9Ma49WzVSrO8K04MzMqkSEY5Wy1804=; b=05pwQISHoWPeQQ1JZMVjTnSM2YW+ghgLe6nuM7w0l1jRNhwSwZa3OdgUkrfAME1Gy/ zvLiv2evWFrVgvaJbxS0Gy08g6aI7VnDyPrP03J7vIpOXY/Sf1ensXVKc8gDhuYYO036 +0k6nUUpxaoH0Fp5A7ug7x5/2QX06odRU+1PVNky/TTu0zCZjELMiZAwvA4w4IubX1RP BEdviynNYNdX4JC3bYZ2ohcUzEL2jtBWk+DIsxXXK3RTcwqwTRpjtcXdEWzGvSCqgnI9 vofxadhh27lBLZFxDt01RUJqiv2J/6UeZywuVG+VIkvz4C89tt0iJMw/m7yvv5OftW8X nTeg==
X-Received: by 10.180.107.5 with SMTP id gy5mr7957041wib.30.1356125242658; Fri, 21 Dec 2012 13:27:22 -0800 (PST)
Received: from [192.168.2.5] ([89.100.190.113]) by mx.google.com with ESMTPS id s10sm20244480wiw.4.2012.12.21.13.27.20 (version=SSLv3 cipher=OTHER); Fri, 21 Dec 2012 13:27:21 -0800 (PST)
Message-ID: <50D4D437.2090600@gmail.com>
Date: Fri, 21 Dec 2012 21:27:19 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: William Mills 
References: <50D387DB.4080608@gmail.com> <1356067808.32663.YahooMailNeo@web31810.mail.mud.yahoo.com> <50D444DB.4000003@gmail.com> <1356105294.799.YahooMailNeo@web31805.mail.mud.yahoo.com> <50D4877F.5090301@gmail.com> <1356107576.97442.YahooMailNeo@web31811.mail.mud.yahoo.com>
In-Reply-To: <1356107576.97442.YahooMailNeo@web31811.mail.mud.yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [OAUTH-WG] Few questions about HOTK
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 21:27:24 -0000

On 21/12/12 16:32, William Mills wrote:
> I would find using a "mac" attribute inside a MAC token confusing.
> Inside a MAC token or any other client signed thing I'd probably call
> the keying assertion inside "key", and make the payload of that defined
> by token type since some things like EC have more than one value in the
> keying information.

OK. Actually, the draft uses "mac_key" to identify the key inside the 
token on the outbound path from the server, and "access_token" assumes 
the role of key identifier which is quite minimalistic, the access token 
has gone - the key has gone, hence the key scoping is supported...

"mac" is use on the path from a client to the server - but it is not 
part of the token as far as I understand - it is the client 
demonstration of the fact it received MAC token with the "mac_key" 
inside it; naming "mac_key" as simply "key" (which I read you 
suggesting) is a good idea IMHO

Sergey

>
> ------------------------------------------------------------------------
> *From:* Sergey Beryozkin 
> *To:* William Mills 
> *Cc:* "" 
> *Sent:* Friday, December 21, 2012 7:59 AM
> *Subject:* Re: [OAUTH-WG] Few questions about HOTK
>
> On 21/12/12 15:54, William Mills wrote:
>  > No, MAC as I'm using it is a MAC token per
>  > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
>
> Sure, what do you mean though when saying
> "HOTK payload can be carried in a MAC token." ?
>
> I'm presuming you have in mind the parameters as defined in the draft,
> and specifically I thought it was the 'mac' attribute which is
> effectively a HOTK payload, possibly alongside few other Authorization
> MAC scheme attributes ?
>
> Sergey
>
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Sergey Beryozkin  >
>  > *To:* William Mills  >
>  > *Cc:* ">"  >
>  > *Sent:* Friday, December 21, 2012 3:15 AM
>  > *Subject:* Re: [OAUTH-WG] Few questions about HOTK
>  >
>  > On 21/12/12 05:30, William Mills wrote:
>  > > MAC and HOTK describe different properties of a token, and could
> both be
>  > > used in the same token. MAC specifies a basic format for a signed token
>  > > payload and transaction. HOTK defines part of a token payload. HOTK
>  > > payload can be carried in a MAC token.
>  >
>  > Speaking of MAC, are you referring to
>  > "mac" parameter within MAC Authorization payload representing a HOTK
>  > property ?
>  >
>  > Cheers, Sergey
>  >
>  > >
>  > > -bill
>  > >
>  > >
> ------------------------------------------------------------------------
>  > > *From:* Sergey Beryozkin  
>  > >>
>  > > *To:* "
> >>"  
>  > >>
>  > > *Sent:* Thursday, December 20, 2012 1:49 PM
>  > > *Subject:* [OAUTH-WG] Few questions about HOTK
>  > >
>  > > Hi Hannes, others,
>  > >
>  > > I'd like to understand what is the difference between HOTK
> Symmetric [1]
>  > > and MAC [2].
>  > >
>  > > I'm reading about HOTK Symmetric and JWS profile and it seems like HOTK
>  > > Symmetric text can support MAC.
>  > >
>  > > My main question at the moment: does HOTK (Symmetric) offer an
>  > > alternative to MAC or is HOTK actually a higher-level token scheme
> which
>  > > can support different types of tokens ?
>  > >
>  > > thanks, Sergey
>  > >
>  > > [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
>  > > [2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
>  > > _______________________________________________
>  > > OAuth mailing list
>  > > OAuth@ietf.org   > 
>  > >>
>  > > https://www.ietf.org/mailman/listinfo/oauth
>  > >
>  > >
>  >
>  >
>
>
>

From peter@peter.de  Fri Dec 21 14:15:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F0621F845D for ; Fri, 21 Dec 2012 14:15:35 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsQ+AxK6QB17 for ; Fri, 21 Dec 2012 14:15:35 -0800 (PST)
Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8929521F84F5 for ; Fri, 21 Dec 2012 14:15:34 -0800 (PST)
Received: by mail-ea0-f179.google.com with SMTP id i12so2064767eaa.38 for ; Fri, 21 Dec 2012 14:15:33 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:x-gm-message-state; bh=S9SWr2mcI51LnFwj7wYrvqTBj2tkkEAiMwW+AzKnw3E=; b=VBddjxBZXmeqd0aoB8vWa3xo8aUfML9stfgw7iQVNUi3/UddOiS190wi9iDmAEkQOD BBzwJr3Yzk4UJIAwRraWZHRkTzxN/gX9MHw1+zJXFdqp1qT7jzebvQcfeHgMR2M87lXp rAt696UpyvyQ/G26ACHoQ7zJuvuBTFHSAPdwxhmK1z6rtNcD2klC34Kv8f4/1RtmmGKz dII2MDTrAOgQeMNiM52qdKn8XCzRBH9Mn+xw4YKxINnQVwa4WbFlm4Ukp00NfWwkSs+P WlZ6YUKNcrjNfx4RxZNtrC1aco8krOux7KUG3RMZbjkFD1pIwFFlZROG7lvIVX+6ncZi fdPw==
X-Received: by 10.14.2.196 with SMTP id 44mr35099957eef.25.1356128133326; Fri, 21 Dec 2012 14:15:33 -0800 (PST)
Received: from funmiraus.local (HSI-KBW-46-223-139-143.hsi.kabel-badenwuerttemberg.de. [46.223.139.143]) by mx.google.com with ESMTPS id q44sm24198256eep.5.2012.12.21.14.15.31 (version=SSLv3 cipher=OTHER); Fri, 21 Dec 2012 14:15:32 -0800 (PST)
Message-ID: <50D4DF81.4020101@peter.de>
Date: Fri, 21 Dec 2012 23:15:29 +0100
From: Peter Mauritius 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20121220 Thunderbird/19.0a2
MIME-Version: 1.0
To: oauth@ietf.org
Content-Type: multipart/alternative; boundary="------------090908010109020201000905"
X-Gm-Message-State: ALoCoQn2zCIv9IeGqF2fEWiv81/AryFzcQUPDav9WHuE95WY7t5o/cQvK+v+uyhJgA6Q2Du2GItZ
Subject: [OAUTH-WG]  Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 22:15:35 -0000

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

During the last week I had the chance to implement the non optional 
features of the token revokation draft. I would be glad if the document 
would get a closer connection to the refrenced RFC6749 regarding the 
error handling.

The draft states to use HTTP status 401 and 403 for certain error 
conditions. RFC6749 declares this as optional (OK, not for the 
Authorization header). The implemation of the token revokation endpoint 
in conjunction with a tokens endpoint would be much easier if there is a 
single way to handle exceptions which conforms to RFC6749.

Therefore I want to suggest to replace

> Status code 401 indicates a
>     failed client authentication, whereas a status code 403 is used if
>     the client is not authorized to revoke the particular token.  For all
>     other error conditions, a status code 400 is used along with an error
>     response as defined insection 5.2  . of [RFC6749  ].
with

    The error presentation conforms to the defintion in section 5.2 of
    [RFC6749].

To express the status code 403 I suggest to use the error code 
"unauthorized_client" of RFC6749 in conjunction with status code 400. 
The additional error codes defined in the draft will remain of course.

Happy apocalypse ;-)
   Peter Mauritius

--------------090908010109020201000905
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit


  

    
  
  
    During the last week I had the chance to implement the non optional
    features of the token revokation draft. I would be glad if the
    document would get a closer connection to the refrenced
    
    RFC6749 regarding the error handling. 

    

    The draft states to use HTTP status 401 and 403 for certain error
    conditions. RFC6749 declares this as optional (OK, not for the
    Authorization header). The implemation of the token revokation
    endpoint in conjunction with a tokens endpoint would be much easier
    if there is a single way to handle exceptions which conforms to
    RFC6749.

    

    Therefore I want to suggest to replace 

    

    

      
      
Status code 401 indicates a
   failed client authentication, whereas a status code 403 is used if
   the client is not authorized to revoke the particular token.  For all
   other error conditions, a status code 400 is used along with an error
   response as defined in section 5.2. of [RFC6749].  

    

    with

    
The error presentation conforms to the defintion in
      section 5.2 of [RFC6749]. 

    

    To express the status code 403 I suggest to use the error code
    "unauthorized_client" of RFC6749 in conjunction with status code
    400. The additional error codes defined in the draft will remain of
    course.

    

    Happy
    
    apocalypse ;-)

     Peter Mauritius

    
    
  


--------------090908010109020201000905--

From Jeff.Hodges@KingsMountain.com  Fri Dec 21 14:42:10 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B1121F882D for ; Fri, 21 Dec 2012 14:42:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.643
X-Spam-Level: 
X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOcUM7ViJjsD for ; Fri, 21 Dec 2012 14:42:09 -0800 (PST)
Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 1E4B721F87DF for ; Fri, 21 Dec 2012 14:42:09 -0800 (PST)
Received: (qmail 8709 invoked by uid 0); 21 Dec 2012 22:41:47 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 21 Dec 2012 22:41:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Ut0Bvx8ZQsoHHtqp20JTLX4+c6NFxXy0ch2/WfRp24w=;  b=vgBRGX/QG2A7CFofzBE8X3e36XUDAFoZDyY8QZfh3a1G0XlT2XbFMLfodc2wKliXOO1kZFMFxLvZ3BmuRqzyEYq1EDj6Sl5V5VaT2mRkAK5Z0xGKjvguYwvOEUpEBBeY;
Received: from [216.113.168.128] (port=28790 helo=[10.244.137.242]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TmBHn-0006Yi-Ad; Fri, 21 Dec 2012 15:41:47 -0700
Message-ID: <50D4E5AD.5020505@KingsMountain.com>
Date: Fri, 21 Dec 2012 14:41:49 -0800
From: =JeffH 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Mike Jones 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 22:42:10 -0000

 > Aah =96 I now see that this is the real misunderstanding.  The =93stri=
ng
 > representing a JSON object=94 is not the base64url encoded form =96 it=
=92s the
 > string representation that=92s parseable into a JSON object.

Thanks, yes, this is a key aspect of my difficulty in parsing the spec.

Though my misunderstanding is subtlety different than you characterized i=
t above.

Rather, it's that my understanding from RFC4627 is that a "JSON object" /=
is a=20
string/. Thus "string representing a JSON object" reads as "string repres=
enting=20
a string", which implied to me that the base64-encoded form was implied.

Since you don't mean to imply that, then yes, my suggestions re terminolo=
gy were=20
somewhat incorrect (apologies).

However, I have these revised suggestions..

 > The reason for the syntactic construction =93string representing a JSO=
N object=94
 > is that its string representation is distinct from the abstract JSON o=
bject
 > itself.

In RFC4627 there isn't an "abstract JSON object". It says..

    JavaScript Object Notation (JSON) is a text format for the
    serialization of structured data.
                   .
                   .
    A JSON text is a serialized object or array.


=2E.from which I understand the latter to mean..

    A JSON text is a string-serialized abstract object or array.


Unfortunately, the overloaded term "JSON object" appears to be used in so=
me=20
contexts to refer to programmatic artifacts (eg the "window.JSON" javascr=
ipt=20
object implemented in browsers), and in other contexts (such as Section "=
8.=20
Examples" in RFC4627) to refer to JSON texts.

So I suggest defining the term "JSON text object", which from nosing arou=
nd=20
seems to be also used in various other places/documents to refer to JSON =
texts=20
that match the "object" ABNF production in RFC4627 "Sec 2.2. Objects" (no=
te that=20
by definition a JSON text is a "serialized object or array" [RFC4627])..

    JSON text object   A JSON text matching the "object" ABNF production
       in Section 2.2 of [RFC4627]. JSON text objects MUST UTF-8 encoded.=



So instead of using the "string representing a JSON object" construct, th=
e JW*=20
specs could use "JSON text object" to refer to the non-base64-encoded thi=
ngs.=20
Then you have..

    JWT Claims Set  A JSON text object containing a set of claims. ...

    JWT Header  A JSON text object describing the
       cryptographic operations applied to the JWT. ...


And just to sketch out "claim" et al..

    Claim:  an assertion of something as a fact. Here, claims are
       name and value pairs, consisting of a Claim Name and a
       Claim Value. A claim is expressed as a JSON text object
       member (see Section "2.2. Objects" of [RFC4627]).

    Claim Name  The name portion of a claim.

    Claim Value  The value portion of a claim.


Then the definitions for the encoded things become simply...

    Encoded JWT Header  A Base64url encoded JWT Header.


The "bytes of the UTF-8 representation of the JWT {Header,Claims Set}" ph=
rasing=20
becomes just "JWT {Header,Claims Set}".



 > I disagree with redefining the term =93JWT=94 to not also include the =
signature.
 > The term =93JWT=94 should continue to refer to the whole thing.

Ok, but by defining a =93JWT=94 as being "signed or MACed and/or encrypte=
d", then=20
you have to go through extra contortions to define the so-called "Plainte=
xt=20
JWTs", which are ostensibly simply unsigned and unencrypted JWTs ("Plaint=
ext" is=20
sort of a misnomer). But perhaps you're doing this in order to encourage =
JWTs to=20
be signed and/or encrypted by default, it's difficult to tell.

Overall, to me, having these three related specs -- JWT - JWE - JWS, defi=
ning=20
three similar objects, and where a JWT is either..

   a profiled JWS, or profiled JWE, or           // "JWT"

   a profiled unsigned JWS, or                   // "Plaintext JWT"
I tend to think that defining a common base thing
   a JWS wrapping a JWT-profiled-JWE, or         // "nested JWT"

   a JWE wrapping a JWT-profiled-JWS             // "nested JWT"

=2E.is confusing. Perhaps laying it out concisely like the above would he=
lp.


 > > Semantics, profiles and relationship to SAML:
 >
 > Can you suggest some language you=92d like to see added about this?

the words I wrote the comments you were replying I trust will suffice to =
get you=20
started.


 > However once you add an issuer and a principal, then you=92re back to =
the JWT
 > being statements made by an entity about a subject.

sure, but note that what I was trying to say is that as defined in the JW=
T spec,=20
a JWT has /no/ semantics. All semantics are supplied by specs profiling t=
he JWT=20
spec (eg draft-ietf-oauth-jwt-bearer-03).

It's just a difference, not necessarily an advantage or disadvantage.


 > > terminology is not alphabetised!
 >
 > No, it=92s in a top-down descriptive order. Is there a requirement in =
IETF
 > specs that the terminology be alphabetized?

No there isn't AFAIK -- it's a personal preference (dunno about the RFC-e=
ditor,=20
but IIRC I've seen RFCs with non-alphabetized terminology sections).  Giv=
en the=20
way I read specs, non-alphabetized is harder for me.


 >> I found meager jwt comparison instructions at the very end of Section=
 7.
 >> it should probably be its own subsection. It should probably explicit=
ly say
 >> that JWTs need to be parsed into their constituent components, and th=
e
 >> latter must be individually examined/compared.
 >
 > We tried to cover this in the end of section 7, starting with the sent=
ence
 > =93Processing a JWT inevitably requires comparing known strings to val=
ues in the
 > token=94, which says how these comparisons must be performed. I agree =
that this
 > should become its own subsection. I don=92t understand your remark abo=
ut
 > constituent components. Can you clarify?

i meant decoding from base64 (and decrypting as necessary) and parsing in=
 order=20
to obtain claim name and value pairs.

 > How about =93Remove any JSON escaping from the input JSON string and c=
onvert
 > the string into a sequence of Unicode code points=94?

fine.


HTH,

=3DJeffH




From Michael.Jones@microsoft.com  Fri Dec 21 14:57:50 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F1421F88E8 for ; Fri, 21 Dec 2012 14:57:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.669
X-Spam-Level: 
X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuezLhxkuT82 for ; Fri, 21 Dec 2012 14:57:46 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0903021F8929 for ; Fri, 21 Dec 2012 14:57:45 -0800 (PST)
Received: from BY2FFO11FD001.protection.gbl (10.1.15.204) by BY2FFO11HUB030.protection.gbl (10.1.14.115) with Microsoft SMTP Server (TLS) id 15.0.586.12; Fri, 21 Dec 2012 22:57:43 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Fri, 21 Dec 2012 22:57:43 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Fri, 21 Dec 2012 22:57:21 +0000
From: Mike Jones 
To: '=JeffH' 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3fzngitD2k767bSqqKOnqgd4Kr1A==
Date: Fri, 21 Dec 2012 22:57:21 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394366997296@TK5EX14MBXC283.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.73]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366997296TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(43784002)(51914002)(51704002)(377454001)(13464002)(35774002)(164054002)(59766001)(44976002)(77982001)(54316002)(5343635001)(5343655001)(56816002)(74502001)(47446002)(31966008)(5343645001)(15202345001)(550184003)(51856001)(16297215001)(49866001)(74662001)(4396001)(46102001)(33656001)(55846006)(16236675001)(76482001)(47736001)(15395725002)(56776001)(54356001)(47976001)(512954001)(50986001)(53806001)(16406001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB030; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07025866F6
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 22:57:50 -0000

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

Thanks for the replies, Jeff.  They make sense.  Particularly, thanks for t=
he "JSON Text Object" suggestion.



For the "claims" definition, I'm actually prone to go with definitions base=
d on those in http://openid.net/specs/openid-connect-messages-1_0-13.html#t=
erminology - specifically:


Claim
A piece of information about an Entity that a Claims Provider asserts about=
 that Entity.
Claims Provider
A system or service that can return Claims about an Entity.
End-User
A human user of a system or service.
Entity
Something that has a separate and distinct existence and that can be identi=
fied in context. An End-User is one example of an Entity.



Comments?



                                                            Thanks again,

                                                            -- Mike



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

From: =3DJeffH [mailto:Jeff.Hodges@KingsMountain.com]

Sent: Friday, December 21, 2012 2:42 PM

To: Mike Jones

Cc: IETF oauth WG

Subject: RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05





> Aah - I now see that this is the real misunderstanding.  The "string  > r=
epresenting a JSON object" is not the base64url encoded form - it's the  > =
string representation that's parseable into a JSON object.



Thanks, yes, this is a key aspect of my difficulty in parsing the spec.



Though my misunderstanding is subtlety different than you characterized it =
above.



Rather, it's that my understanding from RFC4627 is that a "JSON object" /is=
 a string/. Thus "string representing a JSON object" reads as "string repre=
senting a string", which implied to me that the base64-encoded form was imp=
lied.



Since you don't mean to imply that, then yes, my suggestions re terminology=
 were somewhat incorrect (apologies).



However, I have these revised suggestions..



> The reason for the syntactic construction "string representing a JSON obj=
ect"

> is that its string representation is distinct from the abstract JSON obje=
ct  > itself.



In RFC4627 there isn't an "abstract JSON object". It says..



    JavaScript Object Notation (JSON) is a text format for the

    serialization of structured data.

                   .

                   .

    A JSON text is a serialized object or array.





..from which I understand the latter to mean..



    A JSON text is a string-serialized abstract object or array.





Unfortunately, the overloaded term "JSON object" appears to be used in some=
 contexts to refer to programmatic artifacts (eg the "window.JSON" javascri=
pt object implemented in browsers), and in other contexts (such as Section =
"8.

Examples" in RFC4627) to refer to JSON texts.



So I suggest defining the term "JSON text object", which from nosing around=
 seems to be also used in various other places/documents to refer to JSON t=
exts that match the "object" ABNF production in RFC4627 "Sec 2.2. Objects" =
(note that by definition a JSON text is a "serialized object or array" [RFC=
4627])..



    JSON text object   A JSON text matching the "object" ABNF production

       in Section 2.2 of [RFC4627]. JSON text objects MUST UTF-8 encoded.





So instead of using the "string representing a JSON object" construct, the =
JW* specs could use "JSON text object" to refer to the non-base64-encoded t=
hings.

Then you have..



    JWT Claims Set  A JSON text object containing a set of claims. ...



    JWT Header  A JSON text object describing the

       cryptographic operations applied to the JWT. ...





And just to sketch out "claim" et al..



    Claim:  an assertion of something as a fact. Here, claims are

       name and value pairs, consisting of a Claim Name and a

       Claim Value. A claim is expressed as a JSON text object

       member (see Section "2.2. Objects" of [RFC4627]).



    Claim Name  The name portion of a claim.



    Claim Value  The value portion of a claim.





Then the definitions for the encoded things become simply...



    Encoded JWT Header  A Base64url encoded JWT Header.





The "bytes of the UTF-8 representation of the JWT {Header,Claims Set}" phra=
sing becomes just "JWT {Header,Claims Set}".







> I disagree with redefining the term "JWT" to not also include the signatu=
re.

> The term "JWT" should continue to refer to the whole thing.



Ok, but by defining a "JWT" as being "signed or MACed and/or encrypted", th=
en

you have to go through extra contortions to define the so-called "Plaintext

JWTs", which are ostensibly simply unsigned and unencrypted JWTs ("Plaintex=
t" is

sort of a misnomer). But perhaps you're doing this in order to encourage JW=
Ts to

be signed and/or encrypted by default, it's difficult to tell.



Overall, to me, having these three related specs -- JWT - JWE - JWS, defini=
ng

three similar objects, and where a JWT is either..



   a profiled JWS, or profiled JWE, or           // "JWT"



   a profiled unsigned JWS, or                   // "Plaintext JWT"

I tend to think that defining a common base thing

   a JWS wrapping a JWT-profiled-JWE, or         // "nested JWT"



   a JWE wrapping a JWT-profiled-JWS             // "nested JWT"



..is confusing. Perhaps laying it out concisely like the above would help.





> > Semantics, profiles and relationship to SAML:

>

> Can you suggest some language you'd like to see added about this?



the words I wrote the comments you were replying I trust will suffice to ge=
t you

started.





> However once you add an issuer and a principal, then you're back to the J=
WT

> being statements made by an entity about a subject.



sure, but note that what I was trying to say is that as defined in the JWT =
spec,

a JWT has /no/ semantics. All semantics are supplied by specs profiling the=
 JWT

spec (eg draft-ietf-oauth-jwt-bearer-03).



It's just a difference, not necessarily an advantage or disadvantage.





> > terminology is not alphabetised!

>

> No, it's in a top-down descriptive order. Is there a requirement in IETF

> specs that the terminology be alphabetized?



No there isn't AFAIK -- it's a personal preference (dunno about the RFC-edi=
tor,

but IIRC I've seen RFCs with non-alphabetized terminology sections).  Given=
 the

way I read specs, non-alphabetized is harder for me.





>> I found meager jwt comparison instructions at the very end of Section 7.

>> it should probably be its own subsection. It should probably explicitly =
say

>> that JWTs need to be parsed into their constituent components, and the

>> latter must be individually examined/compared.

>

> We tried to cover this in the end of section 7, starting with the sentenc=
e

> "Processing a JWT inevitably requires comparing known strings to values i=
n the

> token", which says how these comparisons must be performed. I agree that =
this

> should become its own subsection. I don't understand your remark about

> constituent components. Can you clarify?



i meant decoding from base64 (and decrypting as necessary) and parsing in o=
rder

to obtain claim name and value pairs.



> How about "Remove any JSON escaping from the input JSON string and conver=
t

> the string into a sequence of Unicode code points"?



fine.





HTH,



=3DJeffH







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











Thanks for the replies, Jeff.  They make sen=
se.  Particularly, thanks for the “JSON Text Object” sugge=
stion.


 


For the "claims" definition, I'm actual=
ly prone to go with definitions based on those in

http://openid.net/specs/openid-connect-messages-1_0-13.html#terminology=
 – specifically:


 


Claim


A piece of information about an Entity that a Claims Provider=
 asserts about that Entity.


Claims Provider=



A system or service that can return Claims about an Entity.


End-User


A human user of a system or service.


Entity


Something that has a separate and distinct existence and that=
 can be identified in context. An End-User is one example of
 an Entity.


 


Comments?


 


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


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


 


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


From: =3DJeffH [mailto:Jeff.Hodges@KingsMountain.=
com] 



Sent: Friday, December 21, 2012 2:42 PM


To: Mike Jones


Cc: IETF oauth WG


Subject: RE: [OAUTH-WG] review: draft-ietf-oauth-=
json-web-token-05


 


 


> Aah – I now see that this is the real =
misunderstanding.  The “string  > representing a JSON ob=
ject” is not the base64url encoded form – it’s the  =
> string representation that’s parseable into a JSON object.<=
/o:p>


 


Thanks, yes, this is a key aspect of my difficult=
y in parsing the spec.


 


Though my misunderstanding is subtlety different =
than you characterized it above.


 


Rather, it's that my understanding from RFC4627 i=
s that a "JSON object" /is a string/. Thus "string represent=
ing a JSON object" reads as "string representing a string", =
which implied to me that the base64-encoded form was implied.

 


Since you don't mean to imply that, then yes, my =
suggestions re terminology were somewhat incorrect (apologies).<=
/p>

 


However, I have these revised suggestions..<=
/o:p>


 


> The reason for the syntactic construction &#=
8220;string representing a JSON object”


> is that its string representation is distinc=
t from the abstract JSON object  > itself.


 


In RFC4627 there isn't an "abstract JSON obj=
ect". It says..


 


    JavaScript Object Notation (JS=
ON) is a text format for the


    serialization of structured da=
ta.


        &=
nbsp;          .

        &=
nbsp;          .

    A JSON text is a serialized ob=
ject or array.


 


 


..from which I understand the latter to mean..


 


    A JSON text is a string-serial=
ized abstract object or array.


 


 


Unfortunately, the overloaded term "JSON obj=
ect" appears to be used in some contexts to refer to programmatic arti=
facts (eg the "window.JSON" javascript object implemented in brow=
sers), and in other contexts (such as Section "8.



Examples" in RFC4627) to refer to JSON texts=
.


 


So I suggest defining the term "JSON text ob=
ject", which from nosing around seems to be also used in various other=
 places/documents to refer to JSON texts that match the "object" =
ABNF production in RFC4627 "Sec 2.2. Objects" (note that
 by definition a JSON text is a "serialized object or array" [RFC=
4627])..


 


    JSON text object   A=
 JSON text matching the "object" ABNF production


       in Section 2=
.2 of [RFC4627]. JSON text objects MUST UTF-8 encoded.


 


 


So instead of using the "string representing=
 a JSON object" construct, the JW* specs could use "JSON text obj=
ect" to refer to the non-base64-encoded things.



Then you have..


 


    JWT Claims Set  A JSON te=
xt object containing a set of claims. ...


 


    JWT Header  A JSON text o=
bject describing the


       cryptographi=
c operations applied to the JWT. ...


 


 


And just to sketch out "claim" et al..<=
o:p>


 


    Claim:  an assertion of s=
omething as a fact. Here, claims are


       name and val=
ue pairs, consisting of a Claim Name and a


       Claim Value.=
 A claim is expressed as a JSON text object


       member (see =
Section "2.2. Objects" of [RFC4627]).


 


    Claim Name  The name port=
ion of a claim.


 


    Claim Value  The value po=
rtion of a claim.


 


 


Then the definitions for the encoded things becom=
e simply...


 


    Encoded JWT Header  A Bas=
e64url encoded JWT Header.


 


 


The "bytes of the UTF-8 representation of th=
e JWT {Header,Claims Set}" phrasing becomes just "JWT {Header,Cla=
ims Set}".


 


 


 


> I disagree with redefining the term “J=
WT” to not also include the signature.


> The term “JWT” should continue t=
o refer to the whole thing.


 


Ok, but by defining a “JWT” as being =
"signed or MACed and/or encrypted", then



you have to go through extra contortions to defin=
e the so-called "Plaintext



JWTs", which are ostensibly simply unsigned =
and unencrypted JWTs ("Plaintext" is



sort of a misnomer). But perhaps you're doing thi=
s in order to encourage JWTs to



be signed and/or encrypted by default, it's diffi=
cult to tell.


 


Overall, to me, having these three related specs =
-- JWT - JWE - JWS, defining



three similar objects, and where a JWT is either.=
.


 


   a profiled JWS, or profiled JWE, or&=
nbsp;          // "JWT&qu=
ot;


 


   a profiled unsigned JWS, or &nb=
sp;            =
     // "Plaintext JWT"


I tend to think that defining a common base thing=



   a JWS wrapping a JWT-profiled-JWE, o=
r         // "nested JWT"=



 


   a JWE wrapping a JWT-profiled-JWS&nb=
sp;            // &q=
uot;nested JWT"


 


..is confusing. Perhaps laying it out concisely l=
ike the above would help.


 


 


> > Semantics, profiles and relationship to=
 SAML:


>


> Can you suggest some language you’d li=
ke to see added about this?


 


the words I wrote the comments you were replying =
I trust will suffice to get you



started.


 


 


> However once you add an issuer and a princip=
al, then you’re back to the JWT


> being statements made by an entity about a s=
ubject.


 


sure, but note that what I was trying to say is t=
hat as defined in the JWT spec,



a JWT has /no/ semantics. All semantics are suppl=
ied by specs profiling the JWT



spec (eg draft-ietf-oauth-jwt-bearer-03).


 


It's just a difference, not necessarily an advant=
age or disadvantage.


 


 


> > terminology is not alphabetised!


>


> No, it’s in a top-down descriptive ord=
er. Is there a requirement in IETF


> specs that the terminology be alphabetized?<=
o:p>


 


No there isn't AFAIK -- it's a personal preferenc=
e (dunno about the RFC-editor,



but IIRC I've seen RFCs with non-alphabetized ter=
minology sections).  Given the



way I read specs, non-alphabetized is harder for =
me.


 


 


>> I found meager jwt comparison instructio=
ns at the very end of Section 7.


>> it should probably be its own subsection=
. It should probably explicitly say


>> that JWTs need to be parsed into their c=
onstituent components, and the


>> latter must be individually examined/com=
pared.


>


> We tried to cover this in the end of section=
 7, starting with the sentence


> “Processing a JWT inevitably requires =
comparing known strings to values in the


> token”, which says how these compariso=
ns must be performed. I agree that this


> should become its own subsection. I don̵=
7;t understand your remark about


> constituent components. Can you clarify?


 


i meant decoding from base64 (and decrypting as n=
ecessary) and parsing in order



to obtain claim name and value pairs.<=
/p>

 


> How about “Remove any JSON escaping fr=
om the input JSON string and convert


> the string into a sequence of Unicode code p=
oints”?


 


fine.


 


 


HTH,


 


=3DJeffH


 


 


 






--_000_4E1F6AAD24975D4BA5B168042967394366997296TK5EX14MBXC283r_--

From Jeff.Hodges@KingsMountain.com  Fri Dec 21 15:07:59 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9260421F857C for ; Fri, 21 Dec 2012 15:07:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.605
X-Spam-Level: 
X-Spam-Status: No, score=-102.605 tagged_above=-999 required=5 tests=[AWL=-0.340, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOAZW+Y06qHm for ; Fri, 21 Dec 2012 15:07:57 -0800 (PST)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id BF16621F8441 for ; Fri, 21 Dec 2012 15:07:57 -0800 (PST)
Received: (qmail 32092 invoked by uid 0); 21 Dec 2012 23:07:34 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 21 Dec 2012 23:07:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=s3TNBfs2dhphCkQuXancy4rS7oNET1I/ZQOmFsjc0vI=;  b=hUv/NalhnskkSk6thczMhJC9qEUo1iYtNzJZkFdoKXt1laWDu0hotGkeIpm/nVTEV97iMeVPRLr1YoTPB7i7e8KfDy1Nt4QsrhFkxUTjc3NcmoSu+Yl6sN8/plo5n05p;
Received: from [216.113.168.128] (port=56998 helo=[10.244.137.242]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TmBgj-00041O-Gj for oauth@ietf.org; Fri, 21 Dec 2012 16:07:33 -0700
Message-ID: <50D4EBB7.6070508@KingsMountain.com>
Date: Fri, 21 Dec 2012 15:07:35 -0800
From: =JeffH 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: IETF oauth WG 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: [OAUTH-WG] regarding nested JWTs and security
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 21 Dec 2012 23:07:59 -0000

"nested JWTs" are only nominally defined in draft-ietf-oauth-json-web-token-05 
(and the term is missing from the terminology section).

the JWT spec implies that "signing and then encrypting" and "encrypting and then 
signing" are equivalent. however they aren't in various ways.

Axel already raised this point in..

   Re: [jose] encrypting AND signing a token
   https://www.ietf.org/mail-archive/web/jose/current/msg01269.html

..and cited this paper (worth citing again)..

   Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML
   Don Davis
   http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.28.7379&rep=rep1&type=pdf


One has to carefully compose signing and encryption in order to avoid various 
vulnerabilities detailed in the latter.

I agree with Axel that there should be one carefully designed way to craft a 
signed and encrypted JW*.

Note that in the JSMS draft (draft-rescorla-jsms-00; an early input into what 
became the JOSE WG), sign & encrypt composition is declared..

 > 4.6.  Composition
 >
 >    This document does not specify a combination signed and encrypted
 >    mode.  However, because the contents of a message can be arbitrary,
 >    and encryption and data origin authentication can be provided by
 >    recursively encapsulating multiple JSMS messages.  In general,
 >    senders SHOULD sign the message and then encrypt the result (thus
 >    encrypting the signature).  This prevents attacks in which the
 >    signature is stripped, leaving just an encrypted message, as well as
 >    providing privacy for the signer.

..tho that's a drafty draft and I didn't review carefully enough to determine 
whether it addresses the need for sign and encrypt to cross-refer (see S4.3 in 
the paper).


HTH,

=JeffH




From Jeff.Hodges@KingsMountain.com  Sun Dec 23 09:41:51 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F130B21F8B2B for ; Sun, 23 Dec 2012 09:41:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.391
X-Spam-Level: 
X-Spam-Status: No, score=-101.391 tagged_above=-999 required=5 tests=[AWL=-0.985, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 574x8TMFGB0r for ; Sun, 23 Dec 2012 09:41:50 -0800 (PST)
Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 4F2D121F8815 for ; Sun, 23 Dec 2012 09:41:50 -0800 (PST)
Received: (qmail 10354 invoked by uid 0); 23 Dec 2012 17:41:23 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 23 Dec 2012 17:41:23 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=IGk00nmIJTqrHnRaRGYo8i0TLubyIvELvvvtD+CCkZ0=;  b=6es/oyrs+O9S9Tq/FXj199Xjq4IHhIpZ5C2EsibIdW2VRt5YUHIkKh3yc8UEEam71tIZ70PE7ofCOxjgsVgSOY5MsKUxS9EmjYIty72bSJ1AG5zEd/5YsVhszX535/eT;
Received: from [24.4.122.173] (port=52431 helo=[192.168.11.12]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TmpYA-0002j6-GL; Sun, 23 Dec 2012 10:41:22 -0700
Message-ID: <50D74241.40905@KingsMountain.com>
Date: Sun, 23 Dec 2012 09:41:21 -0800
From: =JeffH 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Mike Jones 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com}
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Dec 2012 17:41:51 -0000

 > Thanks for the replies, Jeff.  They make sense.  Particularly, thanks for
 > the "JSON Text Object" suggestion.

welcome, glad they made some sense.

similarly, if one employs JSON arrays, I'd define a "JSON text array".


 > For the "claims" definition, I'm actually prone to go with definitions based
 > on those in
 > http://openid.net/specs/openid-connect-messages-1_0-13.html#terminology -
 > specifically:
 >
 > Claim
 > A piece of information about an Entity that a Claims Provider asserts about
 > that Entity.
 > Claims Provider
 > A system or service that can return Claims about an Entity.
 > End-User
 > A human user of a system or service.
 > Entity
 > Something that has a separate and distinct existence and that can be
 > identified in context. An End-User is one example of an Entity.

well, it seems to me, given the manner in which the JWT spec is written, one can 
make the case that JWT claims in general aren't necessarily about an Entity (as 
the latter term is used in the context of the OpenID Connect specs), rather 
they're in general simply assertions about something(s). this is because all 
pre-defined JWT claim types are optional and all JWT semantics are left up to 
specs that profile (aka re-use) the JWT spec.

HTH,

=JeffH


From sakimura@gmail.com  Sun Dec 23 10:09:40 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD91021F8B0A for ; Sun, 23 Dec 2012 10:09:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.349
X-Spam-Level: 
X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[AWL=-2.186, BAYES_50=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGIYb+iXoSE5 for ; Sun, 23 Dec 2012 10:09:40 -0800 (PST)
Received: from mail-ea0-f169.google.com (mail-ea0-f169.google.com [209.85.215.169]) by ietfa.amsl.com (Postfix) with ESMTP id 909E321F8ACB for ; Sun, 23 Dec 2012 10:09:30 -0800 (PST)
Received: by mail-ea0-f169.google.com with SMTP id a12so2691774eaa.28 for ; Sun, 23 Dec 2012 10:09:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=E7XXZi2jNF4+z2RbRgQHqdx766H7jFQrkHzRId99Pds=; b=i1tulk4HI66PbA8J//xTbVhnrKdT1KPskvlDbOX140HWlNyjNu52Fz017Xf9ONvx5G N8xr4bhyqkbeuAXqtbJ5itvimZYK2xNEmfbiRUwBeBGq3JnjwxZek5amJJlOLM4Wmu50 oXMrwYXIDvTS4bVdfuZYxRkbh74EOnISG8ArtviOdiTUJcSF1m8UISBTpkorc/GIFG11 stqey1FY+0ZClhAepiSig5nib6sqtmNEYAMr352dvHZhamux+FSHOGqDBwiyDB1RQyJM QhSfhDI2qIcpel0sfmehcujJMB0zBB3vu3E2+p/chzRavDJH5n+24LjeOkU4P96A9oFD BouQ==
Received: by 10.14.3.195 with SMTP id 43mr49467365eeh.36.1356286169599; Sun, 23 Dec 2012 10:09:29 -0800 (PST)
References: <50D74241.40905@KingsMountain.com>
From: Nat Sakimura 
Mime-Version: 1.0 (1.0)
In-Reply-To: <50D74241.40905@KingsMountain.com>
Date: Mon, 24 Dec 2012 03:09:28 +0900
Message-ID: <-6724914566147778422@unknownmsgid>
To: "=JeffH" 
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: base64
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Dec 2012 18:09:40 -0000

UmUgZGVmaW5pdGlvbiBvZiAnY2xhaW0nLCBhcyBKV1QgaXMgc3VwcG9zZWQgdG8gYmUgZ2VuZXJp
YywgaXQgbWF5IGJlCmJldHRlciB0byBnbyB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIFguMTI1MiBy
YXRoZXIgdGhhbiBPSURDLgoKPW5hdCB2aWEgaVBob25lCgpEZWMgMjQsIDIwMTIgMjo0MhskQiEi
GyhCPUplZmZIIDxKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbT4gGyRCJE4lYSVDJTshPCU4
GyhCOgoKPgo+ID4gVGhhbmtzIGZvciB0aGUgcmVwbGllcywgSmVmZi4gIFRoZXkgbWFrZSBzZW5z
ZS4gIFBhcnRpY3VsYXJseSwgdGhhbmtzIGZvcgo+ID4gdGhlICJKU09OIFRleHQgT2JqZWN0IiBz
dWdnZXN0aW9uLgo+Cj4gd2VsY29tZSwgZ2xhZCB0aGV5IG1hZGUgc29tZSBzZW5zZS4KPgo+IHNp
bWlsYXJseSwgaWYgb25lIGVtcGxveXMgSlNPTiBhcnJheXMsIEknZCBkZWZpbmUgYSAiSlNPTiB0
ZXh0IGFycmF5Ii4KPgo+Cj4gPiBGb3IgdGhlICJjbGFpbXMiIGRlZmluaXRpb24sIEknbSBhY3R1
YWxseSBwcm9uZSB0byBnbyB3aXRoIGRlZmluaXRpb25zIGJhc2VkCj4gPiBvbiB0aG9zZSBpbgo+
ID4gaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtbWVzc2FnZXMtMV8wLTEz
Lmh0bWwjdGVybWlub2xvZ3kgLQo+ID4gc3BlY2lmaWNhbGx5Ogo+ID4KPiA+IENsYWltCj4gPiBB
IHBpZWNlIG9mIGluZm9ybWF0aW9uIGFib3V0IGFuIEVudGl0eSB0aGF0IGEgQ2xhaW1zIFByb3Zp
ZGVyIGFzc2VydHMgYWJvdXQKPiA+IHRoYXQgRW50aXR5Lgo+ID4gQ2xhaW1zIFByb3ZpZGVyCj4g
PiBBIHN5c3RlbSBvciBzZXJ2aWNlIHRoYXQgY2FuIHJldHVybiBDbGFpbXMgYWJvdXQgYW4gRW50
aXR5Lgo+ID4gRW5kLVVzZXIKPiA+IEEgaHVtYW4gdXNlciBvZiBhIHN5c3RlbSBvciBzZXJ2aWNl
Lgo+ID4gRW50aXR5Cj4gPiBTb21ldGhpbmcgdGhhdCBoYXMgYSBzZXBhcmF0ZSBhbmQgZGlzdGlu
Y3QgZXhpc3RlbmNlIGFuZCB0aGF0IGNhbiBiZQo+ID4gaWRlbnRpZmllZCBpbiBjb250ZXh0LiBB
biBFbmQtVXNlciBpcyBvbmUgZXhhbXBsZSBvZiBhbiBFbnRpdHkuCj4KPiB3ZWxsLCBpdCBzZWVt
cyB0byBtZSwgZ2l2ZW4gdGhlIG1hbm5lciBpbiB3aGljaCB0aGUgSldUIHNwZWMgaXMgd3JpdHRl
biwgb25lIGNhbiBtYWtlIHRoZSBjYXNlIHRoYXQgSldUIGNsYWltcyBpbiBnZW5lcmFsIGFyZW4n
dCBuZWNlc3NhcmlseSBhYm91dCBhbiBFbnRpdHkgKGFzIHRoZSBsYXR0ZXIgdGVybSBpcyB1c2Vk
IGluIHRoZSBjb250ZXh0IG9mIHRoZSBPcGVuSUQgQ29ubmVjdCBzcGVjcyksIHJhdGhlciB0aGV5
J3JlIGluIGdlbmVyYWwgc2ltcGx5IGFzc2VydGlvbnMgYWJvdXQgc29tZXRoaW5nKHMpLiB0aGlz
IGlzIGJlY2F1c2UgYWxsIHByZS1kZWZpbmVkIEpXVCBjbGFpbSB0eXBlcyBhcmUgb3B0aW9uYWwg
YW5kIGFsbCBKV1Qgc2VtYW50aWNzIGFyZSBsZWZ0IHVwIHRvIHNwZWNzIHRoYXQgcHJvZmlsZSAo
YWthIHJlLXVzZSkgdGhlIEpXVCBzcGVjLgo+Cj4gSFRILAo+Cj4gPUplZmZICj4KPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IE9BdXRoIG1haWxpbmcg
bGlzdAo+IE9BdXRoQGlldGYub3JnCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aAo=

From dick.hardt@gmail.com  Sun Dec 23 10:19:33 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A221F8909 for ; Sun, 23 Dec 2012 10:19:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1rVUT5k1QUK for ; Sun, 23 Dec 2012 10:19:31 -0800 (PST)
Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id BFE5C21F87AE for ; Sun, 23 Dec 2012 10:19:31 -0800 (PST)
Received: by mail-da0-f50.google.com with SMTP id h15so2857627dan.9 for ; Sun, 23 Dec 2012 10:19:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=9bh8nyDqQ5PbcMrhQn1vXZcrT5synAQ5gly1JKUicXA=; b=yeuj4DiBcjraccjsu11rEDCFTUovAZjh652MfboCm35wP05w1jPkad7yX3sUS+Q9c3 1oIPL3Y4qGa8go7R5fMRiuCQzQotuS4dP5SMg4m+Y8O4okkS9cdNzCsukfFREj2V+Nbg tniz1+wh4BY/XhmeWPIyxZI5wU1/qh5aAHXTPLgKhEX4SqEVjTC7Zy5FCofSoh3nemyh +wjMd0Z7SVAIUHcQ0iPKSl7yUHf5bYnGzc/d4BpMJ0bDFBEczSz/JbbuE3DRTyr/yI1r JY0Th70oC93AnR+TsYIOt6SLVue6BKfFzJRR+05IFOEviRdkp8CzVh/3tSmoGnikRbZf IXRw==
X-Received: by 10.66.83.6 with SMTP id m6mr55906058pay.52.1356286771475; Sun, 23 Dec 2012 10:19:31 -0800 (PST)
Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id x2sm11347954paw.8.2012.12.23.10.19.27 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 23 Dec 2012 10:19:28 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Dick Hardt 
In-Reply-To: <50D74241.40905@KingsMountain.com>
Date: Sun, 23 Dec 2012 10:19:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <288FB5FA-3CEF-487C-9C74-3D016FCD1A41@gmail.com>
References: <50D74241.40905@KingsMountain.com>
To: =JeffH 
X-Mailer: Apple Mail (2.1499)
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Dec 2012 18:19:33 -0000

On Dec 23, 2012, at 9:41 AM, =3DJeffH  =
wrote:

>=20
> > Thanks for the replies, Jeff.  They make sense.  Particularly, =
thanks for
> > the "JSON Text Object" suggestion.
>=20
> welcome, glad they made some sense.
>=20
> similarly, if one employs JSON arrays, I'd define a "JSON text array".
>=20
>=20
> > For the "claims" definition, I'm actually prone to go with =
definitions based
> > on those in
> > =
http://openid.net/specs/openid-connect-messages-1_0-13.html#terminology =
-
> > specifically:
> >
> > Claim
> > A piece of information about an Entity that a Claims Provider =
asserts about
> > that Entity.
> > Claims Provider
> > A system or service that can return Claims about an Entity.
> > End-User
> > A human user of a system or service.
> > Entity
> > Something that has a separate and distinct existence and that can be
> > identified in context. An End-User is one example of an Entity.
>=20
> well, it seems to me, given the manner in which the JWT spec is =
written, one can make the case that JWT claims in general aren't =
necessarily about an Entity (as the latter term is used in the context =
of the OpenID Connect specs), rather they're in general simply =
assertions about something(s). this is because all pre-defined JWT claim =
types are optional and all JWT semantics are left up to specs that =
profile (aka re-use) the JWT spec.

Agreed. I'm using an encrypted JWT that is rendered as a QR code to =
store state.

-- Dick=20=

From Michael.Jones@microsoft.com  Sun Dec 23 13:03:07 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B217421F8951 for ; Sun, 23 Dec 2012 13:03:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.265
X-Spam-Level: 
X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y85GplLUrOJv for ; Sun, 23 Dec 2012 13:03:06 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id CD48521F8A2F for ; Sun, 23 Dec 2012 13:03:06 -0800 (PST)
Received: from BY2FFO11FD004.protection.gbl (10.1.15.203) by BY2FFO11HUB011.protection.gbl (10.1.14.82) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 23 Dec 2012 21:03:04 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 23 Dec 2012 21:03:04 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Sun, 23 Dec 2012 21:03:02 +0000
From: Mike Jones 
To: Jeff Hodges , Nat Sakimura 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3hUOTdFPMEcqRdxE+2+f2vGdoyFg==
Date: Sun, 23 Dec 2012 21:03:01 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436699EC3C@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436699EC3CTK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(51914002)(47446002)(15202345001)(47736001)(5343635001)(5343655001)(74662001)(56816002)(512874001)(33656001)(5343645001)(44976002)(59766001)(55846006)(74502001)(47976001)(15395725002)(54356001)(16406001)(77982001)(31966008)(50986001)(49866001)(4396001)(56776001)(16236675001)(46102001)(51856001)(54316002)(53806001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB011; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0704670F76
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 23 Dec 2012 21:03:07 -0000

--_000_4E1F6AAD24975D4BA5B16804296739436699EC3CTK5EX14MBXC283r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

V2hhdCBpcyB0aGUgWC4xMjUyIGRlZmluaXRpb24/DQoNCi0tIE1pa2UNCg0KRnJvbTogTmF0IFNh
a2ltdXJhDQpTZW50OiDigI5EZWNlbWJlcuKAjiDigI4yM+KAjiwg4oCOMjAxMiDigI4xMOKAjjri
gI4wOeKAjiDigI5BTQ0KVG86ID1KZWZmSA0KQ0M6IE1pa2UgSm9uZXMsIElFVEYgb2F1dGggV0cN
ClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdl
Yi10b2tlbi0wNQ0KDQpSZSBkZWZpbml0aW9uIG9mICdjbGFpbScsIGFzIEpXVCBpcyBzdXBwb3Nl
ZCB0byBiZSBnZW5lcmljLCBpdCBtYXkgYmUNCmJldHRlciB0byBnbyB3aXRoIHRoZSBkZWZpbml0
aW9uIG9mIFguMTI1MiByYXRoZXIgdGhhbiBPSURDLg0KDQo9bmF0IHZpYSBpUGhvbmUNCg0KRGVj
IDI0LCAyMDEyIDI6NDLjgIE9SmVmZkggPEplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPiDj
ga7jg6Hjg4Pjgrvjg7zjgrg6DQoNCj4NCj4gPiBUaGFua3MgZm9yIHRoZSByZXBsaWVzLCBKZWZm
LiAgVGhleSBtYWtlIHNlbnNlLiAgUGFydGljdWxhcmx5LCB0aGFua3MgZm9yDQo+ID4gdGhlICJK
U09OIFRleHQgT2JqZWN0IiBzdWdnZXN0aW9uLg0KPg0KPiB3ZWxjb21lLCBnbGFkIHRoZXkgbWFk
ZSBzb21lIHNlbnNlLg0KPg0KPiBzaW1pbGFybHksIGlmIG9uZSBlbXBsb3lzIEpTT04gYXJyYXlz
LCBJJ2QgZGVmaW5lIGEgIkpTT04gdGV4dCBhcnJheSIuDQo+DQo+DQo+ID4gRm9yIHRoZSAiY2xh
aW1zIiBkZWZpbml0aW9uLCBJJ20gYWN0dWFsbHkgcHJvbmUgdG8gZ28gd2l0aCBkZWZpbml0aW9u
cyBiYXNlZA0KPiA+IG9uIHRob3NlIGluDQo+ID4gaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3Bl
bmlkLWNvbm5lY3QtbWVzc2FnZXMtMV8wLTEzLmh0bWwjdGVybWlub2xvZ3kgLQ0KPiA+IHNwZWNp
ZmljYWxseToNCj4gPg0KPiA+IENsYWltDQo+ID4gQSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBhYm91
dCBhbiBFbnRpdHkgdGhhdCBhIENsYWltcyBQcm92aWRlciBhc3NlcnRzIGFib3V0DQo+ID4gdGhh
dCBFbnRpdHkuDQo+ID4gQ2xhaW1zIFByb3ZpZGVyDQo+ID4gQSBzeXN0ZW0gb3Igc2VydmljZSB0
aGF0IGNhbiByZXR1cm4gQ2xhaW1zIGFib3V0IGFuIEVudGl0eS4NCj4gPiBFbmQtVXNlcg0KPiA+
IEEgaHVtYW4gdXNlciBvZiBhIHN5c3RlbSBvciBzZXJ2aWNlLg0KPiA+IEVudGl0eQ0KPiA+IFNv
bWV0aGluZyB0aGF0IGhhcyBhIHNlcGFyYXRlIGFuZCBkaXN0aW5jdCBleGlzdGVuY2UgYW5kIHRo
YXQgY2FuIGJlDQo+ID4gaWRlbnRpZmllZCBpbiBjb250ZXh0LiBBbiBFbmQtVXNlciBpcyBvbmUg
ZXhhbXBsZSBvZiBhbiBFbnRpdHkuDQo+DQo+IHdlbGwsIGl0IHNlZW1zIHRvIG1lLCBnaXZlbiB0
aGUgbWFubmVyIGluIHdoaWNoIHRoZSBKV1Qgc3BlYyBpcyB3cml0dGVuLCBvbmUgY2FuIG1ha2Ug
dGhlIGNhc2UgdGhhdCBKV1QgY2xhaW1zIGluIGdlbmVyYWwgYXJlbid0IG5lY2Vzc2FyaWx5IGFi
b3V0IGFuIEVudGl0eSAoYXMgdGhlIGxhdHRlciB0ZXJtIGlzIHVzZWQgaW4gdGhlIGNvbnRleHQg
b2YgdGhlIE9wZW5JRCBDb25uZWN0IHNwZWNzKSwgcmF0aGVyIHRoZXkncmUgaW4gZ2VuZXJhbCBz
aW1wbHkgYXNzZXJ0aW9ucyBhYm91dCBzb21ldGhpbmcocykuIHRoaXMgaXMgYmVjYXVzZSBhbGwg
cHJlLWRlZmluZWQgSldUIGNsYWltIHR5cGVzIGFyZSBvcHRpb25hbCBhbmQgYWxsIEpXVCBzZW1h
bnRpY3MgYXJlIGxlZnQgdXAgdG8gc3BlY3MgdGhhdCBwcm9maWxlIChha2EgcmUtdXNlKSB0aGUg
SldUIHNwZWMuDQo+DQo+IEhUSCwNCj4NCj4gPUplZmZIDQo+DQo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlzdA0KPiBP
QXV0aEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoDQo=

--_000_4E1F6AAD24975D4BA5B16804296739436699EC3CTK5EX14MBXC283r_
Content-Type: text/html; charset="utf-8"
Content-ID: <1885588804413042B1108F2E0417D20B@microsoft.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSwmcXVvdDtTZWdvZSBVSSZxdW90OyxNZWlyeW8sJnF1b3Q7TWlj
cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90Oywm
cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O0tobWVyIFVJJnF1b3Q7LCZxdW90O05pcm1h
bGEgVUkmcXVvdDssVHVuZ2EsJnF1b3Q7TGFvIFVJJnF1b3Q7LEVicmltYSxzYW5zLXNlcmlmO2Zv
bnQtc2l6ZToxNnB4OyI+DQo8ZGl2PldoYXQgaXMgdGhlIFguMTI1MiBkZWZpbml0aW9uPzwvZGl2
Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LS0gTWlrZTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp
dj4NCjxkaXYgc3R5bGU9ImJvcmRlci10b3AtY29sb3I6IHJnYigyMjksIDIyOSwgMjI5KTsgYm9y
ZGVyLXRvcC13aWR0aDogMnB4OyBib3JkZXItdG9wLXN0eWxlOiBzb2xpZDsiPg0KPHN0cm9uZz5G
cm9tOjwvc3Ryb25nPiZuYnNwO05hdCBTYWtpbXVyYTxicj4NCjxzdHJvbmc+U2VudDo8L3N0cm9u
Zz4mbmJzcDvigI5EZWNlbWJlcuKAjiDigI4yM+KAjiwg4oCOMjAxMiDigI4xMOKAjjrigI4wOeKA
jiDigI5BTTxicj4NCjxzdHJvbmc+VG86PC9zdHJvbmc+Jm5ic3A7PUplZmZIPGJyPg0KPHN0cm9u
Zz5DQzo8L3N0cm9uZz4mbmJzcDtNaWtlIEpvbmVzLCBJRVRGIG9hdXRoIFdHPGJyPg0KPHN0cm9u
Zz5TdWJqZWN0Ojwvc3Ryb25nPiZuYnNwO1JlOiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0
Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N
ClJlIGRlZmluaXRpb24gb2YgJ2NsYWltJywgYXMgSldUIGlzIHN1cHBvc2VkIHRvIGJlIGdlbmVy
aWMsIGl0IG1heSBiZTxicj4NCmJldHRlciB0byBnbyB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIFgu
MTI1MiByYXRoZXIgdGhhbiBPSURDLjxicj4NCjxicj4NCj1uYXQgdmlhIGlQaG9uZTxicj4NCjxi
cj4NCkRlYyAyNCwgMjAxMiAyOjQy44CBPUplZmZIICZsdDtKZWZmLkhvZGdlc0BraW5nc21vdW50
YWluLmNvbSZndDsg44Gu44Oh44OD44K744O844K4Ojxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7
ICZndDsgVGhhbmtzIGZvciB0aGUgcmVwbGllcywgSmVmZi4mbmJzcDsgVGhleSBtYWtlIHNlbnNl
LiZuYnNwOyBQYXJ0aWN1bGFybHksIHRoYW5rcyBmb3I8YnI+DQomZ3Q7ICZndDsgdGhlICZxdW90
O0pTT04gVGV4dCBPYmplY3QmcXVvdDsgc3VnZ2VzdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyB3
ZWxjb21lLCBnbGFkIHRoZXkgbWFkZSBzb21lIHNlbnNlLjxicj4NCiZndDs8YnI+DQomZ3Q7IHNp
bWlsYXJseSwgaWYgb25lIGVtcGxveXMgSlNPTiBhcnJheXMsIEknZCBkZWZpbmUgYSAmcXVvdDtK
U09OIHRleHQgYXJyYXkmcXVvdDsuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsg
Rm9yIHRoZSAmcXVvdDtjbGFpbXMmcXVvdDsgZGVmaW5pdGlvbiwgSSdtIGFjdHVhbGx5IHByb25l
IHRvIGdvIHdpdGggZGVmaW5pdGlvbnMgYmFzZWQ8YnI+DQomZ3Q7ICZndDsgb24gdGhvc2UgaW48
YnI+DQomZ3Q7ICZndDsgaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtbWVz
c2FnZXMtMV8wLTEzLmh0bWwjdGVybWlub2xvZ3kgLTxicj4NCiZndDsgJmd0OyBzcGVjaWZpY2Fs
bHk6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IENsYWltPGJyPg0KJmd0OyAmZ3Q7IEEg
cGllY2Ugb2YgaW5mb3JtYXRpb24gYWJvdXQgYW4gRW50aXR5IHRoYXQgYSBDbGFpbXMgUHJvdmlk
ZXIgYXNzZXJ0cyBhYm91dDxicj4NCiZndDsgJmd0OyB0aGF0IEVudGl0eS48YnI+DQomZ3Q7ICZn
dDsgQ2xhaW1zIFByb3ZpZGVyPGJyPg0KJmd0OyAmZ3Q7IEEgc3lzdGVtIG9yIHNlcnZpY2UgdGhh
dCBjYW4gcmV0dXJuIENsYWltcyBhYm91dCBhbiBFbnRpdHkuPGJyPg0KJmd0OyAmZ3Q7IEVuZC1V
c2VyPGJyPg0KJmd0OyAmZ3Q7IEEgaHVtYW4gdXNlciBvZiBhIHN5c3RlbSBvciBzZXJ2aWNlLjxi
cj4NCiZndDsgJmd0OyBFbnRpdHk8YnI+DQomZ3Q7ICZndDsgU29tZXRoaW5nIHRoYXQgaGFzIGEg
c2VwYXJhdGUgYW5kIGRpc3RpbmN0IGV4aXN0ZW5jZSBhbmQgdGhhdCBjYW4gYmU8YnI+DQomZ3Q7
ICZndDsgaWRlbnRpZmllZCBpbiBjb250ZXh0LiBBbiBFbmQtVXNlciBpcyBvbmUgZXhhbXBsZSBv
ZiBhbiBFbnRpdHkuPGJyPg0KJmd0Ozxicj4NCiZndDsgd2VsbCwgaXQgc2VlbXMgdG8gbWUsIGdp
dmVuIHRoZSBtYW5uZXIgaW4gd2hpY2ggdGhlIEpXVCBzcGVjIGlzIHdyaXR0ZW4sIG9uZSBjYW4g
bWFrZSB0aGUgY2FzZSB0aGF0IEpXVCBjbGFpbXMgaW4gZ2VuZXJhbCBhcmVuJ3QgbmVjZXNzYXJp
bHkgYWJvdXQgYW4gRW50aXR5IChhcyB0aGUgbGF0dGVyIHRlcm0gaXMgdXNlZCBpbiB0aGUgY29u
dGV4dCBvZiB0aGUgT3BlbklEIENvbm5lY3Qgc3BlY3MpLCByYXRoZXIgdGhleSdyZSBpbiBnZW5l
cmFsDQogc2ltcGx5IGFzc2VydGlvbnMgYWJvdXQgc29tZXRoaW5nKHMpLiB0aGlzIGlzIGJlY2F1
c2UgYWxsIHByZS1kZWZpbmVkIEpXVCBjbGFpbSB0eXBlcyBhcmUgb3B0aW9uYWwgYW5kIGFsbCBK
V1Qgc2VtYW50aWNzIGFyZSBsZWZ0IHVwIHRvIHNwZWNzIHRoYXQgcHJvZmlsZSAoYWthIHJlLXVz
ZSkgdGhlIEpXVCBzcGVjLjxicj4NCiZndDs8YnI+DQomZ3Q7IEhUSCw8YnI+DQomZ3Q7PGJyPg0K
Jmd0OyA9SmVmZkg8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0K
Jmd0OyBPQXV0aEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aDxicj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_4E1F6AAD24975D4BA5B16804296739436699EC3CTK5EX14MBXC283r_--

From torsten@lodderstedt.net  Tue Dec 25 03:24:13 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CA321F86AA for ; Tue, 25 Dec 2012 03:24:13 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+ff9DKndOvj for ; Tue, 25 Dec 2012 03:24:08 -0800 (PST)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3C56B21F84E3 for ; Tue, 25 Dec 2012 03:24:08 -0800 (PST)
Received: from [79.253.55.93] (helo=[192.168.71.42]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TnScA-0003l2-3n; Tue, 25 Dec 2012 12:24:06 +0100
Message-ID: <50D98CD3.9050000@lodderstedt.net>
Date: Tue, 25 Dec 2012 12:24:03 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Mark Wubben 
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net>
In-Reply-To: <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Dec 2012 11:24:13 -0000

Hi Mark,

thanks for reviewing the draft. Comments inline.

Am 02.12.2012 18:27, schrieb Mark Wubben:
> The draft relies heavily on the definition "access grant", but no definition is provided in the draft or RFC 6749. It's been my interpretation that an "access grant" is the *fact* that a resource owner has authorized a client (potentially scoped) access to the protected resources. Once access is granted in this manner, further access tokens may be obtained without explicit permission by the end-user. That is, in the Protocol Flow there is no user input between steps A and B.

That's correct.

>
> In "1. Introduction" it is stated:
>
>>   A
>>     revocation request will invalidate the actual token and, if
>>     applicable, other tokens based on the same access grant and the
>>     access grant itself.
> then, in "2. Token Revocation":
>
>>   In the next step, the authorization server invalidates the token and
>>     the respective access grant.  If the particular token is a refresh
>>     token and the authorization server supports the revocation of access
>>     tokens, then the authorization server SHOULD also invalidate all
>>     access tokens based on the same access grant
> This implies that an access grant only applies to an app authorized on a single device. If an app is installed on multiple devices and the access grant is shared between both instances, revoking device A's access token results in the unexpected revocation of device B's token.

You raised an interesting point. Is it desirable to share an access 
grant among different client instances? I would like to discuss this 
topic in the working group.

If we assume it is desirable, how would the authorization process look 
alike?

I would assume that as result of the authorization process of the 1st 
client instance, the authorization server stores an access grant, which 
is identified by the client_id and the user_id of the resource owner. 
Moreover, it creates a refresh token, which the 1st client instance uses 
to obtain new access tokens. As this client is public, the refresh token 
is the credential the intial client uses to prove its identity.

How does the 2nd client instance join the party? I would assume the 2nd 
client to initiate another code grant type flow (using the same 
client_id as the 1st client). I see two ways the authorization server 
could process this process:

1) After authenticating the resource owner, the authorization server 
finds the existing access grant for the client_id/user_id combination 
and automatically issues tokens w/o further user consent. Since the 
authorization server cannot authenticate the client_id, a malicious 
client could obtain and abuse the access grant of the legitimate client. 
That's why the security considerations of the core spec 
(http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:

The authorization server SHOULD NOT process repeated authorization
    requests automatically (without active resource owner interaction)
    without authenticating the client or relying on other measures to
    ensure the repeated request comes from the original client and not an
    impersonator.

Validating the redirect URI won't help that much, since this URI is 
typically device local (custom scheme or localhost).

2) The authorization server asks the resource owner for user consent and 
issues another pair of access/refresh token to the 2nd client. In this 
case, why would one bind this tokens to the already existing access 
grant? This would limit the resource owners capability to revoke grants 
for particular instances. I would rather create another access grant.

Based on this thoughts I think it is not desirable to share an access 
grant among different client instances.

What do others think?

>
> If "access grant" could be defined as "an authorization issued to the  client, based on the single use of an Authorization Grant" it becomes clear than only the tokens spawning from the app's authorization on device A should be revoked.

I would like to adopt your proposal if the WG agrees.

>
> ---
>
> I spotted a typo in "3. Implementation Note":

Thanks. Fixed.

regards,
Torsten.
>
>> Whether this is an viable option or
>>     whether access token revocation is required should be decided based
>>     on the service provider's risk analysis.
> "an viable option" should be "a viable option".
>
> On 24 Nov 2012, at 18:13, Hannes Tschofenig  wrote:
>
>> Hi all,
>>
>> this is a working group last call for draft-ietf-oauth-revocation-03 on "Token Revocation".  The draft is available here:
>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>>
>> Please send you comments to the OAuth mailing list by December 10, 2012.
>>
>> Thanks,
>> Hannes & Derek
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> --
> Mark Wubben
>
> http://novemberborn.net
> http://twitter.com/novemberborn
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From torsten@lodderstedt.net  Tue Dec 25 04:41:42 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B864721F86CB for ; Tue, 25 Dec 2012 04: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkOAA45IAOjU for ; Tue, 25 Dec 2012 04:41:35 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id 09EBF21F86C8 for ; Tue, 25 Dec 2012 04:41:34 -0800 (PST)
Received: from [79.253.55.93] (helo=[192.168.71.42]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TnTp6-0005Ob-1R; Tue, 25 Dec 2012 13:41:32 +0100
Message-ID: <50D99EF8.80308@lodderstedt.net>
Date: Tue, 25 Dec 2012 13:41:28 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "oauth@ietf.org" 
References:  <50BCC54D.5060609@mitre.org>
In-Reply-To: <50BCC54D.5060609@mitre.org>
Content-Type: multipart/alternative; boundary="------------080002040905030602000502"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Dec 2012 12:41:42 -0000

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

Hi all,

any other opinion regarding having or not having a token type parameter?

I would like to go with #1 as it is rather late in the process to 
(re-)introduce a mandatory parameter. And making it an optional 
parameter (#4) seems not really useful to me.

regards,
Torsten.
> The way I see it, we've got a few options:
>
> 1) Leave it as-is, with no field. Client/RS/whoever just sends the 
> token over and it's the AS's problem.
> 2) Define a required field with "access" and "refresh" value 
> semantics, and state that other values MAY be accepted by a given AS, 
> or defined by extension protocols. These extension values MUST be 
> fully qualified URIs.
> 3) Same as #2, but with IANA registry to allow for non-collision of 
> short names.
> 4) Define an optional field that the client MAY send as a hint to the 
> AS, and it's up to the AS to figure out if it makes any sense in the 
> context of the request. All bets are off as to the content of this 
> field, other than "it's a string".
>
> There may be other approaches as well.
>
>  -- Justin
>
> On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:
>> Here is my review of the Toke Revocation draft 
>> (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>>
>> Section 1. Introduction
>> First paragraph has the following definition in it: "A token is the 
>> external representation of an access grant issued by a resource owner 
>> to a particular client." This seems a bit odd to me. The OAuth2 spec 
>> [1] defines "access token" as "An access token is a string 
>> representing an authorization issued to the client." (section 1.4) 
>> and "refresh token" as "credentials used to obtain access tokens 
>> (section 1.5). Should this spec borrow similar language to be more 
>> consistent?
>>
>> Paragraph 2 "From an end-user's perception" should be "From an 
>> end-user's perspective".
>>
>> Section 2. Token Revocation
>> What is the reason for requiring the service provider to detect the 
>> token type automatically? For our implementation, Access Tokens, 
>> Refresh Tokens, and ID Tokens are all structured tokens (with unique 
>> structures across the three types), and as such are stored in 3 
>> separate database tables. In order to "detect" the token type, we 
>> would need to run a get-by-value query across all three tables, check 
>> if any of those queries returned anything, and then proceed to revoke 
>> the token (if one was found). This does not seem ideal to me.
>>
>> The spec says that "The authorization server first validates the 
>> client credentials (in case of a confidential client) and verifies 
>> whether the client is authorized to revoke the particular token." 
>> What does this verification entail? Does it just mean that 1) the 
>> client credentials must validate and 2) the token must belong to the 
>> client requesting the revocation? If so I think the text should be 
>> clarified to reflect that. Or are you thinking of a case where a 
>> client might not be allowed to revoke its own tokens, via some kind 
>> of scoping?
>>
>> 2.1 Cross Origin Support
>> Formatting looks a little off here, otherwise this section looks fine.
>>
>> 5. Security Considerations
>> Paragraph 3 (Malicious clients...): "Appropriate countermeasures, 
>> which should be in place for the token endpoint as well, MUST be 
>> applied to the revocation endpoint." These countermeasures should be 
>> referenced to the proper section(s) of the OAuth core spec or Threat 
>> Model document.
>>
>> Paragraph 4 reads a bit oddly. Suggest following rewording:
>> "A malicious client may attempt to guess valid tokens on this 
>> endpoint by making revocation requests against potential token 
>> strings. According to this specification, a client's request must 
>> contain a valid client_id, in the case of a public client, or valid 
>> client credentials, in the case of a confidential client. The token 
>> being revoked must also belong to the requesting client. If an 
>> attacker is able to successfully guess a public client's client_id 
>> and one of their tokens, or a private client's credentials and one of 
>> their tokens, they could do much worse damage by using the token 
>> elsewhere than by revoking it. If they chose to revoke the token, the 
>> legitimate client will lose its authorization and will need to prompt 
>> the user again. No further damage is done and the guessed token is 
>> now worthless."
>>
>> References:
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>>
>> -- 
>> Amanda Anganes
>> Info Sys Engineer, G061
>> The MITRE Corporation
>> 781-271-3103
>> aanganes@mitre.org
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    Hi all,

    

    any other opinion regarding having or not having a token type
    parameter?

    

    I would like to go with #1 as it is rather late in the process to
    (re-)introduce a mandatory parameter. And making it an optional
    parameter (#4) seems not really useful to me.

    

    regards,

    Torsten.

    

      
 The way I see it, we've got a few
        options:

        

        1) Leave it as-is, with no field. Client/RS/whoever just sends
        the token over and it's the AS's problem.

        2) Define a required field with "access" and "refresh" value
        semantics, and state that other values MAY be accepted by a
        given AS, or defined by extension protocols. These extension
        values MUST be fully qualified URIs.

        3) Same as #2, but with IANA registry to allow for non-collision
        of short names.

        4) Define an optional field that the client MAY send as a hint
        to the AS, and it's up to the AS to figure out if it makes any
        sense in the context of the request. All bets are off as to the
        content of this field, other than "it's a string".

        

        There may be other approaches as well.

        

         -- Justin

        

        On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:

      

      

        
        

          

            
 Here is my review of
              the Toke Revocation draft (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):

            
 

            

            
 Section 1.
              Introduction

            
First paragraph has the
                following definition in it: "A token is the external
                representation of an access grant
                issued by a resource owner to a particular client." This
                seems a bit odd to me. The OAuth2
                spec [1] defines "access token" as "An access token is a string
                representing an authorization issued to the client." (section 1.4) and "refresh
                token" as "credentials used to obtain access tokens
                (section 1.5). Should this spec borrow similar language
                to be more consistent?

            


              

            
Paragraph 2 "From an end-user's
                perception" should be "From an end-user's perspective".

            


              

            
Section 2. Token Revocation

            
What is the reason for requiring the
                service provider to detect the token type automatically?
                For our implementation, Access Tokens, Refresh Tokens,
                and ID Tokens are all structured tokens (with unique
                structures across the three types), and as such are
                stored in 3 separate database tables. In order to
                "detect" the token type, we would need to run a
                get-by-value query across all three tables, check if any
                of those queries returned anything, and then proceed to
                revoke the token (if one was found). This does not seem
                ideal to me. 

            


              

            
The spec says that "The authorization server first
                validates the client credentials (in case of a
                confidential client) and verifies whether the client is
                authorized to revoke the particular token." What does
                this verification entail? Does it just mean that 1) the
                client credentials must validate and 2) the token must
                belong to the client requesting the revocation? If so I
                think the text should be clarified to reflect that. Or
                are you thinking of a case where a client might not be
                allowed to revoke its own tokens, via some kind of
                scoping? 

            


              

            
 2.1 Cross Origin
              Support

            
 Formatting looks a
              little off here, otherwise this section looks fine.

            
 

            

            
 5. Security
              Considerations

            
 Paragraph 3
              (Malicious clients…): "Appropriate countermeasures, which
              should be in place for the token endpoint as well, MUST be
              applied to the revocation endpoint." These countermeasures
              should be referenced to the proper section(s) of the OAuth
              core spec or Threat Model document. 

            
 

            

            
 Paragraph 4 reads a
              bit oddly. Suggest following rewording:

            
 "A
              malicious client may attempt to guess valid tokens on this
              endpoint by making revocation requests against potential
              token strings. According to this specification, a client's
              request must contain a valid client_id, in the case of a
              public client, or valid client credentials, in the case of
              a confidential client. The token being revoked must also
              belong to the requesting client. If an attacker is able to
              successfully guess a public client's client_id and one of
              their tokens, or a private client's credentials and one of
              their tokens, they could do much worse damage by using the
              token elsewhere than by revoking it. If they chose to
              revoke the token, the legitimate client will lose its
              authorization and will need to prompt the user again. No
              further damage is done and the guessed token is now
              worthless." 

            
 

            

            
 References:

            
            
 

            

            

              

                
-- 

                

                  
Amanda Anganes

                  
Info Sys Engineer, G061

                  
The MITRE Corporation

                  
781-271-3103

                  
                

              

            

          

        

        

        

        

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


      

      

      

      

      

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


    

    

  


--------------080002040905030602000502--

From torsten@lodderstedt.net  Tue Dec 25 05:11:14 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7144121F8717 for ; Tue, 25 Dec 2012 05:11: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4wJlAyjk37L for ; Tue, 25 Dec 2012 05:11:10 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.42]) by ietfa.amsl.com (Postfix) with ESMTP id E601121F870E for ; Tue, 25 Dec 2012 05:11:09 -0800 (PST)
Received: from [79.253.55.93] (helo=[192.168.71.42]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TnUHk-0004BR-9T; Tue, 25 Dec 2012 14:11:08 +0100
Message-ID: <50D9A5E9.20205@lodderstedt.net>
Date: Tue, 25 Dec 2012 14:11:05 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Anganes, Amanda L" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070408050300090903070709"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Dec 2012 13:11:14 -0000

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

Hi Amanda,

thank you for reviewing the draft. Comments inline.

Am 30.11.2012 22:28, schrieb Anganes, Amanda L:
> Here is my review of the Toke Revocation draft 
> (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>
> Section 1. Introduction
> First paragraph has the following definition in it: "A token is the 
> external representation of an access grant issued by a resource owner 
> to a particular client." This seems a bit odd to me. The OAuth2 spec 
> [1] defines "access token" as "An access token is a string 
> representing an authorization issued to the client." (section 1.4) and 
> "refresh token" as "credentials used to obtain access tokens (section 
> 1.5). Should this spec borrow similar language to be more consistent?
>

What about this:

"A token is a string representing an authorization issued by the 
resource owner to the client. A revocation request will invalidate the 
actual token and, if applicable, other tokens based on the same 
authorization and the authorization itself."


> Paragraph 2 "From an end-user's perception" should be "From an 
> end-user's perspective".

changed it.

>
> Section 2. Token Revocation
> What is the reason for requiring the service provider to detect the 
> token type automatically? For our implementation, Access Tokens, 
> Refresh Tokens, and ID Tokens are all structured tokens (with unique 
> structures across the three types), and as such are stored in 3 
> separate database tables. In order to "detect" the token type, we 
> would need to run a get-by-value query across all three tables, check 
> if any of those queries returned anything, and then proceed to revoke 
> the token (if one was found). This does not seem ideal to me.

As pointed out by Justin, there was such a parameter in an early 
revision of the draft. WG feedback caused me to remove it. I would like 
to stick with auto detection if not otherwise decided by the working 
group. I explicitely asked for feedback on the other thread.

>
> The spec says that "The authorization server first validates the 
> client credentials (in case of a confidential client) and verifies 
> whether the client is authorized to revoke the particular token." What 
> does this verification entail? Does it just mean that 1) the client 
> credentials must validate and 2) the token must belong to the client 
> requesting the revocation? If so I think the text should be clarified 
> to reflect that. Or are you thinking of a case where a client might 
> not be allowed to revoke its own tokens, via some kind of scoping?

It's 1+2

What about this text

"The authorization server first validates the client credentials (in 
case of a confidential client) and then verifies whether the client is 
authorized to revoke the token. A client may only revoke a token if the 
validation of the client identity succeeds and the particular token had 
been issued to this client."

>
> 2.1 Cross Origin Support
> Formatting looks a little off here, otherwise this section looks fine.

What specifically to you mean?

>
> 5. Security Considerations
> Paragraph 3 (Malicious clients...): "Appropriate countermeasures, 
> which should be in place for the token endpoint as well, MUST be 
> applied to the revocation endpoint." These countermeasures should be 
> referenced to the proper section(s) of the OAuth core spec or Threat 
> Model document.

Added reference to section 4.4.1.11 of threat model documemt

>
> Paragraph 4 reads a bit oddly. Suggest following rewording:
> "A malicious client may attempt to guess valid tokens on this endpoint 
> by making revocation requests against potential token strings. 
> According to this specification, a client's request must contain a 
> valid client_id, in the case of a public client, or valid client 
> credentials, in the case of a confidential client. The token being 
> revoked must also belong to the requesting client. If an attacker is 
> able to successfully guess a public client's client_id and one of 
> their tokens, or a private client's credentials and one of their 
> tokens, they could do much worse damage by using the token elsewhere 
> than by revoking it. If they chose to revoke the token, the legitimate 
> client will lose its authorization and will need to prompt the user 
> again. No further damage is done and the guessed token is now worthless."
>

Adopted your text.

best regards,
Torsten.
> References:
> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>
> -- 
> Amanda Anganes
> Info Sys Engineer, G061
> The MITRE Corporation
> 781-271-3103
> aanganes@mitre.org
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    Hi Amanda,

    

    thank you for reviewing the draft. Comments inline.

    

    
Am 30.11.2012 22:28, schrieb Anganes,
      Amanda L:

    

    

      
      

        

          

            Here is my review of the Toke Revocation draft (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):

          

            

          

          

            Section 1. Introduction

          
First
              paragraph has the following definition in it: "A token is
              the external representation of an access grant
              issued by a resource owner to a particular client." This
              seems a bit odd to me. The OAuth2 spec
              [1] defines "access token" as "An
            access token is a string
              representing an authorization issued to the client." (section 1.4) and "refresh
              token" as "credentials used to obtain access tokens
              (section 1.5). Should this spec borrow similar language to
              be more consistent?

          


            

        

      

    

    

    What about this:

    

    "A token is a string representing an authorization issued by the
    resource owner to the client. A revocation request will invalidate
    the actual token and, if applicable, other tokens based on the same
    authorization and the authorization itself."

    

    

    

      

        

          

            

          
Paragraph 2 "From an end-user's
              perception" should be "From an end-user's perspective".

        

      

    

    

    changed it.

    

    

      

        

          


            

          
Section 2. Token Revocation

          
What is the reason for requiring the
              service provider to detect the token type automatically?
              For our implementation, Access Tokens, Refresh Tokens, and
              ID Tokens are all structured tokens (with unique
              structures across the three types), and as such are stored
              in 3 separate database tables. In order to "detect" the
              token type, we would need to run a get-by-value query
              across all three tables, check if any of those queries
              returned anything, and then proceed to revoke the token
              (if one was found). This does not seem ideal to me.

        

      

    

    

    As pointed out by Justin, there was such a parameter in an early
    revision of the draft. WG feedback caused me to remove it. I would
    like to stick with auto detection if not otherwise decided by the
    working group. I explicitely asked for feedback on the other
    thread.  

    

    

      

        

          

            

          


            

          
The
              spec says that "The authorization server first validates
              the client credentials (in case of a confidential client)
              and verifies whether the client is authorized to revoke
              the particular token." What does this verification entail?
              Does it just mean that 1) the client credentials must
              validate and 2) the token must belong to the client
              requesting the revocation? If so I think the text should
              be clarified to reflect that. Or are you thinking of a
              case where a client might not be allowed to revoke its own
              tokens, via some kind of scoping?

        

      

    

    

    It's 1+2

    

    What about this text

    

    "The authorization server first validates the client credentials (in
    case of a confidential client) and then verifies whether the client
    is authorized to revoke the token. A client may only revoke a token
    if the validation of the client identity succeeds and the particular
    token had been issued to this client."

    

    

      

        

          

            

          


            

          

            2.1 Cross Origin Support

          

            Formatting looks a little off here, otherwise this section
            looks fine.

        

      

    

    

    What specifically to you mean?

    

    

      

        

          

            

          

          

            5. Security Considerations

          

            Paragraph 3 (Malicious clients…): "Appropriate
            countermeasures, which should be in place for the token
            endpoint as well, MUST be applied to the revocation
            endpoint." These countermeasures should be referenced to the
            proper section(s) of the OAuth core spec or Threat Model
            document. 

          

        

      

    

    

    Added reference to section 4.4.1.11 of threat model documemt

      

    
    

      

        

          

            

          

          

            Paragraph 4 reads a bit oddly. Suggest following rewording:

          

            "A
            malicious client may attempt to guess valid tokens on this
            endpoint by making revocation requests against potential
            token strings. According to this specification, a client's
            request must contain a valid client_id, in the case of a
            public client, or valid client credentials, in the case of a
            confidential client. The token being revoked must also
            belong to the requesting client. If an attacker is able to
            successfully guess a public client's client_id and one of
            their tokens, or a private client's credentials and one of
            their tokens, they could do much worse damage by using the
            token elsewhere than by revoking it. If they chose to revoke
            the token, the legitimate client will lose its authorization
            and will need to prompt the user again. No further damage is
            done and the guessed token is now worthless." 

          

            

          

        

      

    

    

    Adopted your text.

    

    best regards,

    Torsten.

    

      

        

          

          

          

            References:

          
          

            

          

          

            

              
-- 

              

                
Amanda Anganes

                
Info Sys Engineer, G061

                
The MITRE Corporation

                
781-271-3103

                
              

            

          

        

      

      

      

      

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


    

    

  


--------------070408050300090903070709--

From torsten@lodderstedt.net  Tue Dec 25 05:19:54 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A333521F8606 for ; Tue, 25 Dec 2012 05:19:54 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jE8bBuw0zhmQ for ; Tue, 25 Dec 2012 05:19:50 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.99]) by ietfa.amsl.com (Postfix) with ESMTP id 6674C21F85DB for ; Tue, 25 Dec 2012 05:19:50 -0800 (PST)
Received: from [79.253.55.93] (helo=[192.168.71.42]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TnUQ8-0001Tk-JM; Tue, 25 Dec 2012 14:19:48 +0100
Message-ID: <50D9A7F1.8090506@lodderstedt.net>
Date: Tue, 25 Dec 2012 14:19:45 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Peter Mauritius 
References: <50D4DF81.4020101@peter.de>
In-Reply-To: <50D4DF81.4020101@peter.de>
Content-Type: multipart/alternative; boundary="------------050106070200010806000602"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: OAuth WG 
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Dec 2012 13:19:54 -0000

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

Hi Peter,

your proposal sounds reasonable.

Since it involves a change to the interface spec (400 instead of 403 in 
case of unauthorized access) I would like to ask the working group for 
feedback.

What do you think? I especially would like to gain feedback from 
implementors of the draft (e.g. Marius, Chuck, Justin).

regards,
Torsten.

Am 21.12.2012 23:15, schrieb Peter Mauritius:
> During the last week I had the chance to implement the non optional 
> features of the token revokation draft. I would be glad if the 
> document would get a closer connection to the refrenced RFC6749 
> regarding the error handling.
>
> The draft states to use HTTP status 401 and 403 for certain error 
> conditions. RFC6749 declares this as optional (OK, not for the 
> Authorization header). The implemation of the token revokation 
> endpoint in conjunction with a tokens endpoint would be much easier if 
> there is a single way to handle exceptions which conforms to RFC6749.
>
> Therefore I want to suggest to replace
>
>> Status code 401 indicates a
>>     failed client authentication, whereas a status code 403 is used if
>>     the client is not authorized to revoke the particular token.  For all
>>     other error conditions, a status code 400 is used along with an error
>>     response as defined insection 5.2  . of [RFC6749  ].
> with
>
>     The error presentation conforms to the defintion in section 5.2 of
>     [RFC6749].
>
> To express the status code 403 I suggest to use the error code 
> "unauthorized_client" of RFC6749 in conjunction with status code 400. 
> The additional error codes defined in the draft will remain of course.
>
> Happy apocalypse ;-)
>   Peter Mauritius
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    Hi Peter,

    

    your proposal sounds reasonable. 

    

    Since it involves a change to the interface spec (400 instead of 403
    in case of unauthorized access) I would like to ask the working
    group for feedback.

    

    What do you think? I especially would like to gain feedback from
    implementors of the draft (e.g. Marius, Chuck, Justin).

    

    regards,

    Torsten.

    

    
Am 21.12.2012 23:15, schrieb Peter
      Mauritius:

    

    

      
      During the last week I had the chance to implement the non
      optional features of the token revokation draft. I would be glad
      if the document would get a closer connection to the refrenced 
      
      RFC6749 regarding the error handling. 

      

      The draft states to use HTTP status 401 and 403 for certain error
      conditions. RFC6749 declares this as optional (OK, not for the
      Authorization header). The implemation of the token revokation
      endpoint in conjunction with a tokens endpoint would be much
      easier if there is a single way to handle exceptions which
      conforms to RFC6749.

      

      Therefore I want to suggest to replace 

      

      

        
        
Status code 401 indicates a
   failed client authentication, whereas a status code 403 is used if
   the client is not authorized to revoke the particular token.  For all
   other error conditions, a status code 400 is used along with an error
   response as defined in section 5.2. of [RFC6749].  

      

      with

      
The error presentation conforms to the defintion in
        section 5.2 of [RFC6749]. 

      

      To express the status code 403 I suggest to use the error code
      "unauthorized_client" of RFC6749 in conjunction with status code
      400. The additional error codes defined in the draft will remain
      of course.

      

      Happy
      
      apocalypse ;-)

        Peter Mauritius

      
      
      

      

      

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


    

    

  


--------------050106070200010806000602--

From torsten@lodderstedt.net  Tue Dec 25 05:29:17 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D80821F8621 for ; Tue, 25 Dec 2012 05:29:17 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZXMNxEM6vQp for ; Tue, 25 Dec 2012 05:29:13 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.27]) by ietfa.amsl.com (Postfix) with ESMTP id D15AA21F845E for ; Tue, 25 Dec 2012 05:29:12 -0800 (PST)
Received: from [79.253.55.93] (helo=[192.168.71.42]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1TnUZD-0005hT-Cw; Tue, 25 Dec 2012 14:29:11 +0100
Message-ID: <50D9AA24.9000404@lodderstedt.net>
Date: Tue, 25 Dec 2012 14:29:08 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Hannes Tschofenig 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 25 Dec 2012 13:29:17 -0000

Hi Hannes,

thanks for providing feedback to the draft. I adopted the text you=20
proposed with minor tweaks.

Does this work for your?

OAuth 2.0 allows deployment flexibility with respect to the style of=20
access tokens. The access tokens may be self-contained so that an=20
resource server needs no further interaction with an authorization=20
server issuing these tokens to perform an authorization decision of the=20
client requesting access to a protected resource. A system design may,=20
however, instead use access tokens that are handles referring to=20
authorization data stored at the authorization server. This consequently =

requires a resource server to issue a request to the respective=20
authorization server to retrieve the content of the access token every=20
time a client presents an access token.

While these are not the only options they illustrate the implications=20
for revocation. In the latter case the authorization server is able to=20
revoke an access token previously issued to a client when the resource=20
server relays a received access token. In the former case some=20
(currently non-standardized) backend interaction between the=20
authorization server and the resource server may be used when immediate=20
access token revocation is desired. Another design alternative is to=20
issue short-lived access tokens, which can be refreshed at any time=20
using the corresponding refresh tokens. This allows the authorization=20
server to have a limit on the time revoked access tokens are in use.

Which approach of token revocation is chosen will depend on the overall=20
system design and on the application service provider's risk analysis.=20
The cost of revocation in terms of required state and communication=20
overhead is ultimately the result of the desired security properties.

regards,
Torsten.

Am 26.11.2012 09:36, schrieb Hannes Tschofenig:
> Hi Torsten,
>
> thanks for the draft update. It looks good to me.
>
> I only have a minor wording suggestion for Section 3.
>
> Instead of
> "
>     Depending on the authorization server's token design, revocation of=

>     access tokens might be a costly process.  For example, revocation o=
f
>     self-contained access tokens requires (time-consuming) backend call=
s
>     between resource and authorization server on every request to the
>     resource server or to push notifications from the authorization
>     server to the affected resource servers.  Alternatively,
>     authorization servers may choose to issue short living access token=
s,
>     which can be refreshed at any time using the corresponding refresh
>     tokens.  In this case, a client would revoke the refresh token and
>     access tokens issued based on this particular refresh token are at
>     most valid until expiration.  Whether this is an viable option or
>     whether access token revocation is required should be decided based=

>     on the service provider's risk analysis.
> "
>
> what about the following text:
>
> "
> OAuth 2.0 allows deployment flexibility with respect to the style of ac=
cess tokens. The access tokens may be self-contained so that an resource =
server needs no further interaction with an authorization server issuing =
these tokens to perform an authorization decision of the client requestin=
g access to a protected resource. A system design may, however, instead u=
se access tokens that are opaque to the resource server. This consequentl=
y requires a resource server to issue a request to an authorization serve=
r to retrieve the content of the access token every time a client present=
s an access token. While these are not the only options they illustrate t=
he implications for revocation. In the latter case the authorization serv=
er is able to revoke an access token previously issued to a client when t=
he resource server relays a received access token. In the former case som=
e (currently non-standardized) back-end interaction between the authoriza=
tion server and the resource server may be
>   used when immediate access token revocation is desired or another des=
ign alternative is to issue short-lived access tokens, which can be refre=
shed at any time using the corresponding refresh tokens. This allows the =
authorization server to have a limit on the time revoked access tokens ar=
e in use.
>
> Which approach of token revocation is chosen will depend on the overall=
 system design and on the application service provider's risk analysis. T=
he cost of revocation in terms of required state and communication overhe=
ad is ultimately the result of the desired security properties.
> "
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth



From ve7jtb@ve7jtb.com  Wed Dec 26 06:18:05 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D45621F8CBD for ; Wed, 26 Dec 2012 06:18:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.338
X-Spam-Level: 
X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyelFjVPlYEQ for ; Wed, 26 Dec 2012 06:18:04 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CADBE21F8CAF for ; Wed, 26 Dec 2012 06:18:03 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id b25so4493164qca.31 for ; Wed, 26 Dec 2012 06:18:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=ripwg4p7Yk7O3AW+X6l+fU7cSY9fDD9G6N2fALT42YA=; b=Cn4K/ttkM44RWCgLUvQ0xBuOqxmcRZsUmvTUEbDl7vh2XZDjtkbH092Xws6N6Kntm1 79FNdDKIDMC+vr6tXG01M81ypfzKOqsUNxPGxwsY93tuUK6Y8V6CNvioxcfaQhHM8LKM BRX2yg5grKK+n1HHuJTS3UCgsJMDjOcht72OgEjYV3ni4vyqVIWEkwj9R+dgjl9s+bRq Pdb4LzuIwAZDaOV1vG6jrqY/HRLpEmRsUbVwTKideYCSU1UtK5+k/WisqcZKAOIHqxtD Em+vE/ZH92Tb7AKoUYe273P3+A3cz15uYG22Xh8Uj3JPaDlCdwgTvBkHXV86xbwoaEaD tQRA==
X-Received: by 10.224.179.211 with SMTP id br19mr12496559qab.43.1356531483099;  Wed, 26 Dec 2012 06:18:03 -0800 (PST)
Received: from [192.168.1.211] (190-20-45-222.baf.movistar.cl. [190.20.45.222]) by mx.google.com with ESMTPS id jy4sm4088573qeb.12.2012.12.26.06.17.58 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Dec 2012 06:18:00 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3079B514-8332-4075-9CD8-577329E82590"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <50D99EF8.80308@lodderstedt.net>
Date: Wed, 26 Dec 2012 11:17:51 -0300
Message-Id: 
References:  <50BCC54D.5060609@mitre.org> <50D99EF8.80308@lodderstedt.net>
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmQhNWySiqhQjXcrdrUYMqYuSDob/dsD2l/z0GlamqWjyt5cchjiIwf+6yJqWOghZl2BI1U
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Dec 2012 14:18:05 -0000

--Apple-Mail=_3079B514-8332-4075-9CD8-577329E82590
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I agree that #1 is currently the best option.    Tokens are supposed to =
be opaque to the client in principal.  The AS is in the best position to =
sort it out of required.   Nothing stops the token from being structured =
if it is an issue for the AS.

John B.

On 2012-12-25, at 9:41 AM, Torsten Lodderstedt  =
wrote:

> Hi all,
>=20
> any other opinion regarding having or not having a token type =
parameter?
>=20
> I would like to go with #1 as it is rather late in the process to =
(re-)introduce a mandatory parameter. And making it an optional =
parameter (#4) seems not really useful to me.
>=20
> regards,
> Torsten.
>> The way I see it, we've got a few options:
>>=20
>> 1) Leave it as-is, with no field. Client/RS/whoever just sends the =
token over and it's the AS's problem.
>> 2) Define a required field with "access" and "refresh" value =
semantics, and state that other values MAY be accepted by a given AS, or =
defined by extension protocols. These extension values MUST be fully =
qualified URIs.
>> 3) Same as #2, but with IANA registry to allow for non-collision of =
short names.
>> 4) Define an optional field that the client MAY send as a hint to the =
AS, and it's up to the AS to figure out if it makes any sense in the =
context of the request. All bets are off as to the content of this =
field, other than "it's a string".
>>=20
>> There may be other approaches as well.
>>=20
>>  -- Justin
>>=20
>> On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:
>>> Here is my review of the Toke Revocation draft =
(http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>>>=20
>>> Section 1. Introduction
>>> First paragraph has the following definition in it: "A token is the =
external representation of an access grant issued by a resource owner to =
a particular client." This seems a bit odd to me. The OAuth2 spec [1] =
defines "access token" as "An access token is a string
>>>                 representing an authorization issued to the client." =
(section 1.4) and "refresh
>>>                 token" as "credentials used to obtain access tokens
>>>                 (section 1.5). Should this spec borrow similar =
language
>>>                 to be more consistent?
>>>=20
>>>=20
>>>              =20
>>> Paragraph 2 "=46rom an end-user's
>>>                 perception" should be "=46rom an end-user's =
perspective".
>>>=20
>>>=20
>>>              =20
>>> Section 2. Token Revocation
>>> What is the reason for requiring the
>>>                 service provider to detect the token type =
automatically?
>>>                 For our implementation, Access Tokens, Refresh =
Tokens,
>>>                 and ID Tokens are all structured tokens (with unique
>>>                 structures across the three types), and as such are
>>>                 stored in 3 separate database tables. In order to
>>>                 "detect" the token type, we would need to run a
>>>                 get-by-value query across all three tables, check if =
any
>>>                 of those queries returned anything, and then proceed =
to
>>>                 revoke the token (if one was found). This does not =
seem
>>>                 ideal to me.=20
>>>=20
>>>=20
>>>              =20
>>> The spec says that "The authorization server first
>>>                 validates the client credentials (in case of a
>>>                 confidential client) and verifies whether the client =
is
>>>                 authorized to revoke the particular token." What =
does
>>>                 this verification entail? Does it just mean that 1) =
the
>>>                 client credentials must validate and 2) the token =
must
>>>                 belong to the client requesting the revocation? If =
so I
>>>                 think the text should be clarified to reflect that. =
Or
>>>                 are you thinking of a case where a client might not =
be
>>>                 allowed to revoke its own tokens, via some kind of
>>>                 scoping?=20
>>>=20
>>>=20
>>>              =20
>>> 2.1 Cross Origin Support
>>> Formatting looks a little off here, otherwise this section looks =
fine.
>>>=20
>>> 5. Security Considerations
>>> Paragraph 3 (Malicious clients=85): "Appropriate countermeasures, =
which should be in place for the token endpoint as well, MUST be applied =
to the revocation endpoint." These countermeasures should be referenced =
to the proper section(s) of the OAuth core spec or Threat Model =
document.=20
>>>=20
>>> Paragraph 4 reads a bit oddly. Suggest following rewording:
>>> "A malicious client may attempt to guess valid tokens on this =
endpoint by making revocation requests against potential token strings. =
According to this specification, a client's request must contain a valid =
client_id, in the case of a public client, or valid client credentials, =
in the case of a confidential client. The token being revoked must also =
belong to the requesting client. If an attacker is able to successfully =
guess a public client's client_id and one of their tokens, or a private =
client's credentials and one of their tokens, they could do much worse =
damage by using the token elsewhere than by revoking it. If they chose =
to revoke the token, the legitimate client will lose its authorization =
and will need to prompt the user again. No further damage is done and =
the guessed token is now worthless."=20
>>>=20
>>> References:
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>>>=20
>>> --=20
>>> Amanda Anganes
>>> Info Sys Engineer, G061
>>> The MITRE Corporation
>>> 781-271-3103
>>> aanganes@mitre.org
>>>=20
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>=20
>>=20
>>=20
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_3079B514-8332-4075-9CD8-577329E82590
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

I =
agree that #1 is currently the best option.    Tokens are =
supposed to be opaque to the client in principal.  The AS is in the =
best position to sort it out of required.   Nothing stops the token =
from being structured if it is an issue for the =
AS.

John B.

On 2012-12-25, at =
9:41 AM, Torsten Lodderstedt <torsten@lodderstedt.net> =
wrote:


 =20
    
 =20
  

    Hi all,

    

    any other opinion regarding having or not having a token type
    parameter?

    

    I would like to go with #1 as it is rather late in the process to
    (re-)introduce a mandatory parameter. And making it an optional
    parameter (#4) seems not really useful to me.

    

    regards,

    Torsten.

    

      
 The way I see it, we've got a few
        options:

        

        1) Leave it as-is, with no field. Client/RS/whoever just sends
        the token over and it's the AS's problem.

        2) Define a required field with "access" and "refresh" value
        semantics, and state that other values MAY be accepted by a
        given AS, or defined by extension protocols. These extension
        values MUST be fully qualified URIs.

        3) Same as #2, but with IANA registry to allow for non-collision
        of short names.

        4) Define an optional field that the client MAY send as a hint
        to the AS, and it's up to the AS to figure out if it makes any
        sense in the context of the request. All bets are off as to the
        content of this field, other than "it's a string".

        

        There may be other approaches as well.

        

         -- Justin

        

        On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:

      

      

        
        

          

            
 Here is my review of
              the Toke Revocation draft (http=
://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):

            
 

            

            
 Section 1.
              Introduction

            
First paragraph has the
                following definition in it: "A token is the external
                representation of an access grant
                issued by a resource owner to a particular client." This
                seems a bit odd to me. The OAuth2
                spec [1] defines "access token" as "An access token is a string
                representing an authorization issued to the =
client." (section 1.4) and "refresh
                token" as "credentials used to obtain access tokens
                (section 1.5). Should this spec borrow similar language
                to be more consistent?

            


              

            
Paragraph 2 "=46rom an end-user's
                perception" should be "=46rom an end-user's =
perspective".

            


              

            
Section 2. Token =
Revocation

            
What is the reason for requiring the
                service provider to detect the token type automatically?
                For our implementation, Access Tokens, Refresh Tokens,
                and ID Tokens are all structured tokens (with unique
                structures across the three types), and as such are
                stored in 3 separate database tables. In order to
                "detect" the token type, we would need to run a
                get-by-value query across all three tables, check if any
                of those queries returned anything, and then proceed to
                revoke the token (if one was found). This does not seem
                ideal to me. 

            


              

            
The spec says that "The authorization server first
                validates the client credentials (in case of a
                confidential client) and verifies whether the client is
                authorized to revoke the particular token." What does
                this verification entail? Does it just mean that 1) the
                client credentials must validate and 2) the token must
                belong to the client requesting the revocation? If so I
                think the text should be clarified to reflect that. Or
                are you thinking of a case where a client might not be
                allowed to revoke its own tokens, via some kind of
                scoping? 

            


              

            
 2.1 Cross Origin
              Support

            
 Formatting looks a
              little off here, otherwise this section looks fine.

            
 

            

            
 5. Security
              Considerations

            
 Paragraph 3
              (Malicious clients=85): "Appropriate countermeasures, =
which
              should be in place for the token endpoint as well, MUST be
              applied to the revocation endpoint." These countermeasures
              should be referenced to the proper section(s) of the OAuth
              core spec or Threat Model document. 

            
 

            

            
 Paragraph 4 reads a
              bit oddly. Suggest following rewording:

            
 "A
              malicious client may attempt to guess valid tokens on this
              endpoint by making revocation requests against potential
              token strings. According to this specification, a client's
              request must contain a valid client_id, in the case of a
              public client, or valid client credentials, in the case of
              a confidential client. The token being revoked must also
              belong to the requesting client. If an attacker is able to
              successfully guess a public client's client_id and one of
              their tokens, or a private client's credentials and one of
              their tokens, they could do much worse damage by using the
              token elsewhere than by revoking it. If they chose to
              revoke the token, the legitimate client will lose its
              authorization and will need to prompt the user again. No
              further damage is done and the guessed token is now
              worthless." 

            
 

            

            
 References:

            
            
 

            

            

              

                
-- 

                

                  
Amanda Anganes

                  
Info Sys Engineer, G061

                  
The MITRE Corporation

                  
781-271-3103

                  
                

              

            

          

        

        

        

        

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


      

      

      

      

      

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


    

    

  


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

=

--Apple-Mail=_3079B514-8332-4075-9CD8-577329E82590--

From ve7jtb@ve7jtb.com  Wed Dec 26 06:38:49 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454AD21F8CBE for ; Wed, 26 Dec 2012 06:38:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.343
X-Spam-Level: 
X-Spam-Status: No, score=-3.343 tagged_above=-999 required=5 tests=[AWL=0.256,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fyiLLIgA01P for ; Wed, 26 Dec 2012 06:38:48 -0800 (PST)
Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id DEFB521F8CBC for ; Wed, 26 Dec 2012 06:38:47 -0800 (PST)
Received: by mail-qc0-f171.google.com with SMTP id d1so4454926qca.16 for ; Wed, 26 Dec 2012 06:38:47 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=NHjm0ucQdp6WDw0wo5XZrnDdfsVKsZfib1KWRQbniLE=; b=Ke6Tde2+N4vW2jvm7XQOxbGShReoEkTHC0nNFJth195qIjxIky1pJJ3hw2jGSPrem+ muRYWqea5VuRA4WP2UMgoJx40/OAizmnNwDyfrJH7WR+3eAGfODXJakNnWWbZMTGBq1q FT7RZ6HurCGEk3TtucDBTtCYJ2XZiYfw3CQrPG40BX4J7V+SLZeztBMte7wfoeo6lJvA Bxepo8p3zrIAfEsS03W0uAXzEHM7XShiIPjjqky8iQaYJoTTDQdGF5Asg1eoyY6IN9pM 3F81Mp8m08flJRo/Ex8WqHOL06ux+YF/JboKKeV2OvFY5NaM0MBMUXzpDy2xoOzClaRr 4HaA==
X-Received: by 10.224.17.193 with SMTP id t1mr12382822qaa.89.1356532727091; Wed, 26 Dec 2012 06:38:47 -0800 (PST)
Received: from [192.168.1.211] (190-20-45-222.baf.movistar.cl. [190.20.45.222]) by mx.google.com with ESMTPS id l6sm6105600qal.21.2012.12.26.06.38.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 26 Dec 2012 06:38:45 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <50D98CD3.9050000@lodderstedt.net>
Date: Wed, 26 Dec 2012 11:38:37 -0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com>
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net>
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQl0kKvMgKqvvdifl7B8X+jVTMRUcgY5+PH6lmBmbrajkveDxaNgCze9NPah0+tu9oLl+C3v
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Dec 2012 14:38:49 -0000

We don't want to share grant information across multiple instances of =
public client.

However we don't necessarily want to preclude multiple instances of a =
private client,  Though how the AS would tell them apart is a =
interesting side question.

=46rom a revocation point of view if you revoke the grant for one =
instance of a client you revoke it for all, though for a public client =
the grant is not doing anything anyway as the AS shield not be pre =
approving based on the grant.

There are still some open questions about an extension to identify =
client instances, though personally I prefer to have each instance with =
it's own client ID.

The language around grants has always been a bit philosophical for my =
taste.  =20

If I recall correctly in the code flow the code is the representation of =
the grant.  In  the implicit flow the grant is implicit in the access =
token.
What construct (if any in the implicit case) is stored in the AS to =
represent this is mostly left to the imagination of the implementer.

John B.


On 2012-12-25, at 8:24 AM, Torsten Lodderstedt  =
wrote:

> Hi Mark,
>=20
> thanks for reviewing the draft. Comments inline.
>=20
> Am 02.12.2012 18:27, schrieb Mark Wubben:
>> The draft relies heavily on the definition "access grant", but no =
definition is provided in the draft or RFC 6749. It's been my =
interpretation that an "access grant" is the *fact* that a resource =
owner has authorized a client (potentially scoped) access to the =
protected resources. Once access is granted in this manner, further =
access tokens may be obtained without explicit permission by the =
end-user. That is, in the Protocol Flow there is no user input between =
steps A and B.
>=20
> That's correct.
>=20
>>=20
>> In "1. Introduction" it is stated:
>>=20
>>>  A
>>>    revocation request will invalidate the actual token and, if
>>>    applicable, other tokens based on the same access grant and the
>>>    access grant itself.
>> then, in "2. Token Revocation":
>>=20
>>>  In the next step, the authorization server invalidates the token =
and
>>>    the respective access grant.  If the particular token is a =
refresh
>>>    token and the authorization server supports the revocation of =
access
>>>    tokens, then the authorization server SHOULD also invalidate all
>>>    access tokens based on the same access grant
>> This implies that an access grant only applies to an app authorized =
on a single device. If an app is installed on multiple devices and the =
access grant is shared between both instances, revoking device A's =
access token results in the unexpected revocation of device B's token.
>=20
> You raised an interesting point. Is it desirable to share an access =
grant among different client instances? I would like to discuss this =
topic in the working group.
>=20
> If we assume it is desirable, how would the authorization process look =
alike?
>=20
> I would assume that as result of the authorization process of the 1st =
client instance, the authorization server stores an access grant, which =
is identified by the client_id and the user_id of the resource owner. =
Moreover, it creates a refresh token, which the 1st client instance uses =
to obtain new access tokens. As this client is public, the refresh token =
is the credential the intial client uses to prove its identity.
>=20
> How does the 2nd client instance join the party? I would assume the =
2nd client to initiate another code grant type flow (using the same =
client_id as the 1st client). I see two ways the authorization server =
could process this process:
>=20
> 1) After authenticating the resource owner, the authorization server =
finds the existing access grant for the client_id/user_id combination =
and automatically issues tokens w/o further user consent. Since the =
authorization server cannot authenticate the client_id, a malicious =
client could obtain and abuse the access grant of the legitimate client. =
That's why the security considerations of the core spec =
(http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:
>=20
> The authorization server SHOULD NOT process repeated authorization
>   requests automatically (without active resource owner interaction)
>   without authenticating the client or relying on other measures to
>   ensure the repeated request comes from the original client and not =
an
>   impersonator.
>=20
> Validating the redirect URI won't help that much, since this URI is =
typically device local (custom scheme or localhost).
>=20
> 2) The authorization server asks the resource owner for user consent =
and issues another pair of access/refresh token to the 2nd client. In =
this case, why would one bind this tokens to the already existing access =
grant? This would limit the resource owners capability to revoke grants =
for particular instances. I would rather create another access grant.
>=20
> Based on this thoughts I think it is not desirable to share an access =
grant among different client instances.
>=20
> What do others think?
>=20
>>=20
>> If "access grant" could be defined as "an authorization issued to the =
 client, based on the single use of an Authorization Grant" it becomes =
clear than only the tokens spawning from the app's authorization on =
device A should be revoked.
>=20
> I would like to adopt your proposal if the WG agrees.
>=20
>>=20
>> ---
>>=20
>> I spotted a typo in "3. Implementation Note":
>=20
> Thanks. Fixed.
>=20
> regards,
> Torsten.
>>=20
>>> Whether this is an viable option or
>>>    whether access token revocation is required should be decided =
based
>>>    on the service provider's risk analysis.
>> "an viable option" should be "a viable option".
>>=20
>> On 24 Nov 2012, at 18:13, Hannes Tschofenig =
 wrote:
>>=20
>>> Hi all,
>>>=20
>>> this is a working group last call for draft-ietf-oauth-revocation-03 =
on "Token Revocation".  The draft is available here:
>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>>>=20
>>> Please send you comments to the OAuth mailing list by December 10, =
2012.
>>>=20
>>> Thanks,
>>> Hannes & Derek
>>>=20
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> --
>> Mark Wubben
>>=20
>> http://novemberborn.net
>> http://twitter.com/novemberborn
>>=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 torsten@lodderstedt.net  Wed Dec 26 08:14:42 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F40D21F8CB4 for ; Wed, 26 Dec 2012 08:14:42 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKsxdRkU8Zrv for ; Wed, 26 Dec 2012 08:14:41 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5763A21F89F0 for ; Wed, 26 Dec 2012 08:14:39 -0800 (PST)
Received: from [79.253.60.241] (helo=[192.168.71.42]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1Tntcq-0001Sy-Sj; Wed, 26 Dec 2012 17:14:37 +0100
Message-ID: <50DB2269.6020501@lodderstedt.net>
Date: Wed, 26 Dec 2012 17:14:33 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: John Bradley 
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net> <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com>
In-Reply-To: <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com>
Content-Type: multipart/alternative; boundary="------------050109000101020503080001"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 26 Dec 2012 16:14:42 -0000

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

Hi John,

thanks for your feedback.

After having thought through this topic again I came to the conclusion 
that I want to have a simple spec, which doesn't unnessarily restricts 
implementations. OAuth leaves so much freedom to implementors (for good 
reasons), which we should preserve.

What does this mean? I would like to focus on the revocation of the 
token actually passed to the revocation endpoint and leave the impact on 
other related tokens and the authorization itself to the authorization 
server's policy. The authorization server may incorporate the client 
type into its revocation policy.

My base assumption is that a client must be prepared to handle 
invalidation of tokens at any time. So from an interoperability 
perspective, it's not necessary to dictate a certain revocation policy 
to authorization servers.

Current text:

In the next step, the authorization server invalidates the token and the 
respective authorization. If the particular token is a refresh token and 
the authorization server supports the revocation of access tokens, then 
the authorization server SHOULD also invalidate all access tokens based 
on the same authorization (seeImplementation Note <#impl>).

The client MUST NOT use the token again after revocation.

Proposal:

         In the next step, the authorization server invalidates the 
token. The client MUST NOT use this token again after revocation.

         Depending on the authorization server's revocation policy, the 
revocation of a particular token may cause the revocation of related 
tokens and the underlying authorization.
         If the particular token is a refresh token and the 
authorization server supports the revocation of access tokens, then the 
authorization server SHOULD also invalidate all access tokens based on 
         the same authorization (seeImplementation Note <#impl>).

Thoughts?

regards,
Torsten.

Am 26.12.2012 15:38, schrieb John Bradley:
> We don't want to share grant information across multiple instances of public client.
>
> However we don't necessarily want to preclude multiple instances of a private client,  Though how the AS would tell them apart is a interesting side question.
>
>  From a revocation point of view if you revoke the grant for one instance of a client you revoke it for all, though for a public client the grant is not doing anything anyway as the AS shield not be pre approving based on the grant.
>
> There are still some open questions about an extension to identify client instances, though personally I prefer to have each instance with it's own client ID.
>
> The language around grants has always been a bit philosophical for my taste.
>
> If I recall correctly in the code flow the code is the representation of the grant.  In  the implicit flow the grant is implicit in the access token.
> What construct (if any in the implicit case) is stored in the AS to represent this is mostly left to the imagination of the implementer.
>
> John B.
>
>
> On 2012-12-25, at 8:24 AM, Torsten Lodderstedt  wrote:
>
>> Hi Mark,
>>
>> thanks for reviewing the draft. Comments inline.
>>
>> Am 02.12.2012 18:27, schrieb Mark Wubben:
>>> The draft relies heavily on the definition "access grant", but no definition is provided in the draft or RFC 6749. It's been my interpretation that an "access grant" is the *fact* that a resource owner has authorized a client (potentially scoped) access to the protected resources. Once access is granted in this manner, further access tokens may be obtained without explicit permission by the end-user. That is, in the Protocol Flow there is no user input between steps A and B.
>> That's correct.
>>
>>> In "1. Introduction" it is stated:
>>>
>>>>   A
>>>>     revocation request will invalidate the actual token and, if
>>>>     applicable, other tokens based on the same access grant and the
>>>>     access grant itself.
>>> then, in "2. Token Revocation":
>>>
>>>>   In the next step, the authorization server invalidates the token and
>>>>     the respective access grant.  If the particular token is a refresh
>>>>     token and the authorization server supports the revocation of access
>>>>     tokens, then the authorization server SHOULD also invalidate all
>>>>     access tokens based on the same access grant
>>> This implies that an access grant only applies to an app authorized on a single device. If an app is installed on multiple devices and the access grant is shared between both instances, revoking device A's access token results in the unexpected revocation of device B's token.
>> You raised an interesting point. Is it desirable to share an access grant among different client instances? I would like to discuss this topic in the working group.
>>
>> If we assume it is desirable, how would the authorization process look alike?
>>
>> I would assume that as result of the authorization process of the 1st client instance, the authorization server stores an access grant, which is identified by the client_id and the user_id of the resource owner. Moreover, it creates a refresh token, which the 1st client instance uses to obtain new access tokens. As this client is public, the refresh token is the credential the intial client uses to prove its identity.
>>
>> How does the 2nd client instance join the party? I would assume the 2nd client to initiate another code grant type flow (using the same client_id as the 1st client). I see two ways the authorization server could process this process:
>>
>> 1) After authenticating the resource owner, the authorization server finds the existing access grant for the client_id/user_id combination and automatically issues tokens w/o further user consent. Since the authorization server cannot authenticate the client_id, a malicious client could obtain and abuse the access grant of the legitimate client. That's why the security considerations of the core spec (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:
>>
>> The authorization server SHOULD NOT process repeated authorization
>>    requests automatically (without active resource owner interaction)
>>    without authenticating the client or relying on other measures to
>>    ensure the repeated request comes from the original client and not an
>>    impersonator.
>>
>> Validating the redirect URI won't help that much, since this URI is typically device local (custom scheme or localhost).
>>
>> 2) The authorization server asks the resource owner for user consent and issues another pair of access/refresh token to the 2nd client. In this case, why would one bind this tokens to the already existing access grant? This would limit the resource owners capability to revoke grants for particular instances. I would rather create another access grant.
>>
>> Based on this thoughts I think it is not desirable to share an access grant among different client instances.
>>
>> What do others think?
>>
>>> If "access grant" could be defined as "an authorization issued to the  client, based on the single use of an Authorization Grant" it becomes clear than only the tokens spawning from the app's authorization on device A should be revoked.
>> I would like to adopt your proposal if the WG agrees.
>>
>>> ---
>>>
>>> I spotted a typo in "3. Implementation Note":
>> Thanks. Fixed.
>>
>> regards,
>> Torsten.
>>>> Whether this is an viable option or
>>>>     whether access token revocation is required should be decided based
>>>>     on the service provider's risk analysis.
>>> "an viable option" should be "a viable option".
>>>
>>> On 24 Nov 2012, at 18:13, Hannes Tschofenig  wrote:
>>>
>>>> Hi all,
>>>>
>>>> this is a working group last call for draft-ietf-oauth-revocation-03 on "Token Revocation".  The draft is available here:
>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>>>>
>>>> Please send you comments to the OAuth mailing list by December 10, 2012.
>>>>
>>>> Thanks,
>>>> Hannes & Derek
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> --
>>> Mark Wubben
>>>
>>> http://novemberborn.net
>>> http://twitter.com/novemberborn
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    Hi John,

    

    thanks for your feedback. 

    

    After having thought through this topic again I came to the
    conclusion that I want to have a simple spec, which doesn't
    unnessarily restricts implementations. OAuth leaves so much freedom
    to implementors (for good reasons), which we should preserve.

    

    What does this mean? I would like to focus on the revocation of the
    token actually passed to the revocation endpoint and leave the
    impact on other related tokens and the authorization itself to the
    authorization server's policy. The authorization server may
    incorporate the client type into its revocation policy.  

    

    My base assumption is that a client must be prepared to handle
    invalidation of tokens at any time. So from an interoperability
    perspective, it's not necessary to dictate a certain revocation
    policy to authorization servers.  

    

    Current text:

    

    
In
      the next step, the authorization server invalidates the token and
      the respective authorization. If the particular token is a refresh
      token and the authorization server supports the revocation of
      access tokens, then the authorization server SHOULD also
      invalidate all access tokens based on the same authorization (see Implementation Note).

    
The
      client MUST NOT use the token again after revocation.

    Proposal:

    

            In the next step, the authorization server invalidates the
    token. The client MUST NOT use this token again after revocation.
    

     

            Depending on the authorization server's revocation policy,
    the revocation of a particular token may cause the revocation of
    related tokens and the underlying authorization. 

            If the particular token is a refresh token and the
    authorization server supports the revocation of access tokens, then
    the authorization server SHOULD also invalidate all access tokens
    based on         the same authorization (see Implementation Note).

    

    Thoughts?

    

    regards,

    Torsten.

    

    
Am 26.12.2012 15:38, schrieb John
      Bradley:

    

    

      
We don't want to share grant information across multiple instances of public client.

However we don't necessarily want to preclude multiple instances of a private client,  Though how the AS would tell them apart is a interesting side question.

>From a revocation point of view if you revoke the grant for one instance of a client you revoke it for all, though for a public client the grant is not doing anything anyway as the AS shield not be pre approving based on the grant.

There are still some open questions about an extension to identify client instances, though personally I prefer to have each instance with it's own client ID.

The language around grants has always been a bit philosophical for my taste.   

If I recall correctly in the code flow the code is the representation of the grant.  In  the implicit flow the grant is implicit in the access token.
What construct (if any in the implicit case) is stored in the AS to represent this is mostly left to the imagination of the implementer.

John B.


On 2012-12-25, at 8:24 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:



      

        
Hi Mark,

thanks for reviewing the draft. Comments inline.

Am 02.12.2012 18:27, schrieb Mark Wubben:


        

          
The draft relies heavily on the definition "access grant", but no definition is provided in the draft or RFC 6749. It's been my interpretation that an "access grant" is the *fact* that a resource owner has authorized a client (potentially scoped) access to the protected resources. Once access is granted in this manner, further access tokens may be obtained without explicit permission by the end-user. That is, in the Protocol Flow there is no user input between steps A and B.


        

        
That's correct.



        

          
In "1. Introduction" it is stated:



          

            
 A
   revocation request will invalidate the actual token and, if
   applicable, other tokens based on the same access grant and the
   access grant itself.


          

          
then, in "2. Token Revocation":



          

            
 In the next step, the authorization server invalidates the token and
   the respective access grant.  If the particular token is a refresh
   token and the authorization server supports the revocation of access
   tokens, then the authorization server SHOULD also invalidate all
   access tokens based on the same access grant


          

          
This implies that an access grant only applies to an app authorized on a single device. If an app is installed on multiple devices and the access grant is shared between both instances, revoking device A's access token results in the unexpected revocation of device B's token.


        

        
You raised an interesting point. Is it desirable to share an access grant among different client instances? I would like to discuss this topic in the working group.

If we assume it is desirable, how would the authorization process look alike?

I would assume that as result of the authorization process of the 1st client instance, the authorization server stores an access grant, which is identified by the client_id and the user_id of the resource owner. Moreover, it creates a refresh token, which the 1st client instance uses to obtain new access tokens. As this client is public, the refresh token is the credential the intial client uses to prove its identity.

How does the 2nd client instance join the party? I would assume the 2nd client to initiate another code grant type flow (using the same client_id as the 1st client). I see two ways the authorization server could process this process:

1) After authenticating the resource owner, the authorization server finds the existing access grant for the client_id/user_id combination and automatically issues tokens w/o further user consent. Since the authorization server cannot authenticate the client_id, a malicious client could obtain and abuse the access grant of the legitimate client. That's why the security considerations of the core spec (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:

The authorization server SHOULD NOT process repeated authorization
  requests automatically (without active resource owner interaction)
  without authenticating the client or relying on other measures to
  ensure the repeated request comes from the original client and not an
  impersonator.

Validating the redirect URI won't help that much, since this URI is typically device local (custom scheme or localhost).

2) The authorization server asks the resource owner for user consent and issues another pair of access/refresh token to the 2nd client. In this case, why would one bind this tokens to the already existing access grant? This would limit the resource owners capability to revoke grants for particular instances. I would rather create another access grant.

Based on this thoughts I think it is not desirable to share an access grant among different client instances.

What do others think?



        

          
If "access grant" could be defined as "an authorization issued to the  client, based on the single use of an Authorization Grant" it becomes clear than only the tokens spawning from the app's authorization on device A should be revoked.


        

        
I would like to adopt your proposal if the WG agrees.



        

          
---

I spotted a typo in "3. Implementation Note":


        

        
Thanks. Fixed.

regards,
Torsten.


        

          

          

            
Whether this is an viable option or
   whether access token revocation is required should be decided based
   on the service provider's risk analysis.


          

          
"an viable option" should be "a viable option".

On 24 Nov 2012, at 18:13, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:



          

            
Hi all,

this is a working group last call for draft-ietf-oauth-revocation-03 on "Token Revocation".  The draft is available here:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-03

Please send you comments to the OAuth mailing list by December 10, 2012.

Thanks,
Hannes & Derek

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


          

          
--
Mark Wubben

http://novemberborn.net
http://twitter.com/novemberborn

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


        

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


      

      

    

    

  


--------------050109000101020503080001--

From Michael.Jones@microsoft.com  Wed Dec 26 17:43:26 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BE921F8CA9 for ; Wed, 26 Dec 2012 17:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level: 
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A2nw3oMAgji for ; Wed, 26 Dec 2012 17:43:25 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.29]) by ietfa.amsl.com (Postfix) with ESMTP id 390C821F8C98 for ; Wed, 26 Dec 2012 17:43:25 -0800 (PST)
Received: from BY2FFO11FD009.protection.gbl (10.1.15.200) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 27 Dec 2012 01:43:11 +0000
Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD009.mail.protection.outlook.com (10.1.14.73) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 27 Dec 2012 01:43:10 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14MLTC101.redmond.corp.microsoft.com ([157.54.79.178]) with mapi id 14.02.0318.003; Thu, 27 Dec 2012 01:43:08 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: Must the Audience value in the Assertions Spec be a URI?
Thread-Index: Ac3j04NezOeB4joAT3Gv4w/5l0I27g==
Date: Thu, 27 Dec 2012 01:43:08 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.36]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669A88C1TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51444002)(31966008)(50986001)(54316002)(54356001)(51856001)(16406001)(512954001)(47446002)(44976002)(74662001)(74502001)(59766001)(49866001)(15202345001)(46102001)(5343635001)(4396001)(47976001)(53806001)(33656001)(56816002)(77982001)(76482001)(47736001)(5343655001)(56776001)(55846006)(16236675001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07083FF734
Subject: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 01:43:26 -0000

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

http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 curre=
ntly says:


   Audience  A URI that identifies the party intended to process the

      assertion.  The audience SHOULD be the URL of the Token Endpoint

      as defined in Section 3.2 of OAuth 2.0 [RFC6749].


I think that "URI" should be changed to "value", since audience values in g=
eneral need not be URIs.  In particular, in some contexts OAuth client_id v=
alues are used as audience values, and they need not be URIs.  Also, SAML a=
llows multiple audiences (and indeed, the OAuth SAML profile is written in =
terms of "an audience value" - not "the audience value"), and so the generi=
c Assertions spec should do likewise.

Thus, I would propose changing the text above to the following:


   Audience  A value that identifies the parties intended to process the

      assertion.  An audience value SHOULD be the URL of the Token Endpoint

      as defined in Section 3.2 of OAuth 2.0 [RFC6749].

                                                            -- Mike


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











http://tools.ietf.org/html/draft-ietf-oauth-a=
ssertions-08#section-5.1 currently says:


 


   Audience  A URI that identifies the party inten=
ded to process the


      assertion.  The audience SHOU=
LD be the URL of the Token Endpoint


      as defined in Section 3.2 of OAuth 2.0 [RFC6749].


 


I think that “URI” should be changed to =
“value”, since audience values in general need not be URIs.&nbs=
p; In particular, in some contexts OAuth client_id values are used as audie=
nce values, and they need not be URIs.  Also, SAML allows multiple
 audiences (and indeed, the OAuth SAML profile is written in terms of ̶=
0;an audience value” – not “the audience value”), a=
nd so the generic Assertions spec should do likewise.


 


Thus, I would propose changing the text above to the=
 following:


 


   Audience  A value that identifies the parties i=
ntended to process the


      assertion.  An audience value=
 SHOULD be the URL of the Token Endpoint


      as defined in Section 3.2 of OAuth 2.0 [RFC6749].


 


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


 






--_000_4E1F6AAD24975D4BA5B1680429673943669A88C1TK5EX14MBXC283r_--

From torsten@lodderstedt.net  Thu Dec 27 00:18:14 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D9521F8D51 for ; Thu, 27 Dec 2012 00:18:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.816
X-Spam-Level: 
X-Spam-Status: No, score=-0.816 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnfkKcxPn7Ef for ; Thu, 27 Dec 2012 00:18:14 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id C6A8D21F85B0 for ; Thu, 27 Dec 2012 00:18:13 -0800 (PST)
Received: from [80.187.107.59] (helo=[192.168.43.3]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1To8fL-0006WX-B6; Thu, 27 Dec 2012 09:18:11 +0100
References: 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
X-Mailer: iPad Mail (10A523)
From: Torsten Lodderstedt 
Date: Thu, 27 Dec 2012 09:18:10 +0100
To: Hannes Tschofenig 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] draft-tschofenig-oauth-hotk-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 08:18:14 -0000

Hi Hannes,

as far as I understand, your proposal prevents adversaries to create new req=
uests utilizing a stolen access token. Does the proposal also intend to prev=
ent request replay?

Regards,
Torsten.

Am 16.07.2012 um 20:07 schrieb Hannes Tschofenig =
:

> Hi all,=20
>=20
> I had just submitted an updated version of the holder-of-the-key document a=
nd you can find it here:=20
> http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
>=20
> John, Tony, and Phil joined me as co-authors and the document now also des=
cribes the symmetric key case (even though I am not entirely convinced about=
 it) but there was good discussion feedback on the mailing list about it and=
 so it makes sense to illustrate a strawman solution.=20
>=20
> Ciao
> Hannes
>=20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From sberyozkin@gmail.com  Thu Dec 27 01:41:31 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC4821F8722 for ; Thu, 27 Dec 2012 01:41:31 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K9RtBjHiQYTt for ; Thu, 27 Dec 2012 01:41:29 -0800 (PST)
Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08E21F870E for ; Thu, 27 Dec 2012 01:41:28 -0800 (PST)
Received: by mail-bk0-f41.google.com with SMTP id jg9so4144574bkc.14 for ; Thu, 27 Dec 2012 01:41:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=S6QICdzYxKYYypGKxW/E37DUACZsfi5R2e0EnMkJt8k=; b=wGqR058bHdpssq3oVOEQmxYD5ftC+MNq83xc4baCIGVPYAXi32H8tj3gZKBDZUlsxe 4GQg8vpGTiS+GtT4EJ3Y5NO+QQ91Obowc6qHZCF4uWWYG6j+EodTI6s0qq+iLWG0CzQ5 qIaeQAKzV5r224kIGEeBuymx5iQv0w1CfeS3bn9O2HceK0QNZ4eQ08ID1UI4AI0dqUPN KjMIG5FM73MoACG+EdCUmdfdmMksbS/XRA2xzwUPowZ3jRz48Glj2qA/W8ReH+KvXtAh FwLRFoTpsOjXbAcO3nsOksBZUa59AJ8kdoRBWQs7C9b4xOykDZ2xtoPWhMlxNVMdnnA9 lmvw==
X-Received: by 10.204.147.5 with SMTP id j5mr14288949bkv.49.1356601287413; Thu, 27 Dec 2012 01:41:27 -0800 (PST)
Received: from [192.168.2.5] ([89.100.190.43]) by mx.google.com with ESMTPS id r16sm19914002bkv.3.2012.12.27.01.41.25 (version=SSLv3 cipher=OTHER); Thu, 27 Dec 2012 01:41:26 -0800 (PST)
Message-ID: <50DC17C4.6040300@gmail.com>
Date: Thu, 27 Dec 2012 09:41:24 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net> <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com> <50DB2269.6020501@lodderstedt.net>
In-Reply-To: <50DB2269.6020501@lodderstedt.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 09:41:31 -0000

Hi
On 26/12/12 16:14, Torsten Lodderstedt wrote:
> Hi John,
>
> thanks for your feedback.
>
> After having thought through this topic again I came to the conclusion
> that I want to have a simple spec, which doesn't unnessarily restricts
> implementations. OAuth leaves so much freedom to implementors (for good
> reasons), which we should preserve.
>
> What does this mean? I would like to focus on the revocation of the
> token actually passed to the revocation endpoint and leave the impact on
> other related tokens and the authorization itself to the authorization
> server's policy. The authorization server may incorporate the client
> type into its revocation policy.
>
> My base assumption is that a client must be prepared to handle
> invalidation of tokens at any time. So from an interoperability
> perspective, it's not necessary to dictate a certain revocation policy
> to authorization servers.
>
> Current text:
>
> In the next step, the authorization server invalidates the token and the
> respective authorization. If the particular token is a refresh token and
> the authorization server supports the revocation of access tokens, then
> the authorization server SHOULD also invalidate all access tokens based
> on the same authorization (seeImplementation Note <#impl>).
>
> The client MUST NOT use the token again after revocation.
>
> Proposal:
>
> In the next step, the authorization server invalidates the token. The
> client MUST NOT use this token again after revocation.
>
> Depending on the authorization server's revocation policy, the
> revocation of a particular token may cause the revocation of related
> tokens and the underlying authorization.
> If the particular token is a refresh token and the authorization server
> supports the revocation of access tokens, then the authorization server
> SHOULD also invalidate all access tokens based on the same authorization
> (seeImplementation Note <#impl>).
>

This implies that some ASs may, in theory at least, allow the client to 
revoke the token but keep that specific client's authorization...

Cheers, Sergey

> Thoughts?
>
> regards,
> Torsten.
>
> Am 26.12.2012 15:38, schrieb John Bradley:
>> We don't want to share grant information across multiple instances of public client.
>>
>> However we don't necessarily want to preclude multiple instances of a private client,  Though how the AS would tell them apart is a interesting side question.
>>
>>  From a revocation point of view if you revoke the grant for one instance of a client you revoke it for all, though for a public client the grant is not doing anything anyway as the AS shield not be pre approving based on the grant.
>>
>> There are still some open questions about an extension to identify client instances, though personally I prefer to have each instance with it's own client ID.
>>
>> The language around grants has always been a bit philosophical for my taste.
>>
>> If I recall correctly in the code flow the code is the representation of the grant.  In  the implicit flow the grant is implicit in the access token.
>> What construct (if any in the implicit case) is stored in the AS to represent this is mostly left to the imagination of the implementer.
>>
>> John B.
>>
>>
>> On 2012-12-25, at 8:24 AM, Torsten Lodderstedt  wrote:
>>
>>> Hi Mark,
>>>
>>> thanks for reviewing the draft. Comments inline.
>>>
>>> Am 02.12.2012 18:27, schrieb Mark Wubben:
>>>> The draft relies heavily on the definition "access grant", but no definition is provided in the draft or RFC 6749. It's been my interpretation that an "access grant" is the *fact* that a resource owner has authorized a client (potentially scoped) access to the protected resources. Once access is granted in this manner, further access tokens may be obtained without explicit permission by the end-user. That is, in the Protocol Flow there is no user input between steps A and B.
>>> That's correct.
>>>
>>>> In "1. Introduction" it is stated:
>>>>
>>>>>   A
>>>>>     revocation request will invalidate the actual token and, if
>>>>>     applicable, other tokens based on the same access grant and the
>>>>>     access grant itself.
>>>> then, in "2. Token Revocation":
>>>>
>>>>>   In the next step, the authorization server invalidates the token and
>>>>>     the respective access grant.  If the particular token is a refresh
>>>>>     token and the authorization server supports the revocation of access
>>>>>     tokens, then the authorization server SHOULD also invalidate all
>>>>>     access tokens based on the same access grant
>>>> This implies that an access grant only applies to an app authorized on a single device. If an app is installed on multiple devices and the access grant is shared between both instances, revoking device A's access token results in the unexpected revocation of device B's token.
>>> You raised an interesting point. Is it desirable to share an access grant among different client instances? I would like to discuss this topic in the working group.
>>>
>>> If we assume it is desirable, how would the authorization process look alike?
>>>
>>> I would assume that as result of the authorization process of the 1st client instance, the authorization server stores an access grant, which is identified by the client_id and the user_id of the resource owner. Moreover, it creates a refresh token, which the 1st client instance uses to obtain new access tokens. As this client is public, the refresh token is the credential the intial client uses to prove its identity.
>>>
>>> How does the 2nd client instance join the party? I would assume the 2nd client to initiate another code grant type flow (using the same client_id as the 1st client). I see two ways the authorization server could process this process:
>>>
>>> 1) After authenticating the resource owner, the authorization server finds the existing access grant for the client_id/user_id combination and automatically issues tokens w/o further user consent. Since the authorization server cannot authenticate the client_id, a malicious client could obtain and abuse the access grant of the legitimate client. That's why the security considerations of the core spec (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:
>>>
>>> The authorization server SHOULD NOT process repeated authorization
>>>    requests automatically (without active resource owner interaction)
>>>    without authenticating the client or relying on other measures to
>>>    ensure the repeated request comes from the original client and not an
>>>    impersonator.
>>>
>>> Validating the redirect URI won't help that much, since this URI is typically device local (custom scheme or localhost).
>>>
>>> 2) The authorization server asks the resource owner for user consent and issues another pair of access/refresh token to the 2nd client. In this case, why would one bind this tokens to the already existing access grant? This would limit the resource owners capability to revoke grants for particular instances. I would rather create another access grant.
>>>
>>> Based on this thoughts I think it is not desirable to share an access grant among different client instances.
>>>
>>> What do others think?
>>>
>>>> If "access grant" could be defined as "an authorization issued to the  client, based on the single use of an Authorization Grant" it becomes clear than only the tokens spawning from the app's authorization on device A should be revoked.
>>> I would like to adopt your proposal if the WG agrees.
>>>
>>>> ---
>>>>
>>>> I spotted a typo in "3. Implementation Note":
>>> Thanks. Fixed.
>>>
>>> regards,
>>> Torsten.
>>>>> Whether this is an viable option or
>>>>>     whether access token revocation is required should be decided based
>>>>>     on the service provider's risk analysis.
>>>> "an viable option" should be "a viable option".
>>>>
>>>> On 24 Nov 2012, at 18:13, Hannes Tschofenig  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> this is a working group last call for draft-ietf-oauth-revocation-03 on "Token Revocation".  The draft is available here:
>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>>>>>
>>>>> Please send you comments to the OAuth mailing list by December 10, 2012.
>>>>>
>>>>> Thanks,
>>>>> Hannes&  Derek
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> --
>>>> Mark Wubben
>>>>
>>>> http://novemberborn.net
>>>> http://twitter.com/novemberborn
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From torsten@lodderstedt.net  Wed Dec 26 22:46:19 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09A321F8D19 for ; Wed, 26 Dec 2012 22:46:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level: 
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[AWL=-0.698,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+GO99IaFqgO for ; Wed, 26 Dec 2012 22:46:13 -0800 (PST)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.37]) by ietfa.amsl.com (Postfix) with ESMTP id 310BE21F8C9F for ; Wed, 26 Dec 2012 22:46:12 -0800 (PST)
Received: from [79.253.52.158] (helo=[192.168.71.56]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1To7EI-0000qO-1M; Thu, 27 Dec 2012 07:46:10 +0100
References: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary=Apple-Mail-2D703248-DBFF-4B3F-9C9F-A266EE2076E5
Content-Transfer-Encoding: 7bit
Message-Id: <0D574E13-BA0C-46BD-9A27-37C06EAA1986@lodderstedt.net>
X-Mailer: iPad Mail (10A523)
From: Torsten Lodderstedt 
Date: Thu, 27 Dec 2012 07:46:10 +0100
To: Mike Jones 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 06:46:19 -0000

--Apple-Mail-2D703248-DBFF-4B3F-9C9F-A266EE2076E5
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

+1=20

Am 27.12.2012 um 02:43 schrieb Mike Jones :

> http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 curr=
ently says:
> =20
>    Audience  A URI that identifies the party intended to process the
>       assertion.  The audience SHOULD be the URL of the Token Endpoint
>       as defined in Section 3.2 of OAuth 2.0 [RFC6749].
> =20
> I think that =E2=80=9CURI=E2=80=9D should be changed to =E2=80=9Cvalue=E2=80=
=9D, since audience values in general need not be URIs.  In particular, in s=
ome contexts OAuth client_id values are used as audience values, and they ne=
ed not be URIs.  Also, SAML allows multiple audiences (and indeed, the OAuth=
 SAML profile is written in terms of =E2=80=9Can audience value=E2=80=9D =E2=
=80=93 not =E2=80=9Cthe audience value=E2=80=9D), and so the generic Asserti=
ons spec should do likewise.
> =20
> Thus, I would propose changing the text above to the following:
> =20
>    Audience  A value that identifies the parties intended to process the
>       assertion.  An audience value SHOULD be the URL of the Token Endpoin=
t
>       as defined in Section 3.2 of OAuth 2.0 [RFC6749].
> =20
>                                                             -- Mike
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

--Apple-Mail-2D703248-DBFF-4B3F-9C9F-A266EE2076E5
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


+1 

Am 27.12.2012 um 02:43=
 schrieb Mike Jones <Micha=
el.Jones@microsoft.com>:

=


=








http://tools.ietf.org/html/draft-ietf-oauth-ass=
ertions-08#section-5.1 currently says:


 


   Audience  A URI that identifies the party intende=
d to process the


      assertion.  The audience SHOULD=
 be the URL of the Token Endpoint


      as defined in Section 3.2 o=
f OAuth 2.0 [RFC6749].<=
/pre>

 


I think that =E2=80=9CURI=E2=80=9D should be changed t=
o =E2=80=9Cvalue=E2=80=9D, since audience values in general need not be URIs=
.  In particular, in some contexts OAuth client_id values are used as a=
udience values, and they need not be URIs.  Also, SAML allows multiple
 audiences (and indeed, the OAuth SAML profile is written in terms of =E2=80=
=9Can audience value=E2=80=9D =E2=80=93 not =E2=80=9Cthe audience value=E2=80=
=9D), and so the generic Assertions spec should do likewise.


 


Thus, I would propose changing the text above to the f=
ollowing:


 


   Audience  A value that identifies the parties int=
ended to process the


      assertion.  An audience value S=
HOULD be the URL of the Token Endpoint


      as defined in Section 3.2 o=
f OAuth 2.0 [RFC6749].<=
/pre>

 


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


 






____________________=
___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai=
lman/listinfo/oauth
=

--Apple-Mail-2D703248-DBFF-4B3F-9C9F-A266EE2076E5--

From sberyozkin@gmail.com  Thu Dec 27 01:57:53 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AAE21F890D for ; Thu, 27 Dec 2012 01:57:53 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzYQDoc398Pm for ; Thu, 27 Dec 2012 01:57:52 -0800 (PST)
Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id EE79E21F85F3 for ; Thu, 27 Dec 2012 01:57:51 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id j4so4131859bkw.20 for ; Thu, 27 Dec 2012 01:57:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8a0IG35lvZ/ELKYFL6CoI4XsQlO5WhN84scvLTunWh4=; b=vS7UKLSas5qRksQwnGAk3rATSUEihV9VJQBCg4uEkatc/mot3+2PZspDNaUjCRipqF roOZ5JnDzT98dyzroUTKS/LJar3ANbnzD1F1/V2j0fJtg2neNLEKdaPEIFbvT1nfKNiW /EZ6yKj0dzwPIcxcnQBsw5fvuyP7YX8nISm0fdUc7DTLoaN3vwMwdKJIamtjBL8/gDZp EqzMIitVyWQ/xGFzhlOVjkfnXbCTuM0wk0B0s2/DWevCWWstCuysqPO0qWjbo2rsgnAC h39PZTEnsk7juJMH5V/hileduqnACO7hQ/ghLSk0OY82bzWQHVVlTwUkZb5Wv8teaSn6 /72Q==
X-Received: by 10.204.4.90 with SMTP id 26mr14908355bkq.76.1356602270389; Thu, 27 Dec 2012 01:57:50 -0800 (PST)
Received: from [192.168.2.5] ([89.100.190.43]) by mx.google.com with ESMTPS id u3sm19970697bkw.9.2012.12.27.01.57.48 (version=SSLv3 cipher=OTHER); Thu, 27 Dec 2012 01:57:49 -0800 (PST)
Message-ID: <50DC1B9C.1020505@gmail.com>
Date: Thu, 27 Dec 2012 09:57:48 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References:  <50BCC54D.5060609@mitre.org> <50D99EF8.80308@lodderstedt.net>
In-Reply-To: <50D99EF8.80308@lodderstedt.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 09:57:53 -0000

sHi
On 25/12/12 12:41, Torsten Lodderstedt wrote:
> Hi all,
>
> any other opinion regarding having or not having a token type parameter?
>
> I would like to go with #1 as it is rather late in the process to
> (re-)introduce a mandatory parameter. And making it an optional
> parameter (#4) seems not really useful to me.
>
ce
+1 to #4 - it might help optimizing the lookups. Example, refresh and 
access token keys may be kept in different tables, so ideally revoking a 
refresh token only would involve a definite lookup to the refresh token 
table/etc only, same for access tokens.

Having said this, the optional parameter can probably be added later.

However, it made me think, should the client be able to say, "I'd like 
to revoke this refresh token and the access token linked to this refresh 
token", in other words, should the client be given an option to optimize 
the revocation process ? Probably can be reviewed later too

thanks, Sergey

> regards,
> Torsten.
>> The way I see it, we've got a few options:
>>
>> 1) Leave it as-is, with no field. Client/RS/whoever just sends the
>> token over and it's the AS's problem.
>> 2) Define a required field with "access" and "refresh" value
>> semantics, and state that other values MAY be accepted by a given AS,
>> or defined by extension protocols. These extension values MUST be
>> fully qualified URIs.
>> 3) Same as #2, but with IANA registry to allow for non-collision of
>> short names.
>> 4) Define an optional field that the client MAY send as a hint to the
>> AS, and it's up to the AS to figure out if it makes any sense in the
>> context of the request. All bets are off as to the content of this
>> field, other than "it's a string".
>>
>> There may be other approaches as well.
>>
>> -- Justin
>>
>> On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:
>>> Here is my review of the Toke Revocation draft
>>> (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>>>
>>> Section 1. Introduction
>>> First paragraph has the following definition in it: "A token is the
>>> external representation of an access grant issued by a resource owner
>>> to a particular client." This seems a bit odd to me. The OAuth2 spec
>>> [1] defines "access token" as "An access token is a string
>>> representing an authorization issued to the client." (section 1.4)
>>> and "refresh token" as "credentials used to obtain access tokens
>>> (section 1.5). Should this spec borrow similar language to be more
>>> consistent?
>>>
>>> Paragraph 2 "From an end-user's perception" should be "From an
>>> end-user's perspective".
>>>
>>> Section 2. Token Revocation
>>> What is the reason for requiring the service provider to detect the
>>> token type automatically? For our implementation, Access Tokens,
>>> Refresh Tokens, and ID Tokens are all structured tokens (with unique
>>> structures across the three types), and as such are stored in 3
>>> separate database tables. In order to "detect" the token type, we
>>> would need to run a get-by-value query across all three tables, check
>>> if any of those queries returned anything, and then proceed to revoke
>>> the token (if one was found). This does not seem ideal to me.
>>>
>>> The spec says that "The authorization server first validates the
>>> client credentials (in case of a confidential client) and verifies
>>> whether the client is authorized to revoke the particular token."
>>> What does this verification entail? Does it just mean that 1) the
>>> client credentials must validate and 2) the token must belong to the
>>> client requesting the revocation? If so I think the text should be
>>> clarified to reflect that. Or are you thinking of a case where a
>>> client might not be allowed to revoke its own tokens, via some kind
>>> of scoping?
>>>
>>> 2.1 Cross Origin Support
>>> Formatting looks a little off here, otherwise this section looks fine.
>>>
>>> 5. Security Considerations
>>> Paragraph 3 (Malicious clients): "Appropriate countermeasures, which
>>> should be in place for the token endpoint as well, MUST be applied to
>>> the revocation endpoint." These countermeasures should be referenced
>>> to the proper section(s) of the OAuth core spec or Threat Model
>>> document.
>>>
>>> Paragraph 4 reads a bit oddly. Suggest following rewording:
>>> "A malicious client may attempt to guess valid tokens on this
>>> endpoint by making revocation requests against potential token
>>> strings. According to this specification, a client's request must
>>> contain a valid client_id, in the case of a public client, or valid
>>> client credentials, in the case of a confidential client. The token
>>> being revoked must also belong to the requesting client. If an
>>> attacker is able to successfully guess a public client's client_id
>>> and one of their tokens, or a private client's credentials and one of
>>> their tokens, they could do much worse damage by using the token
>>> elsewhere than by revoking it. If they chose to revoke the token, the
>>> legitimate client will lose its authorization and will need to prompt
>>> the user again. No further damage is done and the guessed token is
>>> now worthless."
>>>
>>> References:
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>>>
>>> --
>>> Amanda Anganes
>>> Info Sys Engineer, G061
>>> The MITRE Corporation
>>> 781-271-3103
>>> aanganes@mitre.org
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From sberyozkin@gmail.com  Thu Dec 27 03:44:07 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC0821F8D4C for ; Thu, 27 Dec 2012 03:44: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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGj45GYqT7T5 for ; Thu, 27 Dec 2012 03:44:06 -0800 (PST)
Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id 4778921F8D45 for ; Thu, 27 Dec 2012 03:44:06 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id j4so4213273bkw.34 for ; Thu, 27 Dec 2012 03:44:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Rydjg2FdRBgXs2ppYWQ3Y/fJFZAsc9BvhuwBvQcaMB0=; b=fQ4YIw+Ke31aQBpmMz9MPqMqMjwy7XoYTU9Uq3NRS/etUjXL2zOIUJzXnvSgHDVFUm sMwBDES3+/5VBcityyaB969VZBb6qIDbf6J6JIBTbXVpgA9xZZRHBpIGijlwioowu2lA M/k4pBoJtNQS9GdxlD74vQ1SipRIHDbPVe+jZEmFNC0q97geyGUUTehZecGSlJXhFFt8 N567+I+9Y+Z5SyFZmRccK06Oh0y8slyjwPnoqOJvglzvtYoUYTxIlQteSBPTi9zaekGM suEGCoTvBQF0EVuszYhBfjGmCxD+i6dacuTSLlKfdDz8vmJnrOL35InZqqGv6YIg5TRO o2ig==
X-Received: by 10.204.130.87 with SMTP id r23mr14443704bks.90.1356608644883; Thu, 27 Dec 2012 03:44:04 -0800 (PST)
Received: from [192.168.2.5] ([89.100.190.43]) by mx.google.com with ESMTPS id f24sm20276886bkv.7.2012.12.27.03.44.02 (version=SSLv3 cipher=OTHER); Thu, 27 Dec 2012 03:44:03 -0800 (PST)
Message-ID: <50DC3481.7070808@gmail.com>
Date: Thu, 27 Dec 2012 11:44:01 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net> <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com> <50DB2269.6020501@lodderstedt.net> <50DC17C4.6040300@gmail.com>
In-Reply-To: <50DC17C4.6040300@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 11:44:08 -0000

Hi again,
On 27/12/12 09:41, Sergey Beryozkin wrote:
> Hi
> On 26/12/12 16:14, Torsten Lodderstedt wrote:
>> Hi John,
>>
>> thanks for your feedback.
>>
>> After having thought through this topic again I came to the conclusion
>> that I want to have a simple spec, which doesn't unnessarily restricts
>> implementations. OAuth leaves so much freedom to implementors (for good
>> reasons), which we should preserve.
>>
>> What does this mean? I would like to focus on the revocation of the
>> token actually passed to the revocation endpoint and leave the impact on
>> other related tokens and the authorization itself to the authorization
>> server's policy. The authorization server may incorporate the client
>> type into its revocation policy.
>>
>> My base assumption is that a client must be prepared to handle
>> invalidation of tokens at any time. So from an interoperability
>> perspective, it's not necessary to dictate a certain revocation policy
>> to authorization servers.
>>
>> Current text:
>>
>> In the next step, the authorization server invalidates the token and the
>> respective authorization. If the particular token is a refresh token and
>> the authorization server supports the revocation of access tokens, then
>> the authorization server SHOULD also invalidate all access tokens based
>> on the same authorization (seeImplementation Note <#impl>).
>>
>> The client MUST NOT use the token again after revocation.
>>
>> Proposal:
>>
>> In the next step, the authorization server invalidates the token. The
>> client MUST NOT use this token again after revocation.
>>
>> Depending on the authorization server's revocation policy, the
>> revocation of a particular token may cause the revocation of related
>> tokens and the underlying authorization.
>> If the particular token is a refresh token and the authorization server
>> supports the revocation of access tokens, then the authorization server
>> SHOULD also invalidate all access tokens based on the same authorization
>> (seeImplementation Note <#impl>).
>>
>
> This implies that some ASs may, in theory at least, allow the client to
> revoke the token but keep that specific client's authorization...

Perhaps, having an optional token type parameter (as discussed in the 
different thread) will make the proposed update more interesting, for 
example, it can be the policy of a given AS to revoke a related access 
token if the client requests the revocation of the refresh token only, 
this can be documented and the client can thus avoid issuing a 2nd 
revocation request

Sorry if it all misses the point :-)

thanks, Sergey

>
> Cheers, Sergey
>
>> Thoughts?
>>
>> regards,
>> Torsten.
>>
>> Am 26.12.2012 15:38, schrieb John Bradley:
>>> We don't want to share grant information across multiple instances of
>>> public client.
>>>
>>> However we don't necessarily want to preclude multiple instances of a
>>> private client, Though how the AS would tell them apart is a
>>> interesting side question.
>>>
>>> From a revocation point of view if you revoke the grant for one
>>> instance of a client you revoke it for all, though for a public
>>> client the grant is not doing anything anyway as the AS shield not be
>>> pre approving based on the grant.
>>>
>>> There are still some open questions about an extension to identify
>>> client instances, though personally I prefer to have each instance
>>> with it's own client ID.
>>>
>>> The language around grants has always been a bit philosophical for my
>>> taste.
>>>
>>> If I recall correctly in the code flow the code is the representation
>>> of the grant. In the implicit flow the grant is implicit in the
>>> access token.
>>> What construct (if any in the implicit case) is stored in the AS to
>>> represent this is mostly left to the imagination of the implementer.
>>>
>>> John B.
>>>
>>>
>>> On 2012-12-25, at 8:24 AM, Torsten
>>> Lodderstedt wrote:
>>>
>>>> Hi Mark,
>>>>
>>>> thanks for reviewing the draft. Comments inline.
>>>>
>>>> Am 02.12.2012 18:27, schrieb Mark Wubben:
>>>>> The draft relies heavily on the definition "access grant", but no
>>>>> definition is provided in the draft or RFC 6749. It's been my
>>>>> interpretation that an "access grant" is the *fact* that a resource
>>>>> owner has authorized a client (potentially scoped) access to the
>>>>> protected resources. Once access is granted in this manner, further
>>>>> access tokens may be obtained without explicit permission by the
>>>>> end-user. That is, in the Protocol Flow there is no user input
>>>>> between steps A and B.
>>>> That's correct.
>>>>
>>>>> In "1. Introduction" it is stated:
>>>>>
>>>>>> A
>>>>>> revocation request will invalidate the actual token and, if
>>>>>> applicable, other tokens based on the same access grant and the
>>>>>> access grant itself.
>>>>> then, in "2. Token Revocation":
>>>>>
>>>>>> In the next step, the authorization server invalidates the token and
>>>>>> the respective access grant. If the particular token is a refresh
>>>>>> token and the authorization server supports the revocation of access
>>>>>> tokens, then the authorization server SHOULD also invalidate all
>>>>>> access tokens based on the same access grant
>>>>> This implies that an access grant only applies to an app authorized
>>>>> on a single device. If an app is installed on multiple devices and
>>>>> the access grant is shared between both instances, revoking device
>>>>> A's access token results in the unexpected revocation of device B's
>>>>> token.
>>>> You raised an interesting point. Is it desirable to share an access
>>>> grant among different client instances? I would like to discuss this
>>>> topic in the working group.
>>>>
>>>> If we assume it is desirable, how would the authorization process
>>>> look alike?
>>>>
>>>> I would assume that as result of the authorization process of the
>>>> 1st client instance, the authorization server stores an access
>>>> grant, which is identified by the client_id and the user_id of the
>>>> resource owner. Moreover, it creates a refresh token, which the 1st
>>>> client instance uses to obtain new access tokens. As this client is
>>>> public, the refresh token is the credential the intial client uses
>>>> to prove its identity.
>>>>
>>>> How does the 2nd client instance join the party? I would assume the
>>>> 2nd client to initiate another code grant type flow (using the same
>>>> client_id as the 1st client). I see two ways the authorization
>>>> server could process this process:
>>>>
>>>> 1) After authenticating the resource owner, the authorization server
>>>> finds the existing access grant for the client_id/user_id
>>>> combination and automatically issues tokens w/o further user
>>>> consent. Since the authorization server cannot authenticate the
>>>> client_id, a malicious client could obtain and abuse the access
>>>> grant of the legitimate client. That's why the security
>>>> considerations of the core spec
>>>> (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:
>>>>
>>>> The authorization server SHOULD NOT process repeated authorization
>>>> requests automatically (without active resource owner interaction)
>>>> without authenticating the client or relying on other measures to
>>>> ensure the repeated request comes from the original client and not an
>>>> impersonator.
>>>>
>>>> Validating the redirect URI won't help that much, since this URI is
>>>> typically device local (custom scheme or localhost).
>>>>
>>>> 2) The authorization server asks the resource owner for user consent
>>>> and issues another pair of access/refresh token to the 2nd client.
>>>> In this case, why would one bind this tokens to the already existing
>>>> access grant? This would limit the resource owners capability to
>>>> revoke grants for particular instances. I would rather create
>>>> another access grant.
>>>>
>>>> Based on this thoughts I think it is not desirable to share an
>>>> access grant among different client instances.
>>>>
>>>> What do others think?
>>>>
>>>>> If "access grant" could be defined as "an authorization issued to
>>>>> the client, based on the single use of an Authorization Grant" it
>>>>> becomes clear than only the tokens spawning from the app's
>>>>> authorization on device A should be revoked.
>>>> I would like to adopt your proposal if the WG agrees.
>>>>
>>>>> ---
>>>>>
>>>>> I spotted a typo in "3. Implementation Note":
>>>> Thanks. Fixed.
>>>>
>>>> regards,
>>>> Torsten.
>>>>>> Whether this is an viable option or
>>>>>> whether access token revocation is required should be decided based
>>>>>> on the service provider's risk analysis.
>>>>> "an viable option" should be "a viable option".
>>>>>
>>>>> On 24 Nov 2012, at 18:13, Hannes
>>>>> Tschofenig wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> this is a working group last call for
>>>>>> draft-ietf-oauth-revocation-03 on "Token Revocation". The draft is
>>>>>> available here:
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>>>>>>
>>>>>> Please send you comments to the OAuth mailing list by December 10,
>>>>>> 2012.
>>>>>>
>>>>>> Thanks,
>>>>>> Hannes& Derek
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> --
>>>>> Mark Wubben
>>>>>
>>>>> http://novemberborn.net
>>>>> http://twitter.com/novemberborn
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>


From ve7jtb@ve7jtb.com  Thu Dec 27 05:31:51 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAA021F8C74 for ; Thu, 27 Dec 2012 05:31:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.348
X-Spam-Level: 
X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfXZh+dxMQAv for ; Thu, 27 Dec 2012 05:31:50 -0800 (PST)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 401E521F8C54 for ; Thu, 27 Dec 2012 05:31:50 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id n41so4886793qco.21 for ; Thu, 27 Dec 2012 05:31:49 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=Wmr8ifNyFzooBqoSLQKjt9Ylu8bbuCUDRCkiJqesF0Y=; b=exvuquQBsprPNqs5NhAv3rSSR8ZLj87K6J+P3g9LOvJ1zL0cpq+TMq8qg4C95S1RyR FezvaDkDqAVciM4TtwWaDAGYl4S9YhEt6xATFuvA/Q6MQ3p1vnkgvRV/XMHKeN3PVNrg s0Rs3s4rdvrA3PjtBHaJvqztURzgfMF7zSN6DO9pyDgcS+oJeljHzZhf7swmMsyVI1xR Vz8tyC4pegSwpDq+LpqxSYMUr6rpPjMXpudm/Q/pUmgKEYkPTSYeFXkYye8tBGSSW1PH NcOTBi8YzUXfmfu13Bi260cR+mimzi9qFR1UXqmvZ9dYBXm+r786KnsofmJ4GDi+WFT7 bu1g==
X-Received: by 10.224.183.194 with SMTP id ch2mr13841408qab.24.1356615109414;  Thu, 27 Dec 2012 05:31:49 -0800 (PST)
Received: from [192.168.1.211] (190-20-36-168.baf.movistar.cl. [190.20.36.168]) by mx.google.com with ESMTPS id l6sm6570078qal.21.2012.12.27.05.31.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Dec 2012 05:31:48 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0A8986B2-50F6-48FD-B132-7482D464A5B7"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Thu, 27 Dec 2012 10:31:40 -0300
Message-Id: 
References: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkJbDInHrN+liTtxCXGS+iXipy03IfwGOF0z51SSw7l+Y8sZbXy/ftVxcn5PHQTRundhoCs
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 13:31:51 -0000

--Apple-Mail=_0A8986B2-50F6-48FD-B132-7482D464A5B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Agreed.

We need to clarify that the value of the audience claim can be multi =
valued as well.=20

John B.

On 2012-12-26, at 10:43 PM, Mike Jones  =
wrote:

> http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 =
currently says:
> =20
>    Audience  A URI that identifies the party intended to process the
>       assertion.  The audience SHOULD be the URL of the Token Endpoint
>       as defined in Section 3.2 of OAuth 2.0 [RFC6749].
> =20
> I think that =93URI=94 should be changed to =93value=94, since =
audience values in general need not be URIs.  In particular, in some =
contexts OAuth client_id values are used as audience values, and they =
need not be URIs.  Also, SAML allows multiple audiences (and indeed, the =
OAuth SAML profile is written in terms of =93an audience value=94 =96 =
not =93the audience value=94), and so the generic Assertions spec should =
do likewise.
> =20
> Thus, I would propose changing the text above to the following:
> =20
>    Audience  A value that identifies the parties intended to process =
the
>       assertion.  An audience value SHOULD be the URL of the Token =
Endpoint
>       as defined in Section 3.2 of OAuth 2.0 [RFC6749].
> =20
>                                                             -- Mike
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_0A8986B2-50F6-48FD-B132-7482D464A5B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Agreed.

We =
need to clarify that the value of the audience claim can be multi valued =
as well. 

John =
B.

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

      as defined in =
Section =
3.2 of OAuth 2.0 [
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 14:22:36 -0000

--------------060506000501050707080202
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi Torsten,

Responses inline in blue.

On 12/25/2012 08:11 AM, Torsten Lodderstedt wrote:
> Hi Amanda,
>
> thank you for reviewing the draft. Comments inline.
>
> Am 30.11.2012 22:28, schrieb Anganes, Amanda L:
>> Here is my review of the Toke Revocation draft 
>> (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>>
>> Section 1. Introduction
>> First paragraph has the following definition in it: "A token is the 
>> external representation of an access grant issued by a resource owner 
>> to a particular client." This seems a bit odd to me. The OAuth2 spec 
>> [1] defines "access token" as "An access token is a string 
>> representing an authorization issued to the client." (section 1.4) 
>> and "refresh token" as "credentials used to obtain access tokens 
>> (section 1.5). Should this spec borrow similar language to be more 
>> consistent?
>>
>
> What about this:
>
> "A token is a string representing an authorization issued by the 
> resource owner to the client. A revocation request will invalidate the 
> actual token and, if applicable, other tokens based on the same 
> authorization and the authorization itself."
>
Yes, that sounds more consistent.
>
>> Paragraph 2 "From an end-user's perception" should be "From an 
>> end-user's perspective".
>
> changed it.
>
>>
>> Section 2. Token Revocation
>> What is the reason for requiring the service provider to detect the 
>> token type automatically? For our implementation, Access Tokens, 
>> Refresh Tokens, and ID Tokens are all structured tokens (with unique 
>> structures across the three types), and as such are stored in 3 
>> separate database tables. In order to "detect" the token type, we 
>> would need to run a get-by-value query across all three tables, check 
>> if any of those queries returned anything, and then proceed to revoke 
>> the token (if one was found). This does not seem ideal to me.
>
> As pointed out by Justin, there was such a parameter in an early 
> revision of the draft. WG feedback caused me to remove it. I would 
> like to stick with auto detection if not otherwise decided by the 
> working group. I explicitely asked for feedback on the other thread.
>
>>
>> The spec says that "The authorization server first validates the 
>> client credentials (in case of a confidential client) and verifies 
>> whether the client is authorized to revoke the particular token." 
>> What does this verification entail? Does it just mean that 1) the 
>> client credentials must validate and 2) the token must belong to the 
>> client requesting the revocation? If so I think the text should be 
>> clarified to reflect that. Or are you thinking of a case where a 
>> client might not be allowed to revoke its own tokens, via some kind 
>> of scoping?
>
> It's 1+2
>
> What about this text
>
> "The authorization server first validates the client credentials (in 
> case of a confidential client) and then verifies whether the client is 
> authorized to revoke the token. A client may only revoke a token if 
> the validation of the client identity succeeds and the particular 
> token had been issued to this client."
>
The confusing phrase here is "authorized to revoke the token". If a 
client just needs to be the owner of the token in order to revoke it, I 
would say that:

"The authorization server first validates the client credentials (in 
case of a confidential client) and then verifies whether the token was 
issued to the client making the revocation request."

Otherwise, the "authorized to revoke the token" language sounds like 
there might be some way to *give* authorization to a particular client, 
as opposed to authorization simply requiring authentication and ownership.
>>
>> 2.1 Cross Origin Support
>> Formatting looks a little off here, otherwise this section looks fine.
>
> What specifically to you mean?
The indentation looks strange. Should the example request, successful 
response, and error response be indented? The example request in the 
previous section is indented. Also, should the definition of the 
"callback" parameter say "OPTIONAL." before the definition, or is that 
redundant because the paragraph before indicates "MAY support"? I am not 
sure of the IETF standards for these things; the section just didn't 
look quite right to me.
>
>>
>> 5. Security Considerations
>> Paragraph 3 (Malicious clients...): "Appropriate countermeasures, 
>> which should be in place for the token endpoint as well, MUST be 
>> applied to the revocation endpoint." These countermeasures should be 
>> referenced to the proper section(s) of the OAuth core spec or Threat 
>> Model document.
>
> Added reference to section 4.4.1.11 of threat model documemt
>
>>
>> Paragraph 4 reads a bit oddly. Suggest following rewording:
>> "A malicious client may attempt to guess valid tokens on this 
>> endpoint by making revocation requests against potential token 
>> strings. According to this specification, a client's request must 
>> contain a valid client_id, in the case of a public client, or valid 
>> client credentials, in the case of a confidential client. The token 
>> being revoked must also belong to the requesting client. If an 
>> attacker is able to successfully guess a public client's client_id 
>> and one of their tokens, or a private client's credentials and one of 
>> their tokens, they could do much worse damage by using the token 
>> elsewhere than by revoking it. If they chose to revoke the token, the 
>> legitimate client will lose its authorization and will need to prompt 
>> the user again. No further damage is done and the guessed token is 
>> now worthless."
>>
>
> Adopted your text.
>
> best regards,
> Torsten.
>> References:
>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>>
>> -- 
>> Amanda Anganes
>> Info Sys Engineer, G061
>> The MITRE Corporation
>> 781-271-3103
>> aanganes@mitre.org
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
Thanks,

--Amanda

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


  
    
  
  
    Hi Torsten,

      

      Responses inline in blue. 

    

    
On 12/25/2012 08:11 AM, Torsten
      Lodderstedt wrote:

    

    

      
      Hi Amanda,

      

      thank you for reviewing the draft. Comments inline.

      

      
Am 30.11.2012 22:28, schrieb Anganes,
        Amanda L:

      

      

        

          

            
            
 

            

            
 Section 1.
              Introduction

            
First paragraph has the
                following definition in it: "A token is the external
                representation of an access grant
                issued by a resource owner to a particular client." This
                seems a bit odd to me. The OAuth2
                spec [1] defines "access token" as "An access token is a string
                representing an authorization issued to the client." (section 1.4) and "refresh
                token" as "credentials used to obtain access tokens
                (section 1.5). Should this spec borrow similar language
                to be more consistent?

            


              

          

        

      

      

      What about this:

      

      "A token is a string representing an authorization issued by the
      resource owner to the client. A revocation request will invalidate
      the actual token and, if applicable, other tokens based on the
      same authorization and the authorization itself."

      

    

    Yes, that sounds more consistent. 

    
 

      

        

          

            
 

            
Paragraph 2 "From an end-user's
                perception" should be "From an end-user's perspective".

          

        

      

      

      changed it.

      

      

        

          

            


              

            
Section 2. Token Revocation

            
What is the reason for requiring the
                service provider to detect the token type automatically?
                For our implementation, Access Tokens, Refresh Tokens,
                and ID Tokens are all structured tokens (with unique
                structures across the three types), and as such are
                stored in 3 separate database tables. In order to
                "detect" the token type, we would need to run a
                get-by-value query across all three tables, check if any
                of those queries returned anything, and then proceed to
                revoke the token (if one was found). This does not seem
                ideal to me.

          

        

      

      

      As pointed out by Justin, there was such a parameter in an early
      revision of the draft. WG feedback caused me to remove it. I would
      like to stick with auto detection if not otherwise decided by the
      working group. I explicitely asked for feedback on the other
      thread.  

      

      

        

          

            
 

            


              

            
The spec says that "The authorization server first
                validates the client credentials (in case of a
                confidential client) and verifies whether the client is
                authorized to revoke the particular token." What does
                this verification entail? Does it just mean that 1) the
                client credentials must validate and 2) the token must
                belong to the client requesting the revocation? If so I
                think the text should be clarified to reflect that. Or
                are you thinking of a case where a client might not be
                allowed to revoke its own tokens, via some kind of
                scoping?

          

        

      

      

      It's 1+2

      

      What about this text

      

      "The authorization server first validates the client credentials
      (in case of a confidential client) and then verifies whether the
      client is authorized to revoke the token. A client may only revoke
      a token if the validation of the client identity succeeds and the
      particular token had been issued to this client."

      

    

    The confusing phrase here is "authorized to
      revoke the token". If a client just needs to be the owner of the
      token in order to revoke it, I would say that:

      

      "The authorization server first validates the client credentials
      (in case of a confidential client) and then verifies whether the
      token was issued to the client making the revocation request." 

      

      Otherwise, the "authorized to revoke the token" language sounds
      like there might be some way to *give* authorization to a
      particular client, as opposed to authorization simply requiring
      authentication and ownership. 

    

      

        

          

            
 

            


              

            
 2.1 Cross Origin
              Support

            
 Formatting looks a
              little off here, otherwise this section looks fine.

          

        

      

      

      What specifically to you mean?

    

    The indentation looks strange. Should the
      example request, successful response, and error response be
      indented? The example request in the previous section is indented.
      Also, should the definition of the "callback" parameter say
      "OPTIONAL." before the definition, or is that redundant because
      the paragraph before indicates "MAY support"? I am not sure of the
      IETF standards for these things; the section just didn't look
      quite right to me. 

    
 

      

        

          

            
 

            

            
 5. Security
              Considerations

            
 Paragraph 3
              (Malicious clients…): "Appropriate countermeasures, which
              should be in place for the token endpoint as well, MUST be
              applied to the revocation endpoint." These countermeasures
              should be referenced to the proper section(s) of the OAuth
              core spec or Threat Model document. 

            

          

        

      

      

      Added reference to section 4.4.1.11 of
        threat model documemt

        

      
      

        

          

            
 

            

            
 Paragraph 4 reads a
              bit oddly. Suggest following rewording:

            
 "A
              malicious client may attempt to guess valid tokens on this
              endpoint by making revocation requests against potential
              token strings. According to this specification, a client's
              request must contain a valid client_id, in the case of a
              public client, or valid client credentials, in the case of
              a confidential client. The token being revoked must also
              belong to the requesting client. If an attacker is able to
              successfully guess a public client's client_id and one of
              their tokens, or a private client's credentials and one of
              their tokens, they could do much worse damage by using the
              token elsewhere than by revoking it. If they chose to
              revoke the token, the legitimate client will lose its
              authorization and will need to prompt the user again. No
              further damage is done and the guessed token is now
              worthless." 

            
 

            

          

        

      

      

      Adopted your text.

      

      best regards,

      Torsten.

      

        

          

            
 

            
 References:

            
            
 

            

            

              

                
-- 

                

                  
Amanda Anganes

                  
Info Sys Engineer, G061

                  
The MITRE Corporation

                  
781-271-3103

                  
                

              

            

          

        

        

        

        

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


      

      

    

    Thanks,

      

      --Amanda

    
  


--------------060506000501050707080202--

From bcampbell@pingidentity.com  Thu Dec 27 08:52:57 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F62B21F8A4A for ; Thu, 27 Dec 2012 08:52:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.835
X-Spam-Level: 
X-Spam-Status: No, score=-4.835 tagged_above=-999 required=5 tests=[AWL=1.141,  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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH1BkOD6xv0j for ; Thu, 27 Dec 2012 08:52:56 -0800 (PST)
Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5748B21F88EA for ; Thu, 27 Dec 2012 08:52:56 -0800 (PST)
Received: from mail-ia0-f200.google.com ([209.85.210.200]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKUNx855IunEVQBK4fKkhb5809a4VrqScX@postini.com; Thu, 27 Dec 2012 08:52:56 PST
Received: by mail-ia0-f200.google.com with SMTP id f6so28376574iag.7 for ; Thu, 27 Dec 2012 08:52:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=vaVRoJZt/aFBctnmszfvtlIy+8gPHuKzovjcRycN138=; b=b7uIl5vUsFDTaMUmarhX3EdexquOM/Hz1MDSxCamjxSkgqHbsdLO3gQpZi/Hc+Ul9F rCPCjhLGiHnJVdCB5DtNBccZ23q1LsjqTf2zAJjDXoHa29Mb+9PfllSiC9j1b93qpl6C R4D2JjcxTS+J+NMxGn0AK/7kLOCS9bonRCD1hPDix60G91m1sPoAQvcaQDa9maHKP6iu KgMAFnzZfZ303qZ8O9UhRENR8naZDMaHEjkYG9xkfbZ7DITNEAVXHakusYHW+FYG4KtY 6sqjD8KjXk/ZxNGVh8HyTTn6zdeFpD9FbZy3xYnkOWyq73lBOqRvTHyUqizy55HfLzYu YTpQ==
X-Received: by 10.50.53.196 with SMTP id d4mr22609098igp.88.1356627175543; Thu, 27 Dec 2012 08:52:55 -0800 (PST)
Received: by 10.50.53.196 with SMTP id d4mr22609087igp.88.1356627175433; Thu, 27 Dec 2012 08:52:55 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.17.134 with HTTP; Thu, 27 Dec 2012 08:52:25 -0800 (PST)
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>
From: Brian Campbell 
Date: Thu, 27 Dec 2012 09:52:25 -0700
Message-ID: 
To: Mike Jones 
Content-Type: multipart/alternative; boundary=f46d042fdeb2e2657004d1d8607a
X-Gm-Message-State: ALoCoQmq/Xie7cm5G6p82rwtR50WyfPQAOlf3wMMfiClmggC8+yvRiHDZ4kkTs4Tfmr18UZHBPvojum5fcjdCfwd5X6ITD1iWqUy6EN+/RQXeBWtb1070aSUg9dto+qbRjyBGMFcTZ/m
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 16:52:57 -0000

--f46d042fdeb2e2657004d1d8607a
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I agree that =93URI=94 should be changed to =93value=94 for audience in the
Assertions Spec (draft-ietf-oauth-assertions) as well as the JWT
incarnation of it (draft-ietf-oauth-jwt-bearer).  The SAML incarnation
(draft-ietf-oauth-saml2-bearer) should probably keep URI because that's how
the core SAML specification (saml-core-2.0-os) defines audience.


On Wed, Dec 26, 2012 at 6:43 PM, Mike Jones wr=
ote:

>  http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1cur=
rently says:
> ****
>
> ** **
>
>    Audience  A URI that identifies the party intended to process the****
>
>       assertion.  The audience SHOULD be the URL of the Token Endpoint***=
*
>
>       as defined in Section 3.2  of OAuth 2.0 [RFC6749 ].****
>
> ** **
>
> I think that =93URI=94 should be changed to =93value=94, since audience v=
alues in
> general need not be URIs.  In particular, in some contexts OAuth client_i=
d
> values are used as audience values, and they need not be URIs.  Also, SAM=
L
> allows multiple audiences (and indeed, the OAuth SAML profile is written =
in
> terms of =93an audience value=94 =96 not =93the audience value=94), and s=
o the
> generic Assertions spec should do likewise.****
>
> ** **
>
> Thus, I would propose changing the text above to the following:****
>
> ** **
>
>    Audience  A value that identifies the parties intended to process the*=
***
>
>       assertion.  An audience value SHOULD be the URL of the Token Endpoi=
nt****
>
>       as defined in Section 3.2  of OAuth 2.0 [RFC6749 ].****
>
>  ** **
>
>                                                             -- Mike****
>
> ** **
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>

--f46d042fdeb2e2657004d1d8607a
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


I agree that =93URI=94 should be changed to =93value=94 fo=
r audience in the Assertions Spec (draft-ietf-oauth-assertions) as well as =
the JWT incarnation of it (draft-ietf-oauth-jwt-bearer). =A0The SAML incarn=
ation (draft-ietf-oauth-saml2-bearer) should probably keep URI because that=
's how the core SAML specification (saml-core-2.0-os) defines audience.=






On Wed, Dec 2=
6, 2012 at 6:43 PM, Mike Jones <Michael.Jones@microsoft.com&=
gt; wrote:














http://tools.ietf.org/html/draft-iet=
f-oauth-assertions-08#section-5.1 currently says:


=A0


=A0=A0 Audience=A0 A URI th=
at identifies the party intended to process the


=A0=A0=A0=A0=A0 assertion.=
=A0 The audience SHOULD be the URL of the Token Endpoint


=A0=A0=A0=A0=A0 as defined =
in Section 3.2 of OAuth 2.0 [RFC6749].




=A0

I think that =93URI=94 should be changed to =93value=94, sinc=
e audience values in general need not be URIs.=A0 In particular, in some co=
ntexts OAuth client_id values are used as audience values, and they need no=
t be URIs.=A0 Also, SAML allows multiple
 audiences (and indeed, the OAuth SAML profile is written in terms of =93an=
 audience value=94 =96 not =93the audience value=94), and so the generic As=
sertions spec should do likewise.


=A0


Thus, I would propose changing the text above to the followin=
g:


=A0


=A0=A0 Audience=A0 A value =
that identifies the parties intended to process the

=A0=A0=A0=A0=A0 assertion.=
=A0 An audience value SHOULD be the URL of the Token Endpoint=



=A0=A0=A0=A0=A0 as defined =
in Section 3.2 of OAuth 2.0 [RFC6749].




=A0


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=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







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





--f46d042fdeb2e2657004d1d8607a--

From torsten@lodderstedt.net  Thu Dec 27 10:03:05 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC7521F8D69 for ; Thu, 27 Dec 2012 10:03:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.149
X-Spam-Level: 
X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.100,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFO23PQfforf for ; Thu, 27 Dec 2012 10:03:04 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.25]) by ietfa.amsl.com (Postfix) with ESMTP id ACC2D21F8D67 for ; Thu, 27 Dec 2012 10:03:03 -0800 (PST)
Received: from [79.253.52.158] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1ToHnJ-0006Q7-G8; Thu, 27 Dec 2012 19:03:01 +0100
Message-ID: <50DC8D52.6020404@lodderstedt.net>
Date: Thu, 27 Dec 2012 19:02:58 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Sergey Beryozkin 
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net> <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com> <50DB2269.6020501@lodderstedt.net> <50DC17C4.6040300@gmail.com>
In-Reply-To: <50DC17C4.6040300@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 18:03:05 -0000

>>
>> Depending on the authorization server's revocation policy, the
>> revocation of a particular token may cause the revocation of related
>> tokens and the underlying authorization.
>> If the particular token is a refresh token and the authorization server
>> supports the revocation of access tokens, then the authorization server
>> SHOULD also invalidate all access tokens based on the same authorization
>> (seeImplementation Note <#impl>).
>>
>
> This implies that some ASs may, in theory at least, allow the client 
> to revoke the token but keep that specific client's authorization...

yep, it does. If this makes sense from the ASs perspective.

regards,
Torsten.

>
> Cheers, Sergey
>
>> Thoughts?
>>
>> regards,
>> Torsten.
>>
>> Am 26.12.2012 15:38, schrieb John Bradley:
>>> We don't want to share grant information across multiple instances 
>>> of public client.
>>>
>>> However we don't necessarily want to preclude multiple instances of 
>>> a private client,  Though how the AS would tell them apart is a 
>>> interesting side question.
>>>
>>>  From a revocation point of view if you revoke the grant for one 
>>> instance of a client you revoke it for all, though for a public 
>>> client the grant is not doing anything anyway as the AS shield not 
>>> be pre approving based on the grant.
>>>
>>> There are still some open questions about an extension to identify 
>>> client instances, though personally I prefer to have each instance 
>>> with it's own client ID.
>>>
>>> The language around grants has always been a bit philosophical for 
>>> my taste.
>>>
>>> If I recall correctly in the code flow the code is the 
>>> representation of the grant.  In  the implicit flow the grant is 
>>> implicit in the access token.
>>> What construct (if any in the implicit case) is stored in the AS to 
>>> represent this is mostly left to the imagination of the implementer.
>>>
>>> John B.
>>>
>>>
>>> On 2012-12-25, at 8:24 AM, Torsten 
>>> Lodderstedt  wrote:
>>>
>>>> Hi Mark,
>>>>
>>>> thanks for reviewing the draft. Comments inline.
>>>>
>>>> Am 02.12.2012 18:27, schrieb Mark Wubben:
>>>>> The draft relies heavily on the definition "access grant", but no 
>>>>> definition is provided in the draft or RFC 6749. It's been my 
>>>>> interpretation that an "access grant" is the *fact* that a 
>>>>> resource owner has authorized a client (potentially scoped) access 
>>>>> to the protected resources. Once access is granted in this manner, 
>>>>> further access tokens may be obtained without explicit permission 
>>>>> by the end-user. That is, in the Protocol Flow there is no user 
>>>>> input between steps A and B.
>>>> That's correct.
>>>>
>>>>> In "1. Introduction" it is stated:
>>>>>
>>>>>>   A
>>>>>>     revocation request will invalidate the actual token and, if
>>>>>>     applicable, other tokens based on the same access grant and the
>>>>>>     access grant itself.
>>>>> then, in "2. Token Revocation":
>>>>>
>>>>>>   In the next step, the authorization server invalidates the 
>>>>>> token and
>>>>>>     the respective access grant.  If the particular token is a 
>>>>>> refresh
>>>>>>     token and the authorization server supports the revocation of 
>>>>>> access
>>>>>>     tokens, then the authorization server SHOULD also invalidate all
>>>>>>     access tokens based on the same access grant
>>>>> This implies that an access grant only applies to an app 
>>>>> authorized on a single device. If an app is installed on multiple 
>>>>> devices and the access grant is shared between both instances, 
>>>>> revoking device A's access token results in the unexpected 
>>>>> revocation of device B's token.
>>>> You raised an interesting point. Is it desirable to share an access 
>>>> grant among different client instances? I would like to discuss 
>>>> this topic in the working group.
>>>>
>>>> If we assume it is desirable, how would the authorization process 
>>>> look alike?
>>>>
>>>> I would assume that as result of the authorization process of the 
>>>> 1st client instance, the authorization server stores an access 
>>>> grant, which is identified by the client_id and the user_id of the 
>>>> resource owner. Moreover, it creates a refresh token, which the 1st 
>>>> client instance uses to obtain new access tokens. As this client is 
>>>> public, the refresh token is the credential the intial client uses 
>>>> to prove its identity.
>>>>
>>>> How does the 2nd client instance join the party? I would assume the 
>>>> 2nd client to initiate another code grant type flow (using the same 
>>>> client_id as the 1st client). I see two ways the authorization 
>>>> server could process this process:
>>>>
>>>> 1) After authenticating the resource owner, the authorization 
>>>> server finds the existing access grant for the client_id/user_id 
>>>> combination and automatically issues tokens w/o further user 
>>>> consent. Since the authorization server cannot authenticate the 
>>>> client_id, a malicious client could obtain and abuse the access 
>>>> grant of the legitimate client. That's why the security 
>>>> considerations of the core spec 
>>>> (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) 
>>>> state:
>>>>
>>>> The authorization server SHOULD NOT process repeated authorization
>>>>    requests automatically (without active resource owner interaction)
>>>>    without authenticating the client or relying on other measures to
>>>>    ensure the repeated request comes from the original client and 
>>>> not an
>>>>    impersonator.
>>>>
>>>> Validating the redirect URI won't help that much, since this URI is 
>>>> typically device local (custom scheme or localhost).
>>>>
>>>> 2) The authorization server asks the resource owner for user 
>>>> consent and issues another pair of access/refresh token to the 2nd 
>>>> client. In this case, why would one bind this tokens to the already 
>>>> existing access grant? This would limit the resource owners 
>>>> capability to revoke grants for particular instances. I would 
>>>> rather create another access grant.
>>>>
>>>> Based on this thoughts I think it is not desirable to share an 
>>>> access grant among different client instances.
>>>>
>>>> What do others think?
>>>>
>>>>> If "access grant" could be defined as "an authorization issued to 
>>>>> the  client, based on the single use of an Authorization Grant" it 
>>>>> becomes clear than only the tokens spawning from the app's 
>>>>> authorization on device A should be revoked.
>>>> I would like to adopt your proposal if the WG agrees.
>>>>
>>>>> ---
>>>>>
>>>>> I spotted a typo in "3. Implementation Note":
>>>> Thanks. Fixed.
>>>>
>>>> regards,
>>>> Torsten.
>>>>>> Whether this is an viable option or
>>>>>>     whether access token revocation is required should be decided 
>>>>>> based
>>>>>>     on the service provider's risk analysis.
>>>>> "an viable option" should be "a viable option".
>>>>>
>>>>> On 24 Nov 2012, at 18:13, Hannes 
>>>>> Tschofenig  wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> this is a working group last call for 
>>>>>> draft-ietf-oauth-revocation-03 on "Token Revocation". The draft 
>>>>>> is available here:
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>>>>>>
>>>>>> Please send you comments to the OAuth mailing list by December 
>>>>>> 10, 2012.
>>>>>>
>>>>>> Thanks,
>>>>>> Hannes&  Derek
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> -- 
>>>>> Mark Wubben
>>>>>
>>>>> http://novemberborn.net
>>>>> http://twitter.com/novemberborn
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From torsten@lodderstedt.net  Thu Dec 27 10:13:45 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C889421F8D71 for ; Thu, 27 Dec 2012 10:13:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.161
X-Spam-Level: 
X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DnbxLfzEeeq for ; Thu, 27 Dec 2012 10:13:44 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id 444C621F8D6A for ; Thu, 27 Dec 2012 10:13:44 -0800 (PST)
Received: from [79.253.52.158] (helo=[192.168.71.42]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1ToHxe-0006XZ-FT; Thu, 27 Dec 2012 19:13:42 +0100
Message-ID: <50DC8FD3.4020708@lodderstedt.net>
Date: Thu, 27 Dec 2012 19:13:39 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Sergey Beryozkin 
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net> <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com> <50DB2269.6020501@lodderstedt.net> <50DC17C4.6040300@gmail.com> <50DC3481.7070808@gmail.com>
In-Reply-To: <50DC3481.7070808@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 18:13:45 -0000

Am 27.12.2012 12:44, schrieb Sergey Beryozkin:
> Hi again,
> On 27/12/12 09:41, Sergey Beryozkin wrote:
>> Hi
>> On 26/12/12 16:14, Torsten Lodderstedt wrote:
>>> Hi John,
>>>
>>> thanks for your feedback.
>>>
>>> After having thought through this topic again I came to the conclusion
>>> that I want to have a simple spec, which doesn't unnessarily restricts
>>> implementations. OAuth leaves so much freedom to implementors (for good
>>> reasons), which we should preserve.
>>>
>>> What does this mean? I would like to focus on the revocation of the
>>> token actually passed to the revocation endpoint and leave the 
>>> impact on
>>> other related tokens and the authorization itself to the authorization
>>> server's policy. The authorization server may incorporate the client
>>> type into its revocation policy.
>>>
>>> My base assumption is that a client must be prepared to handle
>>> invalidation of tokens at any time. So from an interoperability
>>> perspective, it's not necessary to dictate a certain revocation policy
>>> to authorization servers.
>>>
>>> Current text:
>>>
>>> In the next step, the authorization server invalidates the token and 
>>> the
>>> respective authorization. If the particular token is a refresh token 
>>> and
>>> the authorization server supports the revocation of access tokens, then
>>> the authorization server SHOULD also invalidate all access tokens based
>>> on the same authorization (seeImplementation Note <#impl>).
>>>
>>> The client MUST NOT use the token again after revocation.
>>>
>>> Proposal:
>>>
>>> In the next step, the authorization server invalidates the token. The
>>> client MUST NOT use this token again after revocation.
>>>
>>> Depending on the authorization server's revocation policy, the
>>> revocation of a particular token may cause the revocation of related
>>> tokens and the underlying authorization.
>>> If the particular token is a refresh token and the authorization server
>>> supports the revocation of access tokens, then the authorization server
>>> SHOULD also invalidate all access tokens based on the same 
>>> authorization
>>> (seeImplementation Note <#impl>).
>>>
>>
>> This implies that some ASs may, in theory at least, allow the client to
>> revoke the token but keep that specific client's authorization...
>
> Perhaps, having an optional token type parameter (as discussed in the 
> different thread) will make the proposed update more interesting, for 
> example, it can be the policy of a given AS to revoke a related access 
> token if the client requests the revocation of the refresh token only, 
> this can be documented and the client can thus avoid issuing a 2nd 
> revocation request

How do you imagine the token type parameter to determine the 
authorization servers revocation policy?

regards,
Torsten,
>
> Sorry if it all misses the point :-)
>
> thanks, Sergey
>
>>
>> Cheers, Sergey
>>
>>> Thoughts?
>>>
>>> regards,
>>> Torsten.
>>>
>>> Am 26.12.2012 15:38, schrieb John Bradley:
>>>> We don't want to share grant information across multiple instances of
>>>> public client.
>>>>
>>>> However we don't necessarily want to preclude multiple instances of a
>>>> private client, Though how the AS would tell them apart is a
>>>> interesting side question.
>>>>
>>>> From a revocation point of view if you revoke the grant for one
>>>> instance of a client you revoke it for all, though for a public
>>>> client the grant is not doing anything anyway as the AS shield not be
>>>> pre approving based on the grant.
>>>>
>>>> There are still some open questions about an extension to identify
>>>> client instances, though personally I prefer to have each instance
>>>> with it's own client ID.
>>>>
>>>> The language around grants has always been a bit philosophical for my
>>>> taste.
>>>>
>>>> If I recall correctly in the code flow the code is the representation
>>>> of the grant. In the implicit flow the grant is implicit in the
>>>> access token.
>>>> What construct (if any in the implicit case) is stored in the AS to
>>>> represent this is mostly left to the imagination of the implementer.
>>>>
>>>> John B.
>>>>
>>>>
>>>> On 2012-12-25, at 8:24 AM, Torsten
>>>> Lodderstedt wrote:
>>>>
>>>>> Hi Mark,
>>>>>
>>>>> thanks for reviewing the draft. Comments inline.
>>>>>
>>>>> Am 02.12.2012 18:27, schrieb Mark Wubben:
>>>>>> The draft relies heavily on the definition "access grant", but no
>>>>>> definition is provided in the draft or RFC 6749. It's been my
>>>>>> interpretation that an "access grant" is the *fact* that a resource
>>>>>> owner has authorized a client (potentially scoped) access to the
>>>>>> protected resources. Once access is granted in this manner, further
>>>>>> access tokens may be obtained without explicit permission by the
>>>>>> end-user. That is, in the Protocol Flow there is no user input
>>>>>> between steps A and B.
>>>>> That's correct.
>>>>>
>>>>>> In "1. Introduction" it is stated:
>>>>>>
>>>>>>> A
>>>>>>> revocation request will invalidate the actual token and, if
>>>>>>> applicable, other tokens based on the same access grant and the
>>>>>>> access grant itself.
>>>>>> then, in "2. Token Revocation":
>>>>>>
>>>>>>> In the next step, the authorization server invalidates the token 
>>>>>>> and
>>>>>>> the respective access grant. If the particular token is a refresh
>>>>>>> token and the authorization server supports the revocation of 
>>>>>>> access
>>>>>>> tokens, then the authorization server SHOULD also invalidate all
>>>>>>> access tokens based on the same access grant
>>>>>> This implies that an access grant only applies to an app authorized
>>>>>> on a single device. If an app is installed on multiple devices and
>>>>>> the access grant is shared between both instances, revoking device
>>>>>> A's access token results in the unexpected revocation of device B's
>>>>>> token.
>>>>> You raised an interesting point. Is it desirable to share an access
>>>>> grant among different client instances? I would like to discuss this
>>>>> topic in the working group.
>>>>>
>>>>> If we assume it is desirable, how would the authorization process
>>>>> look alike?
>>>>>
>>>>> I would assume that as result of the authorization process of the
>>>>> 1st client instance, the authorization server stores an access
>>>>> grant, which is identified by the client_id and the user_id of the
>>>>> resource owner. Moreover, it creates a refresh token, which the 1st
>>>>> client instance uses to obtain new access tokens. As this client is
>>>>> public, the refresh token is the credential the intial client uses
>>>>> to prove its identity.
>>>>>
>>>>> How does the 2nd client instance join the party? I would assume the
>>>>> 2nd client to initiate another code grant type flow (using the same
>>>>> client_id as the 1st client). I see two ways the authorization
>>>>> server could process this process:
>>>>>
>>>>> 1) After authenticating the resource owner, the authorization server
>>>>> finds the existing access grant for the client_id/user_id
>>>>> combination and automatically issues tokens w/o further user
>>>>> consent. Since the authorization server cannot authenticate the
>>>>> client_id, a malicious client could obtain and abuse the access
>>>>> grant of the legitimate client. That's why the security
>>>>> considerations of the core spec
>>>>> (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) 
>>>>> state:
>>>>>
>>>>> The authorization server SHOULD NOT process repeated authorization
>>>>> requests automatically (without active resource owner interaction)
>>>>> without authenticating the client or relying on other measures to
>>>>> ensure the repeated request comes from the original client and not an
>>>>> impersonator.
>>>>>
>>>>> Validating the redirect URI won't help that much, since this URI is
>>>>> typically device local (custom scheme or localhost).
>>>>>
>>>>> 2) The authorization server asks the resource owner for user consent
>>>>> and issues another pair of access/refresh token to the 2nd client.
>>>>> In this case, why would one bind this tokens to the already existing
>>>>> access grant? This would limit the resource owners capability to
>>>>> revoke grants for particular instances. I would rather create
>>>>> another access grant.
>>>>>
>>>>> Based on this thoughts I think it is not desirable to share an
>>>>> access grant among different client instances.
>>>>>
>>>>> What do others think?
>>>>>
>>>>>> If "access grant" could be defined as "an authorization issued to
>>>>>> the client, based on the single use of an Authorization Grant" it
>>>>>> becomes clear than only the tokens spawning from the app's
>>>>>> authorization on device A should be revoked.
>>>>> I would like to adopt your proposal if the WG agrees.
>>>>>
>>>>>> ---
>>>>>>
>>>>>> I spotted a typo in "3. Implementation Note":
>>>>> Thanks. Fixed.
>>>>>
>>>>> regards,
>>>>> Torsten.
>>>>>>> Whether this is an viable option or
>>>>>>> whether access token revocation is required should be decided based
>>>>>>> on the service provider's risk analysis.
>>>>>> "an viable option" should be "a viable option".
>>>>>>
>>>>>> On 24 Nov 2012, at 18:13, Hannes
>>>>>> Tschofenig wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> this is a working group last call for
>>>>>>> draft-ietf-oauth-revocation-03 on "Token Revocation". The draft is
>>>>>>> available here:
>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>>>>>>>
>>>>>>> Please send you comments to the OAuth mailing list by December 10,
>>>>>>> 2012.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Hannes& Derek
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> -- 
>>>>>> Mark Wubben
>>>>>>
>>>>>> http://novemberborn.net
>>>>>> http://twitter.com/novemberborn
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From torsten@lodderstedt.net  Thu Dec 27 10:22:39 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DEE21F8D6A for ; Thu, 27 Dec 2012 10:22:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.171
X-Spam-Level: 
X-Spam-Status: No, score=-2.171 tagged_above=-999 required=5 tests=[AWL=0.078,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eI+jdqxoF++R for ; Thu, 27 Dec 2012 10:22:39 -0800 (PST)
Received: from smtprelay05.ispgateway.de (smtprelay05.ispgateway.de [80.67.31.97]) by ietfa.amsl.com (Postfix) with ESMTP id B512321F8D60 for ; Thu, 27 Dec 2012 10:22:38 -0800 (PST)
Received: from [79.253.52.158] (helo=[192.168.71.42]) by smtprelay05.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1ToI6H-0006RV-8A; Thu, 27 Dec 2012 19:22:37 +0100
Message-ID: <50DC91E8.4010009@lodderstedt.net>
Date: Thu, 27 Dec 2012 19:22:32 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Sergey Beryozkin 
References:  <50BCC54D.5060609@mitre.org> <50D99EF8.80308@lodderstedt.net> <50DC1B9C.1020505@gmail.com>
In-Reply-To: <50DC1B9C.1020505@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 18:22:40 -0000

Am 27.12.2012 10:57, schrieb Sergey Beryozkin:
> sHi
> On 25/12/12 12:41, Torsten Lodderstedt wrote:
>> Hi all,
>>
>> any other opinion regarding having or not having a token type parameter?
>>
>> I would like to go with #1 as it is rather late in the process to
>> (re-)introduce a mandatory parameter. And making it an optional
>> parameter (#4) seems not really useful to me.
>>
> ce
> +1 to #4 - it might help optimizing the lookups. Example, refresh and 
> access token keys may be kept in different tables, so ideally revoking 
> a refresh token only would involve a definite lookup to the refresh 
> token table/etc only, same for access tokens.
>
> Having said this, the optional parameter can probably be added later.
>
> However, it made me think, should the client be able to say, "I'd like 
> to revoke this refresh token and the access token linked to this 
> refresh token", in other words, should the client be given an option 
> to optimize the revocation process ? Probably can be reviewed later too

Hi Sergey,

ok, got you. Thanks for the proposal. I agree with your assessment that 
this can be added later. In my opinion, we generally need more 
real-world implementation experience in order to optimize the protocol. 
For the time being, I would like to have basic revocation support.

regards,
Torsten.

>
> thanks, Sergey
>
>> regards,
>> Torsten.
>>> The way I see it, we've got a few options:
>>>
>>> 1) Leave it as-is, with no field. Client/RS/whoever just sends the
>>> token over and it's the AS's problem.
>>> 2) Define a required field with "access" and "refresh" value
>>> semantics, and state that other values MAY be accepted by a given AS,
>>> or defined by extension protocols. These extension values MUST be
>>> fully qualified URIs.
>>> 3) Same as #2, but with IANA registry to allow for non-collision of
>>> short names.
>>> 4) Define an optional field that the client MAY send as a hint to the
>>> AS, and it's up to the AS to figure out if it makes any sense in the
>>> context of the request. All bets are off as to the content of this
>>> field, other than "it's a string".
>>>
>>> There may be other approaches as well.
>>>
>>> -- Justin
>>>
>>> On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:
>>>> Here is my review of the Toke Revocation draft
>>>> (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>>>>
>>>> Section 1. Introduction
>>>> First paragraph has the following definition in it: "A token is the
>>>> external representation of an access grant issued by a resource owner
>>>> to a particular client." This seems a bit odd to me. The OAuth2 spec
>>>> [1] defines "access token" as "An access token is a string
>>>> representing an authorization issued to the client." (section 1.4)
>>>> and "refresh token" as "credentials used to obtain access tokens
>>>> (section 1.5). Should this spec borrow similar language to be more
>>>> consistent?
>>>>
>>>> Paragraph 2 "From an end-user's perception" should be "From an
>>>> end-user's perspective".
>>>>
>>>> Section 2. Token Revocation
>>>> What is the reason for requiring the service provider to detect the
>>>> token type automatically? For our implementation, Access Tokens,
>>>> Refresh Tokens, and ID Tokens are all structured tokens (with unique
>>>> structures across the three types), and as such are stored in 3
>>>> separate database tables. In order to "detect" the token type, we
>>>> would need to run a get-by-value query across all three tables, check
>>>> if any of those queries returned anything, and then proceed to revoke
>>>> the token (if one was found). This does not seem ideal to me.
>>>>
>>>> The spec says that "The authorization server first validates the
>>>> client credentials (in case of a confidential client) and verifies
>>>> whether the client is authorized to revoke the particular token."
>>>> What does this verification entail? Does it just mean that 1) the
>>>> client credentials must validate and 2) the token must belong to the
>>>> client requesting the revocation? If so I think the text should be
>>>> clarified to reflect that. Or are you thinking of a case where a
>>>> client might not be allowed to revoke its own tokens, via some kind
>>>> of scoping?
>>>>
>>>> 2.1 Cross Origin Support
>>>> Formatting looks a little off here, otherwise this section looks fine.
>>>>
>>>> 5. Security Considerations
>>>> Paragraph 3 (Malicious clients): "Appropriate countermeasures, which
>>>> should be in place for the token endpoint as well, MUST be applied to
>>>> the revocation endpoint." These countermeasures should be referenced
>>>> to the proper section(s) of the OAuth core spec or Threat Model
>>>> document.
>>>>
>>>> Paragraph 4 reads a bit oddly. Suggest following rewording:
>>>> "A malicious client may attempt to guess valid tokens on this
>>>> endpoint by making revocation requests against potential token
>>>> strings. According to this specification, a client's request must
>>>> contain a valid client_id, in the case of a public client, or valid
>>>> client credentials, in the case of a confidential client. The token
>>>> being revoked must also belong to the requesting client. If an
>>>> attacker is able to successfully guess a public client's client_id
>>>> and one of their tokens, or a private client's credentials and one of
>>>> their tokens, they could do much worse damage by using the token
>>>> elsewhere than by revoking it. If they chose to revoke the token, the
>>>> legitimate client will lose its authorization and will need to prompt
>>>> the user again. No further damage is done and the guessed token is
>>>> now worthless."
>>>>
>>>> References:
>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>>>>
>>>> -- 
>>>> Amanda Anganes
>>>> Info Sys Engineer, G061
>>>> The MITRE Corporation
>>>> 781-271-3103
>>>> aanganes@mitre.org
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From torsten@lodderstedt.net  Thu Dec 27 10:28:49 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCC721F8D6E for ; Thu, 27 Dec 2012 10:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Level: 
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.070,  BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVZtyVKRqkp9 for ; Thu, 27 Dec 2012 10:28:47 -0800 (PST)
Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.31.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8958C21F8D6C for ; Thu, 27 Dec 2012 10:28:46 -0800 (PST)
Received: from [79.253.52.158] (helo=[192.168.71.42]) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1ToICC-0005dj-4H; Thu, 27 Dec 2012 19:28:44 +0100
Message-ID: <50DC9359.7010603@lodderstedt.net>
Date: Thu, 27 Dec 2012 19:28:41 +0100
From: Torsten Lodderstedt 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Amanda Anganes 
References:  <50D9A5E9.20205@lodderstedt.net> <50DC59AC.7090200@mitre.org>
In-Reply-To: <50DC59AC.7090200@mitre.org>
Content-Type: multipart/alternative; boundary="------------090004090609000202080607"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 18:28:49 -0000

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

Hi Amanda,

I incoporated your comments. I'm waiting for feedback on the other 
threads before I will post another revision.

http://www.ietf.org/mail-archive/web/oauth/current/msg10334.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10331.html
http://www.ietf.org/mail-archive/web/oauth/current/msg10335.html

best regards,
Torsten.

Am 27.12.2012 15:22, schrieb Amanda Anganes:
> Hi Torsten,
>
> Responses inline in blue.
>
> On 12/25/2012 08:11 AM, Torsten Lodderstedt wrote:
>> Hi Amanda,
>>
>> thank you for reviewing the draft. Comments inline.
>>
>> Am 30.11.2012 22:28, schrieb Anganes, Amanda L:
>>> Here is my review of the Toke Revocation draft 
>>> (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>>>
>>> Section 1. Introduction
>>> First paragraph has the following definition in it: "A token is the 
>>> external representation of an access grant issued by a resource 
>>> owner to a particular client." This seems a bit odd to me. The 
>>> OAuth2 spec [1] defines "access token" as "An access token is a 
>>> string representing an authorization issued to the client." (section 
>>> 1.4) and "refresh token" as "credentials used to obtain access 
>>> tokens (section 1.5). Should this spec borrow similar language to be 
>>> more consistent?
>>>
>>
>> What about this:
>>
>> "A token is a string representing an authorization issued by the 
>> resource owner to the client. A revocation request will invalidate 
>> the actual token and, if applicable, other tokens based on the same 
>> authorization and the authorization itself."
>>
> Yes, that sounds more consistent.
>>
>>> Paragraph 2 "From an end-user's perception" should be "From an 
>>> end-user's perspective".
>>
>> changed it.
>>
>>>
>>> Section 2. Token Revocation
>>> What is the reason for requiring the service provider to detect the 
>>> token type automatically? For our implementation, Access Tokens, 
>>> Refresh Tokens, and ID Tokens are all structured tokens (with unique 
>>> structures across the three types), and as such are stored in 3 
>>> separate database tables. In order to "detect" the token type, we 
>>> would need to run a get-by-value query across all three tables, 
>>> check if any of those queries returned anything, and then proceed to 
>>> revoke the token (if one was found). This does not seem ideal to me.
>>
>> As pointed out by Justin, there was such a parameter in an early 
>> revision of the draft. WG feedback caused me to remove it. I would 
>> like to stick with auto detection if not otherwise decided by the 
>> working group. I explicitely asked for feedback on the other thread.
>>
>>>
>>> The spec says that "The authorization server first validates the 
>>> client credentials (in case of a confidential client) and verifies 
>>> whether the client is authorized to revoke the particular token." 
>>> What does this verification entail? Does it just mean that 1) the 
>>> client credentials must validate and 2) the token must belong to the 
>>> client requesting the revocation? If so I think the text should be 
>>> clarified to reflect that. Or are you thinking of a case where a 
>>> client might not be allowed to revoke its own tokens, via some kind 
>>> of scoping?
>>
>> It's 1+2
>>
>> What about this text
>>
>> "The authorization server first validates the client credentials (in 
>> case of a confidential client) and then verifies whether the client 
>> is authorized to revoke the token. A client may only revoke a token 
>> if the validation of the client identity succeeds and the particular 
>> token had been issued to this client."
>>
> The confusing phrase here is "authorized to revoke the token". If a 
> client just needs to be the owner of the token in order to revoke it, 
> I would say that:
>
> "The authorization server first validates the client credentials (in 
> case of a confidential client) and then verifies whether the token was 
> issued to the client making the revocation request."
>
> Otherwise, the "authorized to revoke the token" language sounds like 
> there might be some way to *give* authorization to a particular 
> client, as opposed to authorization simply requiring authentication 
> and ownership.
>>>
>>> 2.1 Cross Origin Support
>>> Formatting looks a little off here, otherwise this section looks fine.
>>
>> What specifically to you mean?
> The indentation looks strange. Should the example request, successful 
> response, and error response be indented? The example request in the 
> previous section is indented. Also, should the definition of the 
> "callback" parameter say "OPTIONAL." before the definition, or is that 
> redundant because the paragraph before indicates "MAY support"? I am 
> not sure of the IETF standards for these things; the section just 
> didn't look quite right to me.
>>
>>>
>>> 5. Security Considerations
>>> Paragraph 3 (Malicious clients...): "Appropriate countermeasures, 
>>> which should be in place for the token endpoint as well, MUST be 
>>> applied to the revocation endpoint." These countermeasures should be 
>>> referenced to the proper section(s) of the OAuth core spec or Threat 
>>> Model document.
>>
>> Added reference to section 4.4.1.11 of threat model documemt
>>
>>>
>>> Paragraph 4 reads a bit oddly. Suggest following rewording:
>>> "A malicious client may attempt to guess valid tokens on this 
>>> endpoint by making revocation requests against potential token 
>>> strings. According to this specification, a client's request must 
>>> contain a valid client_id, in the case of a public client, or valid 
>>> client credentials, in the case of a confidential client. The token 
>>> being revoked must also belong to the requesting client. If an 
>>> attacker is able to successfully guess a public client's client_id 
>>> and one of their tokens, or a private client's credentials and one 
>>> of their tokens, they could do much worse damage by using the token 
>>> elsewhere than by revoking it. If they chose to revoke the token, 
>>> the legitimate client will lose its authorization and will need to 
>>> prompt the user again. No further damage is done and the guessed 
>>> token is now worthless."
>>>
>>
>> Adopted your text.
>>
>> best regards,
>> Torsten.
>>> References:
>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>>>
>>> -- 
>>> Amanda Anganes
>>> Info Sys Engineer, G061
>>> The MITRE Corporation
>>> 781-271-3103
>>> aanganes@mitre.org
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
> Thanks,
>
> --Amanda


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


  
    
  
  
    Hi Amanda,

    

    I incoporated your comments. I'm waiting for feedback on the other
    threads before I will post another revision. 

    

    http://www.ietf.org/mail-archive/web/oauth/current/msg10334.html

    http://www.ietf.org/mail-archive/web/oauth/current/msg10331.html

    http://www.ietf.org/mail-archive/web/oauth/current/msg10335.html

    

    best regards,

    Torsten.

    

    
Am 27.12.2012 15:22, schrieb Amanda
      Anganes:

    

    

      
      Hi Torsten,

        

        Responses inline in blue. 

      

      
On 12/25/2012 08:11 AM, Torsten
        Lodderstedt wrote:

      

      

        
        Hi Amanda,

        

        thank you for reviewing the draft. Comments inline.

        

        
Am 30.11.2012 22:28, schrieb
          Anganes, Amanda L:

        

        

          

            

              
 Here is my review
                of the Toke Revocation draft (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):

              
 

              

              
 Section 1.
                Introduction

              
First paragraph has the
                  following definition in it: "A token is the external
                  representation of an access grant

                  issued by a resource owner to a particular client."
                  This seems a bit odd to me. The
                  OAuth2 spec [1] defines "access token" as "An access token is a string
                  representing an authorization issued to the client." (section 1.4) and "refresh
                  token" as "credentials used to obtain access tokens
                  (section 1.5). Should this spec borrow similar
                  language to be more consistent?

              


                

            

          

        

        

        What about this:

        

        "A token is a string representing an authorization issued by the
        resource owner to the client. A revocation request will
        invalidate the actual token and, if applicable, other tokens
        based on the same authorization and the authorization itself."

        

      

      Yes, that sounds more consistent. 

      

        

        

          

            

              
 

              
Paragraph 2 "From an
                  end-user's perception" should be "From an end-user's
                  perspective".

            

          

        

        

        changed it.

        

        

          

            

              


                

              
Section 2. Token Revocation

              
What is the reason for
                  requiring the service provider to detect the token
                  type automatically? For our implementation, Access
                  Tokens, Refresh Tokens, and ID Tokens are all
                  structured tokens (with unique structures across the
                  three types), and as such are stored in 3 separate
                  database tables. In order to "detect" the token type,
                  we would need to run a get-by-value query across all
                  three tables, check if any of those queries returned
                  anything, and then proceed to revoke the token (if one
                  was found). This does not seem ideal to me.

            

          

        

        

        As pointed out by Justin, there was such a parameter in an early
        revision of the draft. WG feedback caused me to remove it. I
        would like to stick with auto detection if not otherwise decided
        by the working group. I explicitely asked for feedback on the
        other thread.  

        

        

          

            

              
 

              


                

              
The spec says that "The authorization server
                  first validates the client credentials (in case of a
                  confidential client) and verifies whether the client
                  is authorized to revoke the particular token." What
                  does this verification entail? Does it just mean that
                  1) the client credentials must validate and 2) the
                  token must belong to the client requesting the
                  revocation? If so I think the text should be clarified
                  to reflect that. Or are you thinking of a case where a
                  client might not be allowed to revoke its own tokens,
                  via some kind of scoping?

            

          

        

        

        It's 1+2

        

        What about this text

        

        "The authorization server first validates the client credentials
        (in case of a confidential client) and then verifies whether the
        client is authorized to revoke the token. A client may only
        revoke a token if the validation of the client identity succeeds
        and the particular token had been issued to this client."

        

      

      The confusing phrase here is "authorized to
        revoke the token". If a client just needs to be the owner of the
        token in order to revoke it, I would say that:

        

        "The authorization server first validates the client credentials
        (in case of a confidential client) and then verifies whether the
        token was issued to the client making the revocation request." 

        

        Otherwise, the "authorized to revoke the token" language sounds
        like there might be some way to *give* authorization to a
        particular client, as opposed to authorization simply requiring
        authentication and ownership. 

      

        

          

            

              
 

              


                

              
 2.1 Cross Origin
                Support

              
 Formatting looks a
                little off here, otherwise this section looks fine.

            

          

        

        

        What specifically to you mean?

      

      The indentation looks strange. Should the
        example request, successful response, and error response be
        indented? The example request in the previous section is
        indented. Also, should the definition of the "callback"
        parameter say "OPTIONAL." before the definition, or is that
        redundant because the paragraph before indicates "MAY support"?
        I am not sure of the IETF standards for these things; the
        section just didn't look quite right to me. 

      

        

        

          

            

              
 

              

              
 5. Security
                Considerations

              
 Paragraph 3
                (Malicious clients…): "Appropriate countermeasures,
                which should be in place for the token endpoint as well,
                MUST be applied to the revocation endpoint." These
                countermeasures should be referenced to the proper
                section(s) of the OAuth core spec or Threat Model
                document. 

              

            

          

        

        

        Added reference to section 4.4.1.11
          of threat model documemt

          

        
        

          

            

              
 

              

              
 Paragraph 4 reads a
                bit oddly. Suggest following rewording:

              
 "A

                malicious client may attempt to guess valid tokens on
                this endpoint by making revocation requests against
                potential token strings. According to this
                specification, a client's request must contain a valid
                client_id, in the case of a public client, or valid
                client credentials, in the case of a confidential
                client. The token being revoked must also belong to the
                requesting client. If an attacker is able to
                successfully guess a public client's client_id and one
                of their tokens, or a private client's credentials and
                one of their tokens, they could do much worse damage by
                using the token elsewhere than by revoking it. If they
                chose to revoke the token, the legitimate client will
                lose its authorization and will need to prompt the user
                again. No further damage is done and the guessed token
                is now worthless." 

              
 

              

            

          

        

        

        Adopted your text.

        

        best regards,

        Torsten.

        

          

            

              
 

              
 References:

              
              
 

              

              

                

                  
-- 

                  

                    
Amanda Anganes

                    
Info Sys Engineer, G061

                    
The MITRE Corporation

                    
781-271-3103

                    
                  

                

              

            

          

          

          

          

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


        

        

      

      Thanks,

        

        --Amanda

       

    

  


--------------090004090609000202080607--

From hardjono@mit.edu  Thu Dec 27 11:25:00 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F1621F8C6F for ; Thu, 27 Dec 2012 11:25:00 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LO91ay+nNF4P for ; Thu, 27 Dec 2012 11:24:59 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8022121F8B38 for ; Thu, 27 Dec 2012 11:24:59 -0800 (PST)
X-AuditID: 12074425-b7ff26d000007f8d-b4-50dca08a1779
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 8F.40.32653.A80ACD05; Thu, 27 Dec 2012 14:24:58 -0500 (EST)
Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id qBRJOwL1001926;  Thu, 27 Dec 2012 14:24:58 -0500
Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id qBRJOqkr025581; Thu, 27 Dec 2012 14:24:57 -0500
Received: from OC11EXHUB10.exchange.mit.edu (18.9.3.24) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 27 Dec 2012 14:24:06 -0500
Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.103]) by OC11EXHUB10.exchange.mit.edu ([18.9.3.24]) with mapi id 14.02.0309.002; Thu, 27 Dec 2012 14:24:36 -0500
From: Thomas Hardjono 
To: "oauth@ietf.org" 
Thread-Topic: OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
Thread-Index: Ac3kZ80uYlMMo4p2TFO+SThlSNMWiA==
Date: Thu, 27 Dec 2012 19:24:35 +0000
Message-ID: <5E393DF26B791A428E5F003BB6C5342A10CCB1D7@OC11EXPO24.exchange.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [71.184.223.209]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGKsWRmVeSWpSXmKPExsUixG6notu14E6AwbnD+hZLd95jtTj59hWb xZlbKxgdmD12zrrL7rF40342jyVLfjIFMEdx2aSk5mSWpRbp2yVwZXx8/52x4IRAxZt7x1ka GCcIdDFycEgImEj8+azZxcgJZIpJXLi3ng3EFhLYxyhxvkG4i5ELyD7AKDFv6Xw2COcYo8Te BU+ZIJztjBKvvt9mhXBWM0rsb+8H62cT0JA493svO4gtIqAqse/oFXaQImaBHYwS15afYAVJ CAvUSjxcew5slIhAE6PE5HdTWCE69CQ62xcxgRzIAtT9ZKYwSJhXIEji1ITnYCWMQMd+P7WG CcRmFhCXuPVkPhPEE4ISi2bvYYZ56N+uh2wQtpLEo73nwEYyC2hKrN+lD9GqKDGl+yE7xHhB iZMzn7BMYBSfhWTqLISOWUg6ZiHpWMDIsopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0Qv NaV0EyM4+lxUdzBOOKR0iFGAg1GJh3dBz50AIdbEsuLK3EOMkhxMSqK8mnOAQnxJ+SmVGYnF GfFFpTmpxYcYJTiYlUR4v8cD5XhTEiurUovyYVLSHCxK4rw3Um76CwmkJ5akZqemFqQWwWRl ODiUJHgb5gM1ChalpqdWpGXmlCCkmTg4QYbzAA2fAVLDW1yQmFucmQ6RP8WoKCXOOxEkIQCS yCjNg+uFJcdXjOJArwjzFoBU8QATK1z3K6DBTECDrXnABpckIqSkGhgtOBhnXthfLMVUdkKL sWbHplTb248bD15bw9ni0/0gMsDKRDP+Qaq0mspGiVfOEW9PMS09ufGH46m9vyPZfdm5srh+ bP52t+wct8lD4Xc/7tX/++9Suyy8Ly7RMf3q6ZnBjgu2rVXgemV+xHDFCbdnWYF8b9ptJ7yM +LiHxUhXxH3WcTu9FDklluKMREMt5qLiRAAUzDpMaQMAAA==
Subject: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 19:25:00 -0000

Rm9sa3MsDQoNClRoZSBPQXV0aCAyLjAgUmVzb3VyY2UgU2V0IFJlZ2lzdHJhdGlvbiBkcmFmdCBp
cyBlc3NlbnRpYWxseSBhIGdlbmVyaWMgZmlyc3QgcGhhc2Ugb2YgdGhlIFVzZXIgTWFuYWdlZCBB
Y2Nlc3MgKFVNQSkgcHJvZmlsZSBvZiBPQXV0aDIuMC4gIFRoaXMgYWxsb3dzIHRoZSBSTyB0byAi
cmVnaXN0ZXIiIChtYWtlIGtub3duKSB0byB0aGUgQVMgdGhlIHJlc291cmNlcyBoZS9zaGUgd2lz
aGVzIHRvIHNoYXJlLg0KDQpMb29raW5nIGZvcndhcmQgdG8gY29tbWVudHMvZmVlZGJhY2suDQoN
Ci90aG9tYXMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBUaHVyc2RheSwg
RGVjZW1iZXIgMjcsIDIwMTIgMjowNyBQTQ0KVG86IFRob21hcyBIYXJkam9ubw0KU3ViamVjdDog
TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1oYXJkam9uby1vYXV0aC1yZXNvdXJj
ZS1yZWctMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWhhcmRqb25vLW9h
dXRoLXJlc291cmNlLXJlZy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQg
YnkgVGhvbWFzIEhhcmRqb25vIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0K
RmlsZW5hbWU6ICAgICAgICBkcmFmdC1oYXJkam9uby1vYXV0aC1yZXNvdXJjZS1yZWcNClJldmlz
aW9uOiAgICAgICAgMDANClRpdGxlOiAgICAgICAgICAgT0F1dGggMi4wIFJlc291cmNlIFNldCBS
ZWdpc3RyYXRpb24NCkNyZWF0aW9uIGRhdGU6ICAgMjAxMi0xMi0yNw0KV0cgSUQ6ICAgICAgICAg
ICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTkNClVSTDogICAgICAg
ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFyZGpvbm8t
b2F1dGgtcmVzb3VyY2UtcmVnLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWhhcmRqb25vLW9hdXRoLXJlc291cmNlLXJlZw0KSHRt
bGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYXJkam9uby1v
YXV0aC1yZXNvdXJjZS1yZWctMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlv
biBkZWZpbmVzIGEgcmVzb3VyY2Ugc2V0IHJlZ2lzdHJhdGlvbiBtZWNoYW5pc20NCiAgIGJldHdl
ZW4gYW4gT0F1dGggMi4wIGF1dGhvcml6YXRpb24gc2VydmVyIGFuZCByZXNvdXJjZSBzZXJ2ZXIu
ICBUaGUNCiAgIHJlc291cmNlIHNlcnZlciByZWdpc3RlcnMgaW5mb3JtYXRpb24gYWJvdXQgdGhl
IHNlbWFudGljcyBhbmQNCiAgIGRpc2NvdmVyeSBwcm9wZXJ0aWVzIG9mIGl0cyByZXNvdXJjZXMg
d2l0aCB0aGUgYXV0aG9yaXphdGlvbiBzZXJ2ZXIuDQoNCg0KDQoNClRoZSBJRVRGIFNlY3JldGFy
aWF0DQoNCg==

From aanganes@mitre.org  Thu Dec 27 13:57:25 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A8421F8CF0 for ; Thu, 27 Dec 2012 13:57:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FVDXpKailmN for ; Thu, 27 Dec 2012 13:57:24 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id AB41521F8CD7 for ; Thu, 27 Dec 2012 13:57:23 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B94D4390024; Thu, 27 Dec 2012 16:57:23 -0500 (EST)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DE5544350234; Thu, 27 Dec 2012 16:57:22 -0500 (EST)
Received: from IMCMBX04.MITRE.ORG ([169.254.4.200]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Thu, 27 Dec 2012 16:57:22 -0500
From: "Anganes, Amanda L" 
To: Thomas Hardjono , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
Thread-Index: Ac3kZ80uYlMMo4p2TFO+SThlSNMWiAAFVdwA
Date: Thu, 27 Dec 2012 21:57:21 +0000
Message-ID: 
In-Reply-To: <5E393DF26B791A428E5F003BB6C5342A10CCB1D7@OC11EXPO24.exchange.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.5.121010
x-originating-ip: [172.31.38.112]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <2BF61D826983D244A516E874DD55DB6C@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 21:57:25 -0000

Hi Thomas,

Here is some initial feedback.

Introduction paragraph 2:

Remove duplicate "with": "the OpenID Provider (OP) component is a
specialized version of an OAuth authorization server that brokers
availability of user attributes by dealing *with with* an ecosystem of
attribute providers (APs)."

Section 1.2 Terminology:

This is more of a comment for the UMA WG in general: "scope type" is an
unfortunate term (which appears in the UMA core draft [1] as well - if
memory serves the term used to be just "scope" but I couldn't find a diff
reference for when that changed). Including "type" in the term makes it
sound like it refers to a class or kind of scope, which doesn't seem to be
what you mean. I understand that "scope" cannot be used since it is
already reserved by OAuth, but perhaps a better synonym could be found and
used instead?=20

2. Resource set registration

2nd sentence reads oddly. Change from "For any of the resource owner's
sets of resources this authorization server needs to be aware of, the
resource server MUST register these resource sets=8A" to "If this
authorization server needs to be aware of any of the resource sets, the
resource server MUST register those resource sets=8A"

2.2 Resource set descriptions

"scopes" and to refer to sets of "scope type"s and "type" to refer to the
class/kind of resource set this is add to the argument above that "scope
type" is a misleading term.

2.3 Resource set registration API

I don't understand what this sentence means: "Without a specific resource
set identifier path component, the URI applies to the set of resource set
descriptions already registered." Can you clarify?

The {rsreguri} URI component is defined but never used. It looks like all
of the "/resource_set" URIs should be prefaced with this component
throughout the following sections?

[1] https://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/

--=20
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
781-271-3103
aanganes@mitre.org


On 12/27/12 2:24 PM, "Thomas Hardjono"  wrote:

>Folks,
>
>The OAuth 2.0 Resource Set Registration draft is essentially a generic
>first phase of the User Managed Access (UMA) profile of OAuth2.0.  This
>allows the RO to "register" (make known) to the AS the resources he/she
>wishes to share.
>
>Looking forward to comments/feedback.
>
>/thomas/
>
>__________________________________________
>
>
>-----Original Message-----
>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>Sent: Thursday, December 27, 2012 2:07 PM
>To: Thomas Hardjono
>Subject: New Version Notification for
>draft-hardjono-oauth-resource-reg-00.txt
>
>
>A new version of I-D, draft-hardjono-oauth-resource-reg-00.txt
>has been successfully submitted by Thomas Hardjono and posted to the IETF
>repository.
>
>Filename:        draft-hardjono-oauth-resource-reg
>Revision:        00
>Title:           OAuth 2.0 Resource Set Registration
>Creation date:   2012-12-27
>WG ID:           Individual Submission
>Number of pages: 19
>URL:            =20
>http://www.ietf.org/internet-drafts/draft-hardjono-oauth-resource-reg-00.t
>xt
>Status:         =20
>http://datatracker.ietf.org/doc/draft-hardjono-oauth-resource-reg
>Htmlized:       =20
>http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
>
>
>Abstract:
>   This specification defines a resource set registration mechanism
>   between an OAuth 2.0 authorization server and resource server.  The
>   resource server registers information about the semantics and
>   discovery properties of its resources with the authorization server.
>
>
>
>
>The IETF Secretariat
>
>_______________________________________________
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth


From tonynad@microsoft.com  Thu Dec 27 14:57:04 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165D721F8DC1 for ; Thu, 27 Dec 2012 14:57:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.367
X-Spam-Level: *
X-Spam-Status: No, score=1.367 tagged_above=-999 required=5 tests=[AWL=0.833,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhvfG8OkWJ+d for ; Thu, 27 Dec 2012 14:57:03 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id AF64721F8D5F for ; Thu, 27 Dec 2012 14:57:01 -0800 (PST)
Received: from BY2FFO11FD011.protection.gbl (10.1.15.203) by BY2FFO11HUB039.protection.gbl (10.1.14.122) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 27 Dec 2012 22:56:53 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 27 Dec 2012 22:56:52 +0000
Received: from va3outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 27 Dec 2012 22:56:29 +0000
Received: from mail25-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE007.bigfish.com (10.7.40.11) with Microsoft SMTP Server id 14.1.225.23; Thu, 27 Dec 2012 22:56:28 +0000
Received: from mail25-va3 (localhost [127.0.0.1])	by mail25-va3-R.bigfish.com (Postfix) with ESMTP id 7AFFF3C01C5	for ; Thu, 27 Dec 2012 22:56:28 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -17
X-BigFish: PS-17(zz9371Ic89bhd6eah1418Ic857hzz1de0h1202h1e76h1d1ah1d2ah1082kzz8275bh8275dh1033IL18c673h17326ahz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail25-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB041; LANG:en; 
Received: from mail25-va3 (localhost.localdomain [127.0.0.1]) by mail25-va3 (MessageSwitch) id 1356648986292486_14280; Thu, 27 Dec 2012 22:56:26 +0000 (UTC)
Received: from VA3EHSMHS042.bigfish.com (unknown [10.7.14.247])	by mail25-va3.bigfish.com (Postfix) with ESMTP id 3AA1F360085; Thu, 27 Dec 2012 22:56:26 +0000 (UTC)
Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS042.bigfish.com (10.7.99.52) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 27 Dec 2012 22:56:24 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 27 Dec 2012 22:56:24 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 27 Dec 2012 22:55:58 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Thu, 27 Dec 2012 22:55:58 +0000
From: Anthony Nadalin 
To: Torsten Lodderstedt , Mike Jones 
Thread-Topic: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
Thread-Index: AQHN5BorHF0tt5bL60KZvuNO0KVLYpgtQf9g
Date: Thu, 27 Dec 2012 22:55:58 +0000
Message-ID: <8239313babad4a5ba73de1740093ff26@BY2PR03MB041.namprd03.prod.outlook.com>
References: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com> <0D574E13-BA0C-46BD-9A27-37C06EAA1986@lodderstedt.net>
In-Reply-To: <0D574E13-BA0C-46BD-9A27-37C06EAA1986@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.46.126.7]
Content-Type: multipart/alternative; boundary="_000_8239313babad4a5ba73de1740093ff26BY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT001.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%LODDERSTEDT.NET$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14MLTC103.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14MLTC103.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51444002)(377454001)(33646001)(47736001)(74662001)(54316002)(15202345001)(31966008)(4396001)(550184003)(47446002)(49866001)(56816002)(74502001)(50986001)(44976002)(54356001)(5343635001)(76482001)(47976001)(51856001)(77982001)(16236675001)(5343655001)(46102001)(59766001)(53806001)(6806001)(16676001)(56776001)(512874001)(42262001)(24736002)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB039; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07083FF734
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a	URI?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 22:57:04 -0000

--_000_8239313babad4a5ba73de1740093ff26BY2PR03MB041namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Q29uY2VybiBoZXJlIGlzIHRoYXQgdmFsdWUgY291bGQgYmUgYW4g4oCcaW50ZXJwcmV0YXRpb27i
gJ0gYW5kIHRodXMgeW91IG1heSBnZXQgZGlmZmVyZW50IHJlc3VsdHMgdGhhdCB5b3UgZG9u4oCZ
dCBnZXQgd2hlbiBpdOKAmXMgYSBVUkkNCg0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBb
bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUb3JzdGVuIExvZGRl
cnN0ZWR0DQpTZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDI2LCAyMDEyIDEwOjQ2IFBNDQpUbzog
TWlrZSBKb25lcw0KQ2M6IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSBN
dXN0IHRoZSBBdWRpZW5jZSB2YWx1ZSBpbiB0aGUgQXNzZXJ0aW9ucyBTcGVjIGJlIGEgVVJJPw0K
DQorMQ0KDQpBbSAyNy4xMi4yMDEyIHVtIDAyOjQzIHNjaHJpZWIgTWlrZSBKb25lcyA8TWljaGFl
bC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+
PjoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtYXNzZXJ0aW9u
cy0wOCNzZWN0aW9uLTUuMSBjdXJyZW50bHkgc2F5czoNCg0KDQogICBBdWRpZW5jZSAgQSBVUkkg
dGhhdCBpZGVudGlmaWVzIHRoZSBwYXJ0eSBpbnRlbmRlZCB0byBwcm9jZXNzIHRoZQ0KDQogICAg
ICBhc3NlcnRpb24uICBUaGUgYXVkaWVuY2UgU0hPVUxEIGJlIHRoZSBVUkwgb2YgdGhlIFRva2Vu
IEVuZHBvaW50DQoNCiAgICAgIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjI8aHR0cDovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA4I3NlY3Rpb24tMy4y
PiBvZiBPQXV0aCAyLjAgW1JGQzY3NDk8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0
OT5dLg0KDQoNCkkgdGhpbmsgdGhhdCDigJxVUknigJ0gc2hvdWxkIGJlIGNoYW5nZWQgdG8g4oCc
dmFsdWXigJ0sIHNpbmNlIGF1ZGllbmNlIHZhbHVlcyBpbiBnZW5lcmFsIG5lZWQgbm90IGJlIFVS
SXMuICBJbiBwYXJ0aWN1bGFyLCBpbiBzb21lIGNvbnRleHRzIE9BdXRoIGNsaWVudF9pZCB2YWx1
ZXMgYXJlIHVzZWQgYXMgYXVkaWVuY2UgdmFsdWVzLCBhbmQgdGhleSBuZWVkIG5vdCBiZSBVUklz
LiAgQWxzbywgU0FNTCBhbGxvd3MgbXVsdGlwbGUgYXVkaWVuY2VzIChhbmQgaW5kZWVkLCB0aGUg
T0F1dGggU0FNTCBwcm9maWxlIGlzIHdyaXR0ZW4gaW4gdGVybXMgb2Yg4oCcYW4gYXVkaWVuY2Ug
dmFsdWXigJ0g4oCTIG5vdCDigJx0aGUgYXVkaWVuY2UgdmFsdWXigJ0pLCBhbmQgc28gdGhlIGdl
bmVyaWMgQXNzZXJ0aW9ucyBzcGVjIHNob3VsZCBkbyBsaWtld2lzZS4NCg0KVGh1cywgSSB3b3Vs
ZCBwcm9wb3NlIGNoYW5naW5nIHRoZSB0ZXh0IGFib3ZlIHRvIHRoZSBmb2xsb3dpbmc6DQoNCg0K
ICAgQXVkaWVuY2UgIEEgdmFsdWUgdGhhdCBpZGVudGlmaWVzIHRoZSBwYXJ0aWVzIGludGVuZGVk
IHRvIHByb2Nlc3MgdGhlDQoNCiAgICAgIGFzc2VydGlvbi4gIEFuIGF1ZGllbmNlIHZhbHVlIFNI
T1VMRCBiZSB0aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludA0KDQogICAgICBhcyBkZWZpbmVk
IGluIFNlY3Rpb24gMy4yPGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1
dGgtYXNzZXJ0aW9ucy0wOCNzZWN0aW9uLTMuMj4gb2YgT0F1dGggMi4wIFtSRkM2NzQ5PGh0dHA6
Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY3NDk+XS4NCg0KICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGluZyBs
aXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo=

--_000_8239313babad4a5ba73de1740093ff26BY2PR03MB041namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N
CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u
TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1
cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h
cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ
Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ
e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp
b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh
bWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl
OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6
d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ
Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Db25jZXJuIGhl
cmUgaXMgdGhhdCB2YWx1ZSBjb3VsZCBiZSBhbiDigJxpbnRlcnByZXRhdGlvbuKAnSBhbmQgdGh1
cyB5b3UgbWF5IGdldCBkaWZmZXJlbnQgcmVzdWx0cyB0aGF0IHlvdSBkb27igJl0IGdldCB3aGVu
IGl04oCZcyBhIFVSSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp
biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IG9hdXRoLWJvdW5jZXNA
aWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9m
IDwvYj5Ub3JzdGVuIExvZGRlcnN0ZWR0PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRGVj
ZW1iZXIgMjYsIDIwMTIgMTA6NDYgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+DQo8
Yj5DYzo8L2I+IG9hdXRoQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbT0FVVEgt
V0ddIE11c3QgdGhlIEF1ZGllbmNlIHZhbHVlIGluIHRoZSBBc3NlcnRpb25zIFNwZWMgYmUgYSBV
Ukk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mIzQzOzEmbmJzcDs8YnI+DQo8YnI+DQpBbSAyNy4xMi4y
MDEyIHVtIDAyOjQzIHNjaHJpZWIgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hh
ZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn
dDs6PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA4I3NlY3Rpb24t
NS4xIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWFzc2VydGlv
bnMtMDgjc2VjdGlvbi01LjE8L2E+IGN1cnJlbnRseSBzYXlzOjxvOnA+PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJwYWdl
LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEw
LjBwdCI+Jm5ic3A7Jm5ic3A7IEF1ZGllbmNlJm5ic3A7IEEgVVJJIHRoYXQgaWRlbnRpZmllcyB0
aGUgcGFydHkgaW50ZW5kZWQgdG8gcHJvY2VzcyB0aGU8L3NwYW4+PG86cD48L286cD48L3ByZT4N
CjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXNz
ZXJ0aW9uLiZuYnNwOyBUaGUgYXVkaWVuY2UgU0hPVUxEIGJlIHRoZSBVUkwgb2YgdGhlIFRva2Vu
IEVuZHBvaW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr
LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFzIGRlZmluZWQgaW4gPGEgaHJlZj0iaHR0
cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1hc3NlcnRpb25zLTA4I3Nl
Y3Rpb24tMy4yIj5TZWN0aW9uIDMuMjwvYT4gb2YgT0F1dGggMi4wIFs8YSBocmVmPSJodHRwOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NzQ5IiB0aXRsZT0iJnF1b3Q7VGhlIE9BdXRoIDIuMCBB
dXRob3JpemF0aW9uIEZyYW1ld29yayZxdW90OyI+UkZDNjc0OTwvYT5dLjwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBs
YW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IOKAnFVSSeKAnSBzaG91
bGQgYmUgY2hhbmdlZCB0byDigJx2YWx1ZeKAnSwgc2luY2UgYXVkaWVuY2UgdmFsdWVzIGluIGdl
bmVyYWwgbmVlZCBub3QgYmUgVVJJcy4mbmJzcDsgSW4gcGFydGljdWxhciwgaW4gc29tZSBjb250
ZXh0cyBPQXV0aCBjbGllbnRfaWQgdmFsdWVzIGFyZSB1c2VkIGFzIGF1ZGllbmNlIHZhbHVlcywg
YW5kIHRoZXkgbmVlZCBub3QgYmUgVVJJcy4mbmJzcDsgQWxzbywgU0FNTCBhbGxvd3MgbXVsdGlw
bGUNCiBhdWRpZW5jZXMgKGFuZCBpbmRlZWQsIHRoZSBPQXV0aCBTQU1MIHByb2ZpbGUgaXMgd3Jp
dHRlbiBpbiB0ZXJtcyBvZiDigJxhbiBhdWRpZW5jZSB2YWx1ZeKAnSDigJMgbm90IOKAnHRoZSBh
dWRpZW5jZSB2YWx1ZeKAnSksIGFuZCBzbyB0aGUgZ2VuZXJpYyBBc3NlcnRpb25zIHNwZWMgc2hv
dWxkIGRvIGxpa2V3aXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaHVzLCBJIHdvdWxkIHBy
b3Bvc2UgY2hhbmdpbmcgdGhlIHRleHQgYWJvdmUgdG8gdGhlIGZvbGxvd2luZzo8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHByZSBz
dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyBBdWRpZW5jZSZuYnNwOyBBIHZhbHVlIHRoYXQg
aWRlbnRpZmllcyB0aGUgcGFydGllcyBpbnRlbmRlZCB0byBwcm9jZXNzIHRoZTwvc3Bhbj48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh
biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBhc3NlcnRpb24uJm5ic3A7IEFuIGF1ZGllbmNlIHZhbHVlIFNIT1VMRCBiZSB0
aGUgVVJMIG9mIHRoZSBUb2tlbiBFbmRwb2ludDwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcyBkZWZp
bmVkIGluIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1
dGgtYXNzZXJ0aW9ucy0wOCNzZWN0aW9uLTMuMiI+U2VjdGlvbiAzLjI8L2E+IG9mIE9BdXRoIDIu
MCBbPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSIgdGl0bGU9IiZx
dW90O1RoZSBPQXV0aCAyLjAgQXV0aG9yaXphdGlvbiBGcmFtZXdvcmsmcXVvdDsiPlJGQzY3NDk8
L2E+XS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p
a2U8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBo
cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj5odHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_8239313babad4a5ba73de1740093ff26BY2PR03MB041namprd03pro_--

From tonynad@microsoft.com  Thu Dec 27 14:58:19 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A102721F8DC2 for ; Thu, 27 Dec 2012 14:58:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.159
X-Spam-Level: *
X-Spam-Status: No, score=1.159 tagged_above=-999 required=5 tests=[AWL=0.625,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fawcgq1+8T3h for ; Thu, 27 Dec 2012 14:58:18 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id DA36821F8D5F for ; Thu, 27 Dec 2012 14:58:17 -0800 (PST)
Received: from BL2FFO11FD015.protection.gbl (10.173.161.202) by BL2FFO11HUB009.protection.gbl (10.173.161.111) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 27 Dec 2012 22:58:09 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD015.mail.protection.outlook.com (10.173.160.223) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Thu, 27 Dec 2012 22:58:08 +0000
Received: from co1outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 27 Dec 2012 22:57:40 +0000
Received: from mail30-co1-R.bigfish.com (10.243.78.197) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Thu, 27 Dec 2012 22:57:40 +0000
Received: from mail30-co1 (localhost [127.0.0.1])	by mail30-co1-R.bigfish.com (Postfix) with ESMTP id 76AED7400BB	for ; Thu, 27 Dec 2012 22:57:40 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -19
X-BigFish: PS-19(zz98dI9371Id6eah936eIc85fh1418Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275bh8275dh1033IL18c673h17326ahz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail30-co1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB044; LANG:en; 
Received: from mail30-co1 (localhost.localdomain [127.0.0.1]) by mail30-co1 (MessageSwitch) id 1356649058313039_10900; Thu, 27 Dec 2012 22:57:38 +0000 (UTC)
Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.199])	by mail30-co1.bigfish.com (Postfix) with ESMTP id 494D6900108; Thu, 27 Dec 2012 22:57:38 +0000 (UTC)
Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 27 Dec 2012 22:57:38 +0000
Received: from BY2PR03MB044.namprd03.prod.outlook.com (10.255.241.148) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.245.2; Thu, 27 Dec 2012 22:57:36 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB044.namprd03.prod.outlook.com (10.255.241.148) with Microsoft SMTP Server (TLS) id 15.0.586.12; Thu, 27 Dec 2012 22:57:28 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Thu, 27 Dec 2012 22:57:10 +0000
From: Anthony Nadalin 
To: John Bradley , Mike Jones 
Thread-Topic: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
Thread-Index: AQHN5DacwwSjS5JJ1UC2BfUMbk4WcZgtQmMA
Date: Thu, 27 Dec 2012 22:57:09 +0000
Message-ID: <8b1f49ba29404f349af3dc3abb2878e4@BY2PR03MB041.namprd03.prod.outlook.com>
References: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.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: [50.46.126.7]
Content-Type: multipart/alternative; boundary="_000_8b1f49ba29404f349af3dc3abb2878e4BY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT003.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(377454001)(51444002)(24454001)(54356001)(53806001)(31966008)(74662001)(54316002)(51856001)(512954001)(49866001)(550184003)(56816002)(47736001)(47976001)(76482001)(4396001)(47446002)(77982001)(50986001)(6806001)(74502001)(15202345001)(16236675001)(56776001)(44976002)(16676001)(5343655001)(33646001)(46102001)(59766001)(5343635001)(42262001)(24736002)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB009; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07083FF734
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a	URI?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Dec 2012 22:58:19 -0000

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

What do you mean by multi-valued and what are the semantics of multi-vale ?

From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of J=
ohn Bradley
Sent: Thursday, December 27, 2012 5:32 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a=
 URI?

Agreed.

We need to clarify that the value of the audience claim can be multi valued=
 as well.

John B.

On 2012-12-26, at 10:43 PM, Mike Jones > wrote:


http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 curre=
ntly says:


   Audience  A URI that identifies the party intended to process the

      assertion.  The audience SHOULD be the URL of the Token Endpoint

      as defined in Section 3.2 of OAuth 2.0 [RFC6749].


I think that "URI" should be changed to "value", since audience values in g=
eneral need not be URIs.  In particular, in some contexts OAuth client_id v=
alues are used as audience values, and they need not be URIs.  Also, SAML a=
llows multiple audiences (and indeed, the OAuth SAML profile is written in =
terms of "an audience value" - not "the audience value"), and so the generi=
c Assertions spec should do likewise.

Thus, I would propose changing the text above to the following:


   Audience  A value that identifies the parties intended to process the

      assertion.  An audience value SHOULD be the URL of the Token Endpoint

      as defined in Section 3.2 of OAuth 2.0 [RFC6749].

                                                            -- Mike

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


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











What do you mean by multi=
-valued and what are the semantics of multi-vale ?


 






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

Sent: Thursday, December 27, 2012 5:32 AM

To: Mike Jones

Cc: oauth@ietf.org

Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Sp=
ec be a URI?






 


Agreed.




 






We need to clarify that the value of the audience cl=
aim can be multi valued as well. 






 






John B.






 






On 2012-12-26, at 10:43 PM, Mike Jones <Michael.Jones@microsoft.com>=
 wrote:


















 




   Audi=
ence  A URI that identifies the party intended to process the


   =
;   assertion.  The audience SHOULD be the URL of the Token =
Endpoint


   =
;   as defined in Section 3.2=
 of OAuth 2.0 [RFC6749].


 




I think that “URI” should b=
e changed to “value”, since audience values in general need not=
 be URIs.  In particular, in some contexts OAuth client_id values are =
used as audience
 values, and they need not be URIs.  Also, SAML allows multiple audien=
ces (and indeed, the OAuth SAML profile is written in terms of “an au=
dience value” – not “the audience value”), and so t=
he generic Assertions spec should do likewise.






 






Thus, I would propose changing the text=
 above to the following:






 




   Audi=
ence  A value that identifies the parties intended to process the


   =
;   assertion.  An audience value SHOULD be the URL of the T=
oken Endpoint

   =
;   as defined in Section 3.2=
 of OAuth 2.0 [RFC6749].




 






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






 




_____________________________________=
__________

OAuth mailing list

OAuth@ietf.o=
rg

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









 








--_000_8b1f49ba29404f349af3dc3abb2878e4BY2PR03MB041namprd03pro_--

From hardjono@mit.edu  Thu Dec 27 16:38:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C921F8DCA for ; Thu, 27 Dec 2012 16:38:32 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyH3aqRrx-kk for ; Thu, 27 Dec 2012 16:38:31 -0800 (PST)
Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3647921F8DC9 for ; Thu, 27 Dec 2012 16:38:30 -0800 (PST)
X-AuditID: 12074422-b7f616d000000e7c-40-50dcea06b901
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 4C.BA.03708.60AECD05; Thu, 27 Dec 2012 19:38:30 -0500 (EST)
Received: from outgoing-exchange-1.mit.edu (OUTGOING-EXCHANGE-1.MIT.EDU [18.9.28.15]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id qBS0cTRP023374;  Thu, 27 Dec 2012 19:38:29 -0500
Received: from W92EXEDGE6.EXCHANGE.MIT.EDU (W92EXEDGE6.EXCHANGE.MIT.EDU [18.7.73.28]) by outgoing-exchange-1.mit.edu (8.13.8/8.12.4) with ESMTP id qBS0cK80021540; Thu, 27 Dec 2012 19:38:29 -0500
Received: from OC11EXHUB10.exchange.mit.edu (18.9.3.24) by W92EXEDGE6.EXCHANGE.MIT.EDU (18.7.73.28) with Microsoft SMTP Server (TLS) id 14.2.309.2; Thu, 27 Dec 2012 19:36:59 -0500
Received: from OC11EXPO24.exchange.mit.edu ([169.254.1.103]) by OC11EXHUB10.exchange.mit.edu ([18.9.3.24]) with mapi id 14.02.0309.002; Thu, 27 Dec 2012 19:37:29 -0500
From: Thomas Hardjono 
To: "Anganes, Amanda L" , "oauth@ietf.org" 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
Thread-Index: Ac3kZ80uYlMMo4p2TFO+SThlSNMWiAAFVdwAAASuhzA=
Date: Fri, 28 Dec 2012 00:37:29 +0000
Message-ID: <5E393DF26B791A428E5F003BB6C5342A10CCB5F3@OC11EXPO24.exchange.mit.edu>
References: <5E393DF26B791A428E5F003BB6C5342A10CCB1D7@OC11EXPO24.exchange.mit.edu> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [71.184.223.209]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CDE469.986139A0"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sb0gTcRjH+d3O223s6pzafmkWHpWVzVQ0TKUsfCG9yBH5xgK73E832qbc baK+2ougsKyMEbagVEaQBjMDDdPIWYmL/ANOnIr5N2s2JYhKS+lul3/efZ57vt/v8zzcj5Sp nUQ0abRYEWdhTQyhxNWKqAQtEZjQJc19lKW/7fkB0vuCASIby3W5VrDcoN0n12EFyiw9MhnL EXfs5GWloaOhES/7XVzhH/BgdhC8VA0UJKRT4Yg/IJd4FxycdBPVQEmq6dcADi+6gFS8AbBt 1imTivcAztj/YqJFTbcDuHTntMTNAA6tMSIT9CHY/6crFBtJF8BPbXZCZBl9EL4YuxEmBkXQ twB8+MgbKiLpGgBHv/bhkiMDLjRMhCbg9AHYOtUZclP0eThfNyiX1rgH4IDvfkikoM/CeZcD iAyEK355n2HSOA0cm3uMSddFwumhD8TGpesd0/+ZgTNd/ZgYKhO3aB4aBdK0cNj3YA6/C6Bz W5Zzu865TSeJkqCrYRWTOAE+aViUSZwJ61a7CYnjoOPmtFziNLj47juoB2QTiNWbq7Rm1mji UZGWL2ItFsRp0xLNRmsi0ttagfjb5TnMS7DSzXgATQJGReVWT+jUYWw5X2n2gN0kxkRRaEH4 tONKqb7SwPKGQs5mQrwH7BdmzbQ0D4Jo3FJqQUwk5fIJOkrPVlYhrnRDFkPijIYa0fvz1HQJ a0VXESpD3EZ3D0kykKr9IhjDOVSCKoqNJutWGyMVHgBJlRD+XFyC4stYM28skfpeEBetodyi mRYbBptl07vxpANAI5wVQXWKKpXw4DfdASEYE4IzVaFgK7vVirYD/cK5+Kyx67MFafvam054 e4ZjWyrW/I6JJWtmBul2BLKXl1V5z25rlNlPC9JTFDmj5ti4ps94b3lh8lF3W/7Ct5KRrNre yaWI1fJ4m24vF9WN/KnL1a/yD/ujsi6k7ETxk+v1Z5Z6i7hxR+N48tTYRVvhNd+pmp9yXWPM 6PEgg/MGNvmIjOPZf2ayy+StAwAA
Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 00:38:32 -0000

------=_NextPart_000_0000_01CDE469.986139A0
Content-Type: text/plain;
	charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

Thanks Amanda,

- Scope and types:  We went back and forth with regards to "scope type" =
and finally just used "type" with the assumption that the reader would =
know what we mean by it (ie. context dependent).  However, we're very =
open to going back to the previous language.

- Resource set registration: yes that sentence does read weirdly, will =
fix :-)

- Resource set registration API:  If Alice (the RO) has already =
previously registered some resources at the AS, then Alice will already =
have a PAT token (and the AS knows about Alice, her PAT, her resource =
sets and scopes). If Alice comes back again with the same PAT and =
forgets to specificy the path component, we assume the AS is smart =
enough to figure out which sets Alice is refering to. Does this help? =
(or does it still read weirdly).

- The {rsreguri} URI component is defined but never used: hmm yes you =
are correct. Will fix this.


Thank you again.

cheers,

/thomas/

__________________________________________


> -----Original Message-----
> From: Anganes, Amanda L [mailto:aanganes@mitre.org]
> Sent: Thursday, December 27, 2012 4:57 PM
> To: Thomas Hardjono; oauth@ietf.org
> Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW:
> New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
>=20
> Hi Thomas,
>=20
> Here is some initial feedback.
>=20
> Introduction paragraph 2:
>=20
> Remove duplicate "with": "the OpenID Provider (OP) component is a
> specialized version of an OAuth authorization server that brokers
> availability of user attributes by dealing *with with* an ecosystem of
> attribute providers (APs)."
>=20
> Section 1.2 Terminology:
>=20
> This is more of a comment for the UMA WG in general: "scope type" is =
an
> unfortunate term (which appears in the UMA core draft [1] as well - if
> memory serves the term used to be just "scope" but I couldn't find a
> diff reference for when that changed). Including "type" in the term
> makes it sound like it refers to a class or kind of scope, which
> doesn't seem to be what you mean. I understand that "scope" cannot be
> used since it is already reserved by OAuth, but perhaps a better
> synonym could be found and used instead?
>=20
> 2. Resource set registration
>=20
> 2nd sentence reads oddly. Change from "For any of the resource owner's
> sets of resources this authorization server needs to be aware of, the
> resource server MUST register these resource sets=A9" to "If this
> authorization server needs to be aware of any of the resource sets, =
the
> resource server MUST register those resource sets=A9"
>=20
> 2.2 Resource set descriptions
>=20
> "scopes" and to refer to sets of "scope type"s and "type" to refer to
> the class/kind of resource set this is add to the argument above that
> "scope type" is a misleading term.
>=20
> 2.3 Resource set registration API
>=20
> I don't understand what this sentence means: "Without a specific
> resource set identifier path component, the URI applies to the set of
> resource set descriptions already registered." Can you clarify?
>=20
> The {rsreguri} URI component is defined but never used. It looks like
> all of the "/resource_set" URIs should be prefaced with this component
> throughout the following sections?
>=20
> [1] https://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
>=20
> --
> Amanda Anganes
> Info Sys Engineer, G061
> The MITRE Corporation
> 781-271-3103
> aanganes@mitre.org
>=20
>=20
> On 12/27/12 2:24 PM, "Thomas Hardjono"  wrote:
>=20
> >Folks,
> >
> >The OAuth 2.0 Resource Set Registration draft is essentially a =
generic
> >first phase of the User Managed Access (UMA) profile of OAuth2.0.
> This
> >allows the RO to "register" (make known) to the AS the resources
> he/she
> >wishes to share.
> >
> >Looking forward to comments/feedback.
> >
> >/thomas/
> >
> >__________________________________________
> >
> >
> >-----Original Message-----
> >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> >Sent: Thursday, December 27, 2012 2:07 PM
> >To: Thomas Hardjono
> >Subject: New Version Notification for
> >draft-hardjono-oauth-resource-reg-00.txt
> >
> >
> >A new version of I-D, draft-hardjono-oauth-resource-reg-00.txt
> >has been successfully submitted by Thomas Hardjono and posted to the
> IETF
> >repository.
> >
> >Filename:        draft-hardjono-oauth-resource-reg
> >Revision:        00
> >Title:           OAuth 2.0 Resource Set Registration
> >Creation date:   2012-12-27
> >WG ID:           Individual Submission
> >Number of pages: 19
> >URL:
> =
>http://www.ietf.org/internet-drafts/draft-hardjono-oauth-resource-reg-
> 00.t
> >xt
> >Status:
> >http://datatracker.ietf.org/doc/draft-hardjono-oauth-resource-reg
> >Htmlized:
> >http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
> >
> >
> >Abstract:
> >   This specification defines a resource set registration mechanism
> >   between an OAuth 2.0 authorization server and resource server.  =
The
> >   resource server registers information about the semantics and
> >   discovery properties of its resources with the authorization
> server.
> >
> >
> >
> >
> >The IETF Secretariat
> >
> >_______________________________________________
> >OAuth mailing list
> >OAuth@ietf.org
> >https://www.ietf.org/mailman/listinfo/oauth


------=_NextPart_000_0000_01CDE469.986139A0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP4DCCBBow
ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk
IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp
ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd
hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj
DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU
Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF
s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D
J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez
useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg
lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8
T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6
g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE
74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggTMMIIDtKADAgECAhB4Uq7mlIth1FJ90gEtCu8wMA0G
CSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd
BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBo
dHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBW
YWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVy
IENBIC0gRzMwHhcNMTIwMzA2MDAwMDAwWhcNMTMwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZl
cmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13
d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChj
KTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQg
Q2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9u
bzEfMB0GCSqGSIb3DQEJARYQaGFyZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw
gYkCgYEAmPCe+VCa3OQBiPsHUyh69qmKngwP6dHrXQtHphyr1P9LnMHdF+DletpaSm1b4HXjqbzm
Ne/dj5169ZzwMjFdl3cVYGbZTvILmHNXH0kSlYl4NM/59ri+UBnV3oBnXg+g3Vhet6MDWJn/7exV
AY4u5SpM7I+b+yQwDlTT90rJbXcCAwEAAaOB0jCBzzAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYL
YIZIAYb4RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTAL
BgNVHQ8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMFAGA1UdHwRJMEcwRaBD
oEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRh
bElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAthQJhe+BCY99zTBcAG73fFOmROKAFQyQLxzV
mJLBy8HV2hNXVA8qL87UpbBLcWT3+qDmMYn70X3Hhj+givCw0hLLeEpOWWRtXSuGt7MNrjQR1sNz
Zl+NJQN+S9kl1AzYMec19OE8D+5A8WbOna8aWhGmMISqwJ3FBt6VUFIosTUGTHLI9H+LrgENQMif
jCrY2PoLZvsgdQRtwhYTMbbeSLWuHILpZn2zEluSU6drzaTBPIA5uOUAtwCPRfocAzTh/mvfJ51y
MNoLjFeZaovhhUdeBYJaI78y55A0nBsGyYQvYdESuqJf1UCGIK76M3c37q5YZOvmVA6sIloOcWk1
wzCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl
ZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0
aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5MDQzMDIzNTk1OVow
gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp
Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl
cmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG
A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwTj+mxjUFONPfaC+Nq
+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliWB6+eFBgHT1q9n9Ix
slQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGcedAATDdCG2pNn+DMD
rho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69ssQRevsG2lC2XkC0n
0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOMWev7btVCxL5Bx/UC
AwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AudmVy
aXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtghkgBhvhFAQcXATBW
MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoGCCsGAQUFBwICMB4a
HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2Ny
bC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4GCCsGAQUFBwEMBGIw
YKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy70FI4mymsSweLIQUY
MCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNVHREEJzAlpCMwITEf
MB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdhCEH9OASiS+e1zPVD
9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlT
aWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykg
MTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0g
RzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9BmYG1qQW1UjjpOYSJ
bOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN7/HSgZfKVFpDvzeL
eo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqTOtWuEnAI6/s74nfs
6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih/1yybUneZVJC+w6I
0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0DuFUWjMZoA+ciqHML
sbyg2lJY3QoOf8GCMYIEuDCCBLQCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp
U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy
bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsT
FVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlk
dWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQeFKu5pSLYdRSfdIBLQrvMDAJBgUrDgMCGgUAoIIDGzAY
BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjEyMjgwMDM3MjRaMCMG
CSqGSIb3DQEJBDEWBBQK13NK++1j7GeUPt6qHxapwleMKDCBqwYJKoZIhvcNAQkPMYGdMIGaMAsG
CWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3
DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAL
BglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATCCAQMGCSsGAQQBgjcQBDGB9TCB
8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw
NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczAhB4
Uq7mlIth1FJ90gEtCu8wMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7
MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp
MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh
c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQeFKu5pSLYdRSfdIBLQrvMDANBgkq
hkiG9w0BAQEFAASBgC2LO3vulomWKQOwiQUsyiNOlj0HaAPJMQNH7W2OUeEGnLru4M3hhhYH0Kg6
zTX01MPXb7v90ztcoIrTq/4nlpz9qNpXmoW10I3LG0ALLUIYrzooO7e3QN8AxV7t5yb5d9y2ZX8k
mEFoIjiUg/7z2bXjgdJMO7ypEMEo/5b65TdcAAAAAAAA

------=_NextPart_000_0000_01CDE469.986139A0--

From ve7jtb@ve7jtb.com  Thu Dec 27 16:53:56 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5680521F8DDD for ; Thu, 27 Dec 2012 16:53:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.352
X-Spam-Level: 
X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=0.246,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvsmfX1iHG9K for ; Thu, 27 Dec 2012 16:53:55 -0800 (PST)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5B46A21F8DDF for ; Thu, 27 Dec 2012 16:53:54 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id hg5so9263672qab.15 for ; Thu, 27 Dec 2012 16:53:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=CX26d1fUhJiQ/jIAFMeGXiwfpb7j8qLGOtfTRsxvRvA=; b=lWVYyb3fjEERbNM9vKaRqm9YkKmOuW6tWMM7EHjx5F7BrIPk7TJWA9ymcXG12/DdRv 9mU7J3J2j9fQVl5P5wBtV+ocFiirDYP8NAoh6ulmveBfPQW/MPwzLyPVLcvCiYsGTEUW z0xepupUUV5OKwHpkJdx91gxgYPLzLjMSwSfc77q6t8OtldN/CqEaBa7f/lULt2ubUeV 10RCwq0QCJFKCP2suDe7FTAuWP3A/TkN+VEhuFoBCV5fc5ZxkJC21aney8Ax85SNXq6N GfLFoEkkQ5jMOVBExI41/uBsGqADyF0kdooPHGZCplLE0FXQ3mo9UYbqqM1iaSPwkw51 xr3Q==
X-Received: by 10.49.71.178 with SMTP id w18mr17835720qeu.11.1356656033944; Thu, 27 Dec 2012 16:53:53 -0800 (PST)
Received: from [192.168.1.211] (190-20-36-168.baf.movistar.cl. [190.20.36.168]) by mx.google.com with ESMTPS id f5sm7139097qac.5.2012.12.27.16.53.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Dec 2012 16:53:52 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CB940E11-4C16-4AF3-B74E-2C63A702A612"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <8b1f49ba29404f349af3dc3abb2878e4@BY2PR03MB041.namprd03.prod.outlook.com>
Date: Thu, 27 Dec 2012 21:53:41 -0300
Message-Id: <76EAF572-1701-4FB6-AA20-21831D8055D7@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>  <8b1f49ba29404f349af3dc3abb2878e4@BY2PR03MB041.namprd03.prod.outlook.com>
To: Anthony Nadalin 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmhJgtYliePri07QFI6QVIxYGZkgZzdDfxmVEw82awRAIeLs0ncuNZZyXH5JkHBVhjuq26f
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 00:53:56 -0000

--Apple-Mail=_CB940E11-4C16-4AF3-B74E-2C63A702A612
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

The discussion on the Connect call was that audience could be a literal =
or an array.

example

"aud":["http://audiance1.com","http://audiance2.com"]

In some cases the token may want to have more than a single audience. =20=

(anthropomorphic license)

in the simple case it would still be
"aud":"http://audiance1.com"

While dynamic typing of variables is not my favourite thing in =
principal, I am assured that this is common JSON syntax that people can =
deal with.

The idea is to standardize this rather than everyone coming up with =
their own way around the restriction as google did by adding the prn =
claim.

At least this way if you only trust tokens with yourself as the audience =
you have a easy way to check.

John B.

On 2012-12-27, at 7:57 PM, Anthony Nadalin  =
wrote:

> What do you mean by multi-valued and what are the semantics of =
multi-vale ?
> =20
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf =
Of John Bradley
> Sent: Thursday, December 27, 2012 5:32 AM
> To: Mike Jones
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec =
be a URI?
> =20
> Agreed.
> =20
> We need to clarify that the value of the audience claim can be multi =
valued as well.=20
> =20
> John B.
> =20
> On 2012-12-26, at 10:43 PM, Mike Jones  =
wrote:
>=20
>=20
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 =
currently says:
> =20
>    Audience  A URI that identifies the party intended to process the
>       assertion.  The audience SHOULD be the URL of the Token Endpoint
>       as defined in Section 3.2 of OAuth 2.0 [RFC6749].
> =20
> I think that =93URI=94 should be changed to =93value=94, since =
audience values in general need not be URIs.  In particular, in some =
contexts OAuth client_id values are used as audience values, and they =
need not be URIs.  Also, SAML allows multiple audiences (and indeed, the =
OAuth SAML profile is written in terms of =93an audience value=94 =96 =
not =93the audience value=94), and so the generic Assertions spec should =
do likewise.
> =20
> Thus, I would propose changing the text above to the following:
> =20
>    Audience  A value that identifies the parties intended to process =
the
>       assertion.  An audience value SHOULD be the URL of the Token =
Endpoint
>       as defined in Section 3.2 of OAuth 2.0 [RFC6749].
> =20
>                                                             -- Mike
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_CB940E11-4C16-4AF3-B74E-2C63A702A612
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

The discussion on the Connect =
call was that audience could be a literal or an =
array.

example


In some cases the token may want to have more than a single =
audience.  
(anthropomorphic =
license)

in the simple case it would still =
be

While dynamic typing of variables is not my favourite thing in =
principal, I am assured that this is common JSON syntax that people can =
deal with.

The idea is to standardize this =
rather than everyone coming up with their own way around the restriction =
as google did by adding the prn claim.

At least =
this way if you only trust tokens with yourself as the audience you have =
a easy way to check.

John =
B.

On 2012-12-27, at 7:57 PM, Anthony =
Nadalin <tonynad@microsoft.com> =
wrote:

What do you mean by =
multi-valued and what are the semantics of multi-vale =
?
 oauth-bounces@ietf.org =
[mailto:oauth-bounces@ietf.org] On Behalf Of John =
Bradley
Sent: Thursday, December 27, 2012 =
5:32 AM
To: Mike =
Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Must the =
Audience value in the Assertions Spec be a =
URI?
We =
need to clarify that the value of the audience claim can be multi valued =
as well. 
John =
B.
On =
2012-12-26, at 10:43 PM, Mike Jones <Michael.Jones@microsoft.com> =
wrote:
      assertion.  The audience =
SHOULD be the URL of the Token Endpoint
      as defined in Section 3.2 of OAuth 2.0 [ I think =
that =93URI=94 should be changed to =93value=94, since audience values =
in general need not be URIs.  In particular, in some contexts OAuth =
client_id values are used as audience values, and they need not be =
URIs.  Also, SAML allows multiple audiences (and indeed, the OAuth =
SAML profile is written in terms of =93an audience value=94 =96 not =93the=
 audience value=94), and so the generic Assertions spec should do =
likewise.
   =
Audience  A value that identifies the parties intended to process =
the
      assertion.  An audience =
value SHOULD be the URL of the Token Endpoint
      as defined in Section 3.2 of OAuth 2.0 [
Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 01:11:33 -0000

Amanda, thanks for the lightning-fast comments back. A couple of =
additional notes on top of Thomas's response:

The "scope type" language is indeed new this time -- of course this =
whole modular spec is newly broken out, but the previous text from UMA's =
rev 05 still said "scope". (There's a new member in the JSON description =
of a resource set that is called "type", but this is actually the =
resource set's type: different thing.) Maybe this should just be changed =
back to "scope" and "scope description", as we really do mean the same =
construct as in plain OAuth, although here it's enhanced with a =
machine-readable description, and it's mappable to resource sets that =
have been explicitly identified. One thing we've been learning lately is =
that terminology impedance mismatches are not worth the cost; this one =
is a recent back-sliding. :)

Regarding the sentence "Without a specific resource set identifier path =
component, the URI applies to the set of resource set descriptions =
already registered." in Section 2.3: I suspect this can just be deleted =
entirely. It's redundant with the "List resource set registrations" =
bullet item just below, which literally shows the {rsid} component of =
the path being absent. This is the only supported method in this API =
that has no {rsid} path component.

Regarding {rsreguri}: I do see it defined, in this same Section 2.3. =
Basically this notation is simply a device to allow for referring to a =
"resource set registration endpoint" (defined in the Terminology =
section) in the URIs here that serve as method templates. Is there a =
better way to do this?

	Eve

On 27 Dec 2012, at 4:37 PM, Thomas Hardjono  wrote:

> Thanks Amanda,
>=20
> - Scope and types:  We went back and forth with regards to "scope =
type" and finally just used "type" with the assumption that the reader =
would know what we mean by it (ie. context dependent).  However, we're =
very open to going back to the previous language.
>=20
> - Resource set registration: yes that sentence does read weirdly, will =
fix :-)
>=20
> - Resource set registration API:  If Alice (the RO) has already =
previously registered some resources at the AS, then Alice will already =
have a PAT token (and the AS knows about Alice, her PAT, her resource =
sets and scopes). If Alice comes back again with the same PAT and =
forgets to specificy the path component, we assume the AS is smart =
enough to figure out which sets Alice is refering to. Does this help? =
(or does it still read weirdly).
>=20
> - The {rsreguri} URI component is defined but never used: hmm yes you =
are correct. Will fix this.
>=20
>=20
> Thank you again.
>=20
> cheers,
>=20
> /thomas/
>=20
> __________________________________________
>=20
>=20
>> -----Original Message-----
>> From: Anganes, Amanda L [mailto:aanganes@mitre.org]
>> Sent: Thursday, December 27, 2012 4:57 PM
>> To: Thomas Hardjono; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW:
>> New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
>>=20
>> Hi Thomas,
>>=20
>> Here is some initial feedback.
>>=20
>> Introduction paragraph 2:
>>=20
>> Remove duplicate "with": "the OpenID Provider (OP) component is a
>> specialized version of an OAuth authorization server that brokers
>> availability of user attributes by dealing *with with* an ecosystem =
of
>> attribute providers (APs)."
>>=20
>> Section 1.2 Terminology:
>>=20
>> This is more of a comment for the UMA WG in general: "scope type" is =
an
>> unfortunate term (which appears in the UMA core draft [1] as well - =
if
>> memory serves the term used to be just "scope" but I couldn't find a
>> diff reference for when that changed). Including "type" in the term
>> makes it sound like it refers to a class or kind of scope, which
>> doesn't seem to be what you mean. I understand that "scope" cannot be
>> used since it is already reserved by OAuth, but perhaps a better
>> synonym could be found and used instead?
>>=20
>> 2. Resource set registration
>>=20
>> 2nd sentence reads oddly. Change from "For any of the resource =
owner's
>> sets of resources this authorization server needs to be aware of, the
>> resource server MUST register these resource sets=A9" to "If this
>> authorization server needs to be aware of any of the resource sets, =
the
>> resource server MUST register those resource sets=A9"
>>=20
>> 2.2 Resource set descriptions
>>=20
>> "scopes" and to refer to sets of "scope type"s and "type" to refer to
>> the class/kind of resource set this is add to the argument above that
>> "scope type" is a misleading term.
>>=20
>> 2.3 Resource set registration API
>>=20
>> I don't understand what this sentence means: "Without a specific
>> resource set identifier path component, the URI applies to the set of
>> resource set descriptions already registered." Can you clarify?
>>=20
>> The {rsreguri} URI component is defined but never used. It looks like
>> all of the "/resource_set" URIs should be prefaced with this =
component
>> throughout the following sections?
>>=20
>> [1] https://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
>>=20
>> --
>> Amanda Anganes
>> Info Sys Engineer, G061
>> The MITRE Corporation
>> 781-271-3103
>> aanganes@mitre.org
>>=20
>>=20
>> On 12/27/12 2:24 PM, "Thomas Hardjono"  wrote:
>>=20
>>> Folks,
>>>=20
>>> The OAuth 2.0 Resource Set Registration draft is essentially a =
generic
>>> first phase of the User Managed Access (UMA) profile of OAuth2.0.
>> This
>>> allows the RO to "register" (make known) to the AS the resources
>> he/she
>>> wishes to share.
>>>=20
>>> Looking forward to comments/feedback.
>>>=20
>>> /thomas/
>>>=20
>>> __________________________________________
>>>=20
>>>=20
>>> -----Original Message-----
>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>> Sent: Thursday, December 27, 2012 2:07 PM
>>> To: Thomas Hardjono
>>> Subject: New Version Notification for
>>> draft-hardjono-oauth-resource-reg-00.txt
>>>=20
>>>=20
>>> A new version of I-D, draft-hardjono-oauth-resource-reg-00.txt
>>> has been successfully submitted by Thomas Hardjono and posted to the
>> IETF
>>> repository.
>>>=20
>>> Filename:        draft-hardjono-oauth-resource-reg
>>> Revision:        00
>>> Title:           OAuth 2.0 Resource Set Registration
>>> Creation date:   2012-12-27
>>> WG ID:           Individual Submission
>>> Number of pages: 19
>>> URL:
>>> =
http://www.ietf.org/internet-drafts/draft-hardjono-oauth-resource-reg-
>> 00.t
>>> xt
>>> Status:
>>> http://datatracker.ietf.org/doc/draft-hardjono-oauth-resource-reg
>>> Htmlized:
>>> http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
>>>=20
>>>=20
>>> Abstract:
>>>  This specification defines a resource set registration mechanism
>>>  between an OAuth 2.0 authorization server and resource server.  The
>>>  resource server registers information about the semantics and
>>>  discovery properties of its resources with the authorization
>> server.
>>>=20
>>>=20
>>>=20
>>>=20
>>> The IETF Secretariat
>>>=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


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


From internet-drafts@ietf.org  Fri Dec 28 02:01:16 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7803F21F8E01; Fri, 28 Dec 2012 02:01:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeaml3wzAWp0; Fri, 28 Dec 2012 02:01:15 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6AA821F8D27; Fri, 28 Dec 2012 02:01:15 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.37
Message-ID: <20121228100115.23993.75761.idtracker@ietfa.amsl.com>
Date: Fri, 28 Dec 2012 02:01:15 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-json-web-token-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 10:01:16 -0000

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

	Title           : JSON Web Token (JWT)
	Author(s)       : Michael B. Jones
                          John Bradley
                          Nat Sakimura
	Filename        : draft-ietf-oauth-json-web-token-06.txt
	Pages           : 24
	Date            : 2012-12-28

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

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


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

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

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


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


From internet-drafts@ietf.org  Fri Dec 28 02:02:53 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99D2C21F8D22; Fri, 28 Dec 2012 02:02:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.526
X-Spam-Level: 
X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUV3A7+z+ftn; Fri, 28 Dec 2012 02:02:53 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAFB21F8D27; Fri, 28 Dec 2012 02:02:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.37
Message-ID: <20121228100253.24864.21618.idtracker@ietfa.amsl.com>
Date: Fri, 28 Dec 2012 02:02:53 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwt-bearer-04.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 10:02:53 -0000

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

	Title           : JSON Web Token (JWT) Bearer Token Profiles for OAuth 2.0
	Author(s)       : Michael B. Jones
                          Brian Campbell
                          Chuck Mortimore
	Filename        : draft-ietf-oauth-jwt-bearer-04.txt
	Pages           : 11
	Date            : 2012-12-28

Abstract:
   This specification defines the use of a JSON Web Token (JWT) Bearer
   Token as a means for requesting an OAuth 2.0 access token as well as
   for use as a means of client authentication.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwt-bearer-04


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


From internet-drafts@ietf.org  Fri Dec 28 02:04:28 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A7721F8E03; Fri, 28 Dec 2012 02:04:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.525
X-Spam-Level: 
X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWlrBfv1JYqB; Fri, 28 Dec 2012 02:04:27 -0800 (PST)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4639D21F8D22; Fri, 28 Dec 2012 02:04:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.37
Message-ID: <20121228100427.7223.84785.idtracker@ietfa.amsl.com>
Date: Fri, 28 Dec 2012 02:04:27 -0800
Cc: oauth@ietf.org
Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-assertions-09.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 10:04:28 -0000

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

	Title           : Assertion Framework for OAuth 2.0
	Author(s)       : Brian Campbell
                          Chuck Mortimore
                          Michael B. Jones
                          Yaron Y. Goland
	Filename        : draft-ietf-oauth-assertions-09.txt
	Pages           : 22
	Date            : 2012-12-28

Abstract:
   This specification provides a framework for the use of assertions
   with OAuth 2.0 in the form of a new client authentication mechanism
   and a new authorization grant type.  Mechanisms are specified for
   transporting assertions during interactions with a token endpoint, as
   well as general processing rules.

   The intent of this specification is to provide a common framework for
   OAuth 2.0 to interwork with other identity systems using assertions,
   and to provide alternative client authentication mechanisms.

   Note that this specification only defines abstract message flows and
   processing rules.  In order to be implementable, companion
   specifications are necessary to provide the corresponding concrete
   instantiations.


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

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-assertions-09


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


From aanganes@mitre.org  Fri Dec 28 05:58:45 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ACD21F88B5 for ; Fri, 28 Dec 2012 05:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.195
X-Spam-Level: 
X-Spam-Status: No, score=-6.195 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ex4j9WQCadX2 for ; Fri, 28 Dec 2012 05:58:44 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D4F9221F87F9 for ; Fri, 28 Dec 2012 05:58:43 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D585A1F069C; Fri, 28 Dec 2012 08:58:42 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id C33921F078D; Fri, 28 Dec 2012 08:58:42 -0500 (EST)
Received: from IMCMBX04.MITRE.ORG ([169.254.4.200]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Fri, 28 Dec 2012 08:58:42 -0500
From: "Anganes, Amanda L" 
To: Eve Maler , Thomas Hardjono 
Thread-Topic: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
Thread-Index: Ac3kZ80uYlMMo4p2TFO+SThlSNMWiAAFVdwAAASuhzAADJMSAAAQUT6A
Date: Fri, 28 Dec 2012 13:58:41 +0000
Message-ID: 
In-Reply-To: <854169AF-9160-4C8F-AA31-54ED98C5E684@xmlgrrl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.5.121010
x-originating-ip: [172.31.37.53]
Content-Type: multipart/alternative; boundary="_000_B61A05DAABADEA4EA2F19424825286FA1E673C27IMCMBX04MITREOR_"
MIME-Version: 1.0
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 13:58:45 -0000

--_000_B61A05DAABADEA4EA2F19424825286FA1E673C27IMCMBX04MITREOR_
Content-Type: text/plain; charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

Hi Eve and Thomas,

On 12/27/12 8:11 PM, "Eve Maler" > =
wrote:

Amanda, thanks for the lightning-fast comments back. A couple of additional=
 notes on top of Thomas's response:

The "scope type" language is indeed new this time -- of course this whole m=
odular spec is newly broken out, but the previous text from UMA's rev 05 st=
ill said "scope". (There's a new member in the JSON description of a resour=
ce set that is called "type", but this is actually the resource set's type:=
 different thing.) Maybe this should just be changed back to "scope" and "s=
cope description", as we really do mean the same construct as in plain OAut=
h, although here it's enhanced with a machine-readable description, and it'=
s mappable to resource sets that have been explicitly identified. One thing=
 we've been learning lately is that terminology impedance mismatches are no=
t worth the cost; this one is a recent back-sliding. :)

I think it would make much more sense to stick with "scope" and "scope desc=
ription". I assumed that you were trying to avoid collisions with OAuth by =
changing it, but it sounds like that is not the case.

There might be a better way to denote that these are enhanced scopes, but "=
type" isn't quite right for that as it does imply a class or kind of thing =
(to which many particular things might belong), rather than a special or en=
hanced particular thing.


Eve: Regarding the sentence "Without a specific resource set identifier pat=
h component, the URI applies to the set of resource set descriptions alread=
y registered." in Section 2.3: I suspect this can just be deleted entirely.=
 It's redundant with the "List resource set registrations" bullet item just=
 below, which literally shows the {rsid} component of the path being absent=
. This is the only supported method in this API that has no {rsid} path com=
ponent.
Thomas: Resource set registration API:  If Alice (the RO) has already previ=
ously registered some resources at the AS, then Alice will already have a P=
AT token (and the AS knows about Alice, her PAT, her resource sets and scop=
es). If Alice comes back again with the same PAT and forgets to specificy t=
he path component, we assume the AS is smart enough to figure out which set=
s Alice is refering to. Does this help? (or does it still read weirdly).

These two explanations are very different. If Thomas's assessment is correc=
t, I would move that explanatory text up to the end of the paragraph starti=
ng with "The authorization server MUST present an API=85" and explain that =
the PAT can also be used to figure out the {rsid} for any requests where it=
 is left off (implying that the {rsid} component MAY be left off of any of =
the following API calls). Otherwise if Eve is correct and that additional c=
aveat is NOT meant to be there, I would suggest removing the phrase entirel=
y as it does seem to imply that {rsid} may be left off.


Regarding {rsreguri}: I do see it defined, in this same Section 2.3. Basica=
lly this notation is simply a device to allow for referring to a "resource =
set registration endpoint" (defined in the Terminology section) in the URIs=
 here that serve as method templates. Is there a better way to do this?

Yes, it is defined but not actually used to describe the API paths. The def=
inition is fine but if it is there it should be used; for example the "Crea=
te resource set description" path should change from "PUT /resource_set/{rs=
id}" to "PUT {rsreguri}/resource_set/{rid}".

--Amanda


Eve

On 27 Dec 2012, at 4:37 PM, Thomas Hardjono > wrote:

Thanks Amanda,
- Scope and types:  We went back and forth with regards to "scope type" and=
 finally just used "type" with the assumption that the reader would know wh=
at we mean by it (ie. context dependent).  However, we're very open to goin=
g back to the previous language.
- Resource set registration: yes that sentence does read weirdly, will fix =
:-)

- The {rsreguri} URI component is defined but never used: hmm yes you are c=
orrect. Will fix this.
Thank you again.
cheers,
/thomas/
__________________________________________
-----Original Message-----
From: Anganes, Amanda L [mailto:aanganes@mitre.org]
Sent: Thursday, December 27, 2012 4:57 PM
To: Thomas Hardjono; oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW:
New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
Hi Thomas,
Here is some initial feedback.
Introduction paragraph 2:
Remove duplicate "with": "the OpenID Provider (OP) component is a
specialized version of an OAuth authorization server that brokers
availability of user attributes by dealing *with with* an ecosystem of
attribute providers (APs)."
Section 1.2 Terminology:
This is more of a comment for the UMA WG in general: "scope type" is an
unfortunate term (which appears in the UMA core draft [1] as well - if
memory serves the term used to be just "scope" but I couldn't find a
diff reference for when that changed). Including "type" in the term
makes it sound like it refers to a class or kind of scope, which
doesn't seem to be what you mean. I understand that "scope" cannot be
used since it is already reserved by OAuth, but perhaps a better
synonym could be found and used instead?
2. Resource set registration
2nd sentence reads oddly. Change from "For any of the resource owner's
sets of resources this authorization server needs to be aware of, the
resource server MUST register these resource sets=8A" to "If this
authorization server needs to be aware of any of the resource sets, the
resource server MUST register those resource sets=8A"
2.2 Resource set descriptions
"scopes" and to refer to sets of "scope type"s and "type" to refer to
the class/kind of resource set this is add to the argument above that
"scope type" is a misleading term.
2.3 Resource set registration API
I don't understand what this sentence means: "Without a specific
resource set identifier path component, the URI applies to the set of
resource set descriptions already registered." Can you clarify?
The {rsreguri} URI component is defined but never used. It looks like
all of the "/resource_set" URIs should be prefaced with this component
throughout the following sections?
[1] https://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
--
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
781-271-3103
aanganes@mitre.org
On 12/27/12 2:24 PM, "Thomas Hardjono" > wrote:
Folks,
The OAuth 2.0 Resource Set Registration draft is essentially a generic
first phase of the User Managed Access (UMA) profile of OAuth2.0.
This
allows the RO to "register" (make known) to the AS the resources
he/she
wishes to share.
Looking forward to comments/feedback.
/thomas/
__________________________________________
-----Original Message-----
From: internet-drafts@ietf.org [mailto:int=
ernet-drafts@ietf.org]
Sent: Thursday, December 27, 2012 2:07 PM
To: Thomas Hardjono
Subject: New Version Notification for
draft-hardjono-oauth-resource-reg-00.txt
A new version of I-D, draft-hardjono-oauth-resource-reg-00.txt
has been successfully submitted by Thomas Hardjono and posted to the
IETF
repository.
Filename:        draft-hardjono-oauth-resource-reg
Revision:        00
Title:           OAuth 2.0 Resource Set Registration
Creation date:   2012-12-27
WG ID:           Individual Submission
Number of pages: 19
URL:
http://www.ietf.org/internet-drafts/draft-hardjono-oauth-resource-reg-
00.t
xt
Status:
http://datatracker.ietf.org/doc/draft-hardjono-oauth-resource-reg
Htmlized:
http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
Abstract:
  This specification defines a resource set registration mechanism
  between an OAuth 2.0 authorization server and resource server.  The
  resource server registers information about the semantics and
  discovery properties of its resources with the authorization
server.
The IETF Secretariat
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl



--_000_B61A05DAABADEA4EA2F19424825286FA1E673C27IMCMBX04MITREOR_
Content-Type: text/html; charset="windows-1250"
Content-ID: 
Content-Transfer-Encoding: quoted-printable









Hi Eve an=
d Thomas,

















Amanda, thanks for the lightning-fast comments back. A couple of addit=
ional notes on top of Thomas's response:







The "scope type" language is indeed new this time -- of cour=
se this whole modular spec is newly broken out, but the previous text from =
UMA's rev 05 still said "scope". (There's a new member in the JSO=
N description of a resource set that is called "type",
 but this is actually the resource set's type: different thing.) Maybe this=
 should just be changed back to "scope" and "scope descripti=
on", as we really do mean the same construct as in plain OAuth, althou=
gh here it's enhanced with a machine-readable description,
 and it's mappable to resource sets that have been explicitly identified. O=
ne thing we've been learning lately is that terminology impedance mismatche=
s are not worth the cost; this one is a recent back-sliding. :)









I think it would make much more sense to stick with "scope" =
and "scope description". I assumed that you were trying to avoid =
collisions with OAuth by changing it, but it sounds like that is not the ca=
se. 







There might be a better way to denote that these are enhanced scopes, =
but "type" isn't quite right for that as it does imply a class or=
 kind of thing (to which many particular things might belong), rather than =
a special or enhanced particular thing. 














Eve: Regarding the sentence "Without a specific resource set iden=
tifier path component, the URI applies to the set of resource set descripti=
ons already registered." in Section 2.3: I suspect this can just be de=
leted entirely. It's redundant with the "List
 resource set registrations" bullet item just below, which literally s=
hows the {rsid} component of the path being absent. This is the only suppor=
ted method in this API that has no {rsid} path component.








Thomas: Resource set registration API:  =
If Alice (the RO) has already previously registered some resources at the A=
S, then Alice will already have a PAT token (and
 the AS knows about Alice, her PAT, her resource sets and scopes). If Alice=
 comes back again with the same PAT and forgets to specificy the path compo=
nent, we assume the AS is smart enough to figure out which sets Alice is re=
fering to. Does this help? (or does
 it still read weirdly).









These two explanations are very different. If Thom=
as's assessment is correct, I would move that explanatory text up to the en=
d of the paragraph starting with "The
 authorization server MUST present an API=85" and explain that the PAT=
 can also be used to figure out the {rsid} for any requests where it is lef=
t off (implying that the {rsid} component MAY be left off of any of the fol=
lowing API calls). Otherwise if Eve is
 correct and that additional caveat is NOT meant to be there, I would sugge=
st removing the phrase entirely as it does seem to imply that {rsid} may be=
 left off. 
















Regarding {rsreguri}: I do see it defined, in this same Section 2.3. B=
asically this notation is simply a device to allow for referring to a "=
;resource set registration endpoint" (defined in the Terminology secti=
on) in the URIs here that serve as method
 templates. Is there a better way to do this?









Yes, it is defined but not actually used to describe the API paths. Th=
e definition is fine but if it is there it should be used; for example the =
"Create resource set description" path should change from "P=
UT /resource_set/{rsid}" to "PUT {rsreguri}/resource_set/{rid}&qu=
ot;.







--Amanda














Eve






On 27 Dec 2012, at 4:37 PM, Thomas Hardjono <hardjono@mit.edu> wrote:









Thanks Amanda,




- Scope and types:  We went back and forth with regards to &=
quot;scope type" and finally just used "type" with the assum=
ption that the reader would know what we mean by it (ie. context dependent)=
.  However, we're very open to going back to the previous languag=
e.




- Resource set registration: yes that sentence does read weirdly, will=
 fix :-)











- The {rsreguri} URI component is defined but never used: hmm yes you =
are correct. Will fix this.






Thank you again.




cheers,




/thomas/




__________________________________________








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


From: Anganes, Amanda L [mailto:=
aanganes@mitre.org]


Sent: Thursday, December 27, 2012 4:57 PM


To: Thomas Hardjono; oauth@ietf.org<=
/a>


Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW:

New Version Notification for draft-hardjono-oauth-resource-reg-00.txt<=
/div>



Hi Thomas,




Here is some initial feedback.




Introduction paragraph 2:




Remove duplicate "with": "the OpenID Provider (OP) comp=
onent is a


specialized version of an OAuth authorization server that brokers

availability of user attributes by dealing *with with* an ecosystem of=



attribute providers (APs)."




Section 1.2 Terminology:




This is more of a comment for the UMA WG in general: "scope type&=
quot; is an


unfortunate term (which appears in the UMA core draft [1] as well - if=



memory serves the term used to be just "scope" but I couldn'=
t find a


diff reference for when that changed). Including "type" in t=
he term


makes it sound like it refers to a class or kind of scope, which


doesn't seem to be what you mean. I understand that "scope" =
cannot be


used since it is already reserved by OAuth, but perhaps a better


synonym could be found and used instead?




2. Resource set registration




2nd sentence reads oddly. Change from "For any of the resource ow=
ner's


sets of resources this authorization server needs to be aware of, the<=
/div>

resource server MUST register these resource sets=8A" to "If=
 this


authorization server needs to be aware of any of the resource sets, th=
e


resource server MUST register those resource sets=8A"




2.2 Resource set descriptions




"scopes" and to refer to sets of "scope type"s and=
 "type" to refer to


the class/kind of resource set this is add to the argument above that<=
/div>

"scope type" is a misleading term.




2.3 Resource set registration API




I don't understand what this sentence means: "Without a specific<=
/div>

resource set identifier path component, the URI applies to the set of<=
/div>

resource set descriptions already registered." Can you clarify?



The {rsreguri} URI component is defined but never used. It looks like<=
/div>

all of the "/resource_set" URIs should be prefaced with this=
 component


throughout the following sections?







--


Amanda Anganes


Info Sys Engineer, G061


The MITRE Corporation


781-271-3103







On 12/27/12 2:24 PM, "Thomas Hardjono" <hardjono@MIT.EDU> wrote:






Folks,




The OAuth 2.0 Resource Set Registration draft is essentially a generic=



first phase of the User Managed Access (UMA) profile of OAuth2.0.



This




allows the RO to "register" (make known) to the AS the resou=
rces




he/she




wishes to share.




Looking forward to comments/feedback.




/thomas/




__________________________________________






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



Sent: Thursday, December 27, 2012 2:07 PM


To: Thomas Hardjono


Subject: New Version Notification for


draft-hardjono-oauth-resource-reg-00.txt






A new version of I-D, draft-hardjono-oauth-resource-reg-00.txt


has been successfully submitted by Thomas Hardjono and posted to the



IETF




repository.




Filename:        draft-hardjon=
o-oauth-resource-reg


Revision:        00


Title:           OAu=
th 2.0 Resource Set Registration


Creation date:   2012-12-27


WG ID:           Ind=
ividual Submission


Number of pages: 19


URL:





00.t




xt


Status:



Htmlized:


http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00





Abstract:


  This specification defines a resource set registration mec=
hanism


  between an OAuth 2.0 authorization server and resource ser=
ver.  The


  resource server registers information about the semantics =
and


  discovery properties of its resources with the authorizati=
on




server.












The IETF Secretariat




_______________________________________________


OAuth mailing list










_______________________________________________


OAuth mailing list
















Eve Maler          &=
nbsp;           &nbs=
p;           http://www.xmlgrrl.com/blog


+1 425 345 6756        &nb=
sp;            =
    
http://www.twitter.com/xmlgrrl
















--_000_B61A05DAABADEA4EA2F19424825286FA1E673C27IMCMBX04MITREOR_--

From bcampbell@pingidentity.com  Fri Dec 28 05:59:56 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56AB321F85C7 for ; Fri, 28 Dec 2012 05:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.917
X-Spam-Level: 
X-Spam-Status: No, score=-4.917 tagged_above=-999 required=5 tests=[AWL=1.060,  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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfvJktdPAIjd for ; Fri, 28 Dec 2012 05:59:55 -0800 (PST)
Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id CDFE921F853E for ; Fri, 28 Dec 2012 05:59:54 -0800 (PST)
Received: from mail-ie0-f200.google.com ([209.85.223.200]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKUN2l2gvjxxVz76QohPfDvmDVml1TZRKR@postini.com; Fri, 28 Dec 2012 05:59:54 PST
Received: by mail-ie0-f200.google.com with SMTP id k13so45768131iea.11 for ; Fri, 28 Dec 2012 05:59:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=22buxQDIlGbHFEIXymsYCwDS0IXsLmkqvV8m7Oj7bSQ=; b=GG7YcMYPjNcSf3QtC06ZW5uU3W2KwDd8JroN/x/H8oymP38eYsUtjoScKdnyyG7OWA ETTjoWcG+Y1aqxluznMbCyaIS3+GNtR46NuZ9x/NwHWEyAFKtnf7f7wDqbBpBg9VXG3Q WGpvo4XmQlsRXbTDX8NNhuUk5ZfeuTekp/2eRxWwPR93jGRyAeGyesV+nKfgWOMk+T6v fhGsr3pilWfea+Dc0x2xWxhvqEwoH3bFeSI3VIs9s8SIX5I9MYzlyPmxbkI8ZNzeZCR/ dMkbmPWizge7xOG+KTOHczVsqla+FVtvyv/gL4jbW3GiSmYWF+32rIHes1k0TvpJ5+KY n4gQ==
X-Received: by 10.50.53.196 with SMTP id d4mr24760219igp.88.1356703194302; Fri, 28 Dec 2012 05:59:54 -0800 (PST)
Received: by 10.50.53.196 with SMTP id d4mr24760215igp.88.1356703194152; Fri, 28 Dec 2012 05:59:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.17.134 with HTTP; Fri, 28 Dec 2012 05:59:24 -0800 (PST)
In-Reply-To: <76EAF572-1701-4FB6-AA20-21831D8055D7@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>  <8b1f49ba29404f349af3dc3abb2878e4@BY2PR03MB041.namprd03.prod.outlook.com> <76EAF572-1701-4FB6-AA20-21831D8055D7@ve7jtb.com>
From: Brian Campbell 
Date: Fri, 28 Dec 2012 06:59:24 -0700
Message-ID: 
To: John Bradley 
Content-Type: multipart/alternative; boundary=f46d042fdeb2f4009c04d1ea1308
X-Gm-Message-State: ALoCoQm4xQekeIaveXh4IogGvdzHNER44R/DQ4H1ZR7kEJl9SGjjD7/YZ6Dl2BkEEINc0oeg9HgtdwVEUpU2Q6jhEZYKJjHiTbaW+u6r1jXoJHYrg+xCSIdQfNgiD6q++kEmcNcdm5aS
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 13:59:56 -0000

--f46d042fdeb2f4009c04d1ea1308
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I believe John meant to refer to Google's adding of the *cid* claim rather
than the *prn* claim.


On Thu, Dec 27, 2012 at 5:53 PM, John Bradley  wrote:

> The discussion on the Connect call was that audience could be a literal o=
r
> an array.
>
> example
>
> "aud":["http://audiance1.com","http://audiance2.com"]
>
> In some cases the token may want to have more than a single audience.
> (anthropomorphic license)
>
> in the simple case it would still be
> "aud":"http://audiance1.com"
>
> While dynamic typing of variables is not my favourite thing in principal,
> I am assured that this is common JSON syntax that people can deal with.
>
> The idea is to standardize this rather than everyone coming up with their
> own way around the restriction as google did by adding the prn claim.
>
> At least this way if you only trust tokens with yourself as the audience
> you have a easy way to check.
>
> John B.
>
> On 2012-12-27, at 7:57 PM, Anthony Nadalin  wrote:
>
> What do you mean by multi-valued and what are the semantics of multi-vale=
 ?
> ****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *John Bradley
> *Sent:* Thursday, December 27, 2012 5:32 AM
> *To:* Mike Jones
> *Cc:* oauth@ietf.org
> *Subject:* Re: [OAUTH-WG] Must the Audience value in the Assertions Spec
> be a URI?****
> ** **
> Agreed.****
> ** **
> We need to clarify that the value of the audience claim can be multi
> valued as well. ****
> ** **
> John B.****
> ** **
> On 2012-12-26, at 10:43 PM, Mike Jones 
> wrote:****
>
>
> ****
>
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 cur=
rently
> says:****
>  ****
>
>    Audience  A URI that identifies the party intended to process the****
>
>       assertion.  The audience SHOULD be the URL of the Token Endpoint***=
*
>
>       as defined in Section 3.2  of OAuth 2.0 [RFC6749 ].****
>
>  ****
>
> I think that =93URI=94 should be changed to =93value=94, since audience v=
alues in
> general need not be URIs.  In particular, in some contexts OAuth client_i=
d
> values are used as audience values, and they need not be URIs.  Also, SAM=
L
> allows multiple audiences (and indeed, the OAuth SAML profile is written =
in
> terms of =93an audience value=94 =96 not =93the audience value=94), and s=
o the
> generic Assertions spec should do likewise.****
>  ****
> Thus, I would propose changing the text above to the following:****
>  ****
>
>    Audience  A value that identifies the parties intended to process the*=
***
>
>       assertion.  An audience value SHOULD be the URL of the Token Endpoi=
nt****
>
>       as defined in Section 3.2  of OAuth 2.0 [RFC6749 ].****
>
>  ****
>                                                             -- 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
>
>

--f46d042fdeb2f4009c04d1ea1308
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


I believe John meant to refer to Google's adding of th=
e cid claim rather than the prn claim.


On Thu, Dec 27, 2012 at 5:=
53 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:



The disc=
ussion on the Connect call was that audience could be a literal or an array=
.



example





In some cases the token may want to have more than a si=
ngle audience. =A0
(anthropomorphic license)

=

in the simple case it would still be
"aud":"<=
a href=3D"http://audiance1.com" target=3D"_blank">http://audiance1.com&=
quot;




While dynamic typing of variables is not my favourite t=
hing in principal, I am assured that this is common JSON syntax that people=
 can deal with.

The idea is to standardize this ra=
ther than everyone coming up with their own way around the restriction as g=
oogle did by adding the prn claim.




At least this way if you only trust tokens with yoursel=
f as the audience you have a easy way to check.

Jo=
hn B.

On 2012-12-=
27, at 7:57 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:






What do you mean by multi-valued and wh=
at are the semantics of multi-vale ?





=
From:<=
/b>=A0<=
/span>oauth-bou=
nces@ietf.org [mailto:oauth=
-bounces@ietf.org=
]=A0On Behalf Of=A0John Bradley


Sent:=A0Thursday, December 27, 2012 5:32 AM
To:=A0Mike Jones
Cc:=A0oauth@ietf.org
Subject:=A0Re: [OAUTH-WG] Must the Audience value in the Assertions Spec =
be a URI?



=A0


Agreed.
=A0


We need to clarify that the value of the audience claim can be multi valued=
 as well.=A0
=
=A0



John B.


=A0
On 2012-12-26, at 1=
0:43 PM, Mike Jones <Michael.Jone=
s@microsoft.com> wrote:





=A0

=A0=A0 Audience=A0 A URI that identifies the party intend=
ed to process the

=A0=A0=A0=A0=A0 assertion.=A0 The audience SHOULD be the =
URL of the Token Endpoint

=A0=A0=A0=A0=A0 as defined in Section 3.2 of OAuth 2.0 [RFC6749].



=A0=



I think that =
=93URI=94 should be changed to =93value=94, since audience values in genera=
l need not be URIs.=A0 In particular, in some contexts OAuth client_id valu=
es are used as audience values, and they need not be URIs.=A0 Also, SAML al=
lows multiple audiences (and indeed, the OAuth SAML profile is written in t=
erms of =93an audience value=94 =96 not =93the audience value=94), and so t=
he generic Assertions spec should do likewise.



=A0


Thus, I would=
 propose changing the text above to the following:


=A0=

=A0=A0 Audience=A0 A =
value that identifies the parties intended to process the



=A0=A0=A0=A0=A0 assertion.=A0 An audience va=
lue SHOULD be the URL of the Token Endpoint



=A0=A0=A0=A0=A0 as defined in Section 3.2 of OAuth 2.0 [RFC6749].



=A0


=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=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=

______________________________________=
_________


OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut=
h





_________________=
______________________________



OAuth mailing list

OAuth@ietf.org

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





--f46d042fdeb2f4009c04d1ea1308--

From ve7jtb@ve7jtb.com  Fri Dec 28 06:30:17 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E6A21F8BC9 for ; Fri, 28 Dec 2012 06:30:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.357
X-Spam-Level: 
X-Spam-Status: No, score=-3.357 tagged_above=-999 required=5 tests=[AWL=0.241,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ya2shWRQbiMX for ; Fri, 28 Dec 2012 06:30:12 -0800 (PST)
Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9229D21F861A for ; Fri, 28 Dec 2012 06:30:12 -0800 (PST)
Received: by mail-gg0-f172.google.com with SMTP id r1so1703048ggn.31 for ; Fri, 28 Dec 2012 06:30:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=Q4+rTPUh/eEX9SzSK6szjUg2mXqfSbtR2od5KEbXjAo=; b=peIddG8/zFO1SgxQZKGYbQcc3se/QpBa8FnqrZ5CP5LpJVLnsrudtnIdp3QjpHWgsd liBAVdlCK69Y0cYrPEObeqBfZWAUOHE3B5Ba48+sL8rmYGPxDYzut8vS/WVhKl64JiaZ kMELDhoLuZCMB/XBnCBGF9LGqVEsH1BugaUq0dZq93iRrHWmqcRiFd6beGh1HQRjhtXJ WfXvIfHt8H88tcURDjWMiw0tcghHIkgy8y3XE//jMPNxl5D0YIGGi6KqrmUakU8azwmr 7j4uqljyUdw4icZg/7FCOIeL8rEA0XZ2hilBNAxZQYWZMkTjAICDqlIH57IiITgAV7y8 0lZg==
X-Received: by 10.236.124.49 with SMTP id w37mr30205564yhh.39.1356705011913; Fri, 28 Dec 2012 06:30:11 -0800 (PST)
Received: from [192.168.1.211] (190-20-5-108.baf.movistar.cl. [190.20.5.108]) by mx.google.com with ESMTPS id x41sm30512506yhg.9.2012.12.28.06.30.08 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Dec 2012 06:30:10 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_478BAD34-A256-48AD-A374-DC2F6FE16301"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: 
Date: Fri, 28 Dec 2012 11:30:01 -0300
Message-Id: <6E76F446-33D5-498C-8595-751C272C5271@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B1680429673943669A88C1@TK5EX14MBXC283.redmond.corp.microsoft.com>  <8b1f49ba29404f349af3dc3abb2878e4@BY2PR03MB041.namprd03.prod.outlook.com> <76EAF572-1701-4FB6-AA20-21831D8055D7@ve7jtb.com> 
To: Brian Campbell 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQkIoGTjPlulQ1lrJD/yHDLg5x7UcZ+0Pri24fDra4oqi1s/hYwM88TrdVdwRv0RozghlCmC
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a URI?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 14:30:17 -0000

--Apple-Mail=_478BAD34-A256-48AD-A374-DC2F6FE16301
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Sorry yes, Google calls it cid.   Mike's TLA theory for JWT, JWE, JWS , =
JWK can be confusing at times.

On 2012-12-28, at 10:59 AM, Brian Campbell  =
wrote:

> I believe John meant to refer to Google's adding of the cid claim =
rather than the prn claim.
>=20
>=20
> On Thu, Dec 27, 2012 at 5:53 PM, John Bradley  =
wrote:
> The discussion on the Connect call was that audience could be a =
literal or an array.
>=20
> example
>=20
> "aud":["http://audiance1.com","http://audiance2.com"]
>=20
> In some cases the token may want to have more than a single audience. =20=

> (anthropomorphic license)
>=20
> in the simple case it would still be
> "aud":"http://audiance1.com"
>=20
> While dynamic typing of variables is not my favourite thing in =
principal, I am assured that this is common JSON syntax that people can =
deal with.
>=20
> The idea is to standardize this rather than everyone coming up with =
their own way around the restriction as google did by adding the prn =
claim.
>=20
> At least this way if you only trust tokens with yourself as the =
audience you have a easy way to check.
>=20
> John B.
>=20
> On 2012-12-27, at 7:57 PM, Anthony Nadalin  =
wrote:
>=20
>> What do you mean by multi-valued and what are the semantics of =
multi-vale ?
>> =20
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of John Bradley
>> Sent: Thursday, December 27, 2012 5:32 AM
>> To: Mike Jones
>> Cc: oauth@ietf.org
>> Subject: Re: [OAUTH-WG] Must the Audience value in the Assertions =
Spec be a URI?
>> =20
>> Agreed.
>> =20
>> We need to clarify that the value of the audience claim can be multi =
valued as well.=20
>> =20
>> John B.
>> =20
>> On 2012-12-26, at 10:43 PM, Mike Jones  =
wrote:
>>=20
>>=20
>> http://tools.ietf.org/html/draft-ietf-oauth-assertions-08#section-5.1 =
currently says:
>> =20
>>=20
>>    Audience  A URI that identifies the party intended to process the
>>=20
>>       assertion.  The audience SHOULD be the URL of the Token =
Endpoint
>>=20
>>       as defined in Section 3.2 of OAuth 2.0 [RFC6749].
>> =20
>> I think that =93URI=94 should be changed to =93value=94, since =
audience values in general need not be URIs.  In particular, in some =
contexts OAuth client_id values are used as audience values, and they =
need not be URIs.  Also, SAML allows multiple audiences (and indeed, the =
OAuth SAML profile is written in terms of =93an audience value=94 =96 =
not =93the audience value=94), and so the generic Assertions spec should =
do likewise.
>> =20
>> Thus, I would propose changing the text above to the following:
>> =20
>>    Audience  A value that identifies the parties intended to process =
the
>>       assertion.  An audience value SHOULD be the URL of the Token =
Endpoint
>>       as defined in Section 3.2 of OAuth 2.0 [RFC6749].
>> =20
>>                                                             -- Mike
>> =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=_478BAD34-A256-48AD-A374-DC2F6FE16301
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Sorry =
yes, Google calls it cid.   Mike's TLA theory for JWT, JWE, JWS , =
JWK can be confusing at times.

On 2012-12-28, at 10:59 =
AM, Brian Campbell <bcampbell@pingidentity.com&=
gt; wrote:

I believe John meant to refer to Google's =
adding of the cid claim rather than the prn =
claim.


On Thu, Dec 27, 2012 at 5:53 PM, John Bradley =
<ve7jtb@ve7jtb.com> wrote:



The discussion on the Connect call was =
that audience could be a literal or an array.



example





In some cases the token may want to have more than a =
single audience.  
(anthropomorphic =
license)

in the simple case it would still =
be




While dynamic typing of variables is not my =
favourite thing in principal, I am assured that this is common JSON =
syntax that people can deal with.

The idea is =
to standardize this rather than everyone coming up with their own way =
around the restriction as google did by adding the prn claim.




At least this way if you only trust tokens with =
yourself as the audience you have a easy way to =
check.

John B.

On 2012-12-27, at 7:57 PM, =
Anthony Nadalin <tonynad@microsoft.com> wrote:






What do you mean by multi-valued and what are the semantics of =
multi-vale ?





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


Sent: Thursday, December 27, 2012 5:32 =
AM
To: Mike =
Jones
Cc: oauth@ietf.org
Subject: =
Re: [OAUTH-WG] Must the Audience value in the Assertions Spec be a =
URI?



 


Agreed.
 


We need to clarify that the value of the audience claim can be multi =
valued as well. 
 



John =
B.


 
On =
2012-12-26, at 10:43 PM, Mike Jones <Michael.Jones@microsoft.com> =
wrote:





 
   Audience  A URI that identifies the =
party intended to process the
      assertion.  The =
audience SHOULD be the URL of the Token Endpoint
      as defined in Section 3.2 of =
OAuth 2.0 [RFC6749].



 


I think =
that =93URI=94 should be changed to =93value=94, since audience values =
in general need not be URIs.  In particular, in some contexts OAuth =
client_id values are used as audience values, and they need not be =
URIs.  Also, SAML allows multiple audiences (and indeed, the OAuth =
SAML profile is written in terms of =93an audience value=94 =96 not =93the=
 audience value=94), and so the generic Assertions spec should do =
likewise.



 


Thus, I =
would propose changing the text above to the =
following:


 
   Audience  A value that identifies the =
parties intended to process the



      assertion.  An audience =
value SHOULD be the URL of the Token Endpoint



      as defined in Section 3.2 of =
OAuth 2.0 [RFC6749].



 


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


 
______________=
_________________________________


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





_______________________________________________



OAuth mailing list

OAuth@ietf.org

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






=

--Apple-Mail=_478BAD34-A256-48AD-A374-DC2F6FE16301--

From jricher@mitre.org  Fri Dec 28 07:12:18 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EFE21F8BC9 for ; Fri, 28 Dec 2012 07:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.468
X-Spam-Level: 
X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDyq1IBQEDfD for ; Fri, 28 Dec 2012 07:12:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id E058E21F879E for ; Fri, 28 Dec 2012 07:12:17 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 556C41F0A36; Fri, 28 Dec 2012 10:12:17 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3F1061F0A33; Fri, 28 Dec 2012 10:12:17 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 28 Dec 2012 10:12:16 -0500
Message-ID: <50DDB655.1010609@mitre.org>
Date: Fri, 28 Dec 2012 10:10:13 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Torsten Lodderstedt 
References: <50D4DF81.4020101@peter.de> <50D9A7F1.8090506@lodderstedt.net>
In-Reply-To: <50D9A7F1.8090506@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------070909040406060205000906"
X-Originating-IP: [129.83.31.58]
Cc: Peter Mauritius , OAuth WG 
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 15:12:18 -0000

--------------070909040406060205000906
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Sounds reasonable to me.

  -- Justin

On 12/25/2012 08:19 AM, Torsten Lodderstedt wrote:
> Hi Peter,
>
> your proposal sounds reasonable.
>
> Since it involves a change to the interface spec (400 instead of 403 
> in case of unauthorized access) I would like to ask the working group 
> for feedback.
>
> What do you think? I especially would like to gain feedback from 
> implementors of the draft (e.g. Marius, Chuck, Justin).
>
> regards,
> Torsten.
>
> Am 21.12.2012 23:15, schrieb Peter Mauritius:
>> During the last week I had the chance to implement the non optional 
>> features of the token revokation draft. I would be glad if the 
>> document would get a closer connection to the refrenced RFC6749 
>> regarding the error handling.
>>
>> The draft states to use HTTP status 401 and 403 for certain error 
>> conditions. RFC6749 declares this as optional (OK, not for the 
>> Authorization header). The implemation of the token revokation 
>> endpoint in conjunction with a tokens endpoint would be much easier 
>> if there is a single way to handle exceptions which conforms to RFC6749.
>>
>> Therefore I want to suggest to replace
>>
>>> Status code 401 indicates a
>>>     failed client authentication, whereas a status code 403 is used if
>>>     the client is not authorized to revoke the particular token.  For all
>>>     other error conditions, a status code 400 is used along with an error
>>>     response as defined insection 5.2  . of [RFC6749  ].
>> with
>>
>>     The error presentation conforms to the defintion in section 5.2
>>     of [RFC6749].
>>
>> To express the status code 403 I suggest to use the error code 
>> "unauthorized_client" of RFC6749 in conjunction with status code 400. 
>> The additional error codes defined in the draft will remain of course.
>>
>> Happy apocalypse ;-)
>>   Peter Mauritius
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    
Sounds reasonable to me.

      

       -- Justin

      

      On 12/25/2012 08:19 AM, Torsten Lodderstedt wrote:

    

    

      
      Hi Peter,

      

      your proposal sounds reasonable. 

      

      Since it involves a change to the interface spec (400 instead of
      403 in case of unauthorized access) I would like to ask the
      working group for feedback.

      

      What do you think? I especially would like to gain feedback from
      implementors of the draft (e.g. Marius, Chuck, Justin).

      

      regards,

      Torsten.

      

      
Am 21.12.2012 23:15, schrieb Peter
        Mauritius:

      

      

        During the last week I had the chance to implement the non
        optional features of the token revokation draft. I would be glad
        if the document would get a closer connection to the refrenced 
        RFC6749 regarding the error handling. 

        

        The draft states to use HTTP status 401 and 403 for certain
        error conditions. RFC6749 declares this as optional (OK, not for
        the Authorization header). The implemation of the token
        revokation endpoint in conjunction with a tokens endpoint would
        be much easier if there is a single way to handle exceptions
        which conforms to RFC6749.

        

        Therefore I want to suggest to replace 

        

        

          
Status code 401 indicates a
   failed client authentication, whereas a status code 403 is used if
   the client is not authorized to revoke the particular token.  For all
   other error conditions, a status code 400 is used along with an error
   response as defined in section 5.2. of [RFC6749].  

        

        with

        
The error presentation conforms to the defintion in
          section 5.2 of [RFC6749]. 

        

        To express the status code 403 I suggest to use the error code
        "unauthorized_client" of RFC6749 in conjunction with status code
        400. The additional error codes defined in the draft will remain
        of course.

        

        Happy apocalypse ;-)

          Peter Mauritius

        

        

        

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


      

      

      

      

      

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


    

    

  


--------------070909040406060205000906--

From jricher@mitre.org  Fri Dec 28 07:17:48 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B6321F87FA for ; Fri, 28 Dec 2012 07:17:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.474
X-Spam-Level: 
X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.124,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ41kKMTahTw for ; Fri, 28 Dec 2012 07:17:46 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 729F721F86D5 for ; Fri, 28 Dec 2012 07:17:46 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DD1C75310389; Fri, 28 Dec 2012 10:17:45 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id CC91B5310387; Fri, 28 Dec 2012 10:17:45 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 28 Dec 2012 10:17:45 -0500
Message-ID: <50DDB79D.3010609@mitre.org>
Date: Fri, 28 Dec 2012 10:15:41 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Torsten Lodderstedt 
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net> <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com> <50DB2269.6020501@lodderstedt.net>
In-Reply-To: <50DB2269.6020501@lodderstedt.net>
Content-Type: multipart/alternative; boundary="------------090700080607030706010408"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 15:17:48 -0000

--------------090700080607030706010408
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I'm fine with this approach, though I'd leave in a RECOMMEND for the 
refresh token -> access token cascading delete, since it will be a 
common one.

  -- Justin

On 12/26/2012 11:14 AM, Torsten Lodderstedt wrote:
> Hi John,
>
> thanks for your feedback.
>
> After having thought through this topic again I came to the conclusion 
> that I want to have a simple spec, which doesn't unnessarily restricts 
> implementations. OAuth leaves so much freedom to implementors (for 
> good reasons), which we should preserve.
>
> What does this mean? I would like to focus on the revocation of the 
> token actually passed to the revocation endpoint and leave the impact 
> on other related tokens and the authorization itself to the 
> authorization server's policy. The authorization server may 
> incorporate the client type into its revocation policy.
>
> My base assumption is that a client must be prepared to handle 
> invalidation of tokens at any time. So from an interoperability 
> perspective, it's not necessary to dictate a certain revocation policy 
> to authorization servers.
>
> Current text:
>
> In the next step, the authorization server invalidates the token and 
> the respective authorization. If the particular token is a refresh 
> token and the authorization server supports the revocation of access 
> tokens, then the authorization server SHOULD also invalidate all 
> access tokens based on the same authorization (seeImplementation Note 
> <#impl>).
>
> The client MUST NOT use the token again after revocation.
>
> Proposal:
>
>         In the next step, the authorization server invalidates the 
> token. The client MUST NOT use this token again after revocation.
>
>         Depending on the authorization server's revocation policy, the 
> revocation of a particular token may cause the revocation of related 
> tokens and the underlying authorization.
>         If the particular token is a refresh token and the 
> authorization server supports the revocation of access tokens, then 
> the authorization server SHOULD also invalidate all access tokens 
> based on         the same authorization (seeImplementation Note <#impl>).
>
> Thoughts?
>
> regards,
> Torsten.
>
> Am 26.12.2012 15:38, schrieb John Bradley:
>> We don't want to share grant information across multiple instances of public client.
>>
>> However we don't necessarily want to preclude multiple instances of a private client,  Though how the AS would tell them apart is a interesting side question.
>>
>>  From a revocation point of view if you revoke the grant for one instance of a client you revoke it for all, though for a public client the grant is not doing anything anyway as the AS shield not be pre approving based on the grant.
>>
>> There are still some open questions about an extension to identify client instances, though personally I prefer to have each instance with it's own client ID.
>>
>> The language around grants has always been a bit philosophical for my taste.
>>
>> If I recall correctly in the code flow the code is the representation of the grant.  In  the implicit flow the grant is implicit in the access token.
>> What construct (if any in the implicit case) is stored in the AS to represent this is mostly left to the imagination of the implementer.
>>
>> John B.
>>
>>
>> On 2012-12-25, at 8:24 AM, Torsten Lodderstedt  wrote:
>>
>>> Hi Mark,
>>>
>>> thanks for reviewing the draft. Comments inline.
>>>
>>> Am 02.12.2012 18:27, schrieb Mark Wubben:
>>>> The draft relies heavily on the definition "access grant", but no definition is provided in the draft or RFC 6749. It's been my interpretation that an "access grant" is the *fact* that a resource owner has authorized a client (potentially scoped) access to the protected resources. Once access is granted in this manner, further access tokens may be obtained without explicit permission by the end-user. That is, in the Protocol Flow there is no user input between steps A and B.
>>> That's correct.
>>>
>>>> In "1. Introduction" it is stated:
>>>>
>>>>>   A
>>>>>     revocation request will invalidate the actual token and, if
>>>>>     applicable, other tokens based on the same access grant and the
>>>>>     access grant itself.
>>>> then, in "2. Token Revocation":
>>>>
>>>>>   In the next step, the authorization server invalidates the token and
>>>>>     the respective access grant.  If the particular token is a refresh
>>>>>     token and the authorization server supports the revocation of access
>>>>>     tokens, then the authorization server SHOULD also invalidate all
>>>>>     access tokens based on the same access grant
>>>> This implies that an access grant only applies to an app authorized on a single device. If an app is installed on multiple devices and the access grant is shared between both instances, revoking device A's access token results in the unexpected revocation of device B's token.
>>> You raised an interesting point. Is it desirable to share an access grant among different client instances? I would like to discuss this topic in the working group.
>>>
>>> If we assume it is desirable, how would the authorization process look alike?
>>>
>>> I would assume that as result of the authorization process of the 1st client instance, the authorization server stores an access grant, which is identified by the client_id and the user_id of the resource owner. Moreover, it creates a refresh token, which the 1st client instance uses to obtain new access tokens. As this client is public, the refresh token is the credential the intial client uses to prove its identity.
>>>
>>> How does the 2nd client instance join the party? I would assume the 2nd client to initiate another code grant type flow (using the same client_id as the 1st client). I see two ways the authorization server could process this process:
>>>
>>> 1) After authenticating the resource owner, the authorization server finds the existing access grant for the client_id/user_id combination and automatically issues tokens w/o further user consent. Since the authorization server cannot authenticate the client_id, a malicious client could obtain and abuse the access grant of the legitimate client. That's why the security considerations of the core spec (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:
>>>
>>> The authorization server SHOULD NOT process repeated authorization
>>>    requests automatically (without active resource owner interaction)
>>>    without authenticating the client or relying on other measures to
>>>    ensure the repeated request comes from the original client and not an
>>>    impersonator.
>>>
>>> Validating the redirect URI won't help that much, since this URI is typically device local (custom scheme or localhost).
>>>
>>> 2) The authorization server asks the resource owner for user consent and issues another pair of access/refresh token to the 2nd client. In this case, why would one bind this tokens to the already existing access grant? This would limit the resource owners capability to revoke grants for particular instances. I would rather create another access grant.
>>>
>>> Based on this thoughts I think it is not desirable to share an access grant among different client instances.
>>>
>>> What do others think?
>>>
>>>> If "access grant" could be defined as "an authorization issued to the  client, based on the single use of an Authorization Grant" it becomes clear than only the tokens spawning from the app's authorization on device A should be revoked.
>>> I would like to adopt your proposal if the WG agrees.
>>>
>>>> ---
>>>>
>>>> I spotted a typo in "3. Implementation Note":
>>> Thanks. Fixed.
>>>
>>> regards,
>>> Torsten.
>>>>> Whether this is an viable option or
>>>>>     whether access token revocation is required should be decided based
>>>>>     on the service provider's risk analysis.
>>>> "an viable option" should be "a viable option".
>>>>
>>>> On 24 Nov 2012, at 18:13, Hannes Tschofenig  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> this is a working group last call for draft-ietf-oauth-revocation-03 on "Token Revocation".  The draft is available here:
>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>>>>>
>>>>> Please send you comments to the OAuth mailing list by December 10, 2012.
>>>>>
>>>>> Thanks,
>>>>> Hannes & Derek
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> --
>>>> Mark Wubben
>>>>
>>>> http://novemberborn.net
>>>> http://twitter.com/novemberborn
>>>>
>>>> _______________________________________________
>>>> OAuth mailing 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


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


  
    
  
  
    
I'm fine with this approach, though I'd
      leave in a RECOMMEND for the refresh token -> access token
      cascading delete, since it will be a common one. 

      

       -- Justin

      

      On 12/26/2012 11:14 AM, Torsten Lodderstedt wrote:

    

    

      
      Hi John,

      

      thanks for your feedback. 

      

      After having thought through this topic again I came to the
      conclusion that I want to have a simple spec, which doesn't
      unnessarily restricts implementations. OAuth leaves so much
      freedom to implementors (for good reasons), which we should
      preserve.

      

      What does this mean? I would like to focus on the revocation of
      the token actually passed to the revocation endpoint and leave the
      impact on other related tokens and the authorization itself to the
      authorization server's policy. The authorization server may
      incorporate the client type into its revocation policy.  

      

      My base assumption is that a client must be prepared to handle
      invalidation of tokens at any time. So from an interoperability
      perspective, it's not necessary to dictate a certain revocation
      policy to authorization servers.  

      

      Current text:

      

      
In the next step, the
        authorization server invalidates the token and the respective
        authorization. If the particular token is a refresh token and
        the authorization server supports the revocation of access
        tokens, then the authorization server SHOULD also invalidate all
        access tokens based on the same authorization (see Implementation Note).

      
The client MUST NOT use the
        token again after revocation.

      Proposal:

      

              In the next step, the authorization server invalidates the
      token. The client MUST NOT use this token again after revocation.
      

       

              Depending on the authorization server's revocation policy,
      the revocation of a particular token may cause the revocation of
      related tokens and the underlying authorization. 

              If the particular token is a refresh token and the
      authorization server supports the revocation of access tokens,
      then the authorization server SHOULD also invalidate all access
      tokens based on         the same authorization (see Implementation Note).

      

      Thoughts?

      

      regards,

      Torsten.

      

      
Am 26.12.2012 15:38, schrieb John
        Bradley:

      

      

        
We don't want to share grant information across multiple instances of public client.

However we don't necessarily want to preclude multiple instances of a private client,  Though how the AS would tell them apart is a interesting side question.

>From a revocation point of view if you revoke the grant for one instance of a client you revoke it for all, though for a public client the grant is not doing anything anyway as the AS shield not be pre approving based on the grant.

There are still some open questions about an extension to identify client instances, though personally I prefer to have each instance with it's own client ID.

The language around grants has always been a bit philosophical for my taste.   

If I recall correctly in the code flow the code is the representation of the grant.  In  the implicit flow the grant is implicit in the access token.
What construct (if any in the implicit case) is stored in the AS to represent this is mostly left to the imagination of the implementer.

John B.


On 2012-12-25, at 8:24 AM, Torsten Lodderstedt <torsten@lodderstedt.net> wrote:



        

          
Hi Mark,

thanks for reviewing the draft. Comments inline.

Am 02.12.2012 18:27, schrieb Mark Wubben:


          

            
The draft relies heavily on the definition "access grant", but no definition is provided in the draft or RFC 6749. It's been my interpretation that an "access grant" is the *fact* that a resource owner has authorized a client (potentially scoped) access to the protected resources. Once access is granted in this manner, further access tokens may be obtained without explicit permission by the end-user. That is, in the Protocol Flow there is no user input between steps A and B.


          

          
That's correct.



          

            
In "1. Introduction" it is stated:



            

              
 A
   revocation request will invalidate the actual token and, if
   applicable, other tokens based on the same access grant and the
   access grant itself.


            

            
then, in "2. Token Revocation":



            

              
 In the next step, the authorization server invalidates the token and
   the respective access grant.  If the particular token is a refresh
   token and the authorization server supports the revocation of access
   tokens, then the authorization server SHOULD also invalidate all
   access tokens based on the same access grant


            

            
This implies that an access grant only applies to an app authorized on a single device. If an app is installed on multiple devices and the access grant is shared between both instances, revoking device A's access token results in the unexpected revocation of device B's token.


          

          
You raised an interesting point. Is it desirable to share an access grant among different client instances? I would like to discuss this topic in the working group.

If we assume it is desirable, how would the authorization process look alike?

I would assume that as result of the authorization process of the 1st client instance, the authorization server stores an access grant, which is identified by the client_id and the user_id of the resource owner. Moreover, it creates a refresh token, which the 1st client instance uses to obtain new access tokens. As this client is public, the refresh token is the credential the intial client uses to prove its identity.

How does the 2nd client instance join the party? I would assume the 2nd client to initiate another code grant type flow (using the same client_id as the 1st client). I see two ways the authorization server could process this process:

1) After authenticating the resource owner, the authorization server finds the existing access grant for the client_id/user_id combination and automatically issues tokens w/o further user consent. Since the authorization server cannot authenticate the client_id, a malicious client could obtain and abuse the access grant of the legitimate client. That's why the security considerations of the core spec (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2) state:

The authorization server SHOULD NOT process repeated authorization
  requests automatically (without active resource owner interaction)
  without authenticating the client or relying on other measures to
  ensure the repeated request comes from the original client and not an
  impersonator.

Validating the redirect URI won't help that much, since this URI is typically device local (custom scheme or localhost).

2) The authorization server asks the resource owner for user consent and issues another pair of access/refresh token to the 2nd client. In this case, why would one bind this tokens to the already existing access grant? This would limit the resource owners capability to revoke grants for particular instances. I would rather create another access grant.

Based on this thoughts I think it is not desirable to share an access grant among different client instances.

What do others think?



          

            
If "access grant" could be defined as "an authorization issued to the  client, based on the single use of an Authorization Grant" it becomes clear than only the tokens spawning from the app's authorization on device A should be revoked.


          

          
I would like to adopt your proposal if the WG agrees.



          

            
---

I spotted a typo in "3. Implementation Note":


          

          
Thanks. Fixed.

regards,
Torsten.


          

            

              
Whether this is an viable option or
   whether access token revocation is required should be decided based
   on the service provider's risk analysis.


            

            
"an viable option" should be "a viable option".

On 24 Nov 2012, at 18:13, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:



            

              
Hi all,

this is a working group last call for draft-ietf-oauth-revocation-03 on "Token Revocation".  The draft is available here:
http://tools.ietf.org/html/draft-ietf-oauth-revocation-03

Please send you comments to the OAuth mailing list by December 10, 2012.

Thanks,
Hannes & Derek

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


            

            
--
Mark Wubben

http://novemberborn.net
http://twitter.com/novemberborn

_______________________________________________
OAuth mailing 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


    

    

  


--------------090700080607030706010408--

From jricher@mitre.org  Fri Dec 28 07:40:23 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378A421F8C87 for ; Fri, 28 Dec 2012 07:40:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.68
X-Spam-Level: 
X-Spam-Status: No, score=-3.68 tagged_above=-999 required=5 tests=[AWL=-2.682,  BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxv9oz9DWT3P for ; Fri, 28 Dec 2012 07:40:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8EE21F8BF1 for ; Fri, 28 Dec 2012 07:40:18 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BC0BB1F07B1; Fri, 28 Dec 2012 10:40:17 -0500 (EST)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A63C11F069C; Fri, 28 Dec 2012 10:40:17 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.318.4; Fri, 28 Dec 2012 10:40:17 -0500
Message-ID: <50DDBCE5.8080205@mitre.org>
Date: Fri, 28 Dec 2012 10:38:13 -0500
From: Justin Richer 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Mike Jones 
References: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436697FA11@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436697FA11@TK5EX14MBXC283.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="------------060904010000090702020305"
X-Originating-IP: [129.83.31.58]
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 15:40:23 -0000

--------------060904010000090702020305
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I thought I should drop in my full rundown of the party representation 
here. Assuming a standard 3-legged OAuth flow of any flavor, you have 
the following mapping:

  iss => Authorization Server
  aud => Resource Server(s)
  sub => Resource Owner
  azp => Client

Note that the "sub" claim here is a drop-in replacement for "prn" and 
that "azp" is a more or less drop-in replacement for "cid".

Of course there are other ways that a JWT could be minted, so let me be 
a bit more concrete with a few examples.

3-legged OAuth:

  iss: http://auth.example.org/
  aud: http://resource.example.org/
  sub: bob.smith
  azp: oauth-client-1

2-legged OAuth (client credentials):

  iss: http://auth.example.org/
  aud: http://resource.example.org/
  sub: oauth-client-1
  azp: oauth-client-1

Client authentication assertion, self-issued:

  iss: oauth-client-1
  aud: http://auth.example.org/
  sub: oauth-client-1
  azp: oauth-client-1

Authorization grant assertion, self-issued:

  iss: oauth-client-1
  aud: http://auth.example.org/
  sub: bob.smith
  azp: oauth-client-1

Client authentication assertion, non-self-issued:

  iss: http://auth.example.org/
  aud: http://auth.example.org/
  sub: oauth-client-1
  azp: oauth-client-1

Authorization grant assertion, non-self-issued:

  iss: http://auth.example.org/
  aud: http://auth.example.org/
  sub: bob.smith
  azp: oauth-client-1

OpenID Connect ID Token:

  iss: http://auth.example.org/
  aud: oauth-client-1
  sub: bob.smith
  azp: oauth-client-1



Note that repeated values are intentional and MUST be preserved, since 
there's no way to know the value of a "missing" claim otherwise.

There are likely other use cases here as well. Writing this all out has 
made me wonder if this needs to be captured in an online spreadsheet 
somewhere.

  -- Justin


On 12/20/2012 11:22 AM, Mike Jones wrote:
>
> This was discussed on the OpenID Connect call this morning.  Our sense 
> was that "Authorized Party" was actually a more general description of 
> the concept than Client ID.  Justin Richer pointed out that at that 
> point, there would be claims defined for representing all four 
> potential parties in an OAuth interaction.  Connect plans to define 
> the optional "azp" (Authorized Party) claim to let people experiment 
> with it.  There wasn't a sense that it's necessary to add to the JWT 
> spec itself at this time.
>
> As for the proposed "cid" (Client Identification Data claim type) 
> claim, our sense was that that is more related to proof of possession, 
> and can be discussed in that context.
>
> -- Mike
>
> *From:*Nat Sakimura [mailto:sakimura@gmail.com]
> *Sent:* Wednesday, December 19, 2012 11:43 PM
> *To:* Mike Jones
> *Cc:* Anthony Nadalin; John Bradley; oauth
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT
>
> As "prn" is way under-defined [1], there can be two interpretations 
> for "prn".
>
> Considering that "subject" is not a defined term (= dictionary term), 
> and interpreting a boarding pass as:
>
> "Japan Airlines authorizes JL002 to accept passenger John Smith at the 
> Gate B22 provided safety and other requirements are met between the 
> boarding time (14:30) and 10 minutes before the departure time (15:10)"
>
> then:
>
> iss: Japan Airlines
>
> prn: JL002 (the flight number)
>
> cid: John Smith (the passenger, who uses the boarding pass)
>
> aud: Gate B22 (Gate assigned to JL002)
>
> nbf: 2012-12-31T14:30+9
>
> exp: 2012-12-31T15:00+9
>
> Alternatively, if we interpret the boarding pass as:
>
> "Japan Airlines authorizes John Smith to board JL002 at the Gate B22 
> provided safety and other requirements are met the boarding time 
> (14:30) and 10 minutes before the departure time (15:10)""
>
> iss: Japan Airlines
>
> prn: John Smith
>
> cid: John Smith
>
> aud: Gate B22 (Gate assigned to JL002)
>
> nbf: 2012-12-31T14:30+9
>
> exp: 2012-12-31T15:00+9
>
> This interpretation has lost some information while encoding into JWT, 
> so prior one may be more appropriate.
>
> Either way, as "prn" lacks exact semantics, what goes into it is 
> subject to interpretation while "cid" is very clearly defined.
>
> Let me give another example.
>
> An entitlement that says: "John Smith is allowed to activate the 
> system when Mary White presents this token (#1234) to the System A" 
> that is issued by the "ABC Corp"
>
> iss: ABC Corp.
>
> jti: #1234
>
> prn: John Smith
>
> cid: Mary White
>
> aud: System A
>
> Note: this is not delegation nor on-behalf-of.
>
> More webby example: "John Smith authorizes photo print service A to 
> access photo archive service B for John Smith's photo #123 until 
> 2013-04-01 for the sum of $100."
>
> iss: John Smith's Authorization Server
>
> prn: John Smith's photo #123
>
> cid: Photo print service A
>
> aud: photo archive service B
>
> exp: 2013-04-01
>
> Nat
>
> [1]  4.1.6 "prn" defines its value as what identifies:
>
>     "the subject of the JWT"
>
> This can be expanded by replacing "JWT" with its definition as
>
>     "the subject of the string consisting of multiple parts, the first
>     being the Encoded JWT Header, plus additional parts depending upon
>     the contents of the header, with the parts being separated by
>     period ('.') characters, and each part containing base64url
>     encoded content."
>
> Further, expanding "JWT Header", it will become
>
>     "the subject of the string consisting of multiple parts, the first
>     being the string representing a JSON object that describes the
>     cryptographic operations applied to the string, plus additional
>     parts depending upon the contents of the header, with the parts
>     being separated by period ('.') characters, and each part
>     containing base64url encoded content."
>
> To me, it is not clear what it means.
>
> On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones 
> > wrote:
>
> What would the iss, prn, aud, and cid values represent in the boarding 
> pass example?
>
> -- Mike
>
> *From:* Nat Sakimura
> *Sent:* December 19, 2012 9:32 PM
> *To:* Mike Jones
> *CC:* Anthony Nadalin, John Bradley, oauth
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT
>
> I obviously disagree - if I did agree, I did not send it to the list 
> to start with :-)
>
> "cid" (or in my original proposal, "reg") has a very clear and 
> established meaning.
>
> The parallel examples abounds in our daily life.
>
> It has very little to do with On-behalf-of.
>
> It is not a delegation statement.
>
> "cid" is there to indicate to whom it was issued to.
>
> The entity who was issued this "token" is eligible to use it at the
>
> entities indicated by "aud".
>
> Example in our real life are like:
>
> - Airline boarding pass
>
> - Registered instruments (bond / share)
>
> - Monthly train pass
>
> - Disneyland annual passport
>
>  etc. etc.
>
> Please do not mix it up with a delegation statement like on-behalf-of,
>
> which is much less well defined.
>
> Nat
>
> On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones 
> > wrote:
>
>     I'm with Tony on this.  This seems premature to put into the JWT
>     standard.  All the other JWT claims have well established meanings
>     and history behind them.  These don't.
>
>     If the goal is to allow OpenID Connect implementations to not
>     reject tokens using "cid", there are lots of other ways to
>     accomplish this that I think we should consider first.
>
>     -- Mike
>
>     *From:* John Bradley
>     *Sent:* December 19, 2012 6:25 PM
>     *To:* Anthony Nadalin
>     *CC:* oauth
>
>     *Subject:* Re: [OAUTH-WG] "cid" claim in JWT
>
>     I agree, audience who requested it and and who it is requested for
>     are all interrelated.
>
>     However we do need to set down some standard way of expressing it
>     as people are starting to make stuff up on their own that will
>     impact interoperability.
>
>     If Google starts thawing in cid and clients don't know about it
>     they must reject the JWT etc.
>
>     John
>
>     On 2012-12-19, at 9:40 PM, Anthony Nadalin      > wrote:
>
>         It seems premature and we should consider this in the bigger
>         context of the "on behalf of"/delegation work that has been
>         started
>
>         *From:*oauth-bounces@ietf.org 
>         [mailto:oauth- bounces@ietf.org
>         ] *On Behalf Of *Nat Sakimura
>         *Sent:* Tuesday, December 18, 2012 6:22 PM
>         *To:* oauth
>         *Subject:* [OAUTH-WG] "cid" claim in JWT
>
>         In OpenID Connect WG, we have been talking this for sometime.
>
>         "cid" claim identifies the entity that the JWT was issued to
>         as a rightful/licensed user.
>
>         Google already uses this in their implementation of id_token
>         of OIDC.
>
>         Here is the text proposal. It introduces two new standard
>         claims: "cid" and "cit".
>
>         It would be very useful in creating a HoK drafts as well.
>
>         Cheers,
>
>         Nat
>
>           
>
>         *4.1.9. "cid" Client Identification Data Claim*
>
>           
>
>         The "cid" (client identification data) claim allows the receiver
>
>         of the JWT to identify the entity that the JWT is
>
>         intended to be used by. The audience of the JWT MUST be
>
>         able to identify the client with the value of this claim.
>
>           
>
>         The "cid" value is acase  sensitive string containing a StringOrURI value.
>
>         This claim is OPTIONAL. If the entity processing the claim does not
>
>         identify the user of the JWT with the identifier in the "cid" claim value,
>
>         then the JWT MUST be rejected. The interpretation of the registered to
>
>         value is generally application specific.
>
>           
>
>         A typical example of a registered to claim includes following:
>
>         * client_id that the audience can use to authenticate and
>
>            identify the client.
>
>         * A base64url encoded JWK.
>
>         * A URL that points to the key material that the audience can use to
>
>            authenticate the user of the JWT.
>
>           
>
>         *4.1.10 "cit" (Client Identification Data claim type)*
>
>           
>
>         The "cit" (Client Identification Data claim type) identifies the type
>
>         of the "cid" claim. It is a StringOrURI value. The defined values
>
>         are the following:
>
>           
>
>         "client_id" The value of the "cid" claim is the Client ID of the client
>
>         that the audience of the JWT is able to use to authenticate the client.
>
>           
>
>         "jwk" The value of the "cid" claim is a base64url encoded JWK of
>
>         the registered client.
>
>           
>
>         "jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of
>
>         JSON web signature [JWS].
>
>           
>
>         "x5u" The value of the "cid" claim is the URL that points to the public
>
>         key certificate of the registered client. The format of the content
>
>         that x5u points to is described in section 4.1.4 of the JSON Web Signature.
>
>         -- 
>         Nat Sakimura (=nat)
>
>         Chairman, OpenID Foundation
>         http://nat.sakimura.org/
>         @_nat_en
>
>         _______________________________________________
>         OAuth mailing list
>         OAuth@ietf.org 
>         https://www.ietf.org/mailman/listinfo/oauth
>
>
>     _______________________________________________
>     OAuth mailing list
>     OAuth@ietf.org 
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> -- 
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
> -- 
> Nat Sakimura (=nat)
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


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


  
    
  
  
    
I thought I should drop in my full
      rundown of the party representation here. Assuming a standard
      3-legged OAuth flow of any flavor, you have the following mapping:

      

       iss => Authorization Server

       aud => Resource Server(s)

       sub => Resource Owner

       azp => Client

      

      Note that the "sub" claim here is a drop-in replacement for "prn"
      and that "azp" is a more or less drop-in replacement for "cid". 

      

      Of course there are other ways that a JWT could be minted, so let
      me be a bit more concrete with a few examples. 

      

      3-legged OAuth:

      

       iss: http://auth.example.org/

       aud: http://resource.example.org/

       sub: bob.smith

       azp: oauth-client-1

      

      2-legged OAuth (client credentials):

      

       iss: http://auth.example.org/

       aud: http://resource.example.org/

       sub: oauth-client-1

       azp: oauth-client-1

      

      Client authentication assertion, self-issued:

      

       iss: oauth-client-1

       aud: http://auth.example.org/

       sub: oauth-client-1

       azp: oauth-client-1

      

      Authorization grant assertion, self-issued:

      

       iss: oauth-client-1

       aud: http://auth.example.org/

       sub: bob.smith

       azp: oauth-client-1

      

      Client authentication assertion, non-self-issued:

      

       iss: http://auth.example.org/

       aud: http://auth.example.org/

       sub: oauth-client-1

       azp: oauth-client-1

      

      Authorization grant assertion, non-self-issued:

      

       iss: http://auth.example.org/

       aud: http://auth.example.org/

       sub: bob.smith

       azp: oauth-client-1

      

      OpenID Connect ID Token:

      

       iss: http://auth.example.org/

       aud: oauth-client-1

       sub: bob.smith

       azp: oauth-client-1

      

      

      

      Note that repeated values are intentional and MUST be preserved,
      since there's no way to know the value of a "missing" claim
      otherwise. 

      

      There are likely other use cases here as well. Writing this all
      out has made me wonder if this needs to be captured in an online
      spreadsheet somewhere.

      

       -- Justin

       
      

      

      On 12/20/2012 11:22 AM, Mike Jones wrote:

    

    

      
      
      
      

        
This
            was discussed on the OpenID Connect call this morning.  Our
            sense was that “Authorized Party” was actually a more
            general description of the concept than Client ID.  Justin
            Richer pointed out that at that point, there would be claims
            defined for representing all four potential parties in an
            OAuth interaction.  Connect plans to define the optional
            “azp” (Authorized Party) claim to let people experiment with
            it.  There wasn’t a sense that it’s necessary to add to the
            JWT spec itself at this time.

        
 

        
As
            for the proposed “cid” (Client Identification Data claim
            type) claim, our sense was that that is more related to
            proof of possession, and can be discussed in that context.

        
 

        
                                                           
            -- Mike

        
 

        
From:
            Nat Sakimura [mailto:sakimura@gmail.com]
            

            Sent: Wednesday, December 19, 2012 11:43 PM

            To: Mike Jones

            Cc: Anthony Nadalin; John Bradley; oauth

            Subject: Re: [OAUTH-WG] "cid" claim in JWT

        
 

        

          

            
As "prn" is way under-defined [1],
              there can be two interpretations for "prn". 

          

          

            
 

          

          

            
Considering that "subject" is not a
              defined term (= dictionary term), and interpreting a
              boarding pass as:

          

          

            
 

          

          

            
"Japan Airlines authorizes JL002 to
              accept passenger John Smith at the Gate B22 provided
              safety and other requirements are met between the boarding
              time (14:30) and 10 minutes before the departure time
              (15:10)" 

          

          

            
 

          

          

            
then: 

          

          

            
 

          

          
iss: Japan Airlines

          

            
prn: JL002 (the flight number)

          

          

            
cid: John Smith (the passenger, who
              uses the boarding pass)

          

          

            
aud: Gate B22 (Gate assigned to JL002)

          

        

        

          
nbf: 2012-12-31T14:30+9

        

        

          
exp: 2012-12-31T15:00+9

        

        

          
 

        

        

          
Alternatively, if we interpret the
            boarding pass as: 

        

        

          
 

        

        

          
"Japan Airlines authorizes John Smith to
            board JL002 at the Gate B22 provided safety and other
            requirements are met the boarding time (14:30) and 10
            minutes before the departure time (15:10)""

        

        

          
 

        

        

          
iss: Japan Airlines

        

        

          
prn: John Smith

        

        

          
cid: John Smith

        

        

          
aud: Gate B22 (Gate assigned to JL002)

        

        

          

            
nbf: 2012-12-31T14:30+9

          

          

            
exp: 2012-12-31T15:00+9

          

        

        

          
 

        

        

          
This interpretation has lost some
            information while encoding into JWT, so prior one may be
            more appropriate. 

        

        

          
 

        

        

          
Either way, as "prn" lacks exact
            semantics, what goes into it is subject to interpretation
            while "cid" is very clearly defined. 

        

        

          
 

        

        

          
Let me give another example. 

        

        

          
 

        

        

          
An entitlement that says: "John Smith is
            allowed to activate the system when Mary White presents this
            token (#1234) to the System A" that is issued by the "ABC
            Corp"

        

        

          
 

        

        

          
iss: ABC Corp. 

        

        

          
jti: #1234

        

        

          
prn: John Smith

        

        

          
cid: Mary White

        

        

          
aud: System A

        

        

          
 

        

        

          
Note: this is not delegation nor
            on-behalf-of. 

        

        

          
 

        

        

          
More webby example: "John Smith
            authorizes photo print service A to access photo archive
            service B for John Smith's photo #123 until 2013-04-01 for
            the sum of $100."

        

        

          
 

        

        

          
iss: John Smith's Authorization Server

        

        

          
prn: John Smith's photo #123

        

        

          
cid: Photo print service A

        

        

          
aud: photo archive service B

        

        

          
exp: 2013-04-01

        

        

          
 

        

        

          
Nat

        

        

          
 

        

        

          
[1]  4.1.6 "prn" defines its value as
            what identifies:

        

        

          
 

        

        

          

            

              
"the
                  subject of the JWT" 

            

          

          

            

              
 

            

            

              
This
                  can be expanded by replacing "JWT" with its definition
                  as 

            

            

              
 

            

            

              
"the
                  subject of the string consisting of multiple parts,
                  the first being the Encoded JWT Header, plus
                  additional parts depending upon the contents of the
                  header, with the parts being separated by period ('.')
                  characters, and each part containing base64url encoded
                  content."

            

            

              
 

            

            

              
Further,
                  expanding "JWT Header", it will become 

            

            

              
 

            

            

              
"the
                  subject of the string consisting of multiple parts,
                  the first being the string representing a JSON object
                  that describes the cryptographic operations applied to
                  the string, plus additional parts depending upon the
                  contents of the header, with the parts being separated
                  by period ('.') characters, and each part containing
                  base64url encoded content."

            

            

              
 

            

            

              
To
                  me, it is not clear what it means. 

            

          

          

            
 

          

        

        

          
 

          

            
On Thu, Dec 20, 2012 at 3:07 PM, Mike
              Jones <Michael.Jones@microsoft.com>
              wrote:

            

              

                

                  
What
                      would the iss, prn, aud, and cid values represent
                      in the boarding pass example?

                

                

                  
 

                

                

                  
--
                      Mike

                

                

                  
 

                

                

                  
From: Nat
                      Sakimura

                      Sent: December
                      19, 2012 9:32 PM

                      To: Mike
                      Jones

                      CC: Anthony
                      Nadalin, John Bradley, oauth

                      Subject: Re:
                      [OAUTH-WG] "cid" claim in JWT

                

                

                  

                    

                      
 

                    

                    
I
                        obviously disagree - if I did agree, I did not
                        send it to the list to start with :-)
                        

                    

                      
 

                    

                    

                      
"cid"
                          (or in my original proposal, "reg") has a very
                          clear and established meaning. 

                    

                    

                      
The
                          parallel examples abounds in our daily life. 

                    

                    

                      
 

                    

                    

                      
It
                          has very little to do with On-behalf-of. 

                    

                    

                      
It
                          is not a delegation statement. 

                    

                    

                      
 

                    

                    

                      
"cid"
                          is there to indicate to whom it was issued
                          to. 

                    

                    

                      
The
                          entity who was issued this "token" is eligible
                          to use it at the 

                    

                    

                      
entities
                          indicated by "aud". 

                    

                    

                      
 

                    

                    

                      
Example
                          in our real life are like: 

                    

                    

                      
 

                    

                    

                      
-
                          Airline boarding pass

                    

                    

                      
-
                          Registered instruments (bond / share) 

                    

                    

                      
-
                          Monthly train pass

                    

                    

                      
-
                          Disneyland annual passport

                    

                    

                      
 etc.
                          etc. 

                    

                    

                      
 

                    

                    

                      
Please
                          do not mix it up with a delegation statement
                          like on-behalf-of, 

                    

                    

                      
which
                          is much less well defined. 

                    

                    

                      
 

                    

                    

                      
Nat

                    

                    

                      
 

                    

                  

                

                

                  
 

                  

                    

                      

                        
On
                            Thu, Dec 20, 2012 at 12:07 PM, Mike Jones
                            <Michael.Jones@microsoft.com>
                            wrote:

                      

                    

                    

                      

                        

                          

                            

                              

                                
I'm
                                    with Tony on this.  This seems
                                    premature to put into the JWT
                                    standard.  All the other JWT claims
                                    have well established meanings and
                                    history behind them.  These don't.

                              

                              

                                
 

                              

                              

                                
If
                                    the goal is to allow OpenID Connect
                                    implementations to not reject tokens
                                    using “cid”, there are lots of other
                                    ways to accomplish this that I think
                                    we should consider first.

                              

                              

                                
 

                              

                              

                                
--
                                    Mike

                              

                              

                                
 

                              

                              

                                
 

                              

                            

                          

                          

                            

                              

                                
From: John
                                    Bradley

                                    Sent: December
                                    19, 2012 6:25 PM

                                    To: Anthony
                                    Nadalin

                                    CC: oauth

                              

                            

                            
Subject: Re:
                                [OAUTH-WG] "cid" claim in JWT

                          

                          

                            

                              

                                

                                  
 

                                

                                
I
                                    agree, audience who requested it and
                                    and who it is requested for are all
                                    interrelated.
                                    

                                

                                  
 

                                

                              

                              

                                

                                  

                                    
However
                                        we do need to set down some
                                        standard way of expressing it as
                                        people are starting to make
                                        stuff up on their own that will
                                        impact interoperability.

                                  

                                  

                                    
 

                                  

                                  

                                    
If
                                        Google starts thawing in cid and
                                        clients don't know about it they
                                        must reject the JWT etc.

                                  

                                  

                                    
 

                                  

                                  

                                    
John

                                  

                                  

                                    
 

                                    

                                      

                                        
On
                                            2012-12-19, at 9:40 PM,
                                            Anthony Nadalin <tonynad@microsoft.com>
                                            wrote:

                                      

                                      

                                        
 

                                        

                                          

                                            

                                              
It
                                                  seems premature and we
                                                  should consider this
                                                  in the bigger context
                                                  of the “on behalf
                                                  of”/delegation work
                                                  that has been started

                                            

                                            

                                              
 

                                            

                                            

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

                                                    Behalf Of Nat
                                                  Sakimura

                                                  Sent: Tuesday,
                                                  December 18, 2012 6:22
                                                  PM

                                                  To: oauth

                                                  Subject: [OAUTH-WG]
                                                  "cid" claim in JWT

                                            

                                            

                                              
 

                                            

                                            

                                              
In
                                                OpenID Connect WG, we
                                                have been talking this
                                                for sometime. 

                                            

                                            

                                              

                                                
"cid"
                                                  claim identifies the
                                                  entity that the JWT
                                                  was issued to as a
                                                  rightful/licensed
                                                  user. 

                                              

                                            

                                            

                                              

                                                
Google
                                                  already uses this in
                                                  their implementation
                                                  of id_token of OIDC. 

                                              

                                            

                                            

                                              

                                                
 

                                              

                                            

                                            

                                              

                                                
Here
                                                  is the text proposal.
                                                  It introduces two new
                                                  standard claims: "cid"
                                                  and "cit". 

                                              

                                            

                                            

                                              

                                                
 

                                              

                                            

                                            

                                              

                                                
It
                                                    would be very useful
                                                    in creating a HoK
                                                    drafts as well. 

                                              

                                              

                                                
 

                                              

                                              

                                                
Cheers, 

                                              

                                              

                                                
 

                                              

                                              

                                                
Nat

                                              

                                              

                                                
 

                                              

                                              

                                                

                                                  
 

                                                  
4.1.9. "cid" Client Identification Data Claim

                                                  
 

                                                  
The "cid" (client identification data) claim allows the receiver 

                                                  
of the JWT to identify the entity that the JWT is 

                                                  
intended to be used by. The audience of the JWT MUST be 

                                                  
able to identify the client with the value of this claim.

                                                  
 

                                                  
The "cid" value is a case sensitive string containing a StringOrURI value.

                                                  
This claim is OPTIONAL. If the entity processing the claim does not 

                                                  
identify the user of the JWT with the identifier in the "cid" claim value, 

                                                  
then the JWT MUST be rejected. The interpretation of the registered to 

                                                  
value is generally application specific.

                                                  
 

                                                  
A typical example of a registered to claim includes following: 

                                                  
* client_id that the audience can use to authenticate and 

                                                  
  identify the client.

                                                  
* A base64url encoded JWK. 

                                                  
* A URL that points to the key material that the audience can use to 

                                                  
  authenticate the user of the JWT.

                                                  
 

                                                  
4.1.10 "cit" (Client Identification Data claim type)

                                                  
 

                                                  
The "cit" (Client Identification Data claim type) identifies the type 

                                                  
of the "cid" claim. It is a StringOrURI value. The defined values 

                                                  
are the following:

                                                  
 

                                                  
"client_id" The value of the "cid" claim is the Client ID of the client 

                                                  
that the audience of the JWT is able to use to authenticate the client.

                                                  
 

                                                  
"jwk" The value of the "cid" claim is a base64url encoded JWK of 

                                                  
the registered client.

                                                  
 

                                                  
"jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of 

                                                  
JSON web signature [JWS].

                                                  
 

                                                  
"x5u" The value of the "cid" claim is the URL that points to the public 

                                                  
key certificate of the registered client. The format of the content 

                                                  
that x5u points to is described in section 4.1.4 of the JSON Web Signature.

                                                

                                              

                                            

                                            

                                              

                                                

                                                  
 

                                                

                                              

                                              

                                                
-- 

                                                  Nat Sakimura (=nat)

                                              

                                              

                                                

                                                  
Chairman,
                                                    OpenID Foundation

                                                    http://nat.sakimura.org/

                                                    @_nat_en

                                                

                                              

                                              

                                                
 

                                              

                                            

                                          

                                          
_______________________________________________

                                              OAuth mailing list

                                              OAuth@ietf.org

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

                                        

                                      

                                    

                                    
 

                                  

                                

                              

                            

                          

                        

                      

                      

                        

                          


_______________________________________________

                              OAuth mailing list

                              OAuth@ietf.org

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

                        

                      

                    

                  

                  

                    

                      


                          

                          

                      

                        
 

                      

                      
--
                          

                          Nat Sakimura (=nat) 

                      

                        
Chairman,
                            OpenID Foundation

                            http://nat.sakimura.org/

                            @_nat_en

                      

                    

                  

                

              

            

          

          


            

            

          

            
 

          

          
-- 

            Nat Sakimura (=nat)

          

            
Chairman, OpenID Foundation

              http://nat.sakimura.org/

              @_nat_en

          

        

      

      

      

      

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


    

    

  


--------------060904010000090702020305--

From sberyozkin@gmail.com  Fri Dec 28 07:45:32 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754B921F8CED for ; Fri, 28 Dec 2012 07:45:32 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FB3IhuICRcRq for ; Fri, 28 Dec 2012 07:45:31 -0800 (PST)
Received: from mail-bk0-f48.google.com (mail-bk0-f48.google.com [209.85.214.48]) by ietfa.amsl.com (Postfix) with ESMTP id CDA2721F8C87 for ; Fri, 28 Dec 2012 07:45:30 -0800 (PST)
Received: by mail-bk0-f48.google.com with SMTP id jc3so4651376bkc.7 for ; Fri, 28 Dec 2012 07:45:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XkAufrG8uFvHl0iqAMKhEkHYL5IZTZSl9EwSAV8d87c=; b=SM/CLNwoP8Tf8DZIFdFT9262cOvCqzso3Dw2wUZ4BM2ZMGxks5fprzvM0OG+HFNyP7 VVJGekQKIP3pEp63ldJyjBKjgeUunLky1Wb2vSKQHwCPU2zjMTmXmXRF+x4X33o43SJm XFYg3VeFcMOmuiA/wPKkFyQDuRtIm2a8oTUD/fsM3XOrx1XCie1dM/SPSshIFNNgS9LU Keb6jha1VvZWF8hi07ww99Ohk1gbBrDmnuM9j51yIerDqyKjoH2uyF8ok1TwCWE0ZGF8 gpZWOOVcsdj/Lk1nkow5uJVnDopT4Pjf/vVGSQbm2miXSsb6StQBLBJoDRNDicyGSnfC 20Kw==
X-Received: by 10.204.129.202 with SMTP id p10mr16124820bks.56.1356709529562;  Fri, 28 Dec 2012 07:45:29 -0800 (PST)
Received: from [10.36.224.146] ([217.173.99.61]) by mx.google.com with ESMTPS id y11sm23080345bkw.8.2012.12.28.07.45.27 (version=SSLv3 cipher=OTHER); Fri, 28 Dec 2012 07:45:28 -0800 (PST)
Message-ID: <50DDBE96.6050501@gmail.com>
Date: Fri, 28 Dec 2012 15:45:26 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Torsten Lodderstedt 
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net> <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com> <50DB2269.6020501@lodderstedt.net> <50DC17C4.6040300@gmail.com> <50DC8D52.6020404@lodderstedt.net>
In-Reply-To: <50DC8D52.6020404@lodderstedt.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 15:45:32 -0000

Hi Torsten
On 27/12/12 18:02, Torsten Lodderstedt wrote:
>
>>>
>>> Depending on the authorization server's revocation policy, the
>>> revocation of a particular token may cause the revocation of related
>>> tokens and the underlying authorization.
>>> If the particular token is a refresh token and the authorization server
>>> supports the revocation of access tokens, then the authorization server
>>> SHOULD also invalidate all access tokens based on the same authorization
>>> (seeImplementation Note <#impl>).
>>>
>>
>> This implies that some ASs may, in theory at least, allow the client
>> to revoke the token but keep that specific client's authorization...
>
> yep, it does. If this makes sense from the ASs perspective.
>
is it something OAuth2 allows ?

For example, what if the end user (as opposed to the client owning the 
token) goes and revokes a token for a given client via some UI console 
interacting with AS, I guess the end user expectations here is that the 
affected client won't be able to access this user's resources unless 
re-authorized again.

Why would it be different for a client revoking its access token ?

thanks, Sergey

> regards,
> Torsten.
>
>>
>> Cheers, Sergey
>>
>>> Thoughts?
>>>
>>> regards,
>>> Torsten.
>>>
>>> Am 26.12.2012 15:38, schrieb John Bradley:
>>>> We don't want to share grant information across multiple instances
>>>> of public client.
>>>>
>>>> However we don't necessarily want to preclude multiple instances of
>>>> a private client, Though how the AS would tell them apart is a
>>>> interesting side question.
>>>>
>>>> From a revocation point of view if you revoke the grant for one
>>>> instance of a client you revoke it for all, though for a public
>>>> client the grant is not doing anything anyway as the AS shield not
>>>> be pre approving based on the grant.
>>>>
>>>> There are still some open questions about an extension to identify
>>>> client instances, though personally I prefer to have each instance
>>>> with it's own client ID.
>>>>
>>>> The language around grants has always been a bit philosophical for
>>>> my taste.
>>>>
>>>> If I recall correctly in the code flow the code is the
>>>> representation of the grant. In the implicit flow the grant is
>>>> implicit in the access token.
>>>> What construct (if any in the implicit case) is stored in the AS to
>>>> represent this is mostly left to the imagination of the implementer.
>>>>
>>>> John B.
>>>>
>>>>
>>>> On 2012-12-25, at 8:24 AM, Torsten
>>>> Lodderstedt wrote:
>>>>
>>>>> Hi Mark,
>>>>>
>>>>> thanks for reviewing the draft. Comments inline.
>>>>>
>>>>> Am 02.12.2012 18:27, schrieb Mark Wubben:
>>>>>> The draft relies heavily on the definition "access grant", but no
>>>>>> definition is provided in the draft or RFC 6749. It's been my
>>>>>> interpretation that an "access grant" is the *fact* that a
>>>>>> resource owner has authorized a client (potentially scoped) access
>>>>>> to the protected resources. Once access is granted in this manner,
>>>>>> further access tokens may be obtained without explicit permission
>>>>>> by the end-user. That is, in the Protocol Flow there is no user
>>>>>> input between steps A and B.
>>>>> That's correct.
>>>>>
>>>>>> In "1. Introduction" it is stated:
>>>>>>
>>>>>>> A
>>>>>>> revocation request will invalidate the actual token and, if
>>>>>>> applicable, other tokens based on the same access grant and the
>>>>>>> access grant itself.
>>>>>> then, in "2. Token Revocation":
>>>>>>
>>>>>>> In the next step, the authorization server invalidates the token and
>>>>>>> the respective access grant. If the particular token is a refresh
>>>>>>> token and the authorization server supports the revocation of access
>>>>>>> tokens, then the authorization server SHOULD also invalidate all
>>>>>>> access tokens based on the same access grant
>>>>>> This implies that an access grant only applies to an app
>>>>>> authorized on a single device. If an app is installed on multiple
>>>>>> devices and the access grant is shared between both instances,
>>>>>> revoking device A's access token results in the unexpected
>>>>>> revocation of device B's token.
>>>>> You raised an interesting point. Is it desirable to share an access
>>>>> grant among different client instances? I would like to discuss
>>>>> this topic in the working group.
>>>>>
>>>>> If we assume it is desirable, how would the authorization process
>>>>> look alike?
>>>>>
>>>>> I would assume that as result of the authorization process of the
>>>>> 1st client instance, the authorization server stores an access
>>>>> grant, which is identified by the client_id and the user_id of the
>>>>> resource owner. Moreover, it creates a refresh token, which the 1st
>>>>> client instance uses to obtain new access tokens. As this client is
>>>>> public, the refresh token is the credential the intial client uses
>>>>> to prove its identity.
>>>>>
>>>>> How does the 2nd client instance join the party? I would assume the
>>>>> 2nd client to initiate another code grant type flow (using the same
>>>>> client_id as the 1st client). I see two ways the authorization
>>>>> server could process this process:
>>>>>
>>>>> 1) After authenticating the resource owner, the authorization
>>>>> server finds the existing access grant for the client_id/user_id
>>>>> combination and automatically issues tokens w/o further user
>>>>> consent. Since the authorization server cannot authenticate the
>>>>> client_id, a malicious client could obtain and abuse the access
>>>>> grant of the legitimate client. That's why the security
>>>>> considerations of the core spec
>>>>> (http://tools.ietf.org/html/draft-ietf-oauth-v2-31#section-10.2)
>>>>> state:
>>>>>
>>>>> The authorization server SHOULD NOT process repeated authorization
>>>>> requests automatically (without active resource owner interaction)
>>>>> without authenticating the client or relying on other measures to
>>>>> ensure the repeated request comes from the original client and not an
>>>>> impersonator.
>>>>>
>>>>> Validating the redirect URI won't help that much, since this URI is
>>>>> typically device local (custom scheme or localhost).
>>>>>
>>>>> 2) The authorization server asks the resource owner for user
>>>>> consent and issues another pair of access/refresh token to the 2nd
>>>>> client. In this case, why would one bind this tokens to the already
>>>>> existing access grant? This would limit the resource owners
>>>>> capability to revoke grants for particular instances. I would
>>>>> rather create another access grant.
>>>>>
>>>>> Based on this thoughts I think it is not desirable to share an
>>>>> access grant among different client instances.
>>>>>
>>>>> What do others think?
>>>>>
>>>>>> If "access grant" could be defined as "an authorization issued to
>>>>>> the client, based on the single use of an Authorization Grant" it
>>>>>> becomes clear than only the tokens spawning from the app's
>>>>>> authorization on device A should be revoked.
>>>>> I would like to adopt your proposal if the WG agrees.
>>>>>
>>>>>> ---
>>>>>>
>>>>>> I spotted a typo in "3. Implementation Note":
>>>>> Thanks. Fixed.
>>>>>
>>>>> regards,
>>>>> Torsten.
>>>>>>> Whether this is an viable option or
>>>>>>> whether access token revocation is required should be decided based
>>>>>>> on the service provider's risk analysis.
>>>>>> "an viable option" should be "a viable option".
>>>>>>
>>>>>> On 24 Nov 2012, at 18:13, Hannes
>>>>>> Tschofenig wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> this is a working group last call for
>>>>>>> draft-ietf-oauth-revocation-03 on "Token Revocation". The draft
>>>>>>> is available here:
>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-revocation-03
>>>>>>>
>>>>>>> Please send you comments to the OAuth mailing list by December
>>>>>>> 10, 2012.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Hannes& Derek
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>> --
>>>>>> Mark Wubben
>>>>>>
>>>>>> http://novemberborn.net
>>>>>> http://twitter.com/novemberborn
>>>>>>
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>


From sberyozkin@gmail.com  Fri Dec 28 07:56:17 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C95221F8A63 for ; Fri, 28 Dec 2012 07:56:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzpTyq534omR for ; Fri, 28 Dec 2012 07:56:16 -0800 (PST)
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id 40C5321F86D5 for ; Fri, 28 Dec 2012 07:56:16 -0800 (PST)
Received: by mail-bk0-f43.google.com with SMTP id jf20so4693007bkc.16 for ; Fri, 28 Dec 2012 07:56:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qMQnS9yqW0IZFPiIxh98wqdm8Vb/lXULSJl17pNVFC4=; b=Ucq/LGLalS+S6GVJ2KKD9ps4I6CJdcgPkjG0fs6T/5v5r3/zRBpizBKMmSBP0VY8dy HXdxJVksULFd/mS02IkHUUrnXe94g3K8GOLshWQONFH9SauaCvHEBRWvtPrUnqZ7J0El +eEFHTovmHKnDzck0BdxoNlwImq6fLkIH86hF54fnH4OYjOC3eq+lYs4aSrGLn7i9XZ+ qq6XpcZ2WUmmpYM7P/yk0W49y98+03AbwbnPVGIc/CxR0MsyDZCBkmRNJp3IOwsHlaPT l0goRvgTK+hkV0nFsMQAx0zXcevIjNfJ/RJyrRjJWMj7LCXDnCSlgKO8ldoYsi61RhUJ gThg==
X-Received: by 10.204.5.135 with SMTP id 7mr16095317bkv.48.1356710175152; Fri, 28 Dec 2012 07:56:15 -0800 (PST)
Received: from [10.36.224.146] ([217.173.99.61]) by mx.google.com with ESMTPS id f24sm23101649bkv.7.2012.12.28.07.56.13 (version=SSLv3 cipher=OTHER); Fri, 28 Dec 2012 07:56:14 -0800 (PST)
Message-ID: <50DDC11C.4080904@gmail.com>
Date: Fri, 28 Dec 2012 15:56:12 +0000
From: Sergey Beryozkin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Torsten Lodderstedt 
References:  <50BCC54D.5060609@mitre.org> <50D99EF8.80308@lodderstedt.net> <50DC1B9C.1020505@gmail.com> <50DC91E8.4010009@lodderstedt.net>
In-Reply-To: <50DC91E8.4010009@lodderstedt.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Review of Token Revocation draft
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 15:56:17 -0000

Hi Torsten
On 27/12/12 18:22, Torsten Lodderstedt wrote:
>
> Am 27.12.2012 10:57, schrieb Sergey Beryozkin:
>> sHi
>> On 25/12/12 12:41, Torsten Lodderstedt wrote:
>>> Hi all,
>>>
>>> any other opinion regarding having or not having a token type parameter?
>>>
>>> I would like to go with #1 as it is rather late in the process to
>>> (re-)introduce a mandatory parameter. And making it an optional
>>> parameter (#4) seems not really useful to me.
>>>
>> ce
>> +1 to #4 - it might help optimizing the lookups. Example, refresh and
>> access token keys may be kept in different tables, so ideally revoking
>> a refresh token only would involve a definite lookup to the refresh
>> token table/etc only, same for access tokens.
>>
>> Having said this, the optional parameter can probably be added later.
>>
>> However, it made me think, should the client be able to say, "I'd like
>> to revoke this refresh token and the access token linked to this
>> refresh token", in other words, should the client be given an option
>> to optimize the revocation process ? Probably can be reviewed later too
>
> Hi Sergey,
>
> ok, got you. Thanks for the proposal. I agree with your assessment that
> this can be added later. In my opinion, we generally need more
> real-world implementation experience in order to optimize the protocol.
> For the time being, I would like to have basic revocation support.
>

+1 again :-)

Thanks, Sergey

> regards,
> Torsten.
>
>>
>> thanks, Sergey
>>
>>> regards,
>>> Torsten.
>>>> The way I see it, we've got a few options:
>>>>
>>>> 1) Leave it as-is, with no field. Client/RS/whoever just sends the
>>>> token over and it's the AS's problem.
>>>> 2) Define a required field with "access" and "refresh" value
>>>> semantics, and state that other values MAY be accepted by a given AS,
>>>> or defined by extension protocols. These extension values MUST be
>>>> fully qualified URIs.
>>>> 3) Same as #2, but with IANA registry to allow for non-collision of
>>>> short names.
>>>> 4) Define an optional field that the client MAY send as a hint to the
>>>> AS, and it's up to the AS to figure out if it makes any sense in the
>>>> context of the request. All bets are off as to the content of this
>>>> field, other than "it's a string".
>>>>
>>>> There may be other approaches as well.
>>>>
>>>> -- Justin
>>>>
>>>> On 11/30/2012 04:28 PM, Anganes, Amanda L wrote:
>>>>> Here is my review of the Toke Revocation draft
>>>>> (http://datatracker.ietf.org/doc/draft-ietf-oauth-revocation/):
>>>>>
>>>>> Section 1. Introduction
>>>>> First paragraph has the following definition in it: "A token is the
>>>>> external representation of an access grant issued by a resource owner
>>>>> to a particular client." This seems a bit odd to me. The OAuth2 spec
>>>>> [1] defines "access token" as "An access token is a string
>>>>> representing an authorization issued to the client." (section 1.4)
>>>>> and "refresh token" as "credentials used to obtain access tokens
>>>>> (section 1.5). Should this spec borrow similar language to be more
>>>>> consistent?
>>>>>
>>>>> Paragraph 2 "From an end-user's perception" should be "From an
>>>>> end-user's perspective".
>>>>>
>>>>> Section 2. Token Revocation
>>>>> What is the reason for requiring the service provider to detect the
>>>>> token type automatically? For our implementation, Access Tokens,
>>>>> Refresh Tokens, and ID Tokens are all structured tokens (with unique
>>>>> structures across the three types), and as such are stored in 3
>>>>> separate database tables. In order to "detect" the token type, we
>>>>> would need to run a get-by-value query across all three tables, check
>>>>> if any of those queries returned anything, and then proceed to revoke
>>>>> the token (if one was found). This does not seem ideal to me.
>>>>>
>>>>> The spec says that "The authorization server first validates the
>>>>> client credentials (in case of a confidential client) and verifies
>>>>> whether the client is authorized to revoke the particular token."
>>>>> What does this verification entail? Does it just mean that 1) the
>>>>> client credentials must validate and 2) the token must belong to the
>>>>> client requesting the revocation? If so I think the text should be
>>>>> clarified to reflect that. Or are you thinking of a case where a
>>>>> client might not be allowed to revoke its own tokens, via some kind
>>>>> of scoping?
>>>>>
>>>>> 2.1 Cross Origin Support
>>>>> Formatting looks a little off here, otherwise this section looks fine.
>>>>>
>>>>> 5. Security Considerations
>>>>> Paragraph 3 (Malicious clients): "Appropriate countermeasures, which
>>>>> should be in place for the token endpoint as well, MUST be applied to
>>>>> the revocation endpoint." These countermeasures should be referenced
>>>>> to the proper section(s) of the OAuth core spec or Threat Model
>>>>> document.
>>>>>
>>>>> Paragraph 4 reads a bit oddly. Suggest following rewording:
>>>>> "A malicious client may attempt to guess valid tokens on this
>>>>> endpoint by making revocation requests against potential token
>>>>> strings. According to this specification, a client's request must
>>>>> contain a valid client_id, in the case of a public client, or valid
>>>>> client credentials, in the case of a confidential client. The token
>>>>> being revoked must also belong to the requesting client. If an
>>>>> attacker is able to successfully guess a public client's client_id
>>>>> and one of their tokens, or a private client's credentials and one of
>>>>> their tokens, they could do much worse damage by using the token
>>>>> elsewhere than by revoking it. If they chose to revoke the token, the
>>>>> legitimate client will lose its authorization and will need to prompt
>>>>> the user again. No further damage is done and the guessed token is
>>>>> now worthless."
>>>>>
>>>>> References:
>>>>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-31
>>>>>
>>>>> --
>>>>> Amanda Anganes
>>>>> Info Sys Engineer, G061
>>>>> The MITRE Corporation
>>>>> 781-271-3103
>>>>> aanganes@mitre.org
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>


From dick.hardt@gmail.com  Fri Dec 28 08:51:58 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190CA21F8D33 for ; Fri, 28 Dec 2012 08:51:58 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkfBYinkaqJl for ; Fri, 28 Dec 2012 08:51:57 -0800 (PST)
Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6F91621F8C54 for ; Fri, 28 Dec 2012 08:51:47 -0800 (PST)
Received: by mail-pb0-f50.google.com with SMTP id wz7so6006306pbc.37 for ; Fri, 28 Dec 2012 08:51:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=QrNiMClkNQk2YKtToS00JnExbKoMU3jCX3n8OP4hVXo=; b=HgqPYbOWpzfGyIcQlAdzeY3HDUtNCOkFzgj0Dsp8kGhvbbOlZhSXbrf9UdMvQE/b5v jKJi5dfmXSCV12KH5I5yP4P4emfm1FOERYc89U9bEVRPQzrHrUMIxXbKi50cgqfa6Go7 BV5LA0Nvb81DizIchENQ89DN+4Vnq600wrK5MKfAyQKj84FwJ29TW3IAruHG535HIQpZ 8pYGCAaRohJECox17M5hDMrwXTpPy0dMHBfZd9/Qlxwe+YcgpTK2GjFPQiShdWbT12+H GwUV4f8wvsmpbhhaYJBCo1XLQ20VI+e5ARnz7Dhhc9lntk8aVHfF30p+wTenK9YrO91X u1zA==
X-Received: by 10.68.230.135 with SMTP id sy7mr106704869pbc.76.1356713503850;  Fri, 28 Dec 2012 08:51:43 -0800 (PST)
Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id f5sm20638441pav.22.2012.12.28.08.51.40 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Dec 2012 08:51:41 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Dick Hardt 
In-Reply-To: <20121228100115.23993.75761.idtracker@ietfa.amsl.com>
Date: Fri, 28 Dec 2012 08:51:39 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20121228100115.23993.75761.idtracker@ietfa.amsl.com>
To: oauth@ietf.org
X-Mailer: Apple Mail (2.1499)
Subject: [OAUTH-WG] "prn" -> "sub" :: draft-ietf-oauth-json-web-token-06.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 16:51:58 -0000

Did I miss the discussion on this code breaking change?

I'm ok with the change, but would have expected more discussion / notice =
about a change such as this.

Before I run around and make edits to running code, I'd like to know if =
we are staying with this label.

-- Dick



From eve@xmlgrrl.com  Fri Dec 28 11:31:21 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6DA21F8E10 for ; Fri, 28 Dec 2012 11:31:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Level: 
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=0.175,  BAYES_00=-2.599, FROM_DOMAIN_NOVOWEL=0.5, HTML_MESSAGE=0.001, SARE_URI_CONS7=0.306, URI_NOVOWEL=0.5]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5oLATJbBUA4R for ; Fri, 28 Dec 2012 11:31:20 -0800 (PST)
Received: from mail.promanage-inc.com (eliasisrael.com [50.47.36.5]) by ietfa.amsl.com (Postfix) with ESMTP id D361B21F8DFD for ; Fri, 28 Dec 2012 11:31:19 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.promanage-inc.com (Postfix) with ESMTP id BF699765DEF; Fri, 28 Dec 2012 11:31:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at promanage-inc.com
Received: from mail.promanage-inc.com ([127.0.0.1]) by localhost (greendome.promanage-inc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WRg08YUOv5Hv; Fri, 28 Dec 2012 11:31:14 -0800 (PST)
Received: from [192.168.168.111] (unknown [192.168.168.111]) by mail.promanage-inc.com (Postfix) with ESMTPSA id 6CC1C765DC9; Fri, 28 Dec 2012 11:31:14 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_361D0D34-317A-497B-AB3B-E17A5CECE00D"
From: Eve Maler 
In-Reply-To: 
Date: Fri, 28 Dec 2012 11:31:13 -0800
Message-Id: 
References: 
To: "Anganes, Amanda L" 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] OAuth 2.0 Resource Registration draft -- FW: New Version Notification for draft-hardjono-oauth-resource-reg-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Dec 2012 19:31:21 -0000

--Apple-Mail=_361D0D34-317A-497B-AB3B-E17A5CECE00D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1250


On 28 Dec 2012, at 5:58 AM, "Anganes, Amanda L"  =
wrote:

> Hi Eve and Thomas,
>=20
> On 12/27/12 8:11 PM, "Eve Maler"  wrote:
>=20
>> Amanda, thanks for the lightning-fast comments back. A couple of =
additional notes on top of Thomas's response:
>>=20
>> The "scope type" language is indeed new this time -- of course this =
whole modular spec is newly broken out, but the previous text from UMA's =
rev 05 still said "scope". (There's a new member in the JSON description =
of a resource set that is called "type", but this is actually the =
resource set's type: different thing.) Maybe this should just be changed =
back to "scope" and "scope description", as we really do mean the same =
construct as in plain OAuth, although here it's enhanced with a =
machine-readable description, and it's mappable to resource sets that =
have been explicitly identified. One thing we've been learning lately is =
that terminology impedance mismatches are not worth the cost; this one =
is a recent back-sliding. :)
>=20
> I think it would make much more sense to stick with "scope" and "scope =
description". I assumed that you were trying to avoid collisions with =
OAuth by changing it, but it sounds like that is not the case.=20
>=20
> There might be a better way to denote that these are enhanced scopes, =
but "type" isn't quite right for that as it does imply a class or kind =
of thing (to which many particular things might belong), rather than a =
special or enhanced particular thing.=20

Our experience so far is that enhanced versions of things should just =
use the name for the thing. Hence, in the UMA core spec we've finally =
started using OAuth terminology directly rather than sticking with our =
original names (which dated from OAuth 1.0). I for one find it a LOT =
clearer, now that OAuth's architecture has become more widely =
understood.

>=20
>>=20
>> Eve: Regarding the sentence "Without a specific resource set =
identifier path component, the URI applies to the set of resource set =
descriptions already registered." in Section 2.3: I suspect this can =
just be deleted entirely. It's redundant with the "List resource set =
registrations" bullet item just below, which literally shows the {rsid} =
component of the path being absent. This is the only supported method in =
this API that has no {rsid} path component.
>> Thomas: Resource set registration API:  If Alice (the RO) has already =
previously registered some resources at the AS, then Alice will already =
have a PAT token (and the AS knows about Alice, her PAT, her resource =
sets and scopes). If Alice comes back again with the same PAT and =
forgets to specificy the path component, we assume the AS is smart =
enough to figure out which sets Alice is refering to. Does this help? =
(or does it still read weirdly).
>>=20
> These two explanations are very different. If Thomas's assessment is =
correct, I would move that explanatory text up to the end of the =
paragraph starting with "The authorization server MUST present an API=85" =
and explain that the PAT can also be used to figure out the {rsid} for =
any requests where it is left off (implying that the {rsid} component =
MAY be left off of any of the following API calls). Otherwise if Eve is =
correct and that additional caveat is NOT meant to be there, I would =
suggest removing the phrase entirely as it does seem to imply that =
{rsid} may be left off.=20

I think Thomas might been thinking about a different issue we have faced =
in the past regarding URIs, which is the question of how =
protected-resource endpoints are disinguishable per resource owner. I =
won't deep-dive on that issue here to save confusion, but suffice to say =
I think we can remove the offending sentence.

>=20
>>=20
>> Regarding {rsreguri}: I do see it defined, in this same Section 2.3. =
Basically this notation is simply a device to allow for referring to a =
"resource set registration endpoint" (defined in the Terminology =
section) in the URIs here that serve as method templates. Is there a =
better way to do this?
>=20
> Yes, it is defined but not actually used to describe the API paths. =
The definition is fine but if it is there it should be used; for example =
the "Create resource set description" path should change from "PUT =
/resource_set/{rsid}" to "PUT {rsreguri}/resource_set/{rid}".

It's used just above the explanation:=20

The authorization server MUST present an API for registering resource =
set descriptions at a set of URIs with the structure =
"{rsreguri}/resource_set/{rsid}", where the PAT provides sufficient =
context to distinguish between identical resource set identifiers =
assigned by different hosts.

Calls to this API are made to that endpoint, but don't include it in the =
in-band HTTP request syntax. Does this make sense, or am I crazy?...

>=20
> --Amanda

Thanks again,

	Eve


Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl


--Apple-Mail=_361D0D34-317A-497B-AB3B-E17A5CECE00D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1250

aanganes@mitre.org> =
wrote:










Hi Eve =
and Thomas,









On =
12/27/12 8:11 PM, "Eve Maler" <eve@xmlgrrl.com> wrote:









Amanda, thanks for the lightning-fast comments back. A couple of =
additional notes on top of Thomas's response:







The "scope type" language is indeed new this time -- of course this =
whole modular spec is newly broken out, but the previous text from UMA's =
rev 05 still said "scope". (There's a new member in the JSON description =
of a resource set that is called "type",
 but this is actually the resource set's type: different thing.) Maybe =
this should just be changed back to "scope" and "scope description", as =
we really do mean the same construct as in plain OAuth, although here =
it's enhanced with a machine-readable description,
 and it's mappable to resource sets that have been explicitly =
identified. One thing we've been learning lately is that terminology =
impedance mismatches are not worth the cost; this one is a recent =
back-sliding. :)









I think it would make much more sense to stick with "scope" and =
"scope description". I assumed that you were trying to avoid collisions =
with OAuth by changing it, but it sounds like that is not the =
case. 







There might be a better way to denote that these are enhanced =
scopes, but "type" isn't quite right for that as it does imply a class =
or kind of thing (to which many particular things might belong), rather =
than a special or enhanced particular =
thing. 

Our experience =
so far is that enhanced versions of things should just use the name for =
the thing. Hence, in the UMA core spec we've finally started using OAuth =
terminology directly rather than sticking with our original names (which =
dated from OAuth 1.0). I for one find it a LOT clearer, now that OAuth's =
architecture has become more widely understood.















Eve: Regarding the sentence "Without a specific resource set =
identifier path component, the URI applies to the set of resource set =
descriptions already registered." in Section 2.3: I suspect this can =
just be deleted entirely. It's redundant with the "List
 resource set registrations" bullet item just below, which literally =
shows the {rsid} component of the path being absent. This is the only =
supported method in this API that has no {rsid} path component.








Thomas: Resource set registration =
API:  If Alice (the RO) has already previously registered some =
resources at the AS, then Alice will already have a PAT token (and
 the AS knows about Alice, her PAT, her resource sets and scopes). If =
Alice comes back again with the same PAT and forgets to specificy the =
path component, we assume the AS is smart enough to figure out which =
sets Alice is refering to. Does this help? (or does
 it still read weirdly).









These two explanations are very =
different. If Thomas's assessment is correct, I would move that =
explanatory text up to the end of the paragraph starting with "The
 authorization server MUST present an API=85" and explain that the PAT =
can also be used to figure out the {rsid} for any requests where it is =
left off (implying that the {rsid} component MAY be left off of any of =
the following API calls). Otherwise if Eve is
 correct and that additional caveat is NOT meant to be there, I would =
suggest removing the phrase entirely as it does seem to imply that =
{rsid} may be left =
off. 

I =
think Thomas might been thinking about a different issue we have faced =
in the past regarding URIs, which is the question of how =
protected-resource endpoints are disinguishable per resource owner. I =
won't deep-dive on that issue here to save confusion, but suffice to say =
I think we can remove the offending sentence.

















Regarding {rsreguri}: I do see it defined, in this same Section =
2.3. Basically this notation is simply a device to allow for referring =
to a "resource set registration endpoint" (defined in the Terminology =
section) in the URIs here that serve as method
 templates. Is there a better way to do this?









Yes, it is defined but not actually used to describe the API paths. =
The definition is fine but if it is there it should be used; for example =
the "Create resource set description" path should change from "PUT =
/resource_set/{rsid}" to "PUT =
{rsreguri}/resource_set/{rid}".

It's used just above the =
explanation: 

The authorization server MUST =
present an API for registering resource set descriptions at a set of =
URIs with the structure "{rsreguri}/resource_set/{rsid}", where the PAT =
provides sufficient context to distinguish between identical resource =
set identifiers assigned by different hosts.
Calls to this API are made to that endpoint, but =
don't include it in the in-band HTTP request syntax. Does this make =
sense, or am I crazy?...








--Amanda



Thanks =
again,

	Eve


Eve Maler       =
                    =
       http://www.xmlgrrl.com/blog
+1=
 425 345 6756                 =
        http://www.twitter.com/xmlgrrl=





=

--Apple-Mail=_361D0D34-317A-497B-AB3B-E17A5CECE00D--

From Michael.Jones@microsoft.com  Fri Dec 28 17:07:56 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D03A21F8E3F for ; Fri, 28 Dec 2012 17:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTa67aq8af6G for ; Fri, 28 Dec 2012 17:07:54 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.24]) by ietfa.amsl.com (Postfix) with ESMTP id 698A221F8E2A for ; Fri, 28 Dec 2012 17:07:50 -0800 (PST)
Received: from BY2FFO11FD008.protection.gbl (10.1.15.203) by BY2FFO11HUB025.protection.gbl (10.1.14.111) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sat, 29 Dec 2012 01:07:47 +0000
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sat, 29 Dec 2012 01:07:47 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Sat, 29 Dec 2012 01:07:46 +0000
From: Mike Jones 
To: "oauth@ietf.org" 
Thread-Topic: December 27, 2012 OAuth Release
Thread-Index: Ac3lYOVg59Z0pf6IRui17x5NiyOcmw==
Date: Sat, 29 Dec 2012 01:07:46 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.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.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669B0A1ETK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(31966008)(5343635001)(15202345001)(33656001)(77982001)(59766001)(5343655001)(51856001)(47446002)(50986001)(74502001)(53806001)(74662001)(49866001)(76482001)(512954001)(54316002)(47736001)(47976001)(5343665001)(56776001)(44976002)(16236675001)(56816002)(55846006)(16406001)(54356001)(46102001)(4396001)(6606295001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB025; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07106EF9B9
Subject: [OAUTH-WG] December 27, 2012 OAuth Release
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 01:07:56 -0000

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

New versions of the OAuth JWT, JWT Bearer Profile, and Assertions specs hav=
e been released incorporating feedback since IETF 85 in Atlanta.  The prima=
ry change is changing the name of the "prn" claim to "sub" (subject) both t=
o more closely align with SAML name usage and to use a more intuitive name =
for this concept.  (Also, see the related coordinated change to the OpenID =
Connect specifications.)  The definition =
of the "aud" (audience) claim was also extended to allow JWTs to have multi=
ple audiences (a feature also in SAML assertions).

An explanation was added to the JWT spec about why should be signed and the=
n encrypted.

The audience definition in the Assertions specification was relaxed so that=
 audience values can be OAuth "client_id" values.  Informative references t=
o the SAML Bearer Profile and JWT Bearer Profile specs were also added.
This release incorporates editorial improvements suggested by Jeff Hodges, =
Hannes Tschofenig, and Prateek Mishra in their reviews of the JWT specifica=
tion.  Many of these simplified the terminology usage.  See the Document Hi=
story section of each specification for more details about the changes made=
.

This release is part of a coordinated release of JOSE, OAuth, and OpenID Co=
nnect specifications.  You can read about the other releases here:  JOSE Re=
lease Notes, OpenID Connect Release Notes=
.

The new specification versions are:

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

*        http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04

*        http://tools.ietf.org/html/draft-ietf-oauth-assertions-09

HTML formatted versions are available at:

*        http://self-issued.info/docs/draft-ietf-oauth-json-web-token-06.ht=
ml

*        http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-04.html

*        http://self-issued.info/docs/draft-ietf-oauth-assertions-09.html

                                                            -- Mike


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











New versions of the OAuth JWT, JWT Bearer Profile, a=
nd Assertions specs have been released incorporating feedback since IETF 85=
 in Atlanta.  The primary change is changing the name of the “prn”
 claim to “sub” (subject) both to more closely align with SAML name usage and t=
o use a more intuitive name for this concept.  (Also, see the related
coordinated change to the Open=
ID Connect specifications.)  The definition of the “aud” (audience) cl=
aim was also extended to allow JWTs to have multiple audiences (a
 feature also in SAML assertions).


 


An explanation was added to the JWT spec about why s=
hould be signed and then encrypted.


 


The audience definition in the Assertions specificat=
ion was relaxed so that audience values can be OAuth “client_id” values.  =
Informative references to the SAML Bearer Profile and JWT Bearer
 Profile specs were also added.




This release incorporates editorial improvements sug=
gested by Jeff Hodges, Hannes Tschofenig, and Prateek Mishra in their revie=
ws of the JWT specification.  Many of these simplified the terminology=
 usage.  See the Document History section
 of each specification for more details about the changes made.<=
/p>

 


This release is part of a coordinated release of JOS=
E, OAuth, and OpenID Connect specifications.  You can read about the o=
ther releases here: 
JOSE Release Notes, 
OpenID Connect Release Notes.


 


The new specification versions are:


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


·       
http://tools.ietf.org/html/draft-ietf-oauth-jwt-b=
earer-04


·       
http://tools.ietf.org/html/draft-ietf-oauth-asser=
tions-09


 


HTML formatted versions are available at:=



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


·       
http://self-issued.info/docs/draft-ietf-oa=
uth-jwt-bearer-04.html


·       
http://self-issued.info/docs/draft-ietf-oa=
uth-assertions-09.html


 


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


 






--_000_4E1F6AAD24975D4BA5B1680429673943669B0A1ETK5EX14MBXC283r_--

From Michael.Jones@microsoft.com  Fri Dec 28 17:10:24 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7BD21F8E30 for ; Fri, 28 Dec 2012 17:10:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb6IGouVh6iz for ; Fri, 28 Dec 2012 17:10:14 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2D04F21F8E1D for ; Fri, 28 Dec 2012 17:10:14 -0800 (PST)
Received: from BL2FFO11FD008.protection.gbl (10.173.161.204) by BL2FFO11HUB037.protection.gbl (10.173.160.241) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sat, 29 Dec 2012 01:10:10 +0000
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sat, 29 Dec 2012 01:10:10 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Sat, 29 Dec 2012 01:10:08 +0000
From: Mike Jones 
To: '=JeffH' , 'IETF oauth WG' 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYTXykKfJ1TsWSvG7/OFVVl60vg==
Date: Sat, 29 Dec 2012 01:10:07 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669B0A79@TK5EX14MBXC283.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.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669B0A79TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(43784002)(377454001)(13464002)(51704002)(44976002)(47736001)(31966008)(16236675001)(54316002)(47446002)(74662001)(550184003)(74502001)(56816002)(33656001)(15202345001)(47976001)(59766001)(56776001)(55846006)(50986001)(76482001)(15395725002)(77982001)(16406001)(46102001)(54356001)(4396001)(5343645001)(512954001)(49866001)(5343635001)(51856001)(5343655001)(53806001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB037; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07106EF9B9
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 01:10:24 -0000

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

Thanks again for the detailed and useful review, Jeff.  Edits resulting fro=
m your suggestions are now in the latest published drafts.

                                                            Thanks again!
                                                            -- Mike

From: Mike Jones
Sent: Wednesday, December 19, 2012 4:15 PM
To: '=3DJeffH'; IETF oauth WG
Subject: RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05


Thanks a bunch for the useful review, Jeff!  Responses are inline in green.



                                                                -- Mike



-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of =3DJeffH
Sent: Tuesday, November 27, 2012 2:23 PM
To: IETF oauth WG
Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05



Hi, at ietf-85 atlanta I agreed to do a review of draft-ietf-oauth-json-web=
-token-05, and so I have some thoughts below. Also, +1 to Hannes' comments.



Overall the spec seems to get its idea across, but is pretty rough. Part of=
 this is due to the language being convoluted, plus some concepts are only =
tacitly described (with clues scattered throughout the spec), and thus it i=
s difficult to understand without multiple passes of this spec as well as [=
JWE] and [JWS].



For example, a JWT appears to be simply either a JWS or a JWE containing a =
JWT Claims Set, but this is not stated until right before section 3.1 (and =
it isn't stated that clearly).



OK, I'll say that earlier and more clearly.



Immediately below are some overall comments, and then below that some detai=
led comments on various portions of the spec.  I'm not addressing everythin=
g I noticed due to time constraints (apologies).



HTH



=3DJeffH

------





JWT terminology:



Some issues seem to me to be caused by defining the JWT to be the base64url=
 encoded JSON  object itself and not having terminology to clearly refer to=
 its unencoded form.



For example, these two JSON objects together apparently comprise a (unencod=
ed) JWT..



      {"typ":"JWT",

       "alg":"HS256"}



This is the JWT Header.  The base64url encoded version is the Encoded JWT H=
eader.



      {"iss":"joe",

       "exp":1300819380,

       "http://example.com/is_root":true}



This is the JWT Claims Set.



..but there's no defined way to refer to them given the spec's terminlogy.



The terms above are already defined in the spec.



Consider terming the above a JWT and its encoded-string form an Encoded JWT=
, and define them separately. And then there'll be similar definitions for =
JWT Header and JWT Claims Set, e.g.,



I disagree with redefining the term "JWT" to not also include the signature=
.  The term "JWT" should continue to refer to the whole thing.



    Encoded JWT   A JWT that has been encoded according to the

       process defined in Section X.



    Encoded JWT Header   The encoded-string form of a JWT Header



    Encoded JWT Claims Set   The encoded-string form of a JWT Claims Set



I'll note that when the JWT is encrypted, a base64url encoded representatio=
n of the JWT Claims Set is never used.  (The encrypted form of them is base=
64url encoded instead.)



    encoded-string form   The result of applying Base64url encoding to an

       input JSON text .



Sometimes he input to the base64url encoding is not JSON - for instance sig=
nature values or encrypted payloads.



    JSON Web Token (JWT)  A JWT comprises a JWT Header and a JWT Claims Set=
. ...



    JWT Header  A JSON object that is a component of a JWT. It denotes the

       cryptographic operations applied to the JWT.  ...



    JWT Claims Set  A JSON object containing a set of claims.  ...



This also gets rid of the use of the "A string representing a JSON object..=
."

which I find confusing and potentially misleading (because it is actually "=
a Base64url encoding of a JSON object").



Aah - I now see that this is the real misunderstanding.  The "string repres=
enting a JSON object" is not the base64url encoded form - it's the string r=
epresentation that's parseable into a JSON object.  For instance, it could =
be a string such as {"alg":"RS256"} - not the base64url encoded version of =
that string.  The reason for the syntactic construction "string representin=
g a JSON object" is that its string representation is distinct from the abs=
tract JSON object itself.  If I insert whitespace after the colon in the st=
ring {"alg":"RS256"} it would parse to an equivalent JSON object but it wou=
ld be a different string representation.  It's the string representation th=
at is actually operated on by the JWT/JWS/JWE operations.



I'll try to make this clearer in the spec.



UTF-8:



UTF-8 is mentioned in lots of places. It could probably be stated once up n=
ear

the beginning of the spec that all the JSON text is UTF-8 encoded, and all =
the

JSON strings are UTF-8 encoded.



I'll see if I can figure out how to do this without introducing ambiguity.



Semantics, profiles and relationship to SAML:



The spec does not define any overall JWT semantics (i.e., what any given JW=
T

/means/). Semantics are only defined in context of each individual Reserved

Claim Name.



Thus any application of JWTs will need to profile the JWT spec: specifying =
the

claim set(s) contents, and the overall semantics of the resultant JWT(s).  =
This

is not explicitly explained in the JWT spec.



Can you suggest some language you'd like to see added about this?



In terms of SAML, Appendix B should refer to SAML assertions rather than sa=
ml

tokens. Also, I'm not sure SAML assertions inherently have more expressivit=
y

than JWTs. They do have more pre-defined structure and semantics.



OK



Syntactically, it seems one can encode pretty much anything in whatever amo=
unt

in a JWT (one can do the same with SAML assertions), and thus theoretically=
 JWTs

could be used to accomplish the same things as SAML assertions.



Semantically, SAML assertions are explicitly statements made by a system en=
tity

about a subject. But by default, a JWT is empty, and has no semantics (this

isn't stated explicitly). All semantics defined in the JWT spec are particu=
lar

to individual reserved claims, but all reserved claims are optional. Thus a=
n

application of JWTs to use cases also apropos for SAML assertions will requ=
ire

arguably more profiling than that needed to apply SAML assertions.



All true.  However once you add an issuer and a principal, then you're back=
 to the JWT being statements made by an entity about a subject.  Again, if =
there is language you believe should be added in that regard, please let me=
 know.  (BTW, one such usage profile is in http://tools.ietf.org/html/draft=
-ietf-oauth-jwt-bearer-03.  Another is in http://openid.net/specs/openid-co=
nnect-messages-1_0.html#id_token.)



The token size & complexity comparison seems nominally fine.



Some detailed-but-rough comments and musings on portions of the spec as I w=
as

reading through it...



> 2. Terminology



terminology is not alphabetised!



No, it's in a top-down descriptive order.  Is there a requirement in IETF s=
pecs that the terminology be alphabetized?



"claim", "claims", "token" should be defined in terminology



I'll add a definition for "claim".  "token" should actually probably become=
 "security token", with a definition of the term.



suggestion:



      Claim:  an assertion of something as a fact. Here, claims are

         name and value pairs, consisting of a Claim Name and a

         Claim Value.





>    JSON Web Token (JWT)



   is jwt always a "string" or is it string (only) when it's been serialize=
d

into one?



It's always the string representation of the serialized parts.



>                    A string representing a set of claims as a JSON

>       object that is digitally signed or MACed and/or encrypted.



   is it more that it's a set of claims encoded as a JSON object

   that is string-serialized?



No, per my earlier comments



   is it /not/ a JWT by definition if it is not ((signed or unmac'd) and/or

encrypted) ?   No, because there are Plaintext JWTs, but they aren't in

terminology (probably should be).



Good catch



   "parts" in JWT definition is unclear

     are "parts" json objects or arrays unto themselves ?



The parts are all base64url encoded values.  I'll review this terminology u=
sage to see if it can be clarified.



   the definition assumes knowledge that's presented later. perhaps needs f=
wd

   reference(s), or perhaps better is to not present as much technical deta=
il

   in the definitions.



I'll review



>    JWT Claims Set



   similar comments as to JSON Web Token (JWT)



   the definition says how it is encoded and encrypted, but not how claims =
are

mapped into a JSON object





should probably be simply:



    JWT Claims Set: A set of claims expressed as a JSON object, where each

       claim is an object member (i.e., a name/value pair). A claim may hav=
e

       a JWT Claims Set as a value.



I'll look into moving the definition in this direction.  What you're missin=
g in the above, though, is the distinction between the string representing =
the JSON object and the abstract JSON object.  We want the former.



>    Claim Name  The name of a member of the JSON object representing a

>       JWT Claims Set.



should probably be simply:



    Claim Name  The name portion of a claim, expressed as a JSON object mem=
ber

       name.





>    Claim Value  The value of a member of the JSON object representing a

>       JWT Claims Set.



should probably be simply:



    Claim Value  The value portion of a claim, expressed as a JSON object m=
ember

       value.



I'll look into moving the definitions in this direction.



> 3. JSON Web Token (JWT) Overview



>    The bytes of the UTF-8 representation of the JWT Claims Set are

>    digitally signed or MACed in the manner described in JSON Web

>    Signature (JWS) [JWS] and/or encrypted in the manner described in

>    JSON Web Encryption (JWE) [JWE].



s/ and/or encrypted / or encrypted and signed /



I think you mean "encrypted and integrity protected" rather than "encrypted=
 and signed", right?



>    The contents of the JWT Header describe the cryptographic operations

>    applied to the JWT Claims Set. If the JWT Header is a JWS Header, the

>    claims are digitally signed or MACed.  If the JWT Header is a JWE

>    Header, the claims are encrypted.



What if a JWT is signed AND encrypted?  Hm, from my looking at JWS and JWE

specs, it seems that in that case one uses JWE because that encompasses bot=
h

encrypt & sign.



No, actually JWE just provides an integrity check - not a signature.  If yo=
u want a signature, you need to use JWS.  They can (and often are) used in =
a nested fashion.



>    A JWT is represented as a JWS or JWE.  The number of parts is

>    dependent upon the representation of the resulting JWS or JWE.



Does the above mean to say..



    A JWT consists of a JWS or JWE object, which in turn conveys the JWT

    Claims Set. In the case of a JWS, the JWT Claims Set is the JWS

    Payload. In the case of a JWE, the JWT Claims Set is the input

    Plaintext.



Yes.  Although this is missing the fact that nested signing/encryption may =
be employed.



> 4. JWT Claims

>

>

>    The JWT Claims Set represents a JSON object whose members are the

>    claims conveyed by the JWT.  The Claim Names within this object MUST

>    be unique; JWTs with duplicate Claim Names MUST be rejected.



does the above mean to say claim names must be unique amongst the set of cl=
aim

names within any given JWT Claims Set ?  If so, that's only implied by the =
above

but should be stated explicitly; as it is, the above is ambiguous.



OK



> 4.2. Public Claim Names

>

>

>    Claim names can be defined at will by those using JWTs.  However, in



s/Claim names/Public claim names/



>    order to prevent collisions, any new claim name SHOULD either be

>    registered in the IANA JSON Web Token Claims registry Section 9.1 or

>    be a URI that contains a Collision Resistant Namespace.





why should a claim name be a URI if I wish to make use of Collision Resista=
nt

Namespaces?  For example, if I simply use say UUIDs as claim names..



      {"iss":"joe",

       "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}



..it will be universally unique provided I minted it appropriately (no URI

syntax is needed).



Fair enough.  I'll try to generalize the language.



> 4.3. Private Claim Names

>

>

>    A producer and consumer of a JWT may agree to any claim name that is

>    not a Reserved Name Section 4.1 or a Public Name Section 4.2.  Unlike

>    Public Names, these private names are subject to collision and should

>    be used with caution.



it seems private claim names are only subject to collision if the implement=
ers

don't make appropriate use of Collision Resistant Namespaces, i.e. they "ca=
n be"

subject to collision.



True



the above two sections use "public" and "private" as distinguishing factors=
, but

it seems to me the distinguishing factor (given how the above is written) i=
s

more whether Collision Resistant Namespaces are employed or not.



Yes, although using a collision resistant namespace effectively makes them =
public, as we're using the term



An implied aspect of public claim names seems to be that it is assumed that=
 they

are publicly listed/documented/leaked, thus the "public" moniker, and hence

ought to be universally unique as a matter of course.



and "private" ones seem to be assumed to be obfuscated to all but the agree=
ing

parties?  Or they are "private" in only the sense that they are created in =
the

context of a private arrangement?



Private in that they are created in the context of a private arrangement.  =
I'll try to clarify this point.  Facebook could define how they're going to=
 use the "id" claim very publicly, and yet it would still be a private clai=
m if not registered with IANA.



>

> 7. Rules for Creating and Validating a JWT

>

>

>    To create a JWT, one MUST perform these steps.  The order of the

>    steps is not significant in cases where there are no dependencies

>    between the inputs and outputs of the steps.

>

>    1.  Create a JWT Claims Set containing the desired claims.  Note that

>        white space is explicitly allowed in the representation and no

>        canonicalization is performed before encoding.



I presume the rationale for allowing white space is that JSON objects are

unordered (and can contain arbitrary whitespace), thus simple buffer-to-buf=
fer

comparisons between serialized objects cannot be reliably performed.  If so=
 this

should be explicitly stated.



Actually, it's to avoid canonicalization.  I'll reread the spec to see if w=
e've stated that clearly or not.



It seems that member/value-by-member/value comparisons must always be done,=
 by

parsing the JSON objects and extracting all members and values, this should=
 be

stated explicitly in the spec.



I found meager jwt comparison instructions at the very end of Section 7. it

should probably be its own subsection. It should probably explicitly say th=
at

JWTs need to be parsed into their constituent components, and the latter mu=
st be

individually examined/compared.



We tried to cover this in the end of section 7, starting with the sentence =
"Processing a JWT inevitably requires comparing known strings to values in =
the token", which says how these comparisons must be performed.  I agree th=
at this should become its own subsection.  I don't understand your remark a=
bout constituent components.  Can you clarify?



>    Comparisons between JSON strings and other Unicode strings MUST be

>    performed as specified below:



this comparison algorithm seems to be attempting to allow for comparison of

UTF-8 encoded JSON strings with other unicode strings in any of the unicode

encoding formats, but only implies that; it should be stated.



Good



>

>    1.  Remove any JSON applied escaping to produce an array of Unicode

>        code points.



I don't think (1) is correct.  A JSON string is by default encoded in UTF-8=
. A

UTF-8 encoded string is not "an array of Unicode code points" (its a sequen=
ce of

code units, which must be decoded into code points), i think a step is miss=
ing

here..



    1.  Remove any JSON escaping from the input JSON string.



    1.a  convert the string into a sequence of unicode code points.



How about "Remove any JSON escaping from the input JSON string and convert =
the string into a sequence of Unicode code points"?



..and then compare code point-by-code point. This overall algorithm /seems/=
 ok,

but I'm not sure, it seems there's rationale that's not expressed, eg for

excluding use of Unicode Normalization [USA15]. Also the alg is incomplete =
in

that it doesn't stipulate converting the "other unicode string" into a sequ=
ence

of code points.



Fair enough



> 10. Security Considerations

>

>

>    All of the security issues faced by any cryptographic application

>    must be faced by a JWT/JWS/JWE/JWK agent.  Among these issues are

>    protecting the user's private key, preventing various attacks, and

>    helping the user avoid mistakes such as inadvertently encrypting a

>    message for the wrong recipient.  The entire list of security

>    considerations is beyond the scope of this document, but some

>    significant concerns are listed here.

>

>    All the security considerations in the JWS specification also apply

>    to JWT, as do the JWE security considerations when encryption is

>    employed.  In particular, the JWS JSON Security Considerations and

>    Unicode Comparison Security Considerations apply equally to the JWT

>    Claims Set in the same manner that they do to the JWS Header.

>



dunno if you can get away with sec cons wholly in other docs, and I'm not s=
ure

it's appropriate given that JWTs are a profile of JWE or JWS.



That was the approach that Sean had suggested.  If there other things you t=
hink we should specifically add, however, please let me know.



above needs editorial polish -- there aren't any  "significant concerns"

actually listed here.



True enough



---

end





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

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











Thanks again for the d=
etailed and useful review, Jeff.  Edits resulting from your suggestion=
s are now in the latest published drafts.


 


   &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p;      Thanks again!


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


 






From: Mike Jon=
es


Sent: Wednesday, December 19, 2012 4:15 PM

To: '=3DJeffH'; IETF oauth WG

Subject: RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05






 


Thanks a bunch for the useful review, Jeff! =
 Responses are inline
in green.


 


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


 


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

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

Sent: Tuesday, November 27, 2012 2:23 PM

To: IETF oauth WG

Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05

 


Hi, at ietf-85 atlanta I agreed to do a review of=
 draft-ietf-oauth-json-web-token-05, and so I have some thoughts below. Als=
o, +1 to Hannes' comments.


 


Overall the spec seems to get its idea across, bu=
t is pretty rough. Part of this is due to the language being convoluted, pl=
us some concepts are only tacitly described (with clues scattered throughou=
t the spec), and thus it is difficult
 to understand without multiple passes of this spec as well as [JWE] and [J=
WS].


 


For example, a JWT appears to be simply either a =
JWS or a JWE containing a JWT Claims Set, but this is not stated until righ=
t before section 3.1 (and it isn't stated that clearly).


 


OK, I’ll say =
that earlier and more clearly.


 


Immediately below are some overall comments, and =
then below that some detailed comments on various portions of the spec.&nbs=
p; I'm not addressing everything I noticed due to time constraints (apologi=
es).


 


HTH


 


=3DJeffH


------


 


 


JWT terminology:


 


Some issues seem to me to be caused by defining t=
he JWT to be the base64url encoded JSON  object itself and not having =
terminology to clearly refer to its unencoded form.


 


For example, these two JSON objects together appa=
rently comprise a (unencoded) JWT..


 


      {"typ":&=
quot;JWT",


       "alg&qu=
ot;:"HS256"}


 


This is the JWT Hea=
der.  The base64url encoded version is the Encoded JWT Header.


 


      {"iss":&=
quot;joe",


       "exp&qu=
ot;:1300819380,


       "http://example.com/is_root":true}

 


This is the JWT Cla=
ims Set.


 


..but there's no defined way to refer to them giv=
en the spec's terminlogy.


 


The terms above are=
 already defined in the spec.


 


Consider terming the above a JWT and its encoded-=
string form an Encoded JWT, and define them separately. And then there'll b=
e similar definitions for JWT Header and JWT Claims Set, e.g.,

 


I disagree with red=
efining the term “JWT” to not also include the signature. =
 The term “JWT” should continue to refer to the whole thing.


 


    Encoded JWT   A JWT =
that has been encoded according to the


       process defi=
ned in Section X.


 


    Encoded JWT Header  =
 The encoded-string form of a JWT Header


 


    Encoded JWT Claims Set &n=
bsp; The encoded-string form of a JWT Claims Set


 


I’ll note tha=
t when the JWT is encrypted, a base64url encoded representation of the JWT =
Claims Set is never used.  (The encrypted form of them is base64url en=
coded instead.)


 


    encoded-string form  =
; The result of applying Base64url encoding to an


       input JSON t=
ext .


 


Sometimes he input =
to the base64url encoding is not JSON – for instance signature values=
 or encrypted payloads.


 


    JSON Web Token (JWT)  A J=
WT comprises a JWT Header and a JWT Claims Set. ...


 


    JWT Header  A JSON object=
 that is a component of a JWT. It denotes the


       cryptographi=
c operations applied to the JWT.  ...


 


    JWT Claims Set  A JSON ob=
ject containing a set of claims.  ...


 


This also gets rid of the use of the "A stri=
ng representing a JSON object..."



which I find confusing and potentially misleading=
 (because it is actually "a Base64url encoding of a JSON object")=
.


 


Aah – I now s=
ee that this is the real misunderstanding.  The “string represen=
ting a JSON object” is not the base64url encoded form – it̵=
7;s the string representation that’s parseable into a JSON object.&nb=
sp; For
 instance, it could be a string such as {“alg”:”RS256R=
21;} – not the base64url encoded version of that string.  The re=
ason for the syntactic construction “string representing a JSON objec=
t” is that its string representation is distinct from the abstract JS=
ON object
 itself.  If I insert whitespace after the colon in the string {“=
;alg”:”RS256”} it would parse to an equivalent JSON objec=
t but it would be a different string representation.  It’s the s=
tring representation that is actually operated on by the JWT/JWS/JWE operat=
ions.


 


I’ll try to m=
ake this clearer in the spec.


 


UTF-8:


 


UTF-8 is mentioned in lots of places. It could pr=
obably be stated once up near



the beginning of the spec that all the JSON text =
is UTF-8 encoded, and all the



JSON strings are UTF-8 encoded.


 


I’ll see if I=
 can figure out how to do this without introducing ambiguity.


 


Semantics, profiles and relationship to SAML:


 


The spec does not define any overall JWT semantic=
s (i.e., what any given JWT



/means/). Semantics are only defined in context o=
f each individual Reserved



Claim Name.


 


Thus any application of JWTs will need to profile=
 the JWT spec: specifying the



claim set(s) contents, and the overall semantics =
of the resultant JWT(s).  This



is not explicitly explained in the JWT spec.=



 


Can you suggest som=
e language you’d like to see added about this?


 


In terms of SAML, Appendix B should refer to SAML=
 assertions rather than saml



tokens. Also, I'm not sure SAML assertions inhere=
ntly have more expressivity



than JWTs. They do have more pre-defined structur=
e and semantics.


 


OK


 


Syntactically, it seems one can encode pretty muc=
h anything in whatever amount



in a JWT (one can do the same with SAML assertion=
s), and thus theoretically JWTs



could be used to accomplish the same things as SA=
ML assertions.


 


Semantically, SAML assertions are explicitly stat=
ements made by a system entity



about a subject. But by default, a JWT is empty, =
and has no semantics (this



isn't stated explicitly). All semantics defined i=
n the JWT spec are particular



to individual reserved claims, but all reserved c=
laims are optional. Thus an



application of JWTs to use cases also apropos for=
 SAML assertions will require



arguably more profiling than that needed to apply=
 SAML assertions.


 


All true.  How=
ever once you add an issuer and a principal, then you’re back to the =
JWT being statements made by an entity about a subject.  Again, if the=
re is language you believe should be added in that regard,
 please let me know.  (BTW, one such usage profile is in http://tool=
s.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.  Another is in
http://openid.net/specs/openid-connect-messages-1_0.html#id_token=
.)


 


The token size & complexity comparison seems =
nominally fine.


 


Some detailed-but-rough comments and musings on p=
ortions of the spec as I was



reading through it...


 


> 2. Terminology


 


terminology is not alphabetised!


 


No, it’s in a=
 top-down descriptive order.  Is there a requirement in IETF specs tha=
t the terminology be alphabetized?


 


"claim", "claims", "toke=
n" should be defined in terminology


 


I’ll add a de=
finition for “claim”.  “token” should actually=
 probably become “security token”, with a definition of the ter=
m.


 


suggestion:


 


      Claim:  an as=
sertion of something as a fact. Here, claims are


         =
name and value pairs, consisting of a Claim Name and a


         =
Claim Value.


 


 


>    JSON Web Token (JWT)<=
/o:p>


 


   is jwt always a "string" o=
r is it string (only) when it's been serialized



into one?


 


It’s always t=
he string representation of the serialized parts.


 


>       &nb=
sp;            A str=
ing representing a set of claims as a JSON


>       object t=
hat is digitally signed or MACed and/or encrypted.


 


   is it more that it's a set of claims=
 encoded as a JSON object


   that is string-serialized?


 


No, per my earlier =
comments 



 


   is it /not/ a JWT by definition if i=
t is not ((signed or unmac'd) and/or



encrypted) ?   No, because there are Pl=
aintext JWTs, but they aren't in



terminology (probably should be).


 


Good catch


 


   "parts" in JWT definition =
is unclear


     are "parts" js=
on objects or arrays unto themselves ?


 


The parts are all b=
ase64url encoded values.  I’ll review this terminology usage to =
see if it can be clarified.


 


   the definition assumes knowledge tha=
t's presented later. perhaps needs fwd


   reference(s), or perhaps better is t=
o not present as much technical detail


   in the definitions.


 


I’ll review


 


>    JWT Claims Set<=
/p>

 


   similar comments as to JSON Web Toke=
n (JWT)


 


   the definition says how it is encode=
d and encrypted, but not how claims are



mapped into a JSON object


 


 


should probably be simply:


 


    JWT Claims Set: A set of claim=
s expressed as a JSON object, where each


       claim is an =
object member (i.e., a name/value pair). A claim may have


       a JWT Claims=
 Set as a value.


 


I’ll look int=
o moving the definition in this direction.  What you’re missing =
in the above, though, is the distinction between the string representing th=
e JSON object and the abstract JSON object.  We want
 the former.


 


>    Claim Name  The name =
of a member of the JSON object representing a


>       JWT Clai=
ms Set.


 


should probably be simply:


 


    Claim Name  The name port=
ion of a claim, expressed as a JSON object member


       name.


 


 


>    Claim Value  The valu=
e of a member of the JSON object representing a


>       JWT Clai=
ms Set.


 


should probably be simply:


 


    Claim Value  The value po=
rtion of a claim, expressed as a JSON object member


       value.<=
/o:p>


 


I’ll look int=
o moving the definitions in this direction. 



 


> 3. JSON Web Token (JWT) Overview<=
/p>

 


>    The bytes of the UTF-8 rep=
resentation of the JWT Claims Set are


>    digitally signed or MACed =
in the manner described in JSON Web


>    Signature (JWS) [JWS] and/=
or encrypted in the manner described in


>    JSON Web Encryption (JWE) =
[JWE].


 


s/ and/or encrypted / or encrypted and signed /


 


I think you mean &#=
8220;encrypted and integrity protected” rather than “encrypted =
and signed”, right?


 


>    The contents of the JWT He=
ader describe the cryptographic operations


>    applied to the JWT Claims =
Set. If the JWT Header is a JWS Header, the


>    claims are digitally signe=
d or MACed.  If the JWT Header is a JWE


>    Header, the claims are enc=
rypted.


 


What if a JWT is signed AND encrypted?  Hm, =
from my looking at JWS and JWE



specs, it seems that in that case one uses JWE be=
cause that encompasses both



encrypt & sign.


 


No, actually JWE ju=
st provides an integrity check – not a signature.  If you want a=
 signature, you need to use JWS.  They can (and often are) used in a n=
ested fashion.


 


>    A JWT is represented as a =
JWS or JWE.  The number of parts is


>    dependent upon the represe=
ntation of the resulting JWS or JWE.


 


Does the above mean to say..


 


    A JWT consists of a JWS or JWE=
 object, which in turn conveys the JWT


    Claims Set. In the case of a J=
WS, the JWT Claims Set is the JWS


    Payload. In the case of a JWE,=
 the JWT Claims Set is the input


    Plaintext.


 


Yes.  Although=
 this is missing the fact that nested signing/encryption may be employed.


 


> 4. JWT Claims


> 


> 


>    The JWT Claims Set represe=
nts a JSON object whose members are the


>    claims conveyed by the JWT=
.  The Claim Names within this object MUST


>    be unique; JWTs with dupli=
cate Claim Names MUST be rejected.


 


does the above mean to say claim names must be un=
ique amongst the set of claim



names within any given JWT Claims Set ?  If =
so, that's only implied by the above



but should be stated explicitly; as it is, the ab=
ove is ambiguous.


 


OK


 


> 4.2. Public Claim Names


> 


> 


>    Claim names can be defined=
 at will by those using JWTs.  However, in


 


s/Claim names/Public claim names/


 


>    order to prevent collision=
s, any new claim name SHOULD either be


>    registered in the IANA JSO=
N Web Token Claims registry Section 9.1 or


>    be a URI that contains a C=
ollision Resistant Namespace.


 


 


why should a claim name be a URI if I wish to mak=
e use of Collision Resistant



Namespaces?  For example, if I simply use sa=
y UUIDs as claim names..


 


      {"iss":&=
quot;joe",


       "3005fa=
05-e76c-4994-bbc9-65b2ace2305c":"foo"}


 


..it will be universally unique provided I minted=
 it appropriately (no URI



syntax is needed).


 


Fair enough.  =
I’ll try to generalize the language.


 


> 4.3. Private Claim Names


> 


> 


>    A producer and consumer of=
 a JWT may agree to any claim name that is


>    not a Reserved Name Sectio=
n 4.1 or a Public Name Section 4.2.  Unlike


>    Public Names, these privat=
e names are subject to collision and should


>    be used with caution.=



 


it seems private claim names are only subject to =
collision if the implementers



don't make appropriate use of Collision Resistant=
 Namespaces, i.e. they "can be"



subject to collision.


 


True


 


the above two sections use "public" and=
 "private" as distinguishing factors, but



it seems to me the distinguishing factor (given h=
ow the above is written) is



more whether Collision Resistant Namespaces are e=
mployed or not.


 


Yes, although using=
 a collision resistant namespace effectively makes them public, as we’=
;re using the term


 


An implied aspect of public claim names seems to =
be that it is assumed that they



are publicly listed/documented/leaked, thus the &=
quot;public" moniker, and hence



ought to be universally unique as a matter of cou=
rse.


 


and "private" ones seem to be assumed t=
o be obfuscated to all but the agreeing



parties?  Or they are "private" in=
 only the sense that they are created in the



context of a private arrangement?


 


Private in that the=
y are created in the context of a private arrangement.  I’ll try=
 to clarify this point.  Facebook could define how they’re going=
 to use the “id” claim very publicly, and yet it would still
 be a private claim if not registered with IANA.


 


> 


> 7. Rules for Creating and Validating a JWT


> 


> 


>    To create a JWT, one MUST =
perform these steps.  The order of the


>    steps is not significant i=
n cases where there are no dependencies


>    between the inputs and out=
puts of the steps.


> 


>    1.  Create a JWT Clai=
ms Set containing the desired claims.  Note that


>        wh=
ite space is explicitly allowed in the representation and no


>        ca=
nonicalization is performed before encoding.


 


I presume the rationale for allowing white space =
is that JSON objects are



unordered (and can contain arbitrary whitespace),=
 thus simple buffer-to-buffer



comparisons between serialized objects cannot be =
reliably performed.  If so this



should be explicitly stated.


 


Actually, it’=
s to avoid canonicalization.  I’ll reread the spec to see if we&=
#8217;ve stated that clearly or not.


 


It seems that member/value-by-member/value compar=
isons must always be done, by



parsing the JSON objects and extracting all membe=
rs and values, this should be



stated explicitly in the spec.


 


I found meager jwt comparison instructions at the=
 very end of Section 7. it



should probably be its own subsection. It should =
probably explicitly say that



JWTs need to be parsed into their constituent com=
ponents, and the latter must be



individually examined/compared.


 


We tried to cover t=
his in the end of section 7, starting with the sentence “Processing a=
 JWT inevitably requires comparing known strings to values in the tokenR=
21;, which says how these comparisons must be performed. 
 I agree that this should become its own subsection.  I don’t un=
derstand your remark about constituent components.  Can you clarify?


 


>    Comparisons between JSON s=
trings and other Unicode strings MUST be


>    performed as specified bel=
ow:


 


this comparison algorithm seems to be attempting =
to allow for comparison of



UTF-8 encoded JSON strings with other unicode str=
ings in any of the unicode



encoding formats, but only implies that; it shoul=
d be stated.


 


Good


 


> 


>    1.  Remove any JSON a=
pplied escaping to produce an array of Unicode


>        co=
de points.


 


I don't think (1) is correct.  A JSON string=
 is by default encoded in UTF-8. A



UTF-8 encoded string is not "an array of Uni=
code code points" (its a sequence of



code units, which must be decoded into code point=
s), i think a step is missing



here..


 


    1.  Remove any JSON escap=
ing from the input JSON string.


 


    1.a  convert the string i=
nto a sequence of unicode code points.


 


How about “Re=
move any JSON escaping from the input JSON string and convert the string in=
to a sequence of Unicode code points”?


 


..and then compare code point-by-code point. This=
 overall algorithm /seems/ ok,



but I'm not sure, it seems there's rationale that=
's not expressed, eg for



excluding use of Unicode Normalization [USA15]. A=
lso the alg is incomplete in



that it doesn't stipulate converting the "ot=
her unicode string" into a sequence



of code points.


 


Fair enough


 


> 10. Security Considerations


> 


> 


>    All of the security issues=
 faced by any cryptographic application


>    must be faced by a JWT/JWS=
/JWE/JWK agent.  Among these issues are


>    protecting the user's priv=
ate key, preventing various attacks, and


>    helping the user avoid mis=
takes such as inadvertently encrypting a


>    message for the wrong reci=
pient.  The entire list of security


>    considerations is beyond t=
he scope of this document, but some


>    significant concerns are l=
isted here.


> 


>    All the security considera=
tions in the JWS specification also apply


>    to JWT, as do the JWE secu=
rity considerations when encryption is


>    employed.  In particu=
lar, the JWS JSON Security Considerations and


>    Unicode Comparison Securit=
y Considerations apply equally to the JWT


>    Claims Set in the same man=
ner that they do to the JWS Header.


> 


 


dunno if you can get away with sec cons wholly in=
 other docs, and I'm not sure



it's appropriate given that JWTs are a profile of=
 JWE or JWS.


 


That was the approa=
ch that Sean had suggested.  If there other things you think we should=
 specifically add, however, please let me know.


 


above needs editorial polish -- there aren't any&=
nbsp; "significant concerns"



actually listed here.


 


True enough


 


---


end


 


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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






--_000_4E1F6AAD24975D4BA5B1680429673943669B0A79TK5EX14MBXC283r_--

From Michael.Jones@microsoft.com  Fri Dec 28 17:10:45 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7721F8E40 for ; Fri, 28 Dec 2012 17:10:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhsBYNTUvDaf for ; Fri, 28 Dec 2012 17:10:34 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 79D8821F8E3F for ; Fri, 28 Dec 2012 17:10:34 -0800 (PST)
Received: from BY2FFO11FD008.protection.gbl (10.1.15.202) by BY2FFO11HUB018.protection.gbl (10.1.14.92) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sat, 29 Dec 2012 01:10:32 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sat, 29 Dec 2012 01:10:32 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Sat, 29 Dec 2012 01:10:30 +0000
From: Mike Jones 
To: 'prateek mishra' , "'oauth@ietf.org'" 
Thread-Topic: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token
Thread-Index: Ac3lYUWWUI56pF+VQAWhkhhAuiLHSw==
Date: Sat, 29 Dec 2012 01:10:29 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669B0A9F@TK5EX14MBXC283.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.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669B0A9FTK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914002)(43784002)(377454001)(164054002)(51856001)(56816002)(54316002)(47446002)(47736001)(46102001)(56776001)(76482001)(59766001)(16406001)(47976001)(77982001)(55846006)(16236675001)(15843345002)(74502001)(512954001)(550184003)(44976002)(53806001)(5343635001)(74662001)(31966008)(15202345001)(49866001)(4396001)(5343655001)(54356001)(50986001)(33656001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB018; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07106EF9B9
Subject: Re: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 01:10:46 -0000

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

Thanks for your review, Prateek.  Updates resulting from these comments are=
 included in the latest drafts.

                                                            Thanks again,
                                                            -- Mike

From: Mike Jones
Sent: Monday, December 10, 2012 5:51 PM
To: 'prateek mishra'; oauth@ietf.org
Subject: RE: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token

Thanks for the comments, Prateek.  Replies inline in green...

                                                                -- Mike

From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of prateek mishra
Sent: Wednesday, November 07, 2012 7:16 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Please review draft-ietf-oauth-json-web-token

Hannes - here a couple of comments on the 05 draft -

(i) Section 4 -

[quote]
Note however, that the set of claims that a JWT must contain to be
considered valid is context-dependent and is outside the scope of this spec=
ification. When
used in a security-related context, implementations MUST understand and sup=
port all of the
claims present; otherwise, the JWT MUST be rejected for processing.
[\quote]

I am not sure what is being stated here. I understand the general sense of =
the paragraph but I found the
two sentences to be contradictory. The second sentence is also very strong =
- suppose we find
some private claim in a JWT that the recipient is unable to understand - pe=
rhaps an optional
attribute-value pair - MUST it then reject the token?
The strong language about "MUST understand" mirrors the same language in th=
e JOSE specs.  As you probably know, there's an open issue being discussed =
by the JOSE working group about whether all header fields must be understoo=
d, or whether there will be a mechanism for signaling that some header fiel=
ds may be safely ignored if not understood.  I suspect that if a change is =
made to the JOSE specs in this regard, a similar change might be applied he=
re as well.

(ii) Section 6 -

[quote]

A plaintext

   JWT is a JWS using the "none" JWS "alg" header parameter value

   defined in JSON Web Algorithms (JWA) [JWA]; it is a JWS with an empty

   JWS Signature value.

[\quote]

It is later clarified that by "empty JWS Signature value" the draft means "=
empty string". That could
be added as a parenthetical remark at the end of the sentence. I actually s=
pent some time looking
up the term "empty JWS Signature value" in the JWS specification.
I'll plan to apply this clarification in the next spec release.

Thanks,
prateek

Hi all,



you may have noticed that the JOSE working group had made good progress wit=
h their work and they are getting closer to a WGLC. This is a good point in=
 time for us to review the JWT spec (see http://datatracker.ietf.org/doc/dr=
aft-ietf-oauth-json-web-token/). Please read through it in preparation for =
the meeting.



It would be good to hear who has implemented it and whether there is feedba=
ck on the document. Given the OpenID Connect interoperability tests there s=
eem to be lots of implementations.



We would like to start a WGLC as soon as the WGLC for the JOSE documents  s=
tarts.



Ciao

Hannes



_______________________________________________

OAuth mailing list

OAuth@ietf.org

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


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











Thanks for your review, P=
rateek.  Updates resulting from these comments are included in the lat=
est drafts.


 <=
/p>

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


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


 <=
/p>





From: Mike Jones


Sent: Monday, December 10, 2012 5:51 PM

To: 'prateek mishra'; oauth@ietf.org

Subject: RE: [OAUTH-WG] Please review draft-ietf-oauth-json-web-toke=
n






 


Thanks for the comments, =
Prateek.  Replies inline
in green…


 <=
/p>

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


 <=
/p>



 


Hannes - here a coupl=
e of comments on the 05 draft -




(i) Section 4 - 



[quote]

Note however, that the set of claims that a JWT must contain to be

considered valid is context-dependent and is outside the scope of this spec=
ification. When

used in a security-related context, implementations MUST understand and sup=
port all of the

claims present; otherwise, the JWT MUST be rejected for processing.

[\quote]



I am not sure what is being stated here. I understand the general sense of =
the paragraph but I found the


two sentences to be contradictory. The second sentence is also very strong =
- suppose we find

some private claim in a JWT that the recipient is unable to understand - pe=
rhaps an optional


attribute-value pair - MUST it then reject the token?


The strong language about=
 “MUST understand” mirrors the same language in the JOSE specs.=
  As you probably know, there’s an open issue being discussed by=
 the
 JOSE working group about whether all header fields must be understood, or =
whether there will be a mechanism for signaling that some header fields may=
 be safely ignored if not understood.  I suspect that if a change is m=
ade to the JOSE specs in this regard,
 a similar change might be applied here as well.




(ii) Section 6 - 



[quote]


A =
plaintext


&n=
bsp;  JWT is a JWS using the "none" JWS "alg" head=
er parameter value


&n=
bsp;  defined in JSON Web Algorithms (JWA) [JWA]; it is a JWS with an empty<=
/o:p>


&n=
bsp;  JWS Signature value.




[\quote]



It is later clarified that by "empty JWS Signature value" the dra=
ft means "empty string". That could

be added as a parenthetical remark at the end of the sentence. I actually s=
pent some time looking

up the term "empty JWS Signature value" in the JWS specification.=



I’ll plan to apply =
this clarification in the next spec release.




Thanks,

prateek


Hi all, 


 


you may have noticed that the JOSE working group had made good progres=
s with their work and they are getting closer to a WGLC. This is a good poi=
nt in time for us to review the JWT spec (see http://datatracker.ietf.org=
/doc/draft-ietf-oauth-json-web-token/). Please read through it in prepa=
ration for the meeting. 


 


It would be good to hear who has implemented it and whether there is f=
eedback on the document. Given the OpenID Connect interoperability tests th=
ere seem to be lots of implementations. 


 


We would like to start a WGLC as soon as the WGLC for the JOSE documen=
ts  starts. 


 


Ciao


Hannes


 


_______________________________________________


OAuth mailing list


OAuth@ietf.org


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


 






--_000_4E1F6AAD24975D4BA5B1680429673943669B0A9FTK5EX14MBXC283r_--

From Michael.Jones@microsoft.com  Fri Dec 28 17:11:14 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4EF21F8E42 for ; Fri, 28 Dec 2012 17:11:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.012,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06LcpVHXvMFR for ; Fri, 28 Dec 2012 17:11:09 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.31]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7D21F8E3F for ; Fri, 28 Dec 2012 17:11:08 -0800 (PST)
Received: from BY2FFO11FD010.protection.gbl (10.1.15.202) by BY2FFO11HUB017.protection.gbl (10.1.14.91) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sat, 29 Dec 2012 01:11:04 +0000
Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sat, 29 Dec 2012 01:10:52 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Sat, 29 Dec 2012 01:10:52 +0000
From: Mike Jones 
To: 'Hannes Tschofenig' , "'oauth@ietf.org WG'" 
Thread-Topic: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYVEht98lf4ktRCCG0LDhdLrxbg==
Date: Sat, 29 Dec 2012 01:10:51 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669B0AC8@TK5EX14MBXC283.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.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669B0AC8TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(43784002)(53754002)(51914002)(77982001)(74662001)(16236675001)(55846006)(46102001)(74502001)(59766001)(51856001)(56816002)(47976001)(47736001)(15843345002)(15202345001)(550184003)(44976002)(4396001)(16406001)(5343655001)(5343635001)(54356001)(47446002)(54316002)(31966008)(49866001)(33656001)(50986001)(76482001)(56776001)(53806001)(512954001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB017; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07106EF9B9
Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 01:11:14 -0000

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

Thanks for your review, Hannes.  Updates resulting from these comments are =
included in the latest drafts.

                                                            Thanks again,
                                                            -- Mike

From: Mike Jones
Sent: Monday, December 10, 2012 6:24 PM
To: 'Hannes Tschofenig'; oauth@ietf.org WG
Subject: RE: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05


Thanks for the review comments, Hannes.  Replies are inline in green...



                                                                -- Mike



-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of Hannes Tschofenig
Sent: Sunday, November 25, 2012 11:49 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05



Hi all,



I reviewed the document and I have a few questions (see below). I also thin=
k that this document has to wait for the JOSE documents to complete WGLC be=
fore it can be moved forward. It will have to wait anyway in the queue beca=
use of the normative dependency.



Agreed



- Header



In Section 3.1 you have an example of a JWT with an HMAC SHA-256 keyed mess=
age digest.

I would have assumed that the header contains the key id so that the receip=
ient can actually decode it. I am sure you assume it implicitly determines =
it (somehow) but wouldn't it be better practice to additionally include the=
 kid field to make it less ambigious?



I agree that in some contexts, including a Key ID would be important.  That=
 being said, in other contexts, including some OAuth contexts, the key is i=
mplicitly known from context.  For instance, a shared symmetric key may be =
assigned to be used for an OAuth client at client registration time.  In th=
at case, both the client and the server already know what key to use withou=
t needing a Key ID.  The same may true when using public key cryptography w=
ith an issuer that publishes a public key and a relying party that also pub=
lishes a public key.  Here again, the correct keys to be used can be determ=
ined via means external to the token itself.



- Namespace



The document defines a couple of claims. Quite naturally one wants to provi=
de extension points since others will quite likely come up with new claims =
in the near future. The obvious approach would be to use an IANA registry t=
o maintain uniqueness of the labels but without using a namespace declarati=
on concept like XML does.



For some reason that does not seem to be enough to use IANA alone: the docu=
ment introduces three types of claims, namely Reserved Claim Names, Public =
Claim Names, and Private Claim Names



No mechanism is stated how these claims can be differentiated but essential=
ly everything is allowed. Section 2 ("Terminology") says that the claims th=
at are not registered through IANA may be Domain Names, Object Identifiers =
(OIDs), UUIDs, etc.



Later in Section 4.2 it is said that public claims could be a URI, which is=
 again different to what is said in Section 2.



Furthermore, Private Claims (as defined in Section 4.3) do not seem to have=
 the requirement for uniqueness anymore even though Section 4 says that cla=
im names in a JWT have to be unique.



The danger is obviously that two parties define claim names that have diffe=
rent semantic. This will lead to confusion. When claims with the same names=
 are added to a JWT then, per specification, the receiver will have to fail=
.



If people are following the spec and using (IANA) reserved claim names, or =
public claim names (those containing a collision-resistant namespace), then=
 the same names will always have the same semantics.  IANA is used for rese=
rved claim names, where conflicts would otherwise be likely.  IANA is unnec=
essary for public claim names, because the collision-resistant namespace in=
 the claim name prevents duplication.



Do we really need to support claims where uniqueness cannot be guaranteed?



Private claim names are there because in some contexts, the communication i=
s between a fixed or constrained set of parties between whom private agreem=
ents are a perfectly acceptable namespace allocation solution.  Indeed, it =
wouldn't make much sense to register the meanings of claims with IANA that =
will only be used in a closed environment.



Can we decide on a few namespace concepts rather than leaving the list open=
-ended? What are the JOSE guys going to do about this issue?



The same namespace allocation strategy is being used by JOSE.



Btw, is it allowed to use JavaScript reserved keywords as claim names?



Yes



* "Mandatory to Implement"/"Mandatory to Understand"



Section 4 you write:



"

When used in a security-related context,

   implementations MUST understand and support all of the claims

   present; otherwise, the JWT MUST be rejected for processing.

"



In the same paragraph you write:



"

   Note

   however, that the set of claims that a JWT must contain to be

   considered valid is context-dependent and is outside the scope of

   this specification.

"



Wouldn't it also be application context dependent to decide how unknown cla=
ims are dealt with.

I fear that the above statement would lead to the problem that no extension=
s are possible anymore since you cannot be sure that the recipient understa=
nds all the extensions.



(See my reply to Prateek Mishra on the same topic.)



Then, in Section 4.1 you write:



"

The following claim names are reserved.  None of the claims defined

   below are intended to be mandatory, but rather, provide a starting

   point for a set of useful, interoperable claims.

"



What does mandatory mean here? Given the statement you made above all claim=
s must be understood anyway.



Mandatory to use.  I'll plan to clarify this in the next draft.



Almost every claim description contains the following statement: "This clai=
m is OPTIONAL."

What does this mean? Here are a few choices of what it could mean:



* A library does not need to implement it.

 * When an entity receives a JWT with an optional claim it can safely ignor=
e it.

 * When constructing a JWT payload this claim is optional to include.



The intended meaning is "Use of this claim is OPTIONAL."  I'll clarify this=
 in the next draft.



* Data Types



I would suggest to move the two data types (IntDate & StringOrURI) into a s=
eparate Section instead of leaving them in the terminology since you are us=
ing RFC 2119 language there.



This would make for a pretty short section.  I realize that RFC 2119 langua=
ge shouldn't be used in the abstract or introduction, but the RFC 2119 requ=
irements are legitimate constraints on the definitions of these terms.



* MTI Algorithms



You list a number of algorithms that must be implemented, namely "RSA-PKCS1=
-1.5 with 2048 bit keys, AES-128-KW, AES-256-KW, AES-128-CBC, and AES-256-C=
BC". While this may be a good choice for a Web environment I doubt it is us=
eful for other, more constrained use cases.



There are a few ways to deal with this, such as:



-  Avoid a MTI list and use RECOMMENDED language.

 -  State the usage environment and thereby provide an escape clause for ot=
her use cases.

 -  Outsource these algorithsm into a separate document that can be updated=
 independently.



Having a small set of MTI algorithms is part of what makes the spec simple =
and promotes real interoperability.  That being said, per Sean Turner's sug=
gestion, the Required/Recommended/Optional/Deprecated status of algorithms =
can change over time in the IANA algorithms registry, as the changing crypt=
o landscape may require.



* Security Consideration Section



I think the text could be improved. I was hoping to see some text about the=
 plaintext JWS.



I will try to make a suggestion in the next few days.



Sure - that would be good.



* Examples



To me it seems that Appendix A & Appendix B are a copy-and-paste of the tex=
t in http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-07.



Maybe it would be better to replace the text with a reference to draft-ietf=
-jose-json-web-signature-07. No need to artificially increase the size of t=
he document.



It's an editorial judgment call.  The example is there so people reading th=
e JWT spec first will get the (correct) sense that "this is pretty simple".=
  If they have to immediately go to another spec just to see an example, my=
 sense is that they'll likely think "this is already getting complicated!".



* References



The references to [JWA], [JWK], and [JWS] are incomplete. [JWS] and [JWK] h=
as to be, IMHO, a normative reference.



I'll plan to address this in the next draft.



[USA15] is not a normative reference, IMHO.



I think it's probably normative because it occurs in the context of RFC 211=
9 language: "Unicode Normalization [USA15] MUST NOT be applied...".



Ciao

Hannes

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

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











Thanks for your review=
, Hannes.  Updates resulting from these comments are included in the l=
atest drafts.


 


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


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


 






From: Mike Jon=
es


Sent: Monday, December 10, 2012 6:24 PM

To: 'Hannes Tschofenig'; oauth@ietf.org WG

Subject: RE: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05=







 


Thanks for the review comments, Hannes.  Rep=
lies are inline in green...=



 


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


 


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

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

Sent: Sunday, November 25, 2012 11:49 AM

To: oauth@ietf.org WG

Subject: [OAUTH-WG] Review of draft-ietf-oauth-json-web-token-05=



 


Hi all, 


 


I reviewed the document and I have a few question=
s (see below). I also think that this document has to wait for the JOSE doc=
uments to complete WGLC before it can be moved forward. It will have to wai=
t anyway in the queue because of the
 normative dependency. 


 


Agreed


 


- Header


 


In Section 3.1 you have an example of a JWT with =
an HMAC SHA-256 keyed message digest.



I would have assumed that the header contains the=
 key id so that the receipient can actually decode it. I am sure you assume=
 it implicitly determines it (somehow) but wouldn't it be better practice t=
o additionally include the kid field
 to make it less ambigious? 


 


I agree that in som=
e contexts, including a Key ID would be important.  That being said, i=
n other contexts, including some OAuth contexts, the key is implicitly know=
n from context.  For instance, a shared symmetric
 key may be assigned to be used for an OAuth client at client registration =
time.  In that case, both the client and the server already know what =
key to use without needing a Key ID.  The same may true when using pub=
lic key cryptography with an issuer that publishes
 a public key and a relying party that also publishes a public key.  H=
ere again, the correct keys to be used can be determined via means external=
 to the token itself.


 


- Namespace


 


The document defines a couple of claims. Quite na=
turally one wants to provide extension points since others will quite likel=
y come up with new claims in the near future. The obvious approach would be=
 to use an IANA registry to maintain
 uniqueness of the labels but without using a namespace declaration concept=
 like XML does.



 


For some reason that does not seem to be enough t=
o use IANA alone: the document introduces three types of claims, namely Res=
erved Claim Names, Public Claim Names, and Private Claim Names

 


No mechanism is stated how these claims can be di=
fferentiated but essentially everything is allowed. Section 2 ("Termin=
ology") says that the claims that are not registered through IANA may =
be Domain Names, Object Identifiers (OIDs),
 UUIDs, etc. 


 


Later in Section 4.2 it is said that public claim=
s could be a URI, which is again different to what is said in Section 2.



 


Furthermore, Private Claims (as defined in Sectio=
n 4.3) do not seem to have the requirement for uniqueness anymore even thou=
gh Section 4 says that claim names in a JWT have to be unique.



 


The danger is obviously that two parties define c=
laim names that have different semantic. This will lead to confusion. When =
claims with the same names are added to a JWT then, per specification, the =
receiver will have to fail.



 


If people are follo=
wing the spec and using (IANA) reserved claim names, or public claim names =
(those containing a collision-resistant namespace), then the same names wil=
l always have the same semantics.  IANA
 is used for reserved claim names, where conflicts would otherwise be likel=
y.  IANA is unnecessary for public claim names, because the collision-=
resistant namespace in the claim name prevents duplication.


 


Do we really need to support claims where uniquen=
ess cannot be guaranteed?


 


Private claim names=
 are there because in some contexts, the communication is between a fixed o=
r constrained set of parties between whom private agreements are a perfectl=
y acceptable namespace allocation solution. 
 Indeed, it wouldn’t make much sense to register the meanings of clai=
ms with IANA that will only be used in a closed environment.


 


Can we decide on a few namespace concepts rather =
than leaving the list open-ended? What are the JOSE guys going to do about =
this issue?


 


The same namespace =
allocation strategy is being used by JOSE.


 


Btw, is it allowed to use JavaScript reserved key=
words as claim names?


 


Yes


 


* "Mandatory to Implement"/"Mandat=
ory to Understand"


 


Section 4 you write:


 


"


When used in a security-related context,


   implementations MUST understand and =
support all of the claims


   present; otherwise, the JWT MUST be =
rejected for processing.


"


 


In the same paragraph you write: 


 


"


   Note


   however, that the set of claims that=
 a JWT must contain to be


   considered valid is context-dependen=
t and is outside the scope of


   this specification.


"


 


Wouldn't it also be application context dependent=
 to decide how unknown claims are dealt with.


I fear that the above statement would lead to the=
 problem that no extensions are possible anymore since you cannot be sure t=
hat the recipient understands all the extensions.



 


(See my reply to Pr=
ateek Mishra on the same topic.)


 


Then, in Section 4.1 you write:


 


"


The following claim names are reserved.  Non=
e of the claims defined


   below are intended to be mandatory, =
but rather, provide a starting


   point for a set of useful, interoper=
able claims.


"


 


What does mandatory mean here? Given the statemen=
t you made above all claims must be understood anyway.



 


Mandatory to use.&n=
bsp; I’ll plan to clarify this in the next draft.

 


Almost every claim description contains the follo=
wing statement: "This claim is OPTIONAL."


What does this mean? Here are a few choices of wh=
at it could mean:



 


* A library does not need to implement it. <=
/o:p>


 * When an entity receives a JWT with an opt=
ional claim it can safely ignore it.



 * When constructing a JWT payload this clai=
m is optional to include.



  


The intended meanin=
g is “Use of this claim is OPTIONAL.”  I’ll clarify =
this in the next draft.


 


* Data Types


 


I would suggest to move the two data types (IntDa=
te & StringOrURI) into a separate Section instead of leaving them in th=
e terminology since you are using RFC 2119 language there.



 


This would make for=
 a pretty short section.  I realize that RFC 2119 language shouldnR=
17;t be used in the abstract or introduction, but the RFC 2119 requirements=
 are legitimate constraints on the definitions
 of these terms. 


 


* MTI Algorithms


 


You list a number of algorithms that must be impl=
emented, namely "RSA-PKCS1-1.5 with 2048 bit keys, AES-128-KW, AES-256=
-KW, AES-128-CBC, and AES-256-CBC". While this may be a good choice fo=
r a Web environment I doubt it is useful for
 other, more constrained use cases. 


 


There are a few ways to deal with this, such as: =



 


-  Avoid a MTI list and use RECOMMENDED lang=
uage.  


 -  State the usage environment and the=
reby provide an escape clause for other use cases.



 -  Outsource these algorithsm into a s=
eparate document that can be updated independently.



 


Having a small set =
of MTI algorithms is part of what makes the spec simple and promotes real i=
nteroperability.  That being said, per Sean Turner’s suggestion,=
 the Required/Recommended/Optional/Deprecated status
 of algorithms can change over time in the IANA algorithms registry, as the=
 changing crypto landscape may require.


 


* Security Consideration Section


 


I think the text could be improved. I was hoping =
to see some text about the plaintext JWS.



 


I will try to make a suggestion in the next few d=
ays.  



 


Sure – that w=
ould be good.


 


* Examples


 


To me it seems that Appendix A & Appendix B a=
re a copy-and-paste of the text in
http://tools.ietf.o=
rg/html/draft-ietf-jose-json-web-signature-07.



 


Maybe it would be better to replace the text with=
 a reference to draft-ietf-jose-json-web-signature-07. No need to artificia=
lly increase the size of the document.



 


It’s an edito=
rial judgment call.  The example is there so people reading the JWT sp=
ec first will get the (correct) sense that “this is pretty simpleR=
21;.  If they have to immediately go to another spec just to
 see an example, my sense is that they’ll likely think “this is=
 already getting complicated!”.


 


* References 


 


The references to [JWA], [JWK], and [JWS] are inc=
omplete. [JWS] and [JWK] has to be, IMHO, a normative reference.



 


I’ll plan to =
address this in the next draft.


 


[USA15] is not a normative reference, IMHO. =



 


I think it’s =
probably normative because it occurs in the context of RFC 2119 language: &=
#8220;Unicode Normalization [USA15] MUST NOT be applied…”.=



 


Ciao


Hannes


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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






--_000_4E1F6AAD24975D4BA5B1680429673943669B0AC8TK5EX14MBXC283r_--

From Michael.Jones@microsoft.com  Fri Dec 28 17:11:55 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1B821F8E3C for ; Fri, 28 Dec 2012 17:11:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=-0.012,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvzZ8mKUVcUB for ; Fri, 28 Dec 2012 17:11:54 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id B13E821F8E1D for ; Fri, 28 Dec 2012 17:11:54 -0800 (PST)
Received: from BL2FFO11FD004.protection.gbl (10.173.161.201) by BL2FFO11HUB016.protection.gbl (10.173.160.108) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sat, 29 Dec 2012 01:11:51 +0000
Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD004.mail.protection.outlook.com (10.173.160.104) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sat, 29 Dec 2012 01:11:51 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.59]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Sat, 29 Dec 2012 01:11:50 +0000
From: Mike Jones 
To: Jeff Hodges , Nat Sakimura 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYXPoELEFPMRSTq+X4Nh79LI8wg==
Date: Sat, 29 Dec 2012 01:11:49 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.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.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669B0B1FTK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914002)(51704002)(377454001)(4396001)(49866001)(44976002)(46102001)(74502001)(15202345001)(74662001)(47446002)(31966008)(550184003)(50986001)(47976001)(47736001)(5343645001)(54316002)(5343655001)(51856001)(55846006)(5343635001)(77982001)(56776001)(512874001)(59766001)(16236675001)(54356001)(33656001)(76482001)(15395725002)(16406001)(56816002)(53806001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB016; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 07106EF9B9
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 01:11:55 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943669B0B1FTK5EX14MBXC283r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBmb3VuZCB0aGUgWC4xMjUyIGRlZmluaXRpb24uICBJdCBpczoNCg0KNi4xOCBjbGFpbSBbYi1P
RURdOiBUbyBzdGF0ZSBhcyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBiZWluZyBhYmxlIHRvIGdp
dmUgcHJvb2YuDQoNClRoYXQgc2VlbXMgYm90aCBhIGJpdCB2YWd1ZSwgYW5kIGFjdHVhbGx5IGlu
Y29ycmVjdCwgYXMgdGhlIEpXVCBtYXkgaW5jbHVkZSBwcm9vZiBvZiB0aGUgdmVyYWNpdHkgb2Yg
dGhlIGNsYWltLiAgUGxlYXNlIHNlZSB0aGUgdXBkYXRlZCBKV1QgZHJhZnQgZm9yIGEgaG9wZWZ1
bGx5IG1vcmUgdXNlZnVsIOKAnENsYWlt4oCdIGRlZmluaXRpb24uDQoNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJlc3Qgd2lzaGVz
LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBNaWtlIEpvbmVzDQpTZW50OiBTdW5kYXksIERlY2VtYmVy
IDIzLCAyMDEyIDE6MDMgUE0NClRvOiBKZWZmIEhvZGdlczsgTmF0IFNha2ltdXJhDQpDYzogSUVU
RiBvYXV0aCBXRw0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9h
dXRoLWpzb24td2ViLXRva2VuLTA1DQoNCldoYXQgaXMgdGhlIFguMTI1MiBkZWZpbml0aW9uPw0K
DQotLSBNaWtlDQoNCkZyb206IE5hdCBTYWtpbXVyYQ0KU2VudDog4oCORGVjZW1iZXLigI4g4oCO
MjPigI4sIOKAjjIwMTIg4oCOMTDigI464oCOMDnigI4g4oCOQU0NClRvOiA9SmVmZkgNCkNDOiBN
aWtlIEpvbmVzLCBJRVRGIG9hdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSByZXZpZXc6
IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDUNCg0KUmUgZGVmaW5pdGlvbiBvZiAn
Y2xhaW0nLCBhcyBKV1QgaXMgc3VwcG9zZWQgdG8gYmUgZ2VuZXJpYywgaXQgbWF5IGJlDQpiZXR0
ZXIgdG8gZ28gd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiBYLjEyNTIgcmF0aGVyIHRoYW4gT0lEQy4N
Cg0KPW5hdCB2aWEgaVBob25lDQoNCkRlYyAyNCwgMjAxMiAyOjQy44CBPUplZmZIIDxKZWZmLkhv
ZGdlc0BraW5nc21vdW50YWluLmNvbTxtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5j
b20+PiDjga7jg6Hjg4Pjgrvjg7zjgrg6DQoNCj4NCj4gPiBUaGFua3MgZm9yIHRoZSByZXBsaWVz
LCBKZWZmLiAgVGhleSBtYWtlIHNlbnNlLiAgUGFydGljdWxhcmx5LCB0aGFua3MgZm9yDQo+ID4g
dGhlICJKU09OIFRleHQgT2JqZWN0IiBzdWdnZXN0aW9uLg0KPg0KPiB3ZWxjb21lLCBnbGFkIHRo
ZXkgbWFkZSBzb21lIHNlbnNlLg0KPg0KPiBzaW1pbGFybHksIGlmIG9uZSBlbXBsb3lzIEpTT04g
YXJyYXlzLCBJJ2QgZGVmaW5lIGEgIkpTT04gdGV4dCBhcnJheSIuDQo+DQo+DQo+ID4gRm9yIHRo
ZSAiY2xhaW1zIiBkZWZpbml0aW9uLCBJJ20gYWN0dWFsbHkgcHJvbmUgdG8gZ28gd2l0aCBkZWZp
bml0aW9ucyBiYXNlZA0KPiA+IG9uIHRob3NlIGluDQo+ID4gaHR0cDovL29wZW5pZC5uZXQvc3Bl
Y3Mvb3BlbmlkLWNvbm5lY3QtbWVzc2FnZXMtMV8wLTEzLmh0bWwjdGVybWlub2xvZ3kgLQ0KPiA+
IHNwZWNpZmljYWxseToNCj4gPg0KPiA+IENsYWltDQo+ID4gQSBwaWVjZSBvZiBpbmZvcm1hdGlv
biBhYm91dCBhbiBFbnRpdHkgdGhhdCBhIENsYWltcyBQcm92aWRlciBhc3NlcnRzIGFib3V0DQo+
ID4gdGhhdCBFbnRpdHkuDQo+ID4gQ2xhaW1zIFByb3ZpZGVyDQo+ID4gQSBzeXN0ZW0gb3Igc2Vy
dmljZSB0aGF0IGNhbiByZXR1cm4gQ2xhaW1zIGFib3V0IGFuIEVudGl0eS4NCj4gPiBFbmQtVXNl
cg0KPiA+IEEgaHVtYW4gdXNlciBvZiBhIHN5c3RlbSBvciBzZXJ2aWNlLg0KPiA+IEVudGl0eQ0K
PiA+IFNvbWV0aGluZyB0aGF0IGhhcyBhIHNlcGFyYXRlIGFuZCBkaXN0aW5jdCBleGlzdGVuY2Ug
YW5kIHRoYXQgY2FuIGJlDQo+ID4gaWRlbnRpZmllZCBpbiBjb250ZXh0LiBBbiBFbmQtVXNlciBp
cyBvbmUgZXhhbXBsZSBvZiBhbiBFbnRpdHkuDQo+DQo+IHdlbGwsIGl0IHNlZW1zIHRvIG1lLCBn
aXZlbiB0aGUgbWFubmVyIGluIHdoaWNoIHRoZSBKV1Qgc3BlYyBpcyB3cml0dGVuLCBvbmUgY2Fu
IG1ha2UgdGhlIGNhc2UgdGhhdCBKV1QgY2xhaW1zIGluIGdlbmVyYWwgYXJlbid0IG5lY2Vzc2Fy
aWx5IGFib3V0IGFuIEVudGl0eSAoYXMgdGhlIGxhdHRlciB0ZXJtIGlzIHVzZWQgaW4gdGhlIGNv
bnRleHQgb2YgdGhlIE9wZW5JRCBDb25uZWN0IHNwZWNzKSwgcmF0aGVyIHRoZXkncmUgaW4gZ2Vu
ZXJhbCBzaW1wbHkgYXNzZXJ0aW9ucyBhYm91dCBzb21ldGhpbmcocykuIHRoaXMgaXMgYmVjYXVz
ZSBhbGwgcHJlLWRlZmluZWQgSldUIGNsYWltIHR5cGVzIGFyZSBvcHRpb25hbCBhbmQgYWxsIEpX
VCBzZW1hbnRpY3MgYXJlIGxlZnQgdXAgdG8gc3BlY3MgdGhhdCBwcm9maWxlIChha2EgcmUtdXNl
KSB0aGUgSldUIHNwZWMuDQo+DQo+IEhUSCwNCj4NCj4gPUplZmZIDQo+DQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9BdXRoIG1haWxpbmcgbGlz
dA0KPiBPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg==

--_000_4E1F6AAD24975D4BA5B1680429673943669B0B1FTK5EX14MBXC283r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ
cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlRpbWVzTmV3Um9tYW5cLEJvbGQiOw0KCXBhbm9zZS0xOjAg
MCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUaW1lc05ld1Jv
bWFuOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlv
bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu
OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250
LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl
cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp
b246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh
dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl
eHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z
aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJh
bGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglm
b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7
bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz
YW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls
ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp
b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp
bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz
cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg
ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N
Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh
c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBmb3VuZCB0aGUgWC4xMjUyIGRlZmluaXRpb24u
Jm5ic3A7IEl0IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXNOZXdSb21hbixCb2xkJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7
Ij42LjE4IGNsYWltDQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU
aW1lc05ld1JvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5bYi1PRURdOiBUbyBzdGF0ZSBh
cyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBiZWluZyBhYmxlIHRvIGdpdmUgcHJvb2YuPC9zcGFu
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo
YXQgc2VlbXMgYm90aCBhIGJpdCB2YWd1ZSwgYW5kIGFjdHVhbGx5IGluY29ycmVjdCwgYXMgdGhl
IEpXVCBtYXkgaW5jbHVkZSBwcm9vZiBvZiB0aGUgdmVyYWNpdHkgb2YgdGhlIGNsYWltLiZuYnNw
OyBQbGVhc2Ugc2VlIHRoZSB1cGRhdGVkIEpXVCBkcmFmdCBmb3IgYSBob3BlZnVsbHkNCiBtb3Jl
IHVzZWZ1bCDigJxDbGFpbeKAnSBkZWZpbml0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJl
c3Qgd2lzaGVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0g
TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj
QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss
JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pa2UgSm9uZXMNCjxicj4NCjxiPlNlbnQ6PC9iPiBT
dW5kYXksIERlY2VtYmVyIDIzLCAyMDEyIDE6MDMgUE08YnI+DQo8Yj5Ubzo8L2I+IEplZmYgSG9k
Z2VzOyBOYXQgU2FraW11cmE8YnI+DQo8Yj5DYzo8L2I+IElFVEYgb2F1dGggV0c8YnI+DQo8Yj5T
dWJqZWN0OjwvYj4gUkU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24t
d2ViLXRva2VuLTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XaGF0IGlzIHRoZSBYLjEyNTIgZGVmaW5pdGlv
bj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tLSBNaWtlPG86cD48L286cD48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFNUU1RTUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBp
biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv
c3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDtOYXQgU2FraW11cmE8YnI+DQo8c3Ryb25n
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPlNlbnQ6PC9zcGFuPjwvc3Ryb25nPiZuYnNwO+KAjkRlY2VtYmVy4oCOIOKA
jjIz4oCOLCDigI4yMDEyIOKAjjEw4oCOOuKAjjA54oCOIOKAjkFNPGJyPg0KPHN0cm9uZz48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5Ubzo8L3NwYW4+PC9zdHJvbmc+Jm5ic3A7PUplZmZIPGJyPg0KPHN0cm9uZz48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij5DQzo8L3NwYW4+PC9zdHJvbmc+Jm5ic3A7TWlrZSBKb25lcywgSUVURiBvYXV0aCBX
Rzxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3ViamVjdDo8L3NwYW4+PC9zdHJvbmc+Jm5ic3A7
UmU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZSBkZWZpbml0aW9uIG9mICdjbGFpbScsIGFz
IEpXVCBpcyBzdXBwb3NlZCB0byBiZSBnZW5lcmljLCBpdCBtYXkgYmU8YnI+DQpiZXR0ZXIgdG8g
Z28gd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiBYLjEyNTIgcmF0aGVyIHRoYW4gT0lEQy48YnI+DQo8
YnI+DQo9bmF0IHZpYSBpUGhvbmU8YnI+DQo8YnI+DQpEZWMgMjQsIDIwMTIgMjo0Mjwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jgIE8L3NwYW4+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+PUplZmZIICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOkplZmYuSG9kZ2Vz
QGtpbmdzbW91bnRhaW4uY29tIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5KZWZmLkhvZGdlc0BraW5nc21vdW50YWlu
LmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDsiPuOBruODoeODg+OCu+ODvOOCuDwvc3Bhbj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7Ij46PGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBUaGFua3MgZm9yIHRo
ZSByZXBsaWVzLCBKZWZmLiZuYnNwOyBUaGV5IG1ha2Ugc2Vuc2UuJm5ic3A7IFBhcnRpY3VsYXJs
eSwgdGhhbmtzIGZvcjxicj4NCiZndDsgJmd0OyB0aGUgJnF1b3Q7SlNPTiBUZXh0IE9iamVjdCZx
dW90OyBzdWdnZXN0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IHdlbGNvbWUsIGdsYWQgdGhleSBt
YWRlIHNvbWUgc2Vuc2UuPGJyPg0KJmd0Ozxicj4NCiZndDsgc2ltaWxhcmx5LCBpZiBvbmUgZW1w
bG95cyBKU09OIGFycmF5cywgSSdkIGRlZmluZSBhICZxdW90O0pTT04gdGV4dCBhcnJheSZxdW90
Oy48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBGb3IgdGhlICZxdW90O2NsYWlt
cyZxdW90OyBkZWZpbml0aW9uLCBJJ20gYWN0dWFsbHkgcHJvbmUgdG8gZ28gd2l0aCBkZWZpbml0
aW9ucyBiYXNlZDxicj4NCiZndDsgJmd0OyBvbiB0aG9zZSBpbjxicj4NCiZndDsgJmd0OyA8L3Nw
YW4+PGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtbWVzc2Fn
ZXMtMV8wLTEzLmh0bWwjdGVybWlub2xvZ3kiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmh0dHA6Ly9vcGVuaWQubmV0
L3NwZWNzL29wZW5pZC1jb25uZWN0LW1lc3NhZ2VzLTFfMC0xMy5odG1sI3Rlcm1pbm9sb2d5PC9z
cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCiAtPGJyPg0KJmd0OyAmZ3Q7IHNwZWNpZmljYWxseTo8YnI+
DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgQ2xhaW08YnI+DQomZ3Q7ICZndDsgQSBwaWVjZSBv
ZiBpbmZvcm1hdGlvbiBhYm91dCBhbiBFbnRpdHkgdGhhdCBhIENsYWltcyBQcm92aWRlciBhc3Nl
cnRzIGFib3V0PGJyPg0KJmd0OyAmZ3Q7IHRoYXQgRW50aXR5Ljxicj4NCiZndDsgJmd0OyBDbGFp
bXMgUHJvdmlkZXI8YnI+DQomZ3Q7ICZndDsgQSBzeXN0ZW0gb3Igc2VydmljZSB0aGF0IGNhbiBy
ZXR1cm4gQ2xhaW1zIGFib3V0IGFuIEVudGl0eS48YnI+DQomZ3Q7ICZndDsgRW5kLVVzZXI8YnI+
DQomZ3Q7ICZndDsgQSBodW1hbiB1c2VyIG9mIGEgc3lzdGVtIG9yIHNlcnZpY2UuPGJyPg0KJmd0
OyAmZ3Q7IEVudGl0eTxicj4NCiZndDsgJmd0OyBTb21ldGhpbmcgdGhhdCBoYXMgYSBzZXBhcmF0
ZSBhbmQgZGlzdGluY3QgZXhpc3RlbmNlIGFuZCB0aGF0IGNhbiBiZTxicj4NCiZndDsgJmd0OyBp
ZGVudGlmaWVkIGluIGNvbnRleHQuIEFuIEVuZC1Vc2VyIGlzIG9uZSBleGFtcGxlIG9mIGFuIEVu
dGl0eS48YnI+DQomZ3Q7PGJyPg0KJmd0OyB3ZWxsLCBpdCBzZWVtcyB0byBtZSwgZ2l2ZW4gdGhl
IG1hbm5lciBpbiB3aGljaCB0aGUgSldUIHNwZWMgaXMgd3JpdHRlbiwgb25lIGNhbiBtYWtlIHRo
ZSBjYXNlIHRoYXQgSldUIGNsYWltcyBpbiBnZW5lcmFsIGFyZW4ndCBuZWNlc3NhcmlseSBhYm91
dCBhbiBFbnRpdHkgKGFzIHRoZSBsYXR0ZXIgdGVybSBpcyB1c2VkIGluIHRoZSBjb250ZXh0IG9m
IHRoZSBPcGVuSUQgQ29ubmVjdCBzcGVjcyksIHJhdGhlciB0aGV5J3JlIGluIGdlbmVyYWwNCiBz
aW1wbHkgYXNzZXJ0aW9ucyBhYm91dCBzb21ldGhpbmcocykuIHRoaXMgaXMgYmVjYXVzZSBhbGwg
cHJlLWRlZmluZWQgSldUIGNsYWltIHR5cGVzIGFyZSBvcHRpb25hbCBhbmQgYWxsIEpXVCBzZW1h
bnRpY3MgYXJlIGxlZnQgdXAgdG8gc3BlY3MgdGhhdCBwcm9maWxlIChha2EgcmUtdXNlKSB0aGUg
SldUIHNwZWMuPGJyPg0KJmd0Ozxicj4NCiZndDsgSFRILDxicj4NCiZndDs8YnI+DQomZ3Q7ID1K
ZWZmSDxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KJmd0OyBPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDwv
c3Bhbj48YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9BdXRoQGll
dGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQomZ3Q7IDwvc3Bhbj48YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9zcGFuPjwvYT48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K

--_000_4E1F6AAD24975D4BA5B1680429673943669B0B1FTK5EX14MBXC283r_--

From wmills_92105@yahoo.com  Fri Dec 28 18:06:37 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B6F21F8D3F for ; Fri, 28 Dec 2012 18:06:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.996
X-Spam-Level: 
X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=-0.998, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8cXpa5R-8vY for ; Fri, 28 Dec 2012 18:06:37 -0800 (PST)
Received: from nm30-vm0.bullet.mail.bf1.yahoo.com (nm30-vm0.bullet.mail.bf1.yahoo.com [98.139.213.126]) by ietfa.amsl.com (Postfix) with ESMTP id 8D60F21F8D32 for ; Fri, 28 Dec 2012 18:06:36 -0800 (PST)
Received: from [98.139.212.152] by nm30.bullet.mail.bf1.yahoo.com with NNFMP; 29 Dec 2012 02:06:35 -0000
Received: from [98.139.212.235] by tm9.bullet.mail.bf1.yahoo.com with NNFMP; 29 Dec 2012 02:06:35 -0000
Received: from [127.0.0.1] by omp1044.mail.bf1.yahoo.com with NNFMP; 29 Dec 2012 02:06:35 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 760317.77400.bm@omp1044.mail.bf1.yahoo.com
Received: (qmail 68544 invoked by uid 60001); 29 Dec 2012 02:06:35 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356746795; bh=Lau5GAGnChRNiBSh3hGDMRJc2a3E4IvpR21PfLJkY7Y=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IMMf1Z9gb/T98bEFTKucvbNwRALAvyIa2nfz8iuJQVs7xG5Tmt/bYOBWu7AeGHAueVxoTfOZ/2wSbbbj5BtXqeZfZ2AmOKDldDC2mBAlMPWqC0IK0vNCxSbJtzQE4fhdQr1ksA1ww3fhEtMddNc2e+Vv48h3AwjWlonAUbAbXVU=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ZotbYO/2+KInj6ihQ6zdaY8u6eWMTQ0HTtOl9X5OwzQYAbUQ92VFVQaDsZ+nHZVQJJfv0moBBaRbVpLQOYxz/oeJSysAoX+BRfT34PMGWu/As/lbjYEmDoUxWcclyz5ig6h59YyHZMMp0nNpQCDSy2zd7k2JRy/i9Y0FUwKP32U=;
X-YMail-OSG: TQHNOoYVM1n1hJ3z5.R68qkGtJgn9MI4iuCgQMV_AEUHrex HGxXSgg5CiRJpgA8f9uLK9UI36A2M1ZZg68idLsf_qz3UHcJZ5Z60eSxQ2KT oOH5h8pnomK7Jt1dpy94mEEpdOF9aAY5LIBuDWKLBUZwbBrMhzwtJoolsiXl T6SC.sC6w9OA3zuPTOt2Vw4PVxMZYlpnrET4DTs_Mgxpm2aViOGkefBWT_B0 JH8gfRkRuD7RkIvFBL52YFFoLK6v62PN5gEYs8FkgtPWj6vPpBoZTn6wnyK6 HaJp8WzFQ1BGRLgtJa4764cFH.wDhNp1nQp9asvUREJuUzeKcFpQ8DRWXt7e zmKYeuTctBHhiAvu2pFlk8sZxhHafO5Iv2qWlx9xbSfScGCp_AGQWHQBTTFC BbgDOaSkkjDRm3cbiL_55mQk8447GDuMxGlCyfjubZ_Mt5XXXo2LI6zoSXAa QMrGQVyJRp82WGP6jmZCrM7xUnkkowjDYxbaJ3Vchplvcqe7LVe4PrgyyVVa LSQdYOV2dF3f8d24ote4-
Received: from [99.31.212.42] by web31807.mail.mud.yahoo.com via HTTP; Fri, 28 Dec 2012 18:06:34 PST
X-Rocket-MIMEInfo: 001.001, TWlrZSwKCkkndmUgcmVhZCB0aHJvdWdoIHRoZSBKV1Qgc3BlYyBhbmQgSSdtIGN1cmlvdXMgYWJvdXQgc29tZXRoaW5nLiDCoEhvdyBkbyBJIHNwZWNpZnkgYSBzaWduYXR1cmUgcmVxdWlyZW1lbnQgYXMgdGhlIHNlcnZlcj8gwqBJIGRpZG4ndCBzZWUgaXQgYnV0IEkgcHJvYmFibHkganVzdCBtaXNzZWQgaXQuIMKgSSdtIHRoaW5raW5nIHRoYXQgd2l0aCB2ZXJ5IGxpdHRsZSB3b3JrIGEgSldUIGNhbiBkbyBldmVyeXRoaW5nIHRoYXQgTUFDIGRvZXMgd2l0aCBncmVhdGVyIGZsZXhpYmlsaXR5LCAqQlVUKiABMAEBAQE-
X-Mailer: YahooMailWebService/0.8.129.483
References: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.redmond.corp.microsoft.com>
Message-ID: <1356746794.51868.YahooMailNeo@web31807.mail.mud.yahoo.com>
Date: Fri, 28 Dec 2012 18:06:34 -0800 (PST)
From: William Mills 
To: Mike Jones , "oauth@ietf.org" 
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.redmond.corp.microsoft.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="-125733401-346383595-1356746794=:51868"
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: William Mills 
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 02:06:38 -0000

---125733401-346383595-1356746794=:51868
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Mike,=0A=0AI've read through the JWT spec and I'm curious about something. =
=A0How do I specify a signature requirement as the server? =A0I didn't see =
it but I probably just missed it. =A0I'm thinking that with very little wor=
k a JWT can do everything that MAC does with greater flexibility, *BUT* the=
 server needs to be able to require a signed usage. =A0Something I never li=
ked about OAuth 1.0 is that the server must support all valid signature typ=
es, even PLAINTEXT, so I want to be able to avoid that.=0A=0AIt would requi=
re the client to be able to include client generated stuff in the JWT.=0A=
=0AThanks,=0A=0A-bill
---125733401-346383595-1356746794=:51868
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable


Mike=
,

I've read through the JWT spec =
and I'm curious about something.  How do I specify a signature require=
ment as the server?  I didn't see it but I probably just missed it. &n=
bsp;I'm thinking that with very little work a JWT can do everything that MA=
C does with greater flexibility, *BUT* the server needs to be able to requi=
re a signed usage.  Something I never liked about OAuth 1.0 is that th=
e server must support all valid signature types, even PLAINTEXT, so I want =
to be able to avoid that.

=

It would require the client to be able to include cli=
ent generated stuff in the JWT.

Thanks,

-bill
  

---125733401-346383595-1356746794=:51868--

From dick.hardt@gmail.com  Fri Dec 28 20:10:52 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85FB21F84BB for ; Fri, 28 Dec 2012 20:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level: 
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=-1.490, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_PORN=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_ADLTOBFU=0.68]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g200G2RbgdJr for ; Fri, 28 Dec 2012 20:10:51 -0800 (PST)
Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by ietfa.amsl.com (Postfix) with ESMTP id D4AA221F84B2 for ; Fri, 28 Dec 2012 20:10:51 -0800 (PST)
Received: by mail-pb0-f43.google.com with SMTP id um15so6224143pbc.16 for ; Fri, 28 Dec 2012 20:10:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=BWc+sWJsy5JNgBMRYsdFwh7xWuhFW5sY6ff3c9uajQY=; b=cO2sGSYmwPHmVPrU+HRB0RbIA5oqLo9it3MN6u68DDMXd7EPDWoqsMBnGmgy5HFWoP d59v7QTYDKRhpWTOe87+TsOQ6T0knyyt95aXBEscqyfIOUShbMdkw07QXLP9zR7qolS+ +LXM/4qd+o5gUMelx0cH0/dH/Jl21XIwsYmgQ2yIHY7FzG1yk1zkGFwmbRz13z6Ibqd6 Vsr9UtLWx4bTcAJaSqSJHTWfNUWT2ggfRQT/guJJpn50zWtqNE6K7P0zGjAzvOyJGRGI 9iRn9XVnsIPa+pQyaUClo6mnInCNiBgSrptEHEoF72fxRyV0pXL253h9flLEvwOnlWRX a53Q==
X-Received: by 10.68.233.230 with SMTP id tz6mr109535946pbc.36.1356754251599;  Fri, 28 Dec 2012 20:10:51 -0800 (PST)
Received: from [10.0.0.4] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id pm8sm20760310pbb.29.2012.12.28.20.10.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 28 Dec 2012 20:10:47 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_750AD96C-8F1B-4708-AC88-303AE61C78C6"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Dick Hardt 
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Fri, 28 Dec 2012 20:10:44 -0800
Message-Id: <61A65272-73E1-477A-B288-8C7E4B420659@gmail.com>
References: <4E1F6AAD24975D4BA5B1680429673943669B0A1E@TK5EX14MBXC283.redmond.corp.microsoft.com>
To: Mike Jones 
X-Mailer: Apple Mail (2.1499)
Cc: "oauth@ietf.org" 
Subject: Re: [OAUTH-WG] December 27, 2012 OAuth Release
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 04:10:52 -0000

--Apple-Mail=_750AD96C-8F1B-4708-AC88-303AE61C78C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Looks like I was not the only one that was reading "p0rn" when I saw =
"prn" =85 ;-)

On Dec 28, 2012, at 5:07 PM, Mike Jones  =
wrote:

> New versions of the OAuth JWT, JWT Bearer Profile, and Assertions =
specs have been released incorporating feedback since IETF 85 in =
Atlanta.  The primary change is changing the name of the =93prn=94 claim =
to =93sub=94 (subject) both to more closely align with SAML name usage =
and to use a more intuitive name for this concept.  (Also, see the =
related coordinated change to the OpenID Connect specifications.)  The =
definition of the =93aud=94 (audience) claim was also extended to allow =
JWTs to have multiple audiences (a feature also in SAML assertions).
> =20
> An explanation was added to the JWT spec about why should be signed =
and then encrypted.
> =20
> The audience definition in the Assertions specification was relaxed so =
that audience values can be OAuth =93client_id=94 values.  Informative =
references to the SAML Bearer Profile and JWT Bearer Profile specs were =
also added.
> This release incorporates editorial improvements suggested by Jeff =
Hodges, Hannes Tschofenig, and Prateek Mishra in their reviews of the =
JWT specification.  Many of these simplified the terminology usage.  See =
the Document History section of each specification for more details =
about the changes made.
> =20
> This release is part of a coordinated release of JOSE, OAuth, and =
OpenID Connect specifications.  You can read about the other releases =
here:  JOSE Release Notes, OpenID Connect Release Notes.
> =20
> The new specification versions are:
> =B7        =
http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06
> =B7        http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-04
> =B7        http://tools.ietf.org/html/draft-ietf-oauth-assertions-09
> =20
> HTML formatted versions are available at:
> =B7        =
http://self-issued.info/docs/draft-ietf-oauth-json-web-token-06.html
> =B7        =
http://self-issued.info/docs/draft-ietf-oauth-jwt-bearer-04.html
> =B7        =
http://self-issued.info/docs/draft-ietf-oauth-assertions-09.html
> =20
>                                                             -- Mike
> =20
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_750AD96C-8F1B-4708-AC88-303AE61C78C6
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Looks like I was not the only =
one that was reading "p0rn" when I saw "prn" =85 =
;-)

On Dec 28, 2012, at 5:07 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

An explanation was =
added to the JWT spec about why should be signed and then =
encrypted.
The audience =
definition in the Assertions specification was relaxed so that audience =
values can be OAuth =93This release incorporates =
editorial improvements suggested by Jeff Hodges, Hannes Tschofenig, and =
Prateek Mishra in their reviews of the JWT specification.  Many of =
these simplified the terminology usage.  See the Document History =
section of each specification for more details about the changes =
made.
 
This release is part of a coordinated release of =
JOSE, OAuth, and OpenID Connect specifications.  You can read about =
the other releases here:  JOSE Release Notes, OpenID Connect Release =
Notes.
The new =
specification versions are:
        =B7 =B7  
>
>> welcome, glad they made some sense.
>>
>> similarly, if one employs JSON arrays, I'd define a "JSON text array".
>>
>>
>> > For the "claims" definition, I'm actually prone to go with definitions based
>> > on those in
>> >http://openid.net/specs/openid-connect-messages-1_0-13.html#terminology-
>> > specifically:
>> >
>> > Claim
>> > A piece of information about an Entity that a Claims Provider asserts about
>> > that Entity.
>> > Claims Provider
>> > A system or service that can return Claims about an Entity.
>> > End-User
>> > A human user of a system or service.
>> > Entity
>> > Something that has a separate and distinct existence and that can be
>> > identified in context. An End-User is one example of an Entity.
>>
>> well, it seems to me, given the manner in which the JWT spec is written, one can make the case that JWT claims in general aren't necessarily about an Entity (as the latter term is used in the context of the OpenID Connect specs), rather they're in general  simply assertions about something(s). this is because all pre-defined
> JWT claim types are optional and all JWT semantics are left up to specs
> that profile (aka re-use) the JWT spec.
>>
>> HTH,
>>
>> =JeffH
>>
>> _______________________________________________
>> OAuth mailing 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 asanso@adobe.com  Sat Dec 29 02:35:34 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB9721F84F2 for ; Sat, 29 Dec 2012 02:35:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.398
X-Spam-Level: 
X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dt2h45U+XXKG for ; Sat, 29 Dec 2012 02:35:31 -0800 (PST)
Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id C472D21F8480 for ; Sat, 29 Dec 2012 02:35:28 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUN7HcNNdgryLvHfI+ZKkxSrXKscAWQ4F@postini.com; Sat, 29 Dec 2012 02:35:31 PST
Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qBTAZPC9006370; Sat, 29 Dec 2012 02:35:26 -0800 (PST)
Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qBTAZKAX011748; Sat, 29 Dec 2012 02:35:25 -0800 (PST)
Received: from eurhub01.eur.adobe.com (10.128.4.30) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sat, 29 Dec 2012 02:35:21 -0800
Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurhub01.eur.adobe.com ([10.128.4.30]) with mapi; Sat, 29 Dec 2012 10:34:57 +0000
From: Antonio Sanso 
To: Nat Sakimura 
Date: Sat, 29 Dec 2012 10:34:49 +0000
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lsCUr2u5dcQ3vRYG1rXXUMLoNnA==
Message-ID: <7816700B-65D6-4C91-8D62-A2EED02442F7@adobe.com>
References: <50B53D3E.1000107@KingsMountain.com> <4E1F6AAD24975D4BA5B168042967394366979DAD@TK5EX14MBXC283.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: multipart/alternative; boundary="_000_7816700B65D64C918D62A2EED02442F7adobecom_"
MIME-Version: 1.0
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 10:35:34 -0000

--_000_7816700B65D64C918D62A2EED02442F7adobecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Nat,

apologies if this sounds trivial but I am trying to understand the JW* stuf=
f and this mail thread is helping me to clarify some of my doubts.


On Dec 20, 2012, at 7:12 AM, Nat Sakimura wrote:

Thanks.

Just a few things:

1. Sign+Encrypt

kind of nitpicking here, but would not be better to invert those terms in o=
rder to sound Encrypt+Sign (as long as I know the order matters here and th=
e only safe way is encrypt than  MAC).


Sign+Encrypt is useful when you want the signed JWT as a proof of consent t=
o sign.
It can also exist after being decrypted.
If you just want integrity protection, use JWE.

For integrity should not be enough the signature so JWS?

Thanks a lot and regards

Antonio


2. Alphabetization of the terminology

That's one way of organizing it.
Another way of organizing it is to lay them out in a semantic order,
where the preceding definition cannot use the terms defined later.
It is a good way to make sure the consistency, and I probably like this way=
 better.

Of the definition themselves, I agree it still lacks bunch of terms that ne=
eds to be defined,
and needs tightening up.

Best,

Nat


On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones > wrote:

Thanks a bunch for the useful review, Jeff!  Responses are inline in green.



                                                                -- Mike



-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of =3DJeffH
Sent: Tuesday, November 27, 2012 2:23 PM
To: IETF oauth WG
Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05



Hi, at ietf-85 atlanta I agreed to do a review of draft-ietf-oauth-json-web=
-token-05, and so I have some thoughts below. Also, +1 to Hannes' comments.



Overall the spec seems to get its idea across, but is pretty rough. Part of=
 this is due to the language being convoluted, plus some concepts are only =
tacitly described (with clues scattered throughout the spec), and thus it i=
s difficult to understand without multiple passes of this spec as well as [=
JWE] and [JWS].



For example, a JWT appears to be simply either a JWS or a JWE containing a =
JWT Claims Set, but this is not stated until right before section 3.1 (and =
it isn't stated that clearly).



OK, I=92ll say that earlier and more clearly.



Immediately below are some overall comments, and then below that some detai=
led comments on various portions of the spec.  I'm not addressing everythin=
g I noticed due to time constraints (apologies).



HTH



=3DJeffH

------





JWT terminology:



Some issues seem to me to be caused by defining the JWT to be the base64url=
 encoded JSON  object itself and not having terminology to clearly refer to=
 its unencoded form.



For example, these two JSON objects together apparently comprise a (unencod=
ed) JWT..



      {"typ":"JWT",

       "alg":"HS256"}



This is the JWT Header.  The base64url encoded version is the Encoded JWT H=
eader.



      {"iss":"joe",

       "exp":1300819380,

       "http://example.com/is_root":true}



This is the JWT Claims Set.



..but there's no defined way to refer to them given the spec's terminlogy.



The terms above are already defined in the spec.



Consider terming the above a JWT and its encoded-string form an Encoded JWT=
, and define them separately. And then there'll be similar definitions for =
JWT Header and JWT Claims Set, e.g.,



I disagree with redefining the term =93JWT=94 to not also include the signa=
ture.  The term =93JWT=94 should continue to refer to the whole thing.



    Encoded JWT   A JWT that has been encoded according to the

       process defined in Section X.



    Encoded JWT Header   The encoded-string form of a JWT Header



    Encoded JWT Claims Set   The encoded-string form of a JWT Claims Set



I=92ll note that when the JWT is encrypted, a base64url encoded representat=
ion of the JWT Claims Set is never used.  (The encrypted form of them is ba=
se64url encoded instead.)



    encoded-string form   The result of applying Base64url encoding to an

       input JSON text .



Sometimes he input to the base64url encoding is not JSON =96 for instance s=
ignature values or encrypted payloads.



    JSON Web Token (JWT)  A JWT comprises a JWT Header and a JWT Claims Set=
. ...



    JWT Header  A JSON object that is a component of a JWT. It denotes the

       cryptographic operations applied to the JWT.  ...



    JWT Claims Set  A JSON object containing a set of claims.  ...



This also gets rid of the use of the "A string representing a JSON object..=
."

which I find confusing and potentially misleading (because it is actually "=
a Base64url encoding of a JSON object").



Aah =96 I now see that this is the real misunderstanding.  The =93string re=
presenting a JSON object=94 is not the base64url encoded form =96 it=92s th=
e string representation that=92s parseable into a JSON object.  For instanc=
e, it could be a string such as {=93alg=94:=94RS256=94} =96 not the base64u=
rl encoded version of that string.  The reason for the syntactic constructi=
on =93string representing a JSON object=94 is that its string representatio=
n is distinct from the abstract JSON object itself.  If I insert whitespace=
 after the colon in the string {=93alg=94:=94RS256=94} it would parse to an=
 equivalent JSON object but it would be a different string representation. =
 It=92s the string representation that is actually operated on by the JWT/J=
WS/JWE operations.



I=92ll try to make this clearer in the spec.



UTF-8:



UTF-8 is mentioned in lots of places. It could probably be stated once up n=
ear

the beginning of the spec that all the JSON text is UTF-8 encoded, and all =
the

JSON strings are UTF-8 encoded.



I=92ll see if I can figure out how to do this without introducing ambiguity=
.



Semantics, profiles and relationship to SAML:



The spec does not define any overall JWT semantics (i.e., what any given JW=
T

/means/). Semantics are only defined in context of each individual Reserved

Claim Name.



Thus any application of JWTs will need to profile the JWT spec: specifying =
the

claim set(s) contents, and the overall semantics of the resultant JWT(s).  =
This

is not explicitly explained in the JWT spec.



Can you suggest some language you=92d like to see added about this?



In terms of SAML, Appendix B should refer to SAML assertions rather than sa=
ml

tokens. Also, I'm not sure SAML assertions inherently have more expressivit=
y

than JWTs. They do have more pre-defined structure and semantics.



OK



Syntactically, it seems one can encode pretty much anything in whatever amo=
unt

in a JWT (one can do the same with SAML assertions), and thus theoretically=
 JWTs

could be used to accomplish the same things as SAML assertions.



Semantically, SAML assertions are explicitly statements made by a system en=
tity

about a subject. But by default, a JWT is empty, and has no semantics (this

isn't stated explicitly). All semantics defined in the JWT spec are particu=
lar

to individual reserved claims, but all reserved claims are optional. Thus a=
n

application of JWTs to use cases also apropos for SAML assertions will requ=
ire

arguably more profiling than that needed to apply SAML assertions.



All true.  However once you add an issuer and a principal, then you=92re ba=
ck to the JWT being statements made by an entity about a subject.  Again, i=
f there is language you believe should be added in that regard, please let =
me know.  (BTW, one such usage profile is in http://tools.ietf.org/html/dra=
ft-ietf-oauth-jwt-bearer-03.  Another is in http://openid.net/specs/openid-=
connect-messages-1_0.html#id_token.)



The token size & complexity comparison seems nominally fine.



Some detailed-but-rough comments and musings on portions of the spec as I w=
as

reading through it...



> 2. Terminology



terminology is not alphabetised!



No, it=92s in a top-down descriptive order.  Is there a requirement in IETF=
 specs that the terminology be alphabetized?



"claim", "claims", "token" should be defined in terminology



I=92ll add a definition for =93claim=94.  =93token=94 should actually proba=
bly become =93security token=94, with a definition of the term.



suggestion:



      Claim:  an assertion of something as a fact. Here, claims are

         name and value pairs, consisting of a Claim Name and a

         Claim Value.





>    JSON Web Token (JWT)



   is jwt always a "string" or is it string (only) when it's been serialize=
d

into one?



It=92s always the string representation of the serialized parts.



>                    A string representing a set of claims as a JSON

>       object that is digitally signed or MACed and/or encrypted.



   is it more that it's a set of claims encoded as a JSON object

   that is string-serialized?



No, per my earlier comments



   is it /not/ a JWT by definition if it is not ((signed or unmac'd) and/or

encrypted) ?   No, because there are Plaintext JWTs, but they aren't in

terminology (probably should be).



Good catch



   "parts" in JWT definition is unclear

     are "parts" json objects or arrays unto themselves ?



The parts are all base64url encoded values.  I=92ll review this terminology=
 usage to see if it can be clarified.



   the definition assumes knowledge that's presented later. perhaps needs f=
wd

   reference(s), or perhaps better is to not present as much technical deta=
il

   in the definitions.



I=92ll review



>    JWT Claims Set



   similar comments as to JSON Web Token (JWT)



   the definition says how it is encoded and encrypted, but not how claims =
are

mapped into a JSON object





should probably be simply:



    JWT Claims Set: A set of claims expressed as a JSON object, where each

       claim is an object member (i.e., a name/value pair). A claim may hav=
e

       a JWT Claims Set as a value.



I=92ll look into moving the definition in this direction.  What you=92re mi=
ssing in the above, though, is the distinction between the string represent=
ing the JSON object and the abstract JSON object.  We want the former.



>    Claim Name  The name of a member of the JSON object representing a

>       JWT Claims Set.



should probably be simply:



    Claim Name  The name portion of a claim, expressed as a JSON object mem=
ber

       name.





>    Claim Value  The value of a member of the JSON object representing a

>       JWT Claims Set.



should probably be simply:



    Claim Value  The value portion of a claim, expressed as a JSON object m=
ember

       value.



I=92ll look into moving the definitions in this direction.



> 3. JSON Web Token (JWT) Overview



>    The bytes of the UTF-8 representation of the JWT Claims Set are

>    digitally signed or MACed in the manner described in JSON Web

>    Signature (JWS) [JWS] and/or encrypted in the manner described in

>    JSON Web Encryption (JWE) [JWE].



s/ and/or encrypted / or encrypted and signed /



I think you mean =93encrypted and integrity protected=94 rather than =93enc=
rypted and signed=94, right?



>    The contents of the JWT Header describe the cryptographic operations

>    applied to the JWT Claims Set. If the JWT Header is a JWS Header, the

>    claims are digitally signed or MACed.  If the JWT Header is a JWE

>    Header, the claims are encrypted.



What if a JWT is signed AND encrypted?  Hm, from my looking at JWS and JWE

specs, it seems that in that case one uses JWE because that encompasses bot=
h

encrypt & sign.



No, actually JWE just provides an integrity check =96 not a signature.  If =
you want a signature, you need to use JWS.  They can (and often are) used i=
n a nested fashion.



>    A JWT is represented as a JWS or JWE.  The number of parts is

>    dependent upon the representation of the resulting JWS or JWE.



Does the above mean to say..



    A JWT consists of a JWS or JWE object, which in turn conveys the JWT

    Claims Set. In the case of a JWS, the JWT Claims Set is the JWS

    Payload. In the case of a JWE, the JWT Claims Set is the input

    Plaintext.



Yes.  Although this is missing the fact that nested signing/encryption may =
be employed.



> 4. JWT Claims

>

>

>    The JWT Claims Set represents a JSON object whose members are the

>    claims conveyed by the JWT.  The Claim Names within this object MUST

>    be unique; JWTs with duplicate Claim Names MUST be rejected.



does the above mean to say claim names must be unique amongst the set of cl=
aim

names within any given JWT Claims Set ?  If so, that's only implied by the =
above

but should be stated explicitly; as it is, the above is ambiguous.



OK



> 4.2. Public Claim Names

>

>

>    Claim names can be defined at will by those using JWTs.  However, in



s/Claim names/Public claim names/



>    order to prevent collisions, any new claim name SHOULD either be

>    registered in the IANA JSON Web Token Claims registry Section 9.1 or

>    be a URI that contains a Collision Resistant Namespace.





why should a claim name be a URI if I wish to make use of Collision Resista=
nt

Namespaces?  For example, if I simply use say UUIDs as claim names..



      {"iss":"joe",

       "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}



..it will be universally unique provided I minted it appropriately (no URI

syntax is needed).



Fair enough.  I=92ll try to generalize the language.



> 4.3. Private Claim Names

>

>

>    A producer and consumer of a JWT may agree to any claim name that is

>    not a Reserved Name Section 4.1 or a Public Name Section 4.2.  Unlike

>    Public Names, these private names are subject to collision and should

>    be used with caution.



it seems private claim names are only subject to collision if the implement=
ers

don't make appropriate use of Collision Resistant Namespaces, i.e. they "ca=
n be"

subject to collision.



True



the above two sections use "public" and "private" as distinguishing factors=
, but

it seems to me the distinguishing factor (given how the above is written) i=
s

more whether Collision Resistant Namespaces are employed or not.



Yes, although using a collision resistant namespace effectively makes them =
public, as we=92re using the term



An implied aspect of public claim names seems to be that it is assumed that=
 they

are publicly listed/documented/leaked, thus the "public" moniker, and hence

ought to be universally unique as a matter of course.



and "private" ones seem to be assumed to be obfuscated to all but the agree=
ing

parties?  Or they are "private" in only the sense that they are created in =
the

context of a private arrangement?



Private in that they are created in the context of a private arrangement.  =
I=92ll try to clarify this point.  Facebook could define how they=92re goin=
g to use the =93id=94 claim very publicly, and yet it would still be a priv=
ate claim if not registered with IANA.



>

> 7. Rules for Creating and Validating a JWT

>

>

>    To create a JWT, one MUST perform these steps.  The order of the

>    steps is not significant in cases where there are no dependencies

>    between the inputs and outputs of the steps.

>

>    1.  Create a JWT Claims Set containing the desired claims.  Note that

>        white space is explicitly allowed in the representation and no

>        canonicalization is performed before encoding.



I presume the rationale for allowing white space is that JSON objects are

unordered (and can contain arbitrary whitespace), thus simple buffer-to-buf=
fer

comparisons between serialized objects cannot be reliably performed.  If so=
 this

should be explicitly stated.



Actually, it=92s to avoid canonicalization.  I=92ll reread the spec to see =
if we=92ve stated that clearly or not.



It seems that member/value-by-member/value comparisons must always be done,=
 by

parsing the JSON objects and extracting all members and values, this should=
 be

stated explicitly in the spec.



I found meager jwt comparison instructions at the very end of Section 7. it

should probably be its own subsection. It should probably explicitly say th=
at

JWTs need to be parsed into their constituent components, and the latter mu=
st be

individually examined/compared.



We tried to cover this in the end of section 7, starting with the sentence =
=93Processing a JWT inevitably requires comparing known strings to values i=
n the token=94, which says how these comparisons must be performed.  I agre=
e that this should become its own subsection.  I don=92t understand your re=
mark about constituent components.  Can you clarify?



>    Comparisons between JSON strings and other Unicode strings MUST be

>    performed as specified below:



this comparison algorithm seems to be attempting to allow for comparison of

UTF-8 encoded JSON strings with other unicode strings in any of the unicode

encoding formats, but only implies that; it should be stated.



Good



>

>    1.  Remove any JSON applied escaping to produce an array of Unicode

>        code points.



I don't think (1) is correct.  A JSON string is by default encoded in UTF-8=
. A

UTF-8 encoded string is not "an array of Unicode code points" (its a sequen=
ce of

code units, which must be decoded into code points), i think a step is miss=
ing

here..



    1.  Remove any JSON escaping from the input JSON string.



    1.a  convert the string into a sequence of unicode code points.



How about =93Remove any JSON escaping from the input JSON string and conver=
t the string into a sequence of Unicode code points=94?



..and then compare code point-by-code point. This overall algorithm /seems/=
 ok,

but I'm not sure, it seems there's rationale that's not expressed, eg for

excluding use of Unicode Normalization [USA15]. Also the alg is incomplete =
in

that it doesn't stipulate converting the "other unicode string" into a sequ=
ence

of code points.



Fair enough



> 10. Security Considerations

>

>

>    All of the security issues faced by any cryptographic application

>    must be faced by a JWT/JWS/JWE/JWK agent.  Among these issues are

>    protecting the user's private key, preventing various attacks, and

>    helping the user avoid mistakes such as inadvertently encrypting a

>    message for the wrong recipient.  The entire list of security

>    considerations is beyond the scope of this document, but some

>    significant concerns are listed here.

>

>    All the security considerations in the JWS specification also apply

>    to JWT, as do the JWE security considerations when encryption is

>    employed.  In particular, the JWS JSON Security Considerations and

>    Unicode Comparison Security Considerations apply equally to the JWT

>    Claims Set in the same manner that they do to the JWS Header.

>



dunno if you can get away with sec cons wholly in other docs, and I'm not s=
ure

it's appropriate given that JWTs are a profile of JWE or JWS.



That was the approach that Sean had suggested.  If there other things you t=
hink we should specifically add, however, please let me know.



above needs editorial polish -- there aren't any  "significant concerns"

actually listed here.



True enough



---

end





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--_000_7816700B65D64C918D62A2EED02442F7adobecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Nat,

apologies if this sounds trivial but I am trying to understand the JW* stu=
ff and this mail thread is helping me to clarify some of my doubts.


On Dec 20, 2012, at 7:12 AM, Nat Sakimura w=
rote:

Thanks. 

Just a few things: 

<=
/div>
1. Sign+Encrypt

kind of nit=
picking here, but would not be better to invert those terms in order to sou=
nd Encrypt+Sign (as long as I know the order matters here and the only safe=
 way is encrypt than  MAC).

Sign+Encrypt is useful when you want the signed JWT as a proof=
 of consent to sign. 
It can also exist after being decrypte=
d. 


If you just want integrity protection, use JWE. 

For integrity should not be enough the signature so J=
WS?

Thanks a lot and regards

<=
div>Antonio


2. Alpha=
betization of the terminology

That's one way of or=
ganizing it. 
Another way of organizing it is to lay them ou=
t in a semantic order, 


where the preceding definition cannot use the terms defined later.&nbs=
p;
It is a good way to make sure the consistency, and I probably =
like this way better. 

Of the definition them=
selves, I agree it still lacks bunch of terms that needs to be defined,&nbs=
p;


and needs tightening up. 

Best, 

Nat


On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones <<=
a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon=
es@microsoft.com> wrote:











Thanks a bunch for the useful review, Jeff!  Responses are inl=
ine
in green.
&=
nbsp;
         &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;    -- Mike
 
-----Original Message-----

From: oauth-bou=
nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =3DJeffH

Sent: Tuesday, November 27, 2012 2:23 PM

To: IETF oauth WG

Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
 
Hi, at ietf-85 atlanta I agreed to do a review of draf=
t-ietf-oauth-json-web-token-05, and so I have some thoughts below. Also, +1=
 to Hannes' comments.
 
Overal=
l the spec seems to get its idea across, but is pretty rough. Part of this =
is due to the language being convoluted, plus some concepts are only tacitl=
y described (with clues scattered throughout the spec), and thus it is diff=
icult
 to understand without multiple passes of this spec as well as [JWE] and [J=
WS].
 
For example, a JWT appe=
ars to be simply either a JWS or a JWE containing a JWT Claims Set, but thi=
s is not stated until right before section 3.1 (and it isn't stated that cl=
early).
 


OK, I=92ll say that earlier and more=
 clearly.
 
Immediately below are some over=
all comments, and then below that some detailed comments on various portion=
s of the spec.  I'm not addressing everything I noticed due to time co=
nstraints (apologies).
 
HTH
 
=3DJeffH
=
------
 
 <=
/p>
JWT terminology:
 
Some =
issues seem to me to be caused by defining the JWT to be the base64url enco=
ded JSON  object itself and not having terminology to clearly refer to=
 its unencoded form.
 
For exa=
mple, these two JSON objects together apparently comprise a (unencoded) JWT=
..
 
    &=
nbsp; {"typ":"JWT",
      =
; "alg":"HS256"}
 


This is the JWT Header.  The ba=
se64url encoded version is the Encoded JWT Header.
=

 
&nb=
sp;     {"iss":"joe",
  &=
nbsp;    "exp":1300819380,
  &=
nbsp;    "http://example=
.com/is_root":true}
 


This is the JWT Claims Set.
 <=
/span>
..but there's no defined way to refer to them given the spec's=
 terminlogy.
 


The terms above are already defined =
in the spec.
=
 
Consider terming the above a JWT and its =
encoded-string form an Encoded JWT, and define them separately. And then th=
ere'll be similar definitions for JWT Header and JWT Claims Set, e.g.,
 


I disagree with redefining the term =
=93JWT=94 to not also include the signature.  The term =93JWT=94 shoul=
d continue to refer to the whole thing.
 
  &=
nbsp; Encoded JWT   A JWT that has been encoded according to the<=
u>
       process defined in=
 Section X.
 
  &nbs=
p; Encoded JWT Header   The encoded-string form of a JWT Header
 
    Encoded JW=
T Claims Set   The encoded-string form of a JWT Claims Set=

 


I=92ll note that when the JWT is enc=
rypted, a base64url encoded representation of the JWT Claims Set is never u=
sed.  (The encrypted form of them is base64url encoded instead.)


 
&nb=
sp;   encoded-string form   The result of applying Base=
64url encoding to an
     &nbs=
p; input JSON text .
 


Sometimes he input to the base64url =
encoding is not JSON =96 for instance signature values or encrypted payload=
s.
&nb=
sp;
    JSON Web Token (JWT)  A JWT=
 comprises a JWT Header and a JWT Claims Set. ...
 
    JWT Header  A JSON object tha=
t is a component of a JWT. It denotes the
  &=
nbsp;    cryptographic operations applied to the JWT.  =
...
 
    JWT C=
laims Set  A JSON object containing a set of claims.  ...<=
u>
 
This also gets rid of the use of th=
e "A string representing a JSON object..."

which I find confusing and potentially misleading (bec=
ause it is actually "a Base64url encoding of a JSON object").=

 


Aah =96 I now see that this is the r=
eal misunderstanding.  The =93string representing a JSON object=94 is =
not the base64url encoded form =96 it=92s the string representation that=92=
s parseable into a JSON object.  For
 instance, it could be a string such as {=93alg=94:=94RS256=94} =96 not the=
 base64url encoded version of that string.  The reason for the syntact=
ic construction =93string representing a JSON object=94 is that its string =
representation is distinct from the abstract JSON object
 itself.  If I insert whitespace after the colon in the string {=93alg=
=94:=94RS256=94} it would parse to an equivalent JSON object but it would b=
e a different string representation.  It=92s the string representation=
 that is actually operated on by the JWT/JWS/JWE operations.<=
/span>
 
<=
p>I=92ll try to make this clearer in the spec=
.
 
U=
TF-8:
 
UTF-8 is mentioned in =
lots of places. It could probably be stated once up near

the beginning of the spec that all the JSON text is UT=
F-8 encoded, and all the

JSON strings are UTF-8 encoded.
 


I=92ll see if I can figure out how t=
o do this without introducing ambiguity.
 
Semantics, profiles and relationship =
to SAML:
 
The spec does not d=
efine any overall JWT semantics (i.e., what any given JWT

/means/). Semantics are only defined in context of eac=
h individual Reserved

Claim Name.
 
Thus any application of JWTs will need to profile the JWT spec: specif=
ying the

claim set(s) contents, and the overall semantics of th=
e resultant JWT(s).  This

is not explicitly explained in the JWT spec.=

 


Can you suggest some language you=92=
d like to see added about this?
 
<=
p>In terms of SAML, Appendix B should refer to SAML assertions rather than =
saml

tokens. Also, I'm not sure SAML assertions inherently =
have more expressivity

than JWTs. They do have more pre-defined structure and=
 semantics.
 


OK
 
Syntacticall=
y, it seems one can encode pretty much anything in whatever amount

in a JWT (one can do the same with SAML assertions), a=
nd thus theoretically JWTs

could be used to accomplish the same things as SAML as=
sertions.
 
Semantically, SAML=
 assertions are explicitly statements made by a system entity

about a subject. But by default, a JWT is empty, and h=
as no semantics (this

isn't stated explicitly). All semantics defined in the=
 JWT spec are particular

to individual reserved claims, but all reserved claims=
 are optional. Thus an

application of JWTs to use cases also apropos for SAML=
 assertions will require

arguably more profiling than that needed to apply SAML=
 assertions.
 


All true.  However once you add=
 an issuer and a principal, then you=92re back to the JWT being statements =
made by an entity about a subject.  Again, if there is language you be=
lieve should be added in that regard,
 please let me know.  (BTW, one such usage profile is in 
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.  Anothe=
r is in 
http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)<=
/u>
 =

The token size & complexity comparison seems nominall=
y fine.
 
Some detailed-but-ro=
ugh comments and musings on portions of the spec as I was

reading through it...
 =
;
> 2. Terminology
 =

terminology is not alphabetised!
 


No, it=92s in a top-down descriptive=
 order.  Is there a requirement in IETF specs that the terminology be =
alphabetized?
 =

"claim", "claims", "token" should be defined in terminology
 


I=92ll add a definition for =93claim=
=94.  =93token=94 should actually probably become =93security token=94=
, with a definition of the term.
=

 
suggestion:=

 
      Claim:=
  an assertion of something as a fact. Here, claims are<=
/p>
         name and value pairs=
, consisting of a Claim Name and a
   &n=
bsp;     Claim Value.
 =

 
>    JSON Web To=
ken (JWT)
 
   is jw=
t always a "string" or is it string (only) when it's been serialized

into one?
 


It=92s always the string representat=
ion of the serialized parts.
<=
span style=3D""> 
>   &nb=
sp;            =
    A string representing a set of claims as a JSON
>       object that is digital=
ly signed or MACed and/or encrypted.
 
   is it more that it's a set of claims encoded as a JSO=
N object
   that is string-serialized?=

 


No, per my earlier comments 

 
   is it /not/ a JWT by definition if it is not ((=
signed or unmac'd) and/or

encrypted) ?   No, because there are Plainte=
xt JWTs, but they aren't in

terminology (probably should be).
=
 


Good catch
<=
div class=3D"im">
 
&nbs=
p;  "parts" in JWT definition is unclear
 &nb=
sp;   are "parts" json objects or arrays unto themselves ?=

 


The parts are all base64url encoded =
values.  I=92ll review this terminology usage to see if it can be clar=
ified.
 
   the definition assumes knowledge t=
hat's presented later. perhaps needs fwd
   r=
eference(s), or perhaps better is to not present as much technical detail
   in the definitions.
=
 


I=92ll review
 
>    JW=
T Claims Set
 
   si=
milar comments as to JSON Web Token (JWT)
 =

   the definition says how it is encoded and encryp=
ted, but not how claims are

mapped into a JSON object
&=
nbsp;
 
should probably be simply:=

 
    JWT Claims =
Set: A set of claims expressed as a JSON object, where each
       claim is an object member (i.e., =
a name/value pair). A claim may have
   =
    a JWT Claims Set as a value.
=
 


I=92ll look into moving the definiti=
on in this direction.  What you=92re missing in the above, though, is =
the distinction between the string representing the JSON object and the abs=
tract JSON object.  We want
 the former.
 <=
/u>
>    Claim Name  The name of a member of t=
he JSON object representing a
>   &nb=
sp;   JWT Claims Set.
 
should probably be simply:
 
=

    Claim Name  The name portion of a claim, express=
ed as a JSON object member
    &nbs=
p;  name.
 
 =

>    Claim Value  The value of a membe=
r of the JSON object representing a
>  &nb=
sp;    JWT Claims Set.
 <=
/u>
should probably be simply:
 
    Claim Value  The value portion of a claim,=
 expressed as a JSON object member
   &n=
bsp;   value.
 


I=92ll look into moving the definiti=
ons in this direction. 

 
&g=
t; 3. JSON Web Token (JWT) Overview
 
>    The bytes of the UTF-8 representation of the=
 JWT Claims Set are
>    digitally si=
gned or MACed in the manner described in JSON Web
>&=
nbsp;   Signature (JWS) [JWS] and/or encrypted in the manner desc=
ribed in
>    JSON Web Encryption (JW=
E) [JWE].
 
s/ and/or encrypte=
d / or encrypted and signed /
 


I think you mean =93encrypted and in=
tegrity protected=94 rather than =93encrypted and signed=94, right?<=
u>
 
> =
   The contents of the JWT Header describe the cryptographic oper=
ations
>    applied to the JWT Claims=
 Set. If the JWT Header is a JWS Header, the
> =
   claims are digitally signed or MACed.  If the JWT Header =
is a JWE
>    Header, the claims are =
encrypted.
 
What if a JWT is =
signed AND encrypted?  Hm, from my looking at JWS and JWE

specs, it seems that in that case one uses JWE because=
 that encompasses both

encrypt & sign.
 <=
u>


No, actually JWE just provides an in=
tegrity check =96 not a signature.  If you want a signature, you need =
to use JWS.  They can (and often are) used in a nested fashion.=



 
>    A JW=
T is represented as a JWS or JWE.  The number of parts is
>    dependent upon the representation of the res=
ulting JWS or JWE.
 
Does the =
above mean to say..
 
 &n=
bsp;  A JWT consists of a JWS or JWE object, which in turn conveys the=
 JWT
    Claims Set. In the case of a JW=
S, the JWT Claims Set is the JWS
    Pay=
load. In the case of a JWE, the JWT Claims Set is the input
    Plaintext.
 =



Yes.  Although this is missing =
the fact that nested signing/encryption may be employed.
 
> 4. JWT Claims=

>
>
>&nb=
sp;   The JWT Claims Set represents a JSON object whose members a=
re the
>    claims conveyed by the JW=
T.  The Claim Names within this object MUST
>&n=
bsp;   be unique; JWTs with duplicate Claim Names MUST be rejecte=
d.
 
does the above mean to sa=
y claim names must be unique amongst the set of claim

names within any given JWT Claims Set ?  If so, t=
hat's only implied by the above

but should be stated explicitly; as it is, the above i=
s ambiguous.
 


OK
 
> 4.2. Public Claim Names<=
u>
>
>
> &n=
bsp;  Claim names can be defined at will by those using JWTs.  Ho=
wever, in
 
s/Claim names/Publ=
ic claim names/
 
> &n=
bsp;  order to prevent collisions, any new claim name SHOULD either be=

>    registered in the IANA JSON Web=
 Token Claims registry Section 9.1 or
>  &=
nbsp; be a URI that contains a Collision Resistant Namespace.=

 
 
why should a c=
laim name be a URI if I wish to make use of Collision Resistant

Namespaces?  For example, if I simply use say UUI=
Ds as claim names..
 
 &n=
bsp;    {"iss":"joe",
   =
    "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}<=
/u>
 
..it will be universally unique provid=
ed I minted it appropriately (no URI

syntax is needed).
 


Fair enough.  I=92ll try to gen=
eralize the language.
 
> 4.3. Private C=
laim Names
>
><=
/p>
>    A producer and consumer of a JWT may agree to =
any claim name that is
>    not a Res=
erved Name Section 4.1 or a Public Name Section 4.2.  Unlike=

>    Public Names, these private names are sub=
ject to collision and should
>    be =
used with caution.
 
it seems =
private claim names are only subject to collision if the implementers

don't make appropriate use of Collision Resistant Name=
spaces, i.e. they "can be"

subject to collision.
 =
;


True
 
the above two sections use "public=
" and "private" as distinguishing factors, but

it seems to me the distinguishing factor (given how th=
e above is written) is

more whether Collision Resistant Namespaces are employ=
ed or not.
 


Yes, although using a collision resi=
stant namespace effectively makes them public, as we=92re using the term=

 
An implied aspect of public claim names seems to be that=
 it is assumed that they

are publicly listed/documented/leaked, thus the "publi=
c" moniker, and hence

ought to be universally unique as a matter of course.<=
u>
 
and "private" ones seem to b=
e assumed to be obfuscated to all but the agreeing

parties?  Or they are "private" in only the sense=
 that they are created in the

context of a private arrangement?
=
 


Private in that they are created in =
the context of a private arrangement.  I=92ll try to clarify this poin=
t.  Facebook could define how they=92re going to use the =93id=94 clai=
m very publicly, and yet it would still
 be a private claim if not registered with IANA.
 
>
>=
 7. Rules for Creating and Validating a JWT
>=

>
>    To create a J=
WT, one MUST perform these steps.  The order of the
<=
p>>    steps is not significant in cases where there are =
no dependencies
>    between the inpu=
ts and outputs of the steps.
>
&=
gt;    1.  Create a JWT Claims Set containing the desir=
ed claims.  Note that
>    =
    white space is explicitly allowed in the representation =
and no
>        c=
anonicalization is performed before encoding.
&n=
bsp;
I presume the rationale for allowing white space is that =
JSON objects are

unordered (and can contain arbitrary whitespace), thus=
 simple buffer-to-buffer

comparisons between serialized objects cannot be relia=
bly performed.  If so this

should be explicitly stated.
 


Actually, it=92s to avoid canonicali=
zation.  I=92ll reread the spec to see if we=92ve stated that clearly =
or not.
 
It seems that member/value-by-member/value com=
parisons must always be done, by

parsing the JSON objects and extracting all members an=
d values, this should be

stated explicitly in the spec.
=
 
I found meager jwt comparison instructions at the v=
ery end of Section 7. it

should probably be its own subsection. It should proba=
bly explicitly say that

JWTs need to be parsed into their constituent componen=
ts, and the latter must be

individually examined/compared.
 


We tried to cover this in the end of=
 section 7, starting with the sentence =93Processing a JWT inevitably requi=
res comparing known strings to values in the token=94, which says how these=
 comparisons must be performed. 
 I agree that this should become its own subsection.  I don=92t unders=
tand your remark about constituent components.  Can you clarify?
 
>    Comparisons between JSON strings and=
 other Unicode strings MUST be
>    p=
erformed as specified below:
 
this comparison algorithm seems to be attempting to allow for comparison o=
f

UTF-8 encoded JSON strings with other unicode strings =
in any of the unicode

encoding formats, but only implies that; it should be =
stated.
 


Good
 
>
>    1.  Remove any JSON applied esca=
ping to produce an array of Unicode
>  &nb=
sp;     code points.
 <=
u>
I don't think (1) is correct.  A JSON string is by defaul=
t encoded in UTF-8. A

UTF-8 encoded string is not "an array of Unicode code =
points" (its a sequence of

code units, which must be decoded into code points), i=
 think a step is missing

here..
 
=
    1.  Remove any JSON escaping from the input JSON st=
ring.
 
    1.a=
  convert the string into a sequence of unicode code points.=

 


How about =93Remove any JSON escapin=
g from the input JSON string and convert the string into a sequence of Unic=
ode code points=94?
 
..and then compare code point-by-c=
ode point. This overall algorithm /seems/ ok,

but I'm not sure, it seems there's rationale that's no=
t expressed, eg for

excluding use of Unicode Normalization [USA15]. Also t=
he alg is incomplete in

that it doesn't stipulate converting the "other unicod=
e string" into a sequence

of code points.
 


Fair enough
=

 
> 10. Security Considera=
tions
>
>
>    All of the security issues faced by any cryptograph=
ic application
>    must be faced by =
a JWT/JWS/JWE/JWK agent.  Among these issues are
&=
gt;    protecting the user's private key, preventing various=
 attacks, and
>    helping the user a=
void mistakes such as inadvertently encrypting a
>&n=
bsp;   message for the wrong recipient.  The entire list of =
security
>    considerations is beyon=
d the scope of this document, but some
>  =
  significant concerns are listed here.
>
>    All the security considerations in th=
e JWS specification also apply
>    t=
o JWT, as do the JWE security considerations when encryption is
>    employed.  In particular, the JWS JSON=
 Security Considerations and
>    Uni=
code Comparison Security Considerations apply equally to the JWT<=
/u>
>    Claims Set in the same manner that they do=
 to the JWS Header.
>
&nb=
sp;
dunno if you can get away with sec cons wholly in other do=
cs, and I'm not sure

it's appropriate given that JWTs are a profile of JWE =
or JWS.
 


That was the approach that Sean had =
suggested.  If there other things you think we should specifically add=
, however, please let me know.
 
above needs editorial p=
olish -- there aren't any  "significant concerns"

actually listed here.
 =
;


True enough
=

 
---
end=

 
 
=
_______________________________________________
OAuth m=
ailing list
OAuth@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/oauth







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



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

=

--_000_7816700B65D64C918D62A2EED02442F7adobecom_--

From ve7jtb@ve7jtb.com  Sat Dec 29 07:43:48 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F9B21F869C for ; Sat, 29 Dec 2012 07:43:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.534
X-Spam-Level: 
X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=-1.591, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1v8+NCxpBiU for ; Sat, 29 Dec 2012 07:43:45 -0800 (PST)
Received: from mail-yh0-f53.google.com (mail-yh0-f53.google.com [209.85.213.53]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9FF21F86C4 for ; Sat, 29 Dec 2012 07:43:39 -0800 (PST)
Received: by mail-yh0-f53.google.com with SMTP id q11so1928902yhf.12 for ; Sat, 29 Dec 2012 07:43:38 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=qUPX7haKaPltZfyfSFUDl2LsXOqpK1gfY2EGK19kfKU=; b=RNszp8Miu3a1F1FZlnm+53/sNzjya2IKuPbSeyEeNNqeTvXBeFFmA7eh6Wd5u0AmwX nOyurvTjd+foLk8f5YE37XXrEYHxe7zTnT4q8NDGlJxaTbM5KpFksadnEpdrmS/gnmKR WqAQAhsHbheQzTk4d6aZ/VhOvoFjBt0UwCk4BQzc/tfz304T8lt7PQ+HUqq2KkIJQyt7 WXfw2E4CpQlne/VwlgIaOZ9hsNMUWowGy/Tm1j9cJU43TjMJTvwb+XRiIQq8j8unHRLu jxcjRPsCsqN3Lj22nLz/fePfmjzfiJKlroC8syDBUwi3Awl42kqA4fdXKf/gZdeli3lu qnWw==
X-Received: by 10.236.82.169 with SMTP id o29mr33327991yhe.116.1356795818750;  Sat, 29 Dec 2012 07:43:38 -0800 (PST)
Received: from [192.168.1.211] (190-20-5-108.baf.movistar.cl. [190.20.5.108]) by mx.google.com with ESMTPS id u49sm33532189yhd.18.2012.12.29.07.43.34 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Dec 2012 07:43:37 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_BBE17345-BB2E-4EC8-856F-EF2EAC8CB713"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley 
In-Reply-To: <7816700B-65D6-4C91-8D62-A2EED02442F7@adobe.com>
Date: Sat, 29 Dec 2012 12:43:26 -0300
Message-Id: <4E48A647-8507-4648-8FE0-D6BB2447274A@ve7jtb.com>
References: <50B53D3E.1000107@KingsMountain.com> <4E1F6AAD24975D4BA5B168042967394366979DAD@TK5EX14MBXC283.redmond.corp.microsoft.com>  <7816700B-65D6-4C91-8D62-A2EED02442F7@adobe.com>
To: Antonio Sanso 
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmDRfCn9QbRUMKJYBuq3qlEyzLrcpjoThS6esgmLGkdwl+N2WV7YywUabi3kqsOBWSy6jy9
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 15:43:48 -0000

--Apple-Mail=_BBE17345-BB2E-4EC8-856F-EF2EAC8CB713
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

HMAC is not technically considered signing, it is integrity protection.  =
(There is a more or less endless debate around this.)

The best practice is to sign asymmetrically for non repudiation using an =
asymmetric key, then encrypt with an AEAD algorithm to guarantee =
integrity.

JWE only supports encryption with integrity. (equivalent to encrypt + =
HMAC)=20

If you want to use symmetric keys for encryption with JWE you always get =
the equivalent of encrypt + HMAC.

That is why an additional HMAC (Some call signature) step is not =
required.   So JWE on its own is sufficient for encryption plus =
integrity. =20

Signing on its own is always better inside the Encryption that way it =
can persist as evidence after the token is decrypted.

That is not to say that there are not use cases for Encrypt then =
asymmetrically sign, however most of them are covered by JWE using AEAD =
only.

John B.

On 2012-12-29, at 7:34 AM, Antonio Sanso  wrote:

> Hi Nat,
>=20
> apologies if this sounds trivial but I am trying to understand the JW* =
stuff and this mail thread is helping me to clarify some of my doubts.
>=20
>=20
> On Dec 20, 2012, at 7:12 AM, Nat Sakimura wrote:
>=20
>> Thanks.=20
>>=20
>> Just a few things:=20
>>=20
>> 1. Sign+Encrypt
>=20
> kind of nitpicking here, but would not be better to invert those terms =
in order to sound Encrypt+Sign (as long as I know the order matters here =
and the only safe way is encrypt than  MAC).
>=20
>>=20
>> Sign+Encrypt is useful when you want the signed JWT as a proof of =
consent to sign.=20
>> It can also exist after being decrypted.=20
>> If you just want integrity protection, use JWE.=20
>=20
> For integrity should not be enough the signature so JWS?
>=20
> Thanks a lot and regards
>=20
> Antonio
>=20
>>=20
>> 2. Alphabetization of the terminology
>>=20
>> That's one way of organizing it.=20
>> Another way of organizing it is to lay them out in a semantic order,=20=

>> where the preceding definition cannot use the terms defined later.=20
>> It is a good way to make sure the consistency, and I probably like =
this way better.=20
>>=20
>> Of the definition themselves, I agree it still lacks bunch of terms =
that needs to be defined,=20
>> and needs tightening up.=20
>>=20
>> Best,=20
>>=20
>> Nat
>>=20
>>=20
>> On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones =
 wrote:
>> Thanks a bunch for the useful review, Jeff!  Responses are inline in =
green.
>>=20
>> =20
>>=20
>>                                                                 -- =
Mike
>>=20
>> =20
>>=20
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On =
Behalf Of =3DJeffH
>> Sent: Tuesday, November 27, 2012 2:23 PM
>> To: IETF oauth WG
>> Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>>=20
>> =20
>>=20
>> Hi, at ietf-85 atlanta I agreed to do a review of =
draft-ietf-oauth-json-web-token-05, and so I have some thoughts below. =
Also, +1 to Hannes' comments.
>>=20
>> =20
>>=20
>> Overall the spec seems to get its idea across, but is pretty rough. =
Part of this is due to the language being convoluted, plus some concepts =
are only tacitly described (with clues scattered throughout the spec), =
and thus it is difficult to understand without multiple passes of this =
spec as well as [JWE] and [JWS].
>>=20
>> =20
>>=20
>> For example, a JWT appears to be simply either a JWS or a JWE =
containing a JWT Claims Set, but this is not stated until right before =
section 3.1 (and it isn't stated that clearly).
>>=20
>> =20
>>=20
>> OK, I=92ll say that earlier and more clearly.
>>=20
>> =20
>>=20
>> Immediately below are some overall comments, and then below that some =
detailed comments on various portions of the spec.  I'm not addressing =
everything I noticed due to time constraints (apologies).
>>=20
>> =20
>>=20
>> HTH
>>=20
>> =20
>>=20
>> =3DJeffH
>>=20
>> ------
>>=20
>> =20
>>=20
>> =20
>>=20
>> JWT terminology:
>>=20
>> =20
>>=20
>> Some issues seem to me to be caused by defining the JWT to be the =
base64url encoded JSON  object itself and not having terminology to =
clearly refer to its unencoded form.
>>=20
>> =20
>>=20
>> For example, these two JSON objects together apparently comprise a =
(unencoded) JWT..
>>=20
>> =20
>>=20
>>       {"typ":"JWT",
>>=20
>>        "alg":"HS256"}
>>=20
>> =20
>>=20
>> This is the JWT Header.  The base64url encoded version is the Encoded =
JWT Header.
>>=20
>> =20
>>=20
>>       {"iss":"joe",
>>=20
>>        "exp":1300819380,
>>=20
>>        "http://example.com/is_root":true}
>>=20
>> =20
>>=20
>> This is the JWT Claims Set.
>>=20
>> =20
>>=20
>> ..but there's no defined way to refer to them given the spec's =
terminlogy.
>>=20
>> =20
>>=20
>> The terms above are already defined in the spec.
>>=20
>> =20
>>=20
>> Consider terming the above a JWT and its encoded-string form an =
Encoded JWT, and define them separately. And then there'll be similar =
definitions for JWT Header and JWT Claims Set, e.g.,
>>=20
>> =20
>>=20
>> I disagree with redefining the term =93JWT=94 to not also include the =
signature.  The term =93JWT=94 should continue to refer to the whole =
thing.
>>=20
>> =20
>>=20
>>     Encoded JWT   A JWT that has been encoded according to the
>>=20
>>        process defined in Section X.
>>=20
>> =20
>>=20
>>     Encoded JWT Header   The encoded-string form of a JWT Header
>>=20
>> =20
>>=20
>>     Encoded JWT Claims Set   The encoded-string form of a JWT Claims =
Set
>>=20
>> =20
>>=20
>> I=92ll note that when the JWT is encrypted, a base64url encoded =
representation of the JWT Claims Set is never used.  (The encrypted form =
of them is base64url encoded instead.)
>>=20
>> =20
>>=20
>>     encoded-string form   The result of applying Base64url encoding =
to an
>>=20
>>        input JSON text .
>>=20
>> =20
>>=20
>> Sometimes he input to the base64url encoding is not JSON =96 for =
instance signature values or encrypted payloads.
>>=20
>> =20
>>=20
>>     JSON Web Token (JWT)  A JWT comprises a JWT Header and a JWT =
Claims Set. ...
>>=20
>> =20
>>=20
>>     JWT Header  A JSON object that is a component of a JWT. It =
denotes the
>>=20
>>        cryptographic operations applied to the JWT.  ...
>>=20
>> =20
>>=20
>>     JWT Claims Set  A JSON object containing a set of claims.  ...
>>=20
>> =20
>>=20
>> This also gets rid of the use of the "A string representing a JSON =
object..."
>>=20
>> which I find confusing and potentially misleading (because it is =
actually "a Base64url encoding of a JSON object").
>>=20
>> =20
>>=20
>> Aah =96 I now see that this is the real misunderstanding.  The =
=93string representing a JSON object=94 is not the base64url encoded =
form =96 it=92s the string representation that=92s parseable into a JSON =
object.  For instance, it could be a string such as {=93alg=94:=94RS256=94=
} =96 not the base64url encoded version of that string.  The reason for =
the syntactic construction =93string representing a JSON object=94 is =
that its string representation is distinct from the abstract JSON object =
itself.  If I insert whitespace after the colon in the string =
{=93alg=94:=94RS256=94} it would parse to an equivalent JSON object but =
it would be a different string representation.  It=92s the string =
representation that is actually operated on by the JWT/JWS/JWE =
operations.
>>=20
>> =20
>>=20
>> I=92ll try to make this clearer in the spec.
>>=20
>> =20
>>=20
>> UTF-8:
>>=20
>> =20
>>=20
>> UTF-8 is mentioned in lots of places. It could probably be stated =
once up near
>>=20
>> the beginning of the spec that all the JSON text is UTF-8 encoded, =
and all the
>>=20
>> JSON strings are UTF-8 encoded.
>>=20
>> =20
>>=20
>> I=92ll see if I can figure out how to do this without introducing =
ambiguity.
>>=20
>> =20
>>=20
>> Semantics, profiles and relationship to SAML:
>>=20
>> =20
>>=20
>> The spec does not define any overall JWT semantics (i.e., what any =
given JWT
>>=20
>> /means/). Semantics are only defined in context of each individual =
Reserved
>>=20
>> Claim Name.
>>=20
>> =20
>>=20
>> Thus any application of JWTs will need to profile the JWT spec: =
specifying the
>>=20
>> claim set(s) contents, and the overall semantics of the resultant =
JWT(s).  This
>>=20
>> is not explicitly explained in the JWT spec.
>>=20
>> =20
>>=20
>> Can you suggest some language you=92d like to see added about this?
>>=20
>> =20
>>=20
>> In terms of SAML, Appendix B should refer to SAML assertions rather =
than saml
>>=20
>> tokens. Also, I'm not sure SAML assertions inherently have more =
expressivity
>>=20
>> than JWTs. They do have more pre-defined structure and semantics.
>>=20
>> =20
>>=20
>> OK
>>=20
>> =20
>>=20
>> Syntactically, it seems one can encode pretty much anything in =
whatever amount
>>=20
>> in a JWT (one can do the same with SAML assertions), and thus =
theoretically JWTs
>>=20
>> could be used to accomplish the same things as SAML assertions.
>>=20
>> =20
>>=20
>> Semantically, SAML assertions are explicitly statements made by a =
system entity
>>=20
>> about a subject. But by default, a JWT is empty, and has no semantics =
(this
>>=20
>> isn't stated explicitly). All semantics defined in the JWT spec are =
particular
>>=20
>> to individual reserved claims, but all reserved claims are optional. =
Thus an
>>=20
>> application of JWTs to use cases also apropos for SAML assertions =
will require
>>=20
>> arguably more profiling than that needed to apply SAML assertions.
>>=20
>> =20
>>=20
>> All true.  However once you add an issuer and a principal, then =
you=92re back to the JWT being statements made by an entity about a =
subject.  Again, if there is language you believe should be added in =
that regard, please let me know.  (BTW, one such usage profile is in =
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.  Another is =
in http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)
>>=20
>> =20
>>=20
>> The token size & complexity comparison seems nominally fine.
>>=20
>> =20
>>=20
>> Some detailed-but-rough comments and musings on portions of the spec =
as I was
>>=20
>> reading through it...
>>=20
>> =20
>>=20
>> > 2. Terminology
>>=20
>> =20
>>=20
>> terminology is not alphabetised!
>>=20
>> =20
>>=20
>> No, it=92s in a top-down descriptive order.  Is there a requirement =
in IETF specs that the terminology be alphabetized?
>>=20
>> =20
>>=20
>> "claim", "claims", "token" should be defined in terminology
>>=20
>> =20
>>=20
>> I=92ll add a definition for =93claim=94.  =93token=94 should actually =
probably become =93security token=94, with a definition of the term.
>>=20
>> =20
>>=20
>> suggestion:
>>=20
>> =20
>>=20
>>       Claim:  an assertion of something as a fact. Here, claims are
>>=20
>>          name and value pairs, consisting of a Claim Name and a
>>=20
>>          Claim Value.
>>=20
>> =20
>>=20
>> =20
>>=20
>> >    JSON Web Token (JWT)
>>=20
>> =20
>>=20
>>    is jwt always a "string" or is it string (only) when it's been =
serialized
>>=20
>> into one?
>>=20
>> =20
>>=20
>> It=92s always the string representation of the serialized parts.
>>=20
>> =20
>>=20
>> >                    A string representing a set of claims as a JSON
>>=20
>> >       object that is digitally signed or MACed and/or encrypted.
>>=20
>> =20
>>=20
>>    is it more that it's a set of claims encoded as a JSON object
>>=20
>>    that is string-serialized?
>>=20
>> =20
>>=20
>> No, per my earlier comments
>>=20
>> =20
>>=20
>>    is it /not/ a JWT by definition if it is not ((signed or unmac'd) =
and/or
>>=20
>> encrypted) ?   No, because there are Plaintext JWTs, but they aren't =
in
>>=20
>> terminology (probably should be).
>>=20
>> =20
>>=20
>> Good catch
>>=20
>> =20
>>=20
>>    "parts" in JWT definition is unclear
>>=20
>>      are "parts" json objects or arrays unto themselves ?
>>=20
>> =20
>>=20
>> The parts are all base64url encoded values.  I=92ll review this =
terminology usage to see if it can be clarified.
>>=20
>> =20
>>=20
>>    the definition assumes knowledge that's presented later. perhaps =
needs fwd
>>=20
>>    reference(s), or perhaps better is to not present as much =
technical detail
>>=20
>>    in the definitions.
>>=20
>> =20
>>=20
>> I=92ll review
>>=20
>> =20
>>=20
>> >    JWT Claims Set
>>=20
>> =20
>>=20
>>    similar comments as to JSON Web Token (JWT)
>>=20
>> =20
>>=20
>>    the definition says how it is encoded and encrypted, but not how =
claims are
>>=20
>> mapped into a JSON object
>>=20
>> =20
>>=20
>> =20
>>=20
>> should probably be simply:
>>=20
>> =20
>>=20
>>     JWT Claims Set: A set of claims expressed as a JSON object, where =
each
>>=20
>>        claim is an object member (i.e., a name/value pair). A claim =
may have
>>=20
>>        a JWT Claims Set as a value.
>>=20
>> =20
>>=20
>> I=92ll look into moving the definition in this direction.  What =
you=92re missing in the above, though, is the distinction between the =
string representing the JSON object and the abstract JSON object.  We =
want the former.
>>=20
>> =20
>>=20
>> >    Claim Name  The name of a member of the JSON object representing =
a
>>=20
>> >       JWT Claims Set.
>>=20
>> =20
>>=20
>> should probably be simply:
>>=20
>> =20
>>=20
>>     Claim Name  The name portion of a claim, expressed as a JSON =
object member
>>=20
>>        name.
>>=20
>> =20
>>=20
>> =20
>>=20
>> >    Claim Value  The value of a member of the JSON object =
representing a
>>=20
>> >       JWT Claims Set.
>>=20
>> =20
>>=20
>> should probably be simply:
>>=20
>> =20
>>=20
>>     Claim Value  The value portion of a claim, expressed as a JSON =
object member
>>=20
>>        value.
>>=20
>> =20
>>=20
>> I=92ll look into moving the definitions in this direction.=20
>>=20
>> =20
>>=20
>> > 3. JSON Web Token (JWT) Overview
>>=20
>> =20
>>=20
>> >    The bytes of the UTF-8 representation of the JWT Claims Set are
>>=20
>> >    digitally signed or MACed in the manner described in JSON Web
>>=20
>> >    Signature (JWS) [JWS] and/or encrypted in the manner described =
in
>>=20
>> >    JSON Web Encryption (JWE) [JWE].
>>=20
>> =20
>>=20
>> s/ and/or encrypted / or encrypted and signed /
>>=20
>> =20
>>=20
>> I think you mean =93encrypted and integrity protected=94 rather than =
=93encrypted and signed=94, right?
>>=20
>> =20
>>=20
>> >    The contents of the JWT Header describe the cryptographic =
operations
>>=20
>> >    applied to the JWT Claims Set. If the JWT Header is a JWS =
Header, the
>>=20
>> >    claims are digitally signed or MACed.  If the JWT Header is a =
JWE
>>=20
>> >    Header, the claims are encrypted.
>>=20
>> =20
>>=20
>> What if a JWT is signed AND encrypted?  Hm, from my looking at JWS =
and JWE
>>=20
>> specs, it seems that in that case one uses JWE because that =
encompasses both
>>=20
>> encrypt & sign.
>>=20
>> =20
>>=20
>> No, actually JWE just provides an integrity check =96 not a =
signature.  If you want a signature, you need to use JWS.  They can (and =
often are) used in a nested fashion.
>>=20
>> =20
>>=20
>> >    A JWT is represented as a JWS or JWE.  The number of parts is
>>=20
>> >    dependent upon the representation of the resulting JWS or JWE.
>>=20
>> =20
>>=20
>> Does the above mean to say..
>>=20
>> =20
>>=20
>>     A JWT consists of a JWS or JWE object, which in turn conveys the =
JWT
>>=20
>>     Claims Set. In the case of a JWS, the JWT Claims Set is the JWS
>>=20
>>     Payload. In the case of a JWE, the JWT Claims Set is the input
>>=20
>>     Plaintext.
>>=20
>> =20
>>=20
>> Yes.  Although this is missing the fact that nested =
signing/encryption may be employed.
>>=20
>> =20
>>=20
>> > 4. JWT Claims
>>=20
>> >
>>=20
>> >
>>=20
>> >    The JWT Claims Set represents a JSON object whose members are =
the
>>=20
>> >    claims conveyed by the JWT.  The Claim Names within this object =
MUST
>>=20
>> >    be unique; JWTs with duplicate Claim Names MUST be rejected.
>>=20
>> =20
>>=20
>> does the above mean to say claim names must be unique amongst the set =
of claim
>>=20
>> names within any given JWT Claims Set ?  If so, that's only implied =
by the above
>>=20
>> but should be stated explicitly; as it is, the above is ambiguous.
>>=20
>> =20
>>=20
>> OK
>>=20
>> =20
>>=20
>> > 4.2. Public Claim Names
>>=20
>> >
>>=20
>> >
>>=20
>> >    Claim names can be defined at will by those using JWTs.  =
However, in
>>=20
>> =20
>>=20
>> s/Claim names/Public claim names/
>>=20
>> =20
>>=20
>> >    order to prevent collisions, any new claim name SHOULD either be
>>=20
>> >    registered in the IANA JSON Web Token Claims registry Section =
9.1 or
>>=20
>> >    be a URI that contains a Collision Resistant Namespace.
>>=20
>> =20
>>=20
>> =20
>>=20
>> why should a claim name be a URI if I wish to make use of Collision =
Resistant
>>=20
>> Namespaces?  For example, if I simply use say UUIDs as claim names..
>>=20
>> =20
>>=20
>>       {"iss":"joe",
>>=20
>>        "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}
>>=20
>> =20
>>=20
>> ..it will be universally unique provided I minted it appropriately =
(no URI
>>=20
>> syntax is needed).
>>=20
>> =20
>>=20
>> Fair enough.  I=92ll try to generalize the language.
>>=20
>> =20
>>=20
>> > 4.3. Private Claim Names
>>=20
>> >
>>=20
>> >
>>=20
>> >    A producer and consumer of a JWT may agree to any claim name =
that is
>>=20
>> >    not a Reserved Name Section 4.1 or a Public Name Section 4.2.  =
Unlike
>>=20
>> >    Public Names, these private names are subject to collision and =
should
>>=20
>> >    be used with caution.
>>=20
>> =20
>>=20
>> it seems private claim names are only subject to collision if the =
implementers
>>=20
>> don't make appropriate use of Collision Resistant Namespaces, i.e. =
they "can be"
>>=20
>> subject to collision.
>>=20
>> =20
>>=20
>> True
>>=20
>> =20
>>=20
>> the above two sections use "public" and "private" as distinguishing =
factors, but
>>=20
>> it seems to me the distinguishing factor (given how the above is =
written) is
>>=20
>> more whether Collision Resistant Namespaces are employed or not.
>>=20
>> =20
>>=20
>> Yes, although using a collision resistant namespace effectively makes =
them public, as we=92re using the term
>>=20
>> =20
>>=20
>> An implied aspect of public claim names seems to be that it is =
assumed that they
>>=20
>> are publicly listed/documented/leaked, thus the "public" moniker, and =
hence
>>=20
>> ought to be universally unique as a matter of course.
>>=20
>> =20
>>=20
>> and "private" ones seem to be assumed to be obfuscated to all but the =
agreeing
>>=20
>> parties?  Or they are "private" in only the sense that they are =
created in the
>>=20
>> context of a private arrangement?
>>=20
>> =20
>>=20
>> Private in that they are created in the context of a private =
arrangement.  I=92ll try to clarify this point.  Facebook could define =
how they=92re going to use the =93id=94 claim very publicly, and yet it =
would still be a private claim if not registered with IANA.
>>=20
>> =20
>>=20
>> >
>>=20
>> > 7. Rules for Creating and Validating a JWT
>>=20
>> >
>>=20
>> >
>>=20
>> >    To create a JWT, one MUST perform these steps.  The order of the
>>=20
>> >    steps is not significant in cases where there are no =
dependencies
>>=20
>> >    between the inputs and outputs of the steps.
>>=20
>> >
>>=20
>> >    1.  Create a JWT Claims Set containing the desired claims.  Note =
that
>>=20
>> >        white space is explicitly allowed in the representation and =
no
>>=20
>> >        canonicalization is performed before encoding.
>>=20
>> =20
>>=20
>> I presume the rationale for allowing white space is that JSON objects =
are
>>=20
>> unordered (and can contain arbitrary whitespace), thus simple =
buffer-to-buffer
>>=20
>> comparisons between serialized objects cannot be reliably performed.  =
If so this
>>=20
>> should be explicitly stated.
>>=20
>> =20
>>=20
>> Actually, it=92s to avoid canonicalization.  I=92ll reread the spec =
to see if we=92ve stated that clearly or not.
>>=20
>> =20
>>=20
>> It seems that member/value-by-member/value comparisons must always be =
done, by
>>=20
>> parsing the JSON objects and extracting all members and values, this =
should be
>>=20
>> stated explicitly in the spec.
>>=20
>> =20
>>=20
>> I found meager jwt comparison instructions at the very end of Section =
7. it
>>=20
>> should probably be its own subsection. It should probably explicitly =
say that
>>=20
>> JWTs need to be parsed into their constituent components, and the =
latter must be
>>=20
>> individually examined/compared.
>>=20
>> =20
>>=20
>> We tried to cover this in the end of section 7, starting with the =
sentence =93Processing a JWT inevitably requires comparing known strings =
to values in the token=94, which says how these comparisons must be =
performed.  I agree that this should become its own subsection.  I don=92t=
 understand your remark about constituent components.  Can you clarify?
>>=20
>> =20
>>=20
>> >    Comparisons between JSON strings and other Unicode strings MUST =
be
>>=20
>> >    performed as specified below:
>>=20
>> =20
>>=20
>> this comparison algorithm seems to be attempting to allow for =
comparison of
>>=20
>> UTF-8 encoded JSON strings with other unicode strings in any of the =
unicode
>>=20
>> encoding formats, but only implies that; it should be stated.
>>=20
>> =20
>>=20
>> Good
>>=20
>> =20
>>=20
>> >
>>=20
>> >    1.  Remove any JSON applied escaping to produce an array of =
Unicode
>>=20
>> >        code points.
>>=20
>> =20
>>=20
>> I don't think (1) is correct.  A JSON string is by default encoded in =
UTF-8. A
>>=20
>> UTF-8 encoded string is not "an array of Unicode code points" (its a =
sequence of
>>=20
>> code units, which must be decoded into code points), i think a step =
is missing
>>=20
>> here..
>>=20
>> =20
>>=20
>>     1.  Remove any JSON escaping from the input JSON string.
>>=20
>> =20
>>=20
>>     1.a  convert the string into a sequence of unicode code points.
>>=20
>> =20
>>=20
>> How about =93Remove any JSON escaping from the input JSON string and =
convert the string into a sequence of Unicode code points=94?
>>=20
>> =20
>>=20
>> ..and then compare code point-by-code point. This overall algorithm =
/seems/ ok,
>>=20
>> but I'm not sure, it seems there's rationale that's not expressed, eg =
for
>>=20
>> excluding use of Unicode Normalization [USA15]. Also the alg is =
incomplete in
>>=20
>> that it doesn't stipulate converting the "other unicode string" into =
a sequence
>>=20
>> of code points.
>>=20
>> =20
>>=20
>> Fair enough
>>=20
>> =20
>>=20
>> > 10. Security Considerations
>>=20
>> >
>>=20
>> >
>>=20
>> >    All of the security issues faced by any cryptographic =
application
>>=20
>> >    must be faced by a JWT/JWS/JWE/JWK agent.  Among these issues =
are
>>=20
>> >    protecting the user's private key, preventing various attacks, =
and
>>=20
>> >    helping the user avoid mistakes such as inadvertently encrypting =
a
>>=20
>> >    message for the wrong recipient.  The entire list of security
>>=20
>> >    considerations is beyond the scope of this document, but some
>>=20
>> >    significant concerns are listed here.
>>=20
>> >
>>=20
>> >    All the security considerations in the JWS specification also =
apply
>>=20
>> >    to JWT, as do the JWE security considerations when encryption is
>>=20
>> >    employed.  In particular, the JWS JSON Security Considerations =
and
>>=20
>> >    Unicode Comparison Security Considerations apply equally to the =
JWT
>>=20
>> >    Claims Set in the same manner that they do to the JWS Header.
>>=20
>> >
>>=20
>> =20
>>=20
>> dunno if you can get away with sec cons wholly in other docs, and I'm =
not sure
>>=20
>> it's appropriate given that JWTs are a profile of JWE or JWS.
>>=20
>> =20
>>=20
>> That was the approach that Sean had suggested.  If there other things =
you think we should specifically add, however, please let me know.
>>=20
>> =20
>>=20
>> above needs editorial polish -- there aren't any  "significant =
concerns"
>>=20
>> actually listed here.
>>=20
>> =20
>>=20
>> True enough
>>=20
>> =20
>>=20
>> ---
>>=20
>> end
>>=20
>> =20
>>=20
>> =20
>>=20
>> _______________________________________________
>>=20
>> OAuth mailing list
>>=20
>> OAuth@ietf.org
>>=20
>> 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
>>=20
>> --=20
>> Nat Sakimura (=3Dnat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>> _______________________________________________
>> 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=_BBE17345-BB2E-4EC8-856F-EF2EAC8CB713
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

HMAC =
is not technically considered signing, it is integrity protection. =
 (There is a more or less endless debate around =
this.)

The best practice is to sign asymmetrically =
for non repudiation using an asymmetric key, then encrypt with an AEAD =
algorithm to guarantee integrity.

JWE only =
supports encryption with integrity. (equivalent to encrypt + =
HMAC) 

If you want to use symmetric keys =
for encryption with JWE you always get the equivalent of encrypt + =
HMAC.

That is why an additional HMAC (Some call =
signature) step is not required.   So JWE on its own is sufficient =
for encryption plus integrity.  

Signing =
on its own is always better inside the Encryption that way it can =
persist as evidence after the token is =
decrypted.

That is not to say that there are =
not use cases for Encrypt then asymmetrically sign, however most of them =
are covered by JWE using AEAD only.

John =
B.

On 2012-12-29, at 7:34 AM, Antonio Sanso =
<asanso@adobe.com> =
wrote:

Hi =
Nat,

apologies if this sounds trivial but I am trying =
to understand the JW* stuff and this mail thread is helping me to =
clarify some of my doubts.


On Dec =
20, 2012, at 7:12 AM, Nat Sakimura wrote:

Thanks. 

Just a few =
things: 

1. =
Sign+Encrypt

kind of nitpicking =
here, but would not be better to invert those terms in order to sound =
Encrypt+Sign (as long as I know the order matters here and the only safe =
way is encrypt than  MAC).


Sign+Encrypt is useful when you want =
the signed JWT as a proof of consent to sign. 
It can =
also exist after being decrypted. 


If you just want integrity protection, use =
JWE. 

For integrity should =
not be enough the signature so JWS?

Thanks a =
lot and regards

Antonio


2. Alphabetization of the =
terminology

That's one way of organizing =
it. 
Another way of organizing it is to lay them out in a =
semantic order, 


where the preceding definition cannot use the terms defined =
later. 
It is a good way to make sure the consistency, =
and I probably like this way better. 

Of =
the definition themselves, I agree it still lacks bunch of terms that =
needs to be defined, 


and needs tightening =
up. 

Best, 

Na=
t


On Thu, Dec =
20, 2012 at 9:14 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:











Thanks a bunch for the useful review, Jeff!  Responses are =
inline
in =
green.
 
  &=
nbsp;           &nb=
sp;            =
;            &=
nbsp;           &nb=
sp;            -- =
Mike
 
-----Original =
Message-----

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

Sent: Tuesday, November 27, 2012 2:23 PM

To: IETF oauth WG

Subject: [OAUTH-WG] review: =
draft-ietf-oauth-json-web-token-05
 
Hi, =
at ietf-85 atlanta I agreed to do a review of =
draft-ietf-oauth-json-web-token-05, and so I have some thoughts below. =
Also, +1 to Hannes' =
comments.
 
Overall the =
spec seems to get its idea across, but is pretty rough. Part of this is =
due to the language being convoluted, plus some concepts are only =
tacitly described (with clues scattered throughout the spec), and thus =
it is difficult
 to understand without multiple passes of this spec as well as [JWE] and =
[JWS].
 
For example, a JWT =
appears to be simply either a JWS or a JWE containing a JWT Claims Set, =
but this is not stated until right before section 3.1 (and it isn't =
stated that clearly).
 


OK, I=92ll say that earlier and =
more clearly.
 
Immediately =
below are some overall comments, and then below that some detailed =
comments on various portions of the spec.  I'm not addressing =
everything I noticed due to time constraints =
(apologies).
 
HTH<=
/u>
 
=3DJeffH
------
 
 
J=
WT terminology:
 
Some =
issues seem to me to be caused by defining the JWT to be the base64url =
encoded JSON  object itself and not having terminology to clearly =
refer to its unencoded =
form.
 
For example, these =
two JSON objects together apparently comprise a (unencoded) =
JWT..
 
   &nb=
sp;  =
{"typ":"JWT",
       =
"alg":"HS256"}
 


This is the JWT Header.  The =
base64url encoded version is the Encoded JWT =
Header.
 
     =
; {"iss":"joe",
       =
"exp":1300819380,
      =
 "http://example.com/is_root=
":true}
 


This is the JWT Claims =
Set.
 
..but there's no defined =
way to refer to them given the spec's =
terminlogy.
 


The terms above are already =
defined in the spec.
 
Consider terming the above =
a JWT and its encoded-string form an Encoded JWT, and define them =
separately. And then there'll be similar definitions for JWT Header and =
JWT Claims Set, e.g.,
 


I disagree with redefining the =
term =93JWT=94 to not also include the signature.  The term =93JWT=94=
 should continue to refer to the whole =
thing.
 
    Encoded =
JWT   A JWT that has been encoded according to =
the
       process =
defined in Section =
X.
 
    =
Encoded JWT Header   The encoded-string form of a JWT =
Header
 
    =
Encoded JWT Claims Set   The encoded-string form of a JWT =
Claims Set
 


I=92ll note that when the JWT is =
encrypted, a base64url encoded representation of the JWT Claims Set is =
never used.  (The encrypted form of them is base64url encoded =
instead.)


 
    =
encoded-string form   The result of applying Base64url =
encoding to an
       =
input JSON text .
 


Sometimes he input to the =
base64url encoding is not JSON =96 for instance signature values or =
encrypted payloads.
 
    JSON Web =
Token (JWT)  A JWT comprises a JWT Header and a JWT Claims Set. =
...
 
    =
JWT Header  A JSON object that is a component of a JWT. It denotes =
the
       =
cryptographic operations applied to the JWT.  =
...
 
    =
JWT Claims Set  A JSON object containing a set of claims.  =
...
 
This also gets rid of =
the use of the "A string representing a JSON object..."

which I find confusing and potentially misleading =
(because it is actually "a Base64url encoding of a JSON =
object").
 


Aah =96 I now see that this is =
the real misunderstanding.  The =93string representing a JSON =
object=94 is not the base64url encoded form =96 it=92s the string =
representation that=92s parseable into a JSON object.  For
 instance, it could be a string such as {=93alg=94:=94RS256=94} =96 not =
the base64url encoded version of that string.  The reason for the =
syntactic construction =93string representing a JSON object=94 is that =
its string representation is distinct from the abstract JSON object
 itself.  If I insert whitespace after the colon in the string =
{=93alg=94:=94RS256=94} it would parse to an equivalent JSON object but =
it would be a different string representation.  It=92s the string =
representation that is actually operated on by the JWT/JWS/JWE =
operations.
 
I=92ll try to make this clearer in the =
spec.
 
UTF-8:
<=
/u> 
UTF-8 is mentioned in lots of places. It could =
probably be stated once up near

the beginning of the spec that all the JSON text is =
UTF-8 encoded, and all the

JSON strings are UTF-8 =
encoded.
 


I=92ll see if I can figure out =
how to do this without introducing =
ambiguity.
 
Semantics, profiles and =
relationship to SAML:
 
The =
spec does not define any overall JWT semantics (i.e., what any given JWT

/means/). Semantics are only defined in context of =
each individual Reserved

Claim =
Name.
 
Thus any =
application of JWTs will need to profile the JWT spec: specifying the

claim set(s) contents, and the overall semantics of =
the resultant JWT(s).  This

is not explicitly explained in the JWT =
spec.
 


Can you suggest some language =
you=92d like to see added about this?
 
In terms of SAML, Appendix =
B should refer to SAML assertions rather than saml

tokens. Also, I'm not sure SAML assertions =
inherently have more expressivity

than JWTs. They do have more pre-defined structure =
and semantics.
 


OK
 
Syntactically, it seems one =
can encode pretty much anything in whatever amount

in a JWT (one can do the same with SAML =
assertions), and thus theoretically JWTs

could be used to accomplish the same things as SAML =
assertions.
 
Semantically, =
SAML assertions are explicitly statements made by a system entity

about a subject. But by default, a JWT is empty, =
and has no semantics (this

isn't stated explicitly). All semantics defined in =
the JWT spec are particular

to individual reserved claims, but all reserved =
claims are optional. Thus an

application of JWTs to use cases also apropos for =
SAML assertions will require

arguably more profiling than that needed to apply =
SAML assertions.
 


All true.  However once you =
add an issuer and a principal, then you=92re back to the JWT being =
statements made by an entity about a subject.  Again, if there is =
language you believe should be added in that regard,
 please let me know.  (BTW, one such usage profile is in 
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.  =
Another is in 
=
http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)=

 
The token size & =
complexity comparison seems nominally =
fine.
 
Some =
detailed-but-rough comments and musings on portions of the spec as I was

reading through =
it...
 
> 2. =
Terminology
 
terminology =
is not alphabetised!
 


No, it=92s in a top-down =
descriptive order.  Is there a requirement in IETF specs that the =
terminology be alphabetized?
 
"claim", "claims", "token" =
should be defined in =
terminology
 


I=92ll add a definition for =
=93claim=94.  =93token=94 should actually probably become =93security=
 token=94, with a definition of the term.
 
suggestion:
=

 
      =
Claim:  an assertion of something as a fact. Here, claims =
are
         =
name and value pairs, consisting of a Claim Name and =
a
         =
Claim =
Value.
 
 =

>    JSON Web Token =
(JWT)
 
   is jwt =
always a "string" or is it string (only) when it's been serialized

into =
one?
 


It=92s always the string =
representation of the serialized parts.
 
>    &=
nbsp;           &nb=
sp;   A string representing a set of claims as a =
JSON
>       object =
that is digitally signed or MACed and/or =
encrypted.
 
   =
is it more that it's a set of claims encoded as a JSON =
object
   that is =
string-serialized?
 


No, per my earlier comments =


 
   is it /not/ a =
JWT by definition if it is not ((signed or unmac'd) and/or

encrypted) ?   No, because there are =
Plaintext JWTs, but they aren't in

terminology (probably should =
be).
 


Good =
catch
 
   "parts" in JWT =
definition is unclear
     are =
"parts" json objects or arrays unto themselves =
?
 


The parts are all base64url =
encoded values.  I=92ll review this terminology usage to see if it =
can be clarified.
 
   the definition =
assumes knowledge that's presented later. perhaps needs =
fwd
   reference(s), or perhaps better is =
to not present as much technical detail
   =
in the definitions.
 


I=92ll =
review
 
>    JWT =
Claims Set
 
   =
similar comments as to JSON Web Token =
(JWT)
 
   the =
definition says how it is encoded and encrypted, but not how claims are

mapped into a JSON =
object
 
 =

should probably be =
simply:
 
    =
JWT Claims Set: A set of claims expressed as a JSON object, where =
each
       claim is =
an object member (i.e., a name/value pair). A claim may =
have
       a JWT =
Claims Set as a value.
 


I=92ll look into moving the =
definition in this direction.  What you=92re missing in the above, =
though, is the distinction between the string representing the JSON =
object and the abstract JSON object.  We want
 the former.
 
>    Claim =
Name  The name of a member of the JSON object representing =
a
>       JWT =
Claims Set.
 
should =
probably be =
simply:
 
    =
Claim Name  The name portion of a claim, expressed as a JSON object =
member
       =
name.
 
 <=
/p>
>    Claim Value  The value of a member of =
the JSON object representing =
a
>       JWT =
Claims Set.
 
should =
probably be =
simply:
 
    =
Claim Value  The value portion of a claim, expressed as a JSON =
object member
       =
value.
 


I=92ll look into moving the =
definitions in this direction. 

 
> 3. JSON Web Token (JWT) =
Overview
 
>  &n=
bsp; The bytes of the UTF-8 representation of the JWT Claims Set =
are
>    digitally signed or MACed =
in the manner described in JSON =
Web
>    Signature (JWS) [JWS] =
and/or encrypted in the manner described =
in
>    JSON Web Encryption (JWE) =
[JWE].
 
s/ and/or =
encrypted / or encrypted and signed =
/
 


I think you mean =93encrypted and =
integrity protected=94 rather than =93encrypted and signed=94, =
right?
 
>    The =
contents of the JWT Header describe the cryptographic =
operations
>    applied to the JWT =
Claims Set. If the JWT Header is a JWS Header, =
the
>    claims are digitally =
signed or MACed.  If the JWT Header is a =
JWE
>    Header, the claims are =
encrypted.
 
What if a JWT =
is signed AND encrypted?  Hm, from my looking at JWS and JWE

specs, it seems that in that case one uses JWE =
because that encompasses both

encrypt & =
sign.
 


No, actually JWE just provides an =
integrity check =96 not a signature.  If you want a signature, you =
need to use JWS.  They can (and often are) used in a nested =
fashion.


 
>    A =
JWT is represented as a JWS or JWE.  The number of parts =
is
>    dependent upon the =
representation of the resulting JWS or =
JWE.
 
Does the above mean =
to =
say..
 
    =
A JWT consists of a JWS or JWE object, which in turn conveys the =
JWT
    Claims Set. In the case of a =
JWS, the JWT Claims Set is the =
JWS
    Payload. In the case of a =
JWE, the JWT Claims Set is the =
input
    =
Plaintext.
 


Yes.  Although this is =
missing the fact that nested signing/encryption may be =
employed.
 
> 4. JWT =
Claims
>
>
=

>    The JWT Claims Set represents a JSON object =
whose members are the
>    claims =
conveyed by the JWT.  The Claim Names within this object =
MUST
>    be unique; JWTs with =
duplicate Claim Names MUST be =
rejected.
 
does the above =
mean to say claim names must be unique amongst the set of claim

names within any given JWT Claims Set ?  If =
so, that's only implied by the above

but should be stated explicitly; as it is, the =
above is ambiguous.
 


OK
 
> 4.2. Public Claim =
Names
>
>
<=
p>>    Claim names can be defined at will by those =
using JWTs.  However, =
in
 
s/Claim names/Public =
claim =
names/
 
>  &nbs=
p; order to prevent collisions, any new claim name SHOULD either =
be
>    registered in the IANA =
JSON Web Token Claims registry Section 9.1 =
or
>    be a URI that contains a =
Collision Resistant =
Namespace.
 
 =

why should a claim name be a URI if I wish to make use of =
Collision Resistant

Namespaces?  For example, if I simply use say =
UUIDs as claim =
names..
 
   &=
nbsp;  =
{"iss":"joe",
       =
"3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}
&=
nbsp;
..it will be universally unique provided I minted it =
appropriately (no URI

syntax is =
needed).
 


Fair enough.  I=92ll try to =
generalize the language.
 
> 4.3. =
Private Claim =
Names
>
>
<=
p>>    A producer and consumer of a JWT may agree to =
any claim name that is
>    not a =
Reserved Name Section 4.1 or a Public Name Section 4.2.  =
Unlike
>    Public Names, these =
private names are subject to collision and =
should
>    be used with =
caution.
 
it seems private =
claim names are only subject to collision if the implementers

don't make appropriate use of Collision Resistant =
Namespaces, i.e. they "can be"

subject to =
collision.
 


True
 
the above two sections use =
"public" and "private" as distinguishing factors, but

it seems to me the distinguishing factor (given how =
the above is written) is

more whether Collision Resistant Namespaces are =
employed or not.
 


Yes, although using a collision =
resistant namespace effectively makes them public, as we=92re using the =
term
 
An implied aspect of public =
claim names seems to be that it is assumed that they

are publicly listed/documented/leaked, thus the =
"public" moniker, and hence

ought to be universally unique as a matter of =
course.
 
and "private" =
ones seem to be assumed to be obfuscated to all but the agreeing

parties?  Or they are "private" in only the =
sense that they are created in the

context of a private =
arrangement?
 


Private in that they are created =
in the context of a private arrangement.  I=92ll try to clarify =
this point.  Facebook could define how they=92re going to use the =
=93id=94 claim very publicly, and yet it would still
 be a private claim if not registered with =
IANA.
 
>
> =
7. Rules for Creating and Validating a =
JWT
>
>
=
>    To create a JWT, one MUST perform these =
steps.  The order of the
>    =
steps is not significant in cases where there are no =
dependencies
>    between the =
inputs and outputs of the =
steps.
>
>   =
 1.  Create a JWT Claims Set containing the desired claims.  =
Note =
that
>        =
white space is explicitly allowed in the representation and =
no
>        =
canonicalization is performed before =
encoding.
 
I presume the =
rationale for allowing white space is that JSON objects are

unordered (and can contain arbitrary whitespace), =
thus simple buffer-to-buffer

comparisons between serialized objects cannot be =
reliably performed.  If so this

should be explicitly =
stated.
 


Actually, it=92s to avoid =
canonicalization.  I=92ll reread the spec to see if we=92ve stated =
that clearly or not.
 
It seems that =
member/value-by-member/value comparisons must always be done, by

parsing the JSON objects and extracting all members =
and values, this should be

stated explicitly in the =
spec.
 
I found meager jwt =
comparison instructions at the very end of Section 7. it

should probably be its own subsection. It should =
probably explicitly say that

JWTs need to be parsed into their constituent =
components, and the latter must be

individually =
examined/compared.
 


We tried to cover this in the end =
of section 7, starting with the sentence =93Processing a JWT inevitably =
requires comparing known strings to values in the token=94, which says =
how these comparisons must be performed. 
 I agree that this should become its own subsection.  I don=92t =
understand your remark about constituent components.  Can you =
clarify?
 
>    =
Comparisons between JSON strings and other Unicode strings MUST =
be
>    performed as specified =
below:
 
this comparison =
algorithm seems to be attempting to allow for comparison of

UTF-8 encoded JSON strings with other unicode =
strings in any of the unicode

encoding formats, but only implies that; it should =
be stated.
 


Good
 
>
>=
    1.  Remove any JSON applied escaping to produce =
an array of =
Unicode
>       =
 code points.
 
I don't =
think (1) is correct.  A JSON string is by default encoded in =
UTF-8. A

UTF-8 encoded string is not "an array of Unicode =
code points" (its a sequence of

code units, which must be decoded into code =
points), i think a step is missing
=

here..
 
    1.  Remove any JSON escaping from the input =
JSON =
string.
 
    =
1.a  convert the string into a sequence of unicode code =
points.
 


How about =93Remove any JSON =
escaping from the input JSON string and convert the string into a =
sequence of Unicode code points=94?
 
..and =
then compare code point-by-code point. This overall algorithm /seems/ =
ok,

but I'm not sure, it seems there's rationale that's =
not expressed, eg for

excluding use of Unicode Normalization [USA15]. =
Also the alg is incomplete in

that it doesn't stipulate converting the "other =
unicode string" into a sequence

of code =
points.
 


Fair =
enough
 
> 10. Security =
Considerations
>
>=

>    All of the security issues faced by =
any cryptographic application
>    =
must be faced by a JWT/JWS/JWE/JWK agent.  Among these issues =
are
>    protecting the user's =
private key, preventing various attacks, =
and
>    helping the user avoid =
mistakes such as inadvertently encrypting =
a
>    message for the wrong =
recipient.  The entire list of =
security
>    considerations is =
beyond the scope of this document, but =
some
>    significant concerns are =
listed =
here.
>
>    =
All the security considerations in the JWS specification also =
apply
>    to JWT, as do the JWE =
security considerations when encryption =
is
>    employed.  In =
particular, the JWS JSON Security Considerations =
and
>    Unicode Comparison =
Security Considerations apply equally to the =
JWT
>    Claims Set in the same =
manner that they do to the JWS =
Header.
>
 <=
/p>
dunno if you can get away with sec cons wholly in other docs, and =
I'm not sure

it's appropriate given that JWTs are a profile of =
JWE or JWS.
 


That was the approach that Sean =
had suggested.  If there other things you think we should =
specifically add, however, please let me =
know.
 
above needs editorial =
polish -- there aren't any  "significant concerns"

actually listed =
here.
 


True =
enough
 
---
end<=
/u>
 
 
___=
____________________________________________
OAuth =
mailing list
OAuth@ietf.org<=
u>
https://www.ietf.org/mailm=
an/listinfo/oauth







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
Nat =
Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



_______________________________________________
OAuth mailing =
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=_BBE17345-BB2E-4EC8-856F-EF2EAC8CB713--

From bcampbell@pingidentity.com  Sat Dec 29 08:21:37 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D135621F8442 for ; Sat, 29 Dec 2012 08:21:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level: 
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[AWL=0.988,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, TVD_FLOAT_GENERAL=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzncWcosGKTt for ; Sat, 29 Dec 2012 08:21:32 -0800 (PST)
Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2076B21F8440 for ; Sat, 29 Dec 2012 08:21:31 -0800 (PST)
Received: from mail-ia0-f197.google.com ([209.85.210.197]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUN8YiyMKlFSB4gGhaXY+55EWIoOcerf9@postini.com; Sat, 29 Dec 2012 08:21:32 PST
Received: by mail-ia0-f197.google.com with SMTP id x26so33568052iak.8 for ; Sat, 29 Dec 2012 08:21:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=MpgxqldOujYCPJ9MJ1JN9telz6nhEt972PCqn0WOgFA=; b=Qxi53M3fD+MzNVk8JIilm04jSygglX/wzV4LYfBawsNyhRqnrhw2ygOUvDYuGpDFQE mSr8ROKeHyDC8Az/HcPciVmeb+fnk8Mi/MSMeFcq89gZhQ2QzPp7dMCxiP/7qDXBQj+4 q2KbUAauuykfO6A+CrTR3CcGTRYt9nw3QO7xIby6CwP0aJfsERn+CczZ7IJqW1J2NbXo eScbE5L+KV1E6Si+ggC+udgVKrz4nWJm24+7S+f2rKuUXEi19fyLhYWZdMozM4S+NrVw 0coVTk9jVNJ8qaiPxYDaZuLCR4JyzsRtIhrBw0jXsgWretuFKAt8JOGdwgbfQYuwIemo M0xw==
X-Received: by 10.50.1.169 with SMTP id 9mr26733727ign.101.1356798091423; Sat, 29 Dec 2012 08:21:31 -0800 (PST)
Received: by 10.50.1.169 with SMTP id 9mr26733724ign.101.1356798091250; Sat, 29 Dec 2012 08:21:31 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.17.134 with HTTP; Sat, 29 Dec 2012 08:21:01 -0800 (PST)
From: Brian Campbell 
Date: Sat, 29 Dec 2012 09:21:01 -0700
Message-ID: 
To: oauth 
Content-Type: multipart/alternative; boundary=e89a8f50351e42ca1804d2002ca6
X-Gm-Message-State: ALoCoQmjoVslrKjDaZsKpQAEk9u1kEEKvACxR6Q6dCX31vjQjBduK4TrXmjHKYV+c/CLm25Jib4ibJOuqPG4Nxer7iGq5CMEWdrcIjkZiTipM+CZvck4dYuXQzTVtZRAhjkloAJJx970
Subject: [OAUTH-WG] Open Issue in draft-ietf-oauth-json-web-token-06
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 16:21:37 -0000

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

I noticed the open issue quoted below while perusing the diffs of some new
I-Ds today and it reminded me that I'd been meaning to comment on that very
issue.

      "Should all claims continue to be required to be understood by
      implementations using them when used in a security-related context
      or should a means of declaring that specific claims may be safely
      ignored if not understood should be defined?  This is related to
      the similar JOSE issue about whether all header fields must
      continue to be understood."

I've been reluctant to weigh in on the similar JOSE discussion for lack of
confidence about the right answer but I do have a lot of experience working
with identity and security type tokens that may be relevant to the issue in
the JWT context. In my experience many consumers of such tokens will
process the special attributes/claims that it knows about (i.e. aud, iss,
exp, etc.) and pass the remaining values to the application layer as (not
necessarily expected but potently useful) additional claims about the
subject. In fact, I recently wrote a JWT/JWS based OAuth access token
implementation that does exactly that (which a colleague of mine
successfully tested with a MS JWT implementation although I don't know what
claims he used).

Maybe that's not the best approach but I believe it's fairly common and, as
such, that must understand requirement in JWT is likely to be ignored by
many, which can result in a neglected spec requirement and/or potential
interoperability issues.

My 2 cents,
Brian

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


I noticed the open issue quoted below while perusing =
the diffs of some new I-Ds today and it reminded me that I'd been meani=
ng to comment on that very issue.

=A0 =A0 =A0 "Should all claim=
s continue to be required to be understood by


=A0 =A0 =A0 implementations using them when used in a security-related cont=
ext
=A0 =A0 =A0 or should a means of declaring that specific claims may =
be safely
=A0 =A0 =A0 ignored if not understood should be defined? =A0Th=
is is related to


=A0 =A0 =A0 the similar JOSE issue about whether all header fields must
=
=A0 =A0 =A0 continue to be understood."

I've been reluctant=
 to weigh in on the similar JOSE discussion for lack of confidence about th=
e right answer but I do have a lot of experience working with identity and =
security type tokens that may be relevant to the issue in the JWT context. =
In my experience many consumers of such tokens will process the special att=
ributes/claims that it knows about (i.e. aud, iss, exp, etc.) and pass the =
remaining values to the application layer as (not necessarily expected but =
potently useful) additional claims about the subject. In fact, I recently w=
rote a JWT/JWS based OAuth access token implementation that does exactly th=
at (which a colleague of mine successfully tested with a MS JWT implementat=
ion although I don't know what claims he used).



Maybe that's not the best approach but I believe it's fairly co=
mmon and, as such, that must understand requirement in JWT is likely to be =
ignored by many, which can result in a neglected spec requirement and/or potential interoperability iss=
ues.



My 2 cents,
Brian









--e89a8f50351e42ca1804d2002ca6--

From asanso@adobe.com  Sat Dec 29 08:39:22 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ACB21F86A5 for ; Sat, 29 Dec 2012 08:39:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.943
X-Spam-Level: 
X-Spam-Status: No, score=-99.943 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFd6Y7Oqfv0V for ; Sat, 29 Dec 2012 08:39:17 -0800 (PST)
Received: from exprod6og118.obsmtp.com (exprod6og118.obsmtp.com [64.18.1.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC3C21F86A3 for ; Sat, 29 Dec 2012 08:39:14 -0800 (PST)
Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob118.postini.com ([64.18.5.12]) with SMTP ID DSNKUN8csq07Pwqirxllm2tYa2cJtNvITsOv@postini.com; Sat, 29 Dec 2012 08:39:17 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qBTGaF1v019647; Sat, 29 Dec 2012 08:36:16 -0800 (PST)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qBTGdAXL011515; Sat, 29 Dec 2012 08:39:10 -0800 (PST)
Received: from eurcas01.eur.adobe.com (10.128.4.27) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sat, 29 Dec 2012 08:39:09 -0800
Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurcas01.eur.adobe.com ([10.128.4.27]) with mapi; Sat, 29 Dec 2012 16:39:07 +0000
From: Antonio Sanso 
To: John Bradley 
Date: Sat, 29 Dec 2012 16:38:57 +0000
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3l4wU+pszGoFClT7mv2lNo8P2Q9w==
Message-ID: <6D0B1100-D955-4DA3-8327-77A72FE4BD7F@adobe.com>
References: <50B53D3E.1000107@KingsMountain.com> <4E1F6AAD24975D4BA5B168042967394366979DAD@TK5EX14MBXC283.redmond.corp.microsoft.com>  <7816700B-65D6-4C91-8D62-A2EED02442F7@adobe.com> <4E48A647-8507-4648-8FE0-D6BB2447274A@ve7jtb.com>
In-Reply-To: <4E48A647-8507-4648-8FE0-D6BB2447274A@ve7jtb.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_6D0B1100D9554DA3832777A72FE4BD7Fadobecom_"
MIME-Version: 1.0
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 16:39:22 -0000

--_000_6D0B1100D9554DA3832777A72FE4BD7Fadobecom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks a lot John for the explanations,

so which one is the use case for JWE and which for JWS in terms of integrit=
y and encryption?
Is it the same to use one or the other?

Regards

Antonio


On Dec 29, 2012, at 4:43 PM, John Bradley wrote:

HMAC is not technically considered signing, it is integrity protection.  (T=
here is a more or less endless debate around this.)

The best practice is to sign asymmetrically for non repudiation using an as=
ymmetric key, then encrypt with an AEAD algorithm to guarantee integrity.

JWE only supports encryption with integrity. (equivalent to encrypt + HMAC)

If you want to use symmetric keys for encryption with JWE you always get th=
e equivalent of encrypt + HMAC.

That is why an additional HMAC (Some call signature) step is not required. =
  So JWE on its own is sufficient for encryption plus integrity.

Signing on its own is always better inside the Encryption that way it can p=
ersist as evidence after the token is decrypted.

That is not to say that there are not use cases for Encrypt then asymmetric=
ally sign, however most of them are covered by JWE using AEAD only.

John B.

On 2012-12-29, at 7:34 AM, Antonio Sanso > wrote:

Hi Nat,

apologies if this sounds trivial but I am trying to understand the JW* stuf=
f and this mail thread is helping me to clarify some of my doubts.


On Dec 20, 2012, at 7:12 AM, Nat Sakimura wrote:

Thanks.

Just a few things:

1. Sign+Encrypt

kind of nitpicking here, but would not be better to invert those terms in o=
rder to sound Encrypt+Sign (as long as I know the order matters here and th=
e only safe way is encrypt than  MAC).


Sign+Encrypt is useful when you want the signed JWT as a proof of consent t=
o sign.
It can also exist after being decrypted.
If you just want integrity protection, use JWE.

For integrity should not be enough the signature so JWS?

Thanks a lot and regards

Antonio


2. Alphabetization of the terminology

That's one way of organizing it.
Another way of organizing it is to lay them out in a semantic order,
where the preceding definition cannot use the terms defined later.
It is a good way to make sure the consistency, and I probably like this way=
 better.

Of the definition themselves, I agree it still lacks bunch of terms that ne=
eds to be defined,
and needs tightening up.

Best,

Nat


On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones > wrote:

Thanks a bunch for the useful review, Jeff!  Responses are inline in green.



                                                                -- Mike



-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-b=
ounces@ietf.org] On Behalf Of =3DJeffH
Sent: Tuesday, November 27, 2012 2:23 PM
To: IETF oauth WG
Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05



Hi, at ietf-85 atlanta I agreed to do a review of draft-ietf-oauth-json-web=
-token-05, and so I have some thoughts below. Also, +1 to Hannes' comments.



Overall the spec seems to get its idea across, but is pretty rough. Part of=
 this is due to the language being convoluted, plus some concepts are only =
tacitly described (with clues scattered throughout the spec), and thus it i=
s difficult to understand without multiple passes of this spec as well as [=
JWE] and [JWS].



For example, a JWT appears to be simply either a JWS or a JWE containing a =
JWT Claims Set, but this is not stated until right before section 3.1 (and =
it isn't stated that clearly).



OK, I=92ll say that earlier and more clearly.



Immediately below are some overall comments, and then below that some detai=
led comments on various portions of the spec.  I'm not addressing everythin=
g I noticed due to time constraints (apologies).



HTH



=3DJeffH

------





JWT terminology:



Some issues seem to me to be caused by defining the JWT to be the base64url=
 encoded JSON  object itself and not having terminology to clearly refer to=
 its unencoded form.



For example, these two JSON objects together apparently comprise a (unencod=
ed) JWT..



      {"typ":"JWT",

       "alg":"HS256"}



This is the JWT Header.  The base64url encoded version is the Encoded JWT H=
eader.



      {"iss":"joe",

       "exp":1300819380,

       "http://example.com/is_root":true}



This is the JWT Claims Set.



..but there's no defined way to refer to them given the spec's terminlogy.



The terms above are already defined in the spec.



Consider terming the above a JWT and its encoded-string form an Encoded JWT=
, and define them separately. And then there'll be similar definitions for =
JWT Header and JWT Claims Set, e.g.,



I disagree with redefining the term =93JWT=94 to not also include the signa=
ture.  The term =93JWT=94 should continue to refer to the whole thing.



    Encoded JWT   A JWT that has been encoded according to the

       process defined in Section X.



    Encoded JWT Header   The encoded-string form of a JWT Header



    Encoded JWT Claims Set   The encoded-string form of a JWT Claims Set



I=92ll note that when the JWT is encrypted, a base64url encoded representat=
ion of the JWT Claims Set is never used.  (The encrypted form of them is ba=
se64url encoded instead.)



    encoded-string form   The result of applying Base64url encoding to an

       input JSON text .



Sometimes he input to the base64url encoding is not JSON =96 for instance s=
ignature values or encrypted payloads.



    JSON Web Token (JWT)  A JWT comprises a JWT Header and a JWT Claims Set=
. ...



    JWT Header  A JSON object that is a component of a JWT. It denotes the

       cryptographic operations applied to the JWT.  ...



    JWT Claims Set  A JSON object containing a set of claims.  ...



This also gets rid of the use of the "A string representing a JSON object..=
."

which I find confusing and potentially misleading (because it is actually "=
a Base64url encoding of a JSON object").



Aah =96 I now see that this is the real misunderstanding.  The =93string re=
presenting a JSON object=94 is not the base64url encoded form =96 it=92s th=
e string representation that=92s parseable into a JSON object.  For instanc=
e, it could be a string such as {=93alg=94:=94RS256=94} =96 not the base64u=
rl encoded version of that string.  The reason for the syntactic constructi=
on =93string representing a JSON object=94 is that its string representatio=
n is distinct from the abstract JSON object itself.  If I insert whitespace=
 after the colon in the string {=93alg=94:=94RS256=94} it would parse to an=
 equivalent JSON object but it would be a different string representation. =
 It=92s the string representation that is actually operated on by the JWT/J=
WS/JWE operations.



I=92ll try to make this clearer in the spec.



UTF-8:



UTF-8 is mentioned in lots of places. It could probably be stated once up n=
ear

the beginning of the spec that all the JSON text is UTF-8 encoded, and all =
the

JSON strings are UTF-8 encoded.



I=92ll see if I can figure out how to do this without introducing ambiguity=
.



Semantics, profiles and relationship to SAML:



The spec does not define any overall JWT semantics (i.e., what any given JW=
T

/means/). Semantics are only defined in context of each individual Reserved

Claim Name.



Thus any application of JWTs will need to profile the JWT spec: specifying =
the

claim set(s) contents, and the overall semantics of the resultant JWT(s).  =
This

is not explicitly explained in the JWT spec.



Can you suggest some language you=92d like to see added about this?



In terms of SAML, Appendix B should refer to SAML assertions rather than sa=
ml

tokens. Also, I'm not sure SAML assertions inherently have more expressivit=
y

than JWTs. They do have more pre-defined structure and semantics.



OK



Syntactically, it seems one can encode pretty much anything in whatever amo=
unt

in a JWT (one can do the same with SAML assertions), and thus theoretically=
 JWTs

could be used to accomplish the same things as SAML assertions.



Semantically, SAML assertions are explicitly statements made by a system en=
tity

about a subject. But by default, a JWT is empty, and has no semantics (this

isn't stated explicitly). All semantics defined in the JWT spec are particu=
lar

to individual reserved claims, but all reserved claims are optional. Thus a=
n

application of JWTs to use cases also apropos for SAML assertions will requ=
ire

arguably more profiling than that needed to apply SAML assertions.



All true.  However once you add an issuer and a principal, then you=92re ba=
ck to the JWT being statements made by an entity about a subject.  Again, i=
f there is language you believe should be added in that regard, please let =
me know.  (BTW, one such usage profile is in http://tools.ietf.org/html/dra=
ft-ietf-oauth-jwt-bearer-03.  Another is in http://openid.net/specs/openid-=
connect-messages-1_0.html#id_token.)



The token size & complexity comparison seems nominally fine.



Some detailed-but-rough comments and musings on portions of the spec as I w=
as

reading through it...



> 2. Terminology



terminology is not alphabetised!



No, it=92s in a top-down descriptive order.  Is there a requirement in IETF=
 specs that the terminology be alphabetized?



"claim", "claims", "token" should be defined in terminology



I=92ll add a definition for =93claim=94.  =93token=94 should actually proba=
bly become =93security token=94, with a definition of the term.



suggestion:



      Claim:  an assertion of something as a fact. Here, claims are

         name and value pairs, consisting of a Claim Name and a

         Claim Value.





>    JSON Web Token (JWT)



   is jwt always a "string" or is it string (only) when it's been serialize=
d

into one?



It=92s always the string representation of the serialized parts.



>                    A string representing a set of claims as a JSON

>       object that is digitally signed or MACed and/or encrypted.



   is it more that it's a set of claims encoded as a JSON object

   that is string-serialized?



No, per my earlier comments



   is it /not/ a JWT by definition if it is not ((signed or unmac'd) and/or

encrypted) ?   No, because there are Plaintext JWTs, but they aren't in

terminology (probably should be).



Good catch



   "parts" in JWT definition is unclear

     are "parts" json objects or arrays unto themselves ?



The parts are all base64url encoded values.  I=92ll review this terminology=
 usage to see if it can be clarified.



   the definition assumes knowledge that's presented later. perhaps needs f=
wd

   reference(s), or perhaps better is to not present as much technical deta=
il

   in the definitions.



I=92ll review



>    JWT Claims Set



   similar comments as to JSON Web Token (JWT)



   the definition says how it is encoded and encrypted, but not how claims =
are

mapped into a JSON object





should probably be simply:



    JWT Claims Set: A set of claims expressed as a JSON object, where each

       claim is an object member (i.e., a name/value pair). A claim may hav=
e

       a JWT Claims Set as a value.



I=92ll look into moving the definition in this direction.  What you=92re mi=
ssing in the above, though, is the distinction between the string represent=
ing the JSON object and the abstract JSON object.  We want the former.



>    Claim Name  The name of a member of the JSON object representing a

>       JWT Claims Set.



should probably be simply:



    Claim Name  The name portion of a claim, expressed as a JSON object mem=
ber

       name.





>    Claim Value  The value of a member of the JSON object representing a

>       JWT Claims Set.



should probably be simply:



    Claim Value  The value portion of a claim, expressed as a JSON object m=
ember

       value.



I=92ll look into moving the definitions in this direction.



> 3. JSON Web Token (JWT) Overview



>    The bytes of the UTF-8 representation of the JWT Claims Set are

>    digitally signed or MACed in the manner described in JSON Web

>    Signature (JWS) [JWS] and/or encrypted in the manner described in

>    JSON Web Encryption (JWE) [JWE].



s/ and/or encrypted / or encrypted and signed /



I think you mean =93encrypted and integrity protected=94 rather than =93enc=
rypted and signed=94, right?



>    The contents of the JWT Header describe the cryptographic operations

>    applied to the JWT Claims Set. If the JWT Header is a JWS Header, the

>    claims are digitally signed or MACed.  If the JWT Header is a JWE

>    Header, the claims are encrypted.



What if a JWT is signed AND encrypted?  Hm, from my looking at JWS and JWE

specs, it seems that in that case one uses JWE because that encompasses bot=
h

encrypt & sign.



No, actually JWE just provides an integrity check =96 not a signature.  If =
you want a signature, you need to use JWS.  They can (and often are) used i=
n a nested fashion.



>    A JWT is represented as a JWS or JWE.  The number of parts is

>    dependent upon the representation of the resulting JWS or JWE.



Does the above mean to say..



    A JWT consists of a JWS or JWE object, which in turn conveys the JWT

    Claims Set. In the case of a JWS, the JWT Claims Set is the JWS

    Payload. In the case of a JWE, the JWT Claims Set is the input

    Plaintext.



Yes.  Although this is missing the fact that nested signing/encryption may =
be employed.



> 4. JWT Claims

>

>

>    The JWT Claims Set represents a JSON object whose members are the

>    claims conveyed by the JWT.  The Claim Names within this object MUST

>    be unique; JWTs with duplicate Claim Names MUST be rejected.



does the above mean to say claim names must be unique amongst the set of cl=
aim

names within any given JWT Claims Set ?  If so, that's only implied by the =
above

but should be stated explicitly; as it is, the above is ambiguous.



OK



> 4.2. Public Claim Names

>

>

>    Claim names can be defined at will by those using JWTs.  However, in



s/Claim names/Public claim names/



>    order to prevent collisions, any new claim name SHOULD either be

>    registered in the IANA JSON Web Token Claims registry Section 9.1 or

>    be a URI that contains a Collision Resistant Namespace.





why should a claim name be a URI if I wish to make use of Collision Resista=
nt

Namespaces?  For example, if I simply use say UUIDs as claim names..



      {"iss":"joe",

       "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}



..it will be universally unique provided I minted it appropriately (no URI

syntax is needed).



Fair enough.  I=92ll try to generalize the language.



> 4.3. Private Claim Names

>

>

>    A producer and consumer of a JWT may agree to any claim name that is

>    not a Reserved Name Section 4.1 or a Public Name Section 4.2.  Unlike

>    Public Names, these private names are subject to collision and should

>    be used with caution.



it seems private claim names are only subject to collision if the implement=
ers

don't make appropriate use of Collision Resistant Namespaces, i.e. they "ca=
n be"

subject to collision.



True



the above two sections use "public" and "private" as distinguishing factors=
, but

it seems to me the distinguishing factor (given how the above is written) i=
s

more whether Collision Resistant Namespaces are employed or not.



Yes, although using a collision resistant namespace effectively makes them =
public, as we=92re using the term



An implied aspect of public claim names seems to be that it is assumed that=
 they

are publicly listed/documented/leaked, thus the "public" moniker, and hence

ought to be universally unique as a matter of course.



and "private" ones seem to be assumed to be obfuscated to all but the agree=
ing

parties?  Or they are "private" in only the sense that they are created in =
the

context of a private arrangement?



Private in that they are created in the context of a private arrangement.  =
I=92ll try to clarify this point.  Facebook could define how they=92re goin=
g to use the =93id=94 claim very publicly, and yet it would still be a priv=
ate claim if not registered with IANA.



>

> 7. Rules for Creating and Validating a JWT

>

>

>    To create a JWT, one MUST perform these steps.  The order of the

>    steps is not significant in cases where there are no dependencies

>    between the inputs and outputs of the steps.

>

>    1.  Create a JWT Claims Set containing the desired claims.  Note that

>        white space is explicitly allowed in the representation and no

>        canonicalization is performed before encoding.



I presume the rationale for allowing white space is that JSON objects are

unordered (and can contain arbitrary whitespace), thus simple buffer-to-buf=
fer

comparisons between serialized objects cannot be reliably performed.  If so=
 this

should be explicitly stated.



Actually, it=92s to avoid canonicalization.  I=92ll reread the spec to see =
if we=92ve stated that clearly or not.



It seems that member/value-by-member/value comparisons must always be done,=
 by

parsing the JSON objects and extracting all members and values, this should=
 be

stated explicitly in the spec.



I found meager jwt comparison instructions at the very end of Section 7. it

should probably be its own subsection. It should probably explicitly say th=
at

JWTs need to be parsed into their constituent components, and the latter mu=
st be

individually examined/compared.



We tried to cover this in the end of section 7, starting with the sentence =
=93Processing a JWT inevitably requires comparing known strings to values i=
n the token=94, which says how these comparisons must be performed.  I agre=
e that this should become its own subsection.  I don=92t understand your re=
mark about constituent components.  Can you clarify?



>    Comparisons between JSON strings and other Unicode strings MUST be

>    performed as specified below:



this comparison algorithm seems to be attempting to allow for comparison of

UTF-8 encoded JSON strings with other unicode strings in any of the unicode

encoding formats, but only implies that; it should be stated.



Good



>

>    1.  Remove any JSON applied escaping to produce an array of Unicode

>        code points.



I don't think (1) is correct.  A JSON string is by default encoded in UTF-8=
. A

UTF-8 encoded string is not "an array of Unicode code points" (its a sequen=
ce of

code units, which must be decoded into code points), i think a step is miss=
ing

here..



    1.  Remove any JSON escaping from the input JSON string.



    1.a  convert the string into a sequence of unicode code points.



How about =93Remove any JSON escaping from the input JSON string and conver=
t the string into a sequence of Unicode code points=94?



..and then compare code point-by-code point. This overall algorithm /seems/=
 ok,

but I'm not sure, it seems there's rationale that's not expressed, eg for

excluding use of Unicode Normalization [USA15]. Also the alg is incomplete =
in

that it doesn't stipulate converting the "other unicode string" into a sequ=
ence

of code points.



Fair enough



> 10. Security Considerations

>

>

>    All of the security issues faced by any cryptographic application

>    must be faced by a JWT/JWS/JWE/JWK agent.  Among these issues are

>    protecting the user's private key, preventing various attacks, and

>    helping the user avoid mistakes such as inadvertently encrypting a

>    message for the wrong recipient.  The entire list of security

>    considerations is beyond the scope of this document, but some

>    significant concerns are listed here.

>

>    All the security considerations in the JWS specification also apply

>    to JWT, as do the JWE security considerations when encryption is

>    employed.  In particular, the JWS JSON Security Considerations and

>    Unicode Comparison Security Considerations apply equally to the JWT

>    Claims Set in the same manner that they do to the JWS Header.

>



dunno if you can get away with sec cons wholly in other docs, and I'm not s=
ure

it's appropriate given that JWTs are a profile of JWE or JWS.



That was the approach that Sean had suggested.  If there other things you t=
hink we should specifically add, however, please let me know.



above needs editorial polish -- there aren't any  "significant concerns"

actually listed here.



True enough



---

end





_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
_______________________________________________
OAuth mailing 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_6D0B1100D9554DA3832777A72FE4BD7Fadobecom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Thanks a lot John for the =
explanations,

so which one is the use case for JWE and w=
hich for JWS in terms of integrity and encryption?
Is it the same=
 to use one or the other?

Regards

Antonio


On Dec 29, 2012, at=
 4:43 PM, John Bradley wrote:

=

HMAC is not technica=
lly considered signing, it is integrity protection.  (There is a more =
or less endless debate around this.)

The best practice i=
s to sign asymmetrically for non repudiation using an asymmetric key, then =
encrypt with an AEAD algorithm to guarantee integrity.

=

JWE only supports encryption with integrity. (equivalent to encrypt + =
HMAC) 

If you want to use symmetric keys for =
encryption with JWE you always get the equivalent of encrypt + HMAC.
<=
div>
That is why an additional HMAC (Some call signature) ste=
p is not required.   So JWE on its own is sufficient for encryption pl=
us integrity.  

Signing on its own is always =
better inside the Encryption that way it can persist as evidence after the =
token is decrypted.

That is not to say that there =
are not use cases for Encrypt then asymmetrically sign, however most of the=
m are covered by JWE using AEAD only.

John B.

On 2012-12-29, at 7:34 AM, Antonio Sanso <asanso@adobe.com> wrote:

Hi Nat,

apologies if this sounds trivial but I a=
m trying to understand the JW* stuff and this mail thread is helping me to =
clarify some of my doubts.


On Dec 20=
, 2012, at 7:12 AM, Nat Sakimura wrote:

Thanks. 

Just a=
 few things: 

1. Sign+Encrypt

kind of nitpicking here, but would not be better to =
invert those terms in order to sound Encrypt+Sign (as long as I know the or=
der matters here and the only safe way is encrypt than  MAC).

Sign+Encrypt is useful when =
you want the signed JWT as a proof of consent to sign. 
It c=
an also exist after being decrypted. 


If you just want integrity protection, use JWE. 

For integrity should not be enough the signature so J=
WS?

Thanks a lot and regards

<=
div>Antonio


2. Alpha=
betization of the terminology

That's one way of or=
ganizing it. 
Another way of organizing it is to lay them ou=
t in a semantic order, 


where the preceding definition cannot use the terms defined later.&nbs=
p;
It is a good way to make sure the consistency, and I probably =
like this way better. 

Of the definition them=
selves, I agree it still lacks bunch of terms that needs to be defined,&nbs=
p;


and needs tightening up. 

Best, 

Nat


On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones <<=
a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon=
es@microsoft.com> wrote:











Thanks a bunch for the useful review, Jeff!  Responses are inl=
ine
in green.
&=
nbsp;
         &n=
bsp;            =
;            &n=
bsp;            =
;            &n=
bsp;    -- Mike
 
-----Original Message-----

From: oauth-bou=
nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =3DJeffH

Sent: Tuesday, November 27, 2012 2:23 PM

To: IETF oauth WG

Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
 
Hi, at ietf-85 atlanta I agreed to do a review of draf=
t-ietf-oauth-json-web-token-05, and so I have some thoughts below. Also, +1=
 to Hannes' comments.
 
Overal=
l the spec seems to get its idea across, but is pretty rough. Part of this =
is due to the language being convoluted, plus some concepts are only tacitl=
y described (with clues scattered throughout the spec), and thus it is diff=
icult
 to understand without multiple passes of this spec as well as [JWE] and [J=
WS].
 
For example, a JWT appe=
ars to be simply either a JWS or a JWE containing a JWT Claims Set, but thi=
s is not stated until right before section 3.1 (and it isn't stated that cl=
early).
 


OK, I=92ll say that earlier and more=
 clearly.
 
Immediately below are some over=
all comments, and then below that some detailed comments on various portion=
s of the spec.  I'm not addressing everything I noticed due to time co=
nstraints (apologies).
 
HTH
 
=3DJeffH
=
------
 
 <=
/p>
JWT terminology:
 
Some =
issues seem to me to be caused by defining the JWT to be the base64url enco=
ded JSON  object itself and not having terminology to clearly refer to=
 its unencoded form.
 
For exa=
mple, these two JSON objects together apparently comprise a (unencoded) JWT=
..
 
    &=
nbsp; {"typ":"JWT",
      =
; "alg":"HS256"}
 


This is the JWT Header.  The ba=
se64url encoded version is the Encoded JWT Header.
=

 
&nb=
sp;     {"iss":"joe",
  &=
nbsp;    "exp":1300819380,
  &=
nbsp;    "http://example=
.com/is_root":true}
 


This is the JWT Claims Set.
 <=
/span>
..but there's no defined way to refer to them given the spec's=
 terminlogy.
 


The terms above are already defined =
in the spec.
=
 
Consider terming the above a JWT and its =
encoded-string form an Encoded JWT, and define them separately. And then th=
ere'll be similar definitions for JWT Header and JWT Claims Set, e.g.,
 


I disagree with redefining the term =
=93JWT=94 to not also include the signature.  The term =93JWT=94 shoul=
d continue to refer to the whole thing.
 
  &=
nbsp; Encoded JWT   A JWT that has been encoded according to the<=
u>
       process defined in=
 Section X.
 
  &nbs=
p; Encoded JWT Header   The encoded-string form of a JWT Header
 
    Encoded JW=
T Claims Set   The encoded-string form of a JWT Claims Set=

 


I=92ll note that when the JWT is enc=
rypted, a base64url encoded representation of the JWT Claims Set is never u=
sed.  (The encrypted form of them is base64url encoded instead.)


 
&nb=
sp;   encoded-string form   The result of applying Base=
64url encoding to an
     &nbs=
p; input JSON text .
 


Sometimes he input to the base64url =
encoding is not JSON =96 for instance signature values or encrypted payload=
s.
&nb=
sp;
    JSON Web Token (JWT)  A JWT=
 comprises a JWT Header and a JWT Claims Set. ...
 
    JWT Header  A JSON object tha=
t is a component of a JWT. It denotes the
  &=
nbsp;    cryptographic operations applied to the JWT.  =
...
 
    JWT C=
laims Set  A JSON object containing a set of claims.  ...<=
u>
 
This also gets rid of the use of th=
e "A string representing a JSON object..."

which I find confusing and potentially misleading (bec=
ause it is actually "a Base64url encoding of a JSON object").=

 


Aah =96 I now see that this is the r=
eal misunderstanding.  The =93string representing a JSON object=94 is =
not the base64url encoded form =96 it=92s the string representation that=92=
s parseable into a JSON object.  For
 instance, it could be a string such as {=93alg=94:=94RS256=94} =96 not the=
 base64url encoded version of that string.  The reason for the syntact=
ic construction =93string representing a JSON object=94 is that its string =
representation is distinct from the abstract JSON object
 itself.  If I insert whitespace after the colon in the string {=93alg=
=94:=94RS256=94} it would parse to an equivalent JSON object but it would b=
e a different string representation.  It=92s the string representation=
 that is actually operated on by the JWT/JWS/JWE operations.<=
/span>
 
<=
p>I=92ll try to make this clearer in the spec=
.
 
U=
TF-8:
 
UTF-8 is mentioned in =
lots of places. It could probably be stated once up near

the beginning of the spec that all the JSON text is UT=
F-8 encoded, and all the

JSON strings are UTF-8 encoded.
 


I=92ll see if I can figure out how t=
o do this without introducing ambiguity.
 
Semantics, profiles and relationship =
to SAML:
 
The spec does not d=
efine any overall JWT semantics (i.e., what any given JWT

/means/). Semantics are only defined in context of eac=
h individual Reserved

Claim Name.
 
Thus any application of JWTs will need to profile the JWT spec: specif=
ying the

claim set(s) contents, and the overall semantics of th=
e resultant JWT(s).  This

is not explicitly explained in the JWT spec.=

 


Can you suggest some language you=92=
d like to see added about this?
 
<=
p>In terms of SAML, Appendix B should refer to SAML assertions rather than =
saml

tokens. Also, I'm not sure SAML assertions inherently =
have more expressivity

than JWTs. They do have more pre-defined structure and=
 semantics.
 


OK
 
Syntacticall=
y, it seems one can encode pretty much anything in whatever amount

in a JWT (one can do the same with SAML assertions), a=
nd thus theoretically JWTs

could be used to accomplish the same things as SAML as=
sertions.
 
Semantically, SAML=
 assertions are explicitly statements made by a system entity

about a subject. But by default, a JWT is empty, and h=
as no semantics (this

isn't stated explicitly). All semantics defined in the=
 JWT spec are particular

to individual reserved claims, but all reserved claims=
 are optional. Thus an

application of JWTs to use cases also apropos for SAML=
 assertions will require

arguably more profiling than that needed to apply SAML=
 assertions.
 


All true.  However once you add=
 an issuer and a principal, then you=92re back to the JWT being statements =
made by an entity about a subject.  Again, if there is language you be=
lieve should be added in that regard,
 please let me know.  (BTW, one such usage profile is in 
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.  Anothe=
r is in 
http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)<=
/u>
 =

The token size & complexity comparison seems nominall=
y fine.
 
Some detailed-but-ro=
ugh comments and musings on portions of the spec as I was

reading through it...
 =
;
> 2. Terminology
 =

terminology is not alphabetised!
 


No, it=92s in a top-down descriptive=
 order.  Is there a requirement in IETF specs that the terminology be =
alphabetized?
 =

"claim", "claims", "token" should be defined in terminology
 


I=92ll add a definition for =93claim=
=94.  =93token=94 should actually probably become =93security token=94=
, with a definition of the term.
=

 
suggestion:=

 
      Claim:=
  an assertion of something as a fact. Here, claims are<=
/p>
         name and value pairs=
, consisting of a Claim Name and a
   &n=
bsp;     Claim Value.
 =

 
>    JSON Web To=
ken (JWT)
 
   is jw=
t always a "string" or is it string (only) when it's been serialized

into one?
 


It=92s always the string representat=
ion of the serialized parts.
<=
span style=3D""> 
>   &nb=
sp;            =
    A string representing a set of claims as a JSON
>       object that is digital=
ly signed or MACed and/or encrypted.
 
   is it more that it's a set of claims encoded as a JSO=
N object
   that is string-serialized?=

 


No, per my earlier comments 

 
   is it /not/ a JWT by definition if it is not ((=
signed or unmac'd) and/or

encrypted) ?   No, because there are Plainte=
xt JWTs, but they aren't in

terminology (probably should be).
=
 


Good catch
<=
div class=3D"im">
 
&nbs=
p;  "parts" in JWT definition is unclear
 &nb=
sp;   are "parts" json objects or arrays unto themselves ?=

 


The parts are all base64url encoded =
values.  I=92ll review this terminology usage to see if it can be clar=
ified.
 
   the definition assumes knowledge t=
hat's presented later. perhaps needs fwd
   r=
eference(s), or perhaps better is to not present as much technical detail
   in the definitions.
=
 


I=92ll review
 
>    JW=
T Claims Set
 
   si=
milar comments as to JSON Web Token (JWT)
 =

   the definition says how it is encoded and encryp=
ted, but not how claims are

mapped into a JSON object
&=
nbsp;
 
should probably be simply:=

 
    JWT Claims =
Set: A set of claims expressed as a JSON object, where each
       claim is an object member (i.e., =
a name/value pair). A claim may have
   =
    a JWT Claims Set as a value.
=
 


I=92ll look into moving the definiti=
on in this direction.  What you=92re missing in the above, though, is =
the distinction between the string representing the JSON object and the abs=
tract JSON object.  We want
 the former.
 <=
/u>
>    Claim Name  The name of a member of t=
he JSON object representing a
>   &nb=
sp;   JWT Claims Set.
 
should probably be simply:
 
=

    Claim Name  The name portion of a claim, express=
ed as a JSON object member
    &nbs=
p;  name.
 
 =

>    Claim Value  The value of a membe=
r of the JSON object representing a
>  &nb=
sp;    JWT Claims Set.
 <=
/u>
should probably be simply:
 
    Claim Value  The value portion of a claim,=
 expressed as a JSON object member
   &n=
bsp;   value.
 


I=92ll look into moving the definiti=
ons in this direction. 

 
&g=
t; 3. JSON Web Token (JWT) Overview
 
>    The bytes of the UTF-8 representation of the=
 JWT Claims Set are
>    digitally si=
gned or MACed in the manner described in JSON Web
>&=
nbsp;   Signature (JWS) [JWS] and/or encrypted in the manner desc=
ribed in
>    JSON Web Encryption (JW=
E) [JWE].
 
s/ and/or encrypte=
d / or encrypted and signed /
 


I think you mean =93encrypted and in=
tegrity protected=94 rather than =93encrypted and signed=94, right?<=
u>
 
> =
   The contents of the JWT Header describe the cryptographic oper=
ations
>    applied to the JWT Claims=
 Set. If the JWT Header is a JWS Header, the
> =
   claims are digitally signed or MACed.  If the JWT Header =
is a JWE
>    Header, the claims are =
encrypted.
 
What if a JWT is =
signed AND encrypted?  Hm, from my looking at JWS and JWE

specs, it seems that in that case one uses JWE because=
 that encompasses both

encrypt & sign.
 <=
u>


No, actually JWE just provides an in=
tegrity check =96 not a signature.  If you want a signature, you need =
to use JWS.  They can (and often are) used in a nested fashion.=



 
>    A JW=
T is represented as a JWS or JWE.  The number of parts is
>    dependent upon the representation of the res=
ulting JWS or JWE.
 
Does the =
above mean to say..
 
 &n=
bsp;  A JWT consists of a JWS or JWE object, which in turn conveys the=
 JWT
    Claims Set. In the case of a JW=
S, the JWT Claims Set is the JWS
    Pay=
load. In the case of a JWE, the JWT Claims Set is the input
    Plaintext.
 =



Yes.  Although this is missing =
the fact that nested signing/encryption may be employed.
 
> 4. JWT Claims=

>
>
>&nb=
sp;   The JWT Claims Set represents a JSON object whose members a=
re the
>    claims conveyed by the JW=
T.  The Claim Names within this object MUST
>&n=
bsp;   be unique; JWTs with duplicate Claim Names MUST be rejecte=
d.
 
does the above mean to sa=
y claim names must be unique amongst the set of claim

names within any given JWT Claims Set ?  If so, t=
hat's only implied by the above

but should be stated explicitly; as it is, the above i=
s ambiguous.
 


OK
 
> 4.2. Public Claim Names<=
u>
>
>
> &n=
bsp;  Claim names can be defined at will by those using JWTs.  Ho=
wever, in
 
s/Claim names/Publ=
ic claim names/
 
> &n=
bsp;  order to prevent collisions, any new claim name SHOULD either be=

>    registered in the IANA JSON Web=
 Token Claims registry Section 9.1 or
>  &=
nbsp; be a URI that contains a Collision Resistant Namespace.=

 
 
why should a c=
laim name be a URI if I wish to make use of Collision Resistant

Namespaces?  For example, if I simply use say UUI=
Ds as claim names..
 
 &n=
bsp;    {"iss":"joe",
   =
    "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}<=
/u>
 
..it will be universally unique provid=
ed I minted it appropriately (no URI

syntax is needed).
 


Fair enough.  I=92ll try to gen=
eralize the language.
 
> 4.3. Private C=
laim Names
>
><=
/p>
>    A producer and consumer of a JWT may agree to =
any claim name that is
>    not a Res=
erved Name Section 4.1 or a Public Name Section 4.2.  Unlike=

>    Public Names, these private names are sub=
ject to collision and should
>    be =
used with caution.
 
it seems =
private claim names are only subject to collision if the implementers

don't make appropriate use of Collision Resistant Name=
spaces, i.e. they "can be"

subject to collision.
 =
;


True
 
the above two sections use "public=
" and "private" as distinguishing factors, but

it seems to me the distinguishing factor (given how th=
e above is written) is

more whether Collision Resistant Namespaces are employ=
ed or not.
 


Yes, although using a collision resi=
stant namespace effectively makes them public, as we=92re using the term=

 
An implied aspect of public claim names seems to be that=
 it is assumed that they

are publicly listed/documented/leaked, thus the "publi=
c" moniker, and hence

ought to be universally unique as a matter of course.<=
u>
 
and "private" ones seem to b=
e assumed to be obfuscated to all but the agreeing

parties?  Or they are "private" in only the sense=
 that they are created in the

context of a private arrangement?
=
 


Private in that they are created in =
the context of a private arrangement.  I=92ll try to clarify this poin=
t.  Facebook could define how they=92re going to use the =93id=94 clai=
m very publicly, and yet it would still
 be a private claim if not registered with IANA.
 
>
>=
 7. Rules for Creating and Validating a JWT
>=

>
>    To create a J=
WT, one MUST perform these steps.  The order of the
<=
p>>    steps is not significant in cases where there are =
no dependencies
>    between the inpu=
ts and outputs of the steps.
>
&=
gt;    1.  Create a JWT Claims Set containing the desir=
ed claims.  Note that
>    =
    white space is explicitly allowed in the representation =
and no
>        c=
anonicalization is performed before encoding.
&n=
bsp;
I presume the rationale for allowing white space is that =
JSON objects are

unordered (and can contain arbitrary whitespace), thus=
 simple buffer-to-buffer

comparisons between serialized objects cannot be relia=
bly performed.  If so this

should be explicitly stated.
 


Actually, it=92s to avoid canonicali=
zation.  I=92ll reread the spec to see if we=92ve stated that clearly =
or not.
 
It seems that member/value-by-member/value com=
parisons must always be done, by

parsing the JSON objects and extracting all members an=
d values, this should be

stated explicitly in the spec.
=
 
I found meager jwt comparison instructions at the v=
ery end of Section 7. it

should probably be its own subsection. It should proba=
bly explicitly say that

JWTs need to be parsed into their constituent componen=
ts, and the latter must be

individually examined/compared.
 


We tried to cover this in the end of=
 section 7, starting with the sentence =93Processing a JWT inevitably requi=
res comparing known strings to values in the token=94, which says how these=
 comparisons must be performed. 
 I agree that this should become its own subsection.  I don=92t unders=
tand your remark about constituent components.  Can you clarify?
 
>    Comparisons between JSON strings and=
 other Unicode strings MUST be
>    p=
erformed as specified below:
 
this comparison algorithm seems to be attempting to allow for comparison o=
f

UTF-8 encoded JSON strings with other unicode strings =
in any of the unicode

encoding formats, but only implies that; it should be =
stated.
 


Good
 
>
>    1.  Remove any JSON applied esca=
ping to produce an array of Unicode
>  &nb=
sp;     code points.
 <=
u>
I don't think (1) is correct.  A JSON string is by defaul=
t encoded in UTF-8. A

UTF-8 encoded string is not "an array of Unicode code =
points" (its a sequence of

code units, which must be decoded into code points), i=
 think a step is missing

here..
 
=
    1.  Remove any JSON escaping from the input JSON st=
ring.
 
    1.a=
  convert the string into a sequence of unicode code points.=

 


How about =93Remove any JSON escapin=
g from the input JSON string and convert the string into a sequence of Unic=
ode code points=94?
 
..and then compare code point-by-c=
ode point. This overall algorithm /seems/ ok,

but I'm not sure, it seems there's rationale that's no=
t expressed, eg for

excluding use of Unicode Normalization [USA15]. Also t=
he alg is incomplete in

that it doesn't stipulate converting the "other unicod=
e string" into a sequence

of code points.
 


Fair enough
=

 
> 10. Security Considera=
tions
>
>
>    All of the security issues faced by any cryptograph=
ic application
>    must be faced by =
a JWT/JWS/JWE/JWK agent.  Among these issues are
&=
gt;    protecting the user's private key, preventing various=
 attacks, and
>    helping the user a=
void mistakes such as inadvertently encrypting a
>&n=
bsp;   message for the wrong recipient.  The entire list of =
security
>    considerations is beyon=
d the scope of this document, but some
>  =
  significant concerns are listed here.
>
>    All the security considerations in th=
e JWS specification also apply
>    t=
o JWT, as do the JWE security considerations when encryption is
>    employed.  In particular, the JWS JSON=
 Security Considerations and
>    Uni=
code Comparison Security Considerations apply equally to the JWT<=
/u>
>    Claims Set in the same manner that they do=
 to the JWS Header.
>
&nb=
sp;
dunno if you can get away with sec cons wholly in other do=
cs, and I'm not sure

it's appropriate given that JWTs are a profile of JWE =
or JWS.
 


That was the approach that Sean had =
suggested.  If there other things you think we should specifically add=
, however, please let me know.
 
above needs editorial p=
olish -- there aren't any  "significant concerns"

actually listed here.
 =
;


True enough
=

 
---
end=

 
 
=
_______________________________________________
OAuth m=
ailing list
OAuth@ietf.o=
rg
https://www.ietf.org/mailman/listinfo/oauth







_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



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

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


=

--_000_6D0B1100D9554DA3832777A72FE4BD7Fadobecom_--

From sakimura@gmail.com  Sat Dec 29 10:01:30 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF84C21F85E7 for ; Sat, 29 Dec 2012 10:01:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.765
X-Spam-Level: 
X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re6bIHSmcHvK for ; Sat, 29 Dec 2012 10:01:27 -0800 (PST)
Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 026B221F85AF for ; Sat, 29 Dec 2012 10:01:26 -0800 (PST)
Received: by mail-ee0-f47.google.com with SMTP id e51so5556315eek.34 for ; Sat, 29 Dec 2012 10:01:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:from:mime-version:in-reply-to:date:message-id:subject:to :cc:content-type; bh=NVvPkhWgOi1XGgpPAgiZuaaCCZSZtbIPlf02/oi4JGg=; b=B5U8pWT/k9ooojW1lkTnnfsOXPaMFslrnPO4MjIA3forQdgZJBYIjeTLzFt/27N85X u+GiQXtgnEu76QA9d5avl9gfw9KblyNSvmd1vvG5+LTg8MWQ/jQph9mk7jEyMDyrT2Tf WfS6xcOmkHSsktzMPlBTZs1Bj8fJMXIYNHEQS+pVM7k3DHbqIbJfy576TcfnIpuDHH8j IlhDnsEuToZ3sQUFWYLoj8alzXh7K4ehnfsv0jJsWd4kpEbTytA38avCJio+DZuOILhr gPI79deW8nBtyl/zvncLp5trcJEiz01PMXh+BwtCbpKkivNfvKxx5z5r3gNgv1j3OciX SIOQ==
Received: by 10.14.216.70 with SMTP id f46mr96843451eep.12.1356804086097; Sat, 29 Dec 2012 10:01:26 -0800 (PST)
References: <50B53D3E.1000107@KingsMountain.com> <4E1F6AAD24975D4BA5B168042967394366979DAD@TK5EX14MBXC283.redmond.corp.microsoft.com>  <7816700B-65D6-4C91-8D62-A2EED02442F7@adobe.com>
From: Nat Sakimura 
Mime-Version: 1.0 (1.0)
In-Reply-To: <7816700B-65D6-4C91-8D62-A2EED02442F7@adobe.com>
Date: Sun, 30 Dec 2012 03:01:22 +0900
Message-ID: <-2232710541978003268@unknownmsgid>
To: Antonio Sanso 
Content-Type: multipart/alternative; boundary=047d7b603c1e94e64204d2019126
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 29 Dec 2012 18:01:30 -0000

--047d7b603c1e94e64204d2019126
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=3Dnat via iPhone

Dec 29, 2012 19:35=E3=80=81Antonio Sanso  =E3=81=AE=E3=83=
=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8:

Hi Nat,

apologies if this sounds trivial but I am trying to understand the JW*
stuff and this mail thread is helping me to clarify some of my doubts.


On Dec 20, 2012, at 7:12 AM, Nat Sakimura wrote:

Thanks.

Just a few things:

1. Sign+Encrypt


kind of nitpicking here, but would not be better to invert those terms in
order to sound Encrypt+Sign (as long as I know the order matters here and
the only safe way is encrypt than  MAC).


No. You should use AEAD algorithms for the integrity protection.

Signing something that you cannot decrypt and verify is pretty meaningless
 in the contractual settings.



Sign+Encrypt is useful when you want the signed JWT as a proof of consent
to sign.
It can also exist after being decrypted.
If you just want integrity protection, use JWE.


For integrity should not be enough the signature so JWS?


All JWE algorithms are AEAD so JWS signing over JWE is redundant.


Thanks a lot and regards

Antonio


2. Alphabetization of the terminology

That's one way of organizing it.
Another way of organizing it is to lay them out in a semantic order,
where the preceding definition cannot use the terms defined later.
It is a good way to make sure the consistency, and I probably like this way
better.

Of the definition themselves, I agree it still lacks bunch of terms that
needs to be defined,
and needs tightening up.

Best,

Nat


On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones wr=
ote:

>  Thanks a bunch for the useful review, Jeff!  Responses are inline in
> green.****
>
> ** **
>
>                                                                 -- Mike**=
*
> *
>
> ** **
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
> =3DJeffH
> Sent: Tuesday, November 27, 2012 2:23 PM
> To: IETF oauth WG
> Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>
> ** **
>
> Hi, at ietf-85 atlanta I agreed to do a review of
> draft-ietf-oauth-json-web-token-05, and so I have some thoughts below.
> Also, +1 to Hannes' comments.****
>
> ** **
>
> Overall the spec seems to get its idea across, but is pretty rough. Part
> of this is due to the language being convoluted, plus some concepts are
> only tacitly described (with clues scattered throughout the spec), and th=
us
> it is difficult to understand without multiple passes of this spec as wel=
l
> as [JWE] and [JWS].****
>
> ** **
>
> For example, a JWT appears to be simply either a JWS or a JWE containing =
a
> JWT Claims Set, but this is not stated until right before section 3.1 (an=
d
> it isn't stated that clearly).****
>
> ** **
>
> OK, I=E2=80=99ll say that earlier and more clearly.****
>
> ** **
>
> Immediately below are some overall comments, and then below that some
> detailed comments on various portions of the spec.  I'm not addressing
> everything I noticed due to time constraints (apologies).****
>
> ** **
>
> HTH****
>
> ** **
>
> =3DJeffH****
>
> ------****
>
> ** **
>
> ** **
>
> JWT terminology:****
>
> ** **
>
> Some issues seem to me to be caused by defining the JWT to be the
> base64url encoded JSON  object itself and not having terminology to clear=
ly
> refer to its unencoded form.****
>
> ** **
>
> For example, these two JSON objects together apparently comprise a
> (unencoded) JWT..****
>
> ** **
>
>       {"typ":"JWT",****
>
>        "alg":"HS256"}****
>
> ** **
>
> This is the JWT Header.  The base64url encoded version is the Encoded JWT
> Header.****
>
> ** **
>
>       {"iss":"joe",****
>
>        "exp":1300819380,****
>
>        "http://example.com/is_root":true}****
>
> ** **
>
> This is the JWT Claims Set.****
>
> ** **
>
> ..but there's no defined way to refer to them given the spec's terminlogy=
.
> ****
>
> ** **
>
> The terms above are already defined in the spec.****
>
> ** **
>
> Consider terming the above a JWT and its encoded-string form an Encoded
> JWT, and define them separately. And then there'll be similar definitions
> for JWT Header and JWT Claims Set, e.g.,****
>
> ** **
>
> I disagree with redefining the term =E2=80=9CJWT=E2=80=9D to not also inc=
lude the
> signature.  The term =E2=80=9CJWT=E2=80=9D should continue to refer to th=
e whole thing.***
> *
>
> ** **
>
>     Encoded JWT   A JWT that has been encoded according to the****
>
>        process defined in Section X.****
>
> ** **
>
>     Encoded JWT Header   The encoded-string form of a JWT Header****
>
> ** **
>
>     Encoded JWT Claims Set   The encoded-string form of a JWT Claims Set*=
*
> **
>
> ** **
>
> I=E2=80=99ll note that when the JWT is encrypted, a base64url encoded
> representation of the JWT Claims Set is never used.  (The encrypted form =
of
> them is base64url encoded instead.)****
>
> ** **
>
>     encoded-string form   The result of applying Base64url encoding to an=
*
> ***
>
>        input JSON text .****
>
> ** **
>
> Sometimes he input to the base64url encoding is not JSON =E2=80=93 for in=
stance
> signature values or encrypted payloads.****
>
> ** **
>
>     JSON Web Token (JWT)  A JWT comprises a JWT Header and a JWT Claims
> Set. ...****
>
> ** **
>
>     JWT Header  A JSON object that is a component of a JWT. It denotes th=
e
> ****
>
>        cryptographic operations applied to the JWT.  ...****
>
> ** **
>
>     JWT Claims Set  A JSON object containing a set of claims.  ...****
>
> ** **
>
> This also gets rid of the use of the "A string representing a JSON
> object..." ****
>
> which I find confusing and potentially misleading (because it is actually
> "a Base64url encoding of a JSON object").****
>
> ** **
>
> Aah =E2=80=93 I now see that this is the real misunderstanding.  The =E2=
=80=9Cstring
> representing a JSON object=E2=80=9D is not the base64url encoded form =E2=
=80=93 it=E2=80=99s the
> string representation that=E2=80=99s parseable into a JSON object.  For i=
nstance,
> it could be a string such as {=E2=80=9Calg=E2=80=9D:=E2=80=9DRS256=E2=80=
=9D} =E2=80=93 not the base64url encoded
> version of that string.  The reason for the syntactic construction =E2=80=
=9Cstring
> representing a JSON object=E2=80=9D is that its string representation is =
distinct
> from the abstract JSON object itself.  If I insert whitespace after the
> colon in the string {=E2=80=9Calg=E2=80=9D:=E2=80=9DRS256=E2=80=9D} it wo=
uld parse to an equivalent JSON
> object but it would be a different string representation.  It=E2=80=99s t=
he string
> representation that is actually operated on by the JWT/JWS/JWE operations=
.
> ****
>
> ** **
>
> I=E2=80=99ll try to make this clearer in the spec.****
>
> ** **
>
> UTF-8:****
>
> ** **
>
> UTF-8 is mentioned in lots of places. It could probably be stated once up
> near ****
>
> the beginning of the spec that all the JSON text is UTF-8 encoded, and al=
l
> the ****
>
> JSON strings are UTF-8 encoded.****
>
> ** **
>
> I=E2=80=99ll see if I can figure out how to do this without introducing a=
mbiguity.
> ****
>
> ** **
>
> Semantics, profiles and relationship to SAML:****
>
> ** **
>
> The spec does not define any overall JWT semantics (i.e., what any given
> JWT ****
>
> /means/). Semantics are only defined in context of each individual
> Reserved ****
>
> Claim Name.****
>
> ** **
>
> Thus any application of JWTs will need to profile the JWT spec: specifyin=
g
> the ****
>
> claim set(s) contents, and the overall semantics of the resultant JWT(s).
> This ****
>
> is not explicitly explained in the JWT spec.****
>
> ** **
>
> Can you suggest some language you=E2=80=99d like to see added about this?=
****
>
> ** **
>
> In terms of SAML, Appendix B should refer to SAML assertions rather than
> saml ****
>
> tokens. Also, I'm not sure SAML assertions inherently have more
> expressivity ****
>
> than JWTs. They do have more pre-defined structure and semantics.****
>
> ** **
>
> OK****
>
> ** **
>
> Syntactically, it seems one can encode pretty much anything in whatever
> amount ****
>
> in a JWT (one can do the same with SAML assertions), and thus
> theoretically JWTs ****
>
> could be used to accomplish the same things as SAML assertions.****
>
> ** **
>
> Semantically, SAML assertions are explicitly statements made by a system
> entity ****
>
> about a subject. But by default, a JWT is empty, and has no semantics
> (this ****
>
> isn't stated explicitly). All semantics defined in the JWT spec are
> particular ****
>
> to individual reserved claims, but all reserved claims are optional. Thus
> an ****
>
> application of JWTs to use cases also apropos for SAML assertions will
> require ****
>
> arguably more profiling than that needed to apply SAML assertions.****
>
> ** **
>
> All true.  However once you add an issuer and a principal, then you=E2=80=
=99re
> back to the JWT being statements made by an entity about a subject.  Agai=
n,
> if there is language you believe should be added in that regard, please l=
et
> me know.  (BTW, one such usage profile is in
> http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.  Another is in
> http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)****
>
> ** **
>
> The token size & complexity comparison seems nominally fine.****
>
> ** **
>
> Some detailed-but-rough comments and musings on portions of the spec as I
> was ****
>
> reading through it...****
>
> ** **
>
> > 2. Terminology****
>
> ** **
>
> terminology is not alphabetised!****
>
> ** **
>
> No, it=E2=80=99s in a top-down descriptive order.  Is there a requirement=
 in IETF
> specs that the terminology be alphabetized?****
>
> ** **
>
> "claim", "claims", "token" should be defined in terminology****
>
> ** **
>
> I=E2=80=99ll add a definition for =E2=80=9Cclaim=E2=80=9D.  =E2=80=9Ctoke=
n=E2=80=9D should actually probably
> become =E2=80=9Csecurity token=E2=80=9D, with a definition of the term.**=
**
>
> ** **
>
> suggestion:****
>
> ** **
>
>       Claim:  an assertion of something as a fact. Here, claims are****
>
>          name and value pairs, consisting of a Claim Name and a****
>
>          Claim Value.****
>
> ** **
>
> ** **
>
> >    JSON Web Token (JWT)****
>
> ** **
>
>    is jwt always a "string" or is it string (only) when it's been
> serialized ****
>
> into one?****
>
> ** **
>
> It=E2=80=99s always the string representation of the serialized parts.***=
*
>
> ** **
>
> >                    A string representing a set of claims as a JSON****
>
> >       object that is digitally signed or MACed and/or encrypted.****
>
> ** **
>
>    is it more that it's a set of claims encoded as a JSON object****
>
>    that is string-serialized?****
>
> ** **
>
> No, per my earlier comments ** **
>
> ** **
>
>    is it /not/ a JWT by definition if it is not ((signed or unmac'd)
> and/or ****
>
> encrypted) ?   No, because there are Plaintext JWTs, but they aren't in *=
*
> **
>
> terminology (probably should be).****
>
> ** **
>
> Good catch****
>
> ** **
>
>    "parts" in JWT definition is unclear****
>
>      are "parts" json objects or arrays unto themselves ?****
>
> ** **
>
> The parts are all base64url encoded values.  I=E2=80=99ll review this ter=
minology
> usage to see if it can be clarified.****
>
> ** **
>
>    the definition assumes knowledge that's presented later. perhaps needs
> fwd****
>
>    reference(s), or perhaps better is to not present as much technical
> detail****
>
>    in the definitions.****
>
> ** **
>
> I=E2=80=99ll review****
>
> ** **
>
> >    JWT Claims Set****
>
> ** **
>
>    similar comments as to JSON Web Token (JWT)****
>
> ** **
>
>    the definition says how it is encoded and encrypted, but not how claim=
s
> are ****
>
> mapped into a JSON object****
>
> ** **
>
> ** **
>
> should probably be simply:****
>
> ** **
>
>     JWT Claims Set: A set of claims expressed as a JSON object, where eac=
h
> ****
>
>        claim is an object member (i.e., a name/value pair). A claim may
> have****
>
>        a JWT Claims Set as a value.****
>
> ** **
>
> I=E2=80=99ll look into moving the definition in this direction.  What you=
=E2=80=99re
> missing in the above, though, is the distinction between the string
> representing the JSON object and the abstract JSON object.  We want the
> former.****
>
> ** **
>
> >    Claim Name  The name of a member of the JSON object representing a**=
*
> *
>
> >       JWT Claims Set.****
>
> ** **
>
> should probably be simply:****
>
> ** **
>
>     Claim Name  The name portion of a claim, expressed as a JSON object
> member****
>
>        name.****
>
> ** **
>
> ** **
>
> >    Claim Value  The value of a member of the JSON object representing a=
*
> ***
>
> >       JWT Claims Set.****
>
> ** **
>
> should probably be simply:****
>
> ** **
>
>     Claim Value  The value portion of a claim, expressed as a JSON object
> member****
>
>        value.****
>
> ** **
>
> I=E2=80=99ll look into moving the definitions in this direction.  ****
>
> ** **
>
> > 3. JSON Web Token (JWT) Overview****
>
> ** **
>
> >    The bytes of the UTF-8 representation of the JWT Claims Set are****
>
> >    digitally signed or MACed in the manner described in JSON Web****
>
> >    Signature (JWS) [JWS] and/or encrypted in the manner described in***=
*
>
> >    JSON Web Encryption (JWE) [JWE].****
>
> ** **
>
> s/ and/or encrypted / or encrypted and signed /****
>
> ** **
>
> I think you mean =E2=80=9Cencrypted and integrity protected=E2=80=9D rath=
er than
> =E2=80=9Cencrypted and signed=E2=80=9D, right?****
>
> ** **
>
> >    The contents of the JWT Header describe the cryptographic operations=
*
> ***
>
> >    applied to the JWT Claims Set. If the JWT Header is a JWS Header, th=
e
> ****
>
> >    claims are digitally signed or MACed.  If the JWT Header is a JWE***=
*
>
> >    Header, the claims are encrypted.****
>
> ** **
>
> What if a JWT is signed AND encrypted?  Hm, from my looking at JWS and JW=
E
> ****
>
> specs, it seems that in that case one uses JWE because that encompasses
> both ****
>
> encrypt & sign.****
>
> ** **
>
> No, actually JWE just provides an integrity check =E2=80=93 not a signatu=
re.  If
> you want a signature, you need to use JWS.  They can (and often are) used
> in a nested fashion.****
>
> ** **
>
> >    A JWT is represented as a JWS or JWE.  The number of parts is****
>
> >    dependent upon the representation of the resulting JWS or JWE.****
>
> ** **
>
> Does the above mean to say..****
>
> ** **
>
>     A JWT consists of a JWS or JWE object, which in turn conveys the JWT*=
*
> **
>
>     Claims Set. In the case of a JWS, the JWT Claims Set is the JWS****
>
>     Payload. In the case of a JWE, the JWT Claims Set is the input****
>
>     Plaintext.****
>
> ** **
>
> Yes.  Although this is missing the fact that nested signing/encryption ma=
y
> be employed.****
>
> ** **
>
> > 4. JWT Claims****
>
> >****
>
> >****
>
> >    The JWT Claims Set represents a JSON object whose members are the***=
*
>
> >    claims conveyed by the JWT.  The Claim Names within this object MUST=
*
> ***
>
> >    be unique; JWTs with duplicate Claim Names MUST be rejected.****
>
> ** **
>
> does the above mean to say claim names must be unique amongst the set of
> claim ****
>
> names within any given JWT Claims Set ?  If so, that's only implied by th=
e
> above ****
>
> but should be stated explicitly; as it is, the above is ambiguous.****
>
> ** **
>
> OK****
>
> ** **
>
> > 4.2. Public Claim Names****
>
> >****
>
> >****
>
> >    Claim names can be defined at will by those using JWTs.  However, in=
*
> ***
>
> ** **
>
> s/Claim names/Public claim names/****
>
> ** **
>
> >    order to prevent collisions, any new claim name SHOULD either be****
>
> >    registered in the IANA JSON Web Token Claims registry Section 9.1 or=
*
> ***
>
> >    be a URI that contains a Collision Resistant Namespace.****
>
> ** **
>
> ** **
>
> why should a claim name be a URI if I wish to make use of Collision
> Resistant ****
>
> Namespaces?  For example, if I simply use say UUIDs as claim names..****
>
> ** **
>
>       {"iss":"joe",****
>
>        "3005fa05-e76c-4994-bbc9-65b2ace2305c":"foo"}****
>
> ** **
>
> ..it will be universally unique provided I minted it appropriately (no UR=
I
> ****
>
> syntax is needed).****
>
> ** **
>
> Fair enough.  I=E2=80=99ll try to generalize the language.****
>
> ** **
>
> > 4.3. Private Claim Names****
>
> >****
>
> >****
>
> >    A producer and consumer of a JWT may agree to any claim name that is=
*
> ***
>
> >    not a Reserved Name Section 4.1 or a Public Name Section 4.2.  Unlik=
e
> ****
>
> >    Public Names, these private names are subject to collision and shoul=
d
> ****
>
> >    be used with caution.****
>
> ** **
>
> it seems private claim names are only subject to collision if the
> implementers ****
>
> don't make appropriate use of Collision Resistant Namespaces, i.e. they
> "can be" ****
>
> subject to collision.****
>
> ** **
>
> True****
>
> ** **
>
> the above two sections use "public" and "private" as distinguishing
> factors, but ****
>
> it seems to me the distinguishing factor (given how the above is written)
> is ****
>
> more whether Collision Resistant Namespaces are employed or not.****
>
> ** **
>
> Yes, although using a collision resistant namespace effectively makes the=
m
> public, as we=E2=80=99re using the term****
>
> ** **
>
> An implied aspect of public claim names seems to be that it is assumed
> that they ****
>
> are publicly listed/documented/leaked, thus the "public" moniker, and
> hence ****
>
> ought to be universally unique as a matter of course.****
>
> ** **
>
> and "private" ones seem to be assumed to be obfuscated to all but the
> agreeing ****
>
> parties?  Or they are "private" in only the sense that they are created i=
n
> the ****
>
> context of a private arrangement?****
>
> ** **
>
> Private in that they are created in the context of a private arrangement.
> I=E2=80=99ll try to clarify this point.  Facebook could define how they=
=E2=80=99re going to
> use the =E2=80=9Cid=E2=80=9D claim very publicly, and yet it would still =
be a private claim
> if not registered with IANA.****
>
> ** **
>
> >****
>
> > 7. Rules for Creating and Validating a JWT****
>
> >****
>
> >****
>
> >    To create a JWT, one MUST perform these steps.  The order of the****
>
> >    steps is not significant in cases where there are no dependencies***=
*
>
> >    between the inputs and outputs of the steps.****
>
> >****
>
> >    1.  Create a JWT Claims Set containing the desired claims.  Note tha=
t
> ****
>
> >        white space is explicitly allowed in the representation and no**=
*
> *
>
> >        canonicalization is performed before encoding.****
>
> ** **
>
> I presume the rationale for allowing white space is that JSON objects are
> ****
>
> unordered (and can contain arbitrary whitespace), thus simple
> buffer-to-buffer ****
>
> comparisons between serialized objects cannot be reliably performed.  If
> so this ****
>
> should be explicitly stated.****
>
> ** **
>
> Actually, it=E2=80=99s to avoid canonicalization.  I=E2=80=99ll reread th=
e spec to see if
> we=E2=80=99ve stated that clearly or not.****
>
> ** **
>
> It seems that member/value-by-member/value comparisons must always be
> done, by ****
>
> parsing the JSON objects and extracting all members and values, this
> should be ****
>
> stated explicitly in the spec.****
>
> ** **
>
> I found meager jwt comparison instructions at the very end of Section 7.
> it ****
>
> should probably be its own subsection. It should probably explicitly say
> that ****
>
> JWTs need to be parsed into their constituent components, and the latter
> must be ****
>
> individually examined/compared.****
>
> ** **
>
> We tried to cover this in the end of section 7, starting with the sentenc=
e
> =E2=80=9CProcessing a JWT inevitably requires comparing known strings to =
values in
> the token=E2=80=9D, which says how these comparisons must be performed.  =
I agree
> that this should become its own subsection.  I don=E2=80=99t understand y=
our remark
> about constituent components.  Can you clarify?****
>
> ** **
>
> >    Comparisons between JSON strings and other Unicode strings MUST be**=
*
> *
>
> >    performed as specified below:****
>
> ** **
>
> this comparison algorithm seems to be attempting to allow for comparison
> of ****
>
> UTF-8 encoded JSON strings with other unicode strings in any of the
> unicode ****
>
> encoding formats, but only implies that; it should be stated.****
>
> ** **
>
> Good****
>
> ** **
>
> >****
>
> >    1.  Remove any JSON applied escaping to produce an array of Unicode*=
*
> **
>
> >        code points.****
>
> ** **
>
> I don't think (1) is correct.  A JSON string is by default encoded in
> UTF-8. A ****
>
> UTF-8 encoded string is not "an array of Unicode code points" (its a
> sequence of ****
>
> code units, which must be decoded into code points), i think a step is
> missing ****
>
> here..****
>
> ** **
>
>     1.  Remove any JSON escaping from the input JSON string.****
>
> ** **
>
>     1.a  convert the string into a sequence of unicode code points.****
>
> ** **
>
> How about =E2=80=9CRemove any JSON escaping from the input JSON string an=
d convert
> the string into a sequence of Unicode code points=E2=80=9D?****
>
> ** **
>
> ..and then compare code point-by-code point. This overall algorithm
> /seems/ ok, ****
>
> but I'm not sure, it seems there's rationale that's not expressed, eg for
> ****
>
> excluding use of Unicode Normalization [USA15]. Also the alg is incomplet=
e
> in ****
>
> that it doesn't stipulate converting the "other unicode string" into a
> sequence ****
>
> of code points.****
>
> ** **
>
> Fair enough****
>
> ** **
>
> > 10. Security Considerations****
>
> >****
>
> >****
>
> >    All of the security issues faced by any cryptographic application***=
*
>
> >    must be faced by a JWT/JWS/JWE/JWK agent.  Among these issues are***=
*
>
> >    protecting the user's private key, preventing various attacks, and**=
*
> *
>
> >    helping the user avoid mistakes such as inadvertently encrypting a**=
*
> *
>
> >    message for the wrong recipient.  The entire list of security****
>
> >    considerations is beyond the scope of this document, but some****
>
> >    significant concerns are listed here.****
>
> >****
>
> >    All the security considerations in the JWS specification also apply*=
*
> **
>
> >    to JWT, as do the JWE security considerations when encryption is****
>
> >    employed.  In particular, the JWS JSON Security Considerations and**=
*
> *
>
> >    Unicode Comparison Security Considerations apply equally to the JWT*=
*
> **
>
> >    Claims Set in the same manner that they do to the JWS Header.****
>
> >****
>
> ** **
>
> dunno if you can get away with sec cons wholly in other docs, and I'm not
> sure ****
>
> it's appropriate given that JWTs are a profile of JWE or JWS.****
>
> ** **
>
> That was the approach that Sean had suggested.  If there other things you
> think we should specifically add, however, please let me know.****
>
> ** **
>
> above needs editorial polish -- there aren't any  "significant concerns" =
*
> ***
>
> actually listed here.****
>
> ** **
>
> True enough****
>
> ** **
>
> ---****
>
> end****
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> OAuth mailing 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
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
 _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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




=3Dnat via iPhone

Dec 29, 2012 19:35=E3=80=81Antonio Sanso <asanso@adobe.com> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=
=E3=83=BC=E3=82=B8:


Hi Nat,

apologi=
es if this sounds trivial but I am trying to understand the JW* stuff and t=
his mail thread is helping me to clarify some of my doubts.




On Dec 20, 2012, at 7:12 AM, Nat Sakimura wrote:
Thank=
s.=C2=A0

Just a few things:=C2=A0

1. Sign+Encrypt



kind of nitpicking here, but would not be =
better to invert those terms in order to sound Encrypt+Sign (as long as I k=
now the order matters here and the only safe way is encrypt than =C2=A0MAC)=
.



No. You should use AEAD algor=
ithms for the integrity protection.=C2=A0

Signing someth=
ing that you cannot decrypt and verify is pretty meaningless =C2=A0in the c=
ontractual settings.=C2=A0





Sign+Encrypt is useful when you want the signed JW=
T as a proof of consent to sign.=C2=A0
It can also exist after be=
ing decrypted.=C2=A0



If you just want integrity protection, use JWE.=C2=A0

For integrity should not be enough the signature so J=
WS?

All JWE algorithms a=
re AEAD so JWS signing over JWE is redundant.=C2=A0




Thank=
s a lot and regards

Antonio


2. Alphabetization of the terminology


That's one way of organizing it.=C2=A0
An=
other way of organizing it is to lay them out in a semantic order,=C2=A0

where the preceding definition cannot use the terms defined later.=C2=
=A0
It is a good way to make sure the consistency, and I probably=
 like this way better.=C2=A0

Of the definition the=
mselves, I agree it still lacks bunch of terms that needs to be defined,=C2=
=A0



and needs tightening up.=C2=A0

Best,=C2=A0

Nat


On Thu, Dec 20, 2012 at 9:14 AM, Mike Jones <<=
a href=3D"mailto:Michael.Jones@microsoft.com" target=3D"_blank">Michael.Jon=
es@microsoft.com> wrote:












Thanks a bunch for the useful review, Jeff!=C2=A0 Responses are inl=
ine
in green.
=
=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=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
<=
/u>=C2=A0
-----Original Message-----


From: oauth-bou=
nces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of =3DJeffH

Sent: Tuesday, November 27, 2012 2:23 PM

To: IETF oauth WG

Subject: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
=C2=A0
Hi, at ietf-85 atlanta I agreed to do a review of draf=
t-ietf-oauth-json-web-token-05, and so I have some thoughts below. Also, +1=
 to Hannes' comments.


=C2=A0
Overall the spec seems to get its idea across=
, but is pretty rough. Part of this is due to the language being convoluted=
, plus some concepts are only tacitly described (with clues scattered throu=
ghout the spec), and thus it is difficult
 to understand without multiple passes of this spec as well as [JWE] and [J=
WS].
=C2=A0
For example, a JWT appe=
ars to be simply either a JWS or a JWE containing a JWT Claims Set, but thi=
s is not stated until right before section 3.1 (and it isn't stated tha=
t clearly).


=C2=A0


OK, I=E2=80=99ll say that earlier an=
d more clearly.
=C2=A0
Immediately below are som=
e overall comments, and then below that some detailed comments on various p=
ortions of the spec.=C2=A0 I'm not addressing everything I noticed due =
to time constraints (apologies).


=C2=A0
HTH
=C2=A0<=
/p>
=3DJeffH
------
=C2=A0=

=C2=A0
JWT terminology:
=

=C2=A0


Some issues seem to me to be caused by defining the JWT to be the base64=
url encoded JSON=C2=A0 object itself and not having terminology to clearly =
refer to its unencoded form.
=C2=A0
For example, these two JSON objects together apparently comprise a (unenco=
ded) JWT..


=C2=A0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 {"typ&quo=
t;:"JWT",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 "alg":"HS256"}
=C2=A0=



This is the JWT Header.=C2=A0 The ba=
se64url encoded version is the Encoded JWT Header.
=

=C2=A0
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 {"iss":"joe",

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "exp":1300819380,<=
u>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "http://example.com/is_root":true}


=C2=A0


This is the JWT Claims Set.
=C2=A0
..but there's no defined way to refer to them given the spec=
9;s terminlogy.


=C2=A0


The terms above are already defined =
in the spec.
=C2=A0
Consider terming the above a JWT and its encod=
ed-string form an Encoded JWT, and define them separately. And then there&#=
39;ll be similar definitions for JWT Header and JWT Claims Set, e.g.,


=C2=A0


I disagree with redefining the term =
=E2=80=9CJWT=E2=80=9D to not also include the signature.=C2=A0 The term =E2=
=80=9CJWT=E2=80=9D should continue to refer to the whole thing.
=C2=A0

=C2=A0=C2=A0=C2=A0 Encoded JWT=C2=A0=C2=A0 A JWT that has been encoded a=
ccording to the
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0pr=
ocess defined in Section X.
=C2=A0
=
=C2=A0=C2=A0=C2=A0 Encoded JWT Header=C2=A0=C2=A0 The encoded-string form o=
f a JWT Header


=C2=A0
=C2=A0=C2=A0=C2=A0 Encoded JWT Claims Set=C2=
=A0=C2=A0 The encoded-string form of a JWT Claims Set
<=
u>=C2=A0


I=E2=80=99ll note that when the JWT =
is encrypted, a base64url encoded representation of the JWT Claims Set is n=
ever used.=C2=A0 (The encrypted form of them is base64url encoded instead.)=




=C2=A0
=C2=A0=
=C2=A0=C2=A0 encoded-string form=C2=A0=C2=A0 The result of applying Base64u=
rl encoding to an
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
input JSON text .
=C2=A0


Sometimes he input to the base64url =
encoding is not JSON =E2=80=93 for instance signature values or encrypted p=
ayloads.
=
=C2=A0


=C2=A0=C2=A0=C2=A0 JSON Web Token (JWT)=C2=A0 A JWT comprises a JWT Head=
er and a JWT Claims Set. ...
=C2=A0
=C2=A0=C2=A0=C2=A0 JWT Header=C2=A0 A JSON object that is a component of a=
 JWT. It denotes the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cryptographic operations applied to th=
e JWT.=C2=A0 ...
=C2=A0
=C2=A0=C2=
=A0=C2=A0 JWT Claims Set=C2=A0 A JSON object containing a set of claims.=C2=
=A0 ...
=C2=A0
This also gets rid o=
f the use of the "A string representing a JSON object..."

which I find confusing and potentially misleading (bec=
ause it is actually "a Base64url encoding of a JSON object").<=
/u>
=C2=A0


Aah =E2=80=93 I now see that this is=
 the real misunderstanding.=C2=A0 The =E2=80=9Cstring representing a JSON o=
bject=E2=80=9D is not the base64url encoded form =E2=80=93 it=E2=80=99s the=
 string representation that=E2=80=99s parseable into a JSON object.=C2=A0 F=
or
 instance, it could be a string such as {=E2=80=9Calg=E2=80=9D:=E2=80=9DRS2=
56=E2=80=9D} =E2=80=93 not the base64url encoded version of that string.=C2=
=A0 The reason for the syntactic construction =E2=80=9Cstring representing =
a JSON object=E2=80=9D is that its string representation is distinct from t=
he abstract JSON object
 itself.=C2=A0 If I insert whitespace after the colon in the string {=E2=80=
=9Calg=E2=80=9D:=E2=80=9DRS256=E2=80=9D} it would parse to an equivalent JS=
ON object but it would be a different string representation.=C2=A0 It=E2=80=
=99s the string representation that is actually operated on by the JWT/JWS/=
JWE operations.


=C2=A0
I=E2=80=99ll try to make this clearer in the spec.=

=C2=A0
UTF-8=
:

=C2=A0
UTF-8 is mentioned in lots of places. It could p=
robably be stated once up near

the beginning of the spec that all the JSON text is UT=
F-8 encoded, and all the

JSON strings are UTF-8 encoded.
=C2=A0


I=E2=80=99ll see if I can figure out=
 how to do this without introducing ambiguity.
=C2=A0
Semantics, profiles and relatio=
nship to SAML:


=C2=A0
The spec does not define any overall JWT sema=
ntics (i.e., what any given JWT

/means/). Semantics are only defined in context of eac=
h individual Reserved

Claim Name.
=C2=A0
Thus any application of JWTs will need to profile the JWT spec: specif=
ying the

claim set(s) contents, and the overall semantics of th=
e resultant JWT(s).=C2=A0 This

is not explicitly explained in the JWT spec.=

=C2=A0


Can you suggest some language you=E2=
=80=99d like to see added about this?
=C2=A0
In=
 terms of SAML, Appendix B should refer to SAML assertions rather than saml

tokens. Also, I'm not sure SAML assertions inheren=
tly have more expressivity

than JWTs. They do have more pre-defined structure and=
 semantics.
=C2=A0


OK
=C2=A0
Syntactically, it=
 seems one can encode pretty much anything in whatever amount

in a JWT (one can do the same with SAML assertions), a=
nd thus theoretically JWTs

could be used to accomplish the same things as SAML as=
sertions.
=C2=A0
Semantically, SAML=
 assertions are explicitly statements made by a system entity

about a subject. But by default, a JWT is empty, and h=
as no semantics (this

isn't stated explicitly). All semantics defined in=
 the JWT spec are particular

to individual reserved claims, but all reserved claims=
 are optional. Thus an

application of JWTs to use cases also apropos for SAML=
 assertions will require

arguably more profiling than that needed to apply SAML=
 assertions.
=C2=A0


All true.=C2=A0 However once you add=
 an issuer and a principal, then you=E2=80=99re back to the JWT being state=
ments made by an entity about a subject.=C2=A0 Again, if there is language =
you believe should be added in that regard,
 please let me know.=C2=A0 (BTW, one such usage profile is in 
http://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-03.=C2=A0 Anothe=
r is in 
http://openid.net/specs/openid-connect-messages-1_0.html#id_token.)<=
/u>
=C2=A0<=
/span>
The token size & complexity comparison seems nominally fin=
e.


=C2=A0
Some detailed-but-rough comments and musings =
on portions of the spec as I was

reading through it...
=C2=
=A0
> 2. Terminology
=C2=A0
terminology is not alphabetised!
=C2=A0=



No, it=E2=80=99s in a top-down descr=
iptive order.=C2=A0 Is there a requirement in IETF specs that the terminolo=
gy be alphabetized?
=C2=
=A0

"claim", "claims", "token" should be defined =
in terminology
=C2=A0


I=E2=80=99ll add a definition for =
=E2=80=9Cclaim=E2=80=9D.=C2=A0 =E2=80=9Ctoken=E2=80=9D should actually prob=
ably become =E2=80=9Csecurity token=E2=80=9D, with a definition of the term=
.
=C2=A0=



suggestion:
=C2=A0
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 Claim:=C2=A0 an assertion of something as a fact. Here, =
claims are
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 name and value pairs, consisting of a Claim Name and a=



=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Claim Value.<=
/u>
=C2=A0
=C2=A0
>=C2=A0=
=C2=A0=C2=A0 JSON Web Token (JWT)
=C2=A0<=
/p>
=C2=A0=C2=A0 is jwt always a "string" or is it string (only=
) when it's been serialized

into one?
=C2=A0


It=E2=80=99s always the string repre=
sentation of the serialized parts.
=C2=A0
>=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 A string representing a set of claims as a JSON


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 object that is digitally signed=
 or MACed and/or encrypted.
=C2=A0
=
=C2=A0=C2=A0 is it more that it's a set of claims encoded as a JSON obj=
ect
=C2=A0=C2=A0 that is string-serialized?


=C2=A0


No, per my earlier comments 

=C2=A0
=C2=A0=C2=A0 is it /not/ a JWT by definition if it is not ((signe=
d or unmac'd) and/or

encrypted) ?=C2=A0=C2=A0 No, because there are Plainte=
xt JWTs, but they aren't in

terminology (probably should be).
=
=C2=A0


Good catch
<=
div class=3D"im">
=C2=A0
=C2=A0=C2=
=A0 "parts" in JWT definition is unclear
=C2=
=A0=C2=A0=C2=A0=C2=A0 are "parts" json objects or arrays unto the=
mselves ?


=C2=A0


The parts are all base64url encoded =
values.=C2=A0 I=E2=80=99ll review this terminology usage to see if it can b=
e clarified.
=C2=A0


=C2=A0=C2=A0 the definition assumes knowledge that's presented later=
. perhaps needs fwd
=C2=A0=C2=A0 reference(s), or perha=
ps better is to not present as much technical detail
=
=C2=A0=C2=A0 in the definitions.


=C2=A0


I=E2=80=99ll review
=C2=A0
>=C2=A0=C2=A0=C2=
=A0 JWT Claims Set
=C2=A0
=C2=A0=C2=
=A0 similar comments as to JSON Web Token (JWT)


=C2=A0
=C2=A0=C2=A0 the definition says how it is en=
coded and encrypted, but not how claims are

mapped into a JSON object
=
=C2=A0
=C2=A0
should probably be simply:
=C2=A0
=C2=A0=C2=A0=C2=A0 JWT Claims=
 Set: A set of claims expressed as a JSON object, where each<=
/p>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 claim is an object member (i.e., a =
name/value pair). A claim may have
=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 a JWT Claims Set as a value.
=
=C2=A0


I=E2=80=99ll look into moving the de=
finition in this direction.=C2=A0 What you=E2=80=99re missing in the above,=
 though, is the distinction between the string representing the JSON object=
 and the abstract JSON object.=C2=A0 We want
 the former.
=C2=A0<=
/u>
>=C2=A0=C2=A0=C2=A0 Claim Name=C2=A0 The name of a member of t=
he JSON object representing a
>=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 JWT Claims Set.

=C2=A0
should probably be simply:
<=
u>=C2=A0
=C2=A0=C2=A0=C2=A0 Claim Name=C2=A0 The name port=
ion of a claim, expressed as a JSON object member
=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 name.

=C2=A0
=C2=A0
>=C2=A0=C2=A0=C2=
=A0 Claim Value=C2=A0 The value of a member of the JSON object representing=
 a
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 JWT Claims =
Set.
=C2=A0
should probably be simp=
ly:


=C2=A0
=C2=A0=C2=A0=C2=A0 Claim Value=C2=A0 The valu=
e portion of a claim, expressed as a JSON object member
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 value.
=C2=
=A0


I=E2=80=99ll look into moving the de=
finitions in this direction.=C2=A0

=C2=A0
&g=
t; 3. JSON Web Token (JWT) Overview
=C2=A0
>=C2=A0=C2=A0=C2=A0 The bytes of the UTF-8 representation of the=
 JWT Claims Set are


>=C2=A0=C2=A0=C2=A0 digitally signed or MACed in the manner described=
 in JSON Web
>=C2=A0=C2=A0=C2=A0 Signature (JWS) [JW=
S] and/or encrypted in the manner described in
>=C2=
=A0=C2=A0=C2=A0 JSON Web Encryption (JWE) [JWE].


=C2=A0
s/ and/or encrypted / or encrypted and signed=
 /
=C2=A0


I think you mean =E2=80=9Cencrypted =
and integrity protected=E2=80=9D rather than =E2=80=9Cencrypted and signed=
=E2=80=9D, right?
=C2=
=A0
>=C2=A0=C2=A0=C2=A0 The contents of the JWT Header desc=
ribe the cryptographic operations


>=C2=A0=C2=A0=C2=A0 applied to the JWT Claims Set. If the JWT Header =
is a JWS Header, the
>=C2=A0=C2=A0=C2=A0 claims are =
digitally signed or MACed.=C2=A0 If the JWT Header is a JWE
>=C2=A0=C2=A0=C2=A0 Header, the claims are encrypted.=



=C2=A0
What if a JWT is signed AND encrypted?=C2=A0 =
Hm, from my looking at JWS and JWE

specs, it seems that in that case one uses JWE because=
 that encompasses both

encrypt & sign.
=C2=A0<=
u>


No, actually JWE just provides an in=
tegrity check =E2=80=93 not a signature.=C2=A0 If you want a signature, you=
 need to use JWS.=C2=A0 They can (and often are) used in a nested fashion.<=
u>



=C2=A0
>=C2=A0=C2=A0=C2=A0 A JW=
T is represented as a JWS or JWE.=C2=A0 The number of parts is
>=C2=A0=C2=A0=C2=A0 dependent upon the representation of the res=
ulting JWS or JWE.

=C2=A0
Does the above mean to say..
=C2=A0
=C2=A0=C2=A0=C2=A0 A JWT consists of a JWS or J=
WE object, which in turn conveys the JWT
=C2=A0=C2=A0=
=C2=A0 Claims Set. In the case of a JWS, the JWT Claims Set is the JWS


=C2=A0=C2=A0=C2=A0 Payload. In the case of a JWE, the JWT Claims Set is =
the input
=C2=A0=C2=A0=C2=A0 Plaintext.
=C2=A0


Yes.=C2=A0 Although this is missing =
the fact that nested signing/encryption may be employed.
=C2=A0
> 4. JWT Claims=



>
>
>=C2=A0=C2=A0=C2=A0=
 The JWT Claims Set represents a JSON object whose members are the
>=C2=A0=C2=A0=C2=A0 claims conveyed by the JWT.=C2=A0 The Cl=
aim Names within this object MUST


>=C2=A0=C2=A0=C2=A0 be unique; JWTs with duplicate Claim Names MUST b=
e rejected.
=C2=A0
does the above m=
ean to say claim names must be unique amongst the set of claim

names within any given JWT Claims Set ?=C2=A0 If so, t=
hat's only implied by the above

but should be stated explicitly; as it is, the above i=
s ambiguous.
=C2=A0


OK
=C2=A0
> 4.2. Public Claim Names<=
u>
>
>
>=C2=A0=
=C2=A0=C2=A0 Claim names can be defined at will by those using JWTs.=C2=A0 =
However, in


=C2=A0
s/Claim names/Public claim names/
=C2=A0
>=C2=A0=C2=A0=C2=A0 order to prevent=
 collisions, any new claim name SHOULD either be
>=
=C2=A0=C2=A0=C2=A0 registered in the IANA JSON Web Token Claims registry Se=
ction 9.1 or


>=C2=A0=C2=A0=C2=A0 be a URI that contains a Collision Resistant Name=
space.
=C2=A0
=C2=A0<=
/p>
why should a claim name be a URI if I wish to make use of Collision R=
esistant

Namespaces?=C2=A0 For example, if I simply use say UUI=
Ds as claim names..
=C2=A0
=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 {"iss":"joe",
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "3005fa05-e76c-4994-bbc9-65b2=
ace2305c":"foo"}


=C2=A0
..it will be universally unique provided I mi=
nted it appropriately (no URI

syntax is needed).
=C2=A0


Fair enough.=C2=A0 I=E2=80=99ll try =
to generalize the language.
=C2=A0
> 4.3. Pri=
vate Claim Names


>
>
>=C2=A0=C2=A0=C2=A0=
 A producer and consumer of a JWT may agree to any claim name that is
>=C2=A0=C2=A0=C2=A0 not a Reserved Name Section 4.1 or a =
Public Name Section 4.2.=C2=A0 Unlike


>=C2=A0=C2=A0=C2=A0 Public Names, these private names are subject to =
collision and should
>=C2=A0=C2=A0=C2=A0 be used wit=
h caution.
=C2=A0
it seems private =
claim names are only subject to collision if the implementers

don't make appropriate use of Collision Resistant =
Namespaces, i.e. they "can be"

subject to collision.
=C2=
=A0


True
=C2=A0
the above two sections use "p=
ublic" and "private" as distinguishing factors, but

it seems to me the distinguishing factor (given how th=
e above is written) is

more whether Collision Resistant Namespaces are employ=
ed or not.
=C2=A0


Yes, although using a collision resi=
stant namespace effectively makes them public, as we=E2=80=99re using the t=
erm
=C2=A0<=
u>


An implied aspect of public claim names seems to be that it is assumed t=
hat they

are publicly listed/documented/leaked, thus the "=
public" moniker, and hence

ought to be universally unique as a matter of course.<=
u>
=C2=A0
and "private" ones=
 seem to be assumed to be obfuscated to all but the agreeing

parties?=C2=A0 Or they are "private" in only=
 the sense that they are created in the

context of a private arrangement?
=
=C2=A0


Private in that they are created in =
the context of a private arrangement.=C2=A0 I=E2=80=99ll try to clarify thi=
s point.=C2=A0 Facebook could define how they=E2=80=99re going to use the =
=E2=80=9Cid=E2=80=9D claim very publicly, and yet it would still
 be a private claim if not registered with IANA.
=C2=A0
>
>=
 7. Rules for Creating and Validating a JWT
>=



>
>=C2=A0=C2=A0=C2=A0 To create a JWT, one MUS=
T perform these steps.=C2=A0 The order of the
>=C2=
=A0=C2=A0=C2=A0 steps is not significant in cases where there are no depend=
encies
>=C2=A0=C2=A0=C2=A0 between the inputs and ou=
tputs of the steps.


>
>=C2=A0=C2=A0=C2=A0 1.=C2=A0 Create a JWT Cl=
aims Set containing the desired claims.=C2=A0 Note that
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 white space is explicitly a=
llowed in the representation and no

>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 canonicalization is performe=
d before encoding.
=C2=A0
I presume=
 the rationale for allowing white space is that JSON objects are

unordered (and can contain arbitrary whitespace), thus=
 simple buffer-to-buffer

comparisons between serialized objects cannot be relia=
bly performed.=C2=A0 If so this

should be explicitly stated.
=C2=A0


Actually, it=E2=80=99s to avoid cano=
nicalization.=C2=A0 I=E2=80=99ll reread the spec to see if we=E2=80=99ve st=
ated that clearly or not.
=C2=A0


It seems that member/value-by-member/value comparisons must always be do=
ne, by

parsing the JSON objects and extracting all members an=
d values, this should be

stated explicitly in the spec.
=
=C2=A0
I found meager jwt comparison instructions at the v=
ery end of Section 7. it

should probably be its own subsection. It should proba=
bly explicitly say that

JWTs need to be parsed into their constituent componen=
ts, and the latter must be

individually examined/compared.
=C2=A0


We tried to cover this in the end of=
 section 7, starting with the sentence =E2=80=9CProcessing a JWT inevitably=
 requires comparing known strings to values in the token=E2=80=9D, which sa=
ys how these comparisons must be performed.=C2=A0
 I agree that this should become its own subsection.=C2=A0 I don=E2=80=99t =
understand your remark about constituent components.=C2=A0 Can you clarify?=

=C2=A0<=
/u>
>=C2=A0=C2=A0=C2=A0 Comparisons between JSON strings an=
d other Unicode strings MUST be


>=C2=A0=C2=A0=C2=A0 performed as specified below:
=C2=A0
this comparison algorithm seems to be attemptin=
g to allow for comparison of

UTF-8 encoded JSON strings with other unicode strings =
in any of the unicode

encoding formats, but only implies that; it should be =
stated.
=C2=A0


Good
=C2=A0
><=
/u>
>=C2=A0=C2=A0=C2=A0 1.=C2=A0 Remove any JSON applied escaping =
to produce an array of Unicode


>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code points.
=C2=A0
I don't think (1) is correct.=C2=A0 =
A JSON string is by default encoded in UTF-8. A

UTF-8 encoded string is not "an array of Unicode =
code points" (its a sequence of

code units, which must be decoded into code points), i=
 think a step is missing

here..
=C2=A0
=
=C2=A0=C2=A0=C2=A0 1.=C2=A0 Remove any JSON escaping from the input JSON st=
ring.
=C2=A0
=C2=A0=C2=A0=C2=A0 1.a=
=C2=A0 convert the string into a sequence of unicode code points.=



=C2=A0


How about =E2=80=9CRemove any JSON e=
scaping from the input JSON string and convert the string into a sequence o=
f Unicode code points=E2=80=9D?
<=
p>=C2=A0


..and then compare code point-by-code point. This overall algorithm /see=
ms/ ok,

but I'm not sure, it seems there's rationale t=
hat's not expressed, eg for

excluding use of Unicode Normalization [USA15]. Also t=
he alg is incomplete in

that it doesn't stipulate converting the "oth=
er unicode string" into a sequence

of code points.
=C2=A0


Fair enough
=

=C2=A0
> 10. Security Considera=
tions
>
>
>=C2=A0=C2=A0=C2=A0 All of the security issues faced by any cryptograph=
ic application


>=C2=A0=C2=A0=C2=A0 must be faced by a JWT/JWS/JWE/JWK agent.=C2=A0 A=
mong these issues are
>=C2=A0=C2=A0=C2=A0 protecting=
 the user's private key, preventing various attacks, and<=
/p>
>=C2=A0=C2=A0=C2=A0 helping the user avoid mistakes such as inadve=
rtently encrypting a


>=C2=A0=C2=A0 =C2=A0message for the wrong recipient.=C2=A0 The entire=
 list of security
>=C2=A0=C2=A0=C2=A0 considerations=
 is beyond the scope of this document, but some
>=C2=
=A0=C2=A0=C2=A0 significant concerns are listed here.


>
>=C2=A0=C2=A0=C2=A0 All the security conside=
rations in the JWS specification also apply
>=C2=A0 =
=C2=A0=C2=A0to JWT, as do the JWE security considerations when encryption i=
s
>=C2=A0=C2=A0=C2=A0 employed.=C2=A0 In particular,=
 the JWS JSON Security Considerations and


>=C2=A0=C2=A0=C2=A0 Unicode Comparison Security Considerations apply =
equally to the JWT
>=C2=A0=C2=A0=C2=A0 Claims Set in=
 the same manner that they do to the JWS Header.
>
=C2=A0


dunno if you can get away with sec cons wholly in other docs, and I'=
m not sure

it's appropriate given that JWTs are a profile of =
JWE or JWS.
=C2=A0


That was the approach that Sean had =
suggested.=C2=A0 If there other things you think we should specifically add=
, however, please let me know.
=C2=A0


above needs editorial polish -- there aren't any=C2=A0 "signifi=
cant concerns"

actually listed here.
=C2=
=A0


True enough
=

=C2=A0
---
end=

=C2=A0
=C2=A0
=
_______________________________________________


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








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
Nat Saki=
mura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



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





--047d7b603c1e94e64204d2019126--

From tonynad@microsoft.com  Sat Dec 29 16:29:18 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E353521F8846 for ; Sat, 29 Dec 2012 16:29:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.15
X-Spam-Level: 
X-Spam-Status: No, score=-0.15 tagged_above=-999 required=5 tests=[AWL=-0.683,  BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la9DKXg1C0LD for ; Sat, 29 Dec 2012 16:29:17 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.30]) by ietfa.amsl.com (Postfix) with ESMTP id BADF321F8843 for ; Sat, 29 Dec 2012 16:29:17 -0800 (PST)
Received: from BY2FFO11FD003.protection.gbl (10.1.15.204) by BY2FFO11HUB003.protection.gbl (10.1.14.156) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 00:29:15 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD003.mail.protection.outlook.com (10.1.14.125) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 30 Dec 2012 00:29:15 +0000
Received: from db3outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 30 Dec 2012 00:29:14 +0000
Received: from mail57-db3-R.bigfish.com (10.3.81.253) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Sun, 30 Dec 2012 00:29:11 +0000
Received: from mail57-db3 (localhost [127.0.0.1])	by mail57-db3-R.bigfish.com (Postfix) with ESMTP id 57E26400A1	for ; Sun, 30 Dec 2012 00:29:11 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -21
X-BigFish: PS-21(zzbb2dI98dI9371Ic89bhd6eah542I1432I1447Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275bh8275dh8275ch1033IL177df4h17326ahz31h2a8h668h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail57-db3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; LANG:en; 
Received: from mail57-db3 (localhost.localdomain [127.0.0.1]) by mail57-db3 (MessageSwitch) id 13568273491567_13665; Sun, 30 Dec 2012 00:29:09 +0000 (UTC)
Received: from DB3EHSMHS004.bigfish.com (unknown [10.3.81.237])	by mail57-db3.bigfish.com (Postfix) with ESMTP id E7EC038026C; Sun, 30 Dec 2012 00:29:08 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by DB3EHSMHS004.bigfish.com (10.3.87.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 30 Dec 2012 00:29:06 +0000
Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.245.2; Sun, 30 Dec 2012 00:29:04 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 00:28:44 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Sun, 30 Dec 2012 00:28:25 +0000
From: Anthony Nadalin 
To: David Chadwick , Mike Jones 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYXPokKfJ1TsWSvG7/OFVVl60vgAR1McAAB7o9hA=
Date: Sun, 30 Dec 2012 00:28:25 +0000
Message-ID: <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com>
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk>
In-Reply-To: <50DEBAF4.6040700@kent.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.255.156.132]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com
X-FOPE-CRA-Verdict: 157.56.240.21$kent.ac.uk%0%1%duplicatedomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com%False%False%0$
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%KENT.AC.UK$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(51914002)(24454001)(377454001)(51704002)(13464002)(6806001)(23676001)(47776002)(51856001)(74502001)(44976002)(46102001)(16676001)(31966008)(77982001)(47976001)(5343655001)(5343645001)(33646001)(15395725002)(5343635001)(50986001)(47736001)(59766001)(49866001)(56816002)(4396001)(53806001)(54356001)(50466001)(56776001)(74662001)(47446002)(550184003)(54316002)(76482001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB003; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 071156160B
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 00:29:19 -0000

QnkgZGVmaW5pdGlvbiBhIGNsYWltIGlzIGFsd2F5cyBpbiBkb3VidCB0aHVzIGl0IHdvdWxkIG5v
dCBjYWxsIGl0IGEgY3JlZGVudGlhbCB1bnRpbCBpdCBpcyB2ZXJpZmllZA0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm9h
dXRoLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBDaGFkd2ljaw0KU2VudDog
U2F0dXJkYXksIERlY2VtYmVyIDI5LCAyMDEyIDE6NDIgQU0NClRvOiBNaWtlIEpvbmVzDQpDYzog
SUVURiBvYXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRm
LW9hdXRoLWpzb24td2ViLXRva2VuLTA1DQoNCklmIGEgY2xhaW0gcHJvdmlkZXMgcHJvb2YgdGhl
biBJIHdvdWxkIGNhbGwgaXQgYSBjcmVkZW50aWFsIG5vdCBhIGNsYWltDQoNCkRhdmlkDQoNCk9u
IDI5LzEyLzIwMTIgMDE6MTEsIE1pa2UgSm9uZXMgd3JvdGU6DQo+IEkgZm91bmQgdGhlIFguMTI1
MiBkZWZpbml0aW9uLiAgSXQgaXM6DQo+DQo+ICo2LjE4IGNsYWltICpbYi1PRURdOiBUbyBzdGF0
ZSBhcyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBiZWluZyBhYmxlIA0KPiB0byBnaXZlIHByb29m
Lg0KPg0KPiBUaGF0IHNlZW1zIGJvdGggYSBiaXQgdmFndWUsIGFuZCBhY3R1YWxseSBpbmNvcnJl
Y3QsIGFzIHRoZSBKV1QgbWF5IA0KPiBpbmNsdWRlIHByb29mIG9mIHRoZSB2ZXJhY2l0eSBvZiB0
aGUgY2xhaW0uICBQbGVhc2Ugc2VlIHRoZSB1cGRhdGVkIA0KPiBKV1QgZHJhZnQgZm9yIGEgaG9w
ZWZ1bGx5IG1vcmUgdXNlZnVsIOKAnENsYWlt4oCdIGRlZmluaXRpb24uDQo+DQo+ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0
IA0KPiB3aXNoZXMsDQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQo+DQo+ICpGcm9tOipNaWtlIEpvbmVzDQo+
ICpTZW50OiogU3VuZGF5LCBEZWNlbWJlciAyMywgMjAxMiAxOjAzIFBNDQo+ICpUbzoqIEplZmYg
SG9kZ2VzOyBOYXQgU2FraW11cmENCj4gKkNjOiogSUVURiBvYXV0aCBXRw0KPiAqU3ViamVjdDoq
IFJFOiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0w
NQ0KPg0KPiBXaGF0IGlzIHRoZSBYLjEyNTIgZGVmaW5pdGlvbj8NCj4NCj4gLS0gTWlrZQ0KPg0K
PiAqRnJvbToqIE5hdCBTYWtpbXVyYQ0KPiAqU2VudDoqIOKAjkRlY2VtYmVy4oCOIOKAjjIz4oCO
LCDigI4yMDEyIOKAjjEw4oCOOuKAjjA54oCOIOKAjkFNDQo+ICpUbzoqID1KZWZmSA0KPiAqQ0M6
KiBNaWtlIEpvbmVzLCBJRVRGIG9hdXRoIFdHDQo+ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10g
cmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1DQo+DQo+IFJlIGRlZmlu
aXRpb24gb2YgJ2NsYWltJywgYXMgSldUIGlzIHN1cHBvc2VkIHRvIGJlIGdlbmVyaWMsIGl0IG1h
eSBiZSANCj4gYmV0dGVyIHRvIGdvIHdpdGggdGhlIGRlZmluaXRpb24gb2YgWC4xMjUyIHJhdGhl
ciB0aGFuIE9JREMuDQo+DQo+ID1uYXQgdmlhIGlQaG9uZQ0KPg0KPiBEZWMgMjQsIDIwMTIgMjo0
MuOAgT1KZWZmSCA8SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20gDQo+IDxtYWlsdG86SmVm
Zi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+PiDjga7jg6Hjg4Pjgrvjg7zjgrg6DQo+DQo+Pg0K
Pj4gPiBUaGFua3MgZm9yIHRoZSByZXBsaWVzLCBKZWZmLiAgVGhleSBtYWtlIHNlbnNlLiAgUGFy
dGljdWxhcmx5LCANCj4+ID4gdGhhbmtzIGZvciB0aGUgIkpTT04gVGV4dCBPYmplY3QiIHN1Z2dl
c3Rpb24uDQo+Pg0KPj4gd2VsY29tZSwgZ2xhZCB0aGV5IG1hZGUgc29tZSBzZW5zZS4NCj4+DQo+
PiBzaW1pbGFybHksIGlmIG9uZSBlbXBsb3lzIEpTT04gYXJyYXlzLCBJJ2QgZGVmaW5lIGEgIkpT
T04gdGV4dCBhcnJheSIuDQo+Pg0KPj4NCj4+ID4gRm9yIHRoZSAiY2xhaW1zIiBkZWZpbml0aW9u
LCBJJ20gYWN0dWFsbHkgcHJvbmUgdG8gZ28gd2l0aCANCj4+ID5kZWZpbml0aW9ucyBiYXNlZCAg
b24gdGhvc2UgaW4NCj4+ID5odHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29ubmVjdC1t
ZXNzYWdlcy0xXzAtMTMuaHRtbCN0ZXJtaW5vbA0KPj4gPm9neS0NCj4+ID4gc3BlY2lmaWNhbGx5
Og0KPj4gPg0KPj4gPiBDbGFpbQ0KPj4gPiBBIHBpZWNlIG9mIGluZm9ybWF0aW9uIGFib3V0IGFu
IEVudGl0eSB0aGF0IGEgQ2xhaW1zIFByb3ZpZGVyIA0KPj4gPiBhc3NlcnRzIGFib3V0IHRoYXQg
RW50aXR5Lg0KPj4gPiBDbGFpbXMgUHJvdmlkZXINCj4+ID4gQSBzeXN0ZW0gb3Igc2VydmljZSB0
aGF0IGNhbiByZXR1cm4gQ2xhaW1zIGFib3V0IGFuIEVudGl0eS4NCj4+ID4gRW5kLVVzZXINCj4+
ID4gQSBodW1hbiB1c2VyIG9mIGEgc3lzdGVtIG9yIHNlcnZpY2UuDQo+PiA+IEVudGl0eQ0KPj4g
PiBTb21ldGhpbmcgdGhhdCBoYXMgYSBzZXBhcmF0ZSBhbmQgZGlzdGluY3QgZXhpc3RlbmNlIGFu
ZCB0aGF0IGNhbiANCj4+ID4gYmUgaWRlbnRpZmllZCBpbiBjb250ZXh0LiBBbiBFbmQtVXNlciBp
cyBvbmUgZXhhbXBsZSBvZiBhbiBFbnRpdHkuDQo+Pg0KPj4gd2VsbCwgaXQgc2VlbXMgdG8gbWUs
IGdpdmVuIHRoZSBtYW5uZXIgaW4gd2hpY2ggdGhlIEpXVCBzcGVjIGlzIA0KPj4gd3JpdHRlbiwg
b25lIGNhbiBtYWtlIHRoZSBjYXNlIHRoYXQgSldUIGNsYWltcyBpbiBnZW5lcmFsIGFyZW4ndCAN
Cj4+IG5lY2Vzc2FyaWx5IGFib3V0IGFuIEVudGl0eSAoYXMgdGhlIGxhdHRlciB0ZXJtIGlzIHVz
ZWQgaW4gdGhlIA0KPj4gY29udGV4dCBvZiB0aGUgT3BlbklEIENvbm5lY3Qgc3BlY3MpLCByYXRo
ZXIgdGhleSdyZSBpbiBnZW5lcmFsICANCj4+IHNpbXBseSBhc3NlcnRpb25zIGFib3V0IHNvbWV0
aGluZyhzKS4gdGhpcyBpcyBiZWNhdXNlIGFsbCBwcmUtZGVmaW5lZA0KPiBKV1QgY2xhaW0gdHlw
ZXMgYXJlIG9wdGlvbmFsIGFuZCBhbGwgSldUIHNlbWFudGljcyBhcmUgbGVmdCB1cCB0byANCj4g
c3BlY3MgdGhhdCBwcm9maWxlIChha2EgcmUtdXNlKSB0aGUgSldUIHNwZWMuDQo+Pg0KPj4gSFRI
LA0KPj4NCj4+ID1KZWZmSA0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+T0F1dGhAaWV0Zi5vcmcg
PG1haWx0bzpPQXV0aEBpZXRmLm9yZz4gDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3Jn
DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWlsaW5n
IGxpc3QNCk9BdXRoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoDQo=


From sakimura@gmail.com  Sat Dec 29 20:03:49 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA3021F88B2 for ; Sat, 29 Dec 2012 20:03:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.962
X-Spam-Level: 
X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=0.636,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pTSpbndMS77 for ; Sat, 29 Dec 2012 20:03:47 -0800 (PST)
Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by ietfa.amsl.com (Postfix) with ESMTP id F235721F88A8 for ; Sat, 29 Dec 2012 20:03:46 -0800 (PST)
Received: by mail-ea0-f181.google.com with SMTP id k14so4706708eaa.12 for ; Sat, 29 Dec 2012 20:03:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YGVP83/Z9k7wfcllJKPtCd9ipMqfLkHUTdm2gMLfy5E=; b=XybS6wJ9Jlr7xY2Rp9GRDq2Xj1k/xcmfjDI+6YZ+waHN+ySwp2jdUAZTjRPObXD285 8p3sst9ja7JTdEwe/6tyWOxuzfuimoiNyVQvPoIexde4tXVQ3EivfbKf/2bP/QwppFLx egUsqutN9xiWQ1TchvryHV3Xg/WFI3p0xQFhM4z0a3QETMSGwrVxMD0A8oerJeaqD47B kha+m1dREmdwbXPxXa13LQQKowamEFS3H+KcM4YAh8FurBHbGW9yJGDw4vxHcbkidIu5 D0Olcz89p1+Lxtce15c30WNN0dr04K4dWNh0hI/yJ9J1LGDX8XKdjXfm9bJIxnIcpxXv +KKQ==
MIME-Version: 1.0
Received: by 10.14.206.197 with SMTP id l45mr100295811eeo.17.1356840226155; Sat, 29 Dec 2012 20:03:46 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Sat, 29 Dec 2012 20:03:45 -0800 (PST)
In-Reply-To: <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com>
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk> <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com>
Date: Sun, 30 Dec 2012 13:03:45 +0900
Message-ID: 
From: Nat Sakimura 
To: Anthony Nadalin 
Content-Type: multipart/alternative; boundary=047d7b34413cb26d9604d209fb4a
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 04:03:49 -0000

--047d7b34413cb26d9604d209fb4a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Tony,

So do you agree with the following definition in -06? Or prefer X.1252
definition?

Claim  A piece of information asserted about a subject.  Here, Claims
      are represented name/value pairs, consisting of a Claim Name and a
      Claim Value.


Mike:

Regarding the ordering of the terms in terminology, you should either use
the dependency chain or alphabetic order. (Former is more desirable in my
point of view.) However, as it stands, it is none of those. For example,
the term "claim" appears in the definition of JWT, which is the first term
in the terminology, without having been defined. If you do not mind, I will
reorder them and send it to you.

Nat

On Sun, Dec 30, 2012 at 9:28 AM, Anthony Nadalin wro=
te:

> By definition a claim is always in doubt thus it would not call it a
> credential until it is verified
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of
> David Chadwick
> Sent: Saturday, December 29, 2012 1:42 AM
> To: Mike Jones
> Cc: IETF oauth WG
> Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>
> If a claim provides proof then I would call it a credential not a claim
>
> David
>
> On 29/12/2012 01:11, Mike Jones wrote:
> > I found the X.1252 definition.  It is:
> >
> > *6.18 claim *[b-OED]: To state as being the case, without being able
> > to give proof.
> >
> > That seems both a bit vague, and actually incorrect, as the JWT may
> > include proof of the veracity of the claim.  Please see the updated
> > JWT draft for a hopefully more useful =E2=80=9CClaim=E2=80=9D definitio=
n.
> >
> >                                                              Best
> > wishes,
> >
> >                                                              -- Mike
> >
> > *From:*Mike Jones
> > *Sent:* Sunday, December 23, 2012 1:03 PM
> > *To:* Jeff Hodges; Nat Sakimura
> > *Cc:* IETF oauth WG
> > *Subject:* RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
> >
> > What is the X.1252 definition?
> >
> > -- Mike
> >
> > *From:* Nat Sakimura
> > *Sent:* =E2=80=8EDecember=E2=80=8E =E2=80=8E23=E2=80=8E, =E2=80=8E2012 =
=E2=80=8E10=E2=80=8E:=E2=80=8E09=E2=80=8E =E2=80=8EAM
> > *To:* =3DJeffH
> > *CC:* Mike Jones, IETF oauth WG
> > *Subject:* Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
> >
> > Re definition of 'claim', as JWT is supposed to be generic, it may be
> > better to go with the definition of X.1252 rather than OIDC.
> >
> > =3Dnat via iPhone
> >
> > Dec 24, 2012 2:42=E3=80=81=3DJeffH  > > =E3=81=AE=E3=83=A1=E3=83=83=E3=
=82=BB=E3=83=BC=E3=82=B8:
> >
> >>
> >> > Thanks for the replies, Jeff.  They make sense.  Particularly,
> >> > thanks for the "JSON Text Object" suggestion.
> >>
> >> welcome, glad they made some sense.
> >>
> >> similarly, if one employs JSON arrays, I'd define a "JSON text array".
> >>
> >>
> >> > For the "claims" definition, I'm actually prone to go with
> >> >definitions based  on those in
> >> >http://openid.net/specs/openid-connect-messages-1_0-13.html#terminol
> >> >ogy-
> >> > specifically:
> >> >
> >> > Claim
> >> > A piece of information about an Entity that a Claims Provider
> >> > asserts about that Entity.
> >> > Claims Provider
> >> > A system or service that can return Claims about an Entity.
> >> > End-User
> >> > A human user of a system or service.
> >> > Entity
> >> > Something that has a separate and distinct existence and that can
> >> > be identified in context. An End-User is one example of an Entity.
> >>
> >> well, it seems to me, given the manner in which the JWT spec is
> >> written, one can make the case that JWT claims in general aren't
> >> necessarily about an Entity (as the latter term is used in the
> >> context of the OpenID Connect specs), rather they're in general
> >> simply assertions about something(s). this is because all pre-defined
> > JWT claim types are optional and all JWT semantics are left up to
> > specs that profile (aka re-use) the JWT spec.
> >>
> >> HTH,
> >>
> >> =3DJeffH
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >>OAuth@ietf.org 
> >>https://www.ietf.org/mailman/listinfo/oauth
> >
> >
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>



--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

Tony,=C2=A0

So do you agree with the following definitio=
n in -06? Or prefer X.1252 definition?=C2=A0

=
Claim  A piece of information asserted about a subject.  Here, Claims
      are represented name/value pairs, consisting of a Claim Name and a
      Claim Value.

Mike:=C2=A0

Regarding the =
ordering of the terms in terminology, you should either use the dependency =
chain or alphabetic order. (Former is more desirable in my point of view.) =
However, as it stands, it is none of those. For example, the term "cla=
im" appears in the definition of JWT, which is the first term in the t=
erminology, without having been defined. If you do not mind, I will reorder=
 them and send it to you.=C2=A0



Nat

On Sun, Dec 3=
0, 2012 at 9:28 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:


By definition a claim is always in doubt thu=
s it would not call it a credential until it is verified




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

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

Sent: Saturday, December 29, 2012 1:42 AM

To: Mike Jones

Cc: IETF oauth WG


Subject: Re: [OAUTH-WG] revie=
w: draft-ietf-oauth-json-web-token-05



If a claim provides proof then I would call it a credential not a claim



David



On 29/12/2012 01:11, Mike Jones wrote:

> I found the X.1252 definition. =C2=A0It is:

>

> *6.18 claim *[b-OED]: To state as being the case, without being able
> to give proof.

>

> That seems both a bit vague, and actually incorrect, as the JWT may
> include proof of the veracity of the claim. =C2=A0Please see the updat=
ed

> JWT draft for a hopefully more useful =E2=80=9CClaim=E2=80=9D definiti=
on.

>

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Be=
st

> wishes,

>

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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

>

> *From:*Mike Jones

> *Sent:* Sunday, December 23, 2012 1:03 PM

> *To:* Jeff Hodges; Nat Sakimura

> *Cc:* IETF oauth WG

> *Subject:* RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>

> What is the X.1252 definition?

>

> -- Mike

>

> *From:* Nat Sakimura

> *Sent:* =E2=80=8EDecember=E2=80=8E =E2=80=8E23=E2=80=8E, =E2=80=8E2012=
 =E2=80=8E10=E2=80=8E:=E2=80=8E09=E2=80=8E =E2=80=8EAM

> *To:* =3DJeffH

> *CC:* Mike Jones, IETF oauth WG

> *Subject:* Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>

> Re definition of 'claim', as JWT is supposed to be generic, it=
 may be

> better to go with the definition of X.1252 rather than OIDC.

>

> =3Dnat via iPhone

>

> Dec 24, 2012 2:42=E3=80=81=3DJeffH <Jeff.Hodges@kingsmountain.com

> <mailto:Jeff.Hodge=
s@kingsmountain.com>> =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=
=BC=E3=82=B8:

>

>>

>> > Thanks for the replies, Jeff. =C2=A0They make sense. =C2=A0Pa=
rticularly,

>> > thanks for the "JSON Text Object" suggestion.

>>

>> welcome, glad they made some sense.

>>

>> similarly, if one employs JSON arrays, I'd define a "JSON=
 text array".

>>

>>

>> > For the "claims" definition, I'm actually prone=
 to go with

>> >definitions based =C2=A0on those in

>> >http://openid.net/specs/openid-connect=
-messages-1_0-13.html#terminol

>> >ogy-

>> > specifically:

>> >

>> > Claim

>> > A piece of information about an Entity that a Claims Provider=


>> > asserts about that Entity.

>> > Claims Provider

>> > A system or service that can return Claims about an Entity.
>> > End-User

>> > A human user of a system or service.

>> > Entity

>> > Something that has a separate and distinct existence and that=
 can

>> > be identified in context. An End-User is one example of an En=
tity.

>>

>> well, it seems to me, given the manner in which the JWT spec is
>> written, one can make the case that JWT claims in general aren'=
;t

>> necessarily about an Entity (as the latter term is used in the

>> context of the OpenID Connect specs), rather they're in genera=
l

>> simply assertions about something(s). this is because all pre-defi=
ned

> JWT claim types are optional and all JWT semantics are left up to

> specs that profile (aka re-use) the JWT spec.

>>

>> HTH,

>>

>> =3DJeffH

>>

>> _______________________________________________

>> OAuth mailing list

>>OAuth@ietf.org <mailto:OAuth@ietf.org>

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

>

>

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org

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

>

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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

_______________________________________________

OAuth mailing list

OAuth@ietf.org

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





-- 
=
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_=
en




--047d7b34413cb26d9604d209fb4a--

From sakimura@gmail.com  Sat Dec 29 20:18:35 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B2021F88AC for ; Sat, 29 Dec 2012 20:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.345
X-Spam-Level: 
X-Spam-Status: No, score=0.345 tagged_above=-999 required=5 tests=[AWL=-1.657,  BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOFIzC6BFv-q for ; Sat, 29 Dec 2012 20:18:33 -0800 (PST)
Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id EB78721F87B3 for ; Sat, 29 Dec 2012 20:18:32 -0800 (PST)
Received: by mail-ee0-f43.google.com with SMTP id e49so5853889eek.16 for ; Sat, 29 Dec 2012 20:18:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U8P1fSW06xqZu11oiBFw1d13WjpWge8zVDqkUjK2Cds=; b=Ogzgu8vedihkJqs4sExEnvvIPm81Ao2kGW/EXGot0caVVFWaK/lE7LNOR0HVq66gl/ bE2qKXpvG0poyLQabRMX4z7q9/O2GEE6gnATXS/Wjcq92stzXkCQdICVmm4lT4//reCo ne61RW4NywRhyrbLI/9fhiu2vdyik6PhYU0+Kx/fS9nXpcxZ/nOdergWAlBteNWg2R18 sBlx4io3qdvc+/Od9upDpZvtG+wGYNaQWN8g9Tn08DT9cDfOBYAJhpDfijiboD/7XPXk GpaS/nOyEgEAm3UIzzb8SpIrcayLvKM3xL2eD2Gj8KB5sgs1sWHHHLMlKe2gFYWpsrm1 WmvA==
MIME-Version: 1.0
Received: by 10.14.3.195 with SMTP id 43mr99826408eeh.36.1356841112097; Sat, 29 Dec 2012 20:18:32 -0800 (PST)
Received: by 10.14.215.66 with HTTP; Sat, 29 Dec 2012 20:18:31 -0800 (PST)
In-Reply-To: <50DDBCE5.8080205@mitre.org>
References: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436697FA11@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DDBCE5.8080205@mitre.org>
Date: Sun, 30 Dec 2012 13:18:31 +0900
Message-ID: 
From: Nat Sakimura 
To: Justin Richer 
Content-Type: multipart/alternative; boundary=047d7b66f23980d2f304d20a30cf
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 04:18:35 -0000

--047d7b66f23980d2f304d20a30cf
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Thanks Justin for a very good rundown. I agree with these. It would be a
disservice to the community not to include "azp" (aka "reg", "cid") in JWT,
as this gives so much clarity on the issue.

Let me add one more: it is a use case for HoK of the presenter while not
letting the issuer know where it is being presented. (e.g., showing
driver's license at a liquor shop.) Most of the physical identity documents
(e.g., passport, national ID card, etc.) falls into this category.

iss =3D> Authorization Server
aud =3D> *
sub =3D> Subject of the JWT Claim Set
azp =3D> Subject of the JWT Claim Set

Nat

On Sat, Dec 29, 2012 at 12:38 AM, Justin Richer  wrote:

>  I thought I should drop in my full rundown of the party representation
> here. Assuming a standard 3-legged OAuth flow of any flavor, you have the
> following mapping:
>
>  iss =3D> Authorization Server
>  aud =3D> Resource Server(s)
>  sub =3D> Resource Owner
>  azp =3D> Client
>
> Note that the "sub" claim here is a drop-in replacement for "prn" and tha=
t
> "azp" is a more or less drop-in replacement for "cid".
>
> Of course there are other ways that a JWT could be minted, so let me be a
> bit more concrete with a few examples.
>
> 3-legged OAuth:
>
>  iss: http://auth.example.org/
>  aud: http://resource.example.org/
>  sub: bob.smith
>  azp: oauth-client-1
>
> 2-legged OAuth (client credentials):
>
>  iss: http://auth.example.org/
>  aud: http://resource.example.org/
>  sub: oauth-client-1
>  azp: oauth-client-1
>
> Client authentication assertion, self-issued:
>
>  iss: oauth-client-1
>  aud: http://auth.example.org/
>  sub: oauth-client-1
>  azp: oauth-client-1
>
> Authorization grant assertion, self-issued:
>
>  iss: oauth-client-1
>  aud: http://auth.example.org/
>  sub: bob.smith
>  azp: oauth-client-1
>
> Client authentication assertion, non-self-issued:
>
>  iss: http://auth.example.org/
>  aud: http://auth.example.org/
>  sub: oauth-client-1
>  azp: oauth-client-1
>
> Authorization grant assertion, non-self-issued:
>
>  iss: http://auth.example.org/
>  aud: http://auth.example.org/
>  sub: bob.smith
>  azp: oauth-client-1
>
> OpenID Connect ID Token:
>
>  iss: http://auth.example.org/
>  aud: oauth-client-1
>  sub: bob.smith
>  azp: oauth-client-1
>
>
>
> Note that repeated values are intentional and MUST be preserved, since
> there's no way to know the value of a "missing" claim otherwise.
>
> There are likely other use cases here as well. Writing this all out has
> made me wonder if this needs to be captured in an online spreadsheet
> somewhere.
>
>  -- Justin
>
>
>
> On 12/20/2012 11:22 AM, Mike Jones wrote:
>
>  This was discussed on the OpenID Connect call this morning.  Our sense
> was that =93Authorized Party=94 was actually a more general description o=
f the
> concept than Client ID.  Justin Richer pointed out that at that point,
> there would be claims defined for representing all four potential parties
> in an OAuth interaction.  Connect plans to define the optional =93azp=94
> (Authorized Party) claim to let people experiment with it.  There wasn=92=
t a
> sense that it=92s necessary to add to the JWT spec itself at this time.**=
**
>
> ** **
>
> As for the proposed =93cid=94 (Client Identification Data claim type) cla=
im,
> our sense was that that is more related to proof of possession, and can b=
e
> discussed in that context.****
>
> ** **
>
>                                                             -- Mike****
>
> ** **
>
> *From:* Nat Sakimura [mailto:sakimura@gmail.com ]
> *Sent:* Wednesday, December 19, 2012 11:43 PM
> *To:* Mike Jones
> *Cc:* Anthony Nadalin; John Bradley; oauth
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT****
>
> ** **
>
> As "prn" is way under-defined [1], there can be two interpretations for
> "prn". ****
>
> ** **
>
> Considering that "subject" is not a defined term (=3D dictionary term), a=
nd
> interpreting a boarding pass as:****
>
> ** **
>
> "Japan Airlines authorizes JL002 to accept passenger John Smith at the
> Gate B22 provided safety and other requirements are met between the
> boarding time (14:30) and 10 minutes before the departure time (15:10)" *=
*
> **
>
> ** **
>
> then: ****
>
> ** **
>
> iss: Japan Airlines****
>
> prn: JL002 (the flight number)****
>
> cid: John Smith (the passenger, who uses the boarding pass)****
>
> aud: Gate B22 (Gate assigned to JL002)****
>
> nbf: 2012-12-31T14:30+9****
>
> exp: 2012-12-31T15:00+9****
>
> ** **
>
> Alternatively, if we interpret the boarding pass as: ****
>
> ** **
>
> "Japan Airlines authorizes John Smith to board JL002 at the Gate B22
> provided safety and other requirements are met the boarding time (14:30)
> and 10 minutes before the departure time (15:10)""****
>
> ** **
>
> iss: Japan Airlines****
>
> prn: John Smith****
>
> cid: John Smith****
>
> aud: Gate B22 (Gate assigned to JL002)****
>
> nbf: 2012-12-31T14:30+9****
>
> exp: 2012-12-31T15:00+9****
>
> ** **
>
> This interpretation has lost some information while encoding into JWT, so
> prior one may be more appropriate. ****
>
> ** **
>
> Either way, as "prn" lacks exact semantics, what goes into it is subject
> to interpretation while "cid" is very clearly defined. ****
>
> ** **
>
> Let me give another example. ****
>
> ** **
>
> An entitlement that says: "John Smith is allowed to activate the system
> when Mary White presents this token (#1234) to the System A" that is issu=
ed
> by the "ABC Corp"****
>
> ** **
>
> iss: ABC Corp. ****
>
> jti: #1234****
>
> prn: John Smith****
>
> cid: Mary White****
>
> aud: System A****
>
> ** **
>
> Note: this is not delegation nor on-behalf-of. ****
>
> ** **
>
> More webby example: "John Smith authorizes photo print service A to acces=
s
> photo archive service B for John Smith's photo #123 until 2013-04-01 for
> the sum of $100."****
>
> ** **
>
> iss: John Smith's Authorization Server****
>
> prn: John Smith's photo #123****
>
> cid: Photo print service A****
>
> aud: photo archive service B****
>
> exp: 2013-04-01****
>
> ** **
>
> Nat****
>
> ** **
>
> [1]  4.1.6 "prn" defines its value as what identifies:****
>
> ** **
>
> "the subject of the JWT" ****
>
>   ** **
>
> This can be expanded by replacing "JWT" with its definition as ****
>
> ** **
>
> "the subject of the string consisting of multiple parts, the first being
> the Encoded JWT Header, plus additional parts depending upon the contents
> of the header, with the parts being separated by period ('.') characters,
> and each part containing base64url encoded content."****
>
>  ** **
>
> Further, expanding "JWT Header", it will become ****
>
> ** **
>
> "the subject of the string consisting of multiple parts, the first being
> the string representing a JSON object that describes the cryptographic
> operations applied to the string, plus additional parts depending upon th=
e
> contents of the header, with the parts being separated by period ('.')
> characters, and each part containing base64url encoded content."****
>
>  ** **
>
> To me, it is not clear what it means. ****
>
> ** **
>
> ** **
>
> On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones 
> wrote:****
>
> What would the iss, prn, aud, and cid values represent in the boarding
> pass example?****
>
>  ****
>
> -- Mike****
>
>  ****
>
> *From:* Nat Sakimura
> *Sent:* December 19, 2012 9:32 PM
> *To:* Mike Jones
> *CC:* Anthony Nadalin, John Bradley, oauth
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT****
>
>  ****
>
> I obviously disagree - if I did agree, I did not send it to the list to
> start with :-) ****
>
> ** **
>
> "cid" (or in my original proposal, "reg") has a very clear and establishe=
d
> meaning. ****
>
> The parallel examples abounds in our daily life. ****
>
> ** **
>
> It has very little to do with On-behalf-of. ****
>
> It is not a delegation statement. ****
>
> ** **
>
> "cid" is there to indicate to whom it was issued to. ****
>
> The entity who was issued this "token" is eligible to use it at the ****
>
> entities indicated by "aud". ****
>
> ** **
>
> Example in our real life are like: ****
>
> ** **
>
> - Airline boarding pass****
>
> - Registered instruments (bond / share) ****
>
> - Monthly train pass****
>
> - Disneyland annual passport****
>
>  etc. etc. ****
>
> ** **
>
> Please do not mix it up with a delegation statement like on-behalf-of, **=
*
> *
>
> which is much less well defined. ****
>
> ** **
>
> Nat****
>
> ** **
>
> ** **
>
> On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones 
> wrote:****
>
>    I'm with Tony on this.  This seems premature to put into the JWT
> standard.  All the other JWT claims have well established meanings and
> history behind them.  These don't.****
>
>  ****
>
> If the goal is to allow OpenID Connect implementations to not reject
> tokens using =93cid=94, there are lots of other ways to accomplish this t=
hat I
> think we should consider first.****
>
>  ****
>
> -- Mike****
>
>  ****
>
>  ****
>
> *From:* John Bradley
> *Sent:* December 19, 2012 6:25 PM
> *To:* Anthony Nadalin
> *CC:* oauth****
>
> *Subject:* Re: [OAUTH-WG] "cid" claim in JWT****
>
>  ****
>
> I agree, audience who requested it and and who it is requested for are al=
l
> interrelated. ****
>
> ** **
>
> However we do need to set down some standard way of expressing it as
> people are starting to make stuff up on their own that will impact
> interoperability.****
>
> ** **
>
> If Google starts thawing in cid and clients don't know about it they must
> reject the JWT etc.****
>
> ** **
>
> John****
>
> ** **
>
> On 2012-12-19, at 9:40 PM, Anthony Nadalin  wrote:=
*
> ***
>
> ** **
>
> It seems premature and we should consider this in the bigger context of
> the =93on behalf of=94/delegation work that has been started****
>
>  ****
>
> *From:* oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] *On Behalf
> Of *Nat Sakimura
> *Sent:* Tuesday, December 18, 2012 6:22 PM
> *To:* oauth
> *Subject:* [OAUTH-WG] "cid" claim in JWT****
>
>  ****
>
> In OpenID Connect WG, we have been talking this for sometime. ****
>
> "cid" claim identifies the entity that the JWT was issued to as a
> rightful/licensed user. ****
>
> Google already uses this in their implementation of id_token of OIDC. ***=
*
>
>  ****
>
> Here is the text proposal. It introduces two new standard claims: "cid"
> and "cit". ****
>
>  ****
>
> It would be very useful in creating a HoK drafts as well. ****
>
>  ****
>
> Cheers, ****
>
>  ****
>
> Nat****
>
>  ****
>
>  ****
>
> *4.1.9. "cid" Client Identification Data Claim*****
>
>  ****
>
> The "cid" (client identification data) claim allows the receiver ****
>
> of the JWT to identify the entity that the JWT is ****
>
> intended to be used by. The audience of the JWT MUST be ****
>
> able to identify the client with the value of this claim.****
>
>  ****
>
> The "cid" value is a case sensitive string containing a StringOrURI value=
.****
>
> This claim is OPTIONAL. If the entity processing the claim does not ****
>
> identify the user of the JWT with the identifier in the "cid" claim value=
, ****
>
> then the JWT MUST be rejected. The interpretation of the registered to **=
**
>
> value is generally application specific.****
>
>  ****
>
> A typical example of a registered to claim includes following: ****
>
> * client_id that the audience can use to authenticate and ****
>
>   identify the client.****
>
> * A base64url encoded JWK. ****
>
> * A URL that points to the key material that the audience can use to ****
>
>   authenticate the user of the JWT.****
>
>  ****
>
> *4.1.10 "cit" (Client Identification Data claim type)*****
>
>  ****
>
> The "cit" (Client Identification Data claim type) identifies the type ***=
*
>
> of the "cid" claim. It is a StringOrURI value. The defined values ****
>
> are the following:****
>
>  ****
>
> "client_id" The value of the "cid" claim is the Client ID of the client *=
***
>
> that the audience of the JWT is able to use to authenticate the client.**=
**
>
>  ****
>
> "jwk" The value of the "cid" claim is a base64url encoded JWK of ****
>
> the registered client.****
>
>  ****
>
> "jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of ****
>
> JSON web signature [JWS].****
>
>  ****
>
> "x5u" The value of the "cid" claim is the URL that points to the public *=
***
>
> key certificate of the registered client. The format of the content ****
>
> that x5u points to is described in section 4.1.4 of the JSON Web Signatur=
e.****
>
>     ****
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>  ****
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ** **
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=3Dnat) ****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
>
> ****
>
> ** **
>
> --
> Nat Sakimura (=3Dnat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oau=
th
>
>
>


--=20
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

--047d7b66f23980d2f304d20a30cf
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Thanks Justin for a very good rundown. I agree with these. It would be a di=
sservice to the community not to include "azp" (aka "reg&quo=
t;, "cid") in JWT, as this gives so much clarity on the issue.

Let me add one more: it is a use case for HoK of the present=
er while not letting the issuer know where it is being presented. (e.g., sh=
owing driver's license at a liquor shop.) Most of the physical identity=
 documents (e.g., passport, national ID card, etc.) falls into this categor=
y.=A0



iss =3D> Authorization Server
aud =3D> =
*
sub =3D> Subject of the JWT Claim Set
azp =3D> =
Subject of the JWT Claim Set

Nat


On Sat, Dec 29, 2012 at 12:38 AM, Justin Richer <jricher@mitre.org>=
 wrote:


 =20
   =20
 =20
  

    
I thought I should drop in my full
      rundown of the party representation here. Assuming a standard
      3-legged OAuth flow of any flavor, you have the following mapping:
      

      =A0iss =3D> Authorization Server

      =A0aud =3D> Resource Server(s)

      =A0sub =3D> Resource Owner

      =A0azp =3D> Client

      

      Note that the "sub" claim here is a drop-in replacement for=
 "prn"
      and that "azp" is a more or less drop-in replacement for &q=
uot;cid". 

      

      Of course there are other ways that a JWT could be minted, so let
      me be a bit more concrete with a few examples. 

      

      3-legged OAuth:

      

      =A0iss: http:/=
/auth.example.org/

      =A0aud: ht=
tp://resource.example.org/

      =A0sub: bob.smith

      =A0azp: oauth-client-1

      

      2-legged OAuth (client credentials):

      

      =A0iss: http:/=
/auth.example.org/

      =A0aud: ht=
tp://resource.example.org/

      =A0sub: oauth-client-1

      =A0azp: oauth-client-1

      

      Client authentication assertion, self-issued:

      

      =A0iss: oauth-client-1

      =A0aud: http:/=
/auth.example.org/

      =A0sub: oauth-client-1

      =A0azp: oauth-client-1

      

      Authorization grant assertion, self-issued:

      

      =A0iss: oauth-client-1

      =A0aud: http:/=
/auth.example.org/

      =A0sub: bob.smith

      =A0azp: oauth-client-1

      

      Client authentication assertion, non-self-issued:

      

      =A0iss: http:/=
/auth.example.org/

      =A0aud: http:/=
/auth.example.org/

      =A0sub: oauth-client-1

      =A0azp: oauth-client-1

      

      Authorization grant assertion, non-self-issued:

      

      =A0iss: http:/=
/auth.example.org/

      =A0aud: http:/=
/auth.example.org/

      =A0sub: bob.smith

      =A0azp: oauth-client-1

      

      OpenID Connect ID Token:

      

      =A0iss: http:/=
/auth.example.org/

      =A0aud: oauth-client-1

      =A0sub: bob.smith

      =A0azp: oauth-client-1

      

      

      

      Note that repeated values are intentional and MUST be preserved,
      since there's no way to know the value of a "missing" c=
laim
      otherwise. 

      

      There are likely other use cases here as well. Writing this all
      out has made me wonder if this needs to be captured in an online
      spreadsheet somewhere.=


      

      =A0-- Justin


      =A0
      

      

      On 12/20/2012 11:22 AM, Mike Jones wrote:

    

    

     =20
     =20
     =20
      

        
This
            was discussed on the OpenID Connect call this morning.=A0 Our
            sense was that =93Authorized Party=94 was actually a more
            general description of the concept than Client ID.=A0 Justin
            Richer pointed out that at that point, there would be claims
            defined for representing all four potential parties in an
            OAuth interaction.=A0 Connect plans to define the optional
            =93azp=94 (Authorized Party) claim to let people experiment wit=
h
            it.=A0 There wasn=92t a sense that it=92s necessary to add to t=
he
            JWT spec itself at this time.

        
=A0=


        
As
            for the proposed =93cid=94 (Client Identification Data claim
            type) claim, our sense was that that is more related to
            proof of possession, and can be discussed in that context.

        
=A0=


        
=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=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:
            Nat Sakimura [mailto:sakimura@gmail.com]
            

            Sent: Wednesday, December 19, 2012 11:43 PM

            To: Mike Jones

            Cc: Anthony Nadalin; John Bradley; oauth

            Subject: Re: [OAUTH-WG] "cid" claim in JWT<=
/u>

        
=A0

        

          

            
As "prn" is way under-defined =
[1],
              there can be two interpretations for "prn".=A0

          

          

            
=A0

          

          

            
Considering that "subject" is =
not a
              defined term (=3D dictionary term), and interpreting a
              boarding pass as:

          

          

            
=A0

          

          

            
"Japan Airlines authorizes JL002 to
              accept passenger John Smith at the Gate B22 provided
              safety and other requirements are met between the boarding
              time (14:30) and 10 minutes before the departure time
              (15:10)"=A0

          

          

            
=A0

          

          

            
then:=A0

          

          

            
=A0

          

          
iss: Japan Airlines

          

            
prn: JL002 (the flight number)=


          

          

            
cid: John Smith (the passenger, who
              uses the boarding pass)

          

          

            
aud:=A0Gate B22 (Gate assigned to JL002)=


          

        

        

          
nbf: 2012-12-31T14:30+9

        

        

          
exp: 2012-12-31T15:00+9

        

        

          
=A0

        

        

          
Alternatively, if we interpret the
            boarding pass as:=A0

        

        

          
=A0

        

        

          
"Japan Airlines authorizes John Smith=
 to
            board JL002 at the Gate B22 provided safety and other
            requirements are met=A0the boarding time (14:30) and 10
            minutes before the departure time (15:10)""=


        

        

          
=A0

        

        

          
iss: Japan Airlines

        

        

          
prn: John Smith

        

        

          
cid: John Smith

        

        

          
aud: Gate B22 (Gate assigned to JL002)<=
/u>

        

        

          

            
nbf: 2012-12-31T14:30+9
          

          

            
exp: 2012-12-31T15:00+9
          

        

        

          
=A0

        

        

          
This interpretation has lost some
            information while encoding into JWT, so prior one may be
            more appropriate.=A0

        

        

          
=A0

        

        

          
Either way, as "prn" lacks exact
            semantics, what goes into it is subject to interpretation
            while "cid" is very clearly defined.=A0=


        

        

          
=A0

        

        

          
Let me give another example.=A0<=
/u>

        

        

          
=A0

        

        

          
An entitlement that says: "John Smith=
 is
            allowed to activate the system when Mary White presents this
            token (#1234) to the System A" that is issued by the "=
;ABC
            Corp"

        

        

          
=A0

        

        

          
iss: ABC Corp.=A0

        

        

          
jti: #1234

        

        

          
prn: John Smith

        

        

          
cid: Mary White

        

        

          
aud: System A

        

        

          
=A0

        

        

          
Note: this is not delegation nor
            on-behalf-of.=A0

        

        

          
=A0

        

        

          
More webby example: "John Smith
            authorizes photo print service A to access photo archive
            service B for John Smith's photo #123 until 2013-04-01 for
            the sum of $100."

        

        

          
=A0

        

        

          
iss: John Smith's Authorization Server=


        

        

          
prn: John Smith's photo #123=


        

        

          
cid: Photo print service A
        

        

          
aud: photo archive service B=


        

        

          
exp: 2013-04-01

        

        

          
=A0

        

        

          
Nat

        

        

          
=A0

        

        

          
[1] =A04.1.6 "prn" defines its v=
alue as
            what identifies:

        

        

          
=A0

        

        

          

            

              
"the
                  subject of the JWT"=A0

            

          

          

            

              
=A0=


            

            

              
This
                  can be expanded by replacing=A0"JWT" with its d=
efinition
                  as=A0

            

            

              
=A0=


            

            

              
"the
                  subject of the string consisting of multiple parts,
                  the first being the Encoded JWT Header, plus
                  additional parts depending upon the contents of the
                  header, with the parts being separated by period ('.&=
#39;)
                  characters, and each part containing base64url encoded
                  content."

            

            

              
=A0=


            

            

              
Further,
                  expanding "JWT Header", it will become=A0

            

            

              
=A0=


            

            

              
"the
                  subject of the string consisting of multiple parts,
                  the first being the=A0string representing a JSON object
                  that describes the cryptographic operations applied to
                  the string, plus additional parts depending upon the
                  contents of the header, with the parts being separated
                  by period ('.') characters, and each part contain=
ing
                  base64url encoded content."

            

            

              
=A0=


            

            

              
To
                  me, it is not clear what it means.=A0

            

          

          

            
=A0

          

        

        

          
=A0

          

            
On Thu, Dec 20, 2012 at 3:07 PM, Mike
              Jones <Michael.Jones@microsoft.com>
              wrote:

            

              

                

                  
What
                      would the iss, prn, aud, and cid values represent
                      in the boarding pass example?
                

                

                  
=A0

                

                

                  
--
                      Mike

                

                

                  
=A0

                

                

                  
From:=A0Nat
                      Sakimura

                      Sent:=A0December
                      19, 2012 9:32 PM

                      To:=A0Mike
                      Jones

                      CC:=A0Anthony
                      Nadalin, John Bradley, oauth

                      Subject:=A0Re:
                      [OAUTH-WG] "cid" claim in JWT=


                

                

                  

                    

                      
=A0

                    

                    
I
                        obviously disagree - if I did agree, I did not
                        send it to the list to start with :-)
                        

                    

                      
=A0

                    

                    

                      
"cid"
                          (or in my original proposal, "reg") has=
 a very
                          clear and established meaning.=A0

                    

                    

                      
The
                          parallel examples abounds in our daily life.=A0

                    

                    

                      
=A0

                    

                    

                      
It
                          has very little to do with On-behalf-of.=A0

                    

                    

                      
It
                          is not a delegation statement.=A0

                    

                    

                      
=A0

                    

                    

                      
"cid"
                          is there to indicate to whom it was issued
                          to.=A0

                    

                    

                      
The
                          entity who was issued this "token" is e=
ligible
                          to use it at the=A0

                    

                    

                      
entities
                          indicated by "aud".=A0

                    

                    

                      
=A0

                    

                    

                      
Example
                          in our real life are like:=A0

                    

                    

                      
=A0

                    

                    

                      
-
                          Airline boarding pass

                    

                    

                      
-
                          Registered instruments (bond / share)=A0

                    

                    

                      
-
                          Monthly train pass

                    

                    

                      
-
                          Disneyland annual passport
                    

                    

                      
=A0etc.
                          etc.=A0

                    

                    

                      
=A0

                    

                    

                      
Please
                          do not mix it up with a delegation statement
                          like on-behalf-of,=A0

                    

                    

                      
which
                          is much less well defined.=A0

                    

                    

                      
=A0

                    

                    

                      
Nat

                    

                    

                      
=A0

                    

                  

                

                

                  
=
=A0

                  

                    

                      

                        
On
                            Thu, Dec 20, 2012 at 12:07 PM, Mike Jones
                            <Michael.Jones@microsoft.com>
                            wrote:

                      

                    

                    

                      

                        

                          

                            

                              

                                
I'm
                                    with Tony on this.=A0 This seems
                                    premature to put into the JWT
                                    standard.=A0 All the other JWT claims
                                    have well established meanings and
                                    history behind them.=A0 These don't=
.

                              

                              

                                
=A0=


                              

                              

                                
If
                                    the goal is to allow OpenID Connect
                                    implementations to not reject tokens
                                    using=A0=93cid=94, there are lots of ot=
her
                                    ways to accomplish this that I think
                                    we should consider first.=


                              

                              

                                
=A0=


                              

                              

                                
--
                                    Mike

                              

                              

                                
=A0=


                              

                              

                                
=A0=


                              

                            

                          

                          

                            

                              

                                
From:=A0John
                                    Bradley

                                    Sent:=A0December
                                    19, 2012 6:25 PM

                                    To:=A0Anthony
                                    Nadalin

                                    CC:=A0oauth<=
u>

                              

                            

                            
Subject:=
=A0Re:
                                [OAUTH-WG] "cid" claim in JWT<=
/u>

                          

                          

                            

                              

                                

                                  
=A0

                                

                                
I
                                    agree, audience who requested it and
                                    and who it is requested for are all
                                    interrelated.
                                    

                                

                                  
=A0

                                

                              

                              

                                

                                  

                                    
However
                                        we do need to set down some
                                        standard way of expressing it as
                                        people are starting to make
                                        stuff up on their own that will
                                        impact interoperability.<=
/u>

                                  

                                  

                                    
=A0

                                  

                                  

                                    
If
                                        Google starts thawing in cid and
                                        clients don't know about it the=
y
                                        must reject the JWT etc.<=
/u>

                                  

                                  

                                    
=A0

                                  

                                  

                                    
John

                                  

                                  

                                    
=A0

                                    

                                      

                                        
On
                                            2012-12-19, at 9:40 PM,
                                            Anthony Nadalin <tonynad@microsoft.com&g=
t;
                                            wrote:

                                      

                                      

                                        
=A0

                                        

                                          

                                            

                                              
It
                                                  seems premature and we
                                                  should consider this
                                                  in the bigger context
                                                  of the =93on behalf
                                                  of=94/delegation work
                                                  that has been started

                                            

                                            

                                              
=A0


                                            

                                            

                                              
From:=A0oauth-bounces@ietf.org
                                                  [mailto:oauth-bounces@ietf.org]=A0On

                                                    Behalf Of=A0Nat
                                                  Sakimura

                                                  Sent:=A0Tuesday,
                                                  December 18, 2012 6:22
                                                  PM

                                                  To:=A0oauth

                                                  Subject:=A0[OAUTH-=
WG]
                                                  "cid" claim in =
JWT

                                            

                                            

                                              
=A0=


                                            

                                            

                                              
In
                                                OpenID Connect WG, we
                                                have been talking this
                                                for sometime.=A0<=
/u>

                                            

                                            

                                              

                                                
&quo=
t;cid"
                                                  claim identifies the
                                                  entity that the JWT
                                                  was issued to as a
                                                  rightful/licensed
                                                  user.=A0
                                              

                                            

                                            

                                              

                                                
Goog=
le
                                                  already uses this in
                                                  their implementation
                                                  of id_token of OIDC.=A0

                                              

                                            

                                            

                                              

                                                
=A0<=
u>

                                              

                                            

                                            

                                              

                                                
Here
                                                  is the text proposal.
                                                  It introduces two new
                                                  standard claims: "ci=
d"
                                                  and "cit".=A0

                                              

                                            

                                            

                                              

                                                
=A0<=
u>

                                              

                                            

                                            

                                              

                                                
It
                                                    would be very useful
                                                    in creating a HoK
                                                    drafts as well.=A0

                                              

                                              

                                                
=A0<=
/p>

                                              

                                              

                                                
Cheers,=A0<=
u>


                                              

                                              

                                                
=A0<=
/p>

                                              

                                              

                                                
Nat<=
/p>

                                              

                                              

                                                
=A0<=
/p>

                                              

                                              

                                                

                                                  
=A0

                                                  
4.1.9. "cid" Client Identification Data Claim


                                                  
=A0

                                                  
The "cid" (client identification data) claim allows the recei=
ver 


                                                  
of the JWT to identify the entity that the JWT is =



                                                  
intended to be used by. The audience of the JWT MUST be <=
u>


                                                  
able to identify the client with the value of this claim.=



                                                  
=A0

                                                  
The "cid" value is a case sens=
itive string containing a StringOrURI value.


                                                  
This claim is OPTIONAL. If the entity processing the claim does not 


                                                  
identify the user of the JWT with the identifier in the "cid"=
 claim value, 


                                                  
then the JWT MUST be rejected. The interpretation of the registered to =



                                                  
value is generally application specific.

                                                  
=A0

                                                  
A typical example of a registered to claim includes following: <=
u>


                                                  
* client_id that the audience can use to authenticate and 


                                                  
=A0=A0identify the client.

                                                  
* A base64url encoded JWK. 

                                                  
* A URL that points to the key material that the audience can use to 


                                                  
=A0=A0authenticate the user of the JWT.

                                                  
=A0

                                                  
4.1.10 "cit" (Client Identification Data claim type)


                                                  
=A0

                                                  
The "cit" (Client Identification Data claim type) identifies =
the type 


                                                  
of the "cid" claim. It is a StringOrURI value. The defined va=
lues 


                                                  
are the following:

                                                  
=A0

                                                  
"client_id" The value of the "cid" claim is the Cli=
ent ID of the client 


                                                  
that the audience of the JWT is able to use to authenticate the client.=



                                                  
=A0

                                                  
"jwk" The value of the "cid" claim is a base64url e=
ncoded JWK of 


                                                  
the registered client.

                                                  
=A0

                                                  
"jku" The value of the "cid" claim is the "jku=
" defined in 4.1.2 of 


                                                  
JSON web signature [JWS].

                                                  
=A0

                                                  
"x5u" The value of the "cid" claim is the URL that =
points to the public 


                                                  
key certificate of the registered client. The format of the content 


                                                  
that x5u points to is described in section 4.1.4 of the JSON Web Signat=
ure.


                                                

                                              

                                            

                                            

                                              

                                                

                                                  
=
=A0

                                                

                                              

                                              

                                                
--=
=A0

                                                  Nat Sakimura (=3Dnat)<=
/u>

                                              

                                              

                                                

                                                  
Ch=
airman,
                                                    OpenID Foundation

                                                    http://nat.sak=
imura.org/

                                                    @_nat_en<=
/p>
                                                

                                              

                                              

                                                
=A0<=
u>

                                              

                                            

                                          

                                          
______________=
_________________________________

                                              OAuth mailing list

                                              OAuth@ietf.org

                                              https://www.ietf.org/mailman/l=
istinfo/oauth

                                        

                                      

                                    

                                    
=A0

                                  

                                

                              

                            

                          

                        

                      

                      

                        

                          


_______________________________________________

                              OAuth mailing list

                              OAuth@ietf.org

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

                        

                      

                    

                  

                  
                

              

            

          

          


            

            

          

            
=A0

          

          
-- 

            Nat Sakimura (=3Dnat)

          

            
Chairman, OpenID Foundation

              http:/=
/nat.sakimura.org/

              @_nat_en

          

        

      

      

      

      

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


    

    

  






-- 
Nat Sakimura=
 (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en




--047d7b66f23980d2f304d20a30cf--

From tonynad@microsoft.com  Sat Dec 29 21:35:59 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC6521F8920 for ; Sat, 29 Dec 2012 21:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDy+c6gpGO7q for ; Sat, 29 Dec 2012 21:35:57 -0800 (PST)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF4821F888C for ; Sat, 29 Dec 2012 21:35:57 -0800 (PST)
Received: from BL2FFO11FD003.protection.gbl (10.173.161.204) by BL2FFO11HUB029.protection.gbl (10.173.161.53) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 05:35:54 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD003.mail.protection.outlook.com (10.173.160.103) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 30 Dec 2012 05:35:54 +0000
Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.81) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 30 Dec 2012 05:35:52 +0000
Received: from mail35-ch1-R.bigfish.com (10.43.68.238) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.23; Sun, 30 Dec 2012 05:35:52 +0000
Received: from mail35-ch1 (localhost [127.0.0.1])	by mail35-ch1-R.bigfish.com (Postfix) with ESMTP id F2577E0395	for ; Sun, 30 Dec 2012 05:35:51 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -21
X-BigFish: PS-21(zzbb2dI98dI9371Ic89bhd6eah542I1432Ic857h1447Izz1de0h1202h1e76h1d1ah1d2ah1082kz8dhz8275bh8275dh8275ch1033IL177df4h18c673h17326ahz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail35-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; LANG:en; 
Received: from mail35-ch1 (localhost.localdomain [127.0.0.1]) by mail35-ch1 (MessageSwitch) id 1356845748787549_23080; Sun, 30 Dec 2012 05:35:48 +0000 (UTC)
Received: from CH1EHSMHS030.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.244])	by mail35-ch1.bigfish.com (Postfix) with ESMTP id BDA5816030F;	Sun, 30 Dec 2012 05:35:48 +0000 (UTC)
Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS030.bigfish.com (10.43.70.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 30 Dec 2012 05:35:48 +0000
Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.245.2; Sun, 30 Dec 2012 05:35:47 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 05:35:28 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Sun, 30 Dec 2012 05:35:28 +0000
From: Anthony Nadalin 
To: Nat Sakimura 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYXPokKfJ1TsWSvG7/OFVVl60vgAR1McAAB7o9hAAB4+qgAADLfxg
Date: Sun, 30 Dec 2012 05:35:27 +0000
Message-ID: 
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk> <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.46.126.7]
Content-Type: multipart/alternative; boundary="_000_ca5dd691f5dd40dab01ab97fa79d8951BY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT005.namprd03.prod.outlook.com
X-FOPE-CRA-Verdict: 157.56.240.21$kent.ac.uk%0%1%duplicatedomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com%False%False%0$
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%KENT.AC.UK$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(13464002)(51704002)(51914002)(377454001)(24454001)(54316002)(47736001)(5343655001)(5343635001)(50986001)(74502001)(15202345001)(46102001)(49866001)(47446002)(76482001)(47976001)(31966008)(16676001)(15395725002)(53806001)(56816002)(54356001)(51856001)(44976002)(550184003)(74662001)(59766001)(4396001)(33646001)(77982001)(16236675001)(6806001)(5343645001)(512874001)(1411001)(56776001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB029; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 071156160B
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 05:35:59 -0000

--_000_ca5dd691f5dd40dab01ab97fa79d8951BY2PR03MB041namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

MTI1MiBzIGl0IGhhcyBhIHNlY3Rpb24gdGhhdCBleHBsYWlucyB0aGUgdXNhZ2UNCg0KQS4yICAg
ICAgIENsYWltL2Fzc2VydGlvbg0KVGhlIG1lYW5pbmcgb2YgdGhlIHRlcm1zIGNsYWltIGFuZCBh
c3NlcnRpb24gYXJlIGdlbmVyYWxseSBhZ3JlZWQgdG8gYmUgc29tZXdoYXQgc2ltaWxhciBidXQg
d2l0aCBzbGlnaHRseSBkaWZmZXJlbnQgbWVhbmluZ3MuIEluIHNvbWUgY2FzZXMsIGFuIGFzc2Vy
dGlvbiBpcyBjb25zaWRlcmVkIHRvIGJlIGEgInN0cm9uZ2VyIiBzdGF0ZW1lbnQgdGhhbiBhIGNs
YWltLiBGb3IgZXhhbXBsZSwgdGhlIE94Zm9yZCBFbmdsaXNoIERpY3Rpb25hcnkgZGVmaW5lcyBj
bGFpbSBhczoNCg0KYSkgICAgICAgICAgdG8gc3RhdGUgYXMgYmVpbmcgdGhlIGNhc2UsIHdpdGhv
dXQgYmVpbmcgYWJsZSB0byBnaXZlIHByb29mOw0KDQpiKSAgICAgICAgICBhIHN0YXRlbWVudCB0
aGF0IHNvbWV0aGluZyBpcyB0aGUgY2FzZSwNCmFuZCBhc3NlcnRpb24gYXM6IGEgY29uZmlkZW50
IGFuZCBmb3JjZWZ1bCBzdGF0ZW1lbnQuIEhvd2V2ZXIsIGluIGEgZGlnaXRhbCBjb250ZXh0LCB0
aGUgdGVybXMgImNvbmZpZGVudCIgYW5kICJmb3JjZWZ1bCIgYXJlIG5vdCByZWFsbHkgbWVhbmlu
Z2Z1bC4NCkluIG9wZW4gbmV0d29ya3MsIHRoZXJlIHdpbGwgYmUgYSBtb3JlIGNvbXBsZXggYW5k
IGFtYml2YWxlbnQgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHBhcnR5IG1ha2luZyBhIHN0YXRl
bWVudCAoaS5lLiwgcHJlc2VudGluZyBpZGVudGl0eSBpbmZvcm1hdGlvbikgYW5kIHRoZSBwYXJ0
eSB0aGF0IHJlbGllcyBvbiBpdC4gVGhlcmVmb3JlLCBhbnkgc3RhdGVtZW50IGlzIGFzc3VtZWQg
dG8gYmUgaW4gZG91YnQgYW5kLCBhcyBzdWNoLCBpcyBzdWJqZWN0IHRvIHZlcmlmaWNhdGlvbiBv
ciByZXF1ZXN0IGZvciBmdXJ0aGVyIGV2aWRlbmNlLiBOZWl0aGVyIGNsYWltcyBub3IgYXNzZXJ0
aW9ucyBjYW4gYmUgYXNzdW1lZCB0byBiZSBtYWRlIHdpdGggYW55IGF1dGhvcml0eSB3aGF0ZXZl
ci4gSXQgd2lsbCBhbHdheXMgYmUgdXAgdG8gdGhlIHJlbHlpbmcgcGFydHkgdG8gZGVjaWRlIHdo
ZXRoZXIgb3Igbm90IHRvIGFjY2VwdCB0aGUgY2xhaW0gb3IgYXNzZXJ0aW9uIGJhc2VkIG9uIHZl
cmlmaWNhdGlvbiBieSB0aGUgcmVseWluZyBwYXJ0eSAob3IgYnkgYSB2ZXJpZmllciBhY3Rpbmcg
YXQgdGhlIHJlcXVlc3Qgb2YgdGhlIHJlbHlpbmcgcGFydHkpLg0KDQoNCkZyb206IE5hdCBTYWtp
bXVyYSBbbWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJl
ciAyOSwgMjAxMiA4OjA0IFBNDQpUbzogQW50aG9ueSBOYWRhbGluDQpDYzogRGF2aWQgQ2hhZHdp
Y2s7IE1pa2UgSm9uZXM7IElFVEYgb2F1dGggV0cNClN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHJl
dmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNQ0KDQpUb255LA0KDQpTbyBk
byB5b3UgYWdyZWUgd2l0aCB0aGUgZm9sbG93aW5nIGRlZmluaXRpb24gaW4gLTA2PyBPciBwcmVm
ZXIgWC4xMjUyIGRlZmluaXRpb24/DQoNCg0KQ2xhaW0gIEEgcGllY2Ugb2YgaW5mb3JtYXRpb24g
YXNzZXJ0ZWQgYWJvdXQgYSBzdWJqZWN0LiAgSGVyZSwgQ2xhaW1zDQoNCiAgICAgIGFyZSByZXBy
ZXNlbnRlZCBuYW1lL3ZhbHVlIHBhaXJzLCBjb25zaXN0aW5nIG9mIGEgQ2xhaW0gTmFtZSBhbmQg
YQ0KDQogICAgICBDbGFpbSBWYWx1ZS4NCg0KTWlrZToNCg0KUmVnYXJkaW5nIHRoZSBvcmRlcmlu
ZyBvZiB0aGUgdGVybXMgaW4gdGVybWlub2xvZ3ksIHlvdSBzaG91bGQgZWl0aGVyIHVzZSB0aGUg
ZGVwZW5kZW5jeSBjaGFpbiBvciBhbHBoYWJldGljIG9yZGVyLiAoRm9ybWVyIGlzIG1vcmUgZGVz
aXJhYmxlIGluIG15IHBvaW50IG9mIHZpZXcuKSBIb3dldmVyLCBhcyBpdCBzdGFuZHMsIGl0IGlz
IG5vbmUgb2YgdGhvc2UuIEZvciBleGFtcGxlLCB0aGUgdGVybSAiY2xhaW0iIGFwcGVhcnMgaW4g
dGhlIGRlZmluaXRpb24gb2YgSldULCB3aGljaCBpcyB0aGUgZmlyc3QgdGVybSBpbiB0aGUgdGVy
bWlub2xvZ3ksIHdpdGhvdXQgaGF2aW5nIGJlZW4gZGVmaW5lZC4gSWYgeW91IGRvIG5vdCBtaW5k
LCBJIHdpbGwgcmVvcmRlciB0aGVtIGFuZCBzZW5kIGl0IHRvIHlvdS4NCg0KTmF0DQoNCk9uIFN1
biwgRGVjIDMwLCAyMDEyIGF0IDk6MjggQU0sIEFudGhvbnkgTmFkYWxpbiA8dG9ueW5hZEBtaWNy
b3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkJ5IGRlZmlu
aXRpb24gYSBjbGFpbSBpcyBhbHdheXMgaW4gZG91YnQgdGh1cyBpdCB3b3VsZCBub3QgY2FsbCBp
dCBhIGNyZWRlbnRpYWwgdW50aWwgaXQgaXMgdmVyaWZpZWQNCg0KLS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS0NCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJvdW5j
ZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBEYXZpZCBDaGFkd2ljaw0KU2VudDogU2F0
dXJkYXksIERlY2VtYmVyIDI5LCAyMDEyIDE6NDIgQU0NClRvOiBNaWtlIEpvbmVzDQpDYzogSUVU
RiBvYXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9h
dXRoLWpzb24td2ViLXRva2VuLTA1DQoNCklmIGEgY2xhaW0gcHJvdmlkZXMgcHJvb2YgdGhlbiBJ
IHdvdWxkIGNhbGwgaXQgYSBjcmVkZW50aWFsIG5vdCBhIGNsYWltDQoNCkRhdmlkDQoNCk9uIDI5
LzEyLzIwMTIgMDE6MTEsIE1pa2UgSm9uZXMgd3JvdGU6DQo+IEkgZm91bmQgdGhlIFguMTI1MiBk
ZWZpbml0aW9uLiAgSXQgaXM6DQo+DQo+ICo2LjE4IGNsYWltICpbYi1PRURdOiBUbyBzdGF0ZSBh
cyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBiZWluZyBhYmxlDQo+IHRvIGdpdmUgcHJvb2YuDQo+
DQo+IFRoYXQgc2VlbXMgYm90aCBhIGJpdCB2YWd1ZSwgYW5kIGFjdHVhbGx5IGluY29ycmVjdCwg
YXMgdGhlIEpXVCBtYXkNCj4gaW5jbHVkZSBwcm9vZiBvZiB0aGUgdmVyYWNpdHkgb2YgdGhlIGNs
YWltLiAgUGxlYXNlIHNlZSB0aGUgdXBkYXRlZA0KPiBKV1QgZHJhZnQgZm9yIGEgaG9wZWZ1bGx5
IG1vcmUgdXNlZnVsIOKAnENsYWlt4oCdIGRlZmluaXRpb24uDQo+DQo+ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0DQo+IHdp
c2hlcywNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4NCj4gKkZyb206Kk1pa2UgSm9uZXMNCj4gKlNlbnQ6
KiBTdW5kYXksIERlY2VtYmVyIDIzLCAyMDEyIDE6MDMgUE0NCj4gKlRvOiogSmVmZiBIb2RnZXM7
IE5hdCBTYWtpbXVyYQ0KPiAqQ2M6KiBJRVRGIG9hdXRoIFdHDQo+ICpTdWJqZWN0OiogUkU6IFtP
QVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1DQo+DQo+
IFdoYXQgaXMgdGhlIFguMTI1MiBkZWZpbml0aW9uPw0KPg0KPiAtLSBNaWtlDQo+DQo+ICpGcm9t
OiogTmF0IFNha2ltdXJhDQo+ICpTZW50Oiog4oCORGVjZW1iZXLigI4g4oCOMjPigI4sIOKAjjIw
MTIg4oCOMTDigI464oCOMDnigI4g4oCOQU0NCj4gKlRvOiogPUplZmZIDQo+ICpDQzoqIE1pa2Ug
Sm9uZXMsIElFVEYgb2F1dGggV0cNCj4gKlN1YmplY3Q6KiBSZTogW09BVVRILVdHXSByZXZpZXc6
IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDUNCj4NCj4gUmUgZGVmaW5pdGlvbiBv
ZiAnY2xhaW0nLCBhcyBKV1QgaXMgc3VwcG9zZWQgdG8gYmUgZ2VuZXJpYywgaXQgbWF5IGJlDQo+
IGJldHRlciB0byBnbyB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIFguMTI1MiByYXRoZXIgdGhhbiBP
SURDLg0KPg0KPiA9bmF0IHZpYSBpUGhvbmUNCj4NCj4gRGVjIDI0LCAyMDEyIDI6NDLjgIE9SmVm
ZkggPEplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPG1haWx0bzpKZWZmLkhvZGdlc0BraW5n
c21vdW50YWluLmNvbT4NCj4gPG1haWx0bzpKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbTxt
YWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+Pj4g44Gu44Oh44OD44K744O844K4
Og0KPg0KPj4NCj4+ID4gVGhhbmtzIGZvciB0aGUgcmVwbGllcywgSmVmZi4gIFRoZXkgbWFrZSBz
ZW5zZS4gIFBhcnRpY3VsYXJseSwNCj4+ID4gdGhhbmtzIGZvciB0aGUgIkpTT04gVGV4dCBPYmpl
Y3QiIHN1Z2dlc3Rpb24uDQo+Pg0KPj4gd2VsY29tZSwgZ2xhZCB0aGV5IG1hZGUgc29tZSBzZW5z
ZS4NCj4+DQo+PiBzaW1pbGFybHksIGlmIG9uZSBlbXBsb3lzIEpTT04gYXJyYXlzLCBJJ2QgZGVm
aW5lIGEgIkpTT04gdGV4dCBhcnJheSIuDQo+Pg0KPj4NCj4+ID4gRm9yIHRoZSAiY2xhaW1zIiBk
ZWZpbml0aW9uLCBJJ20gYWN0dWFsbHkgcHJvbmUgdG8gZ28gd2l0aA0KPj4gPmRlZmluaXRpb25z
IGJhc2VkICBvbiB0aG9zZSBpbg0KPj4gPmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1j
b25uZWN0LW1lc3NhZ2VzLTFfMC0xMy5odG1sI3Rlcm1pbm9sDQo+PiA+b2d5LQ0KPj4gPiBzcGVj
aWZpY2FsbHk6DQo+PiA+DQo+PiA+IENsYWltDQo+PiA+IEEgcGllY2Ugb2YgaW5mb3JtYXRpb24g
YWJvdXQgYW4gRW50aXR5IHRoYXQgYSBDbGFpbXMgUHJvdmlkZXINCj4+ID4gYXNzZXJ0cyBhYm91
dCB0aGF0IEVudGl0eS4NCj4+ID4gQ2xhaW1zIFByb3ZpZGVyDQo+PiA+IEEgc3lzdGVtIG9yIHNl
cnZpY2UgdGhhdCBjYW4gcmV0dXJuIENsYWltcyBhYm91dCBhbiBFbnRpdHkuDQo+PiA+IEVuZC1V
c2VyDQo+PiA+IEEgaHVtYW4gdXNlciBvZiBhIHN5c3RlbSBvciBzZXJ2aWNlLg0KPj4gPiBFbnRp
dHkNCj4+ID4gU29tZXRoaW5nIHRoYXQgaGFzIGEgc2VwYXJhdGUgYW5kIGRpc3RpbmN0IGV4aXN0
ZW5jZSBhbmQgdGhhdCBjYW4NCj4+ID4gYmUgaWRlbnRpZmllZCBpbiBjb250ZXh0LiBBbiBFbmQt
VXNlciBpcyBvbmUgZXhhbXBsZSBvZiBhbiBFbnRpdHkuDQo+Pg0KPj4gd2VsbCwgaXQgc2VlbXMg
dG8gbWUsIGdpdmVuIHRoZSBtYW5uZXIgaW4gd2hpY2ggdGhlIEpXVCBzcGVjIGlzDQo+PiB3cml0
dGVuLCBvbmUgY2FuIG1ha2UgdGhlIGNhc2UgdGhhdCBKV1QgY2xhaW1zIGluIGdlbmVyYWwgYXJl
bid0DQo+PiBuZWNlc3NhcmlseSBhYm91dCBhbiBFbnRpdHkgKGFzIHRoZSBsYXR0ZXIgdGVybSBp
cyB1c2VkIGluIHRoZQ0KPj4gY29udGV4dCBvZiB0aGUgT3BlbklEIENvbm5lY3Qgc3BlY3MpLCBy
YXRoZXIgdGhleSdyZSBpbiBnZW5lcmFsDQo+PiBzaW1wbHkgYXNzZXJ0aW9ucyBhYm91dCBzb21l
dGhpbmcocykuIHRoaXMgaXMgYmVjYXVzZSBhbGwgcHJlLWRlZmluZWQNCj4gSldUIGNsYWltIHR5
cGVzIGFyZSBvcHRpb25hbCBhbmQgYWxsIEpXVCBzZW1hbnRpY3MgYXJlIGxlZnQgdXAgdG8NCj4g
c3BlY3MgdGhhdCBwcm9maWxlIChha2EgcmUtdXNlKSB0aGUgSldUIHNwZWMuDQo+Pg0KPj4gSFRI
LA0KPj4NCj4+ID1KZWZmSA0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+PiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4+T0F1dGhAaWV0Zi5vcmc8
bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4+DQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1
dGgNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0
aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B
dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0K
T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0NCk5hdCBTYWtpbXVyYSAoPW5hdCkN
CkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtpbXVyYS5vcmcvDQpA
X25hdF9lbg0K

--_000_ca5dd691f5dd40dab01ab97fa79d8951BY2PR03MB041namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDgg
MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3Nl
LTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGli
cmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9u
dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0
IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJ
cGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmgxDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
Ow0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDEgQ2hhciI7DQoJbWFyZ2luLXRvcDoxMi4wcHQ7
DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDow
aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJ
Zm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSBMaWdodCIsInNhbnMtc2Vy
aWYiOw0KCWNvbG9yOiMyRTc0QjU7DQoJZm9udC13ZWlnaHQ6bm9ybWFsO30NCmgyDQoJe21zby1z
dHlsZS1saW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbWFyZ2luLXRvcDoxMi4wcHQ7DQoJbWFyZ2lu
LXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDozOS43cHQ7DQoJ
bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50Oi0zOS43cHQ7DQoJcGFnZS1icmVh
ay1hZnRlcjphdm9pZDsNCglwdW5jdHVhdGlvbi13cmFwOnNpbXBsZTsNCgl0ZXh0LWF1dG9zcGFj
ZTpub25lOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h
biIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2
aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5
OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9y
bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl
ZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwic2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp
Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXtt
c28tc3R5bGUtbmFtZToiSGVhZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1saW5rOiJIZWFkaW5n
IDIiOw0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJZm9udC13ZWln
aHQ6Ym9sZDt9DQpwLmVudW1sZXYxLCBsaS5lbnVtbGV2MSwgZGl2LmVudW1sZXYxDQoJe21zby1z
dHlsZS1uYW1lOmVudW1sZXYxOw0KCW1hcmdpbi10b3A6NC4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBp
bjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDozOS43cHQ7DQoJbWFyZ2luLWJv
dHRvbTouMDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWluZGVudDotMzkuN3B0
Ow0KCXB1bmN0dWF0aW9uLXdyYXA6c2ltcGxlOw0KCXRleHQtYXV0b3NwYWNlOm5vbmU7DQoJZm9u
dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N
CnNwYW4uSGVhZGluZzFDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDEgQ2hhciI7DQoJ
bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMSI7DQoJZm9u
dC1mYW1pbHk6IkNhbGlicmkgTGlnaHQiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMkU3NEI1O30N
Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt
aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg
bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2
IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw
ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N
CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9
IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+MTI1MiBzIGl0IGhhcyBhIHNlY3Rpb24gdGhhdCBleHBsYWlucyB0aGUg
dXNhZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPGgyPjxhIG5hbWU9Il9Ub2MyNTk0MzY0NDEiPjwvYT48YSBuYW1lPSJfVG9jMjYx
NDQwNjg3Ij48L2E+PGEgbmFtZT0iX1RvYzI2NjQzNDkzMyI+PC9hPjxhIG5hbWU9Il9Ub2MyNjc2
NDkzNzEiPjxzcGFuIGxhbmc9IkVOLUdCIj5BLjImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgQ2xhaW0vYXNzZXJ0aW9uPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1HQiI+PG86
cD48L286cD48L3NwYW4+PC9oMj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBtZWFuaW5nIG9m
IHRoZSB0ZXJtcyBjbGFpbSBhbmQgYXNzZXJ0aW9uIGFyZSBnZW5lcmFsbHkgYWdyZWVkIHRvIGJl
IHNvbWV3aGF0IHNpbWlsYXIgYnV0IHdpdGggc2xpZ2h0bHkgZGlmZmVyZW50IG1lYW5pbmdzLiBJ
biBzb21lIGNhc2VzLCBhbiBhc3NlcnRpb24gaXMgY29uc2lkZXJlZCB0byBiZSBhICZxdW90O3N0
cm9uZ2VyJnF1b3Q7IHN0YXRlbWVudCB0aGFuIGEgY2xhaW0uIEZvciBleGFtcGxlLCB0aGUgT3hm
b3JkDQogRW5nbGlzaCBEaWN0aW9uYXJ5IGRlZmluZXMgY2xhaW0gYXM6IDxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9ImVudW1sZXYxIj48c3BhbiBsYW5nPSJFTi1HQiI+YSkmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gc3RhdGUgYXMgYmVp
bmcgdGhlIGNhc2UsIHdpdGhvdXQgYmVpbmcgYWJsZSB0byBnaXZlIHByb29mOzxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJlbnVtbGV2MSI+PHNwYW4gbGFuZz0iRU4tR0IiPmIpJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgc3Rh
dGVtZW50IHRoYXQgc29tZXRoaW5nIGlzIHRoZSBjYXNlLA0KPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIGFzc2VydGlvbiBhczogYSBjb25maWRlbnQgYW5k
IGZvcmNlZnVsIHN0YXRlbWVudC4gSG93ZXZlciwgaW4gYSBkaWdpdGFsIGNvbnRleHQsIHRoZSB0
ZXJtcyAmcXVvdDtjb25maWRlbnQmcXVvdDsgYW5kICZxdW90O2ZvcmNlZnVsJnF1b3Q7IGFyZSBu
b3QgcmVhbGx5IG1lYW5pbmdmdWwuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpKQSI+SW4gb3BlbiBuZXR3b3Jr
cywgdGhlcmUgd2lsbCBiZSBhIG1vcmUgY29tcGxleCBhbmQgYW1iaXZhbGVudCByZWxhdGlvbnNo
aXAgYmV0d2VlbiB0aGUgcGFydHkgbWFraW5nIGEgc3RhdGVtZW50IChpLmUuLCBwcmVzZW50aW5n
IGlkZW50aXR5IGluZm9ybWF0aW9uKSBhbmQgdGhlIHBhcnR5IHRoYXQgcmVsaWVzIG9uIGl0LiBU
aGVyZWZvcmUsIGFueQ0KIHN0YXRlbWVudCBpcyBhc3N1bWVkIHRvIGJlIGluIGRvdWJ0IGFuZCwg
YXMgc3VjaCwgaXMgc3ViamVjdCB0byB2ZXJpZmljYXRpb24gb3IgcmVxdWVzdCBmb3IgZnVydGhl
ciBldmlkZW5jZS4gTmVpdGhlciBjbGFpbXMgbm9yIGFzc2VydGlvbnMgY2FuIGJlIGFzc3VtZWQg
dG8gYmUgbWFkZSB3aXRoIGFueSBhdXRob3JpdHkgd2hhdGV2ZXIuIEl0IHdpbGwgYWx3YXlzIGJl
IHVwIHRvIHRoZSByZWx5aW5nIHBhcnR5IHRvIGRlY2lkZSB3aGV0aGVyIG9yDQogbm90IHRvIGFj
Y2VwdCB0aGUgY2xhaW0gb3IgYXNzZXJ0aW9uIGJhc2VkIG9uIHZlcmlmaWNhdGlvbiBieSB0aGUg
cmVseWluZyBwYXJ0eSAob3IgYnkgYSB2ZXJpZmllciBhY3RpbmcgYXQgdGhlIHJlcXVlc3Qgb2Yg
dGhlIHJlbHlpbmcgcGFydHkpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh
bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp
bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7Ij4gTmF0IFNha2ltdXJhIFttYWlsdG86c2FraW11cmFAZ21haWwuY29t
XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBEZWNlbWJlciAyOSwgMjAxMiA4OjA0IFBN
PGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW48YnI+DQo8Yj5DYzo8L2I+IERhdmlkIENo
YWR3aWNrOyBNaWtlIEpvbmVzOyBJRVRGIG9hdXRoIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl
OiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9ueSwmbmJzcDs8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGRvIHlvdSBhZ3JlZSB3aXRoIHRoZSBm
b2xsb3dpbmcgZGVmaW5pdGlvbiBpbiAtMDY/IE9yIHByZWZlciBYLjEyNTIgZGVmaW5pdGlvbj8m
bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEyLjBwdCI+Q2xhaW0mbmJzcDsgQSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBhc3Nl
cnRlZCBhYm91dCBhIHN1YmplY3QuJm5ic3A7IEhlcmUsIENsYWltczxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSByZXByZXNlbnRlZCBuYW1lL3ZhbHVlIHBhaXJzLCBjb25z
aXN0aW5nIG9mIGEgQ2xhaW0gTmFtZSBhbmQgYTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy
ZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IENsYWltIFZhbHVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+TWlrZTombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoZSBvcmRlcmluZyBvZiB0aGUgdGVybXMgaW4gdGVybWlu
b2xvZ3ksIHlvdSBzaG91bGQgZWl0aGVyIHVzZSB0aGUgZGVwZW5kZW5jeSBjaGFpbiBvciBhbHBo
YWJldGljIG9yZGVyLiAoRm9ybWVyIGlzIG1vcmUgZGVzaXJhYmxlIGluIG15IHBvaW50IG9mIHZp
ZXcuKSBIb3dldmVyLCBhcyBpdCBzdGFuZHMsIGl0IGlzIG5vbmUgb2YgdGhvc2UuIEZvciBleGFt
cGxlLCB0aGUgdGVybSAmcXVvdDtjbGFpbSZxdW90Ow0KIGFwcGVhcnMgaW4gdGhlIGRlZmluaXRp
b24gb2YgSldULCB3aGljaCBpcyB0aGUgZmlyc3QgdGVybSBpbiB0aGUgdGVybWlub2xvZ3ksIHdp
dGhvdXQgaGF2aW5nIGJlZW4gZGVmaW5lZC4gSWYgeW91IGRvIG5vdCBtaW5kLCBJIHdpbGwgcmVv
cmRlciB0aGVtIGFuZCBzZW5kIGl0IHRvIHlvdS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0PG86cD48L286cD48L3A+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgRGVjIDMwLCAyMDEyIGF0
IDk6MjggQU0sIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRvbnluYWRAbWlj
cm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7
IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt
YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkJ5IGRlZmluaXRpb24gYSBjbGFpbSBpcyBhbHdheXMgaW4gZG91YnQgdGh1cyBpdCB3b3VsZCBu
b3QgY2FsbCBpdCBhIGNyZWRlbnRpYWwgdW50aWwgaXQgaXMgdmVyaWZpZWQ8bzpwPjwvbzpwPjwv
cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQotLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3Jn
Ij5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpvYXV0
aC1ib3VuY2VzQGlldGYub3JnIj5vYXV0aC1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxm
IE9mIERhdmlkIENoYWR3aWNrPGJyPg0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDI5LCAyMDEy
IDE6NDIgQU08YnI+DQpUbzogTWlrZSBKb25lczxicj4NCkNjOiBJRVRGIG9hdXRoIFdHPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Vi
amVjdDogUmU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRv
a2VuLTA1PGJyPg0KPGJyPg0KSWYgYSBjbGFpbSBwcm92aWRlcyBwcm9vZiB0aGVuIEkgd291bGQg
Y2FsbCBpdCBhIGNyZWRlbnRpYWwgbm90IGEgY2xhaW08YnI+DQo8YnI+DQpEYXZpZDxicj4NCjxi
cj4NCk9uIDI5LzEyLzIwMTIgMDE6MTEsIE1pa2UgSm9uZXMgd3JvdGU6PGJyPg0KJmd0OyBJIGZv
dW5kIHRoZSBYLjEyNTIgZGVmaW5pdGlvbi4gJm5ic3A7SXQgaXM6PGJyPg0KJmd0Ozxicj4NCiZn
dDsgKjYuMTggY2xhaW0gKltiLU9FRF06IFRvIHN0YXRlIGFzIGJlaW5nIHRoZSBjYXNlLCB3aXRo
b3V0IGJlaW5nIGFibGU8YnI+DQomZ3Q7IHRvIGdpdmUgcHJvb2YuPGJyPg0KJmd0Ozxicj4NCiZn
dDsgVGhhdCBzZWVtcyBib3RoIGEgYml0IHZhZ3VlLCBhbmQgYWN0dWFsbHkgaW5jb3JyZWN0LCBh
cyB0aGUgSldUIG1heTxicj4NCiZndDsgaW5jbHVkZSBwcm9vZiBvZiB0aGUgdmVyYWNpdHkgb2Yg
dGhlIGNsYWltLiAmbmJzcDtQbGVhc2Ugc2VlIHRoZSB1cGRhdGVkPGJyPg0KJmd0OyBKV1QgZHJh
ZnQgZm9yIGEgaG9wZWZ1bGx5IG1vcmUgdXNlZnVsIOKAnENsYWlt4oCdIGRlZmluaXRpb24uPGJy
Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7QmVzdDxicj4NCiZndDsgd2lzaGVzLDxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy0tIE1pa2U8YnI+DQomZ3Q7PGJy
Pg0KJmd0OyAqRnJvbToqTWlrZSBKb25lczxicj4NCiZndDsgKlNlbnQ6KiBTdW5kYXksIERlY2Vt
YmVyIDIzLCAyMDEyIDE6MDMgUE08YnI+DQomZ3Q7ICpUbzoqIEplZmYgSG9kZ2VzOyBOYXQgU2Fr
aW11cmE8YnI+DQomZ3Q7ICpDYzoqIElFVEYgb2F1dGggV0c8YnI+DQomZ3Q7ICpTdWJqZWN0Oiog
UkU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1
PGJyPg0KJmd0Ozxicj4NCiZndDsgV2hhdCBpcyB0aGUgWC4xMjUyIGRlZmluaXRpb24/PGJyPg0K
Jmd0Ozxicj4NCiZndDsgLS0gTWlrZTxicj4NCiZndDs8YnI+DQomZ3Q7ICpGcm9tOiogTmF0IFNh
a2ltdXJhPGJyPg0KJmd0OyAqU2VudDoqIOKAjkRlY2VtYmVy4oCOIOKAjjIz4oCOLCDigI4yMDEy
IOKAjjEw4oCOOuKAjjA54oCOIOKAjkFNPGJyPg0KJmd0OyAqVG86KiA9SmVmZkg8YnI+DQomZ3Q7
ICpDQzoqIE1pa2UgSm9uZXMsIElFVEYgb2F1dGggV0c8YnI+DQomZ3Q7ICpTdWJqZWN0OiogUmU6
IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1PGJy
Pg0KJmd0Ozxicj4NCiZndDsgUmUgZGVmaW5pdGlvbiBvZiAnY2xhaW0nLCBhcyBKV1QgaXMgc3Vw
cG9zZWQgdG8gYmUgZ2VuZXJpYywgaXQgbWF5IGJlPGJyPg0KJmd0OyBiZXR0ZXIgdG8gZ28gd2l0
aCB0aGUgZGVmaW5pdGlvbiBvZiBYLjEyNTIgcmF0aGVyIHRoYW4gT0lEQy48YnI+DQomZ3Q7PGJy
Pg0KJmd0OyA9bmF0IHZpYSBpUGhvbmU8YnI+DQomZ3Q7PGJyPg0KJmd0OyBEZWMgMjQsIDIwMTIg
Mjo0MjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDsiPuOAgTwvc3Bhbj49SmVmZkggJmx0OzxhIGhyZWY9Im1haWx0bzpKZWZm
LkhvZGdlc0BraW5nc21vdW50YWluLmNvbSI+SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb208
L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpKZWZmLkhvZGdlc0BraW5n
c21vdW50YWluLmNvbSI+SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb208L2E+Jmd0OyZndDsN
CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPuOBruODoeODg+OCu+ODvOOCuDwvc3Bhbj46PGJyPg0KJmd0Ozxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBUaGFua3MgZm9yIHRoZSByZXBsaWVzLCBKZWZmLiAm
bmJzcDtUaGV5IG1ha2Ugc2Vuc2UuICZuYnNwO1BhcnRpY3VsYXJseSw8YnI+DQomZ3Q7Jmd0OyAm
Z3Q7IHRoYW5rcyBmb3IgdGhlICZxdW90O0pTT04gVGV4dCBPYmplY3QmcXVvdDsgc3VnZ2VzdGlv
bi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHdlbGNvbWUsIGdsYWQgdGhleSBtYWRlIHNv
bWUgc2Vuc2UuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBzaW1pbGFybHksIGlmIG9uZSBl
bXBsb3lzIEpTT04gYXJyYXlzLCBJJ2QgZGVmaW5lIGEgJnF1b3Q7SlNPTiB0ZXh0IGFycmF5JnF1
b3Q7Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEZvciB0
aGUgJnF1b3Q7Y2xhaW1zJnF1b3Q7IGRlZmluaXRpb24sIEknbSBhY3R1YWxseSBwcm9uZSB0byBn
byB3aXRoPGJyPg0KJmd0OyZndDsgJmd0O2RlZmluaXRpb25zIGJhc2VkICZuYnNwO29uIHRob3Nl
IGluPGJyPg0KJmd0OyZndDsgJmd0OzxhIGhyZWY9Imh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29w
ZW5pZC1jb25uZWN0LW1lc3NhZ2VzLTFfMC0xMy5odG1sI3Rlcm1pbm9sIiB0YXJnZXQ9Il9ibGFu
ayI+aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtbWVzc2FnZXMtMV8wLTEz
Lmh0bWwjdGVybWlub2w8L2E+PGJyPg0KJmd0OyZndDsgJmd0O29neS08YnI+DQomZ3Q7Jmd0OyAm
Z3Q7IHNwZWNpZmljYWxseTo8YnI+DQomZ3Q7Jmd0OyAmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBD
bGFpbTxicj4NCiZndDsmZ3Q7ICZndDsgQSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBhYm91dCBhbiBF
bnRpdHkgdGhhdCBhIENsYWltcyBQcm92aWRlcjxicj4NCiZndDsmZ3Q7ICZndDsgYXNzZXJ0cyBh
Ym91dCB0aGF0IEVudGl0eS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7IENsYWltcyBQcm92aWRlcjxicj4N
CiZndDsmZ3Q7ICZndDsgQSBzeXN0ZW0gb3Igc2VydmljZSB0aGF0IGNhbiByZXR1cm4gQ2xhaW1z
IGFib3V0IGFuIEVudGl0eS48YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEVuZC1Vc2VyPGJyPg0KJmd0OyZn
dDsgJmd0OyBBIGh1bWFuIHVzZXIgb2YgYSBzeXN0ZW0gb3Igc2VydmljZS48YnI+DQomZ3Q7Jmd0
OyAmZ3Q7IEVudGl0eTxicj4NCiZndDsmZ3Q7ICZndDsgU29tZXRoaW5nIHRoYXQgaGFzIGEgc2Vw
YXJhdGUgYW5kIGRpc3RpbmN0IGV4aXN0ZW5jZSBhbmQgdGhhdCBjYW48YnI+DQomZ3Q7Jmd0OyAm
Z3Q7IGJlIGlkZW50aWZpZWQgaW4gY29udGV4dC4gQW4gRW5kLVVzZXIgaXMgb25lIGV4YW1wbGUg
b2YgYW4gRW50aXR5Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgd2VsbCwgaXQgc2VlbXMg
dG8gbWUsIGdpdmVuIHRoZSBtYW5uZXIgaW4gd2hpY2ggdGhlIEpXVCBzcGVjIGlzPGJyPg0KJmd0
OyZndDsgd3JpdHRlbiwgb25lIGNhbiBtYWtlIHRoZSBjYXNlIHRoYXQgSldUIGNsYWltcyBpbiBn
ZW5lcmFsIGFyZW4ndDxicj4NCiZndDsmZ3Q7IG5lY2Vzc2FyaWx5IGFib3V0IGFuIEVudGl0eSAo
YXMgdGhlIGxhdHRlciB0ZXJtIGlzIHVzZWQgaW4gdGhlPGJyPg0KJmd0OyZndDsgY29udGV4dCBv
ZiB0aGUgT3BlbklEIENvbm5lY3Qgc3BlY3MpLCByYXRoZXIgdGhleSdyZSBpbiBnZW5lcmFsPGJy
Pg0KJmd0OyZndDsgc2ltcGx5IGFzc2VydGlvbnMgYWJvdXQgc29tZXRoaW5nKHMpLiB0aGlzIGlz
IGJlY2F1c2UgYWxsIHByZS1kZWZpbmVkPGJyPg0KJmd0OyBKV1QgY2xhaW0gdHlwZXMgYXJlIG9w
dGlvbmFsIGFuZCBhbGwgSldUIHNlbWFudGljcyBhcmUgbGVmdCB1cCB0bzxicj4NCiZndDsgc3Bl
Y3MgdGhhdCBwcm9maWxlIChha2EgcmUtdXNlKSB0aGUgSldUIHNwZWMuPGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyBIVEgsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA9SmVmZkg8YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0
OyZndDs8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiAm
bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8
L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJy
Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi
cj4NCiZndDsgT0F1dGggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86T0F1
dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KJmd0Ozxi
cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
T0F1dGggbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5P
QXV0aEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aDwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy
ZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJf
YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvcD4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KTmF0IFNha2ltdXJhICg9bmF0KTxvOnA+
PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoYWlybWFuLCBPcGVuSUQg
Rm91bmRhdGlvbjxicj4NCjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+DQpAX25hdF9lbjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_ca5dd691f5dd40dab01ab97fa79d8951BY2PR03MB041namprd03pro_--

From Michael.Jones@microsoft.com  Sat Dec 29 23:54:23 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B739F21F8922 for ; Sat, 29 Dec 2012 23:54:23 -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.011, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGy6IpUWCKZa for ; Sat, 29 Dec 2012 23:54:22 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.23]) by ietfa.amsl.com (Postfix) with ESMTP id AB06321F88AC for ; Sat, 29 Dec 2012 23:54:21 -0800 (PST)
Received: from BY2FFO11FD015.protection.gbl (10.1.15.202) by BY2FFO11HUB013.protection.gbl (10.1.14.85) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 07:54:12 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 30 Dec 2012 07:54:11 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Sun, 30 Dec 2012 07:54:11 +0000
From: Mike Jones 
To: Nat Sakimura , Anthony Nadalin 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYXPoELEFPMRSTq+X4Nh79LI8wgAR1McAAB7zZYAAB4U7gAAHpyBQ
Date: Sun, 30 Dec 2012 07:54:10 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669E05E8@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk> <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.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.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669E05E8TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(24454001)(51704002)(13464002)(479174001)(51914002)(55846006)(56776001)(59766001)(512874001)(50986001)(33656001)(49866001)(51856001)(54316002)(31966008)(47736001)(77982001)(76482001)(5343645001)(16236675001)(47976001)(4396001)(56816002)(46102001)(74502001)(47446002)(53806001)(5343655001)(54356001)(44976002)(15395725002)(5343635001)(550184003)(16406001)(15202345001)(74662001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB013; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 071156160B
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 07:54:23 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943669E05E8TK5EX14MBXC283r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhlIHByb2JsZW0gd2l0aCB0aGUgWC4xMjUyIGRlZmluaXRpb24gaXMgaXQgdW5uZWNlc3Nhcmls
eSBhZGRzIHRoZSDigJx3aXRob3V0IGJlaW5nIGFibGUgdG8gZ2l2ZSBwcm9vZuKAnSBjb21tZW50
LiAgVGhhdCB3aWxsIGRpc3RyYWN0IHRoZSByZWFkZXIgaW1tZWRpYXRlbHkuICBUaGUgY3VycmVu
dCDigJxhIHBpZWNlIG9mIGluZm9ybWF0aW9uIGFzc2VydGVkIGFib3V0IGEgc3ViamVjdOKAnSBk
ZWZpbml0aW9uIGlzIGp1c3QgYXMgYWNjdXJhdGUgYXMgdGhlIFguMTI1MiBhbmQgZG9lc27igJl0
IHNlbmQgcmVhZGVycyBkb3duIGEgbWVudGFsIHJhdGhvbGUuDQoNCldlIGNhbiBhZGQgYW4gaW5m
b3JtYXRpdmUgcmVmZXJlbmNlIHRvIFguMTI1MiBpZiB5b3UgbGlrZSwgYnV0IEkgcmVhbGx5IHRo
aW5rIHJlYWRhYmlsaXR5IGFuZCBzaW1wbGljaXR5IGFyZSBtb3JlIGltcG9ydGFudCBpbiB0aGlz
IGtpbmQgb2YgYSBzcGVjIHRoYW4gcmV1c2luZyBvdmVybHkgdGVjaG5pY2FsIGFuZCBvZmYtcHV0
dGluZyBJU08gZGVmaW5pdGlvbnMuDQoNCkFib3V0IHRoZSB0ZXJtaW5vbG9neSBvcmRlcmluZywg
dGhlIGN1cnJlbnQgb3JkZXIgaXMgaW50ZW5kZWQgdG8gYmUgd2hhdCBJIHRoaW5rIHlvdSB3b3Vs
ZCBjYWxsIGEgcmV2ZXJzZSBkZXBlbmRlbmN5IGNoYWluIOKAkyB3aGF0IEkgd291bGQgY2FsbCBh
IHRvcC1kb3duIG9yZGVyaW5nLiAgSXTigJlzIHRoYXQgd2F5IHNvIHRoYXQgdGhlIEpTT04gV2Vi
IFRva2VuIGRlZmluaXRpb24gaXMgZmlyc3QuICBUaGVuLCBhcyB0aGF0IGRlZmluaXRpb24gbmVl
ZHMgb3RoZXIgZGVmaW5pdGlvbnMsIHRoZXkgaW1tZWRpYXRlbHkgZm9sbG93LiAgVGhpcyBpcyBp
bnRlbmRlZCBpbmNyZWFzZSByZWFkYWJpbGl0eSwgYnkgcHJlc2VudGluZyBjb25jZXB0cyBpbiBh
IHRvcC1kb3duIG1hbm5lci4gIEJ5IGNvbXBhcmlzb24sIGJvdHRvbS11cCBvcmRlcmluZyBtYWtl
cyByZWFkZXJzIHdhZGUgdGhyb3VnaCBhIHNlYSBvZiBvdGhlciB0ZXJtcyBiZWZvcmUgZ2V0dGlu
ZyB0byB0aGUgb25lIHRoZXkgcmVhbGx5IGNhcmVkIGFib3V0Lg0KDQpJZiB5b3Ugd2FudCB0byBy
ZW9yZGVyIHRoZSB0ZXJtcyB0byBtYWtlIHN1cmUgdGhleeKAmXJlIGluIHRoZSBiZXN0IHRvcC1k
b3duIG9yZGVyIHBvc3NpYmxlLCB0aGF0IHdvdWxkIGJlIHVzZWZ1bC4gIChJZiB5b3UgZGVjaWRl
IHRvIGRvIHRoYXQsIEnigJlkIGFsc28gbG9vayBhdCB0aGUgdGVybWlub2xvZ3kgb3JkZXJpbmcg
aW4gSldTLCBKV0UsIGFuZCBKV0ssIGFzIHdlIHNob3VsZCBiZSBhcyBjb25zaXN0ZW50IGFzIHBv
c3NpYmxlIGFjcm9zcyB0aGUgc3BlY2lmaWNhdGlvbnMuDQoNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTog
TmF0IFNha2ltdXJhIFttYWlsdG86c2FraW11cmFAZ21haWwuY29tXQ0KU2VudDogU2F0dXJkYXks
IERlY2VtYmVyIDI5LCAyMDEyIDg6MDQgUE0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBEYXZp
ZCBDaGFkd2ljazsgTWlrZSBKb25lczsgSUVURiBvYXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVU
SC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1DQoNClRvbnks
DQoNClNvIGRvIHlvdSBhZ3JlZSB3aXRoIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBpbiAtMDY/
IE9yIHByZWZlciBYLjEyNTIgZGVmaW5pdGlvbj8NCg0KDQpDbGFpbSAgQSBwaWVjZSBvZiBpbmZv
cm1hdGlvbiBhc3NlcnRlZCBhYm91dCBhIHN1YmplY3QuICBIZXJlLCBDbGFpbXMNCg0KICAgICAg
YXJlIHJlcHJlc2VudGVkIG5hbWUvdmFsdWUgcGFpcnMsIGNvbnNpc3Rpbmcgb2YgYSBDbGFpbSBO
YW1lIGFuZCBhDQoNCiAgICAgIENsYWltIFZhbHVlLg0KDQpNaWtlOg0KDQpSZWdhcmRpbmcgdGhl
IG9yZGVyaW5nIG9mIHRoZSB0ZXJtcyBpbiB0ZXJtaW5vbG9neSwgeW91IHNob3VsZCBlaXRoZXIg
dXNlIHRoZSBkZXBlbmRlbmN5IGNoYWluIG9yIGFscGhhYmV0aWMgb3JkZXIuIChGb3JtZXIgaXMg
bW9yZSBkZXNpcmFibGUgaW4gbXkgcG9pbnQgb2Ygdmlldy4pIEhvd2V2ZXIsIGFzIGl0IHN0YW5k
cywgaXQgaXMgbm9uZSBvZiB0aG9zZS4gRm9yIGV4YW1wbGUsIHRoZSB0ZXJtICJjbGFpbSIgYXBw
ZWFycyBpbiB0aGUgZGVmaW5pdGlvbiBvZiBKV1QsIHdoaWNoIGlzIHRoZSBmaXJzdCB0ZXJtIGlu
IHRoZSB0ZXJtaW5vbG9neSwgd2l0aG91dCBoYXZpbmcgYmVlbiBkZWZpbmVkLiBJZiB5b3UgZG8g
bm90IG1pbmQsIEkgd2lsbCByZW9yZGVyIHRoZW0gYW5kIHNlbmQgaXQgdG8geW91Lg0KDQpOYXQN
Cg0KT24gU3VuLCBEZWMgMzAsIDIwMTIgYXQgOToyOCBBTSwgQW50aG9ueSBOYWRhbGluIDx0b255
bmFkQG1pY3Jvc29mdC5jb208bWFpbHRvOnRvbnluYWRAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K
QnkgZGVmaW5pdGlvbiBhIGNsYWltIGlzIGFsd2F5cyBpbiBkb3VidCB0aHVzIGl0IHdvdWxkIG5v
dCBjYWxsIGl0IGEgY3JlZGVudGlhbCB1bnRpbCBpdCBpcyB2ZXJpZmllZA0KDQotLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogb2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPG1haWx0
bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIERhdmlkIENoYWR3aWNrDQpT
ZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMjksIDIwMTIgMTo0MiBBTQ0KVG86IE1pa2UgSm9uZXMN
CkNjOiBJRVRGIG9hdXRoIFdHDQpTdWJqZWN0OiBSZTogW09BVVRILVdHXSByZXZpZXc6IGRyYWZ0
LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDUNCg0KSWYgYSBjbGFpbSBwcm92aWRlcyBwcm9v
ZiB0aGVuIEkgd291bGQgY2FsbCBpdCBhIGNyZWRlbnRpYWwgbm90IGEgY2xhaW0NCg0KRGF2aWQN
Cg0KT24gMjkvMTIvMjAxMiAwMToxMSwgTWlrZSBKb25lcyB3cm90ZToNCj4gSSBmb3VuZCB0aGUg
WC4xMjUyIGRlZmluaXRpb24uICBJdCBpczoNCj4NCj4gKjYuMTggY2xhaW0gKltiLU9FRF06IFRv
IHN0YXRlIGFzIGJlaW5nIHRoZSBjYXNlLCB3aXRob3V0IGJlaW5nIGFibGUNCj4gdG8gZ2l2ZSBw
cm9vZi4NCj4NCj4gVGhhdCBzZWVtcyBib3RoIGEgYml0IHZhZ3VlLCBhbmQgYWN0dWFsbHkgaW5j
b3JyZWN0LCBhcyB0aGUgSldUIG1heQ0KPiBpbmNsdWRlIHByb29mIG9mIHRoZSB2ZXJhY2l0eSBv
ZiB0aGUgY2xhaW0uICBQbGVhc2Ugc2VlIHRoZSB1cGRhdGVkDQo+IEpXVCBkcmFmdCBmb3IgYSBo
b3BlZnVsbHkgbW9yZSB1c2VmdWwg4oCcQ2xhaW3igJ0gZGVmaW5pdGlvbi4NCj4NCj4gICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEJl
c3QNCj4gd2lzaGVzLA0KPg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KPg0KPiAqRnJvbToqTWlrZSBKb25lcw0K
PiAqU2VudDoqIFN1bmRheSwgRGVjZW1iZXIgMjMsIDIwMTIgMTowMyBQTQ0KPiAqVG86KiBKZWZm
IEhvZGdlczsgTmF0IFNha2ltdXJhDQo+ICpDYzoqIElFVEYgb2F1dGggV0cNCj4gKlN1YmplY3Q6
KiBSRTogW09BVVRILVdHXSByZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4t
MDUNCj4NCj4gV2hhdCBpcyB0aGUgWC4xMjUyIGRlZmluaXRpb24/DQo+DQo+IC0tIE1pa2UNCj4N
Cj4gKkZyb206KiBOYXQgU2FraW11cmENCj4gKlNlbnQ6KiDigI5EZWNlbWJlcuKAjiDigI4yM+KA
jiwg4oCOMjAxMiDigI4xMOKAjjrigI4wOeKAjiDigI5BTQ0KPiAqVG86KiA9SmVmZkgNCj4gKkND
OiogTWlrZSBKb25lcywgSUVURiBvYXV0aCBXRw0KPiAqU3ViamVjdDoqIFJlOiBbT0FVVEgtV0dd
IHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNQ0KPg0KPiBSZSBkZWZp
bml0aW9uIG9mICdjbGFpbScsIGFzIEpXVCBpcyBzdXBwb3NlZCB0byBiZSBnZW5lcmljLCBpdCBt
YXkgYmUNCj4gYmV0dGVyIHRvIGdvIHdpdGggdGhlIGRlZmluaXRpb24gb2YgWC4xMjUyIHJhdGhl
ciB0aGFuIE9JREMuDQo+DQo+ID1uYXQgdmlhIGlQaG9uZQ0KPg0KPiBEZWMgMjQsIDIwMTIgMjo0
MuOAgT1KZWZmSCA8SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb208bWFpbHRvOkplZmYuSG9k
Z2VzQGtpbmdzbW91bnRhaW4uY29tPg0KPiA8bWFpbHRvOkplZmYuSG9kZ2VzQGtpbmdzbW91bnRh
aW4uY29tPG1haWx0bzpKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbT4+PiDjga7jg6Hjg4Pj
grvjg7zjgrg6DQo+DQo+Pg0KPj4gPiBUaGFua3MgZm9yIHRoZSByZXBsaWVzLCBKZWZmLiAgVGhl
eSBtYWtlIHNlbnNlLiAgUGFydGljdWxhcmx5LA0KPj4gPiB0aGFua3MgZm9yIHRoZSAiSlNPTiBU
ZXh0IE9iamVjdCIgc3VnZ2VzdGlvbi4NCj4+DQo+PiB3ZWxjb21lLCBnbGFkIHRoZXkgbWFkZSBz
b21lIHNlbnNlLg0KPj4NCj4+IHNpbWlsYXJseSwgaWYgb25lIGVtcGxveXMgSlNPTiBhcnJheXMs
IEknZCBkZWZpbmUgYSAiSlNPTiB0ZXh0IGFycmF5Ii4NCj4+DQo+Pg0KPj4gPiBGb3IgdGhlICJj
bGFpbXMiIGRlZmluaXRpb24sIEknbSBhY3R1YWxseSBwcm9uZSB0byBnbyB3aXRoDQo+PiA+ZGVm
aW5pdGlvbnMgYmFzZWQgIG9uIHRob3NlIGluDQo+PiA+aHR0cDovL29wZW5pZC5uZXQvc3BlY3Mv
b3BlbmlkLWNvbm5lY3QtbWVzc2FnZXMtMV8wLTEzLmh0bWwjdGVybWlub2wNCj4+ID5vZ3ktDQo+
PiA+IHNwZWNpZmljYWxseToNCj4+ID4NCj4+ID4gQ2xhaW0NCj4+ID4gQSBwaWVjZSBvZiBpbmZv
cm1hdGlvbiBhYm91dCBhbiBFbnRpdHkgdGhhdCBhIENsYWltcyBQcm92aWRlcg0KPj4gPiBhc3Nl
cnRzIGFib3V0IHRoYXQgRW50aXR5Lg0KPj4gPiBDbGFpbXMgUHJvdmlkZXINCj4+ID4gQSBzeXN0
ZW0gb3Igc2VydmljZSB0aGF0IGNhbiByZXR1cm4gQ2xhaW1zIGFib3V0IGFuIEVudGl0eS4NCj4+
ID4gRW5kLVVzZXINCj4+ID4gQSBodW1hbiB1c2VyIG9mIGEgc3lzdGVtIG9yIHNlcnZpY2UuDQo+
PiA+IEVudGl0eQ0KPj4gPiBTb21ldGhpbmcgdGhhdCBoYXMgYSBzZXBhcmF0ZSBhbmQgZGlzdGlu
Y3QgZXhpc3RlbmNlIGFuZCB0aGF0IGNhbg0KPj4gPiBiZSBpZGVudGlmaWVkIGluIGNvbnRleHQu
IEFuIEVuZC1Vc2VyIGlzIG9uZSBleGFtcGxlIG9mIGFuIEVudGl0eS4NCj4+DQo+PiB3ZWxsLCBp
dCBzZWVtcyB0byBtZSwgZ2l2ZW4gdGhlIG1hbm5lciBpbiB3aGljaCB0aGUgSldUIHNwZWMgaXMN
Cj4+IHdyaXR0ZW4sIG9uZSBjYW4gbWFrZSB0aGUgY2FzZSB0aGF0IEpXVCBjbGFpbXMgaW4gZ2Vu
ZXJhbCBhcmVuJ3QNCj4+IG5lY2Vzc2FyaWx5IGFib3V0IGFuIEVudGl0eSAoYXMgdGhlIGxhdHRl
ciB0ZXJtIGlzIHVzZWQgaW4gdGhlDQo+PiBjb250ZXh0IG9mIHRoZSBPcGVuSUQgQ29ubmVjdCBz
cGVjcyksIHJhdGhlciB0aGV5J3JlIGluIGdlbmVyYWwNCj4+IHNpbXBseSBhc3NlcnRpb25zIGFi
b3V0IHNvbWV0aGluZyhzKS4gdGhpcyBpcyBiZWNhdXNlIGFsbCBwcmUtZGVmaW5lZA0KPiBKV1Qg
Y2xhaW0gdHlwZXMgYXJlIG9wdGlvbmFsIGFuZCBhbGwgSldUIHNlbWFudGljcyBhcmUgbGVmdCB1
cCB0bw0KPiBzcGVjcyB0aGF0IHByb2ZpbGUgKGFrYSByZS11c2UpIHRoZSBKV1Qgc3BlYy4NCj4+
DQo+PiBIVEgsDQo+Pg0KPj4gPUplZmZIDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4+IE9BdXRoIG1haWxpbmcgbGlzdA0KPj5PQXV0aEBp
ZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc8bWFp
bHRvOk9BdXRoQGlldGYub3JnPj4NCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aA0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0Zi5vcmc8bWFp
bHRvOk9BdXRoQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL29hdXRoDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KT0F1dGggbWFpbGluZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0
Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KT0F1dGggbWFpbGlu
ZyBsaXN0DQpPQXV0aEBpZXRmLm9yZzxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCg0KDQotLQ0KTmF0IFNha2ltdXJh
ICg9bmF0KQ0KQ2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9uDQpodHRwOi8vbmF0LnNha2ltdXJh
Lm9yZy8NCkBfbmF0X2VuDQo=

--_000_4E1F6AAD24975D4BA5B1680429673943669E05E8TK5EX14MBXC283r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ
cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUg
OCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt
YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7
DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy
aWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs
IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv
bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi
Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj
ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5
bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu
cy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvbnNvbGFzIiwi
c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3
RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v
biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl
ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w
aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN
Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht
bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6
ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl
bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp
bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj5UaGUgcHJvYmxlbSB3aXRoIHRoZSBYLjEyNTIgZGVmaW5pdGlvbiBpcyBpdCB1bm5lY2Vz
c2FyaWx5IGFkZHMgdGhlIOKAnHdpdGhvdXQgYmVpbmcgYWJsZSB0byBnaXZlIHByb29m4oCdIGNv
bW1lbnQuJm5ic3A7IFRoYXQgd2lsbCBkaXN0cmFjdCB0aGUgcmVhZGVyIGltbWVkaWF0ZWx5LiZu
YnNwOw0KIFRoZSBjdXJyZW50IOKAnGEgcGllY2Ugb2YgaW5mb3JtYXRpb24gYXNzZXJ0ZWQgYWJv
dXQgYSBzdWJqZWN04oCdIGRlZmluaXRpb24gaXMganVzdCBhcyBhY2N1cmF0ZSBhcyB0aGUgWC4x
MjUyIGFuZCBkb2VzbuKAmXQgc2VuZCByZWFkZXJzIGRvd24gYSBtZW50YWwgcmF0aG9sZS48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPldlIGNhbiBhZGQgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIHRvIFguMTI1MiBpZiB5
b3UgbGlrZSwgYnV0IEkgcmVhbGx5IHRoaW5rIHJlYWRhYmlsaXR5IGFuZCBzaW1wbGljaXR5IGFy
ZSBtb3JlIGltcG9ydGFudCBpbiB0aGlzIGtpbmQgb2YgYSBzcGVjIHRoYW4gcmV1c2luZw0KIG92
ZXJseSB0ZWNobmljYWwgYW5kIG9mZi1wdXR0aW5nIElTTyBkZWZpbml0aW9ucy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PkFib3V0IHRoZSB0ZXJtaW5vbG9neSBvcmRlcmluZywgdGhlIGN1cnJlbnQgb3JkZXIgaXMgaW50
ZW5kZWQgdG8gYmUgd2hhdCBJIHRoaW5rIHlvdSB3b3VsZCBjYWxsIGEgcmV2ZXJzZSBkZXBlbmRl
bmN5IGNoYWluIOKAkyB3aGF0IEkgd291bGQgY2FsbCBhIHRvcC1kb3duIG9yZGVyaW5nLiZuYnNw
Ow0KIEl04oCZcyB0aGF0IHdheSBzbyB0aGF0IHRoZSBKU09OIFdlYiBUb2tlbiBkZWZpbml0aW9u
IGlzIGZpcnN0LiZuYnNwOyBUaGVuLCBhcyB0aGF0IGRlZmluaXRpb24gbmVlZHMgb3RoZXIgZGVm
aW5pdGlvbnMsIHRoZXkgaW1tZWRpYXRlbHkgZm9sbG93LiZuYnNwOyBUaGlzIGlzIGludGVuZGVk
IGluY3JlYXNlIHJlYWRhYmlsaXR5LCBieSBwcmVzZW50aW5nIGNvbmNlcHRzIGluIGEgdG9wLWRv
d24gbWFubmVyLiZuYnNwOyBCeSBjb21wYXJpc29uLCBib3R0b20tdXAgb3JkZXJpbmcNCiBtYWtl
cyByZWFkZXJzIHdhZGUgdGhyb3VnaCBhIHNlYSBvZiBvdGhlciB0ZXJtcyBiZWZvcmUgZ2V0dGlu
ZyB0byB0aGUgb25lIHRoZXkgcmVhbGx5IGNhcmVkIGFib3V0LjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgeW91IHdh
bnQgdG8gcmVvcmRlciB0aGUgdGVybXMgdG8gbWFrZSBzdXJlIHRoZXnigJlyZSBpbiB0aGUgYmVz
dCB0b3AtZG93biBvcmRlciBwb3NzaWJsZSwgdGhhdCB3b3VsZCBiZSB1c2VmdWwuJm5ic3A7IChJ
ZiB5b3UgZGVjaWRlIHRvIGRvIHRoYXQsIEnigJlkIGFsc28gbG9vayBhdA0KIHRoZSB0ZXJtaW5v
bG9neSBvcmRlcmluZyBpbiBKV1MsIEpXRSwgYW5kIEpXSywgYXMgd2Ugc2hvdWxkIGJlIGFzIGNv
bnNpc3RlbnQgYXMgcG9zc2libGUgYWNyb3NzIHRoZSBzcGVjaWZpY2F0aW9ucy48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPiBOYXQgU2FraW11cmEgW21haWx0bzpzYWtpbXVyYUBnbWFpbC5jb21dDQo8YnI+DQo8
Yj5TZW50OjwvYj4gU2F0dXJkYXksIERlY2VtYmVyIDI5LCAyMDEyIDg6MDQgUE08YnI+DQo8Yj5U
bzo8L2I+IEFudGhvbnkgTmFkYWxpbjxicj4NCjxiPkNjOjwvYj4gRGF2aWQgQ2hhZHdpY2s7IE1p
a2UgSm9uZXM7IElFVEYgb2F1dGggV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtPQVVUSC1X
R10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub255LCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gZG8geW91IGFncmVlIHdpdGggdGhlIGZvbGxvd2luZyBk
ZWZpbml0aW9uIGluIC0wNj8gT3IgcHJlZmVyIFguMTI1MiBkZWZpbml0aW9uPyZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTIuMHB0Ij5DbGFpbSZuYnNwOyBBIHBpZWNlIG9mIGluZm9ybWF0aW9uIGFzc2VydGVkIGFib3V0
IGEgc3ViamVjdC4mbmJzcDsgSGVyZSwgQ2xhaW1zPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8
cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgYXJlIHJlcHJlc2VudGVkIG5hbWUvdmFsdWUgcGFpcnMsIGNvbnNpc3Rpbmcgb2Yg
YSBDbGFpbSBOYW1lIGFuZCBhPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2xh
aW0gVmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWtlOiZu
YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5SZWdhcmRpbmcgdGhlIG9yZGVyaW5nIG9mIHRoZSB0ZXJtcyBpbiB0ZXJtaW5vbG9neSwgeW91
IHNob3VsZCBlaXRoZXIgdXNlIHRoZSBkZXBlbmRlbmN5IGNoYWluIG9yIGFscGhhYmV0aWMgb3Jk
ZXIuIChGb3JtZXIgaXMgbW9yZSBkZXNpcmFibGUgaW4gbXkgcG9pbnQgb2Ygdmlldy4pIEhvd2V2
ZXIsIGFzIGl0IHN0YW5kcywgaXQgaXMgbm9uZSBvZiB0aG9zZS4gRm9yIGV4YW1wbGUsIHRoZSB0
ZXJtICZxdW90O2NsYWltJnF1b3Q7DQogYXBwZWFycyBpbiB0aGUgZGVmaW5pdGlvbiBvZiBKV1Qs
IHdoaWNoIGlzIHRoZSBmaXJzdCB0ZXJtIGluIHRoZSB0ZXJtaW5vbG9neSwgd2l0aG91dCBoYXZp
bmcgYmVlbiBkZWZpbmVkLiBJZiB5b3UgZG8gbm90IG1pbmQsIEkgd2lsbCByZW9yZGVyIHRoZW0g
YW5kIHNlbmQgaXQgdG8geW91LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBEZWMgMzAsIDIwMTIgYXQgOToyOCBBTSwg
QW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9ueW5hZEBtaWNyb3NvZnQuY29t
IiB0YXJnZXQ9Il9ibGFuayI+dG9ueW5hZEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CeSBkZWZpbml0aW9uIGEgY2xhaW0g
aXMgYWx3YXlzIGluIGRvdWJ0IHRodXMgaXQgd291bGQgbm90IGNhbGwgaXQgYSBjcmVkZW50aWFs
IHVudGlsIGl0IGlzIHZlcmlmaWVkPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiA8YSBo
cmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9y
ZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1
dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBEYXZpZCBDaGFkd2ljazxicj4N
ClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAyOSwgMjAxMiAxOjQyIEFNPGJyPg0KVG86IE1pa2Ug
Sm9uZXM8YnI+DQpDYzogSUVURiBvYXV0aCBXRzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHJl
dmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxicj4NCjxicj4NCklmIGEg
Y2xhaW0gcHJvdmlkZXMgcHJvb2YgdGhlbiBJIHdvdWxkIGNhbGwgaXQgYSBjcmVkZW50aWFsIG5v
dCBhIGNsYWltPGJyPg0KPGJyPg0KRGF2aWQ8YnI+DQo8YnI+DQpPbiAyOS8xMi8yMDEyIDAxOjEx
LCBNaWtlIEpvbmVzIHdyb3RlOjxicj4NCiZndDsgSSBmb3VuZCB0aGUgWC4xMjUyIGRlZmluaXRp
b24uICZuYnNwO0l0IGlzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICo2LjE4IGNsYWltICpbYi1PRURd
OiBUbyBzdGF0ZSBhcyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBiZWluZyBhYmxlPGJyPg0KJmd0
OyB0byBnaXZlIHByb29mLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYXQgc2VlbXMgYm90aCBhIGJp
dCB2YWd1ZSwgYW5kIGFjdHVhbGx5IGluY29ycmVjdCwgYXMgdGhlIEpXVCBtYXk8YnI+DQomZ3Q7
IGluY2x1ZGUgcHJvb2Ygb2YgdGhlIHZlcmFjaXR5IG9mIHRoZSBjbGFpbS4gJm5ic3A7UGxlYXNl
IHNlZSB0aGUgdXBkYXRlZDxicj4NCiZndDsgSldUIGRyYWZ0IGZvciBhIGhvcGVmdWxseSBtb3Jl
IHVzZWZ1bCDigJxDbGFpbeKAnSBkZWZpbml0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Jlc3Q8YnI+DQomZ3Q7IHdp
c2hlcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDstLSBNaWtlPGJyPg0KJmd0Ozxicj4NCiZndDsgKkZyb206Kk1pa2UgSm9u
ZXM8YnI+DQomZ3Q7ICpTZW50OiogU3VuZGF5LCBEZWNlbWJlciAyMywgMjAxMiAxOjAzIFBNPGJy
Pg0KJmd0OyAqVG86KiBKZWZmIEhvZGdlczsgTmF0IFNha2ltdXJhPGJyPg0KJmd0OyAqQ2M6KiBJ
RVRGIG9hdXRoIFdHPGJyPg0KJmd0OyAqU3ViamVjdDoqIFJFOiBbT0FVVEgtV0ddIHJldmlldzog
ZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxicj4NCiZndDs8YnI+DQomZ3Q7IFdo
YXQgaXMgdGhlIFguMTI1MiBkZWZpbml0aW9uPzxicj4NCiZndDs8YnI+DQomZ3Q7IC0tIE1pa2U8
YnI+DQomZ3Q7PGJyPg0KJmd0OyAqRnJvbToqIE5hdCBTYWtpbXVyYTxicj4NCiZndDsgKlNlbnQ6
KiDigI5EZWNlbWJlcuKAjiDigI4yM+KAjiwg4oCOMjAxMiDigI4xMOKAjjrigI4wOeKAjiDigI5B
TTxicj4NCiZndDsgKlRvOiogPUplZmZIPGJyPg0KJmd0OyAqQ0M6KiBNaWtlIEpvbmVzLCBJRVRG
IG9hdXRoIFdHPGJyPg0KJmd0OyAqU3ViamVjdDoqIFJlOiBbT0FVVEgtV0ddIHJldmlldzogZHJh
ZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxicj4NCiZndDs8YnI+DQomZ3Q7IFJlIGRl
ZmluaXRpb24gb2YgJ2NsYWltJywgYXMgSldUIGlzIHN1cHBvc2VkIHRvIGJlIGdlbmVyaWMsIGl0
IG1heSBiZTxicj4NCiZndDsgYmV0dGVyIHRvIGdvIHdpdGggdGhlIGRlZmluaXRpb24gb2YgWC4x
MjUyIHJhdGhlciB0aGFuIE9JREMuPGJyPg0KJmd0Ozxicj4NCiZndDsgPW5hdCB2aWEgaVBob25l
PGJyPg0KJmd0Ozxicj4NCiZndDsgRGVjIDI0LCAyMDEyIDI6NDI8c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jgIE8L3NwYW4+PUplZmZIICZsdDs8YSBocmVm
PSJtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20iPkplZmYuSG9kZ2VzQGtpbmdz
bW91bnRhaW4uY29tPC9hPjxicj4NCiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86SmVm
Zi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20iPkplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29t
PC9hPiZndDsmZ3Q7DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1
b3Q7Ij7jga7jg6Hjg4Pjgrvjg7zjgrg8L3NwYW4+Ojxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7ICZndDsgVGhhbmtzIGZvciB0aGUgcmVwbGllcywgSmVmZi4gJm5ic3A7VGhl
eSBtYWtlIHNlbnNlLiAmbmJzcDtQYXJ0aWN1bGFybHksPGJyPg0KJmd0OyZndDsgJmd0OyB0aGFu
a3MgZm9yIHRoZSAmcXVvdDtKU09OIFRleHQgT2JqZWN0JnF1b3Q7IHN1Z2dlc3Rpb24uPGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyB3ZWxjb21lLCBnbGFkIHRoZXkgbWFkZSBzb21lIHNlbnNl
Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgc2ltaWxhcmx5LCBpZiBvbmUgZW1wbG95cyBK
U09OIGFycmF5cywgSSdkIGRlZmluZSBhICZxdW90O0pTT04gdGV4dCBhcnJheSZxdW90Oy48YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0OyBGb3IgdGhlICZxdW90
O2NsYWltcyZxdW90OyBkZWZpbml0aW9uLCBJJ20gYWN0dWFsbHkgcHJvbmUgdG8gZ28gd2l0aDxi
cj4NCiZndDsmZ3Q7ICZndDtkZWZpbml0aW9ucyBiYXNlZCAmbmJzcDtvbiB0aG9zZSBpbjxicj4N
CiZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9zcGVjcy9vcGVuaWQtY29u
bmVjdC1tZXNzYWdlcy0xXzAtMTMuaHRtbCN0ZXJtaW5vbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6
Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LW1lc3NhZ2VzLTFfMC0xMy5odG1sI3Rl
cm1pbm9sPC9hPjxicj4NCiZndDsmZ3Q7ICZndDtvZ3ktPGJyPg0KJmd0OyZndDsgJmd0OyBzcGVj
aWZpY2FsbHk6PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgQ2xhaW08YnI+
DQomZ3Q7Jmd0OyAmZ3Q7IEEgcGllY2Ugb2YgaW5mb3JtYXRpb24gYWJvdXQgYW4gRW50aXR5IHRo
YXQgYSBDbGFpbXMgUHJvdmlkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGFzc2VydHMgYWJvdXQgdGhh
dCBFbnRpdHkuPGJyPg0KJmd0OyZndDsgJmd0OyBDbGFpbXMgUHJvdmlkZXI8YnI+DQomZ3Q7Jmd0
OyAmZ3Q7IEEgc3lzdGVtIG9yIHNlcnZpY2UgdGhhdCBjYW4gcmV0dXJuIENsYWltcyBhYm91dCBh
biBFbnRpdHkuPGJyPg0KJmd0OyZndDsgJmd0OyBFbmQtVXNlcjxicj4NCiZndDsmZ3Q7ICZndDsg
QSBodW1hbiB1c2VyIG9mIGEgc3lzdGVtIG9yIHNlcnZpY2UuPGJyPg0KJmd0OyZndDsgJmd0OyBF
bnRpdHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFNvbWV0aGluZyB0aGF0IGhhcyBhIHNlcGFyYXRlIGFu
ZCBkaXN0aW5jdCBleGlzdGVuY2UgYW5kIHRoYXQgY2FuPGJyPg0KJmd0OyZndDsgJmd0OyBiZSBp
ZGVudGlmaWVkIGluIGNvbnRleHQuIEFuIEVuZC1Vc2VyIGlzIG9uZSBleGFtcGxlIG9mIGFuIEVu
dGl0eS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHdlbGwsIGl0IHNlZW1zIHRvIG1lLCBn
aXZlbiB0aGUgbWFubmVyIGluIHdoaWNoIHRoZSBKV1Qgc3BlYyBpczxicj4NCiZndDsmZ3Q7IHdy
aXR0ZW4sIG9uZSBjYW4gbWFrZSB0aGUgY2FzZSB0aGF0IEpXVCBjbGFpbXMgaW4gZ2VuZXJhbCBh
cmVuJ3Q8YnI+DQomZ3Q7Jmd0OyBuZWNlc3NhcmlseSBhYm91dCBhbiBFbnRpdHkgKGFzIHRoZSBs
YXR0ZXIgdGVybSBpcyB1c2VkIGluIHRoZTxicj4NCiZndDsmZ3Q7IGNvbnRleHQgb2YgdGhlIE9w
ZW5JRCBDb25uZWN0IHNwZWNzKSwgcmF0aGVyIHRoZXkncmUgaW4gZ2VuZXJhbDxicj4NCiZndDsm
Z3Q7IHNpbXBseSBhc3NlcnRpb25zIGFib3V0IHNvbWV0aGluZyhzKS4gdGhpcyBpcyBiZWNhdXNl
IGFsbCBwcmUtZGVmaW5lZDxicj4NCiZndDsgSldUIGNsYWltIHR5cGVzIGFyZSBvcHRpb25hbCBh
bmQgYWxsIEpXVCBzZW1hbnRpY3MgYXJlIGxlZnQgdXAgdG88YnI+DQomZ3Q7IHNwZWNzIHRoYXQg
cHJvZmlsZSAoYWthIHJlLXVzZSkgdGhlIEpXVCBzcGVjLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsgSFRILDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPUplZmZIPGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXzxicj4NCiZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7PGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT4gJmx0O21haWx0
bzo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPiZndDs8
YnI+DQomZ3Q7Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7
IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYu
b3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk9BdXRoIG1h
aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0
Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls
dG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K
PGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
Pi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVm
PSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNh
a2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_4E1F6AAD24975D4BA5B1680429673943669E05E8TK5EX14MBXC283r_--

From Michael.Jones@microsoft.com  Sun Dec 30 00:06:06 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2D121F890E for ; Sun, 30 Dec 2012 00:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.191
X-Spam-Level: 
X-Spam-Status: No, score=0.191 tagged_above=-999 required=5 tests=[AWL=-2.811,  BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_35=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcbyrLWlj36z for ; Sun, 30 Dec 2012 00:05:58 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id 95D7321F88E0 for ; Sun, 30 Dec 2012 00:05:57 -0800 (PST)
Received: from BY2FFO11FD005.protection.gbl (10.1.15.204) by BY2FFO11HUB017.protection.gbl (10.1.14.91) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 08:05:53 +0000
Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD005.mail.protection.outlook.com (10.1.14.126) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 30 Dec 2012 08:05:53 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Sun, 30 Dec 2012 08:05:52 +0000
From: Mike Jones 
To: Nat Sakimura , Justin Richer 
Thread-Topic: [OAUTH-WG] "cid" claim in JWT
Thread-Index: Ac3eeDoQnms0qid0tk+0K29GGMlTVQADWJcAABH2AUABkPkUgABM2DeAAAeR6GA=
Date: Sun, 30 Dec 2012 08:05:51 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669E07AF@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B16804296739436697EF82@TK5EX14MBXC283.redmond.corp.microsoft.com>  <4E1F6AAD24975D4BA5B16804296739436697FA11@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DDBCE5.8080205@mitre.org> 
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.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669E07AFTK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377424002)(377454001)(479174001)(24454001)(77982001)(74662001)(74502001)(551984001)(56816002)(59766001)(47976001)(51856001)(47736001)(15202345001)(46102001)(16236675001)(55846006)(54316002)(31966008)(4396001)(16406001)(5343655001)(47446002)(44976002)(5343635001)(54356001)(550184003)(512954001)(56776001)(76482001)(49866001)(33656001)(50986001)(53806001)(404934002)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB017; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 071156160B
Cc: oauth 
Subject: Re: [OAUTH-WG] "cid" claim in JWT
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 08:06:06 -0000

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

We added "azp" as an optional claim in the OpenID Connect ID Token definiti=
on to let people experiment with it.  However, unlike the other three claim=
s (issuer, subject, audience) discussed below, for which there is a great d=
eal of industry experience, the "authorized party" claim is one we're newly=
 making up and I don't think its semantics are well understood.

For starters, would it be better expressed as a second audience value rathe=
r than a separate claim?  Must it also be an audience of the token?  What v=
alidation steps must/should which parties perform when an "azp" claim is pr=
esent?  What steps must/should which parties perform when one is not presen=
t?

If this matures to the point that it seems that there is sufficient usage e=
xperience of the "azp" claim to believe that it's the right way of meeting =
a need and that there are well-understood consensus answers to the question=
s above based upon that usage experience, then great.  At that point I'd be=
 in favor of adding it to the JWT spec.

I'm fine with experimental use in OpenID Connect, but I think it's way too =
early to add it to the JWT spec now.

Finally, remember that it's very easy to add a new claim definition even af=
ter the JWT spec is an RFC by defining the claim in another spec and regist=
ering the claim in the IANA JSON Web Token Claims registry.  I'd rather we =
be conservative about the claims we add in the JWT spec itself and then add=
 new ones by defining them in additional specs as it makes sense.

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Saturday, December 29, 2012 8:19 PM
To: Justin Richer
Cc: Mike Jones; oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

Thanks Justin for a very good rundown. I agree with these. It would be a di=
sservice to the community not to include "azp" (aka "reg", "cid") in JWT, a=
s this gives so much clarity on the issue.

Let me add one more: it is a use case for HoK of the presenter while not le=
tting the issuer know where it is being presented. (e.g., showing driver's =
license at a liquor shop.) Most of the physical identity documents (e.g., p=
assport, national ID card, etc.) falls into this category.

iss =3D> Authorization Server
aud =3D> *
sub =3D> Subject of the JWT Claim Set
azp =3D> Subject of the JWT Claim Set

Nat

On Sat, Dec 29, 2012 at 12:38 AM, Justin Richer > wrote:
I thought I should drop in my full rundown of the party representation here=
. Assuming a standard 3-legged OAuth flow of any flavor, you have the follo=
wing mapping:

 iss =3D> Authorization Server
 aud =3D> Resource Server(s)
 sub =3D> Resource Owner
 azp =3D> Client

Note that the "sub" claim here is a drop-in replacement for "prn" and that =
"azp" is a more or less drop-in replacement for "cid".

Of course there are other ways that a JWT could be minted, so let me be a b=
it more concrete with a few examples.

3-legged OAuth:

 iss: http://auth.example.org/
 aud: http://resource.example.org/
 sub: bob.smith
 azp: oauth-client-1

2-legged OAuth (client credentials):

 iss: http://auth.example.org/
 aud: http://resource.example.org/
 sub: oauth-client-1
 azp: oauth-client-1

Client authentication assertion, self-issued:

 iss: oauth-client-1
 aud: http://auth.example.org/
 sub: oauth-client-1
 azp: oauth-client-1

Authorization grant assertion, self-issued:

 iss: oauth-client-1
 aud: http://auth.example.org/
 sub: bob.smith
 azp: oauth-client-1

Client authentication assertion, non-self-issued:

 iss: http://auth.example.org/
 aud: http://auth.example.org/
 sub: oauth-client-1
 azp: oauth-client-1

Authorization grant assertion, non-self-issued:

 iss: http://auth.example.org/
 aud: http://auth.example.org/
 sub: bob.smith
 azp: oauth-client-1

OpenID Connect ID Token:

 iss: http://auth.example.org/
 aud: oauth-client-1
 sub: bob.smith
 azp: oauth-client-1



Note that repeated values are intentional and MUST be preserved, since ther=
e's no way to know the value of a "missing" claim otherwise.

There are likely other use cases here as well. Writing this all out has mad=
e me wonder if this needs to be captured in an online spreadsheet somewhere=
.

 -- Justin



On 12/20/2012 11:22 AM, Mike Jones wrote:
This was discussed on the OpenID Connect call this morning.  Our sense was =
that "Authorized Party" was actually a more general description of the conc=
ept than Client ID.  Justin Richer pointed out that at that point, there wo=
uld be claims defined for representing all four potential parties in an OAu=
th interaction.  Connect plans to define the optional "azp" (Authorized Par=
ty) claim to let people experiment with it.  There wasn't a sense that it's=
 necessary to add to the JWT spec itself at this time.

As for the proposed "cid" (Client Identification Data claim type) claim, ou=
r sense was that that is more related to proof of possession, and can be di=
scussed in that context.

                                                            -- Mike

From: Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Wednesday, December 19, 2012 11:43 PM
To: Mike Jones
Cc: Anthony Nadalin; John Bradley; oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

As "prn" is way under-defined [1], there can be two interpretations for "pr=
n".

Considering that "subject" is not a defined term (=3D dictionary term), and=
 interpreting a boarding pass as:

"Japan Airlines authorizes JL002 to accept passenger John Smith at the Gate=
 B22 provided safety and other requirements are met between the boarding ti=
me (14:30) and 10 minutes before the departure time (15:10)"

then:

iss: Japan Airlines
prn: JL002 (the flight number)
cid: John Smith (the passenger, who uses the boarding pass)
aud: Gate B22 (Gate assigned to JL002)
nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9

Alternatively, if we interpret the boarding pass as:

"Japan Airlines authorizes John Smith to board JL002 at the Gate B22 provid=
ed safety and other requirements are met the boarding time (14:30) and 10 m=
inutes before the departure time (15:10)""

iss: Japan Airlines
prn: John Smith
cid: John Smith
aud: Gate B22 (Gate assigned to JL002)
nbf: 2012-12-31T14:30+9
exp: 2012-12-31T15:00+9

This interpretation has lost some information while encoding into JWT, so p=
rior one may be more appropriate.

Either way, as "prn" lacks exact semantics, what goes into it is subject to=
 interpretation while "cid" is very clearly defined.

Let me give another example.

An entitlement that says: "John Smith is allowed to activate the system whe=
n Mary White presents this token (#1234) to the System A" that is issued by=
 the "ABC Corp"

iss: ABC Corp.
jti: #1234
prn: John Smith
cid: Mary White
aud: System A

Note: this is not delegation nor on-behalf-of.

More webby example: "John Smith authorizes photo print service A to access =
photo archive service B for John Smith's photo #123 until 2013-04-01 for th=
e sum of $100."

iss: John Smith's Authorization Server
prn: John Smith's photo #123
cid: Photo print service A
aud: photo archive service B
exp: 2013-04-01

Nat

[1]  4.1.6 "prn" defines its value as what identifies:

"the subject of the JWT"

This can be expanded by replacing "JWT" with its definition as

"the subject of the string consisting of multiple parts, the first being th=
e Encoded JWT Header, plus additional parts depending upon the contents of =
the header, with the parts being separated by period ('.') characters, and =
each part containing base64url encoded content."

Further, expanding "JWT Header", it will become

"the subject of the string consisting of multiple parts, the first being th=
e string representing a JSON object that describes the cryptographic operat=
ions applied to the string, plus additional parts depending upon the conten=
ts of the header, with the parts being separated by period ('.') characters=
, and each part containing base64url encoded content."

To me, it is not clear what it means.


On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones > wrote:
What would the iss, prn, aud, and cid values represent in the boarding pass=
 example?

-- Mike

From: Nat Sakimura
Sent: December 19, 2012 9:32 PM
To: Mike Jones
CC: Anthony Nadalin, John Bradley, oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

I obviously disagree - if I did agree, I did not send it to the list to sta=
rt with :-)

"cid" (or in my original proposal, "reg") has a very clear and established =
meaning.
The parallel examples abounds in our daily life.

It has very little to do with On-behalf-of.
It is not a delegation statement.

"cid" is there to indicate to whom it was issued to.
The entity who was issued this "token" is eligible to use it at the
entities indicated by "aud".

Example in our real life are like:

- Airline boarding pass
- Registered instruments (bond / share)
- Monthly train pass
- Disneyland annual passport
 etc. etc.

Please do not mix it up with a delegation statement like on-behalf-of,
which is much less well defined.

Nat


On Thu, Dec 20, 2012 at 12:07 PM, Mike Jones > wrote:
I'm with Tony on this.  This seems premature to put into the JWT standard. =
 All the other JWT claims have well established meanings and history behind=
 them.  These don't.

If the goal is to allow OpenID Connect implementations to not reject tokens=
 using "cid", there are lots of other ways to accomplish this that I think =
we should consider first.

-- Mike


From: John Bradley
Sent: December 19, 2012 6:25 PM
To: Anthony Nadalin
CC: oauth
Subject: Re: [OAUTH-WG] "cid" claim in JWT

I agree, audience who requested it and and who it is requested for are all =
interrelated.

However we do need to set down some standard way of expressing it as people=
 are starting to make stuff up on their own that will impact interoperabili=
ty.

If Google starts thawing in cid and clients don't know about it they must r=
eject the JWT etc.

John

On 2012-12-19, at 9:40 PM, Anthony Nadalin > wrote:

It seems premature and we should consider this in the bigger context of the=
 "on behalf of"/delegation work that has been started

From: oauth-bounces@ietf.org [mailto:oauth-<=
mailto:oauth->bounces@ietf.org] On Behalf Of Nat S=
akimura
Sent: Tuesday, December 18, 2012 6:22 PM
To: oauth
Subject: [OAUTH-WG] "cid" claim in JWT

In OpenID Connect WG, we have been talking this for sometime.
"cid" claim identifies the entity that the JWT was issued to as a rightful/=
licensed user.
Google already uses this in their implementation of id_token of OIDC.

Here is the text proposal. It introduces two new standard claims: "cid" and=
 "cit".

It would be very useful in creating a HoK drafts as well.

Cheers,

Nat




4.1.9. "cid" Client Identification Data Claim



The "cid" (client identification data) claim allows the receiver

of the JWT to identify the entity that the JWT is

intended to be used by. The audience of the JWT MUST be

able to identify the client with the value of this claim.



The "cid" value is a case sensitive string containing a StringOrURI value.

This claim is OPTIONAL. If the entity processing the claim does not

identify the user of the JWT with the identifier in the "cid" claim value,

then the JWT MUST be rejected. The interpretation of the registered to

value is generally application specific.



A typical example of a registered to claim includes following:

* client_id that the audience can use to authenticate and

  identify the client.

* A base64url encoded JWK.

* A URL that points to the key material that the audience can use to

  authenticate the user of the JWT.



4.1.10 "cit" (Client Identification Data claim type)



The "cit" (Client Identification Data claim type) identifies the type

of the "cid" claim. It is a StringOrURI value. The defined values

are the following:



"client_id" The value of the "cid" claim is the Client ID of the client

that the audience of the JWT is able to use to authenticate the client.



"jwk" The value of the "cid" claim is a base64url encoded JWK of

the registered client.



"jku" The value of the "cid" claim is the "jku" defined in 4.1.2 of

JSON web signature [JWS].



"x5u" The value of the "cid" claim is the URL that points to the public

key certificate of the registered client. The format of the content

that x5u points to is described in section 4.1.4 of the JSON Web Signature.

--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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


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



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en



--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


_______________________________________________

OAuth mailing list

OAuth@ietf.org

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




--
Nat Sakimura (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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











We added “azp”=
; as an optional claim in the OpenID Connect ID Token definition to let peo=
ple experiment with it.  However, unlike the other three claims (issue=
r,
 subject, audience) discussed below, for which there is a great deal of ind=
ustry experience, the “authorized party” claim is one we’=
re newly making up and I don’t think its semantics are well understoo=
d.


 <=
/p>

For starters, would it be=
 better expressed as a second audience value rather than a separate claim?&=
nbsp; Must it also be an audience of the token?  What validation
 steps must/should which parties perform when an “azp” claim is=
 present?  What steps must/should which parties perform when one is no=
t present?


 <=
/p>

If this matures to the po=
int that it seems that there is sufficient usage experience of the “a=
zp” claim to believe that it’s the right way of meeting a need
 and that there are well-understood consensus answers to the questions abov=
e based upon that usage experience, then great.  At that point I’=
;d be in favor of adding it to the JWT spec.


 <=
/p>

I’m fine with exper=
imental use in OpenID Connect, but I think it’s way too early to add =
it to the JWT spec now.


 <=
/p>

Finally, remember that it=
’s very easy to add a new claim definition even after the JWT spec is=
 an RFC by defining the claim in another spec and registering
 the claim in the IANA JSON Web Token Claims registry.  I’d rath=
er we be conservative about the claims we add in the JWT spec itself and th=
en add new ones by defining them in additional specs as it makes sense.


 <=
/p>

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


 <=
/p>

From: Nat Saki=
mura [mailto:sakimura@gmail.com]


Sent: Saturday, December 29, 2012 8:19 PM

To: Justin Richer

Cc: Mike Jones; oauth

Subject: Re: [OAUTH-WG] "cid" claim in JWT


 


Thanks Justin for a very good rundown. I agree with =
these. It would be a disservice to the community not to include "azp&q=
uot; (aka "reg", "cid") in JWT, as this gives so much c=
larity on the issue.




 






Let me add one more: it is a use case for HoK of the=
 presenter while not letting the issuer know where it is being presented. (=
e.g., showing driver's license at a liquor shop.) Most of the physical iden=
tity documents (e.g., passport, national
 ID card, etc.) falls into this category. 






 






iss =3D> Authorization Server






aud =3D> *






sub =3D> Subject of the JWT Claim Set<=
/p>





azp =3D> Subject of the JWT Claim Set



Nat






 




On Sat, Dec 29, 2012 at 12:38 AM, Justin Richer <=
jricher@mitre.org> wrote:






I thought I should drop in my full rundown of the pa=
rty representation here. Assuming a standard 3-legged OAuth flow of any fla=
vor, you have the following mapping:



 iss =3D> Authorization Server

 aud =3D> Resource Server(s)

 sub =3D> Resource Owner

 azp =3D> Client



Note that the "sub" claim here is a drop-in replacement for "=
;prn" and that "azp" is a more or less drop-in replacement f=
or "cid".




Of course there are other ways that a JWT could be minted, so let me be a b=
it more concrete with a few examples.




3-legged OAuth:



 iss: http://au=
th.example.org/

 aud: http:=
//resource.example.org/

 sub: bob.smith

 azp: oauth-client-1



2-legged OAuth (client credentials):



 iss: http://au=
th.example.org/

 aud: http:=
//resource.example.org/

 sub: oauth-client-1

 azp: oauth-client-1



Client authentication assertion, self-issued:



 iss: oauth-client-1

 aud: http://au=
th.example.org/

 sub: oauth-client-1

 azp: oauth-client-1



Authorization grant assertion, self-issued:



 iss: oauth-client-1

 aud: http://au=
th.example.org/

 sub: bob.smith

 azp: oauth-client-1



Client authentication assertion, non-self-issued:



 iss: http://au=
th.example.org/

 aud: http://au=
th.example.org/

 sub: oauth-client-1

 azp: oauth-client-1



Authorization grant assertion, non-self-issued:



 iss: http://au=
th.example.org/

 aud: http://au=
th.example.org/

 sub: bob.smith

 azp: oauth-client-1



OpenID Connect ID Token:



 iss: http://au=
th.example.org/

 aud: oauth-client-1

 sub: bob.smith

 azp: oauth-client-1







Note that repeated values are intentional and MUST be preserved, since ther=
e's no way to know the value of a "missing" claim otherwise.




There are likely other use cases here as well. Writing this all out has mad=
e me wonder if this needs to be captured in an online spreadsheet somewhere=
.



 -- Justin








  



On 12/20/2012 11:22 AM, Mike Jones wrote:
















This was discussed on the OpenID Connec=
t call this morning.  Our sense was that “Authorized Party”=
;
 was actually a more general description of the concept than Client ID.&nbs=
p; Justin Richer pointed out that at that point, there would be claims defi=
ned for representing all four potential parties in an OAuth interaction.&nb=
sp; Connect plans to define the optional “azp”
 (Authorized Party) claim to let people experiment with it.  There was=
n’t a sense that it’s necessary to add to the JWT spec itself a=
t this time.


 


As for the proposed “cid” (=
Client Identification Data claim type) claim, our sense was that that
 is more related to proof of possession, and can be discussed in that conte=
xt.


 


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


 


From: Nat Sakimura [mailto:sakimura@gmail.com<=
/a>]


Sent: Wednesday, December 19, 2012 11:43 PM

To: Mike Jones

Cc: Anthony Nadalin; John Bradley; oauth

Subject: Re: [OAUTH-WG] "cid" claim in JWT


 






As "prn" is way under-defined [1], there can be two inte=
rpretations for "prn". 






 






Considering that "subject" is not a defined term (=3D di=
ctionary term), and interpreting a boarding pass as:






 






"Japan Airlines authorizes JL002 to accept passenger John Smi=
th at the Gate B22 provided safety and other requirements are met between t=
he boarding time (14:30) and 10 minutes before
 the departure time (15:10)" 






 






then: 






 




iss: Japan Airlines




prn: JL002 (the flight number)






cid: John Smith (the passenger, who uses the boarding pass)






aud: Gate B22 (Gate assigned to JL002)








nbf: 2012-12-31T14:30+9






exp: 2012-12-31T15:00+9






 






Alternatively, if we interpret the boarding pass as: 






 






"Japan Airlines authorizes John Smith to board JL002 at the G=
ate B22 provided safety and other requirements are met the boarding ti=
me (14:30) and 10 minutes before the departure
 time (15:10)""






 






iss: Japan Airlines






prn: John Smith






cid: John Smith






aud: Gate B22 (Gate assigned to JL002)








nbf: 2012-12-31T14:30+9






exp: 2012-12-31T15:00+9








 






This interpretation has lost some information while encoding into =
JWT, so prior one may be more appropriate. 






 






Either way, as "prn" lacks exact semantics, what goes in=
to it is subject to interpretation while "cid" is very clearly de=
fined. 






 






Let me give another example. 






 






An entitlement that says: "John Smith is allowed to activate =
the system when Mary White presents this token (#1234) to the System A"=
; that is issued by the "ABC Corp"






 






iss: ABC Corp. 






jti: #1234






prn: John Smith






cid: Mary White






aud: System A






 






Note: this is not delegation nor on-behalf-of. 





 






More webby example: "John Smith authorizes photo print servic=
e A to access photo archive service B for John Smith's photo #123 until 201=
3-04-01 for the sum of $100."






 






iss: John Smith's Authorization Server






prn: John Smith's photo #123






cid: Photo print service A






aud: photo archive service B






exp: 2013-04-01






 






Nat






 






[1]  4.1.6 "prn" defines its value as what identifi=
es:






 










"the subject of the JWT" <=
/span>










 






This can be expanded by replacing &q=
uot;JWT" with its definition as 






 






"the subject of the string consistin=
g of multiple parts, the first being the Encoded JWT Header, plus
 additional parts depending upon the contents of the header, with the parts=
 being separated by period ('.') characters, and each part containing base6=
4url encoded content."






 






Further, expanding "JWT Header"=
, it will become 






 






"the subject of the string consistin=
g of multiple parts, the first being the string representing a
 JSON object that describes the cryptographic operations applied to the str=
ing, plus additional parts depending upon the contents of the header, with =
the parts being separated by period ('.') characters, and each part contain=
ing base64url encoded content."






 






To me, it is not clear what it means.&nbs=
p;








 








 




On Thu, Dec 20, 2012 at 3:07 PM, Mike Jones <Michael.Jones@microsoft.com<=
/a>> wrote:








What would the iss, prn, aud, and cid values represent in the boarding=
 pass example?






 






-- Mike






 






From: Nat Sakimura

Sent: December 19, 2012 9:32 PM

To: Mike Jones

CC: Anthony Nadalin, John Bradley, oauth

Subject: Re: [OAUTH-WG] "cid" claim in J=
WT










 




I obviously disagree - if I did agree, I did not send it to the list t=
o start with :-)





 






"cid" (or in my original proposal, "reg") has a ve=
ry clear and established meaning. 






The parallel examples abounds in our daily life. 






 






It has very little to do with On-behalf-of. 





It is not a delegation statement. 






 






"cid" is there to indicate to whom it was issued to. 






The entity who was issued this "token" is eligible to use it=
 at the 






entities indicated by "aud". 






 






Example in our real life are like: 






 






- Airline boarding pass






- Registered instruments (bond / share) 






- Monthly train pass






- Disneyland annual passport






 etc. etc. 






 






Please do not mix it up with a delegation statement like on-behalf-of,=
 






which is much less well defined. 






 






Nat






 










&=
nbsp;

















I'm with Tony on this.  This seems premature to put into the JWT =
standard.  All the other JWT claims have well established meanings
 and history behind them.  These don't.






 






If the goal is to allow OpenID Connect implementations to not reject t=
okens using “cid”, there are lots of other ways to accompl=
ish
 this that I think we should consider first.






 






-- Mike






 






 














From: John Bradley

Sent: December 19, 2012 6:25 PM

To: Anthony Nadalin

CC: oauth






Subject: Re: [OAUTH-WG] "cid" claim=
 in JWT












 




I agree, audience who requested it and and who it is requested for are=
 all interrelated.





 












However we do need to set down some standard way of expressing it as p=
eople are starting to make stuff up on their own that will
 impact interoperability.






 






If Google starts thawing in cid and clients don't know about it they m=
ust reject the JWT etc.






 






John






 






On 2012-12-19, at 9:40 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:






 








It seems premature and we should consid=
er this in the bigger context of the “on behalf of”/delegation
 work that has been started






 






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

Sent: Tuesday, December 18, 2012 6:22 PM

To: oauth

Subject: [OAUTH-WG] "cid" claim in JWT






 






In OpenID Connect WG, we have been talking this for sometime. =
;








"cid" claim identifies the entity that the JWT was issue=
d to as a rightful/licensed user. 










Google already uses this in their implementation of id_token of OI=
DC. 










 










Here is the text proposal. It introduces two new standard claims: =
"cid" and "cit". 










 











It would be very useful in creating a HoK drafts a=
s well. 







 







Cheers, 







 







Nat







 








 


4.1.9. "cid" Client Identificatio=
n Data Claim


 


The "cid" (client identification dat=
a) claim allows the receiver 


of the JWT to identify the entity that the JWT=
 is 


intended to be used by. The audience of the JW=
T MUST be 


able to identify the client with the value of =
this claim.


 


The "cid" value is a case sensitive string containing a StringOrURI value.


This claim is OPTIONAL. If the entity processi=
ng the claim does not 


identify the user of the JWT with the identifi=
er in the "cid" claim value, 


then the JWT MUST be rejected. The interpretat=
ion of the registered to 


value is generally application specific.


 


A typical example of a registered to claim inc=
ludes following: 


* client_id that the audience can use to authe=
nticate and 


  identify the client.


* A base64url encoded JWK. <=
/pre>

* A URL that points to the key material that t=
he audience can use to 


  authenticate the user of the JWT.<=
/span>


 


4.1.10 "cit" (Client Identificati=
on Data claim type)


 


The "cit" (Client Identification Dat=
a claim type) identifies the type 


of the "cid" claim. It is a StringOr=
URI value. The defined values 


are the following:


 


"client_id" The value of the "c=
id" claim is the Client ID of the client 


that the audience of the JWT is able to use to=
 authenticate the client.


 


"jwk" The value of the "cid&quo=
t; claim is a base64url encoded JWK of 


the registered client.


 


"jku" The value of the "cid&quo=
t; claim is the "jku" defined in 4.1.2 of 

JSON web signature [JWS].

 


"x5u" The value of the "cid&quo=
t; claim is the URL that points to the public 


key certificate of the registered client. The =
format of the content 


that x5u points to is described in section 4.1=
.4 of the JSON Web Signature.














 








-- 

Nat Sakimura (=3Dnat)








Chairman, OpenID Foundation

http://nat.sakimura.org/

@_nat_en








 








_______________________________________________

OAuth mailing list

OAuth@ietf.org

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








 




















<=
br>
_______________________________________________

OAuth mailing list

OAuth@ietf.org

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























 




--


Nat Sakimura (=3Dnat) 




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en

























 




--


Nat Sakimura (=3Dnat)




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en








 


_______________________________________________


OAuth mailing list


OAuth@ietf.org=



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




 



















 




-- 

Nat Sakimura (=3Dnat)




Chairman, OpenID Foundation

http://nat.sakimura.=
org/

@_nat_en










--_000_4E1F6AAD24975D4BA5B1680429673943669E07AFTK5EX14MBXC283r_--

From Michael.Jones@microsoft.com  Sun Dec 30 00:07:28 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29C721F88E2 for ; Sun, 30 Dec 2012 00:07:28 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7GqZMl11aQH for ; Sun, 30 Dec 2012 00:07:27 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3026721F88E0 for ; Sun, 30 Dec 2012 00:07:27 -0800 (PST)
Received: from BY2FFO11FD010.protection.gbl (10.1.15.202) by BY2FFO11HUB017.protection.gbl (10.1.14.91) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 08:07:24 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD010.mail.protection.outlook.com (10.1.14.74) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 30 Dec 2012 08:07:25 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Sun, 30 Dec 2012 08:07:24 +0000
From: Mike Jones 
To: Anthony Nadalin , Nat Sakimura 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYXPoELEFPMRSTq+X4Nh79LI8wgAR1McAAB7zZYAAB4U7gAADM92AAAVDVuA=
Date: Sun, 30 Dec 2012 08:07:22 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669E083F@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk> <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.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.34]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669E083FTK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(377454001)(13464002)(479174001)(51914002)(24454001)(77982001)(74662001)(74502001)(56816002)(59766001)(15395725002)(47976001)(51856001)(47736001)(15202345001)(46102001)(16236675001)(55846006)(512874001)(54316002)(31966008)(4396001)(16406001)(5343655001)(47446002)(44976002)(5343635001)(54356001)(550184003)(56776001)(76482001)(5343645001)(49866001)(33656001)(50986001)(53806001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB017; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 071156160B
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 08:07:28 -0000

--_000_4E1F6AAD24975D4BA5B1680429673943669E083FTK5EX14MBXC283r_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBzdXJlIGhvcGUgd2UgZG9u4oCZdCBwbGFuL25lZWQgdG8gZ28gaW50byB0aGF0IGxldmVsIG9m
IHRlY2huaWNhbCBkZXRhaWwgaW4gdGhlIEpXVCBzcGVjLiAgSXTigJlzIGludGVuZGVkIHRvIGJl
IHJlYWRhYmxlIGFuZCBhY2Nlc3NpYmxlIHRvIGRldmVsb3BlcnMg4oCTIG5vdCBhIHRyZWF0aXNl
IG9uIHRoZSBtZWFuaW5ncyBvZiB3b3Jkcy4g4pi6DQoNCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogQW50
aG9ueSBOYWRhbGluDQpTZW50OiBTYXR1cmRheSwgRGVjZW1iZXIgMjksIDIwMTIgOTozNSBQTQ0K
VG86IE5hdCBTYWtpbXVyYQ0KQ2M6IERhdmlkIENoYWR3aWNrOyBNaWtlIEpvbmVzOyBJRVRGIG9h
dXRoIFdHDQpTdWJqZWN0OiBSRTogW09BVVRILVdHXSByZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgt
anNvbi13ZWItdG9rZW4tMDUNCg0KMTI1MiBzIGl0IGhhcyBhIHNlY3Rpb24gdGhhdCBleHBsYWlu
cyB0aGUgdXNhZ2UNCg0KQS4yICAgICAgIENsYWltL2Fzc2VydGlvbg0KVGhlIG1lYW5pbmcgb2Yg
dGhlIHRlcm1zIGNsYWltIGFuZCBhc3NlcnRpb24gYXJlIGdlbmVyYWxseSBhZ3JlZWQgdG8gYmUg
c29tZXdoYXQgc2ltaWxhciBidXQgd2l0aCBzbGlnaHRseSBkaWZmZXJlbnQgbWVhbmluZ3MuIElu
IHNvbWUgY2FzZXMsIGFuIGFzc2VydGlvbiBpcyBjb25zaWRlcmVkIHRvIGJlIGEgInN0cm9uZ2Vy
IiBzdGF0ZW1lbnQgdGhhbiBhIGNsYWltLiBGb3IgZXhhbXBsZSwgdGhlIE94Zm9yZCBFbmdsaXNo
IERpY3Rpb25hcnkgZGVmaW5lcyBjbGFpbSBhczoNCg0KYSkgICAgICAgICAgdG8gc3RhdGUgYXMg
YmVpbmcgdGhlIGNhc2UsIHdpdGhvdXQgYmVpbmcgYWJsZSB0byBnaXZlIHByb29mOw0KDQpiKSAg
ICAgICAgICBhIHN0YXRlbWVudCB0aGF0IHNvbWV0aGluZyBpcyB0aGUgY2FzZSwNCmFuZCBhc3Nl
cnRpb24gYXM6IGEgY29uZmlkZW50IGFuZCBmb3JjZWZ1bCBzdGF0ZW1lbnQuIEhvd2V2ZXIsIGlu
IGEgZGlnaXRhbCBjb250ZXh0LCB0aGUgdGVybXMgImNvbmZpZGVudCIgYW5kICJmb3JjZWZ1bCIg
YXJlIG5vdCByZWFsbHkgbWVhbmluZ2Z1bC4NCkluIG9wZW4gbmV0d29ya3MsIHRoZXJlIHdpbGwg
YmUgYSBtb3JlIGNvbXBsZXggYW5kIGFtYml2YWxlbnQgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhl
IHBhcnR5IG1ha2luZyBhIHN0YXRlbWVudCAoaS5lLiwgcHJlc2VudGluZyBpZGVudGl0eSBpbmZv
cm1hdGlvbikgYW5kIHRoZSBwYXJ0eSB0aGF0IHJlbGllcyBvbiBpdC4gVGhlcmVmb3JlLCBhbnkg
c3RhdGVtZW50IGlzIGFzc3VtZWQgdG8gYmUgaW4gZG91YnQgYW5kLCBhcyBzdWNoLCBpcyBzdWJq
ZWN0IHRvIHZlcmlmaWNhdGlvbiBvciByZXF1ZXN0IGZvciBmdXJ0aGVyIGV2aWRlbmNlLiBOZWl0
aGVyIGNsYWltcyBub3IgYXNzZXJ0aW9ucyBjYW4gYmUgYXNzdW1lZCB0byBiZSBtYWRlIHdpdGgg
YW55IGF1dGhvcml0eSB3aGF0ZXZlci4gSXQgd2lsbCBhbHdheXMgYmUgdXAgdG8gdGhlIHJlbHlp
bmcgcGFydHkgdG8gZGVjaWRlIHdoZXRoZXIgb3Igbm90IHRvIGFjY2VwdCB0aGUgY2xhaW0gb3Ig
YXNzZXJ0aW9uIGJhc2VkIG9uIHZlcmlmaWNhdGlvbiBieSB0aGUgcmVseWluZyBwYXJ0eSAob3Ig
YnkgYSB2ZXJpZmllciBhY3RpbmcgYXQgdGhlIHJlcXVlc3Qgb2YgdGhlIHJlbHlpbmcgcGFydHkp
Lg0KDQoNCkZyb206IE5hdCBTYWtpbXVyYSBbbWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbV0NClNl
bnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAyOSwgMjAxMiA4OjA0IFBNDQpUbzogQW50aG9ueSBOYWRh
bGluDQpDYzogRGF2aWQgQ2hhZHdpY2s7IE1pa2UgSm9uZXM7IElFVEYgb2F1dGggV0cNClN1Ympl
Y3Q6IFJlOiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tl
bi0wNQ0KDQpUb255LA0KDQpTbyBkbyB5b3UgYWdyZWUgd2l0aCB0aGUgZm9sbG93aW5nIGRlZmlu
aXRpb24gaW4gLTA2PyBPciBwcmVmZXIgWC4xMjUyIGRlZmluaXRpb24/DQoNCg0KQ2xhaW0gIEEg
cGllY2Ugb2YgaW5mb3JtYXRpb24gYXNzZXJ0ZWQgYWJvdXQgYSBzdWJqZWN0LiAgSGVyZSwgQ2xh
aW1zDQoNCiAgICAgIGFyZSByZXByZXNlbnRlZCBuYW1lL3ZhbHVlIHBhaXJzLCBjb25zaXN0aW5n
IG9mIGEgQ2xhaW0gTmFtZSBhbmQgYQ0KDQogICAgICBDbGFpbSBWYWx1ZS4NCg0KTWlrZToNCg0K
UmVnYXJkaW5nIHRoZSBvcmRlcmluZyBvZiB0aGUgdGVybXMgaW4gdGVybWlub2xvZ3ksIHlvdSBz
aG91bGQgZWl0aGVyIHVzZSB0aGUgZGVwZW5kZW5jeSBjaGFpbiBvciBhbHBoYWJldGljIG9yZGVy
LiAoRm9ybWVyIGlzIG1vcmUgZGVzaXJhYmxlIGluIG15IHBvaW50IG9mIHZpZXcuKSBIb3dldmVy
LCBhcyBpdCBzdGFuZHMsIGl0IGlzIG5vbmUgb2YgdGhvc2UuIEZvciBleGFtcGxlLCB0aGUgdGVy
bSAiY2xhaW0iIGFwcGVhcnMgaW4gdGhlIGRlZmluaXRpb24gb2YgSldULCB3aGljaCBpcyB0aGUg
Zmlyc3QgdGVybSBpbiB0aGUgdGVybWlub2xvZ3ksIHdpdGhvdXQgaGF2aW5nIGJlZW4gZGVmaW5l
ZC4gSWYgeW91IGRvIG5vdCBtaW5kLCBJIHdpbGwgcmVvcmRlciB0aGVtIGFuZCBzZW5kIGl0IHRv
IHlvdS4NCg0KTmF0DQoNCk9uIFN1biwgRGVjIDMwLCAyMDEyIGF0IDk6MjggQU0sIEFudGhvbnkg
TmFkYWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5j
b20+PiB3cm90ZToNCkJ5IGRlZmluaXRpb24gYSBjbGFpbSBpcyBhbHdheXMgaW4gZG91YnQgdGh1
cyBpdCB3b3VsZCBub3QgY2FsbCBpdCBhIGNyZWRlbnRpYWwgdW50aWwgaXQgaXMgdmVyaWZpZWQN
Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5v
cmc8bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBEYXZp
ZCBDaGFkd2ljaw0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDI5LCAyMDEyIDE6NDIgQU0NClRv
OiBNaWtlIEpvbmVzDQpDYzogSUVURiBvYXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10g
cmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1DQoNCklmIGEgY2xhaW0g
cHJvdmlkZXMgcHJvb2YgdGhlbiBJIHdvdWxkIGNhbGwgaXQgYSBjcmVkZW50aWFsIG5vdCBhIGNs
YWltDQoNCkRhdmlkDQoNCk9uIDI5LzEyLzIwMTIgMDE6MTEsIE1pa2UgSm9uZXMgd3JvdGU6DQo+
IEkgZm91bmQgdGhlIFguMTI1MiBkZWZpbml0aW9uLiAgSXQgaXM6DQo+DQo+ICo2LjE4IGNsYWlt
ICpbYi1PRURdOiBUbyBzdGF0ZSBhcyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBiZWluZyBhYmxl
DQo+IHRvIGdpdmUgcHJvb2YuDQo+DQo+IFRoYXQgc2VlbXMgYm90aCBhIGJpdCB2YWd1ZSwgYW5k
IGFjdHVhbGx5IGluY29ycmVjdCwgYXMgdGhlIEpXVCBtYXkNCj4gaW5jbHVkZSBwcm9vZiBvZiB0
aGUgdmVyYWNpdHkgb2YgdGhlIGNsYWltLiAgUGxlYXNlIHNlZSB0aGUgdXBkYXRlZA0KPiBKV1Qg
ZHJhZnQgZm9yIGEgaG9wZWZ1bGx5IG1vcmUgdXNlZnVsIOKAnENsYWlt4oCdIGRlZmluaXRpb24u
DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICBCZXN0DQo+IHdpc2hlcywNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4NCj4gKkZyb206
Kk1pa2UgSm9uZXMNCj4gKlNlbnQ6KiBTdW5kYXksIERlY2VtYmVyIDIzLCAyMDEyIDE6MDMgUE0N
Cj4gKlRvOiogSmVmZiBIb2RnZXM7IE5hdCBTYWtpbXVyYQ0KPiAqQ2M6KiBJRVRGIG9hdXRoIFdH
DQo+ICpTdWJqZWN0OiogUkU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpz
b24td2ViLXRva2VuLTA1DQo+DQo+IFdoYXQgaXMgdGhlIFguMTI1MiBkZWZpbml0aW9uPw0KPg0K
PiAtLSBNaWtlDQo+DQo+ICpGcm9tOiogTmF0IFNha2ltdXJhDQo+ICpTZW50Oiog4oCORGVjZW1i
ZXLigI4g4oCOMjPigI4sIOKAjjIwMTIg4oCOMTDigI464oCOMDnigI4g4oCOQU0NCj4gKlRvOiog
PUplZmZIDQo+ICpDQzoqIE1pa2UgSm9uZXMsIElFVEYgb2F1dGggV0cNCj4gKlN1YmplY3Q6KiBS
ZTogW09BVVRILVdHXSByZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDUN
Cj4NCj4gUmUgZGVmaW5pdGlvbiBvZiAnY2xhaW0nLCBhcyBKV1QgaXMgc3VwcG9zZWQgdG8gYmUg
Z2VuZXJpYywgaXQgbWF5IGJlDQo+IGJldHRlciB0byBnbyB3aXRoIHRoZSBkZWZpbml0aW9uIG9m
IFguMTI1MiByYXRoZXIgdGhhbiBPSURDLg0KPg0KPiA9bmF0IHZpYSBpUGhvbmUNCj4NCj4gRGVj
IDI0LCAyMDEyIDI6NDLjgIE9SmVmZkggPEplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPG1h
aWx0bzpKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbT4NCj4gPG1haWx0bzpKZWZmLkhvZGdl
c0BraW5nc21vdW50YWluLmNvbTxtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+
Pj4g44Gu44Oh44OD44K744O844K4Og0KPg0KPj4NCj4+ID4gVGhhbmtzIGZvciB0aGUgcmVwbGll
cywgSmVmZi4gIFRoZXkgbWFrZSBzZW5zZS4gIFBhcnRpY3VsYXJseSwNCj4+ID4gdGhhbmtzIGZv
ciB0aGUgIkpTT04gVGV4dCBPYmplY3QiIHN1Z2dlc3Rpb24uDQo+Pg0KPj4gd2VsY29tZSwgZ2xh
ZCB0aGV5IG1hZGUgc29tZSBzZW5zZS4NCj4+DQo+PiBzaW1pbGFybHksIGlmIG9uZSBlbXBsb3lz
IEpTT04gYXJyYXlzLCBJJ2QgZGVmaW5lIGEgIkpTT04gdGV4dCBhcnJheSIuDQo+Pg0KPj4NCj4+
ID4gRm9yIHRoZSAiY2xhaW1zIiBkZWZpbml0aW9uLCBJJ20gYWN0dWFsbHkgcHJvbmUgdG8gZ28g
d2l0aA0KPj4gPmRlZmluaXRpb25zIGJhc2VkICBvbiB0aG9zZSBpbg0KPj4gPmh0dHA6Ly9vcGVu
aWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LW1lc3NhZ2VzLTFfMC0xMy5odG1sI3Rlcm1pbm9s
DQo+PiA+b2d5LQ0KPj4gPiBzcGVjaWZpY2FsbHk6DQo+PiA+DQo+PiA+IENsYWltDQo+PiA+IEEg
cGllY2Ugb2YgaW5mb3JtYXRpb24gYWJvdXQgYW4gRW50aXR5IHRoYXQgYSBDbGFpbXMgUHJvdmlk
ZXINCj4+ID4gYXNzZXJ0cyBhYm91dCB0aGF0IEVudGl0eS4NCj4+ID4gQ2xhaW1zIFByb3ZpZGVy
DQo+PiA+IEEgc3lzdGVtIG9yIHNlcnZpY2UgdGhhdCBjYW4gcmV0dXJuIENsYWltcyBhYm91dCBh
biBFbnRpdHkuDQo+PiA+IEVuZC1Vc2VyDQo+PiA+IEEgaHVtYW4gdXNlciBvZiBhIHN5c3RlbSBv
ciBzZXJ2aWNlLg0KPj4gPiBFbnRpdHkNCj4+ID4gU29tZXRoaW5nIHRoYXQgaGFzIGEgc2VwYXJh
dGUgYW5kIGRpc3RpbmN0IGV4aXN0ZW5jZSBhbmQgdGhhdCBjYW4NCj4+ID4gYmUgaWRlbnRpZmll
ZCBpbiBjb250ZXh0LiBBbiBFbmQtVXNlciBpcyBvbmUgZXhhbXBsZSBvZiBhbiBFbnRpdHkuDQo+
Pg0KPj4gd2VsbCwgaXQgc2VlbXMgdG8gbWUsIGdpdmVuIHRoZSBtYW5uZXIgaW4gd2hpY2ggdGhl
IEpXVCBzcGVjIGlzDQo+PiB3cml0dGVuLCBvbmUgY2FuIG1ha2UgdGhlIGNhc2UgdGhhdCBKV1Qg
Y2xhaW1zIGluIGdlbmVyYWwgYXJlbid0DQo+PiBuZWNlc3NhcmlseSBhYm91dCBhbiBFbnRpdHkg
KGFzIHRoZSBsYXR0ZXIgdGVybSBpcyB1c2VkIGluIHRoZQ0KPj4gY29udGV4dCBvZiB0aGUgT3Bl
bklEIENvbm5lY3Qgc3BlY3MpLCByYXRoZXIgdGhleSdyZSBpbiBnZW5lcmFsDQo+PiBzaW1wbHkg
YXNzZXJ0aW9ucyBhYm91dCBzb21ldGhpbmcocykuIHRoaXMgaXMgYmVjYXVzZSBhbGwgcHJlLWRl
ZmluZWQNCj4gSldUIGNsYWltIHR5cGVzIGFyZSBvcHRpb25hbCBhbmQgYWxsIEpXVCBzZW1hbnRp
Y3MgYXJlIGxlZnQgdXAgdG8NCj4gc3BlY3MgdGhhdCBwcm9maWxlIChha2EgcmUtdXNlKSB0aGUg
SldUIHNwZWMuDQo+Pg0KPj4gSFRILA0KPj4NCj4+ID1KZWZmSA0KPj4NCj4+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBPQXV0aCBtYWlsaW5nIGxp
c3QNCj4+T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRo
QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4+DQo+Pmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRo
QGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFp
bHRvOk9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9vYXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Ck9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3Jn
Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0N
Ck5hdCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDov
L25hdC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0K

--_000_4E1F6AAD24975D4BA5B1680429673943669E083FTK5EX14MBXC283r_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K
CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg
NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIg
MTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN
CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt
aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0
O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToy
IDExIDYgOSA3IDIgNSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt
YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i
b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO
ZXcgUm9tYW4iLCJzZXJpZiI7fQ0KaDENCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0
eWxlLWxpbms6IkhlYWRpbmcgMSBDaGFyIjsNCgltYXJnaW4tdG9wOjEyLjBwdDsNCgltYXJnaW4t
cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCgltYXJn
aW4tYm90dG9tOi4wMDAxcHQ7DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsNCglmb250LXNpemU6
MTYuMHB0Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMyRTc0
QjU7DQoJZm9udC13ZWlnaHQ6bm9ybWFsO30NCmgyDQoJe21zby1zdHlsZS1wcmlvcml0eTo5Ow0K
CW1zby1zdHlsZS1saW5rOiJIZWFkaW5nIDIgQ2hhciI7DQoJbWFyZ2luLXRvcDoxMi4wcHQ7DQoJ
bWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDozOS43
cHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50Oi0zOS43cHQ7DQoJcGFn
ZS1icmVhay1hZnRlcjphdm9pZDsNCglwdW5jdHVhdGlvbi13cmFwOnNpbXBsZTsNCgl0ZXh0LWF1
dG9zcGFjZTpub25lOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l
dyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7
fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv
cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw
cmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm
b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0
YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6
IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSGVhZGluZzFDaGFyDQoJe21zby1zdHlsZS1u
YW1lOiJIZWFkaW5nIDEgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxl
LWxpbms6IkhlYWRpbmcgMSI7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJ
Y29sb3I6IzJFNzRCNTt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVh
ZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJI
ZWFkaW5nIDIiOw0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJZm9u
dC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u
YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh
czt9DQpwLmVudW1sZXYxLCBsaS5lbnVtbGV2MSwgZGl2LmVudW1sZXYxDQoJe21zby1zdHlsZS1u
YW1lOmVudW1sZXYxOw0KCW1hcmdpbi10b3A6NC4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt
YXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDozOS43cHQ7DQoJbWFyZ2luLWJvdHRvbTou
MDAwMXB0Ow0KCXRleHQtYWxpZ246anVzdGlmeTsNCgl0ZXh0LWluZGVudDotMzkuN3B0Ow0KCXB1
bmN0dWF0aW9uLXdyYXA6c2ltcGxlOw0KCXRleHQtYXV0b3NwYWNlOm5vbmU7DQoJZm9udC1zaXpl
OjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4u
RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy
Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXIN
Cgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp
dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRh
aG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu
V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn
dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx
MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz
aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg
Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh
bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT
ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+SSBzdXJlIGhvcGUgd2UgZG9u4oCZdCBwbGFuL25lZWQgdG8gZ28g
aW50byB0aGF0IGxldmVsIG9mIHRlY2huaWNhbCBkZXRhaWwgaW4gdGhlIEpXVCBzcGVjLiZuYnNw
OyBJdOKAmXMgaW50ZW5kZWQgdG8gYmUgcmVhZGFibGUgYW5kIGFjY2Vzc2libGUgdG8gZGV2ZWxv
cGVycyDigJMgbm90IGENCiB0cmVhdGlzZSBvbiB0aGUgbWVhbmluZ3Mgb2Ygd29yZHMuIDwvc3Bh
bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s
b3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0gTWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls
ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w
cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
IEFudGhvbnkgTmFkYWxpbg0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBEZWNlbWJlciAy
OSwgMjAxMiA5OjM1IFBNPGJyPg0KPGI+VG86PC9iPiBOYXQgU2FraW11cmE8YnI+DQo8Yj5DYzo8
L2I+IERhdmlkIENoYWR3aWNrOyBNaWtlIEpvbmVzOyBJRVRGIG9hdXRoIFdHPGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJFOiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdl
Yi10b2tlbi0wNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4xMjUyIHMgaXQgaGFz
IGEgc2VjdGlvbiB0aGF0IGV4cGxhaW5zIHRoZSB1c2FnZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8aDI+PGEgbmFtZT0iX1RvYzI2
NzY0OTM3MSI+PC9hPjxhIG5hbWU9Il9Ub2MyNTk0MzY0NDEiPjwvYT48YSBuYW1lPSJfVG9jMjYx
NDQwNjg3Ij48L2E+PGEgbmFtZT0iX1RvYzI2NjQzNDkzMyI+PC9hPjxzcGFuIGxhbmc9IkVOLUdC
Ij5BLjImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2xhaW0vYXNzZXJ0aW9u
PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L2gyPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+VGhlIG1lYW5pbmcgb2YgdGhlIHRlcm1zIGNsYWltIGFuZCBhc3NlcnRp
b24gYXJlIGdlbmVyYWxseSBhZ3JlZWQgdG8gYmUgc29tZXdoYXQgc2ltaWxhciBidXQgd2l0aCBz
bGlnaHRseSBkaWZmZXJlbnQgbWVhbmluZ3MuIEluIHNvbWUgY2FzZXMsIGFuIGFzc2VydGlvbiBp
cyBjb25zaWRlcmVkIHRvIGJlIGEgJnF1b3Q7c3Ryb25nZXImcXVvdDsgc3RhdGVtZW50IHRoYW4g
YSBjbGFpbS4gRm9yIGV4YW1wbGUsIHRoZSBPeGZvcmQNCiBFbmdsaXNoIERpY3Rpb25hcnkgZGVm
aW5lcyBjbGFpbSBhczogPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZW51bWxldjEiPjxzcGFu
IGxhbmc9IkVOLUdCIj5hKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB0byBzdGF0ZSBhcyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBiZWluZyBh
YmxlIHRvIGdpdmUgcHJvb2Y7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImVudW1s
ZXYxIj48c3BhbiBsYW5nPSJFTi1HQiI+YikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYSBzdGF0ZW1lbnQgdGhhdCBzb21ldGhpbmcgaXMgdGhl
IGNhc2UsDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQg
YXNzZXJ0aW9uIGFzOiBhIGNvbmZpZGVudCBhbmQgZm9yY2VmdWwgc3RhdGVtZW50LiBIb3dldmVy
LCBpbiBhIGRpZ2l0YWwgY29udGV4dCwgdGhlIHRlcm1zICZxdW90O2NvbmZpZGVudCZxdW90OyBh
bmQgJnF1b3Q7Zm9yY2VmdWwmcXVvdDsgYXJlIG5vdCByZWFsbHkgbWVhbmluZ2Z1bC4NCjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0
LWxhbmd1YWdlOkpBIj5JbiBvcGVuIG5ldHdvcmtzLCB0aGVyZSB3aWxsIGJlIGEgbW9yZSBjb21w
bGV4IGFuZCBhbWJpdmFsZW50IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBwYXJ0eSBtYWtpbmcg
YSBzdGF0ZW1lbnQgKGkuZS4sIHByZXNlbnRpbmcgaWRlbnRpdHkgaW5mb3JtYXRpb24pIGFuZCB0
aGUgcGFydHkgdGhhdCByZWxpZXMgb24gaXQuIFRoZXJlZm9yZSwgYW55DQogc3RhdGVtZW50IGlz
IGFzc3VtZWQgdG8gYmUgaW4gZG91YnQgYW5kLCBhcyBzdWNoLCBpcyBzdWJqZWN0IHRvIHZlcmlm
aWNhdGlvbiBvciByZXF1ZXN0IGZvciBmdXJ0aGVyIGV2aWRlbmNlLiBOZWl0aGVyIGNsYWltcyBu
b3IgYXNzZXJ0aW9ucyBjYW4gYmUgYXNzdW1lZCB0byBiZSBtYWRlIHdpdGggYW55IGF1dGhvcml0
eSB3aGF0ZXZlci4gSXQgd2lsbCBhbHdheXMgYmUgdXAgdG8gdGhlIHJlbHlpbmcgcGFydHkgdG8g
ZGVjaWRlIHdoZXRoZXIgb3INCiBub3QgdG8gYWNjZXB0IHRoZSBjbGFpbSBvciBhc3NlcnRpb24g
YmFzZWQgb24gdmVyaWZpY2F0aW9uIGJ5IHRoZSByZWx5aW5nIHBhcnR5IChvciBieSBhIHZlcmlm
aWVyIGFjdGluZyBhdCB0aGUgcmVxdWVzdCBvZiB0aGUgcmVseWluZyBwYXJ0eSkuPC9zcGFuPjxv
OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PC9hPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7
c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi
PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBOYXQgU2FraW11
cmEgWzxhIGhyZWY9Im1haWx0bzpzYWtpbXVyYUBnbWFpbC5jb20iPm1haWx0bzpzYWtpbXVyYUBn
bWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBEZWNlbWJlciAyOSwg
MjAxMiA4OjA0IFBNPGJyPg0KPGI+VG86PC9iPiBBbnRob255IE5hZGFsaW48YnI+DQo8Yj5DYzo8
L2I+IERhdmlkIENoYWR3aWNrOyBNaWtlIEpvbmVzOyBJRVRGIG9hdXRoIFdHPGJyPg0KPGI+U3Vi
amVjdDo8L2I+IFJlOiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdl
Yi10b2tlbi0wNTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9ueSwmbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGRvIHlvdSBhZ3Jl
ZSB3aXRoIHRoZSBmb2xsb3dpbmcgZGVmaW5pdGlvbiBpbiAtMDY/IE9yIHByZWZlciBYLjEyNTIg
ZGVmaW5pdGlvbj8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZT48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Q2xhaW0mbmJzcDsgQSBwaWVjZSBvZiBpbmZv
cm1hdGlvbiBhc3NlcnRlZCBhYm91dCBhIHN1YmplY3QuJm5ic3A7IEhlcmUsIENsYWltczxvOnA+
PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFyZSByZXByZXNlbnRlZCBuYW1lL3ZhbHVl
IHBhaXJzLCBjb25zaXN0aW5nIG9mIGEgQ2xhaW0gTmFtZSBhbmQgYTxvOnA+PC9vOnA+PC9zcGFu
PjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IENsYWltIFZhbHVlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+TWlrZTombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIHRoZSBvcmRlcmluZyBvZiB0aGUgdGVy
bXMgaW4gdGVybWlub2xvZ3ksIHlvdSBzaG91bGQgZWl0aGVyIHVzZSB0aGUgZGVwZW5kZW5jeSBj
aGFpbiBvciBhbHBoYWJldGljIG9yZGVyLiAoRm9ybWVyIGlzIG1vcmUgZGVzaXJhYmxlIGluIG15
IHBvaW50IG9mIHZpZXcuKSBIb3dldmVyLCBhcyBpdCBzdGFuZHMsIGl0IGlzIG5vbmUgb2YgdGhv
c2UuIEZvciBleGFtcGxlLCB0aGUgdGVybSAmcXVvdDtjbGFpbSZxdW90Ow0KIGFwcGVhcnMgaW4g
dGhlIGRlZmluaXRpb24gb2YgSldULCB3aGljaCBpcyB0aGUgZmlyc3QgdGVybSBpbiB0aGUgdGVy
bWlub2xvZ3ksIHdpdGhvdXQgaGF2aW5nIGJlZW4gZGVmaW5lZC4gSWYgeW91IGRvIG5vdCBtaW5k
LCBJIHdpbGwgcmVvcmRlciB0aGVtIGFuZCBzZW5kIGl0IHRvIHlvdS4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TmF0PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgRGVj
IDMwLCAyMDEyIGF0IDk6MjggQU0sIEFudGhvbnkgTmFkYWxpbiAmbHQ7PGEgaHJlZj0ibWFpbHRv
OnRvbnluYWRAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnluYWRAbWljcm9zb2Z0
LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo
dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CeSBkZWZp
bml0aW9uIGEgY2xhaW0gaXMgYWx3YXlzIGluIGRvdWJ0IHRodXMgaXQgd291bGQgbm90IGNhbGwg
aXQgYSBjcmVkZW50aWFsIHVudGlsIGl0IGlzIHZlcmlmaWVkPG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08
YnI+DQpGcm9tOiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1dGgt
Ym91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNl
c0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBEYXZp
ZCBDaGFkd2ljazxicj4NClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAyOSwgMjAxMiAxOjQyIEFN
PGJyPg0KVG86IE1pa2UgSm9uZXM8YnI+DQpDYzogSUVURiBvYXV0aCBXRzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YmplY3Q6IFJl
OiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxi
cj4NCjxicj4NCklmIGEgY2xhaW0gcHJvdmlkZXMgcHJvb2YgdGhlbiBJIHdvdWxkIGNhbGwgaXQg
YSBjcmVkZW50aWFsIG5vdCBhIGNsYWltPGJyPg0KPGJyPg0KRGF2aWQ8YnI+DQo8YnI+DQpPbiAy
OS8xMi8yMDEyIDAxOjExLCBNaWtlIEpvbmVzIHdyb3RlOjxicj4NCiZndDsgSSBmb3VuZCB0aGUg
WC4xMjUyIGRlZmluaXRpb24uICZuYnNwO0l0IGlzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICo2LjE4
IGNsYWltICpbYi1PRURdOiBUbyBzdGF0ZSBhcyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBiZWlu
ZyBhYmxlPGJyPg0KJmd0OyB0byBnaXZlIHByb29mLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYXQg
c2VlbXMgYm90aCBhIGJpdCB2YWd1ZSwgYW5kIGFjdHVhbGx5IGluY29ycmVjdCwgYXMgdGhlIEpX
VCBtYXk8YnI+DQomZ3Q7IGluY2x1ZGUgcHJvb2Ygb2YgdGhlIHZlcmFjaXR5IG9mIHRoZSBjbGFp
bS4gJm5ic3A7UGxlYXNlIHNlZSB0aGUgdXBkYXRlZDxicj4NCiZndDsgSldUIGRyYWZ0IGZvciBh
IGhvcGVmdWxseSBtb3JlIHVzZWZ1bCDigJxDbGFpbeKAnSBkZWZpbml0aW9uLjxicj4NCiZndDs8
YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Jl
c3Q8YnI+DQomZ3Q7IHdpc2hlcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstLSBNaWtlPGJyPg0KJmd0Ozxicj4NCiZndDsg
KkZyb206Kk1pa2UgSm9uZXM8YnI+DQomZ3Q7ICpTZW50OiogU3VuZGF5LCBEZWNlbWJlciAyMywg
MjAxMiAxOjAzIFBNPGJyPg0KJmd0OyAqVG86KiBKZWZmIEhvZGdlczsgTmF0IFNha2ltdXJhPGJy
Pg0KJmd0OyAqQ2M6KiBJRVRGIG9hdXRoIFdHPGJyPg0KJmd0OyAqU3ViamVjdDoqIFJFOiBbT0FV
VEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxicj4NCiZn
dDs8YnI+DQomZ3Q7IFdoYXQgaXMgdGhlIFguMTI1MiBkZWZpbml0aW9uPzxicj4NCiZndDs8YnI+
DQomZ3Q7IC0tIE1pa2U8YnI+DQomZ3Q7PGJyPg0KJmd0OyAqRnJvbToqIE5hdCBTYWtpbXVyYTxi
cj4NCiZndDsgKlNlbnQ6KiDigI5EZWNlbWJlcuKAjiDigI4yM+KAjiwg4oCOMjAxMiDigI4xMOKA
jjrigI4wOeKAjiDigI5BTTxicj4NCiZndDsgKlRvOiogPUplZmZIPGJyPg0KJmd0OyAqQ0M6KiBN
aWtlIEpvbmVzLCBJRVRGIG9hdXRoIFdHPGJyPg0KJmd0OyAqU3ViamVjdDoqIFJlOiBbT0FVVEgt
V0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxicj4NCiZndDs8
YnI+DQomZ3Q7IFJlIGRlZmluaXRpb24gb2YgJ2NsYWltJywgYXMgSldUIGlzIHN1cHBvc2VkIHRv
IGJlIGdlbmVyaWMsIGl0IG1heSBiZTxicj4NCiZndDsgYmV0dGVyIHRvIGdvIHdpdGggdGhlIGRl
ZmluaXRpb24gb2YgWC4xMjUyIHJhdGhlciB0aGFuIE9JREMuPGJyPg0KJmd0Ozxicj4NCiZndDsg
PW5hdCB2aWEgaVBob25lPGJyPg0KJmd0Ozxicj4NCiZndDsgRGVjIDI0LCAyMDEyIDI6NDI8c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jgIE8L3NwYW4+PUpl
ZmZIICZsdDs8YSBocmVmPSJtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20iPkpl
ZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPC9hPjxicj4NCiZndDsgJmx0O21haWx0bzo8YSBo
cmVmPSJtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20iPkplZmYuSG9kZ2VzQGtp
bmdzbW91bnRhaW4uY29tPC9hPiZndDsmZ3Q7DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7TVMgR290aGljJnF1b3Q7Ij7jga7jg6Hjg4Pjgrvjg7zjgrg8L3NwYW4+Ojxicj4NCiZndDs8
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgVGhhbmtzIGZvciB0aGUgcmVwbGllcywg
SmVmZi4gJm5ic3A7VGhleSBtYWtlIHNlbnNlLiAmbmJzcDtQYXJ0aWN1bGFybHksPGJyPg0KJmd0
OyZndDsgJmd0OyB0aGFua3MgZm9yIHRoZSAmcXVvdDtKU09OIFRleHQgT2JqZWN0JnF1b3Q7IHN1
Z2dlc3Rpb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyB3ZWxjb21lLCBnbGFkIHRoZXkg
bWFkZSBzb21lIHNlbnNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgc2ltaWxhcmx5LCBp
ZiBvbmUgZW1wbG95cyBKU09OIGFycmF5cywgSSdkIGRlZmluZSBhICZxdW90O0pTT04gdGV4dCBh
cnJheSZxdW90Oy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJmd0
OyBGb3IgdGhlICZxdW90O2NsYWltcyZxdW90OyBkZWZpbml0aW9uLCBJJ20gYWN0dWFsbHkgcHJv
bmUgdG8gZ28gd2l0aDxicj4NCiZndDsmZ3Q7ICZndDtkZWZpbml0aW9ucyBiYXNlZCAmbmJzcDtv
biB0aG9zZSBpbjxicj4NCiZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5ldC9z
cGVjcy9vcGVuaWQtY29ubmVjdC1tZXNzYWdlcy0xXzAtMTMuaHRtbCN0ZXJtaW5vbCIgdGFyZ2V0
PSJfYmxhbmsiPmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LW1lc3NhZ2Vz
LTFfMC0xMy5odG1sI3Rlcm1pbm9sPC9hPjxicj4NCiZndDsmZ3Q7ICZndDtvZ3ktPGJyPg0KJmd0
OyZndDsgJmd0OyBzcGVjaWZpY2FsbHk6PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsmZ3Q7
ICZndDsgQ2xhaW08YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEEgcGllY2Ugb2YgaW5mb3JtYXRpb24gYWJv
dXQgYW4gRW50aXR5IHRoYXQgYSBDbGFpbXMgUHJvdmlkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IGFz
c2VydHMgYWJvdXQgdGhhdCBFbnRpdHkuPGJyPg0KJmd0OyZndDsgJmd0OyBDbGFpbXMgUHJvdmlk
ZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEEgc3lzdGVtIG9yIHNlcnZpY2UgdGhhdCBjYW4gcmV0dXJu
IENsYWltcyBhYm91dCBhbiBFbnRpdHkuPGJyPg0KJmd0OyZndDsgJmd0OyBFbmQtVXNlcjxicj4N
CiZndDsmZ3Q7ICZndDsgQSBodW1hbiB1c2VyIG9mIGEgc3lzdGVtIG9yIHNlcnZpY2UuPGJyPg0K
Jmd0OyZndDsgJmd0OyBFbnRpdHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFNvbWV0aGluZyB0aGF0IGhh
cyBhIHNlcGFyYXRlIGFuZCBkaXN0aW5jdCBleGlzdGVuY2UgYW5kIHRoYXQgY2FuPGJyPg0KJmd0
OyZndDsgJmd0OyBiZSBpZGVudGlmaWVkIGluIGNvbnRleHQuIEFuIEVuZC1Vc2VyIGlzIG9uZSBl
eGFtcGxlIG9mIGFuIEVudGl0eS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHdlbGwsIGl0
IHNlZW1zIHRvIG1lLCBnaXZlbiB0aGUgbWFubmVyIGluIHdoaWNoIHRoZSBKV1Qgc3BlYyBpczxi
cj4NCiZndDsmZ3Q7IHdyaXR0ZW4sIG9uZSBjYW4gbWFrZSB0aGUgY2FzZSB0aGF0IEpXVCBjbGFp
bXMgaW4gZ2VuZXJhbCBhcmVuJ3Q8YnI+DQomZ3Q7Jmd0OyBuZWNlc3NhcmlseSBhYm91dCBhbiBF
bnRpdHkgKGFzIHRoZSBsYXR0ZXIgdGVybSBpcyB1c2VkIGluIHRoZTxicj4NCiZndDsmZ3Q7IGNv
bnRleHQgb2YgdGhlIE9wZW5JRCBDb25uZWN0IHNwZWNzKSwgcmF0aGVyIHRoZXkncmUgaW4gZ2Vu
ZXJhbDxicj4NCiZndDsmZ3Q7IHNpbXBseSBhc3NlcnRpb25zIGFib3V0IHNvbWV0aGluZyhzKS4g
dGhpcyBpcyBiZWNhdXNlIGFsbCBwcmUtZGVmaW5lZDxicj4NCiZndDsgSldUIGNsYWltIHR5cGVz
IGFyZSBvcHRpb25hbCBhbmQgYWxsIEpXVCBzZW1hbnRpY3MgYXJlIGxlZnQgdXAgdG88YnI+DQom
Z3Q7IHNwZWNzIHRoYXQgcHJvZmlsZSAoYWthIHJlLXVzZSkgdGhlIEpXVCBzcGVjLjxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsgSFRILDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgPUpl
ZmZIPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxi
cj4NCiZndDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9y
ZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGll
dGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0K
Jmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0ibWFp
bHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9
Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2Js
YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4N
CiZndDs8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRm
Lm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+
DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4N
CjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRh
cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRo
PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286
cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5h
dCk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFpcm1hbiwg
T3BlbklEIEZvdW5kYXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8i
IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRf
ZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_4E1F6AAD24975D4BA5B1680429673943669E083FTK5EX14MBXC283r_--

From d.w.chadwick@kent.ac.uk  Sun Dec 30 00:20:24 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C32921F8890 for ; Sun, 30 Dec 2012 00:20:24 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yimmGrqzQKwF for ; Sun, 30 Dec 2012 00:20:23 -0800 (PST)
Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCC121F8871 for ; Sun, 30 Dec 2012 00:20:23 -0800 (PST)
Received: from mx0.kent.ac.uk ([129.12.21.32]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TpE84-0008Oz-Rc; Sun, 30 Dec 2012 08:20:20 +0000
Received: from cpc2-hudd6-0-0-cust318.4-1.cable.virginmedia.com ([82.30.77.63] helo=[192.168.1.3]) by mx0.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TpE84-0004xE-Db; Sun, 30 Dec 2012 08:20:20 +0000
Message-ID: <50DFF93F.5050906@kent.ac.uk>
Date: Sun, 30 Dec 2012 08:20:15 +0000
From: David Chadwick 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Anthony Nadalin 
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk> <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com>
In-Reply-To: <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 08:20:24 -0000

On 30/12/2012 00:28, Anthony Nadalin wrote:
> By definition a claim is always in doubt thus it would not call it a credential until it is verified

No this is not correct, since you can have valid and invalid 
credentials. You present your credentials to the RP, and the RP verifies 
them based on the proof they contain.

If you present a claim without any proof then it is not a credential and 
it cannot be verified (since it contains no proof) without the RP 
obtaining some proof information from elsewhere (such as showing it to 
the issuer and asking them if it is genuine or not).

So I would say that in Oauth you can present a claim or a credential.

regards

David

>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of David Chadwick
> Sent: Saturday, December 29, 2012 1:42 AM
> To: Mike Jones
> Cc: IETF oauth WG
> Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>
> If a claim provides proof then I would call it a credential not a claim
>
> David
>
> On 29/12/2012 01:11, Mike Jones wrote:
>> I found the X.1252 definition.  It is:
>>
>> *6.18 claim *[b-OED]: To state as being the case, without being able
>> to give proof.
>>
>> That seems both a bit vague, and actually incorrect, as the JWT may
>> include proof of the veracity of the claim.  Please see the updated
>> JWT draft for a hopefully more useful “Claim” definition.
>>
>>                                                               Best
>> wishes,
>>
>>                                                               -- Mike
>>
>> *From:*Mike Jones
>> *Sent:* Sunday, December 23, 2012 1:03 PM
>> *To:* Jeff Hodges; Nat Sakimura
>> *Cc:* IETF oauth WG
>> *Subject:* RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>>
>> What is the X.1252 definition?
>>
>> -- Mike
>>
>> *From:* Nat Sakimura
>> *Sent:* ‎December‎ ‎23‎, ‎2012 ‎10‎:‎09‎ ‎AM
>> *To:* =JeffH
>> *CC:* Mike Jones, IETF oauth WG
>> *Subject:* Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>>
>> Re definition of 'claim', as JWT is supposed to be generic, it may be
>> better to go with the definition of X.1252 rather than OIDC.
>>
>> =nat via iPhone
>>
>> Dec 24, 2012 2:42、=JeffH > > のメッセージ:
>>
>>>
>>>> Thanks for the replies, Jeff.  They make sense.  Particularly,
>>>> thanks for the "JSON Text Object" suggestion.
>>>
>>> welcome, glad they made some sense.
>>>
>>> similarly, if one employs JSON arrays, I'd define a "JSON text array".
>>>
>>>
>>>> For the "claims" definition, I'm actually prone to go with
>>>> definitions based  on those in
>>>> http://openid.net/specs/openid-connect-messages-1_0-13.html#terminol
>>>> ogy-
>>>> specifically:
>>>>
>>>> Claim
>>>> A piece of information about an Entity that a Claims Provider
>>>> asserts about that Entity.
>>>> Claims Provider
>>>> A system or service that can return Claims about an Entity.
>>>> End-User
>>>> A human user of a system or service.
>>>> Entity
>>>> Something that has a separate and distinct existence and that can
>>>> be identified in context. An End-User is one example of an Entity.
>>>
>>> well, it seems to me, given the manner in which the JWT spec is
>>> written, one can make the case that JWT claims in general aren't
>>> necessarily about an Entity (as the latter term is used in the
>>> context of the OpenID Connect specs), rather they're in general
>>> simply assertions about something(s). this is because all pre-defined
>> JWT claim types are optional and all JWT semantics are left up to
>> specs that profile (aka re-use) the JWT spec.
>>>
>>> HTH,
>>>
>>> =JeffH
>>>
>>> _______________________________________________
>>> OAuth mailing 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 mark@novemberborn.net  Sun Dec 30 04:53:36 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F35121F8931 for ; Sun, 30 Dec 2012 04:53:36 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJuHQBYlxlHI for ; Sun, 30 Dec 2012 04:53:35 -0800 (PST)
Received: from wolfback.joyent.us (wolfback.joyent.us [8.17.171.168]) by ietfa.amsl.com (Postfix) with ESMTP id 60A9721F8599 for ; Sun, 30 Dec 2012 04:53:35 -0800 (PST)
Received: from [192.168.1.112] (177-134-045-062.dynamic.caiway.nl [62.45.134.177]) by wolfback.joyent.us (Postfix) with ESMTPSA id 84D4B359FC; Sun, 30 Dec 2012 12:53:33 +0000 (GMT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
From: Mark Wubben 
In-Reply-To: <50D98CD3.9050000@lodderstedt.net>
Date: Sun, 30 Dec 2012 13:53:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net>
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.1498)
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 12:53:36 -0000

On 25 Dec 2012, at 12:24, Torsten Lodderstedt  =
wrote:
> You raised an interesting point. Is it desirable to share an access =
grant among different client instances? I would like to discuss this =
topic in the working group.
>=20
> If we assume it is desirable, how would the authorization process look =
alike?
>=20
> I would assume that as result of the authorization process of the 1st =
client instance, the authorization server stores an access grant, which =
is identified by the client_id and the user_id of the resource owner. =
Moreover, it creates a refresh token, which the 1st client instance uses =
to obtain new access tokens. As this client is public, the refresh token =
is the credential the intial client uses to prove its identity.
>=20
> How does the 2nd client instance join the party? I would assume the =
2nd client to initiate another code grant type flow (using the same =
client_id as the 1st client). I see two ways the authorization server =
could process this process:
>=20
> 1) After authenticating the resource owner, the authorization server =
finds the existing access grant for the client_id/user_id combination =
and automatically issues tokens w/o further user consent. Since the =
authorization server cannot authenticate the client_id, a malicious =
client could obtain and abuse the access grant of the legitimate client.

=85

> 2) The authorization server asks the resource owner for user consent =
and issues another pair of access/refresh token to the 2nd client. In =
this case, why would one bind this tokens to the already existing access =
grant? This would limit the resource owners capability to revoke grants =
for particular instances. I would rather create another access grant.
>=20
> Based on this thoughts I think it is not desirable to share an access =
grant among different client instances.

My specific use case is an official mobile app that takes user =
credentials and exchanges them directly for an access token. There is no =
explicit user consent. The AS could reuse the existing access grant, or =
create a new one.They would have the same scope regardless. Other than =
increased storage requirements on the server there is no difference.

Creating different access grants for every authorization would allow the =
grant for device A to be revoked while device B keeps working. The user =
could also remove the app from device A and then re-install it, which =
leaves the old access grant intact and not revoked. That may be solved =
by tying authorizations to specific devices, which OAuth currently does =
not cover. I'm also not sure whether that'd be feasible technically.

--
Mark Wubben

http://novemberborn.net
http://twitter.com/novemberborn


From mark@novemberborn.net  Sun Dec 30 04:53:39 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A07321F8599 for ; Sun, 30 Dec 2012 04:53:39 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsuF6pgJJpbJ for ; Sun, 30 Dec 2012 04:53:38 -0800 (PST)
Received: from wolfback.joyent.us (wolfback.joyent.us [8.17.171.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7D77C21F8962 for ; Sun, 30 Dec 2012 04:53:38 -0800 (PST)
Received: from [192.168.1.112] (177-134-045-062.dynamic.caiway.nl [62.45.134.177]) by wolfback.joyent.us (Postfix) with ESMTPSA id B711C359FF; Sun, 30 Dec 2012 12:53:37 +0000 (GMT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.1 \(1498\))
From: Mark Wubben 
In-Reply-To: <50DB2269.6020501@lodderstedt.net>
Date: Sun, 30 Dec 2012 13:53:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2B4D546B-AF2A-4C45-964B-5D667FCC566D@novemberborn.net>
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net> <57BD8A42-A633-4547-97F6-086365282817@ve7jtb.com> <50DB2269.6020501@lodderstedt.net>
To: Torsten Lodderstedt 
X-Mailer: Apple Mail (2.1498)
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 12:53:39 -0000

On 26 Dec 2012, at 17:14, Torsten Lodderstedt  =
wrote:
> What does this mean? I would like to focus on the revocation of the =
token actually passed to the revocation endpoint and leave the impact on =
other related tokens and the authorization itself to the authorization =
server's policy. The authorization server may incorporate the client =
type into its revocation policy. =20
>=20
> My base assumption is that a client must be prepared to handle =
invalidation of tokens at any time. So from an interoperability =
perspective, it's not necessary to dictate a certain revocation policy =
to authorization servers. =20
>=20
> Current text:
>=20
> In the next step, the authorization server invalidates the token and =
the respective authorization. If the particular token is a refresh token =
and the authorization server supports the revocation of access tokens, =
then the authorization server SHOULD also invalidate all access tokens =
based on the same authorization (see Implementation Note).
>=20
> The client MUST NOT use the token again after revocation.
>=20
> Proposal:
>=20
>         In the next step, the authorization server invalidates the =
token. The client MUST NOT use this token again after revocation.=20
> =20
>         Depending on the authorization server's revocation policy, the =
revocation of a particular token may cause the revocation of related =
tokens and the underlying authorization.=20
>         If the particular token is a refresh token and the =
authorization server supports the revocation of access tokens, then the =
authorization server SHOULD also invalidate all access tokens based on   =
      the same authorization (see Implementation Note).
>=20
> Thoughts?

That works for my use case I think, assuming "authorization" doesn't =
specifically mean "access grant" but whatever the AS takes it to mean.

--
Mark Wubben

http://novemberborn.net
http://twitter.com/novemberborn


From torsten@lodderstedt.net  Sun Dec 30 05:49:09 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731EC21F8962 for ; Sun, 30 Dec 2012 05:49:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.019
X-Spam-Level: 
X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA2qK9qnOTql for ; Sun, 30 Dec 2012 05:49:08 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0150621F8972 for ; Sun, 30 Dec 2012 05:49:07 -0800 (PST)
Received: from [91.2.71.61] (helo=[192.168.71.56]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1TpJGD-0005pL-Iw; Sun, 30 Dec 2012 14:49:05 +0100
References: <20CEED86-7DA4-4EFE-89A8-D476FACB565F@gmx.net> <1A06ACC5-089D-4FD5-8531-4AC84FC0B6F7@novemberborn.net> <50D98CD3.9050000@lodderstedt.net> 
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <626401CF-1141-4569-B212-365500A71C7C@lodderstedt.net>
X-Mailer: iPad Mail (10A523)
From: Torsten Lodderstedt 
Date: Sun, 30 Dec 2012 14:49:06 +0100
To: Mark Wubben 
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC1vbmxpbmUuZGU=
Cc: "oauth@ietf.org WG" 
Subject: Re: [OAUTH-WG] WGLC for draft-ietf-oauth-revocation-03
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 13:49:09 -0000

Am 30.12.2012 um 13:53 schrieb Mark Wubben :

> On 25 Dec 2012, at 12:24, Torsten Lodderstedt  wr=
ote:
>> You raised an interesting point. Is it desirable to share an access grant=
 among different client instances? I would like to discuss this topic in the=
 working group.
>>=20
>> If we assume it is desirable, how would the authorization process look al=
ike?
>>=20
>> I would assume that as result of the authorization process of the 1st cli=
ent instance, the authorization server stores an access grant, which is iden=
tified by the client_id and the user_id of the resource owner. Moreover, it c=
reates a refresh token, which the 1st client instance uses to obtain new acc=
ess tokens. As this client is public, the refresh token is the credential th=
e intial client uses to prove its identity.
>>=20
>> How does the 2nd client instance join the party? I would assume the 2nd c=
lient to initiate another code grant type flow (using the same client_id as t=
he 1st client). I see two ways the authorization server could process this p=
rocess:
>>=20
>> 1) After authenticating the resource owner, the authorization server find=
s the existing access grant for the client_id/user_id combination and automa=
tically issues tokens w/o further user consent. Since the authorization serv=
er cannot authenticate the client_id, a malicious client could obtain and ab=
use the access grant of the legitimate client.
>=20
> =E2=80=A6
>=20
>> 2) The authorization server asks the resource owner for user consent and i=
ssues another pair of access/refresh token to the 2nd client. In this case, w=
hy would one bind this tokens to the already existing access grant? This wou=
ld limit the resource owners capability to revoke grants for particular inst=
ances. I would rather create another access grant.
>>=20
>> Based on this thoughts I think it is not desirable to share an access gra=
nt among different client instances.
>=20
> My specific use case is an official mobile app that takes user credentials=
 and exchanges them directly for an access token. There is no explicit user c=
onsent. The AS could reuse the existing access grant, or create a new one.Th=
ey would have the same scope regardless. Other than increased storage requir=
ements on the server there is no difference.
>=20
> Creating different access grants for every authorization would allow the g=
rant for device A to be revoked while device B keeps working. The user could=
 also remove the app from device A and then re-install it, which leaves the o=
ld access grant intact and not revoked.

> That may be solved by tying authorizations to specific devices, which OAut=
h currently does not cover. I'm also not sure whether that'd be feasible tec=
hnically.

I would assume that the app revokes its refresh token during uninstall, whic=
h should cause the revocation of the authorization as well. Or it's automati=
cally invalidated after some inactivity period.

regards,
Torsten.

>=20
> --
> Mark Wubben
>=20
> http://novemberborn.net
> http://twitter.com/novemberborn
>=20

From asanso@adobe.com  Sun Dec 30 08:01:07 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C93D21F8470 for ; Sun, 30 Dec 2012 08:01:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.443
X-Spam-Level: 
X-Spam-Status: No, score=-101.443 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUL4vD01b9py for ; Sun, 30 Dec 2012 08:01:04 -0800 (PST)
Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id BEB0C21F844F for ; Sun, 30 Dec 2012 08:01:00 -0800 (PST)
Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUOBlOyvp3LZrAD1sx1/gXh7HC6ZbCWWN@postini.com; Sun, 30 Dec 2012 08:01:03 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4b [10.128.4.237]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id qBUG0wC9016800; Sun, 30 Dec 2012 08:00:58 -0800 (PST)
Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id qBUG0uXL008015; Sun, 30 Dec 2012 08:00:57 -0800 (PST)
Received: from eurhub01.eur.adobe.com (10.128.4.30) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sun, 30 Dec 2012 08:00:55 -0800
Received: from eurmbx01.eur.adobe.com ([10.128.4.32]) by eurhub01.eur.adobe.com ([10.128.4.30]) with mapi; Sun, 30 Dec 2012 16:00:53 +0000
From: Antonio Sanso 
To: Nat Sakimura 
Date: Sun, 30 Dec 2012 16:00:39 +0000
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3mptgabsmOkOAnSmaeprYUN/ryrA==
Message-ID: <27E7BEAA-5922-48D4-98B1-C063F2C782F9@adobe.com>
References: <50B53D3E.1000107@KingsMountain.com> <4E1F6AAD24975D4BA5B168042967394366979DAD@TK5EX14MBXC283.redmond.corp.microsoft.com>  <7816700B-65D6-4C91-8D62-A2EED02442F7@adobe.com> <-2232710541978003268@unknownmsgid>
In-Reply-To: <-2232710541978003268@unknownmsgid>
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_27E7BEAA592248D498B1C063F2C782F9adobecom_"
MIME-Version: 1.0
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 16:01:07 -0000

--_000_27E7BEAA592248D498B1C063F2C782F9adobecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmtzIE5hdCwNCg0Kc28gSSBhc3N1bWUgWzBdIGlzIG91dCBvZiBkYXRlIHNpbmNlIG5ldGhl
ciBSU0EtUEtDUzEgYW5kIEFFUy0qIGFyZSBub3QgQUVBRCBhbGdvcml0aG1zIGFzIGxvbmcgYXMg
SSBrbm93Lg0KDQpRdW90aW5nOg0KDQoiSWYgYW4gaW1wbGVtZW50YXRpb24gcHJvdmlkZXMgZW5j
cnlwdGlvbiBjYXBhYmlsaXRpZXMsIG9mIHRoZSBKV0UNCg0KICAgZW5jcnlwdGlvbiBhbGdvcml0
aG1zLCBvbmx5IFJTQS1QS0NTMS0xLjUgd2l0aCAyMDQ4IGJpdCBrZXlzLCBBRVMtDQogICAxMjgt
S1csIEFFUy0yNTYtS1csIEFFUy0xMjgtQ0JDLCBhbmQgQUVTLTI1Ni1DQkMgTVVTVCBiZSBpbXBs
ZW1lbnRlZA0KICAgYnkgY29uZm9ybWluZyBpbXBsZW1lbnRhdGlvbnMuICBJdCBpcyBSRUNPTU1F
TkRFRCB0aGF0DQogICBpbXBsZW1lbnRhdGlvbnMgYWxzbyBzdXBwb3J0IEVDREgtRVMgd2l0aCAy
NTYgYml0IGtleXMsIEFFUy0xMjgtR0NNLA0KICAgYW5kIEFFUy0yNTYtR0NNLiAgU3VwcG9ydCBm
b3Igb3RoZXIgYWxnb3JpdGhtcyBhbmQga2V5IHNpemVzIGlzDQogICBPUFRJT05BTC4iDQoNClJl
Z2FyZHMNCg0KQW50b25pbw0KDQpbMF0gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNiNzZWN0aW9uLTgNCk9uIERlYyAyOSwgMjAxMiwg
YXQgNzowMSBQTSwgTmF0IFNha2ltdXJhIHdyb3RlOg0KDQoNCg0KPW5hdCB2aWEgaVBob25lDQoN
CkRlYyAyOSwgMjAxMiAxOTozNeOAgUFudG9uaW8gU2Fuc28gPGFzYW5zb0BhZG9iZS5jb208bWFp
bHRvOmFzYW5zb0BhZG9iZS5jb20+PiDjga7jg6Hjg4Pjgrvjg7zjgrg6DQoNCkhpIE5hdCwNCg0K
YXBvbG9naWVzIGlmIHRoaXMgc291bmRzIHRyaXZpYWwgYnV0IEkgYW0gdHJ5aW5nIHRvIHVuZGVy
c3RhbmQgdGhlIEpXKiBzdHVmZiBhbmQgdGhpcyBtYWlsIHRocmVhZCBpcyBoZWxwaW5nIG1lIHRv
IGNsYXJpZnkgc29tZSBvZiBteSBkb3VidHMuDQoNCg0KT24gRGVjIDIwLCAyMDEyLCBhdCA3OjEy
IEFNLCBOYXQgU2FraW11cmEgd3JvdGU6DQoNClRoYW5rcy4NCg0KSnVzdCBhIGZldyB0aGluZ3M6
DQoNCjEuIFNpZ24rRW5jcnlwdA0KDQpraW5kIG9mIG5pdHBpY2tpbmcgaGVyZSwgYnV0IHdvdWxk
IG5vdCBiZSBiZXR0ZXIgdG8gaW52ZXJ0IHRob3NlIHRlcm1zIGluIG9yZGVyIHRvIHNvdW5kIEVu
Y3J5cHQrU2lnbiAoYXMgbG9uZyBhcyBJIGtub3cgdGhlIG9yZGVyIG1hdHRlcnMgaGVyZSBhbmQg
dGhlIG9ubHkgc2FmZSB3YXkgaXMgZW5jcnlwdCB0aGFuICBNQUMpLg0KDQpOby4gWW91IHNob3Vs
ZCB1c2UgQUVBRCBhbGdvcml0aG1zIGZvciB0aGUgaW50ZWdyaXR5IHByb3RlY3Rpb24uDQoNClNp
Z25pbmcgc29tZXRoaW5nIHRoYXQgeW91IGNhbm5vdCBkZWNyeXB0IGFuZCB2ZXJpZnkgaXMgcHJl
dHR5IG1lYW5pbmdsZXNzICBpbiB0aGUgY29udHJhY3R1YWwgc2V0dGluZ3MuDQoNCg0KDQpTaWdu
K0VuY3J5cHQgaXMgdXNlZnVsIHdoZW4geW91IHdhbnQgdGhlIHNpZ25lZCBKV1QgYXMgYSBwcm9v
ZiBvZiBjb25zZW50IHRvIHNpZ24uDQpJdCBjYW4gYWxzbyBleGlzdCBhZnRlciBiZWluZyBkZWNy
eXB0ZWQuDQpJZiB5b3UganVzdCB3YW50IGludGVncml0eSBwcm90ZWN0aW9uLCB1c2UgSldFLg0K
DQpGb3IgaW50ZWdyaXR5IHNob3VsZCBub3QgYmUgZW5vdWdoIHRoZSBzaWduYXR1cmUgc28gSldT
Pw0KDQpBbGwgSldFIGFsZ29yaXRobXMgYXJlIEFFQUQgc28gSldTIHNpZ25pbmcgb3ZlciBKV0Ug
aXMgcmVkdW5kYW50Lg0KDQoNClRoYW5rcyBhIGxvdCBhbmQgcmVnYXJkcw0KDQpBbnRvbmlvDQoN
Cg0KMi4gQWxwaGFiZXRpemF0aW9uIG9mIHRoZSB0ZXJtaW5vbG9neQ0KDQpUaGF0J3Mgb25lIHdh
eSBvZiBvcmdhbml6aW5nIGl0Lg0KQW5vdGhlciB3YXkgb2Ygb3JnYW5pemluZyBpdCBpcyB0byBs
YXkgdGhlbSBvdXQgaW4gYSBzZW1hbnRpYyBvcmRlciwNCndoZXJlIHRoZSBwcmVjZWRpbmcgZGVm
aW5pdGlvbiBjYW5ub3QgdXNlIHRoZSB0ZXJtcyBkZWZpbmVkIGxhdGVyLg0KSXQgaXMgYSBnb29k
IHdheSB0byBtYWtlIHN1cmUgdGhlIGNvbnNpc3RlbmN5LCBhbmQgSSBwcm9iYWJseSBsaWtlIHRo
aXMgd2F5IGJldHRlci4NCg0KT2YgdGhlIGRlZmluaXRpb24gdGhlbXNlbHZlcywgSSBhZ3JlZSBp
dCBzdGlsbCBsYWNrcyBidW5jaCBvZiB0ZXJtcyB0aGF0IG5lZWRzIHRvIGJlIGRlZmluZWQsDQph
bmQgbmVlZHMgdGlnaHRlbmluZyB1cC4NCg0KQmVzdCwNCg0KTmF0DQoNCg0KT24gVGh1LCBEZWMg
MjAsIDIwMTIgYXQgOToxNCBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu
Y29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KVGhhbmtz
IGEgYnVuY2ggZm9yIHRoZSB1c2VmdWwgcmV2aWV3LCBKZWZmISAgUmVzcG9uc2VzIGFyZSBpbmxp
bmUgaW4gZ3JlZW4uDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm9hdXRoLWJv
dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86b2F1
dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiA9SmVmZkgNClNlbnQ6IFR1ZXNkYXks
IE5vdmVtYmVyIDI3LCAyMDEyIDI6MjMgUE0NClRvOiBJRVRGIG9hdXRoIFdHDQpTdWJqZWN0OiBb
T0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNQ0KDQoN
Cg0KSGksIGF0IGlldGYtODUgYXRsYW50YSBJIGFncmVlZCB0byBkbyBhIHJldmlldyBvZiBkcmFm
dC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1LCBhbmQgc28gSSBoYXZlIHNvbWUgdGhvdWdo
dHMgYmVsb3cuIEFsc28sICsxIHRvIEhhbm5lcycgY29tbWVudHMuDQoNCg0KDQpPdmVyYWxsIHRo
ZSBzcGVjIHNlZW1zIHRvIGdldCBpdHMgaWRlYSBhY3Jvc3MsIGJ1dCBpcyBwcmV0dHkgcm91Z2gu
IFBhcnQgb2YgdGhpcyBpcyBkdWUgdG8gdGhlIGxhbmd1YWdlIGJlaW5nIGNvbnZvbHV0ZWQsIHBs
dXMgc29tZSBjb25jZXB0cyBhcmUgb25seSB0YWNpdGx5IGRlc2NyaWJlZCAod2l0aCBjbHVlcyBz
Y2F0dGVyZWQgdGhyb3VnaG91dCB0aGUgc3BlYyksIGFuZCB0aHVzIGl0IGlzIGRpZmZpY3VsdCB0
byB1bmRlcnN0YW5kIHdpdGhvdXQgbXVsdGlwbGUgcGFzc2VzIG9mIHRoaXMgc3BlYyBhcyB3ZWxs
IGFzIFtKV0VdIGFuZCBbSldTXS4NCg0KDQoNCkZvciBleGFtcGxlLCBhIEpXVCBhcHBlYXJzIHRv
IGJlIHNpbXBseSBlaXRoZXIgYSBKV1Mgb3IgYSBKV0UgY29udGFpbmluZyBhIEpXVCBDbGFpbXMg
U2V0LCBidXQgdGhpcyBpcyBub3Qgc3RhdGVkIHVudGlsIHJpZ2h0IGJlZm9yZSBzZWN0aW9uIDMu
MSAoYW5kIGl0IGlzbid0IHN0YXRlZCB0aGF0IGNsZWFybHkpLg0KDQoNCg0KT0ssIEnigJlsbCBz
YXkgdGhhdCBlYXJsaWVyIGFuZCBtb3JlIGNsZWFybHkuDQoNCg0KDQpJbW1lZGlhdGVseSBiZWxv
dyBhcmUgc29tZSBvdmVyYWxsIGNvbW1lbnRzLCBhbmQgdGhlbiBiZWxvdyB0aGF0IHNvbWUgZGV0
YWlsZWQgY29tbWVudHMgb24gdmFyaW91cyBwb3J0aW9ucyBvZiB0aGUgc3BlYy4gIEknbSBub3Qg
YWRkcmVzc2luZyBldmVyeXRoaW5nIEkgbm90aWNlZCBkdWUgdG8gdGltZSBjb25zdHJhaW50cyAo
YXBvbG9naWVzKS4NCg0KDQoNCkhUSA0KDQoNCg0KPUplZmZIDQoNCi0tLS0tLQ0KDQoNCg0KDQoN
CkpXVCB0ZXJtaW5vbG9neToNCg0KDQoNClNvbWUgaXNzdWVzIHNlZW0gdG8gbWUgdG8gYmUgY2F1
c2VkIGJ5IGRlZmluaW5nIHRoZSBKV1QgdG8gYmUgdGhlIGJhc2U2NHVybCBlbmNvZGVkIEpTT04g
IG9iamVjdCBpdHNlbGYgYW5kIG5vdCBoYXZpbmcgdGVybWlub2xvZ3kgdG8gY2xlYXJseSByZWZl
ciB0byBpdHMgdW5lbmNvZGVkIGZvcm0uDQoNCg0KDQpGb3IgZXhhbXBsZSwgdGhlc2UgdHdvIEpT
T04gb2JqZWN0cyB0b2dldGhlciBhcHBhcmVudGx5IGNvbXByaXNlIGEgKHVuZW5jb2RlZCkgSldU
Li4NCg0KDQoNCiAgICAgIHsidHlwIjoiSldUIiwNCg0KICAgICAgICJhbGciOiJIUzI1NiJ9DQoN
Cg0KDQpUaGlzIGlzIHRoZSBKV1QgSGVhZGVyLiAgVGhlIGJhc2U2NHVybCBlbmNvZGVkIHZlcnNp
b24gaXMgdGhlIEVuY29kZWQgSldUIEhlYWRlci4NCg0KDQoNCiAgICAgIHsiaXNzIjoiam9lIiwN
Cg0KICAgICAgICJleHAiOjEzMDA4MTkzODAsDQoNCiAgICAgICAiaHR0cDovL2V4YW1wbGUuY29t
L2lzX3Jvb3QiOnRydWV9DQoNCg0KDQpUaGlzIGlzIHRoZSBKV1QgQ2xhaW1zIFNldC4NCg0KDQoN
Ci4uYnV0IHRoZXJlJ3Mgbm8gZGVmaW5lZCB3YXkgdG8gcmVmZXIgdG8gdGhlbSBnaXZlbiB0aGUg
c3BlYydzIHRlcm1pbmxvZ3kuDQoNCg0KDQpUaGUgdGVybXMgYWJvdmUgYXJlIGFscmVhZHkgZGVm
aW5lZCBpbiB0aGUgc3BlYy4NCg0KDQoNCkNvbnNpZGVyIHRlcm1pbmcgdGhlIGFib3ZlIGEgSldU
IGFuZCBpdHMgZW5jb2RlZC1zdHJpbmcgZm9ybSBhbiBFbmNvZGVkIEpXVCwgYW5kIGRlZmluZSB0
aGVtIHNlcGFyYXRlbHkuIEFuZCB0aGVuIHRoZXJlJ2xsIGJlIHNpbWlsYXIgZGVmaW5pdGlvbnMg
Zm9yIEpXVCBIZWFkZXIgYW5kIEpXVCBDbGFpbXMgU2V0LCBlLmcuLA0KDQoNCg0KSSBkaXNhZ3Jl
ZSB3aXRoIHJlZGVmaW5pbmcgdGhlIHRlcm0g4oCcSldU4oCdIHRvIG5vdCBhbHNvIGluY2x1ZGUg
dGhlIHNpZ25hdHVyZS4gIFRoZSB0ZXJtIOKAnEpXVOKAnSBzaG91bGQgY29udGludWUgdG8gcmVm
ZXIgdG8gdGhlIHdob2xlIHRoaW5nLg0KDQoNCg0KICAgIEVuY29kZWQgSldUICAgQSBKV1QgdGhh
dCBoYXMgYmVlbiBlbmNvZGVkIGFjY29yZGluZyB0byB0aGUNCg0KICAgICAgIHByb2Nlc3MgZGVm
aW5lZCBpbiBTZWN0aW9uIFguDQoNCg0KDQogICAgRW5jb2RlZCBKV1QgSGVhZGVyICAgVGhlIGVu
Y29kZWQtc3RyaW5nIGZvcm0gb2YgYSBKV1QgSGVhZGVyDQoNCg0KDQogICAgRW5jb2RlZCBKV1Qg
Q2xhaW1zIFNldCAgIFRoZSBlbmNvZGVkLXN0cmluZyBmb3JtIG9mIGEgSldUIENsYWltcyBTZXQN
Cg0KDQoNCknigJlsbCBub3RlIHRoYXQgd2hlbiB0aGUgSldUIGlzIGVuY3J5cHRlZCwgYSBiYXNl
NjR1cmwgZW5jb2RlZCByZXByZXNlbnRhdGlvbiBvZiB0aGUgSldUIENsYWltcyBTZXQgaXMgbmV2
ZXIgdXNlZC4gIChUaGUgZW5jcnlwdGVkIGZvcm0gb2YgdGhlbSBpcyBiYXNlNjR1cmwgZW5jb2Rl
ZCBpbnN0ZWFkLikNCg0KDQoNCiAgICBlbmNvZGVkLXN0cmluZyBmb3JtICAgVGhlIHJlc3VsdCBv
ZiBhcHBseWluZyBCYXNlNjR1cmwgZW5jb2RpbmcgdG8gYW4NCg0KICAgICAgIGlucHV0IEpTT04g
dGV4dCAuDQoNCg0KDQpTb21ldGltZXMgaGUgaW5wdXQgdG8gdGhlIGJhc2U2NHVybCBlbmNvZGlu
ZyBpcyBub3QgSlNPTiDigJMgZm9yIGluc3RhbmNlIHNpZ25hdHVyZSB2YWx1ZXMgb3IgZW5jcnlw
dGVkIHBheWxvYWRzLg0KDQoNCg0KICAgIEpTT04gV2ViIFRva2VuIChKV1QpICBBIEpXVCBjb21w
cmlzZXMgYSBKV1QgSGVhZGVyIGFuZCBhIEpXVCBDbGFpbXMgU2V0LiAuLi4NCg0KDQoNCiAgICBK
V1QgSGVhZGVyICBBIEpTT04gb2JqZWN0IHRoYXQgaXMgYSBjb21wb25lbnQgb2YgYSBKV1QuIEl0
IGRlbm90ZXMgdGhlDQoNCiAgICAgICBjcnlwdG9ncmFwaGljIG9wZXJhdGlvbnMgYXBwbGllZCB0
byB0aGUgSldULiAgLi4uDQoNCg0KDQogICAgSldUIENsYWltcyBTZXQgIEEgSlNPTiBvYmplY3Qg
Y29udGFpbmluZyBhIHNldCBvZiBjbGFpbXMuICAuLi4NCg0KDQoNClRoaXMgYWxzbyBnZXRzIHJp
ZCBvZiB0aGUgdXNlIG9mIHRoZSAiQSBzdHJpbmcgcmVwcmVzZW50aW5nIGEgSlNPTiBvYmplY3Qu
Li4iDQoNCndoaWNoIEkgZmluZCBjb25mdXNpbmcgYW5kIHBvdGVudGlhbGx5IG1pc2xlYWRpbmcg
KGJlY2F1c2UgaXQgaXMgYWN0dWFsbHkgImEgQmFzZTY0dXJsIGVuY29kaW5nIG9mIGEgSlNPTiBv
YmplY3QiKS4NCg0KDQoNCkFhaCDigJMgSSBub3cgc2VlIHRoYXQgdGhpcyBpcyB0aGUgcmVhbCBt
aXN1bmRlcnN0YW5kaW5nLiAgVGhlIOKAnHN0cmluZyByZXByZXNlbnRpbmcgYSBKU09OIG9iamVj
dOKAnSBpcyBub3QgdGhlIGJhc2U2NHVybCBlbmNvZGVkIGZvcm0g4oCTIGl04oCZcyB0aGUgc3Ry
aW5nIHJlcHJlc2VudGF0aW9uIHRoYXTigJlzIHBhcnNlYWJsZSBpbnRvIGEgSlNPTiBvYmplY3Qu
ICBGb3IgaW5zdGFuY2UsIGl0IGNvdWxkIGJlIGEgc3RyaW5nIHN1Y2ggYXMge+KAnGFsZ+KAnTri
gJ1SUzI1NuKAnX0g4oCTIG5vdCB0aGUgYmFzZTY0dXJsIGVuY29kZWQgdmVyc2lvbiBvZiB0aGF0
IHN0cmluZy4gIFRoZSByZWFzb24gZm9yIHRoZSBzeW50YWN0aWMgY29uc3RydWN0aW9uIOKAnHN0
cmluZyByZXByZXNlbnRpbmcgYSBKU09OIG9iamVjdOKAnSBpcyB0aGF0IGl0cyBzdHJpbmcgcmVw
cmVzZW50YXRpb24gaXMgZGlzdGluY3QgZnJvbSB0aGUgYWJzdHJhY3QgSlNPTiBvYmplY3QgaXRz
ZWxmLiAgSWYgSSBpbnNlcnQgd2hpdGVzcGFjZSBhZnRlciB0aGUgY29sb24gaW4gdGhlIHN0cmlu
ZyB74oCcYWxn4oCdOuKAnVJTMjU24oCdfSBpdCB3b3VsZCBwYXJzZSB0byBhbiBlcXVpdmFsZW50
IEpTT04gb2JqZWN0IGJ1dCBpdCB3b3VsZCBiZSBhIGRpZmZlcmVudCBzdHJpbmcgcmVwcmVzZW50
YXRpb24uICBJdOKAmXMgdGhlIHN0cmluZyByZXByZXNlbnRhdGlvbiB0aGF0IGlzIGFjdHVhbGx5
IG9wZXJhdGVkIG9uIGJ5IHRoZSBKV1QvSldTL0pXRSBvcGVyYXRpb25zLg0KDQoNCg0KSeKAmWxs
IHRyeSB0byBtYWtlIHRoaXMgY2xlYXJlciBpbiB0aGUgc3BlYy4NCg0KDQoNClVURi04Og0KDQoN
Cg0KVVRGLTggaXMgbWVudGlvbmVkIGluIGxvdHMgb2YgcGxhY2VzLiBJdCBjb3VsZCBwcm9iYWJs
eSBiZSBzdGF0ZWQgb25jZSB1cCBuZWFyDQoNCnRoZSBiZWdpbm5pbmcgb2YgdGhlIHNwZWMgdGhh
dCBhbGwgdGhlIEpTT04gdGV4dCBpcyBVVEYtOCBlbmNvZGVkLCBhbmQgYWxsIHRoZQ0KDQpKU09O
IHN0cmluZ3MgYXJlIFVURi04IGVuY29kZWQuDQoNCg0KDQpJ4oCZbGwgc2VlIGlmIEkgY2FuIGZp
Z3VyZSBvdXQgaG93IHRvIGRvIHRoaXMgd2l0aG91dCBpbnRyb2R1Y2luZyBhbWJpZ3VpdHkuDQoN
Cg0KDQpTZW1hbnRpY3MsIHByb2ZpbGVzIGFuZCByZWxhdGlvbnNoaXAgdG8gU0FNTDoNCg0KDQoN
ClRoZSBzcGVjIGRvZXMgbm90IGRlZmluZSBhbnkgb3ZlcmFsbCBKV1Qgc2VtYW50aWNzIChpLmUu
LCB3aGF0IGFueSBnaXZlbiBKV1QNCg0KL21lYW5zLykuIFNlbWFudGljcyBhcmUgb25seSBkZWZp
bmVkIGluIGNvbnRleHQgb2YgZWFjaCBpbmRpdmlkdWFsIFJlc2VydmVkDQoNCkNsYWltIE5hbWUu
DQoNCg0KDQpUaHVzIGFueSBhcHBsaWNhdGlvbiBvZiBKV1RzIHdpbGwgbmVlZCB0byBwcm9maWxl
IHRoZSBKV1Qgc3BlYzogc3BlY2lmeWluZyB0aGUNCg0KY2xhaW0gc2V0KHMpIGNvbnRlbnRzLCBh
bmQgdGhlIG92ZXJhbGwgc2VtYW50aWNzIG9mIHRoZSByZXN1bHRhbnQgSldUKHMpLiAgVGhpcw0K
DQppcyBub3QgZXhwbGljaXRseSBleHBsYWluZWQgaW4gdGhlIEpXVCBzcGVjLg0KDQoNCg0KQ2Fu
IHlvdSBzdWdnZXN0IHNvbWUgbGFuZ3VhZ2UgeW914oCZZCBsaWtlIHRvIHNlZSBhZGRlZCBhYm91
dCB0aGlzPw0KDQoNCg0KSW4gdGVybXMgb2YgU0FNTCwgQXBwZW5kaXggQiBzaG91bGQgcmVmZXIg
dG8gU0FNTCBhc3NlcnRpb25zIHJhdGhlciB0aGFuIHNhbWwNCg0KdG9rZW5zLiBBbHNvLCBJJ20g
bm90IHN1cmUgU0FNTCBhc3NlcnRpb25zIGluaGVyZW50bHkgaGF2ZSBtb3JlIGV4cHJlc3Npdml0
eQ0KDQp0aGFuIEpXVHMuIFRoZXkgZG8gaGF2ZSBtb3JlIHByZS1kZWZpbmVkIHN0cnVjdHVyZSBh
bmQgc2VtYW50aWNzLg0KDQoNCg0KT0sNCg0KDQoNClN5bnRhY3RpY2FsbHksIGl0IHNlZW1zIG9u
ZSBjYW4gZW5jb2RlIHByZXR0eSBtdWNoIGFueXRoaW5nIGluIHdoYXRldmVyIGFtb3VudA0KDQpp
biBhIEpXVCAob25lIGNhbiBkbyB0aGUgc2FtZSB3aXRoIFNBTUwgYXNzZXJ0aW9ucyksIGFuZCB0
aHVzIHRoZW9yZXRpY2FsbHkgSldUcw0KDQpjb3VsZCBiZSB1c2VkIHRvIGFjY29tcGxpc2ggdGhl
IHNhbWUgdGhpbmdzIGFzIFNBTUwgYXNzZXJ0aW9ucy4NCg0KDQoNClNlbWFudGljYWxseSwgU0FN
TCBhc3NlcnRpb25zIGFyZSBleHBsaWNpdGx5IHN0YXRlbWVudHMgbWFkZSBieSBhIHN5c3RlbSBl
bnRpdHkNCg0KYWJvdXQgYSBzdWJqZWN0LiBCdXQgYnkgZGVmYXVsdCwgYSBKV1QgaXMgZW1wdHks
IGFuZCBoYXMgbm8gc2VtYW50aWNzICh0aGlzDQoNCmlzbid0IHN0YXRlZCBleHBsaWNpdGx5KS4g
QWxsIHNlbWFudGljcyBkZWZpbmVkIGluIHRoZSBKV1Qgc3BlYyBhcmUgcGFydGljdWxhcg0KDQp0
byBpbmRpdmlkdWFsIHJlc2VydmVkIGNsYWltcywgYnV0IGFsbCByZXNlcnZlZCBjbGFpbXMgYXJl
IG9wdGlvbmFsLiBUaHVzIGFuDQoNCmFwcGxpY2F0aW9uIG9mIEpXVHMgdG8gdXNlIGNhc2VzIGFs
c28gYXByb3BvcyBmb3IgU0FNTCBhc3NlcnRpb25zIHdpbGwgcmVxdWlyZQ0KDQphcmd1YWJseSBt
b3JlIHByb2ZpbGluZyB0aGFuIHRoYXQgbmVlZGVkIHRvIGFwcGx5IFNBTUwgYXNzZXJ0aW9ucy4N
Cg0KDQoNCkFsbCB0cnVlLiAgSG93ZXZlciBvbmNlIHlvdSBhZGQgYW4gaXNzdWVyIGFuZCBhIHBy
aW5jaXBhbCwgdGhlbiB5b3XigJlyZSBiYWNrIHRvIHRoZSBKV1QgYmVpbmcgc3RhdGVtZW50cyBt
YWRlIGJ5IGFuIGVudGl0eSBhYm91dCBhIHN1YmplY3QuICBBZ2FpbiwgaWYgdGhlcmUgaXMgbGFu
Z3VhZ2UgeW91IGJlbGlldmUgc2hvdWxkIGJlIGFkZGVkIGluIHRoYXQgcmVnYXJkLCBwbGVhc2Ug
bGV0IG1lIGtub3cuICAoQlRXLCBvbmUgc3VjaCB1c2FnZSBwcm9maWxlIGlzIGluIGh0dHA6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJlci0wMy4gIEFub3Ro
ZXIgaXMgaW4gaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtbWVzc2FnZXMt
MV8wLmh0bWwjaWRfdG9rZW4uKQ0KDQoNCg0KVGhlIHRva2VuIHNpemUgJiBjb21wbGV4aXR5IGNv
bXBhcmlzb24gc2VlbXMgbm9taW5hbGx5IGZpbmUuDQoNCg0KDQpTb21lIGRldGFpbGVkLWJ1dC1y
b3VnaCBjb21tZW50cyBhbmQgbXVzaW5ncyBvbiBwb3J0aW9ucyBvZiB0aGUgc3BlYyBhcyBJIHdh
cw0KDQpyZWFkaW5nIHRocm91Z2ggaXQuLi4NCg0KDQoNCj4gMi4gVGVybWlub2xvZ3kNCg0KDQoN
CnRlcm1pbm9sb2d5IGlzIG5vdCBhbHBoYWJldGlzZWQhDQoNCg0KDQpObywgaXTigJlzIGluIGEg
dG9wLWRvd24gZGVzY3JpcHRpdmUgb3JkZXIuICBJcyB0aGVyZSBhIHJlcXVpcmVtZW50IGluIElF
VEYgc3BlY3MgdGhhdCB0aGUgdGVybWlub2xvZ3kgYmUgYWxwaGFiZXRpemVkPw0KDQoNCg0KImNs
YWltIiwgImNsYWltcyIsICJ0b2tlbiIgc2hvdWxkIGJlIGRlZmluZWQgaW4gdGVybWlub2xvZ3kN
Cg0KDQoNCknigJlsbCBhZGQgYSBkZWZpbml0aW9uIGZvciDigJxjbGFpbeKAnS4gIOKAnHRva2Vu
4oCdIHNob3VsZCBhY3R1YWxseSBwcm9iYWJseSBiZWNvbWUg4oCcc2VjdXJpdHkgdG9rZW7igJ0s
IHdpdGggYSBkZWZpbml0aW9uIG9mIHRoZSB0ZXJtLg0KDQoNCg0Kc3VnZ2VzdGlvbjoNCg0KDQoN
CiAgICAgIENsYWltOiAgYW4gYXNzZXJ0aW9uIG9mIHNvbWV0aGluZyBhcyBhIGZhY3QuIEhlcmUs
IGNsYWltcyBhcmUNCg0KICAgICAgICAgbmFtZSBhbmQgdmFsdWUgcGFpcnMsIGNvbnNpc3Rpbmcg
b2YgYSBDbGFpbSBOYW1lIGFuZCBhDQoNCiAgICAgICAgIENsYWltIFZhbHVlLg0KDQoNCg0KDQoN
Cj4gICAgSlNPTiBXZWIgVG9rZW4gKEpXVCkNCg0KDQoNCiAgIGlzIGp3dCBhbHdheXMgYSAic3Ry
aW5nIiBvciBpcyBpdCBzdHJpbmcgKG9ubHkpIHdoZW4gaXQncyBiZWVuIHNlcmlhbGl6ZWQNCg0K
aW50byBvbmU/DQoNCg0KDQpJdOKAmXMgYWx3YXlzIHRoZSBzdHJpbmcgcmVwcmVzZW50YXRpb24g
b2YgdGhlIHNlcmlhbGl6ZWQgcGFydHMuDQoNCg0KDQo+ICAgICAgICAgICAgICAgICAgICBBIHN0
cmluZyByZXByZXNlbnRpbmcgYSBzZXQgb2YgY2xhaW1zIGFzIGEgSlNPTg0KDQo+ICAgICAgIG9i
amVjdCB0aGF0IGlzIGRpZ2l0YWxseSBzaWduZWQgb3IgTUFDZWQgYW5kL29yIGVuY3J5cHRlZC4N
Cg0KDQoNCiAgIGlzIGl0IG1vcmUgdGhhdCBpdCdzIGEgc2V0IG9mIGNsYWltcyBlbmNvZGVkIGFz
IGEgSlNPTiBvYmplY3QNCg0KICAgdGhhdCBpcyBzdHJpbmctc2VyaWFsaXplZD8NCg0KDQoNCk5v
LCBwZXIgbXkgZWFybGllciBjb21tZW50cw0KDQoNCg0KICAgaXMgaXQgL25vdC8gYSBKV1QgYnkg
ZGVmaW5pdGlvbiBpZiBpdCBpcyBub3QgKChzaWduZWQgb3IgdW5tYWMnZCkgYW5kL29yDQoNCmVu
Y3J5cHRlZCkgPyAgIE5vLCBiZWNhdXNlIHRoZXJlIGFyZSBQbGFpbnRleHQgSldUcywgYnV0IHRo
ZXkgYXJlbid0IGluDQoNCnRlcm1pbm9sb2d5IChwcm9iYWJseSBzaG91bGQgYmUpLg0KDQoNCg0K
R29vZCBjYXRjaA0KDQoNCg0KICAgInBhcnRzIiBpbiBKV1QgZGVmaW5pdGlvbiBpcyB1bmNsZWFy
DQoNCiAgICAgYXJlICJwYXJ0cyIganNvbiBvYmplY3RzIG9yIGFycmF5cyB1bnRvIHRoZW1zZWx2
ZXMgPw0KDQoNCg0KVGhlIHBhcnRzIGFyZSBhbGwgYmFzZTY0dXJsIGVuY29kZWQgdmFsdWVzLiAg
SeKAmWxsIHJldmlldyB0aGlzIHRlcm1pbm9sb2d5IHVzYWdlIHRvIHNlZSBpZiBpdCBjYW4gYmUg
Y2xhcmlmaWVkLg0KDQoNCg0KICAgdGhlIGRlZmluaXRpb24gYXNzdW1lcyBrbm93bGVkZ2UgdGhh
dCdzIHByZXNlbnRlZCBsYXRlci4gcGVyaGFwcyBuZWVkcyBmd2QNCg0KICAgcmVmZXJlbmNlKHMp
LCBvciBwZXJoYXBzIGJldHRlciBpcyB0byBub3QgcHJlc2VudCBhcyBtdWNoIHRlY2huaWNhbCBk
ZXRhaWwNCg0KICAgaW4gdGhlIGRlZmluaXRpb25zLg0KDQoNCg0KSeKAmWxsIHJldmlldw0KDQoN
Cg0KPiAgICBKV1QgQ2xhaW1zIFNldA0KDQoNCg0KICAgc2ltaWxhciBjb21tZW50cyBhcyB0byBK
U09OIFdlYiBUb2tlbiAoSldUKQ0KDQoNCg0KICAgdGhlIGRlZmluaXRpb24gc2F5cyBob3cgaXQg
aXMgZW5jb2RlZCBhbmQgZW5jcnlwdGVkLCBidXQgbm90IGhvdyBjbGFpbXMgYXJlDQoNCm1hcHBl
ZCBpbnRvIGEgSlNPTiBvYmplY3QNCg0KDQoNCg0KDQpzaG91bGQgcHJvYmFibHkgYmUgc2ltcGx5
Og0KDQoNCg0KICAgIEpXVCBDbGFpbXMgU2V0OiBBIHNldCBvZiBjbGFpbXMgZXhwcmVzc2VkIGFz
IGEgSlNPTiBvYmplY3QsIHdoZXJlIGVhY2gNCg0KICAgICAgIGNsYWltIGlzIGFuIG9iamVjdCBt
ZW1iZXIgKGkuZS4sIGEgbmFtZS92YWx1ZSBwYWlyKS4gQSBjbGFpbSBtYXkgaGF2ZQ0KDQogICAg
ICAgYSBKV1QgQ2xhaW1zIFNldCBhcyBhIHZhbHVlLg0KDQoNCg0KSeKAmWxsIGxvb2sgaW50byBt
b3ZpbmcgdGhlIGRlZmluaXRpb24gaW4gdGhpcyBkaXJlY3Rpb24uICBXaGF0IHlvdeKAmXJlIG1p
c3NpbmcgaW4gdGhlIGFib3ZlLCB0aG91Z2gsIGlzIHRoZSBkaXN0aW5jdGlvbiBiZXR3ZWVuIHRo
ZSBzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSBKU09OIG9iamVjdCBhbmQgdGhlIGFic3RyYWN0IEpT
T04gb2JqZWN0LiAgV2Ugd2FudCB0aGUgZm9ybWVyLg0KDQoNCg0KPiAgICBDbGFpbSBOYW1lICBU
aGUgbmFtZSBvZiBhIG1lbWJlciBvZiB0aGUgSlNPTiBvYmplY3QgcmVwcmVzZW50aW5nIGENCg0K
PiAgICAgICBKV1QgQ2xhaW1zIFNldC4NCg0KDQoNCnNob3VsZCBwcm9iYWJseSBiZSBzaW1wbHk6
DQoNCg0KDQogICAgQ2xhaW0gTmFtZSAgVGhlIG5hbWUgcG9ydGlvbiBvZiBhIGNsYWltLCBleHBy
ZXNzZWQgYXMgYSBKU09OIG9iamVjdCBtZW1iZXINCg0KICAgICAgIG5hbWUuDQoNCg0KDQoNCg0K
PiAgICBDbGFpbSBWYWx1ZSAgVGhlIHZhbHVlIG9mIGEgbWVtYmVyIG9mIHRoZSBKU09OIG9iamVj
dCByZXByZXNlbnRpbmcgYQ0KDQo+ICAgICAgIEpXVCBDbGFpbXMgU2V0Lg0KDQoNCg0Kc2hvdWxk
IHByb2JhYmx5IGJlIHNpbXBseToNCg0KDQoNCiAgICBDbGFpbSBWYWx1ZSAgVGhlIHZhbHVlIHBv
cnRpb24gb2YgYSBjbGFpbSwgZXhwcmVzc2VkIGFzIGEgSlNPTiBvYmplY3QgbWVtYmVyDQoNCiAg
ICAgICB2YWx1ZS4NCg0KDQoNCknigJlsbCBsb29rIGludG8gbW92aW5nIHRoZSBkZWZpbml0aW9u
cyBpbiB0aGlzIGRpcmVjdGlvbi4NCg0KDQoNCj4gMy4gSlNPTiBXZWIgVG9rZW4gKEpXVCkgT3Zl
cnZpZXcNCg0KDQoNCj4gICAgVGhlIGJ5dGVzIG9mIHRoZSBVVEYtOCByZXByZXNlbnRhdGlvbiBv
ZiB0aGUgSldUIENsYWltcyBTZXQgYXJlDQoNCj4gICAgZGlnaXRhbGx5IHNpZ25lZCBvciBNQUNl
ZCBpbiB0aGUgbWFubmVyIGRlc2NyaWJlZCBpbiBKU09OIFdlYg0KDQo+ICAgIFNpZ25hdHVyZSAo
SldTKSBbSldTXSBhbmQvb3IgZW5jcnlwdGVkIGluIHRoZSBtYW5uZXIgZGVzY3JpYmVkIGluDQoN
Cj4gICAgSlNPTiBXZWIgRW5jcnlwdGlvbiAoSldFKSBbSldFXS4NCg0KDQoNCnMvIGFuZC9vciBl
bmNyeXB0ZWQgLyBvciBlbmNyeXB0ZWQgYW5kIHNpZ25lZCAvDQoNCg0KDQpJIHRoaW5rIHlvdSBt
ZWFuIOKAnGVuY3J5cHRlZCBhbmQgaW50ZWdyaXR5IHByb3RlY3RlZOKAnSByYXRoZXIgdGhhbiDi
gJxlbmNyeXB0ZWQgYW5kIHNpZ25lZOKAnSwgcmlnaHQ/DQoNCg0KDQo+ICAgIFRoZSBjb250ZW50
cyBvZiB0aGUgSldUIEhlYWRlciBkZXNjcmliZSB0aGUgY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb25z
DQoNCj4gICAgYXBwbGllZCB0byB0aGUgSldUIENsYWltcyBTZXQuIElmIHRoZSBKV1QgSGVhZGVy
IGlzIGEgSldTIEhlYWRlciwgdGhlDQoNCj4gICAgY2xhaW1zIGFyZSBkaWdpdGFsbHkgc2lnbmVk
IG9yIE1BQ2VkLiAgSWYgdGhlIEpXVCBIZWFkZXIgaXMgYSBKV0UNCg0KPiAgICBIZWFkZXIsIHRo
ZSBjbGFpbXMgYXJlIGVuY3J5cHRlZC4NCg0KDQoNCldoYXQgaWYgYSBKV1QgaXMgc2lnbmVkIEFO
RCBlbmNyeXB0ZWQ/ICBIbSwgZnJvbSBteSBsb29raW5nIGF0IEpXUyBhbmQgSldFDQoNCnNwZWNz
LCBpdCBzZWVtcyB0aGF0IGluIHRoYXQgY2FzZSBvbmUgdXNlcyBKV0UgYmVjYXVzZSB0aGF0IGVu
Y29tcGFzc2VzIGJvdGgNCg0KZW5jcnlwdCAmIHNpZ24uDQoNCg0KDQpObywgYWN0dWFsbHkgSldF
IGp1c3QgcHJvdmlkZXMgYW4gaW50ZWdyaXR5IGNoZWNrIOKAkyBub3QgYSBzaWduYXR1cmUuICBJ
ZiB5b3Ugd2FudCBhIHNpZ25hdHVyZSwgeW91IG5lZWQgdG8gdXNlIEpXUy4gIFRoZXkgY2FuIChh
bmQgb2Z0ZW4gYXJlKSB1c2VkIGluIGEgbmVzdGVkIGZhc2hpb24uDQoNCg0KDQo+ICAgIEEgSldU
IGlzIHJlcHJlc2VudGVkIGFzIGEgSldTIG9yIEpXRS4gIFRoZSBudW1iZXIgb2YgcGFydHMgaXMN
Cg0KPiAgICBkZXBlbmRlbnQgdXBvbiB0aGUgcmVwcmVzZW50YXRpb24gb2YgdGhlIHJlc3VsdGlu
ZyBKV1Mgb3IgSldFLg0KDQoNCg0KRG9lcyB0aGUgYWJvdmUgbWVhbiB0byBzYXkuLg0KDQoNCg0K
ICAgIEEgSldUIGNvbnNpc3RzIG9mIGEgSldTIG9yIEpXRSBvYmplY3QsIHdoaWNoIGluIHR1cm4g
Y29udmV5cyB0aGUgSldUDQoNCiAgICBDbGFpbXMgU2V0LiBJbiB0aGUgY2FzZSBvZiBhIEpXUywg
dGhlIEpXVCBDbGFpbXMgU2V0IGlzIHRoZSBKV1MNCg0KICAgIFBheWxvYWQuIEluIHRoZSBjYXNl
IG9mIGEgSldFLCB0aGUgSldUIENsYWltcyBTZXQgaXMgdGhlIGlucHV0DQoNCiAgICBQbGFpbnRl
eHQuDQoNCg0KDQpZZXMuICBBbHRob3VnaCB0aGlzIGlzIG1pc3NpbmcgdGhlIGZhY3QgdGhhdCBu
ZXN0ZWQgc2lnbmluZy9lbmNyeXB0aW9uIG1heSBiZSBlbXBsb3llZC4NCg0KDQoNCj4gNC4gSldU
IENsYWltcw0KDQo+DQoNCj4NCg0KPiAgICBUaGUgSldUIENsYWltcyBTZXQgcmVwcmVzZW50cyBh
IEpTT04gb2JqZWN0IHdob3NlIG1lbWJlcnMgYXJlIHRoZQ0KDQo+ICAgIGNsYWltcyBjb252ZXll
ZCBieSB0aGUgSldULiAgVGhlIENsYWltIE5hbWVzIHdpdGhpbiB0aGlzIG9iamVjdCBNVVNUDQoN
Cj4gICAgYmUgdW5pcXVlOyBKV1RzIHdpdGggZHVwbGljYXRlIENsYWltIE5hbWVzIE1VU1QgYmUg
cmVqZWN0ZWQuDQoNCg0KDQpkb2VzIHRoZSBhYm92ZSBtZWFuIHRvIHNheSBjbGFpbSBuYW1lcyBt
dXN0IGJlIHVuaXF1ZSBhbW9uZ3N0IHRoZSBzZXQgb2YgY2xhaW0NCg0KbmFtZXMgd2l0aGluIGFu
eSBnaXZlbiBKV1QgQ2xhaW1zIFNldCA/ICBJZiBzbywgdGhhdCdzIG9ubHkgaW1wbGllZCBieSB0
aGUgYWJvdmUNCg0KYnV0IHNob3VsZCBiZSBzdGF0ZWQgZXhwbGljaXRseTsgYXMgaXQgaXMsIHRo
ZSBhYm92ZSBpcyBhbWJpZ3VvdXMuDQoNCg0KDQpPSw0KDQoNCg0KPiA0LjIuIFB1YmxpYyBDbGFp
bSBOYW1lcw0KDQo+DQoNCj4NCg0KPiAgICBDbGFpbSBuYW1lcyBjYW4gYmUgZGVmaW5lZCBhdCB3
aWxsIGJ5IHRob3NlIHVzaW5nIEpXVHMuICBIb3dldmVyLCBpbg0KDQoNCg0Kcy9DbGFpbSBuYW1l
cy9QdWJsaWMgY2xhaW0gbmFtZXMvDQoNCg0KDQo+ICAgIG9yZGVyIHRvIHByZXZlbnQgY29sbGlz
aW9ucywgYW55IG5ldyBjbGFpbSBuYW1lIFNIT1VMRCBlaXRoZXIgYmUNCg0KPiAgICByZWdpc3Rl
cmVkIGluIHRoZSBJQU5BIEpTT04gV2ViIFRva2VuIENsYWltcyByZWdpc3RyeSBTZWN0aW9uIDku
MSBvcg0KDQo+ICAgIGJlIGEgVVJJIHRoYXQgY29udGFpbnMgYSBDb2xsaXNpb24gUmVzaXN0YW50
IE5hbWVzcGFjZS4NCg0KDQoNCg0KDQp3aHkgc2hvdWxkIGEgY2xhaW0gbmFtZSBiZSBhIFVSSSBp
ZiBJIHdpc2ggdG8gbWFrZSB1c2Ugb2YgQ29sbGlzaW9uIFJlc2lzdGFudA0KDQpOYW1lc3BhY2Vz
PyAgRm9yIGV4YW1wbGUsIGlmIEkgc2ltcGx5IHVzZSBzYXkgVVVJRHMgYXMgY2xhaW0gbmFtZXMu
Lg0KDQoNCg0KICAgICAgeyJpc3MiOiJqb2UiLA0KDQogICAgICAgIjMwMDVmYTA1LWU3NmMtNDk5
NC1iYmM5LTY1YjJhY2UyMzA1YyI6ImZvbyJ9DQoNCg0KDQouLml0IHdpbGwgYmUgdW5pdmVyc2Fs
bHkgdW5pcXVlIHByb3ZpZGVkIEkgbWludGVkIGl0IGFwcHJvcHJpYXRlbHkgKG5vIFVSSQ0KDQpz
eW50YXggaXMgbmVlZGVkKS4NCg0KDQoNCkZhaXIgZW5vdWdoLiAgSeKAmWxsIHRyeSB0byBnZW5l
cmFsaXplIHRoZSBsYW5ndWFnZS4NCg0KDQoNCj4gNC4zLiBQcml2YXRlIENsYWltIE5hbWVzDQoN
Cj4NCg0KPg0KDQo+ICAgIEEgcHJvZHVjZXIgYW5kIGNvbnN1bWVyIG9mIGEgSldUIG1heSBhZ3Jl
ZSB0byBhbnkgY2xhaW0gbmFtZSB0aGF0IGlzDQoNCj4gICAgbm90IGEgUmVzZXJ2ZWQgTmFtZSBT
ZWN0aW9uIDQuMSBvciBhIFB1YmxpYyBOYW1lIFNlY3Rpb24gNC4yLiAgVW5saWtlDQoNCj4gICAg
UHVibGljIE5hbWVzLCB0aGVzZSBwcml2YXRlIG5hbWVzIGFyZSBzdWJqZWN0IHRvIGNvbGxpc2lv
biBhbmQgc2hvdWxkDQoNCj4gICAgYmUgdXNlZCB3aXRoIGNhdXRpb24uDQoNCg0KDQppdCBzZWVt
cyBwcml2YXRlIGNsYWltIG5hbWVzIGFyZSBvbmx5IHN1YmplY3QgdG8gY29sbGlzaW9uIGlmIHRo
ZSBpbXBsZW1lbnRlcnMNCg0KZG9uJ3QgbWFrZSBhcHByb3ByaWF0ZSB1c2Ugb2YgQ29sbGlzaW9u
IFJlc2lzdGFudCBOYW1lc3BhY2VzLCBpLmUuIHRoZXkgImNhbiBiZSINCg0Kc3ViamVjdCB0byBj
b2xsaXNpb24uDQoNCg0KDQpUcnVlDQoNCg0KDQp0aGUgYWJvdmUgdHdvIHNlY3Rpb25zIHVzZSAi
cHVibGljIiBhbmQgInByaXZhdGUiIGFzIGRpc3Rpbmd1aXNoaW5nIGZhY3RvcnMsIGJ1dA0KDQpp
dCBzZWVtcyB0byBtZSB0aGUgZGlzdGluZ3Vpc2hpbmcgZmFjdG9yIChnaXZlbiBob3cgdGhlIGFi
b3ZlIGlzIHdyaXR0ZW4pIGlzDQoNCm1vcmUgd2hldGhlciBDb2xsaXNpb24gUmVzaXN0YW50IE5h
bWVzcGFjZXMgYXJlIGVtcGxveWVkIG9yIG5vdC4NCg0KDQoNClllcywgYWx0aG91Z2ggdXNpbmcg
YSBjb2xsaXNpb24gcmVzaXN0YW50IG5hbWVzcGFjZSBlZmZlY3RpdmVseSBtYWtlcyB0aGVtIHB1
YmxpYywgYXMgd2XigJlyZSB1c2luZyB0aGUgdGVybQ0KDQoNCg0KQW4gaW1wbGllZCBhc3BlY3Qg
b2YgcHVibGljIGNsYWltIG5hbWVzIHNlZW1zIHRvIGJlIHRoYXQgaXQgaXMgYXNzdW1lZCB0aGF0
IHRoZXkNCg0KYXJlIHB1YmxpY2x5IGxpc3RlZC9kb2N1bWVudGVkL2xlYWtlZCwgdGh1cyB0aGUg
InB1YmxpYyIgbW9uaWtlciwgYW5kIGhlbmNlDQoNCm91Z2h0IHRvIGJlIHVuaXZlcnNhbGx5IHVu
aXF1ZSBhcyBhIG1hdHRlciBvZiBjb3Vyc2UuDQoNCg0KDQphbmQgInByaXZhdGUiIG9uZXMgc2Vl
bSB0byBiZSBhc3N1bWVkIHRvIGJlIG9iZnVzY2F0ZWQgdG8gYWxsIGJ1dCB0aGUgYWdyZWVpbmcN
Cg0KcGFydGllcz8gIE9yIHRoZXkgYXJlICJwcml2YXRlIiBpbiBvbmx5IHRoZSBzZW5zZSB0aGF0
IHRoZXkgYXJlIGNyZWF0ZWQgaW4gdGhlDQoNCmNvbnRleHQgb2YgYSBwcml2YXRlIGFycmFuZ2Vt
ZW50Pw0KDQoNCg0KUHJpdmF0ZSBpbiB0aGF0IHRoZXkgYXJlIGNyZWF0ZWQgaW4gdGhlIGNvbnRl
eHQgb2YgYSBwcml2YXRlIGFycmFuZ2VtZW50LiAgSeKAmWxsIHRyeSB0byBjbGFyaWZ5IHRoaXMg
cG9pbnQuICBGYWNlYm9vayBjb3VsZCBkZWZpbmUgaG93IHRoZXnigJlyZSBnb2luZyB0byB1c2Ug
dGhlIOKAnGlk4oCdIGNsYWltIHZlcnkgcHVibGljbHksIGFuZCB5ZXQgaXQgd291bGQgc3RpbGwg
YmUgYSBwcml2YXRlIGNsYWltIGlmIG5vdCByZWdpc3RlcmVkIHdpdGggSUFOQS4NCg0KDQoNCj4N
Cg0KPiA3LiBSdWxlcyBmb3IgQ3JlYXRpbmcgYW5kIFZhbGlkYXRpbmcgYSBKV1QNCg0KPg0KDQo+
DQoNCj4gICAgVG8gY3JlYXRlIGEgSldULCBvbmUgTVVTVCBwZXJmb3JtIHRoZXNlIHN0ZXBzLiAg
VGhlIG9yZGVyIG9mIHRoZQ0KDQo+ICAgIHN0ZXBzIGlzIG5vdCBzaWduaWZpY2FudCBpbiBjYXNl
cyB3aGVyZSB0aGVyZSBhcmUgbm8gZGVwZW5kZW5jaWVzDQoNCj4gICAgYmV0d2VlbiB0aGUgaW5w
dXRzIGFuZCBvdXRwdXRzIG9mIHRoZSBzdGVwcy4NCg0KPg0KDQo+ICAgIDEuICBDcmVhdGUgYSBK
V1QgQ2xhaW1zIFNldCBjb250YWluaW5nIHRoZSBkZXNpcmVkIGNsYWltcy4gIE5vdGUgdGhhdA0K
DQo+ICAgICAgICB3aGl0ZSBzcGFjZSBpcyBleHBsaWNpdGx5IGFsbG93ZWQgaW4gdGhlIHJlcHJl
c2VudGF0aW9uIGFuZCBubw0KDQo+ICAgICAgICBjYW5vbmljYWxpemF0aW9uIGlzIHBlcmZvcm1l
ZCBiZWZvcmUgZW5jb2RpbmcuDQoNCg0KDQpJIHByZXN1bWUgdGhlIHJhdGlvbmFsZSBmb3IgYWxs
b3dpbmcgd2hpdGUgc3BhY2UgaXMgdGhhdCBKU09OIG9iamVjdHMgYXJlDQoNCnVub3JkZXJlZCAo
YW5kIGNhbiBjb250YWluIGFyYml0cmFyeSB3aGl0ZXNwYWNlKSwgdGh1cyBzaW1wbGUgYnVmZmVy
LXRvLWJ1ZmZlcg0KDQpjb21wYXJpc29ucyBiZXR3ZWVuIHNlcmlhbGl6ZWQgb2JqZWN0cyBjYW5u
b3QgYmUgcmVsaWFibHkgcGVyZm9ybWVkLiAgSWYgc28gdGhpcw0KDQpzaG91bGQgYmUgZXhwbGlj
aXRseSBzdGF0ZWQuDQoNCg0KDQpBY3R1YWxseSwgaXTigJlzIHRvIGF2b2lkIGNhbm9uaWNhbGl6
YXRpb24uICBJ4oCZbGwgcmVyZWFkIHRoZSBzcGVjIHRvIHNlZSBpZiB3ZeKAmXZlIHN0YXRlZCB0
aGF0IGNsZWFybHkgb3Igbm90Lg0KDQoNCg0KSXQgc2VlbXMgdGhhdCBtZW1iZXIvdmFsdWUtYnkt
bWVtYmVyL3ZhbHVlIGNvbXBhcmlzb25zIG11c3QgYWx3YXlzIGJlIGRvbmUsIGJ5DQoNCnBhcnNp
bmcgdGhlIEpTT04gb2JqZWN0cyBhbmQgZXh0cmFjdGluZyBhbGwgbWVtYmVycyBhbmQgdmFsdWVz
LCB0aGlzIHNob3VsZCBiZQ0KDQpzdGF0ZWQgZXhwbGljaXRseSBpbiB0aGUgc3BlYy4NCg0KDQoN
CkkgZm91bmQgbWVhZ2VyIGp3dCBjb21wYXJpc29uIGluc3RydWN0aW9ucyBhdCB0aGUgdmVyeSBl
bmQgb2YgU2VjdGlvbiA3LiBpdA0KDQpzaG91bGQgcHJvYmFibHkgYmUgaXRzIG93biBzdWJzZWN0
aW9uLiBJdCBzaG91bGQgcHJvYmFibHkgZXhwbGljaXRseSBzYXkgdGhhdA0KDQpKV1RzIG5lZWQg
dG8gYmUgcGFyc2VkIGludG8gdGhlaXIgY29uc3RpdHVlbnQgY29tcG9uZW50cywgYW5kIHRoZSBs
YXR0ZXIgbXVzdCBiZQ0KDQppbmRpdmlkdWFsbHkgZXhhbWluZWQvY29tcGFyZWQuDQoNCg0KDQpX
ZSB0cmllZCB0byBjb3ZlciB0aGlzIGluIHRoZSBlbmQgb2Ygc2VjdGlvbiA3LCBzdGFydGluZyB3
aXRoIHRoZSBzZW50ZW5jZSDigJxQcm9jZXNzaW5nIGEgSldUIGluZXZpdGFibHkgcmVxdWlyZXMg
Y29tcGFyaW5nIGtub3duIHN0cmluZ3MgdG8gdmFsdWVzIGluIHRoZSB0b2tlbuKAnSwgd2hpY2gg
c2F5cyBob3cgdGhlc2UgY29tcGFyaXNvbnMgbXVzdCBiZSBwZXJmb3JtZWQuICBJIGFncmVlIHRo
YXQgdGhpcyBzaG91bGQgYmVjb21lIGl0cyBvd24gc3Vic2VjdGlvbi4gIEkgZG9u4oCZdCB1bmRl
cnN0YW5kIHlvdXIgcmVtYXJrIGFib3V0IGNvbnN0aXR1ZW50IGNvbXBvbmVudHMuICBDYW4geW91
IGNsYXJpZnk/DQoNCg0KDQo+ICAgIENvbXBhcmlzb25zIGJldHdlZW4gSlNPTiBzdHJpbmdzIGFu
ZCBvdGhlciBVbmljb2RlIHN0cmluZ3MgTVVTVCBiZQ0KDQo+ICAgIHBlcmZvcm1lZCBhcyBzcGVj
aWZpZWQgYmVsb3c6DQoNCg0KDQp0aGlzIGNvbXBhcmlzb24gYWxnb3JpdGhtIHNlZW1zIHRvIGJl
IGF0dGVtcHRpbmcgdG8gYWxsb3cgZm9yIGNvbXBhcmlzb24gb2YNCg0KVVRGLTggZW5jb2RlZCBK
U09OIHN0cmluZ3Mgd2l0aCBvdGhlciB1bmljb2RlIHN0cmluZ3MgaW4gYW55IG9mIHRoZSB1bmlj
b2RlDQoNCmVuY29kaW5nIGZvcm1hdHMsIGJ1dCBvbmx5IGltcGxpZXMgdGhhdDsgaXQgc2hvdWxk
IGJlIHN0YXRlZC4NCg0KDQoNCkdvb2QNCg0KDQoNCj4NCg0KPiAgICAxLiAgUmVtb3ZlIGFueSBK
U09OIGFwcGxpZWQgZXNjYXBpbmcgdG8gcHJvZHVjZSBhbiBhcnJheSBvZiBVbmljb2RlDQoNCj4g
ICAgICAgIGNvZGUgcG9pbnRzLg0KDQoNCg0KSSBkb24ndCB0aGluayAoMSkgaXMgY29ycmVjdC4g
IEEgSlNPTiBzdHJpbmcgaXMgYnkgZGVmYXVsdCBlbmNvZGVkIGluIFVURi04LiBBDQoNClVURi04
IGVuY29kZWQgc3RyaW5nIGlzIG5vdCAiYW4gYXJyYXkgb2YgVW5pY29kZSBjb2RlIHBvaW50cyIg
KGl0cyBhIHNlcXVlbmNlIG9mDQoNCmNvZGUgdW5pdHMsIHdoaWNoIG11c3QgYmUgZGVjb2RlZCBp
bnRvIGNvZGUgcG9pbnRzKSwgaSB0aGluayBhIHN0ZXAgaXMgbWlzc2luZw0KDQpoZXJlLi4NCg0K
DQoNCiAgICAxLiAgUmVtb3ZlIGFueSBKU09OIGVzY2FwaW5nIGZyb20gdGhlIGlucHV0IEpTT04g
c3RyaW5nLg0KDQoNCg0KICAgIDEuYSAgY29udmVydCB0aGUgc3RyaW5nIGludG8gYSBzZXF1ZW5j
ZSBvZiB1bmljb2RlIGNvZGUgcG9pbnRzLg0KDQoNCg0KSG93IGFib3V0IOKAnFJlbW92ZSBhbnkg
SlNPTiBlc2NhcGluZyBmcm9tIHRoZSBpbnB1dCBKU09OIHN0cmluZyBhbmQgY29udmVydCB0aGUg
c3RyaW5nIGludG8gYSBzZXF1ZW5jZSBvZiBVbmljb2RlIGNvZGUgcG9pbnRz4oCdPw0KDQoNCg0K
Li5hbmQgdGhlbiBjb21wYXJlIGNvZGUgcG9pbnQtYnktY29kZSBwb2ludC4gVGhpcyBvdmVyYWxs
IGFsZ29yaXRobSAvc2VlbXMvIG9rLA0KDQpidXQgSSdtIG5vdCBzdXJlLCBpdCBzZWVtcyB0aGVy
ZSdzIHJhdGlvbmFsZSB0aGF0J3Mgbm90IGV4cHJlc3NlZCwgZWcgZm9yDQoNCmV4Y2x1ZGluZyB1
c2Ugb2YgVW5pY29kZSBOb3JtYWxpemF0aW9uIFtVU0ExNV0uIEFsc28gdGhlIGFsZyBpcyBpbmNv
bXBsZXRlIGluDQoNCnRoYXQgaXQgZG9lc24ndCBzdGlwdWxhdGUgY29udmVydGluZyB0aGUgIm90
aGVyIHVuaWNvZGUgc3RyaW5nIiBpbnRvIGEgc2VxdWVuY2UNCg0Kb2YgY29kZSBwb2ludHMuDQoN
Cg0KDQpGYWlyIGVub3VnaA0KDQoNCg0KPiAxMC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0K
Pg0KDQo+DQoNCj4gICAgQWxsIG9mIHRoZSBzZWN1cml0eSBpc3N1ZXMgZmFjZWQgYnkgYW55IGNy
eXB0b2dyYXBoaWMgYXBwbGljYXRpb24NCg0KPiAgICBtdXN0IGJlIGZhY2VkIGJ5IGEgSldUL0pX
Uy9KV0UvSldLIGFnZW50LiAgQW1vbmcgdGhlc2UgaXNzdWVzIGFyZQ0KDQo+ICAgIHByb3RlY3Rp
bmcgdGhlIHVzZXIncyBwcml2YXRlIGtleSwgcHJldmVudGluZyB2YXJpb3VzIGF0dGFja3MsIGFu
ZA0KDQo+ICAgIGhlbHBpbmcgdGhlIHVzZXIgYXZvaWQgbWlzdGFrZXMgc3VjaCBhcyBpbmFkdmVy
dGVudGx5IGVuY3J5cHRpbmcgYQ0KDQo+ICAgIG1lc3NhZ2UgZm9yIHRoZSB3cm9uZyByZWNpcGll
bnQuICBUaGUgZW50aXJlIGxpc3Qgb2Ygc2VjdXJpdHkNCg0KPiAgICBjb25zaWRlcmF0aW9ucyBp
cyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQsIGJ1dCBzb21lDQoNCj4gICAgc2ln
bmlmaWNhbnQgY29uY2VybnMgYXJlIGxpc3RlZCBoZXJlLg0KDQo+DQoNCj4gICAgQWxsIHRoZSBz
ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbiB0aGUgSldTIHNwZWNpZmljYXRpb24gYWxzbyBhcHBs
eQ0KDQo+ICAgIHRvIEpXVCwgYXMgZG8gdGhlIEpXRSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyB3
aGVuIGVuY3J5cHRpb24gaXMNCg0KPiAgICBlbXBsb3llZC4gIEluIHBhcnRpY3VsYXIsIHRoZSBK
V1MgSlNPTiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBhbmQNCg0KPiAgICBVbmljb2RlIENvbXBh
cmlzb24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYXBwbHkgZXF1YWxseSB0byB0aGUgSldUDQoN
Cj4gICAgQ2xhaW1zIFNldCBpbiB0aGUgc2FtZSBtYW5uZXIgdGhhdCB0aGV5IGRvIHRvIHRoZSBK
V1MgSGVhZGVyLg0KDQo+DQoNCg0KDQpkdW5ubyBpZiB5b3UgY2FuIGdldCBhd2F5IHdpdGggc2Vj
IGNvbnMgd2hvbGx5IGluIG90aGVyIGRvY3MsIGFuZCBJJ20gbm90IHN1cmUNCg0KaXQncyBhcHBy
b3ByaWF0ZSBnaXZlbiB0aGF0IEpXVHMgYXJlIGEgcHJvZmlsZSBvZiBKV0Ugb3IgSldTLg0KDQoN
Cg0KVGhhdCB3YXMgdGhlIGFwcHJvYWNoIHRoYXQgU2VhbiBoYWQgc3VnZ2VzdGVkLiAgSWYgdGhl
cmUgb3RoZXIgdGhpbmdzIHlvdSB0aGluayB3ZSBzaG91bGQgc3BlY2lmaWNhbGx5IGFkZCwgaG93
ZXZlciwgcGxlYXNlIGxldCBtZSBrbm93Lg0KDQoNCg0KYWJvdmUgbmVlZHMgZWRpdG9yaWFsIHBv
bGlzaCAtLSB0aGVyZSBhcmVuJ3QgYW55ICAic2lnbmlmaWNhbnQgY29uY2VybnMiDQoNCmFjdHVh
bGx5IGxpc3RlZCBoZXJlLg0KDQoNCg0KVHJ1ZSBlbm91Z2gNCg0KDQoNCi0tLQ0KDQplbmQNCg0K
DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
DQpPQXV0aCBtYWlsaW5nIGxpc3QNCg0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYu
b3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPQXV0aCBtYWls
aW5nIGxpc3QNCk9BdXRoQGlldGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0KDQoNCg0KLS0NCk5hdCBTYWtp
bXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25hdC5zYWtp
bXVyYS5vcmcvDQpAX25hdF9lbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9B
dXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0
aA0KDQoNCg==

--_000_27E7BEAA592248D498B1C063F2C782F9adobecom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13
ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z
cGFjZTsgIj5UaGFua3MgTmF0LDxkaXY+PGJyPjwvZGl2PjxkaXY+c28gSSBhc3N1bWUgWzBdIGlz
IG91dCBvZiBkYXRlIHNpbmNlIG5ldGhlciZuYnNwO1JTQS1QS0NTMSBhbmQgQUVTLSogYXJlIG5v
dCBBRUFEIGFsZ29yaXRobXMgYXMgbG9uZyBhcyBJIGtub3cuPC9kaXY+PGRpdj48YnI+PC9kaXY+
PGRpdj5RdW90aW5nOjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+IjxzcGFuIGNsYXNzPSJBcHBs
ZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgd2hpdGUtc3BhY2U6
IHByZTsgIj5JZiBhbiBpbXBsZW1lbnRhdGlvbiBwcm92aWRlcyBlbmNyeXB0aW9uIGNhcGFiaWxp
dGllcywgb2YgdGhlIEpXRTwvc3Bhbj48L2Rpdj48cHJlIGNsYXNzPSJuZXdwYWdlIj4gICBlbmNy
eXB0aW9uIGFsZ29yaXRobXMsIG9ubHkgUlNBLVBLQ1MxLTEuNSB3aXRoIDIwNDggYml0IGtleXMs
IEFFUy0NCiAgIDEyOC1LVywgQUVTLTI1Ni1LVywgQUVTLTEyOC1DQkMsIGFuZCBBRVMtMjU2LUNC
QyBNVVNUIGJlIGltcGxlbWVudGVkDQogICBieSBjb25mb3JtaW5nIGltcGxlbWVudGF0aW9ucy4g
IEl0IGlzIFJFQ09NTUVOREVEIHRoYXQNCiAgIGltcGxlbWVudGF0aW9ucyBhbHNvIHN1cHBvcnQg
RUNESC1FUyB3aXRoIDI1NiBiaXQga2V5cywgQUVTLTEyOC1HQ00sDQogICBhbmQgQUVTLTI1Ni1H
Q00uICBTdXBwb3J0IGZvciBvdGhlciBhbGdvcml0aG1zIGFuZCBrZXkgc2l6ZXMgaXMNCiAgIE9Q
VElPTkFMLiI8L3ByZT48ZGl2Pjxicj48L2Rpdj48ZGl2PlJlZ2FyZHM8L2Rpdj48ZGl2Pjxicj48
L2Rpdj48ZGl2PkFudG9uaW88L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlswXSZuYnNwOzxhIGhy
ZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWIt
dG9rZW4tMDYjc2VjdGlvbi04Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LW9hdXRoLWpzb24td2ViLXRva2VuLTA2I3NlY3Rpb24tODwvYT48YnI+PGRpdj48ZGl2Pk9uIERl
YyAyOSwgMjAxMiwgYXQgNzowMSBQTSwgTmF0IFNha2ltdXJhIHdyb3RlOjwvZGl2PjxiciBjbGFz
cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp
diBkaXI9ImF1dG8iPjxkaXY+PGJyPjxicj49bmF0IHZpYSBpUGhvbmU8L2Rpdj48ZGl2Pjxicj5E
ZWMgMjksIDIwMTIgMTk6MzXjgIFBbnRvbmlvIFNhbnNvICZsdDs8YSBocmVmPSJtYWlsdG86YXNh
bnNvQGFkb2JlLmNvbSI+YXNhbnNvQGFkb2JlLmNvbTwvYT4mZ3Q7IOOBruODoeODg+OCu+ODvOOC
uDo8YnI+DQo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj5IaSBOYXQsPGRp
dj48YnI+PC9kaXY+PGRpdj5hcG9sb2dpZXMgaWYgdGhpcyBzb3VuZHMgdHJpdmlhbCBidXQgSSBh
bSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGUgSlcqIHN0dWZmIGFuZCB0aGlzIG1haWwgdGhyZWFk
IGlzIGhlbHBpbmcgbWUgdG8gY2xhcmlmeSBzb21lIG9mIG15IGRvdWJ0cy48L2Rpdj48ZGl2Pjxi
cj4NCjwvZGl2PjxkaXY+PGJyPjxkaXY+PGRpdj5PbiBEZWMgMjAsIDIwMTIsIGF0IDc6MTIgQU0s
IE5hdCBTYWtpbXVyYSB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l
d2xpbmUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPlRoYW5rcy4mbmJzcDs8ZGl2Pjxicj48L2Rp
dj48ZGl2Pkp1c3QgYSBmZXcgdGhpbmdzOiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+
MS4gU2lnbitFbmNyeXB0PC9kaXY+DQo8L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5r
aW5kIG9mIG5pdHBpY2tpbmcgaGVyZSwgYnV0IHdvdWxkIG5vdCBiZSBiZXR0ZXIgdG8gaW52ZXJ0
IHRob3NlIHRlcm1zIGluIG9yZGVyIHRvIHNvdW5kIEVuY3J5cHQrU2lnbiAoYXMgbG9uZyBhcyBJ
IGtub3cgdGhlIG9yZGVyIG1hdHRlcnMgaGVyZSBhbmQgdGhlIG9ubHkgc2FmZSB3YXkgaXMgZW5j
cnlwdCB0aGFuICZuYnNwO01BQykuPC9kaXY+DQo8L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVv
dGU+PGRpdj48YnI+PC9kaXY+Tm8uIFlvdSBzaG91bGQgdXNlIEFFQUQgYWxnb3JpdGhtcyBmb3Ig
dGhlIGludGVncml0eSBwcm90ZWN0aW9uLiZuYnNwOzxkaXY+PGJyPjwvZGl2PjxkaXY+U2lnbmlu
ZyBzb21ldGhpbmcgdGhhdCB5b3UgY2Fubm90IGRlY3J5cHQgYW5kIHZlcmlmeSBpcyBwcmV0dHkg
bWVhbmluZ2xlc3MgJm5ic3A7aW4gdGhlIGNvbnRyYWN0dWFsIHNldHRpbmdzLiZuYnNwOzwvZGl2
Pg0KPGRpdj48YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj48ZGl2PjxkaXY+PGJyPjxi
bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PGJyPjwvZGl2PjxkaXY+U2lnbitFbmNyeXB0IGlz
IHVzZWZ1bCB3aGVuIHlvdSB3YW50IHRoZSBzaWduZWQgSldUIGFzIGEgcHJvb2Ygb2YgY29uc2Vu
dCB0byBzaWduLiZuYnNwOzwvZGl2PjxkaXY+SXQgY2FuIGFsc28gZXhpc3QgYWZ0ZXIgYmVpbmcg
ZGVjcnlwdGVkLiZuYnNwOzwvZGl2Pg0KDQo8ZGl2PklmIHlvdSBqdXN0IHdhbnQgaW50ZWdyaXR5
IHByb3RlY3Rpb24sIHVzZSBKV0UuJm5ic3A7PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwv
ZGl2PjxkaXY+Rm9yIGludGVncml0eSBzaG91bGQgbm90IGJlIGVub3VnaCB0aGUgc2lnbmF0dXJl
IHNvIEpXUz88L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9k
aXY+QWxsIEpXRSBhbGdvcml0aG1zIGFyZSBBRUFEIHNvIEpXUyBzaWduaW5nIG92ZXIgSldFIGlz
IHJlZHVuZGFudC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi
PjxkaXY+PGRpdj48ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtzIGEgbG90IGFuZCByZWdh
cmRzPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BbnRvbmlvPC9kaXY+PGJyPjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiPjxkaXY+PGJyPjwvZGl2PjxkaXY+Mi4gQWxwaGFiZXRpemF0aW9uIG9mIHRo
ZSB0ZXJtaW5vbG9neTwvZGl2Pg0KPGRpdj48YnI+PC9kaXY+PGRpdj5UaGF0J3Mgb25lIHdheSBv
ZiBvcmdhbml6aW5nIGl0LiZuYnNwOzwvZGl2PjxkaXY+QW5vdGhlciB3YXkgb2Ygb3JnYW5pemlu
ZyBpdCBpcyB0byBsYXkgdGhlbSBvdXQgaW4gYSBzZW1hbnRpYyBvcmRlciwmbmJzcDs8L2Rpdj4N
CjxkaXY+d2hlcmUgdGhlIHByZWNlZGluZyBkZWZpbml0aW9uIGNhbm5vdCB1c2UgdGhlIHRlcm1z
IGRlZmluZWQgbGF0ZXIuJm5ic3A7PC9kaXY+PGRpdj5JdCBpcyBhIGdvb2Qgd2F5IHRvIG1ha2Ug
c3VyZSB0aGUgY29uc2lzdGVuY3ksIGFuZCBJIHByb2JhYmx5IGxpa2UgdGhpcyB3YXkgYmV0dGVy
LiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+T2YgdGhlIGRlZmluaXRpb24gdGhlbXNl
bHZlcywgSSBhZ3JlZSBpdCBzdGlsbCBsYWNrcyBidW5jaCBvZiB0ZXJtcyB0aGF0IG5lZWRzIHRv
IGJlIGRlZmluZWQsJm5ic3A7PC9kaXY+DQoNCjxkaXY+YW5kIG5lZWRzIHRpZ2h0ZW5pbmcgdXAu
Jm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXN0LCZuYnNwOzwvZGl2PjxkaXY+PGJy
PjwvZGl2PjxkaXY+TmF0PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PGRpdiBjbGFzcz0i
Z21haWxfcXVvdGUiPk9uIFRodSwgRGVjIDIwLCAyMDEyIGF0IDk6MTQgQU0sIE1pa2UgSm9uZXMg
PHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3Nv
ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZn
dDs8L3NwYW4+IHdyb3RlOjxicj4NCg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz
dHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGlu
Zy1sZWZ0OjFleCI+DQoNCg0KDQoNCg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp
bms9InB1cnBsZSI+DQo8ZGl2PjxwPlRoYW5rcyBhIGJ1bmNoIGZvciB0aGUgdXNlZnVsIHJldmll
dywgSmVmZiEmbmJzcDsgUmVzcG9uc2VzIGFyZSBpbmxpbmUNCjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDBiMDUwIj5pbiBncmVlbjwvc3Bhbj4uPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNw
Ozx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1p
a2U8dT48L3U+PHU+PC91PjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHU+PC91PiZuYnNwOzx1Pjwv
dT48L3A+PHA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQoNCkZyb206IDxhIGhyZWY9
Im1haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+b2F1dGgtYm91
bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0Bp
ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBC
ZWhhbGYgT2YgPUplZmZIPGJyPg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjcsIDIwMTIgMjoy
MyBQTTxicj4NClRvOiBJRVRGIG9hdXRoIFdHPGJyPg0KU3ViamVjdDogW09BVVRILVdHXSByZXZp
ZXc6IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDU8L3A+PHA+PHU+PC91PiZuYnNw
Ozx1PjwvdT48L3A+PHA+SGksIGF0IGlldGYtODUgYXRsYW50YSBJIGFncmVlZCB0byBkbyBhIHJl
dmlldyBvZiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1LCBhbmQgc28gSSBoYXZl
IHNvbWUgdGhvdWdodHMgYmVsb3cuIEFsc28sICsxIHRvIEhhbm5lcycgY29tbWVudHMuPHU+PC91
Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+T3ZlcmFsbCB0aGUgc3Bl
YyBzZWVtcyB0byBnZXQgaXRzIGlkZWEgYWNyb3NzLCBidXQgaXMgcHJldHR5IHJvdWdoLiBQYXJ0
IG9mIHRoaXMgaXMgZHVlIHRvIHRoZSBsYW5ndWFnZSBiZWluZyBjb252b2x1dGVkLCBwbHVzIHNv
bWUgY29uY2VwdHMgYXJlIG9ubHkgdGFjaXRseSBkZXNjcmliZWQgKHdpdGggY2x1ZXMgc2NhdHRl
cmVkIHRocm91Z2hvdXQgdGhlIHNwZWMpLCBhbmQgdGh1cyBpdCBpcyBkaWZmaWN1bHQNCiB0byB1
bmRlcnN0YW5kIHdpdGhvdXQgbXVsdGlwbGUgcGFzc2VzIG9mIHRoaXMgc3BlYyBhcyB3ZWxsIGFz
IFtKV0VdIGFuZCBbSldTXS48dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91
PjwvcD48cD5Gb3IgZXhhbXBsZSwgYSBKV1QgYXBwZWFycyB0byBiZSBzaW1wbHkgZWl0aGVyIGEg
SldTIG9yIGEgSldFIGNvbnRhaW5pbmcgYSBKV1QgQ2xhaW1zIFNldCwgYnV0IHRoaXMgaXMgbm90
IHN0YXRlZCB1bnRpbCByaWdodCBiZWZvcmUgc2VjdGlvbiAzLjEgKGFuZCBpdCBpc24ndCBzdGF0
ZWQgdGhhdCBjbGVhcmx5KS48dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91
PjwvcD4NCjwvZGl2PjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBiMDUwIj5PSywgSeKAmWxsIHNh
eSB0aGF0IGVhcmxpZXIgYW5kIG1vcmUgY2xlYXJseS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+
PGRpdiBjbGFzcz0iaW0iPjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBiMDUwIj48dT48L3U+Jm5i
c3A7PHU+PC91Pjwvc3Bhbj48L3A+PHA+SW1tZWRpYXRlbHkgYmVsb3cgYXJlIHNvbWUgb3ZlcmFs
bCBjb21tZW50cywgYW5kIHRoZW4gYmVsb3cgdGhhdCBzb21lIGRldGFpbGVkIGNvbW1lbnRzIG9u
IHZhcmlvdXMgcG9ydGlvbnMgb2YgdGhlIHNwZWMuJm5ic3A7IEknbSBub3QgYWRkcmVzc2luZyBl
dmVyeXRoaW5nIEkgbm90aWNlZCBkdWUgdG8gdGltZSBjb25zdHJhaW50cyAoYXBvbG9naWVzKS48
dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD5IVEg8dT48L3U+
PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD49SmVmZkg8dT48L3U+PHU+
PC91PjwvcD48cD4tLS0tLS08dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91
PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD5KV1QgdGVybWlub2xvZ3k6PHU+PC91
Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+U29tZSBpc3N1ZXMgc2Vl
bSB0byBtZSB0byBiZSBjYXVzZWQgYnkgZGVmaW5pbmcgdGhlIEpXVCB0byBiZSB0aGUgYmFzZTY0
dXJsIGVuY29kZWQgSlNPTiZuYnNwOyBvYmplY3QgaXRzZWxmIGFuZCBub3QgaGF2aW5nIHRlcm1p
bm9sb2d5IHRvIGNsZWFybHkgcmVmZXIgdG8gaXRzIHVuZW5jb2RlZCBmb3JtLjx1PjwvdT48dT48
L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPkZvciBleGFtcGxlLCB0aGVzZSB0
d28gSlNPTiBvYmplY3RzIHRvZ2V0aGVyIGFwcGFyZW50bHkgY29tcHJpc2UgYSAodW5lbmNvZGVk
KSBKV1QuLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7InR5cCI6IkpXVCIsPHU+PC91Pjx1PjwvdT48
L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJhbGciOiJIUzI1NiJ9
PHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj48cD48
c3BhbiBzdHlsZT0iY29sb3I6IzAwYjA1MCI+VGhpcyBpcyB0aGUgSldUIEhlYWRlci4mbmJzcDsg
VGhlIGJhc2U2NHVybCBlbmNvZGVkIHZlcnNpb24gaXMgdGhlIEVuY29kZWQgSldUIEhlYWRlci48
dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PGRpdiBjbGFzcz0iaW0iPjxwPjxzcGFuIHN0eWxlPSIi
Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD48cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgeyJpc3MiOiJqb2UiLDx1PjwvdT48dT48L3U+PC9wPjxwPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiZXhwIjoxMzAwODE5MzgwLDx1PjwvdT48dT48L3U+PC9w
PjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAiPGEgaHJlZj0iaHR0cDov
L2V4YW1wbGUuY29tL2lzX3Jvb3QiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6
d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cDovL2V4YW1wbGUuY29tL2lzX3Jv
b3Q8L3NwYW4+PC9hPiI6dHJ1ZX08dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+
PC91PjwvcD4NCjwvZGl2PjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBiMDUwIj5UaGlzIGlzIHRo
ZSBKV1QgQ2xhaW1zIFNldC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PGRpdiBjbGFzcz0iaW0i
PjxwPjxzcGFuIHN0eWxlPSIiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD48cD4uLmJ1
dCB0aGVyZSdzIG5vIGRlZmluZWQgd2F5IHRvIHJlZmVyIHRvIHRoZW0gZ2l2ZW4gdGhlIHNwZWMn
cyB0ZXJtaW5sb2d5Ljx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9w
Pg0KPC9kaXY+PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAiPlRoZSB0ZXJtcyBhYm92ZSBh
cmUgYWxyZWFkeSBkZWZpbmVkIGluIHRoZSBzcGVjLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48
ZGl2IGNsYXNzPSJpbSI+PHA+PHNwYW4gc3R5bGU9IiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3Nw
YW4+PC9wPjxwPkNvbnNpZGVyIHRlcm1pbmcgdGhlIGFib3ZlIGEgSldUIGFuZCBpdHMgZW5jb2Rl
ZC1zdHJpbmcgZm9ybSBhbiBFbmNvZGVkIEpXVCwgYW5kIGRlZmluZSB0aGVtIHNlcGFyYXRlbHku
IEFuZCB0aGVuIHRoZXJlJ2xsIGJlIHNpbWlsYXIgZGVmaW5pdGlvbnMgZm9yIEpXVCBIZWFkZXIg
YW5kIEpXVCBDbGFpbXMgU2V0LCBlLmcuLDx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9wPg0KPC9kaXY+PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAiPkkgZGlz
YWdyZWUgd2l0aCByZWRlZmluaW5nIHRoZSB0ZXJtIOKAnEpXVOKAnSB0byBub3QgYWxzbyBpbmNs
dWRlIHRoZSBzaWduYXR1cmUuJm5ic3A7IFRoZSB0ZXJtIOKAnEpXVOKAnSBzaG91bGQgY29udGlu
dWUgdG8gcmVmZXIgdG8gdGhlIHdob2xlIHRoaW5nLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48
ZGl2IGNsYXNzPSJpbSI+PHA+PHNwYW4gc3R5bGU9IiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3Nw
YW4+PC9wPjxwPiZuYnNwOyZuYnNwOyZuYnNwOyBFbmNvZGVkIEpXVCZuYnNwOyZuYnNwOyBBIEpX
VCB0aGF0IGhhcyBiZWVuIGVuY29kZWQgYWNjb3JkaW5nIHRvIHRoZTx1PjwvdT48dT48L3U+PC9w
PjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDtwcm9jZXNzIGRlZmluZWQg
aW4gU2VjdGlvbiBYLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9w
PjxwPiZuYnNwOyZuYnNwOyZuYnNwOyBFbmNvZGVkIEpXVCBIZWFkZXImbmJzcDsmbmJzcDsgVGhl
IGVuY29kZWQtc3RyaW5nIGZvcm0gb2YgYSBKV1QgSGVhZGVyPHU+PC91Pjx1PjwvdT48L3A+PHA+
PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVuY29kZWQgSldU
IENsYWltcyBTZXQmbmJzcDsmbmJzcDsgVGhlIGVuY29kZWQtc3RyaW5nIGZvcm0gb2YgYSBKV1Qg
Q2xhaW1zIFNldDx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0K
PC9kaXY+PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAiPknigJlsbCBub3RlIHRoYXQgd2hl
biB0aGUgSldUIGlzIGVuY3J5cHRlZCwgYSBiYXNlNjR1cmwgZW5jb2RlZCByZXByZXNlbnRhdGlv
biBvZiB0aGUgSldUIENsYWltcyBTZXQgaXMgbmV2ZXIgdXNlZC4mbmJzcDsgKFRoZSBlbmNyeXB0
ZWQgZm9ybSBvZiB0aGVtIGlzIGJhc2U2NHVybCBlbmNvZGVkIGluc3RlYWQuKTx1PjwvdT48dT48
L3U+PC9zcGFuPjwvcD4NCg0KPGRpdiBjbGFzcz0iaW0iPjxwPjxzcGFuIHN0eWxlPSIiPjx1Pjwv
dT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD48cD4mbmJzcDsmbmJzcDsmbmJzcDsgZW5jb2RlZC1z
dHJpbmcgZm9ybSZuYnNwOyZuYnNwOyBUaGUgcmVzdWx0IG9mIGFwcGx5aW5nIEJhc2U2NHVybCBl
bmNvZGluZyB0byBhbjx1PjwvdT48dT48L3U+PC9wPjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBpbnB1dCBKU09OIHRleHQgLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1Pjwv
dT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAi
PlNvbWV0aW1lcyBoZSBpbnB1dCB0byB0aGUgYmFzZTY0dXJsIGVuY29kaW5nIGlzIG5vdCBKU09O
IOKAkyBmb3IgaW5zdGFuY2Ugc2lnbmF0dXJlIHZhbHVlcyBvciBlbmNyeXB0ZWQgcGF5bG9hZHMu
PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxkaXYgY2xhc3M9ImltIj48cD48c3BhbiBzdHlsZT0i
Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEpT
T04gV2ViIFRva2VuIChKV1QpJm5ic3A7IEEgSldUIGNvbXByaXNlcyBhIEpXVCBIZWFkZXIgYW5k
IGEgSldUIENsYWltcyBTZXQuIC4uLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8
dT48L3U+PC9wPjxwPiZuYnNwOyZuYnNwOyZuYnNwOyBKV1QgSGVhZGVyJm5ic3A7IEEgSlNPTiBv
YmplY3QgdGhhdCBpcyBhIGNvbXBvbmVudCBvZiBhIEpXVC4gSXQgZGVub3RlcyB0aGU8dT48L3U+
PHU+PC91PjwvcD48cD4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjcnlw
dG9ncmFwaGljIG9wZXJhdGlvbnMgYXBwbGllZCB0byB0aGUgSldULiZuYnNwOyAuLi48dT48L3U+
PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD4mbmJzcDsmbmJzcDsmbmJz
cDsgSldUIENsYWltcyBTZXQmbmJzcDsgQSBKU09OIG9iamVjdCBjb250YWluaW5nIGEgc2V0IG9m
IGNsYWltcy4mbmJzcDsgLi4uPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1Pjwv
dT48L3A+PHA+VGhpcyBhbHNvIGdldHMgcmlkIG9mIHRoZSB1c2Ugb2YgdGhlICJBIHN0cmluZyBy
ZXByZXNlbnRpbmcgYSBKU09OIG9iamVjdC4uLiINCjx1PjwvdT48dT48L3U+PC9wPjxwPndoaWNo
IEkgZmluZCBjb25mdXNpbmcgYW5kIHBvdGVudGlhbGx5IG1pc2xlYWRpbmcgKGJlY2F1c2UgaXQg
aXMgYWN0dWFsbHkgImEgQmFzZTY0dXJsIGVuY29kaW5nIG9mIGEgSlNPTiBvYmplY3QiKS48dT48
L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2PjxwPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDBiMDUwIj5BYWgg4oCTIEkgbm93IHNlZSB0aGF0IHRoaXMgaXMgdGhl
IHJlYWwgbWlzdW5kZXJzdGFuZGluZy4mbmJzcDsgVGhlIOKAnHN0cmluZyByZXByZXNlbnRpbmcg
YSBKU09OIG9iamVjdOKAnSBpcyBub3QgdGhlIGJhc2U2NHVybCBlbmNvZGVkIGZvcm0g4oCTIGl0
4oCZcyB0aGUgc3RyaW5nIHJlcHJlc2VudGF0aW9uIHRoYXTigJlzIHBhcnNlYWJsZSBpbnRvIGEg
SlNPTiBvYmplY3QuJm5ic3A7IEZvcg0KIGluc3RhbmNlLCBpdCBjb3VsZCBiZSBhIHN0cmluZyBz
dWNoIGFzIHvigJxhbGfigJ064oCdUlMyNTbigJ19IOKAkyBub3QgdGhlIGJhc2U2NHVybCBlbmNv
ZGVkIHZlcnNpb24gb2YgdGhhdCBzdHJpbmcuJm5ic3A7IFRoZSByZWFzb24gZm9yIHRoZSBzeW50
YWN0aWMgY29uc3RydWN0aW9uIOKAnHN0cmluZyByZXByZXNlbnRpbmcgYSBKU09OIG9iamVjdOKA
nSBpcyB0aGF0IGl0cyBzdHJpbmcgcmVwcmVzZW50YXRpb24gaXMgZGlzdGluY3QgZnJvbSB0aGUg
YWJzdHJhY3QgSlNPTiBvYmplY3QNCiBpdHNlbGYuJm5ic3A7IElmIEkgaW5zZXJ0IHdoaXRlc3Bh
Y2UgYWZ0ZXIgdGhlIGNvbG9uIGluIHRoZSBzdHJpbmcge+KAnGFsZ+KAnTrigJ1SUzI1NuKAnX0g
aXQgd291bGQgcGFyc2UgdG8gYW4gZXF1aXZhbGVudCBKU09OIG9iamVjdCBidXQgaXQgd291bGQg
YmUgYSBkaWZmZXJlbnQgc3RyaW5nIHJlcHJlc2VudGF0aW9uLiZuYnNwOyBJdOKAmXMgdGhlIHN0
cmluZyByZXByZXNlbnRhdGlvbiB0aGF0IGlzIGFjdHVhbGx5IG9wZXJhdGVkIG9uIGJ5IHRoZSBK
V1QvSldTL0pXRSBvcGVyYXRpb25zLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48cD48c3BhbiBz
dHlsZT0iY29sb3I6IzAwYjA1MCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPjxwPjxz
cGFuIHN0eWxlPSJjb2xvcjojMDBiMDUwIj5J4oCZbGwgdHJ5IHRvIG1ha2UgdGhpcyBjbGVhcmVy
IGluIHRoZSBzcGVjLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+
PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+VVRGLTg6PHU+PC91Pjx1PjwvdT48L3A+PHA+DQo8
dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD5VVEYtOCBpcyBtZW50aW9uZWQgaW4gbG90cyBvZiBw
bGFjZXMuIEl0IGNvdWxkIHByb2JhYmx5IGJlIHN0YXRlZCBvbmNlIHVwIG5lYXINCjx1PjwvdT48
dT48L3U+PC9wPjxwPnRoZSBiZWdpbm5pbmcgb2YgdGhlIHNwZWMgdGhhdCBhbGwgdGhlIEpTT04g
dGV4dCBpcyBVVEYtOCBlbmNvZGVkLCBhbmQgYWxsIHRoZQ0KPHU+PC91Pjx1PjwvdT48L3A+PHA+
SlNPTiBzdHJpbmdzIGFyZSBVVEYtOCBlbmNvZGVkLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1Pjwv
dT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAi
PknigJlsbCBzZWUgaWYgSSBjYW4gZmlndXJlIG91dCBob3cgdG8gZG8gdGhpcyB3aXRob3V0IGlu
dHJvZHVjaW5nIGFtYmlndWl0eS48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PGRpdiBjbGFzcz0i
aW0iPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPlNlbWFudGljcywgcHJvZmlsZXMgYW5k
IHJlbGF0aW9uc2hpcCB0byBTQU1MOjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8
dT48L3U+PC9wPjxwPlRoZSBzcGVjIGRvZXMgbm90IGRlZmluZSBhbnkgb3ZlcmFsbCBKV1Qgc2Vt
YW50aWNzIChpLmUuLCB3aGF0IGFueSBnaXZlbiBKV1QNCjx1PjwvdT48dT48L3U+PC9wPjxwPi9t
ZWFucy8pLiBTZW1hbnRpY3MgYXJlIG9ubHkgZGVmaW5lZCBpbiBjb250ZXh0IG9mIGVhY2ggaW5k
aXZpZHVhbCBSZXNlcnZlZA0KPHU+PC91Pjx1PjwvdT48L3A+PHA+Q2xhaW0gTmFtZS48dT48L3U+
PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD5UaHVzIGFueSBhcHBsaWNh
dGlvbiBvZiBKV1RzIHdpbGwgbmVlZCB0byBwcm9maWxlIHRoZSBKV1Qgc3BlYzogc3BlY2lmeWlu
ZyB0aGUNCjx1PjwvdT48dT48L3U+PC9wPjxwPmNsYWltIHNldChzKSBjb250ZW50cywgYW5kIHRo
ZSBvdmVyYWxsIHNlbWFudGljcyBvZiB0aGUgcmVzdWx0YW50IEpXVChzKS4mbmJzcDsgVGhpcw0K
PHU+PC91Pjx1PjwvdT48L3A+PHA+aXMgbm90IGV4cGxpY2l0bHkgZXhwbGFpbmVkIGluIHRoZSBK
V1Qgc3BlYy48dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwv
ZGl2PjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBiMDUwIj5DYW4geW91IHN1Z2dlc3Qgc29tZSBs
YW5ndWFnZSB5b3XigJlkIGxpa2UgdG8gc2VlIGFkZGVkIGFib3V0IHRoaXM/PC9zcGFuPjxzcGFu
IHN0eWxlPSIiPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHNw
YW4gc3R5bGU9IiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPjxwPkluIHRlcm1zIG9m
IFNBTUwsIEFwcGVuZGl4IEIgc2hvdWxkIHJlZmVyIHRvIFNBTUwgYXNzZXJ0aW9ucyByYXRoZXIg
dGhhbiBzYW1sDQo8dT48L3U+PHU+PC91PjwvcD48cD50b2tlbnMuIEFsc28sIEknbSBub3Qgc3Vy
ZSBTQU1MIGFzc2VydGlvbnMgaW5oZXJlbnRseSBoYXZlIG1vcmUgZXhwcmVzc2l2aXR5DQo8dT48
L3U+PHU+PC91PjwvcD48cD50aGFuIEpXVHMuIFRoZXkgZG8gaGF2ZSBtb3JlIHByZS1kZWZpbmVk
IHN0cnVjdHVyZSBhbmQgc2VtYW50aWNzLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9wPg0KPC9kaXY+PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAiPk9LPHU+
PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxkaXYgY2xhc3M9ImltIj48cD48c3BhbiBzdHlsZT0iIj48
dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+PHA+U3ludGFjdGljYWxseSwgaXQgc2VlbXMg
b25lIGNhbiBlbmNvZGUgcHJldHR5IG11Y2ggYW55dGhpbmcgaW4gd2hhdGV2ZXIgYW1vdW50DQo8
dT48L3U+PHU+PC91PjwvcD48cD5pbiBhIEpXVCAob25lIGNhbiBkbyB0aGUgc2FtZSB3aXRoIFNB
TUwgYXNzZXJ0aW9ucyksIGFuZCB0aHVzIHRoZW9yZXRpY2FsbHkgSldUcw0KPHU+PC91Pjx1Pjwv
dT48L3A+PHA+Y291bGQgYmUgdXNlZCB0byBhY2NvbXBsaXNoIHRoZSBzYW1lIHRoaW5ncyBhcyBT
QU1MIGFzc2VydGlvbnMuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48
L3A+PHA+U2VtYW50aWNhbGx5LCBTQU1MIGFzc2VydGlvbnMgYXJlIGV4cGxpY2l0bHkgc3RhdGVt
ZW50cyBtYWRlIGJ5IGEgc3lzdGVtIGVudGl0eQ0KPHU+PC91Pjx1PjwvdT48L3A+PHA+YWJvdXQg
YSBzdWJqZWN0LiBCdXQgYnkgZGVmYXVsdCwgYSBKV1QgaXMgZW1wdHksIGFuZCBoYXMgbm8gc2Vt
YW50aWNzICh0aGlzDQo8dT48L3U+PHU+PC91PjwvcD48cD5pc24ndCBzdGF0ZWQgZXhwbGljaXRs
eSkuIEFsbCBzZW1hbnRpY3MgZGVmaW5lZCBpbiB0aGUgSldUIHNwZWMgYXJlIHBhcnRpY3VsYXIN
Cjx1PjwvdT48dT48L3U+PC9wPjxwPnRvIGluZGl2aWR1YWwgcmVzZXJ2ZWQgY2xhaW1zLCBidXQg
YWxsIHJlc2VydmVkIGNsYWltcyBhcmUgb3B0aW9uYWwuIFRodXMgYW4NCjx1PjwvdT48dT48L3U+
PC9wPjxwPmFwcGxpY2F0aW9uIG9mIEpXVHMgdG8gdXNlIGNhc2VzIGFsc28gYXByb3BvcyBmb3Ig
U0FNTCBhc3NlcnRpb25zIHdpbGwgcmVxdWlyZQ0KPHU+PC91Pjx1PjwvdT48L3A+PHA+YXJndWFi
bHkgbW9yZSBwcm9maWxpbmcgdGhhbiB0aGF0IG5lZWRlZCB0byBhcHBseSBTQU1MIGFzc2VydGlv
bnMuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj48
cD48c3BhbiBzdHlsZT0iY29sb3I6IzAwYjA1MCI+QWxsIHRydWUuJm5ic3A7IEhvd2V2ZXIgb25j
ZSB5b3UgYWRkIGFuIGlzc3VlciBhbmQgYSBwcmluY2lwYWwsIHRoZW4geW914oCZcmUgYmFjayB0
byB0aGUgSldUIGJlaW5nIHN0YXRlbWVudHMgbWFkZSBieSBhbiBlbnRpdHkgYWJvdXQgYSBzdWJq
ZWN0LiZuYnNwOyBBZ2FpbiwgaWYgdGhlcmUgaXMgbGFuZ3VhZ2UgeW91IGJlbGlldmUgc2hvdWxk
IGJlIGFkZGVkIGluIHRoYXQgcmVnYXJkLA0KIHBsZWFzZSBsZXQgbWUga25vdy4mbmJzcDsgKEJU
Vywgb25lIHN1Y2ggdXNhZ2UgcHJvZmlsZSBpcyBpbiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWp3dC1iZWFyZXItMDMiIHRhcmdldD0iX2JsYW5r
Ij4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb2F1dGgtand0LWJlYXJl
ci0wMzwvYT4uJm5ic3A7IEFub3RoZXIgaXMgaW4gPGEgaHJlZj0iaHR0cDovL29wZW5pZC5uZXQv
c3BlY3Mvb3BlbmlkLWNvbm5lY3QtbWVzc2FnZXMtMV8wLmh0bWwjaWRfdG9rZW4iIHRhcmdldD0i
X2JsYW5rIj4NCmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LW1lc3NhZ2Vz
LTFfMC5odG1sI2lkX3Rva2VuPC9hPi4pPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxkaXYgY2xh
c3M9ImltIj48cD48c3BhbiBzdHlsZT0iIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+
PHA+VGhlIHRva2VuIHNpemUgJmFtcDsgY29tcGxleGl0eSBjb21wYXJpc29uIHNlZW1zIG5vbWlu
YWxseSBmaW5lLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxw
PlNvbWUgZGV0YWlsZWQtYnV0LXJvdWdoIGNvbW1lbnRzIGFuZCBtdXNpbmdzIG9uIHBvcnRpb25z
IG9mIHRoZSBzcGVjIGFzIEkgd2FzDQo8dT48L3U+PHU+PC91PjwvcD48cD5yZWFkaW5nIHRocm91
Z2ggaXQuLi48dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD4m
Z3Q7IDIuIFRlcm1pbm9sb2d5PHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1Pjwv
dT48L3A+PHA+dGVybWlub2xvZ3kgaXMgbm90IGFscGhhYmV0aXNlZCE8dT48L3U+PHU+PC91Pjwv
cD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2PjxwPjxzcGFuIHN0eWxlPSJjb2xv
cjojMDBiMDUwIj5ObywgaXTigJlzIGluIGEgdG9wLWRvd24gZGVzY3JpcHRpdmUgb3JkZXIuJm5i
c3A7IElzIHRoZXJlIGEgcmVxdWlyZW1lbnQgaW4gSUVURiBzcGVjcyB0aGF0IHRoZSB0ZXJtaW5v
bG9neSBiZSBhbHBoYWJldGl6ZWQ/PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxkaXYgY2xhc3M9
ImltIj48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD4NCiJjbGFpbSIsICJjbGFpbXMiLCAi
dG9rZW4iIHNob3VsZCBiZSBkZWZpbmVkIGluIHRlcm1pbm9sb2d5PHU+PC91Pjx1PjwvdT48L3A+
PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj48cD48c3BhbiBzdHlsZT0iY29sb3I6
IzAwYjA1MCI+SeKAmWxsIGFkZCBhIGRlZmluaXRpb24gZm9yIOKAnGNsYWlt4oCdLiZuYnNwOyDi
gJx0b2tlbuKAnSBzaG91bGQgYWN0dWFsbHkgcHJvYmFibHkgYmVjb21lIOKAnHNlY3VyaXR5IHRv
a2Vu4oCdLCB3aXRoIGEgZGVmaW5pdGlvbiBvZiB0aGUgdGVybS48dT48L3U+PHU+PC91Pjwvc3Bh
bj48L3A+PGRpdiBjbGFzcz0iaW0iPjxwPjxzcGFuIHN0eWxlPSIiPjx1PjwvdT4mbmJzcDs8dT48
L3U+PC9zcGFuPjwvcD48cD5zdWdnZXN0aW9uOjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4m
bmJzcDs8dT48L3U+PC9wPjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBDbGFpbTom
bmJzcDsgYW4gYXNzZXJ0aW9uIG9mIHNvbWV0aGluZyBhcyBhIGZhY3QuIEhlcmUsIGNsYWltcyBh
cmU8dT48L3U+PHU+PC91PjwvcD48cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgbmFtZSBhbmQgdmFsdWUgcGFpcnMsIGNvbnNpc3Rpbmcgb2YgYSBDbGFp
bSBOYW1lIGFuZCBhPHU+PC91Pjx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IENsYWltIFZhbHVlLjx1PjwvdT48dT48L3U+PC9wPjxw
Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPiZn
dDsmbmJzcDsmbmJzcDsmbmJzcDsgSlNPTiBXZWIgVG9rZW4gKEpXVCk8dT48L3U+PHU+PC91Pjwv
cD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD4mbmJzcDsmbmJzcDsgaXMgand0IGFsd2F5
cyBhICJzdHJpbmciIG9yIGlzIGl0IHN0cmluZyAob25seSkgd2hlbiBpdCdzIGJlZW4gc2VyaWFs
aXplZA0KPHU+PC91Pjx1PjwvdT48L3A+PHA+aW50byBvbmU/PHU+PC91Pjx1PjwvdT48L3A+PHA+
PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj48cD48c3BhbiBzdHlsZT0iY29sb3I6IzAw
YjA1MCI+SXTigJlzIGFsd2F5cyB0aGUgc3RyaW5nIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBzZXJp
YWxpemVkIHBhcnRzLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+
PHNwYW4gc3R5bGU9IiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPjxwPiZndDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQSBz
dHJpbmcgcmVwcmVzZW50aW5nIGEgc2V0IG9mIGNsYWltcyBhcyBhIEpTT048dT48L3U+PHU+PC91
PjwvcD48cD4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9iamVjdCB0
aGF0IGlzIGRpZ2l0YWxseSBzaWduZWQgb3IgTUFDZWQgYW5kL29yIGVuY3J5cHRlZC48dT48L3U+
PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD4mbmJzcDsmbmJzcDsgaXMg
aXQgbW9yZSB0aGF0IGl0J3MgYSBzZXQgb2YgY2xhaW1zIGVuY29kZWQgYXMgYSBKU09OIG9iamVj
dDx1PjwvdT48dT48L3U+PC9wPjxwPiZuYnNwOyZuYnNwOyB0aGF0IGlzIHN0cmluZy1zZXJpYWxp
emVkPzx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+
PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAiPk5vLCBwZXIgbXkgZWFybGllciBjb21tZW50
cyA8dT48L3U+DQo8dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHNwYW4gc3R5
bGU9IiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPjxwPiZuYnNwOyZuYnNwOyBpcyBp
dCAvbm90LyBhIEpXVCBieSBkZWZpbml0aW9uIGlmIGl0IGlzIG5vdCAoKHNpZ25lZCBvciB1bm1h
YydkKSBhbmQvb3INCjx1PjwvdT48dT48L3U+PC9wPjxwPmVuY3J5cHRlZCkgPyZuYnNwOyZuYnNw
OyBObywgYmVjYXVzZSB0aGVyZSBhcmUgUGxhaW50ZXh0IEpXVHMsIGJ1dCB0aGV5IGFyZW4ndCBp
bg0KPHU+PC91Pjx1PjwvdT48L3A+PHA+dGVybWlub2xvZ3kgKHByb2JhYmx5IHNob3VsZCBiZSku
PHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj48cD48
c3BhbiBzdHlsZT0iY29sb3I6IzAwYjA1MCI+R29vZCBjYXRjaDx1PjwvdT48dT48L3U+PC9zcGFu
PjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHNwYW4gc3R5bGU9IiI+PHU+PC91PiZuYnNwOzx1Pjwv
dT48L3NwYW4+PC9wPjxwPiZuYnNwOyZuYnNwOyAicGFydHMiIGluIEpXVCBkZWZpbml0aW9uIGlz
IHVuY2xlYXI8dT48L3U+PHU+PC91PjwvcD48cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJl
ICJwYXJ0cyIganNvbiBvYmplY3RzIG9yIGFycmF5cyB1bnRvIHRoZW1zZWx2ZXMgPzx1PjwvdT48
dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+PHA+PHNwYW4gc3R5
bGU9ImNvbG9yOiMwMGIwNTAiPlRoZSBwYXJ0cyBhcmUgYWxsIGJhc2U2NHVybCBlbmNvZGVkIHZh
bHVlcy4mbmJzcDsgSeKAmWxsIHJldmlldyB0aGlzIHRlcm1pbm9sb2d5IHVzYWdlIHRvIHNlZSBp
ZiBpdCBjYW4gYmUgY2xhcmlmaWVkLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNz
PSJpbSI+PHA+PHNwYW4gc3R5bGU9IiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPjxw
PiZuYnNwOyZuYnNwOyB0aGUgZGVmaW5pdGlvbiBhc3N1bWVzIGtub3dsZWRnZSB0aGF0J3MgcHJl
c2VudGVkIGxhdGVyLiBwZXJoYXBzIG5lZWRzIGZ3ZDx1PjwvdT48dT48L3U+PC9wPjxwPiZuYnNw
OyZuYnNwOyByZWZlcmVuY2UocyksIG9yIHBlcmhhcHMgYmV0dGVyIGlzIHRvIG5vdCBwcmVzZW50
IGFzIG11Y2ggdGVjaG5pY2FsIGRldGFpbDx1PjwvdT48dT48L3U+PC9wPjxwPiZuYnNwOyZuYnNw
OyBpbiB0aGUgZGVmaW5pdGlvbnMuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1
PjwvdT48L3A+DQo8L2Rpdj48cD48c3BhbiBzdHlsZT0iY29sb3I6IzAwYjA1MCI+SeKAmWxsIHJl
dmlldzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHU+PC91PiZu
YnNwOzx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBKV1QgQ2xhaW1zIFNldDx1
PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPiZuYnNwOyZuYnNw
OyBzaW1pbGFyIGNvbW1lbnRzIGFzIHRvIEpTT04gV2ViIFRva2VuIChKV1QpPHU+PC91Pjx1Pjwv
dT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7IHRoZSBkZWZp
bml0aW9uIHNheXMgaG93IGl0IGlzIGVuY29kZWQgYW5kIGVuY3J5cHRlZCwgYnV0IG5vdCBob3cg
Y2xhaW1zIGFyZQ0KPHU+PC91Pjx1PjwvdT48L3A+PHA+bWFwcGVkIGludG8gYSBKU09OIG9iamVj
dDx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPjx1PjwvdT4m
bmJzcDs8dT48L3U+PC9wPjxwPnNob3VsZCBwcm9iYWJseSBiZSBzaW1wbHk6PHU+PC91Pjx1Pjwv
dT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEpX
VCBDbGFpbXMgU2V0OiBBIHNldCBvZiBjbGFpbXMgZXhwcmVzc2VkIGFzIGEgSlNPTiBvYmplY3Qs
IHdoZXJlIGVhY2g8dT48L3U+PHU+PC91PjwvcD48cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgY2xhaW0gaXMgYW4gb2JqZWN0IG1lbWJlciAoaS5lLiwgYSBuYW1lL3ZhbHVl
IHBhaXIpLiBBIGNsYWltIG1heSBoYXZlPHU+PC91Pjx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgSldUIENsYWltcyBTZXQgYXMgYSB2YWx1ZS48dT48
L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2PjxwPjxzcGFu
IHN0eWxlPSJjb2xvcjojMDBiMDUwIj5J4oCZbGwgbG9vayBpbnRvIG1vdmluZyB0aGUgZGVmaW5p
dGlvbiBpbiB0aGlzIGRpcmVjdGlvbi4mbmJzcDsgV2hhdCB5b3XigJlyZSBtaXNzaW5nIGluIHRo
ZSBhYm92ZSwgdGhvdWdoLCBpcyB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiB0aGUgc3RyaW5nIHJl
cHJlc2VudGluZyB0aGUgSlNPTiBvYmplY3QgYW5kIHRoZSBhYnN0cmFjdCBKU09OIG9iamVjdC4m
bmJzcDsgV2Ugd2FudA0KIHRoZSBmb3JtZXIuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPjxkaXYg
Y2xhc3M9ImltIj48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD4mZ3Q7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IENsYWltIE5hbWUmbmJzcDsgVGhlIG5hbWUgb2YgYSBtZW1iZXIgb2YgdGhlIEpTT04g
b2JqZWN0IHJlcHJlc2VudGluZyBhPHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBKV1QgQ2xhaW1zIFNldC48dT48L3U+PHU+PC91Pjwv
cD48cD4NCjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPnNob3VsZCBwcm9iYWJseSBiZSBzaW1w
bHk6PHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+Jm5ic3A7
Jm5ic3A7Jm5ic3A7IENsYWltIE5hbWUmbmJzcDsgVGhlIG5hbWUgcG9ydGlvbiBvZiBhIGNsYWlt
LCBleHByZXNzZWQgYXMgYSBKU09OIG9iamVjdCBtZW1iZXI8dT48L3U+PHU+PC91PjwvcD48cD4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbmFtZS48dT48L3U+PHU+PC91Pjwv
cD48cD4NCjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9w
PjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2xhaW0gVmFsdWUmbmJzcDsgVGhlIHZhbHVlIG9m
IGEgbWVtYmVyIG9mIHRoZSBKU09OIG9iamVjdCByZXByZXNlbnRpbmcgYTx1PjwvdT48dT48L3U+
PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSldUIENsYWlt
cyBTZXQuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+c2hv
dWxkIHByb2JhYmx5IGJlIHNpbXBseTo8dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7
PHU+PC91PjwvcD48cD4mbmJzcDsmbmJzcDsmbmJzcDsgQ2xhaW0gVmFsdWUmbmJzcDsgVGhlIHZh
bHVlIHBvcnRpb24gb2YgYSBjbGFpbSwgZXhwcmVzc2VkIGFzIGEgSlNPTiBvYmplY3QgbWVtYmVy
PHU+PC91Pjx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHZhbHVlLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9k
aXY+PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAiPknigJlsbCBsb29rIGludG8gbW92aW5n
IHRoZSBkZWZpbml0aW9ucyBpbiB0aGlzIGRpcmVjdGlvbi4mbmJzcDsNCjx1PjwvdT48dT48L3U+
PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+
Jmd0OyAzLiBKU09OIFdlYiBUb2tlbiAoSldUKSBPdmVydmlldzx1PjwvdT48dT48L3U+PC9wPjxw
Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGJ5
dGVzIG9mIHRoZSBVVEYtOCByZXByZXNlbnRhdGlvbiBvZiB0aGUgSldUIENsYWltcyBTZXQgYXJl
PHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBkaWdpdGFsbHkgc2ln
bmVkIG9yIE1BQ2VkIGluIHRoZSBtYW5uZXIgZGVzY3JpYmVkIGluIEpTT04gV2ViPHU+PC91Pjx1
PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBTaWduYXR1cmUgKEpXUykgW0pXU10g
YW5kL29yIGVuY3J5cHRlZCBpbiB0aGUgbWFubmVyIGRlc2NyaWJlZCBpbjx1PjwvdT48dT48L3U+
PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSlNPTiBXZWIgRW5jcnlwdGlvbiAoSldFKSBb
SldFXS48dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD5zLyBh
bmQvb3IgZW5jcnlwdGVkIC8gb3IgZW5jcnlwdGVkIGFuZCBzaWduZWQgLzx1PjwvdT48dT48L3U+
PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+PHA+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMGIwNTAiPkkgdGhpbmsgeW91IG1lYW4g4oCcZW5jcnlwdGVkIGFuZCBpbnRlZ3JpdHkg
cHJvdGVjdGVk4oCdIHJhdGhlciB0aGFuIOKAnGVuY3J5cHRlZCBhbmQgc2lnbmVk4oCdLCByaWdo
dD88dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PGRpdiBjbGFzcz0iaW0iPjxwPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGNvbnRlbnRzIG9mIHRo
ZSBKV1QgSGVhZGVyIGRlc2NyaWJlIHRoZSBjcnlwdG9ncmFwaGljIG9wZXJhdGlvbnM8dT48L3U+
PHU+PC91PjwvcD48cD4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGFwcGxpZWQgdG8gdGhlIEpXVCBD
bGFpbXMgU2V0LiBJZiB0aGUgSldUIEhlYWRlciBpcyBhIEpXUyBIZWFkZXIsIHRoZTx1PjwvdT48
dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xhaW1zIGFyZSBkaWdpdGFsbHkg
c2lnbmVkIG9yIE1BQ2VkLiZuYnNwOyBJZiB0aGUgSldUIEhlYWRlciBpcyBhIEpXRTx1PjwvdT48
dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgSGVhZGVyLCB0aGUgY2xhaW1zIGFy
ZSBlbmNyeXB0ZWQuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+
PHA+V2hhdCBpZiBhIEpXVCBpcyBzaWduZWQgQU5EIGVuY3J5cHRlZD8mbmJzcDsgSG0sIGZyb20g
bXkgbG9va2luZyBhdCBKV1MgYW5kIEpXRQ0KPHU+PC91Pjx1PjwvdT48L3A+PHA+c3BlY3MsIGl0
IHNlZW1zIHRoYXQgaW4gdGhhdCBjYXNlIG9uZSB1c2VzIEpXRSBiZWNhdXNlIHRoYXQgZW5jb21w
YXNzZXMgYm90aA0KPHU+PC91Pjx1PjwvdT48L3A+PHA+ZW5jcnlwdCAmYW1wOyBzaWduLjx1Pjwv
dT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+PHA+PHNwYW4g
c3R5bGU9ImNvbG9yOiMwMGIwNTAiPk5vLCBhY3R1YWxseSBKV0UganVzdCBwcm92aWRlcyBhbiBp
bnRlZ3JpdHkgY2hlY2sg4oCTIG5vdCBhIHNpZ25hdHVyZS4mbmJzcDsgSWYgeW91IHdhbnQgYSBz
aWduYXR1cmUsIHlvdSBuZWVkIHRvIHVzZSBKV1MuJm5ic3A7IFRoZXkgY2FuIChhbmQgb2Z0ZW4g
YXJlKSB1c2VkIGluIGEgbmVzdGVkIGZhc2hpb24uPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K
DQo8ZGl2IGNsYXNzPSJpbSI+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+Jmd0OyZuYnNw
OyZuYnNwOyZuYnNwOyBBIEpXVCBpcyByZXByZXNlbnRlZCBhcyBhIEpXUyBvciBKV0UuJm5ic3A7
IFRoZSBudW1iZXIgb2YgcGFydHMgaXM8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IGRlcGVuZGVudCB1cG9uIHRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgcmVzdWx0
aW5nIEpXUyBvciBKV0UuPHU+PC91Pjx1PjwvdT48L3A+PHA+DQo8dT48L3U+Jm5ic3A7PHU+PC91
PjwvcD48cD5Eb2VzIHRoZSBhYm92ZSBtZWFuIHRvIHNheS4uPHU+PC91Pjx1PjwvdT48L3A+PHA+
PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEEgSldUIGNvbnNp
c3RzIG9mIGEgSldTIG9yIEpXRSBvYmplY3QsIHdoaWNoIGluIHR1cm4gY29udmV5cyB0aGUgSldU
PHU+PC91Pjx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7IENsYWltcyBTZXQuIEluIHRo
ZSBjYXNlIG9mIGEgSldTLCB0aGUgSldUIENsYWltcyBTZXQgaXMgdGhlIEpXUzx1PjwvdT48dT48
L3U+PC9wPjxwPiZuYnNwOyZuYnNwOyZuYnNwOyBQYXlsb2FkLiBJbiB0aGUgY2FzZSBvZiBhIEpX
RSwgdGhlIEpXVCBDbGFpbXMgU2V0IGlzIHRoZSBpbnB1dDx1PjwvdT48dT48L3U+PC9wPjxwPiZu
YnNwOyZuYnNwOyZuYnNwOyBQbGFpbnRleHQuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZu
YnNwOzx1PjwvdT48L3A+DQo8L2Rpdj48cD48c3BhbiBzdHlsZT0iY29sb3I6IzAwYjA1MCI+WWVz
LiZuYnNwOyBBbHRob3VnaCB0aGlzIGlzIG1pc3NpbmcgdGhlIGZhY3QgdGhhdCBuZXN0ZWQgc2ln
bmluZy9lbmNyeXB0aW9uIG1heSBiZSBlbXBsb3llZC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+
PGRpdiBjbGFzcz0iaW0iPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPiZndDsgNC4gSldU
IENsYWltczx1PjwvdT48dT48L3U+PC9wPjxwPiZndDs8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7
PHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgSldUIENsYWlt
cyBTZXQgcmVwcmVzZW50cyBhIEpTT04gb2JqZWN0IHdob3NlIG1lbWJlcnMgYXJlIHRoZTx1Pjwv
dT48dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgY2xhaW1zIGNvbnZleWVkIGJ5
IHRoZSBKV1QuJm5ic3A7IFRoZSBDbGFpbSBOYW1lcyB3aXRoaW4gdGhpcyBvYmplY3QgTVVTVDx1
PjwvdT48dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgdW5pcXVlOyBKV1Rz
IHdpdGggZHVwbGljYXRlIENsYWltIE5hbWVzIE1VU1QgYmUgcmVqZWN0ZWQuPHU+PC91Pjx1Pjwv
dT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+ZG9lcyB0aGUgYWJvdmUgbWVhbiB0
byBzYXkgY2xhaW0gbmFtZXMgbXVzdCBiZSB1bmlxdWUgYW1vbmdzdCB0aGUgc2V0IG9mIGNsYWlt
DQo8dT48L3U+PHU+PC91PjwvcD48cD5uYW1lcyB3aXRoaW4gYW55IGdpdmVuIEpXVCBDbGFpbXMg
U2V0ID8mbmJzcDsgSWYgc28sIHRoYXQncyBvbmx5IGltcGxpZWQgYnkgdGhlIGFib3ZlDQo8dT48
L3U+PHU+PC91PjwvcD48cD5idXQgc2hvdWxkIGJlIHN0YXRlZCBleHBsaWNpdGx5OyBhcyBpdCBp
cywgdGhlIGFib3ZlIGlzIGFtYmlndW91cy48dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5i
c3A7PHU+PC91PjwvcD4NCjwvZGl2PjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBiMDUwIj5PSzx1
PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHU+PC91PiZuYnNwOzx1
PjwvdT48L3A+PHA+Jmd0OyA0LjIuIFB1YmxpYyBDbGFpbSBOYW1lczx1PjwvdT48dT48L3U+PC9w
PjxwPiZndDs8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7PHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0
OyZuYnNwOyZuYnNwOyZuYnNwOyBDbGFpbSBuYW1lcyBjYW4gYmUgZGVmaW5lZCBhdCB3aWxsIGJ5
IHRob3NlIHVzaW5nIEpXVHMuJm5ic3A7IEhvd2V2ZXIsIGluPHU+PC91Pjx1PjwvdT48L3A+PHA+
PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+cy9DbGFpbSBuYW1lcy9QdWJsaWMgY2xhaW0gbmFt
ZXMvPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+Jmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyBvcmRlciB0byBwcmV2ZW50IGNvbGxpc2lvbnMsIGFueSBuZXcgY2xh
aW0gbmFtZSBTSE9VTEQgZWl0aGVyIGJlPHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZu
YnNwOyZuYnNwOyByZWdpc3RlcmVkIGluIHRoZSBJQU5BIEpTT04gV2ViIFRva2VuIENsYWltcyBy
ZWdpc3RyeSBTZWN0aW9uIDkuMSBvcjx1PjwvdT48dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJz
cDsmbmJzcDsgYmUgYSBVUkkgdGhhdCBjb250YWlucyBhIENvbGxpc2lvbiBSZXNpc3RhbnQgTmFt
ZXNwYWNlLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPjx1
PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPndoeSBzaG91bGQgYSBjbGFpbSBuYW1lIGJlIGEgVVJJ
IGlmIEkgd2lzaCB0byBtYWtlIHVzZSBvZiBDb2xsaXNpb24gUmVzaXN0YW50DQo8dT48L3U+PHU+
PC91PjwvcD48cD5OYW1lc3BhY2VzPyZuYnNwOyBGb3IgZXhhbXBsZSwgaWYgSSBzaW1wbHkgdXNl
IHNheSBVVUlEcyBhcyBjbGFpbSBuYW1lcy4uPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZu
YnNwOzx1PjwvdT48L3A+PHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHsiaXNzIjoi
am9lIiw8dT48L3U+PHU+PC91PjwvcD48cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgIjMwMDVmYTA1LWU3NmMtNDk5NC1iYmM5LTY1YjJhY2UyMzA1YyI6ImZvbyJ9PHU+PC91
Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+Li5pdCB3aWxsIGJlIHVu
aXZlcnNhbGx5IHVuaXF1ZSBwcm92aWRlZCBJIG1pbnRlZCBpdCBhcHByb3ByaWF0ZWx5IChubyBV
UkkNCjx1PjwvdT48dT48L3U+PC9wPjxwPnN5bnRheCBpcyBuZWVkZWQpLjx1PjwvdT48dT48L3U+
PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+PHA+PHNwYW4gc3R5bGU9ImNv
bG9yOiMwMGIwNTAiPkZhaXIgZW5vdWdoLiZuYnNwOyBJ4oCZbGwgdHJ5IHRvIGdlbmVyYWxpemUg
dGhlIGxhbmd1YWdlLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+
PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwv
cD48cD4mZ3Q7IDQuMy4gUHJpdmF0ZSBDbGFpbSBOYW1lczx1PjwvdT48dT48L3U+PC9wPjxwPiZn
dDs8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7PHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNw
OyZuYnNwOyZuYnNwOyBBIHByb2R1Y2VyIGFuZCBjb25zdW1lciBvZiBhIEpXVCBtYXkgYWdyZWUg
dG8gYW55IGNsYWltIG5hbWUgdGhhdCBpczx1PjwvdT48dT48L3U+PC9wPjxwPiZndDsmbmJzcDsm
bmJzcDsmbmJzcDsgbm90IGEgUmVzZXJ2ZWQgTmFtZSBTZWN0aW9uIDQuMSBvciBhIFB1YmxpYyBO
YW1lIFNlY3Rpb24gNC4yLiZuYnNwOyBVbmxpa2U8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IFB1YmxpYyBOYW1lcywgdGhlc2UgcHJpdmF0ZSBuYW1lcyBhcmUgc3Vi
amVjdCB0byBjb2xsaXNpb24gYW5kIHNob3VsZDx1PjwvdT48dT48L3U+PC9wPjxwPiZndDsmbmJz
cDsmbmJzcDsmbmJzcDsgYmUgdXNlZCB3aXRoIGNhdXRpb24uPHU+PC91Pjx1PjwvdT48L3A+PHA+
PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+aXQgc2VlbXMgcHJpdmF0ZSBjbGFpbSBuYW1lcyBh
cmUgb25seSBzdWJqZWN0IHRvIGNvbGxpc2lvbiBpZiB0aGUgaW1wbGVtZW50ZXJzDQo8dT48L3U+
PHU+PC91PjwvcD48cD5kb24ndCBtYWtlIGFwcHJvcHJpYXRlIHVzZSBvZiBDb2xsaXNpb24gUmVz
aXN0YW50IE5hbWVzcGFjZXMsIGkuZS4gdGhleSAiY2FuIGJlIg0KPHU+PC91Pjx1PjwvdT48L3A+
PHA+c3ViamVjdCB0byBjb2xsaXNpb24uPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNw
Ozx1PjwvdT48L3A+DQo8L2Rpdj48cD48c3BhbiBzdHlsZT0iY29sb3I6IzAwYjA1MCI+VHJ1ZTx1
PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHU+PC91PiZuYnNwOzx1
PjwvdT48L3A+PHA+dGhlIGFib3ZlIHR3byBzZWN0aW9ucyB1c2UgInB1YmxpYyIgYW5kICJwcml2
YXRlIiBhcyBkaXN0aW5ndWlzaGluZyBmYWN0b3JzLCBidXQNCjx1PjwvdT48dT48L3U+PC9wPjxw
Pml0IHNlZW1zIHRvIG1lIHRoZSBkaXN0aW5ndWlzaGluZyBmYWN0b3IgKGdpdmVuIGhvdyB0aGUg
YWJvdmUgaXMgd3JpdHRlbikgaXMNCjx1PjwvdT48dT48L3U+PC9wPjxwPm1vcmUgd2hldGhlciBD
b2xsaXNpb24gUmVzaXN0YW50IE5hbWVzcGFjZXMgYXJlIGVtcGxveWVkIG9yIG5vdC48dT48L3U+
PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2PjxwPjxzcGFuIHN0
eWxlPSJjb2xvcjojMDBiMDUwIj5ZZXMsIGFsdGhvdWdoIHVzaW5nIGEgY29sbGlzaW9uIHJlc2lz
dGFudCBuYW1lc3BhY2UgZWZmZWN0aXZlbHkgbWFrZXMgdGhlbSBwdWJsaWMsIGFzIHdl4oCZcmUg
dXNpbmcgdGhlIHRlcm08dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PGRpdiBjbGFzcz0iaW0iPjxw
PjxzcGFuIHN0eWxlPSIiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD48cD5BbiBpbXBs
aWVkIGFzcGVjdCBvZiBwdWJsaWMgY2xhaW0gbmFtZXMgc2VlbXMgdG8gYmUgdGhhdCBpdCBpcyBh
c3N1bWVkIHRoYXQgdGhleQ0KPHU+PC91Pjx1PjwvdT48L3A+PHA+YXJlIHB1YmxpY2x5IGxpc3Rl
ZC9kb2N1bWVudGVkL2xlYWtlZCwgdGh1cyB0aGUgInB1YmxpYyIgbW9uaWtlciwgYW5kIGhlbmNl
DQo8dT48L3U+PHU+PC91PjwvcD48cD5vdWdodCB0byBiZSB1bml2ZXJzYWxseSB1bmlxdWUgYXMg
YSBtYXR0ZXIgb2YgY291cnNlLjx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48
L3U+PC9wPjxwPmFuZCAicHJpdmF0ZSIgb25lcyBzZWVtIHRvIGJlIGFzc3VtZWQgdG8gYmUgb2Jm
dXNjYXRlZCB0byBhbGwgYnV0IHRoZSBhZ3JlZWluZw0KPHU+PC91Pjx1PjwvdT48L3A+PHA+cGFy
dGllcz8mbmJzcDsgT3IgdGhleSBhcmUgInByaXZhdGUiIGluIG9ubHkgdGhlIHNlbnNlIHRoYXQg
dGhleSBhcmUgY3JlYXRlZCBpbiB0aGUNCjx1PjwvdT48dT48L3U+PC9wPjxwPmNvbnRleHQgb2Yg
YSBwcml2YXRlIGFycmFuZ2VtZW50Pzx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8
dT48L3U+PC9wPg0KPC9kaXY+PHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAiPlByaXZhdGUg
aW4gdGhhdCB0aGV5IGFyZSBjcmVhdGVkIGluIHRoZSBjb250ZXh0IG9mIGEgcHJpdmF0ZSBhcnJh
bmdlbWVudC4mbmJzcDsgSeKAmWxsIHRyeSB0byBjbGFyaWZ5IHRoaXMgcG9pbnQuJm5ic3A7IEZh
Y2Vib29rIGNvdWxkIGRlZmluZSBob3cgdGhleeKAmXJlIGdvaW5nIHRvIHVzZSB0aGUg4oCcaWTi
gJ0gY2xhaW0gdmVyeSBwdWJsaWNseSwgYW5kIHlldCBpdCB3b3VsZCBzdGlsbA0KIGJlIGEgcHJp
dmF0ZSBjbGFpbSBpZiBub3QgcmVnaXN0ZXJlZCB3aXRoIElBTkEuPHU+PC91Pjx1PjwvdT48L3Nw
YW4+PC9wPjxkaXYgY2xhc3M9ImltIj48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD4mZ3Q7
PHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyA3LiBSdWxlcyBmb3IgQ3JlYXRpbmcgYW5kIFZhbGlk
YXRpbmcgYSBKV1Q8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7PHU+PC91Pjx1PjwvdT48L3A+PHA+
Jmd0Ozx1PjwvdT48dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVG8gY3JlYXRl
IGEgSldULCBvbmUgTVVTVCBwZXJmb3JtIHRoZXNlIHN0ZXBzLiZuYnNwOyBUaGUgb3JkZXIgb2Yg
dGhlPHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBzdGVwcyBpcyBu
b3Qgc2lnbmlmaWNhbnQgaW4gY2FzZXMgd2hlcmUgdGhlcmUgYXJlIG5vIGRlcGVuZGVuY2llczx1
PjwvdT48dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYmV0d2VlbiB0aGUgaW5w
dXRzIGFuZCBvdXRwdXRzIG9mIHRoZSBzdGVwcy48dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7PHU+
PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAxLiZuYnNwOyBDcmVhdGUg
YSBKV1QgQ2xhaW1zIFNldCBjb250YWluaW5nIHRoZSBkZXNpcmVkIGNsYWltcy4mbmJzcDsgTm90
ZSB0aGF0PHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB3aGl0ZSBzcGFjZSBpcyBleHBsaWNpdGx5IGFsbG93ZWQgaW4gdGhl
IHJlcHJlc2VudGF0aW9uIGFuZCBubzx1PjwvdT48dT48L3U+PC9wPjxwPg0KJmd0OyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjYW5vbmljYWxpemF0aW9uIGlzIHBl
cmZvcm1lZCBiZWZvcmUgZW5jb2RpbmcuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNw
Ozx1PjwvdT48L3A+PHA+SSBwcmVzdW1lIHRoZSByYXRpb25hbGUgZm9yIGFsbG93aW5nIHdoaXRl
IHNwYWNlIGlzIHRoYXQgSlNPTiBvYmplY3RzIGFyZQ0KPHU+PC91Pjx1PjwvdT48L3A+PHA+dW5v
cmRlcmVkIChhbmQgY2FuIGNvbnRhaW4gYXJiaXRyYXJ5IHdoaXRlc3BhY2UpLCB0aHVzIHNpbXBs
ZSBidWZmZXItdG8tYnVmZmVyDQo8dT48L3U+PHU+PC91PjwvcD48cD5jb21wYXJpc29ucyBiZXR3
ZWVuIHNlcmlhbGl6ZWQgb2JqZWN0cyBjYW5ub3QgYmUgcmVsaWFibHkgcGVyZm9ybWVkLiZuYnNw
OyBJZiBzbyB0aGlzDQo8dT48L3U+PHU+PC91PjwvcD48cD5zaG91bGQgYmUgZXhwbGljaXRseSBz
dGF0ZWQuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rp
dj48cD48c3BhbiBzdHlsZT0iY29sb3I6IzAwYjA1MCI+QWN0dWFsbHksIGl04oCZcyB0byBhdm9p
ZCBjYW5vbmljYWxpemF0aW9uLiZuYnNwOyBJ4oCZbGwgcmVyZWFkIHRoZSBzcGVjIHRvIHNlZSBp
ZiB3ZeKAmXZlIHN0YXRlZCB0aGF0IGNsZWFybHkgb3Igbm90Ljx1PjwvdT48dT48L3U+PC9zcGFu
PjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHNwYW4gc3R5bGU9IiI+PHU+PC91PiZuYnNwOzx1Pjwv
dT48L3NwYW4+PC9wPjxwPkl0IHNlZW1zIHRoYXQgbWVtYmVyL3ZhbHVlLWJ5LW1lbWJlci92YWx1
ZSBjb21wYXJpc29ucyBtdXN0IGFsd2F5cyBiZSBkb25lLCBieQ0KPHU+PC91Pjx1PjwvdT48L3A+
PHA+cGFyc2luZyB0aGUgSlNPTiBvYmplY3RzIGFuZCBleHRyYWN0aW5nIGFsbCBtZW1iZXJzIGFu
ZCB2YWx1ZXMsIHRoaXMgc2hvdWxkIGJlDQo8dT48L3U+PHU+PC91PjwvcD48cD5zdGF0ZWQgZXhw
bGljaXRseSBpbiB0aGUgc3BlYy48dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+
PC91PjwvcD48cD5JIGZvdW5kIG1lYWdlciBqd3QgY29tcGFyaXNvbiBpbnN0cnVjdGlvbnMgYXQg
dGhlIHZlcnkgZW5kIG9mIFNlY3Rpb24gNy4gaXQNCjx1PjwvdT48dT48L3U+PC9wPjxwPnNob3Vs
ZCBwcm9iYWJseSBiZSBpdHMgb3duIHN1YnNlY3Rpb24uIEl0IHNob3VsZCBwcm9iYWJseSBleHBs
aWNpdGx5IHNheSB0aGF0DQo8dT48L3U+PHU+PC91PjwvcD48cD5KV1RzIG5lZWQgdG8gYmUgcGFy
c2VkIGludG8gdGhlaXIgY29uc3RpdHVlbnQgY29tcG9uZW50cywgYW5kIHRoZSBsYXR0ZXIgbXVz
dCBiZQ0KPHU+PC91Pjx1PjwvdT48L3A+PHA+aW5kaXZpZHVhbGx5IGV4YW1pbmVkL2NvbXBhcmVk
Ljx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPC9kaXY+PHA+
PHNwYW4gc3R5bGU9ImNvbG9yOiMwMGIwNTAiPldlIHRyaWVkIHRvIGNvdmVyIHRoaXMgaW4gdGhl
IGVuZCBvZiBzZWN0aW9uIDcsIHN0YXJ0aW5nIHdpdGggdGhlIHNlbnRlbmNlIOKAnFByb2Nlc3Np
bmcgYSBKV1QgaW5ldml0YWJseSByZXF1aXJlcyBjb21wYXJpbmcga25vd24gc3RyaW5ncyB0byB2
YWx1ZXMgaW4gdGhlIHRva2Vu4oCdLCB3aGljaCBzYXlzIGhvdyB0aGVzZSBjb21wYXJpc29ucyBt
dXN0IGJlIHBlcmZvcm1lZC4mbmJzcDsNCiBJIGFncmVlIHRoYXQgdGhpcyBzaG91bGQgYmVjb21l
IGl0cyBvd24gc3Vic2VjdGlvbi4mbmJzcDsgSSBkb27igJl0IHVuZGVyc3RhbmQgeW91ciByZW1h
cmsgYWJvdXQgY29uc3RpdHVlbnQgY29tcG9uZW50cy4mbmJzcDsgQ2FuIHlvdSBjbGFyaWZ5Pzx1
PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHNwYW4gc3R5bGU9IiI+
PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsg
Q29tcGFyaXNvbnMgYmV0d2VlbiBKU09OIHN0cmluZ3MgYW5kIG90aGVyIFVuaWNvZGUgc3RyaW5n
cyBNVVNUIGJlPHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBwZXJm
b3JtZWQgYXMgc3BlY2lmaWVkIGJlbG93Ojx1PjwvdT48dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9wPjxwPnRoaXMgY29tcGFyaXNvbiBhbGdvcml0aG0gc2VlbXMgdG8gYmUgYXR0
ZW1wdGluZyB0byBhbGxvdyBmb3IgY29tcGFyaXNvbiBvZg0KPHU+PC91Pjx1PjwvdT48L3A+PHA+
VVRGLTggZW5jb2RlZCBKU09OIHN0cmluZ3Mgd2l0aCBvdGhlciB1bmljb2RlIHN0cmluZ3MgaW4g
YW55IG9mIHRoZSB1bmljb2RlDQo8dT48L3U+PHU+PC91PjwvcD48cD5lbmNvZGluZyBmb3JtYXRz
LCBidXQgb25seSBpbXBsaWVzIHRoYXQ7IGl0IHNob3VsZCBiZSBzdGF0ZWQuPHU+PC91Pjx1Pjwv
dT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj48cD48c3BhbiBzdHlsZT0i
Y29sb3I6IzAwYjA1MCI+R29vZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJp
bSI+PHA+PHNwYW4gc3R5bGU9IiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPjxwPiZn
dDs8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEuJm5ic3A7IFJl
bW92ZSBhbnkgSlNPTiBhcHBsaWVkIGVzY2FwaW5nIHRvIHByb2R1Y2UgYW4gYXJyYXkgb2YgVW5p
Y29kZTx1PjwvdT48dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgY29kZSBwb2ludHMuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZu
YnNwOzx1PjwvdT48L3A+PHA+SSBkb24ndCB0aGluayAoMSkgaXMgY29ycmVjdC4mbmJzcDsgQSBK
U09OIHN0cmluZyBpcyBieSBkZWZhdWx0IGVuY29kZWQgaW4gVVRGLTguIEENCjx1PjwvdT48dT48
L3U+PC9wPjxwPlVURi04IGVuY29kZWQgc3RyaW5nIGlzIG5vdCAiYW4gYXJyYXkgb2YgVW5pY29k
ZSBjb2RlIHBvaW50cyIgKGl0cyBhIHNlcXVlbmNlIG9mDQo8dT48L3U+PHU+PC91PjwvcD48cD5j
b2RlIHVuaXRzLCB3aGljaCBtdXN0IGJlIGRlY29kZWQgaW50byBjb2RlIHBvaW50cyksIGkgdGhp
bmsgYSBzdGVwIGlzIG1pc3NpbmcNCjx1PjwvdT48dT48L3U+PC9wPjxwPmhlcmUuLjx1PjwvdT48
dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPiZuYnNwOyZuYnNwOyZuYnNw
OyAxLiZuYnNwOyBSZW1vdmUgYW55IEpTT04gZXNjYXBpbmcgZnJvbSB0aGUgaW5wdXQgSlNPTiBz
dHJpbmcuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+PHA+Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDEuYSZuYnNwOyBjb252ZXJ0IHRoZSBzdHJpbmcgaW50byBhIHNlcXVl
bmNlIG9mIHVuaWNvZGUgY29kZSBwb2ludHMuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZu
YnNwOzx1PjwvdT48L3A+DQo8L2Rpdj48cD48c3BhbiBzdHlsZT0iY29sb3I6IzAwYjA1MCI+SG93
IGFib3V0IOKAnFJlbW92ZSBhbnkgSlNPTiBlc2NhcGluZyBmcm9tIHRoZSBpbnB1dCBKU09OIHN0
cmluZyBhbmQgY29udmVydCB0aGUgc3RyaW5nIGludG8gYSBzZXF1ZW5jZSBvZiBVbmljb2RlIGNv
ZGUgcG9pbnRz4oCdPzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+
PHNwYW4gc3R5bGU9IiI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPjxwPi4uYW5kIHRo
ZW4gY29tcGFyZSBjb2RlIHBvaW50LWJ5LWNvZGUgcG9pbnQuIFRoaXMgb3ZlcmFsbCBhbGdvcml0
aG0gL3NlZW1zLyBvaywNCjx1PjwvdT48dT48L3U+PC9wPjxwPmJ1dCBJJ20gbm90IHN1cmUsIGl0
IHNlZW1zIHRoZXJlJ3MgcmF0aW9uYWxlIHRoYXQncyBub3QgZXhwcmVzc2VkLCBlZyBmb3INCjx1
PjwvdT48dT48L3U+PC9wPjxwPmV4Y2x1ZGluZyB1c2Ugb2YgVW5pY29kZSBOb3JtYWxpemF0aW9u
IFtVU0ExNV0uIEFsc28gdGhlIGFsZyBpcyBpbmNvbXBsZXRlIGluDQo8dT48L3U+PHU+PC91Pjwv
cD48cD50aGF0IGl0IGRvZXNuJ3Qgc3RpcHVsYXRlIGNvbnZlcnRpbmcgdGhlICJvdGhlciB1bmlj
b2RlIHN0cmluZyIgaW50byBhIHNlcXVlbmNlDQo8dT48L3U+PHU+PC91PjwvcD48cD5vZiBjb2Rl
IHBvaW50cy48dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwv
ZGl2PjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMDBiMDUwIj5GYWlyIGVub3VnaDx1PjwvdT48dT48
L3U+PC9zcGFuPjwvcD48ZGl2IGNsYXNzPSJpbSI+PHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+
PHA+Jmd0OyAxMC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8dT48L3U+PHU+PC91PjwvcD48cD4m
Z3Q7PHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0Ozx1PjwvdT48dT48L3U+PC9wPjxwPiZndDsmbmJz
cDsmbmJzcDsmbmJzcDsgQWxsIG9mIHRoZSBzZWN1cml0eSBpc3N1ZXMgZmFjZWQgYnkgYW55IGNy
eXB0b2dyYXBoaWMgYXBwbGljYXRpb248dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IG11c3QgYmUgZmFjZWQgYnkgYSBKV1QvSldTL0pXRS9KV0sgYWdlbnQuJm5ic3A7
IEFtb25nIHRoZXNlIGlzc3VlcyBhcmU8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IHByb3RlY3RpbmcgdGhlIHVzZXIncyBwcml2YXRlIGtleSwgcHJldmVudGluZyB2
YXJpb3VzIGF0dGFja3MsIGFuZDx1PjwvdT48dT48L3U+PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsm
bmJzcDsgaGVscGluZyB0aGUgdXNlciBhdm9pZCBtaXN0YWtlcyBzdWNoIGFzIGluYWR2ZXJ0ZW50
bHkgZW5jcnlwdGluZyBhPHU+PC91Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyAmbmJz
cDttZXNzYWdlIGZvciB0aGUgd3JvbmcgcmVjaXBpZW50LiZuYnNwOyBUaGUgZW50aXJlIGxpc3Qg
b2Ygc2VjdXJpdHk8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNv
bnNpZGVyYXRpb25zIGlzIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCwgYnV0IHNv
bWU8dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNpZ25pZmljYW50
IGNvbmNlcm5zIGFyZSBsaXN0ZWQgaGVyZS48dT48L3U+PHU+PC91PjwvcD48cD4mZ3Q7PHU+PC91
Pjx1PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBBbGwgdGhlIHNlY3VyaXR5IGNv
bnNpZGVyYXRpb25zIGluIHRoZSBKV1Mgc3BlY2lmaWNhdGlvbiBhbHNvIGFwcGx5PHU+PC91Pjx1
PjwvdT48L3A+PHA+Jmd0OyZuYnNwOyAmbmJzcDsmbmJzcDt0byBKV1QsIGFzIGRvIHRoZSBKV0Ug
c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2hlbiBlbmNyeXB0aW9uIGlzPHU+PC91Pjx1PjwvdT48
L3A+PHA+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBlbXBsb3llZC4mbmJzcDsgSW4gcGFydGljdWxh
ciwgdGhlIEpXUyBKU09OIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGFuZDx1PjwvdT48dT48L3U+
PC9wPjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVW5pY29kZSBDb21wYXJpc29uIFNlY3VyaXR5
IENvbnNpZGVyYXRpb25zIGFwcGx5IGVxdWFsbHkgdG8gdGhlIEpXVDx1PjwvdT48dT48L3U+PC9w
PjxwPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQ2xhaW1zIFNldCBpbiB0aGUgc2FtZSBtYW5uZXIg
dGhhdCB0aGV5IGRvIHRvIHRoZSBKV1MgSGVhZGVyLjx1PjwvdT48dT48L3U+PC9wPjxwPiZndDs8
dT48L3U+PHU+PC91PjwvcD48cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD48cD5kdW5ubyBpZiB5
b3UgY2FuIGdldCBhd2F5IHdpdGggc2VjIGNvbnMgd2hvbGx5IGluIG90aGVyIGRvY3MsIGFuZCBJ
J20gbm90IHN1cmUNCjx1PjwvdT48dT48L3U+PC9wPjxwPml0J3MgYXBwcm9wcmlhdGUgZ2l2ZW4g
dGhhdCBKV1RzIGFyZSBhIHByb2ZpbGUgb2YgSldFIG9yIEpXUy48dT48L3U+PHU+PC91PjwvcD48
cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2PjxwPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MDBiMDUwIj5UaGF0IHdhcyB0aGUgYXBwcm9hY2ggdGhhdCBTZWFuIGhhZCBzdWdnZXN0ZWQuJm5i
c3A7IElmIHRoZXJlIG90aGVyIHRoaW5ncyB5b3UgdGhpbmsgd2Ugc2hvdWxkIHNwZWNpZmljYWxs
eSBhZGQsIGhvd2V2ZXIsIHBsZWFzZSBsZXQgbWUga25vdy48dT48L3U+PHU+PC91Pjwvc3Bhbj48
L3A+PGRpdiBjbGFzcz0iaW0iPjxwPjxzcGFuIHN0eWxlPSIiPjx1PjwvdT4mbmJzcDs8dT48L3U+
PC9zcGFuPjwvcD48cD5hYm92ZSBuZWVkcyBlZGl0b3JpYWwgcG9saXNoIC0tIHRoZXJlIGFyZW4n
dCBhbnkmbmJzcDsgInNpZ25pZmljYW50IGNvbmNlcm5zIg0KPHU+PC91Pjx1PjwvdT48L3A+PHA+
YWN0dWFsbHkgbGlzdGVkIGhlcmUuPHU+PC91Pjx1PjwvdT48L3A+PHA+PHU+PC91PiZuYnNwOzx1
PjwvdT48L3A+DQo8L2Rpdj48cD48c3BhbiBzdHlsZT0iY29sb3I6IzAwYjA1MCI+VHJ1ZSBlbm91
Z2g8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+PGRpdiBjbGFzcz0iaW0iPjxwPjx1PjwvdT4mbmJz
cDs8dT48L3U+PC9wPjxwPi0tLTx1PjwvdT48dT48L3U+PC9wPjxwPmVuZDx1PjwvdT48dT48L3U+
PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9w
PjxwPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPHU+PC91
Pjx1PjwvdT48L3A+PHA+T0F1dGggbWFpbGluZyBsaXN0PHU+PC91Pjx1PjwvdT48L3A+PHA+PGEg
aHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9
ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPk9BdXRoQGlldGYub3JnPC9z
cGFuPjwvYT48dT48L3U+PHU+PC91PjwvcD48cD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv
bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vb2F1dGg8L3NwYW4+PC9hPjx1PjwvdT48dT48L3U+PC9wPg0KDQo8
L2Rpdj48L2Rpdj4NCjwvZGl2Pg0KDQo8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt
YWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCjxi
cj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48ZGl2Pjxicj48L2Rpdj4t
LSA8YnI+TmF0IFNha2ltdXJhICg9bmF0KTxkaXY+Q2hhaXJtYW4sIE9wZW5JRCBGb3VuZGF0aW9u
PGJyPjxhIGhyZWY9Imh0dHA6Ly9uYXQuc2FraW11cmEub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHA6Ly9uYXQuc2FraW11cmEub3JnLzwvYT48YnI+QF9uYXRfZW48L2Rpdj4NCjwvZGl2Pg0KX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+T0F1dGggbWFp
bGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpPQXV0aEBpZXRmLm9yZyI+T0F1dGhAaWV0Zi5v
cmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
b2F1dGgiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJy
Pg0KPC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvYm9keT48L2h0bWw+

--_000_27E7BEAA592248D498B1C063F2C782F9adobecom_--

From tonynad@microsoft.com  Sun Dec 30 08:33:17 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DB7421F87B4 for ; Sun, 30 Dec 2012 08:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.951
X-Spam-Level: 
X-Spam-Status: No, score=0.951 tagged_above=-999 required=5 tests=[AWL=0.417,  BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbIyIJEIb-YD for ; Sun, 30 Dec 2012 08:33:15 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.23]) by ietfa.amsl.com (Postfix) with ESMTP id B7F8921F8775 for ; Sun, 30 Dec 2012 08:33:15 -0800 (PST)
Received: from BY2FFO11FD013.protection.gbl (10.1.15.202) by BY2FFO11HUB021.protection.gbl (10.1.14.108) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 16:33:12 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD013.mail.protection.outlook.com (10.1.14.75) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 30 Dec 2012 16:33:12 +0000
Received: from va3outboundpool.messaging.microsoft.com (157.54.51.114) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 30 Dec 2012 16:33:10 +0000
Received: from mail237-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Sun, 30 Dec 2012 16:33:09 +0000
Received: from mail237-va3 (localhost [127.0.0.1])	by mail237-va3-R.bigfish.com (Postfix) with ESMTP id EAB20D002CF	for ; Sun, 30 Dec 2012 16:33:08 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT004.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -21
X-BigFish: PS-21(zzbb2dI98dI9371Ic89bhd6eah542I1432Ic857h1447Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275bh8275dh8275ch1033IL177df4h18c673h17326ahz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail237-va3: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT004.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; LANG:en; 
Received: from mail237-va3 (localhost.localdomain [127.0.0.1]) by mail237-va3 (MessageSwitch) id 1356885185753257_11605; Sun, 30 Dec 2012 16:33:05 +0000 (UTC)
Received: from VA3EHSMHS012.bigfish.com (unknown [10.7.14.247])	by mail237-va3.bigfish.com (Postfix) with ESMTP id B2B38180053; Sun, 30 Dec 2012 16:33:05 +0000 (UTC)
Received: from BL2PRD0310HT004.namprd03.prod.outlook.com (157.56.240.21) by VA3EHSMHS012.bigfish.com (10.7.99.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 30 Dec 2012 16:33:05 +0000
Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT004.namprd03.prod.outlook.com (10.255.97.39) with Microsoft SMTP Server (TLS) id 14.16.245.2; Sun, 30 Dec 2012 16:33:04 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 16:33:02 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Sun, 30 Dec 2012 16:32:50 +0000
From: Anthony Nadalin 
To: Mike Jones , Nat Sakimura 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYXPokKfJ1TsWSvG7/OFVVl60vgAR1McAAB7o9hAAB4+qgAAIDBYAABIWM3A=
Date: Sun, 30 Dec 2012 16:32:47 +0000
Message-ID: <4326b9d5b13b407fb43fe08581c6477b@BY2PR03MB041.namprd03.prod.outlook.com>
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk> <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com>  <4E1F6AAD24975D4BA5B1680429673943669E05E8@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669E05E8@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.46.126.7]
Content-Type: multipart/alternative; boundary="_000_4326b9d5b13b407fb43fe08581c6477bBY2PR03MB041namprd03pro_"
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT004.namprd03.prod.outlook.com
X-FOPE-CRA-Verdict: 157.56.240.21$kent.ac.uk%0%1%duplicatedomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com%False%False%0$
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%KENT.AC.UK$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51704002)(51914002)(479174001)(24454001)(13464002)(5343635001)(56816002)(47976001)(5343655001)(44976002)(47736001)(50986001)(49866001)(76482001)(4396001)(6806001)(15202345001)(74502001)(56776001)(47446002)(51856001)(74662001)(33646001)(77982001)(46102001)(16676001)(59766001)(31966008)(53806001)(512874001)(54356001)(15395725002)(54316002)(5343645001)(550184003)(16236675001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB021; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 071156160B
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 16:33:17 -0000

--_000_4326b9d5b13b407fb43fe08581c6477bBY2PR03MB041namprd03pro_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

TWlrZSwgY2xhaW1zIGFyZSBpbiBkb3VidCB0aHVzIHRoZXkgaGF2ZSB0byBiZSB2ZXJpZmllZCB0
aHVzIHRoZXkgZG9u4oCZdCBjYXJyeSB0aGUgcHJvb2YNCg0KRnJvbTogTWlrZSBKb25lcw0KU2Vu
dDogU2F0dXJkYXksIERlY2VtYmVyIDI5LCAyMDEyIDExOjU0IFBNDQpUbzogTmF0IFNha2ltdXJh
OyBBbnRob255IE5hZGFsaW4NCkNjOiBEYXZpZCBDaGFkd2ljazsgSUVURiBvYXV0aCBXRw0KU3Vi
amVjdDogUkU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRv
a2VuLTA1DQoNClRoZSBwcm9ibGVtIHdpdGggdGhlIFguMTI1MiBkZWZpbml0aW9uIGlzIGl0IHVu
bmVjZXNzYXJpbHkgYWRkcyB0aGUg4oCcd2l0aG91dCBiZWluZyBhYmxlIHRvIGdpdmUgcHJvb2bi
gJ0gY29tbWVudC4gIFRoYXQgd2lsbCBkaXN0cmFjdCB0aGUgcmVhZGVyIGltbWVkaWF0ZWx5LiAg
VGhlIGN1cnJlbnQg4oCcYSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBhc3NlcnRlZCBhYm91dCBhIHN1
YmplY3TigJ0gZGVmaW5pdGlvbiBpcyBqdXN0IGFzIGFjY3VyYXRlIGFzIHRoZSBYLjEyNTIgYW5k
IGRvZXNu4oCZdCBzZW5kIHJlYWRlcnMgZG93biBhIG1lbnRhbCByYXRob2xlLg0KDQpXZSBjYW4g
YWRkIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5jZSB0byBYLjEyNTIgaWYgeW91IGxpa2UsIGJ1dCBJ
IHJlYWxseSB0aGluayByZWFkYWJpbGl0eSBhbmQgc2ltcGxpY2l0eSBhcmUgbW9yZSBpbXBvcnRh
bnQgaW4gdGhpcyBraW5kIG9mIGEgc3BlYyB0aGFuIHJldXNpbmcgb3Zlcmx5IHRlY2huaWNhbCBh
bmQgb2ZmLXB1dHRpbmcgSVNPIGRlZmluaXRpb25zLg0KDQpBYm91dCB0aGUgdGVybWlub2xvZ3kg
b3JkZXJpbmcsIHRoZSBjdXJyZW50IG9yZGVyIGlzIGludGVuZGVkIHRvIGJlIHdoYXQgSSB0aGlu
ayB5b3Ugd291bGQgY2FsbCBhIHJldmVyc2UgZGVwZW5kZW5jeSBjaGFpbiDigJMgd2hhdCBJIHdv
dWxkIGNhbGwgYSB0b3AtZG93biBvcmRlcmluZy4gIEl04oCZcyB0aGF0IHdheSBzbyB0aGF0IHRo
ZSBKU09OIFdlYiBUb2tlbiBkZWZpbml0aW9uIGlzIGZpcnN0LiAgVGhlbiwgYXMgdGhhdCBkZWZp
bml0aW9uIG5lZWRzIG90aGVyIGRlZmluaXRpb25zLCB0aGV5IGltbWVkaWF0ZWx5IGZvbGxvdy4g
IFRoaXMgaXMgaW50ZW5kZWQgaW5jcmVhc2UgcmVhZGFiaWxpdHksIGJ5IHByZXNlbnRpbmcgY29u
Y2VwdHMgaW4gYSB0b3AtZG93biBtYW5uZXIuICBCeSBjb21wYXJpc29uLCBib3R0b20tdXAgb3Jk
ZXJpbmcgbWFrZXMgcmVhZGVycyB3YWRlIHRocm91Z2ggYSBzZWEgb2Ygb3RoZXIgdGVybXMgYmVm
b3JlIGdldHRpbmcgdG8gdGhlIG9uZSB0aGV5IHJlYWxseSBjYXJlZCBhYm91dC4NCg0KSWYgeW91
IHdhbnQgdG8gcmVvcmRlciB0aGUgdGVybXMgdG8gbWFrZSBzdXJlIHRoZXnigJlyZSBpbiB0aGUg
YmVzdCB0b3AtZG93biBvcmRlciBwb3NzaWJsZSwgdGhhdCB3b3VsZCBiZSB1c2VmdWwuICAoSWYg
eW91IGRlY2lkZSB0byBkbyB0aGF0LCBJ4oCZZCBhbHNvIGxvb2sgYXQgdGhlIHRlcm1pbm9sb2d5
IG9yZGVyaW5nIGluIEpXUywgSldFLCBhbmQgSldLLCBhcyB3ZSBzaG91bGQgYmUgYXMgY29uc2lz
dGVudCBhcyBwb3NzaWJsZSBhY3Jvc3MgdGhlIHNwZWNpZmljYXRpb25zLg0KDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtl
DQoNCkZyb206IE5hdCBTYWtpbXVyYSBbbWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbV0NClNlbnQ6
IFNhdHVyZGF5LCBEZWNlbWJlciAyOSwgMjAxMiA4OjA0IFBNDQpUbzogQW50aG9ueSBOYWRhbGlu
DQpDYzogRGF2aWQgQ2hhZHdpY2s7IE1pa2UgSm9uZXM7IElFVEYgb2F1dGggV0cNClN1YmplY3Q6
IFJlOiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0w
NQ0KDQpUb255LA0KDQpTbyBkbyB5b3UgYWdyZWUgd2l0aCB0aGUgZm9sbG93aW5nIGRlZmluaXRp
b24gaW4gLTA2PyBPciBwcmVmZXIgWC4xMjUyIGRlZmluaXRpb24/DQoNCg0KQ2xhaW0gIEEgcGll
Y2Ugb2YgaW5mb3JtYXRpb24gYXNzZXJ0ZWQgYWJvdXQgYSBzdWJqZWN0LiAgSGVyZSwgQ2xhaW1z
DQoNCiAgICAgIGFyZSByZXByZXNlbnRlZCBuYW1lL3ZhbHVlIHBhaXJzLCBjb25zaXN0aW5nIG9m
IGEgQ2xhaW0gTmFtZSBhbmQgYQ0KDQogICAgICBDbGFpbSBWYWx1ZS4NCg0KTWlrZToNCg0KUmVn
YXJkaW5nIHRoZSBvcmRlcmluZyBvZiB0aGUgdGVybXMgaW4gdGVybWlub2xvZ3ksIHlvdSBzaG91
bGQgZWl0aGVyIHVzZSB0aGUgZGVwZW5kZW5jeSBjaGFpbiBvciBhbHBoYWJldGljIG9yZGVyLiAo
Rm9ybWVyIGlzIG1vcmUgZGVzaXJhYmxlIGluIG15IHBvaW50IG9mIHZpZXcuKSBIb3dldmVyLCBh
cyBpdCBzdGFuZHMsIGl0IGlzIG5vbmUgb2YgdGhvc2UuIEZvciBleGFtcGxlLCB0aGUgdGVybSAi
Y2xhaW0iIGFwcGVhcnMgaW4gdGhlIGRlZmluaXRpb24gb2YgSldULCB3aGljaCBpcyB0aGUgZmly
c3QgdGVybSBpbiB0aGUgdGVybWlub2xvZ3ksIHdpdGhvdXQgaGF2aW5nIGJlZW4gZGVmaW5lZC4g
SWYgeW91IGRvIG5vdCBtaW5kLCBJIHdpbGwgcmVvcmRlciB0aGVtIGFuZCBzZW5kIGl0IHRvIHlv
dS4NCg0KTmF0DQoNCk9uIFN1biwgRGVjIDMwLCAyMDEyIGF0IDk6MjggQU0sIEFudGhvbnkgTmFk
YWxpbiA8dG9ueW5hZEBtaWNyb3NvZnQuY29tPG1haWx0bzp0b255bmFkQG1pY3Jvc29mdC5jb20+
PiB3cm90ZToNCkJ5IGRlZmluaXRpb24gYSBjbGFpbSBpcyBhbHdheXMgaW4gZG91YnQgdGh1cyBp
dCB3b3VsZCBub3QgY2FsbCBpdCBhIGNyZWRlbnRpYWwgdW50aWwgaXQgaXMgdmVyaWZpZWQNCg0K
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc8
bWFpbHRvOm9hdXRoLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRm
Lm9yZzxtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBEYXZpZCBD
aGFkd2ljaw0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDI5LCAyMDEyIDE6NDIgQU0NClRvOiBN
aWtlIEpvbmVzDQpDYzogSUVURiBvYXV0aCBXRw0KU3ViamVjdDogUmU6IFtPQVVUSC1XR10gcmV2
aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA1DQoNCklmIGEgY2xhaW0gcHJv
dmlkZXMgcHJvb2YgdGhlbiBJIHdvdWxkIGNhbGwgaXQgYSBjcmVkZW50aWFsIG5vdCBhIGNsYWlt
DQoNCkRhdmlkDQoNCk9uIDI5LzEyLzIwMTIgMDE6MTEsIE1pa2UgSm9uZXMgd3JvdGU6DQo+IEkg
Zm91bmQgdGhlIFguMTI1MiBkZWZpbml0aW9uLiAgSXQgaXM6DQo+DQo+ICo2LjE4IGNsYWltICpb
Yi1PRURdOiBUbyBzdGF0ZSBhcyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBiZWluZyBhYmxlDQo+
IHRvIGdpdmUgcHJvb2YuDQo+DQo+IFRoYXQgc2VlbXMgYm90aCBhIGJpdCB2YWd1ZSwgYW5kIGFj
dHVhbGx5IGluY29ycmVjdCwgYXMgdGhlIEpXVCBtYXkNCj4gaW5jbHVkZSBwcm9vZiBvZiB0aGUg
dmVyYWNpdHkgb2YgdGhlIGNsYWltLiAgUGxlYXNlIHNlZSB0aGUgdXBkYXRlZA0KPiBKV1QgZHJh
ZnQgZm9yIGEgaG9wZWZ1bGx5IG1vcmUgdXNlZnVsIOKAnENsYWlt4oCdIGRlZmluaXRpb24uDQo+
DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBCZXN0DQo+IHdpc2hlcywNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4NCj4gKkZyb206Kk1p
a2UgSm9uZXMNCj4gKlNlbnQ6KiBTdW5kYXksIERlY2VtYmVyIDIzLCAyMDEyIDE6MDMgUE0NCj4g
KlRvOiogSmVmZiBIb2RnZXM7IE5hdCBTYWtpbXVyYQ0KPiAqQ2M6KiBJRVRGIG9hdXRoIFdHDQo+
ICpTdWJqZWN0OiogUkU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24t
d2ViLXRva2VuLTA1DQo+DQo+IFdoYXQgaXMgdGhlIFguMTI1MiBkZWZpbml0aW9uPw0KPg0KPiAt
LSBNaWtlDQo+DQo+ICpGcm9tOiogTmF0IFNha2ltdXJhDQo+ICpTZW50Oiog4oCORGVjZW1iZXLi
gI4g4oCOMjPigI4sIOKAjjIwMTIg4oCOMTDigI464oCOMDnigI4g4oCOQU0NCj4gKlRvOiogPUpl
ZmZIDQo+ICpDQzoqIE1pa2UgSm9uZXMsIElFVEYgb2F1dGggV0cNCj4gKlN1YmplY3Q6KiBSZTog
W09BVVRILVdHXSByZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWItdG9rZW4tMDUNCj4N
Cj4gUmUgZGVmaW5pdGlvbiBvZiAnY2xhaW0nLCBhcyBKV1QgaXMgc3VwcG9zZWQgdG8gYmUgZ2Vu
ZXJpYywgaXQgbWF5IGJlDQo+IGJldHRlciB0byBnbyB3aXRoIHRoZSBkZWZpbml0aW9uIG9mIFgu
MTI1MiByYXRoZXIgdGhhbiBPSURDLg0KPg0KPiA9bmF0IHZpYSBpUGhvbmUNCj4NCj4gRGVjIDI0
LCAyMDEyIDI6NDLjgIE9SmVmZkggPEplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPG1haWx0
bzpKZWZmLkhvZGdlc0BraW5nc21vdW50YWluLmNvbT4NCj4gPG1haWx0bzpKZWZmLkhvZGdlc0Br
aW5nc21vdW50YWluLmNvbTxtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20+Pj4g
44Gu44Oh44OD44K744O844K4Og0KPg0KPj4NCj4+ID4gVGhhbmtzIGZvciB0aGUgcmVwbGllcywg
SmVmZi4gIFRoZXkgbWFrZSBzZW5zZS4gIFBhcnRpY3VsYXJseSwNCj4+ID4gdGhhbmtzIGZvciB0
aGUgIkpTT04gVGV4dCBPYmplY3QiIHN1Z2dlc3Rpb24uDQo+Pg0KPj4gd2VsY29tZSwgZ2xhZCB0
aGV5IG1hZGUgc29tZSBzZW5zZS4NCj4+DQo+PiBzaW1pbGFybHksIGlmIG9uZSBlbXBsb3lzIEpT
T04gYXJyYXlzLCBJJ2QgZGVmaW5lIGEgIkpTT04gdGV4dCBhcnJheSIuDQo+Pg0KPj4NCj4+ID4g
Rm9yIHRoZSAiY2xhaW1zIiBkZWZpbml0aW9uLCBJJ20gYWN0dWFsbHkgcHJvbmUgdG8gZ28gd2l0
aA0KPj4gPmRlZmluaXRpb25zIGJhc2VkICBvbiB0aG9zZSBpbg0KPj4gPmh0dHA6Ly9vcGVuaWQu
bmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LW1lc3NhZ2VzLTFfMC0xMy5odG1sI3Rlcm1pbm9sDQo+
PiA+b2d5LQ0KPj4gPiBzcGVjaWZpY2FsbHk6DQo+PiA+DQo+PiA+IENsYWltDQo+PiA+IEEgcGll
Y2Ugb2YgaW5mb3JtYXRpb24gYWJvdXQgYW4gRW50aXR5IHRoYXQgYSBDbGFpbXMgUHJvdmlkZXIN
Cj4+ID4gYXNzZXJ0cyBhYm91dCB0aGF0IEVudGl0eS4NCj4+ID4gQ2xhaW1zIFByb3ZpZGVyDQo+
PiA+IEEgc3lzdGVtIG9yIHNlcnZpY2UgdGhhdCBjYW4gcmV0dXJuIENsYWltcyBhYm91dCBhbiBF
bnRpdHkuDQo+PiA+IEVuZC1Vc2VyDQo+PiA+IEEgaHVtYW4gdXNlciBvZiBhIHN5c3RlbSBvciBz
ZXJ2aWNlLg0KPj4gPiBFbnRpdHkNCj4+ID4gU29tZXRoaW5nIHRoYXQgaGFzIGEgc2VwYXJhdGUg
YW5kIGRpc3RpbmN0IGV4aXN0ZW5jZSBhbmQgdGhhdCBjYW4NCj4+ID4gYmUgaWRlbnRpZmllZCBp
biBjb250ZXh0LiBBbiBFbmQtVXNlciBpcyBvbmUgZXhhbXBsZSBvZiBhbiBFbnRpdHkuDQo+Pg0K
Pj4gd2VsbCwgaXQgc2VlbXMgdG8gbWUsIGdpdmVuIHRoZSBtYW5uZXIgaW4gd2hpY2ggdGhlIEpX
VCBzcGVjIGlzDQo+PiB3cml0dGVuLCBvbmUgY2FuIG1ha2UgdGhlIGNhc2UgdGhhdCBKV1QgY2xh
aW1zIGluIGdlbmVyYWwgYXJlbid0DQo+PiBuZWNlc3NhcmlseSBhYm91dCBhbiBFbnRpdHkgKGFz
IHRoZSBsYXR0ZXIgdGVybSBpcyB1c2VkIGluIHRoZQ0KPj4gY29udGV4dCBvZiB0aGUgT3BlbklE
IENvbm5lY3Qgc3BlY3MpLCByYXRoZXIgdGhleSdyZSBpbiBnZW5lcmFsDQo+PiBzaW1wbHkgYXNz
ZXJ0aW9ucyBhYm91dCBzb21ldGhpbmcocykuIHRoaXMgaXMgYmVjYXVzZSBhbGwgcHJlLWRlZmlu
ZWQNCj4gSldUIGNsYWltIHR5cGVzIGFyZSBvcHRpb25hbCBhbmQgYWxsIEpXVCBzZW1hbnRpY3Mg
YXJlIGxlZnQgdXAgdG8NCj4gc3BlY3MgdGhhdCBwcm9maWxlIChha2EgcmUtdXNlKSB0aGUgSldU
IHNwZWMuDQo+Pg0KPj4gSFRILA0KPj4NCj4+ID1KZWZmSA0KPj4NCj4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBPQXV0aCBtYWlsaW5nIGxpc3QN
Cj4+T0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPiA8bWFpbHRvOk9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4+DQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vb2F1dGgNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGluZyBsaXN0DQo+IE9BdXRoQGll
dGYub3JnPG1haWx0bzpPQXV0aEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9vYXV0aA0KPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRv
Ok9BdXRoQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9v
YXV0aA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9B
dXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmc8bWFpbHRvOk9BdXRoQGlldGYub3JnPg0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KDQoNCg0KLS0NCk5h
dCBTYWtpbXVyYSAoPW5hdCkNCkNoYWlybWFuLCBPcGVuSUQgRm91bmRhdGlvbg0KaHR0cDovL25h
dC5zYWtpbXVyYS5vcmcvDQpAX25hdF9lbg0K

--_000_4326b9d5b13b407fb43fe08581c6477bBY2PR03MB041namprd03pro_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz
Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m
YW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh
Y2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIg
NSA4IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v
cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJz
ZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRl
ZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh
ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw
LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv
QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz
YW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1l
OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv
LXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9
DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo
YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU
ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0
eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21z
by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu
cy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt
dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u
MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8
Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk1pa2UsIGNsYWltcyBhcmUgaW4gZG91YnQgdGh1cyB0
aGV5IGhhdmUgdG8gYmUgdmVyaWZpZWQgdGh1cyB0aGV5IGRvbuKAmXQgY2FycnkgdGhlIHByb29m
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01h
aWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g
MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm
cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNaWtl
IEpvbmVzDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIERlY2VtYmVyIDI5LCAyMDEyIDEx
OjU0IFBNPGJyPg0KPGI+VG86PC9iPiBOYXQgU2FraW11cmE7IEFudGhvbnkgTmFkYWxpbjxicj4N
CjxiPkNjOjwvYj4gRGF2aWQgQ2hhZHdpY2s7IElFVEYgb2F1dGggV0c8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUkU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRv
a2VuLTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90
OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9ibGVtIHdpdGgg
dGhlIFguMTI1MiBkZWZpbml0aW9uIGlzIGl0IHVubmVjZXNzYXJpbHkgYWRkcyB0aGUg4oCcd2l0
aG91dCBiZWluZyBhYmxlIHRvIGdpdmUgcHJvb2bigJ0gY29tbWVudC4mbmJzcDsgVGhhdCB3aWxs
IGRpc3RyYWN0IHRoZSByZWFkZXIgaW1tZWRpYXRlbHkuJm5ic3A7DQogVGhlIGN1cnJlbnQg4oCc
YSBwaWVjZSBvZiBpbmZvcm1hdGlvbiBhc3NlcnRlZCBhYm91dCBhIHN1YmplY3TigJ0gZGVmaW5p
dGlvbiBpcyBqdXN0IGFzIGFjY3VyYXRlIGFzIHRoZSBYLjEyNTIgYW5kIGRvZXNu4oCZdCBzZW5k
IHJlYWRlcnMgZG93biBhIG1lbnRhbCByYXRob2xlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2UgY2FuIGFkZCBhbiBp
bmZvcm1hdGl2ZSByZWZlcmVuY2UgdG8gWC4xMjUyIGlmIHlvdSBsaWtlLCBidXQgSSByZWFsbHkg
dGhpbmsgcmVhZGFiaWxpdHkgYW5kIHNpbXBsaWNpdHkgYXJlIG1vcmUgaW1wb3J0YW50IGluIHRo
aXMga2luZCBvZiBhIHNwZWMgdGhhbiByZXVzaW5nDQogb3Zlcmx5IHRlY2huaWNhbCBhbmQgb2Zm
LXB1dHRpbmcgSVNPIGRlZmluaXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWJvdXQgdGhlIHRlcm1pbm9sb2d5
IG9yZGVyaW5nLCB0aGUgY3VycmVudCBvcmRlciBpcyBpbnRlbmRlZCB0byBiZSB3aGF0IEkgdGhp
bmsgeW91IHdvdWxkIGNhbGwgYSByZXZlcnNlIGRlcGVuZGVuY3kgY2hhaW4g4oCTIHdoYXQgSSB3
b3VsZCBjYWxsIGEgdG9wLWRvd24gb3JkZXJpbmcuJm5ic3A7DQogSXTigJlzIHRoYXQgd2F5IHNv
IHRoYXQgdGhlIEpTT04gV2ViIFRva2VuIGRlZmluaXRpb24gaXMgZmlyc3QuJm5ic3A7IFRoZW4s
IGFzIHRoYXQgZGVmaW5pdGlvbiBuZWVkcyBvdGhlciBkZWZpbml0aW9ucywgdGhleSBpbW1lZGlh
dGVseSBmb2xsb3cuJm5ic3A7IFRoaXMgaXMgaW50ZW5kZWQgaW5jcmVhc2UgcmVhZGFiaWxpdHks
IGJ5IHByZXNlbnRpbmcgY29uY2VwdHMgaW4gYSB0b3AtZG93biBtYW5uZXIuJm5ic3A7IEJ5IGNv
bXBhcmlzb24sIGJvdHRvbS11cCBvcmRlcmluZw0KIG1ha2VzIHJlYWRlcnMgd2FkZSB0aHJvdWdo
IGEgc2VhIG9mIG90aGVyIHRlcm1zIGJlZm9yZSBnZXR0aW5nIHRvIHRoZSBvbmUgdGhleSByZWFs
bHkgY2FyZWQgYWJvdXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB5b3Ugd2FudCB0byByZW9yZGVyIHRoZSB0ZXJt
cyB0byBtYWtlIHN1cmUgdGhleeKAmXJlIGluIHRoZSBiZXN0IHRvcC1kb3duIG9yZGVyIHBvc3Np
YmxlLCB0aGF0IHdvdWxkIGJlIHVzZWZ1bC4mbmJzcDsgKElmIHlvdSBkZWNpZGUgdG8gZG8gdGhh
dCwgSeKAmWQgYWxzbyBsb29rIGF0DQogdGhlIHRlcm1pbm9sb2d5IG9yZGVyaW5nIGluIEpXUywg
SldFLCBhbmQgSldLLCBhcyB3ZSBzaG91bGQgYmUgYXMgY29uc2lzdGVudCBhcyBwb3NzaWJsZSBh
Y3Jvc3MgdGhlIHNwZWNpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx
dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE5hdCBTYWtpbXVyYSBb
PGEgaHJlZj0ibWFpbHRvOnNha2ltdXJhQGdtYWlsLmNvbSI+bWFpbHRvOnNha2ltdXJhQGdtYWls
LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gU2F0dXJkYXksIERlY2VtYmVyIDI5LCAyMDEy
IDg6MDQgUE08YnI+DQo8Yj5Ubzo8L2I+IEFudGhvbnkgTmFkYWxpbjxicj4NCjxiPkNjOjwvYj4g
RGF2aWQgQ2hhZHdpY2s7IE1pa2UgSm9uZXM7IElFVEYgb2F1dGggV0c8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUmU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRv
a2VuLTA1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub255LCZuYnNwOzxvOnA+PC9v
OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gZG8geW91IGFncmVlIHdp
dGggdGhlIGZvbGxvd2luZyBkZWZpbml0aW9uIGluIC0wNj8gT3IgcHJlZmVyIFguMTI1MiBkZWZp
bml0aW9uPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5DbGFpbSZuYnNwOyBBIHBpZWNlIG9mIGluZm9ybWF0
aW9uIGFzc2VydGVkIGFib3V0IGEgc3ViamVjdC4mbmJzcDsgSGVyZSwgQ2xhaW1zPG86cD48L286
cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXJlIHJlcHJlc2VudGVkIG5hbWUvdmFsdWUgcGFp
cnMsIGNvbnNpc3Rpbmcgb2YgYSBDbGFpbSBOYW1lIGFuZCBhPG86cD48L286cD48L3NwYW4+PC9w
cmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgQ2xhaW0gVmFsdWUuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5NaWtlOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgdGhlIG9yZGVyaW5nIG9mIHRoZSB0ZXJtcyBp
biB0ZXJtaW5vbG9neSwgeW91IHNob3VsZCBlaXRoZXIgdXNlIHRoZSBkZXBlbmRlbmN5IGNoYWlu
IG9yIGFscGhhYmV0aWMgb3JkZXIuIChGb3JtZXIgaXMgbW9yZSBkZXNpcmFibGUgaW4gbXkgcG9p
bnQgb2Ygdmlldy4pIEhvd2V2ZXIsIGFzIGl0IHN0YW5kcywgaXQgaXMgbm9uZSBvZiB0aG9zZS4g
Rm9yIGV4YW1wbGUsIHRoZSB0ZXJtICZxdW90O2NsYWltJnF1b3Q7DQogYXBwZWFycyBpbiB0aGUg
ZGVmaW5pdGlvbiBvZiBKV1QsIHdoaWNoIGlzIHRoZSBmaXJzdCB0ZXJtIGluIHRoZSB0ZXJtaW5v
bG9neSwgd2l0aG91dCBoYXZpbmcgYmVlbiBkZWZpbmVkLiBJZiB5b3UgZG8gbm90IG1pbmQsIEkg
d2lsbCByZW9yZGVyIHRoZW0gYW5kIHNlbmQgaXQgdG8geW91LiZuYnNwOzxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OYXQ8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU3VuLCBEZWMgMzAs
IDIwMTIgYXQgOToyOCBBTSwgQW50aG9ueSBOYWRhbGluICZsdDs8YSBocmVmPSJtYWlsdG86dG9u
eW5hZEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+dG9ueW5hZEBtaWNyb3NvZnQuY29t
PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CeSBk
ZWZpbml0aW9uIGEgY2xhaW0gaXMgYWx3YXlzIGluIGRvdWJ0IHRodXMgaXQgd291bGQgbm90IGNh
bGwgaXQgYSBjcmVkZW50aWFsIHVudGlsIGl0IGlzIHZlcmlmaWVkPG86cD48L286cD48L3A+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS08YnI+DQpGcm9tOiA8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZyI+b2F1
dGgtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86b2F1dGgtYm91
bmNlc0BpZXRmLm9yZyI+b2F1dGgtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBE
YXZpZCBDaGFkd2ljazxicj4NClNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJlciAyOSwgMjAxMiAxOjQy
IEFNPGJyPg0KVG86IE1pa2UgSm9uZXM8YnI+DQpDYzogSUVURiBvYXV0aCBXRzxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1YmplY3Q6
IFJlOiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0w
NTxicj4NCjxicj4NCklmIGEgY2xhaW0gcHJvdmlkZXMgcHJvb2YgdGhlbiBJIHdvdWxkIGNhbGwg
aXQgYSBjcmVkZW50aWFsIG5vdCBhIGNsYWltPGJyPg0KPGJyPg0KRGF2aWQ8YnI+DQo8YnI+DQpP
biAyOS8xMi8yMDEyIDAxOjExLCBNaWtlIEpvbmVzIHdyb3RlOjxicj4NCiZndDsgSSBmb3VuZCB0
aGUgWC4xMjUyIGRlZmluaXRpb24uICZuYnNwO0l0IGlzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICo2
LjE4IGNsYWltICpbYi1PRURdOiBUbyBzdGF0ZSBhcyBiZWluZyB0aGUgY2FzZSwgd2l0aG91dCBi
ZWluZyBhYmxlPGJyPg0KJmd0OyB0byBnaXZlIHByb29mLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRo
YXQgc2VlbXMgYm90aCBhIGJpdCB2YWd1ZSwgYW5kIGFjdHVhbGx5IGluY29ycmVjdCwgYXMgdGhl
IEpXVCBtYXk8YnI+DQomZ3Q7IGluY2x1ZGUgcHJvb2Ygb2YgdGhlIHZlcmFjaXR5IG9mIHRoZSBj
bGFpbS4gJm5ic3A7UGxlYXNlIHNlZSB0aGUgdXBkYXRlZDxicj4NCiZndDsgSldUIGRyYWZ0IGZv
ciBhIGhvcGVmdWxseSBtb3JlIHVzZWZ1bCDigJxDbGFpbeKAnSBkZWZpbml0aW9uLjxicj4NCiZn
dDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
O0Jlc3Q8YnI+DQomZ3Q7IHdpc2hlcyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstLSBNaWtlPGJyPg0KJmd0Ozxicj4NCiZn
dDsgKkZyb206Kk1pa2UgSm9uZXM8YnI+DQomZ3Q7ICpTZW50OiogU3VuZGF5LCBEZWNlbWJlciAy
MywgMjAxMiAxOjAzIFBNPGJyPg0KJmd0OyAqVG86KiBKZWZmIEhvZGdlczsgTmF0IFNha2ltdXJh
PGJyPg0KJmd0OyAqQ2M6KiBJRVRGIG9hdXRoIFdHPGJyPg0KJmd0OyAqU3ViamVjdDoqIFJFOiBb
T0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxicj4N
CiZndDs8YnI+DQomZ3Q7IFdoYXQgaXMgdGhlIFguMTI1MiBkZWZpbml0aW9uPzxicj4NCiZndDs8
YnI+DQomZ3Q7IC0tIE1pa2U8YnI+DQomZ3Q7PGJyPg0KJmd0OyAqRnJvbToqIE5hdCBTYWtpbXVy
YTxicj4NCiZndDsgKlNlbnQ6KiDigI5EZWNlbWJlcuKAjiDigI4yM+KAjiwg4oCOMjAxMiDigI4x
MOKAjjrigI4wOeKAjiDigI5BTTxicj4NCiZndDsgKlRvOiogPUplZmZIPGJyPg0KJmd0OyAqQ0M6
KiBNaWtlIEpvbmVzLCBJRVRGIG9hdXRoIFdHPGJyPg0KJmd0OyAqU3ViamVjdDoqIFJlOiBbT0FV
VEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNTxicj4NCiZn
dDs8YnI+DQomZ3Q7IFJlIGRlZmluaXRpb24gb2YgJ2NsYWltJywgYXMgSldUIGlzIHN1cHBvc2Vk
IHRvIGJlIGdlbmVyaWMsIGl0IG1heSBiZTxicj4NCiZndDsgYmV0dGVyIHRvIGdvIHdpdGggdGhl
IGRlZmluaXRpb24gb2YgWC4xMjUyIHJhdGhlciB0aGFuIE9JREMuPGJyPg0KJmd0Ozxicj4NCiZn
dDsgPW5hdCB2aWEgaVBob25lPGJyPg0KJmd0Ozxicj4NCiZndDsgRGVjIDI0LCAyMDEyIDI6NDI8
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jgIE8L3NwYW4+
PUplZmZIICZsdDs8YSBocmVmPSJtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20i
PkplZmYuSG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tPC9hPjxicj4NCiZndDsgJmx0O21haWx0bzo8
YSBocmVmPSJtYWlsdG86SmVmZi5Ib2RnZXNAa2luZ3Ntb3VudGFpbi5jb20iPkplZmYuSG9kZ2Vz
QGtpbmdzbW91bnRhaW4uY29tPC9hPiZndDsmZ3Q7DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7TVMgR290aGljJnF1b3Q7Ij7jga7jg6Hjg4Pjgrvjg7zjgrg8L3NwYW4+Ojxicj4NCiZn
dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZndDsgVGhhbmtzIGZvciB0aGUgcmVwbGll
cywgSmVmZi4gJm5ic3A7VGhleSBtYWtlIHNlbnNlLiAmbmJzcDtQYXJ0aWN1bGFybHksPGJyPg0K
Jmd0OyZndDsgJmd0OyB0aGFua3MgZm9yIHRoZSAmcXVvdDtKU09OIFRleHQgT2JqZWN0JnF1b3Q7
IHN1Z2dlc3Rpb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyB3ZWxjb21lLCBnbGFkIHRo
ZXkgbWFkZSBzb21lIHNlbnNlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgc2ltaWxhcmx5
LCBpZiBvbmUgZW1wbG95cyBKU09OIGFycmF5cywgSSdkIGRlZmluZSBhICZxdW90O0pTT04gdGV4
dCBhcnJheSZxdW90Oy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
Jmd0OyBGb3IgdGhlICZxdW90O2NsYWltcyZxdW90OyBkZWZpbml0aW9uLCBJJ20gYWN0dWFsbHkg
cHJvbmUgdG8gZ28gd2l0aDxicj4NCiZndDsmZ3Q7ICZndDtkZWZpbml0aW9ucyBiYXNlZCAmbmJz
cDtvbiB0aG9zZSBpbjxicj4NCiZndDsmZ3Q7ICZndDs8YSBocmVmPSJodHRwOi8vb3BlbmlkLm5l
dC9zcGVjcy9vcGVuaWQtY29ubmVjdC1tZXNzYWdlcy0xXzAtMTMuaHRtbCN0ZXJtaW5vbCIgdGFy
Z2V0PSJfYmxhbmsiPmh0dHA6Ly9vcGVuaWQubmV0L3NwZWNzL29wZW5pZC1jb25uZWN0LW1lc3Nh
Z2VzLTFfMC0xMy5odG1sI3Rlcm1pbm9sPC9hPjxicj4NCiZndDsmZ3Q7ICZndDtvZ3ktPGJyPg0K
Jmd0OyZndDsgJmd0OyBzcGVjaWZpY2FsbHk6PGJyPg0KJmd0OyZndDsgJmd0Ozxicj4NCiZndDsm
Z3Q7ICZndDsgQ2xhaW08YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEEgcGllY2Ugb2YgaW5mb3JtYXRpb24g
YWJvdXQgYW4gRW50aXR5IHRoYXQgYSBDbGFpbXMgUHJvdmlkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7
IGFzc2VydHMgYWJvdXQgdGhhdCBFbnRpdHkuPGJyPg0KJmd0OyZndDsgJmd0OyBDbGFpbXMgUHJv
dmlkZXI8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEEgc3lzdGVtIG9yIHNlcnZpY2UgdGhhdCBjYW4gcmV0
dXJuIENsYWltcyBhYm91dCBhbiBFbnRpdHkuPGJyPg0KJmd0OyZndDsgJmd0OyBFbmQtVXNlcjxi
cj4NCiZndDsmZ3Q7ICZndDsgQSBodW1hbiB1c2VyIG9mIGEgc3lzdGVtIG9yIHNlcnZpY2UuPGJy
Pg0KJmd0OyZndDsgJmd0OyBFbnRpdHk8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFNvbWV0aGluZyB0aGF0
IGhhcyBhIHNlcGFyYXRlIGFuZCBkaXN0aW5jdCBleGlzdGVuY2UgYW5kIHRoYXQgY2FuPGJyPg0K
Jmd0OyZndDsgJmd0OyBiZSBpZGVudGlmaWVkIGluIGNvbnRleHQuIEFuIEVuZC1Vc2VyIGlzIG9u
ZSBleGFtcGxlIG9mIGFuIEVudGl0eS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHdlbGws
IGl0IHNlZW1zIHRvIG1lLCBnaXZlbiB0aGUgbWFubmVyIGluIHdoaWNoIHRoZSBKV1Qgc3BlYyBp
czxicj4NCiZndDsmZ3Q7IHdyaXR0ZW4sIG9uZSBjYW4gbWFrZSB0aGUgY2FzZSB0aGF0IEpXVCBj
bGFpbXMgaW4gZ2VuZXJhbCBhcmVuJ3Q8YnI+DQomZ3Q7Jmd0OyBuZWNlc3NhcmlseSBhYm91dCBh
biBFbnRpdHkgKGFzIHRoZSBsYXR0ZXIgdGVybSBpcyB1c2VkIGluIHRoZTxicj4NCiZndDsmZ3Q7
IGNvbnRleHQgb2YgdGhlIE9wZW5JRCBDb25uZWN0IHNwZWNzKSwgcmF0aGVyIHRoZXkncmUgaW4g
Z2VuZXJhbDxicj4NCiZndDsmZ3Q7IHNpbXBseSBhc3NlcnRpb25zIGFib3V0IHNvbWV0aGluZyhz
KS4gdGhpcyBpcyBiZWNhdXNlIGFsbCBwcmUtZGVmaW5lZDxicj4NCiZndDsgSldUIGNsYWltIHR5
cGVzIGFyZSBvcHRpb25hbCBhbmQgYWxsIEpXVCBzZW1hbnRpY3MgYXJlIGxlZnQgdXAgdG88YnI+
DQomZ3Q7IHNwZWNzIHRoYXQgcHJvZmlsZSAoYWthIHJlLXVzZSkgdGhlIEpXVCBzcGVjLjxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSFRILDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
PUplZmZIPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IE9BdXRoIG1haWxpbmcgbGlz
dDxicj4NCiZndDsmZ3Q7PGEgaHJlZj0ibWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRm
Lm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRo
QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7PGJy
Pg0KJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX188YnI+DQomZ3Q7IE9BdXRoIG1haWxpbmcgbGlzdDxicj4NCiZndDsgPGEgaHJlZj0i
bWFpbHRvOk9BdXRoQGlldGYub3JnIj5PQXV0aEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhy
ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgiIHRhcmdldD0i
X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoPC9hPjxi
cj4NCiZndDs8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCk9BdXRoIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpPQXV0aEBp
ZXRmLm9yZyI+T0F1dGhAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGg8L2E+PGJyPg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpPQXV0aCBtYWlsaW5nIGxpc3Q8
YnI+DQo8YSBocmVmPSJtYWlsdG86T0F1dGhAaWV0Zi5vcmciPk9BdXRoQGlldGYub3JnPC9hPjxi
cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgi
IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29h
dXRoPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxicj4NCk5hdCBTYWtpbXVyYSAoPW5hdCk8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFpcm1hbiwgT3BlbklEIEZvdW5k
YXRpb248YnI+DQo8YSBocmVmPSJodHRwOi8vbmF0LnNha2ltdXJhLm9yZy8iIHRhcmdldD0iX2Js
YW5rIj5odHRwOi8vbmF0LnNha2ltdXJhLm9yZy88L2E+PGJyPg0KQF9uYXRfZW48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_4326b9d5b13b407fb43fe08581c6477bBY2PR03MB041namprd03pro_--

From tonynad@microsoft.com  Sun Dec 30 08:36:01 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8354521F8976 for ; Sun, 30 Dec 2012 08:36:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.891
X-Spam-Level: 
X-Spam-Status: No, score=0.891 tagged_above=-999 required=5 tests=[AWL=0.358,  BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJuEw0a1cqA0 for ; Sun, 30 Dec 2012 08:36:00 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.26]) by ietfa.amsl.com (Postfix) with ESMTP id B0CF621F8973 for ; Sun, 30 Dec 2012 08:36:00 -0800 (PST)
Received: from BY2FFO11FD002.protection.gbl (10.1.15.200) by BY2FFO11HUB021.protection.gbl (10.1.14.108) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 16:35:58 +0000
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD002.mail.protection.outlook.com (10.1.14.124) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Sun, 30 Dec 2012 16:35:58 +0000
Received: from ch1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 30 Dec 2012 16:35:58 +0000
Received: from mail211-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE012.bigfish.com (10.43.70.62) with Microsoft SMTP Server id 14.1.225.23; Sun, 30 Dec 2012 16:35:51 +0000
Received: from mail211-ch1 (localhost [127.0.0.1])	by mail211-ch1-R.bigfish.com (Postfix) with ESMTP id 0E8B7E03A7	for ; Sun, 30 Dec 2012 16:35:51 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -21
X-BigFish: PS-21(zzbb2dI98dI9371Ic89bhd6eah542I1432I1447Izz1de0h1202h1e76h1d1ah1d2ah1082kzz8275bh8275dh8275ch1033IL177df4h17326ahz31h2a8h668h839h93fhd24hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h9a9j1155h)
Received-SPF: softfail (mail211-ch1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ;.outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; LANG:en; 
Received: from mail211-ch1 (localhost.localdomain [127.0.0.1]) by mail211-ch1 (MessageSwitch) id 1356885349274641_3628; Sun, 30 Dec 2012 16:35:49 +0000 (UTC)
Received: from CH1EHSMHS029.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.241])	by mail211-ch1.bigfish.com (Postfix) with ESMTP id 2D6C83A0045;	Sun, 30 Dec 2012 16:35:49 +0000 (UTC)
Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CH1EHSMHS029.bigfish.com (10.43.70.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 30 Dec 2012 16:35:44 +0000
Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.245.2; Sun, 30 Dec 2012 16:35:43 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.586.12; Sun, 30 Dec 2012 16:35:41 +0000
Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.160]) with mapi id 15.00.0586.000; Sun, 30 Dec 2012 16:35:23 +0000
From: Anthony Nadalin 
To: David Chadwick 
Thread-Topic: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
Thread-Index: Ac3lYXPokKfJ1TsWSvG7/OFVVl60vgAR1McAAB7o9hAAEIT0gAARRVBQ
Date: Sun, 30 Dec 2012 16:35:23 +0000
Message-ID: <586fa0a965614efb86d8f281609ea467@BY2PR03MB041.namprd03.prod.outlook.com>
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk> <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com> <50DFF93F.5050906@kent.ac.uk>
In-Reply-To: <50DFF93F.5050906@kent.ac.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.46.126.7]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BL2PRD0310HT002.namprd03.prod.outlook.com
X-FOPE-CRA-Verdict: 157.56.240.21$kent.ac.uk%0%1%duplicatedomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com%False%False%0$
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%KENT.AC.UK$RO%2$TLS%6$FQDN%131.107.125.5$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(51704002)(51914002)(479174001)(24454001)(13464002)(5343635001)(56816002)(47976001)(5343655001)(44976002)(47736001)(50986001)(49866001)(76482001)(4396001)(6806001)(15202345001)(47776002)(74502001)(56776001)(47446002)(51856001)(74662001)(33646001)(23676001)(77982001)(46102001)(16676001)(59766001)(31966008)(53806001)(54356001)(15395725002)(50466001)(54316002)(5343645001)(550184003)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB021; LANG:en; 
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 071156160B
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Dec 2012 16:36:01 -0000

Tm9wZSwgZGlzYWdyZWUgYXMgYSBjbGFpbSBpcyBhbHdheXMgaW4gZG91YnQgdGh1cyBpdCBoYXMg
bm8gcHJvb2YsIHRoZSBwcm9vZiBjb21lcyBpbiB0aGUgdmVyaWZpY2F0aW9uDQoNCi0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYXZpZCBDaGFkd2ljayBbbWFpbHRvOmQudy5jaGFk
d2lja0BrZW50LmFjLnVrXSANClNlbnQ6IFN1bmRheSwgRGVjZW1iZXIgMzAsIDIwMTIgMTI6MjAg
QU0NClRvOiBBbnRob255IE5hZGFsaW4NCkNjOiBNaWtlIEpvbmVzOyBJRVRGIG9hdXRoIFdHDQpT
dWJqZWN0OiBSZTogW09BVVRILVdHXSByZXZpZXc6IGRyYWZ0LWlldGYtb2F1dGgtanNvbi13ZWIt
dG9rZW4tMDUNCg0KT24gMzAvMTIvMjAxMiAwMDoyOCwgQW50aG9ueSBOYWRhbGluIHdyb3RlOg0K
PiBCeSBkZWZpbml0aW9uIGEgY2xhaW0gaXMgYWx3YXlzIGluIGRvdWJ0IHRodXMgaXQgd291bGQg
bm90IGNhbGwgaXQgYSANCj4gY3JlZGVudGlhbCB1bnRpbCBpdCBpcyB2ZXJpZmllZA0KDQpObyB0
aGlzIGlzIG5vdCBjb3JyZWN0LCBzaW5jZSB5b3UgY2FuIGhhdmUgdmFsaWQgYW5kIGludmFsaWQg
Y3JlZGVudGlhbHMuIFlvdSBwcmVzZW50IHlvdXIgY3JlZGVudGlhbHMgdG8gdGhlIFJQLCBhbmQg
dGhlIFJQIHZlcmlmaWVzIHRoZW0gYmFzZWQgb24gdGhlIHByb29mIHRoZXkgY29udGFpbi4NCg0K
SWYgeW91IHByZXNlbnQgYSBjbGFpbSB3aXRob3V0IGFueSBwcm9vZiB0aGVuIGl0IGlzIG5vdCBh
IGNyZWRlbnRpYWwgYW5kIGl0IGNhbm5vdCBiZSB2ZXJpZmllZCAoc2luY2UgaXQgY29udGFpbnMg
bm8gcHJvb2YpIHdpdGhvdXQgdGhlIFJQIG9idGFpbmluZyBzb21lIHByb29mIGluZm9ybWF0aW9u
IGZyb20gZWxzZXdoZXJlIChzdWNoIGFzIHNob3dpbmcgaXQgdG8gdGhlIGlzc3VlciBhbmQgYXNr
aW5nIHRoZW0gaWYgaXQgaXMgZ2VudWluZSBvciBub3QpLg0KDQpTbyBJIHdvdWxkIHNheSB0aGF0
IGluIE9hdXRoIHlvdSBjYW4gcHJlc2VudCBhIGNsYWltIG9yIGEgY3JlZGVudGlhbC4NCg0KcmVn
YXJkcw0KDQpEYXZpZA0KDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206
IG9hdXRoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpvYXV0aC1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgDQo+IE9mIERhdmlkIENoYWR3aWNrDQo+IFNlbnQ6IFNhdHVyZGF5LCBEZWNlbWJl
ciAyOSwgMjAxMiAxOjQyIEFNDQo+IFRvOiBNaWtlIEpvbmVzDQo+IENjOiBJRVRGIG9hdXRoIFdH
DQo+IFN1YmplY3Q6IFJlOiBbT0FVVEgtV0ddIHJldmlldzogZHJhZnQtaWV0Zi1vYXV0aC1qc29u
LXdlYi10b2tlbi0wNQ0KPg0KPiBJZiBhIGNsYWltIHByb3ZpZGVzIHByb29mIHRoZW4gSSB3b3Vs
ZCBjYWxsIGl0IGEgY3JlZGVudGlhbCBub3QgYSANCj4gY2xhaW0NCj4NCj4gRGF2aWQNCj4NCj4g
T24gMjkvMTIvMjAxMiAwMToxMSwgTWlrZSBKb25lcyB3cm90ZToNCj4+IEkgZm91bmQgdGhlIFgu
MTI1MiBkZWZpbml0aW9uLiAgSXQgaXM6DQo+Pg0KPj4gKjYuMTggY2xhaW0gKltiLU9FRF06IFRv
IHN0YXRlIGFzIGJlaW5nIHRoZSBjYXNlLCB3aXRob3V0IGJlaW5nIGFibGUgDQo+PiB0byBnaXZl
IHByb29mLg0KPj4NCj4+IFRoYXQgc2VlbXMgYm90aCBhIGJpdCB2YWd1ZSwgYW5kIGFjdHVhbGx5
IGluY29ycmVjdCwgYXMgdGhlIEpXVCBtYXkgDQo+PiBpbmNsdWRlIHByb29mIG9mIHRoZSB2ZXJh
Y2l0eSBvZiB0aGUgY2xhaW0uICBQbGVhc2Ugc2VlIHRoZSB1cGRhdGVkIA0KPj4gSldUIGRyYWZ0
IGZvciBhIGhvcGVmdWxseSBtb3JlIHVzZWZ1bCDigJxDbGFpbeKAnSBkZWZpbml0aW9uLg0KPj4N
Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgQmVzdCANCj4+IHdpc2hlcywNCj4+DQo+PiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCj4+DQo+PiAq
RnJvbToqTWlrZSBKb25lcw0KPj4gKlNlbnQ6KiBTdW5kYXksIERlY2VtYmVyIDIzLCAyMDEyIDE6
MDMgUE0NCj4+ICpUbzoqIEplZmYgSG9kZ2VzOyBOYXQgU2FraW11cmENCj4+ICpDYzoqIElFVEYg
b2F1dGggV0cNCj4+ICpTdWJqZWN0OiogUkU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRm
LW9hdXRoLWpzb24td2ViLXRva2VuLTA1DQo+Pg0KPj4gV2hhdCBpcyB0aGUgWC4xMjUyIGRlZmlu
aXRpb24/DQo+Pg0KPj4gLS0gTWlrZQ0KPj4NCj4+ICpGcm9tOiogTmF0IFNha2ltdXJhDQo+PiAq
U2VudDoqIOKAjkRlY2VtYmVy4oCOIOKAjjIz4oCOLCDigI4yMDEyIOKAjjEw4oCOOuKAjjA54oCO
IOKAjkFNDQo+PiAqVG86KiA9SmVmZkgNCj4+ICpDQzoqIE1pa2UgSm9uZXMsIElFVEYgb2F1dGgg
V0cNCj4+ICpTdWJqZWN0OiogUmU6IFtPQVVUSC1XR10gcmV2aWV3OiBkcmFmdC1pZXRmLW9hdXRo
LWpzb24td2ViLXRva2VuLTA1DQo+Pg0KPj4gUmUgZGVmaW5pdGlvbiBvZiAnY2xhaW0nLCBhcyBK
V1QgaXMgc3VwcG9zZWQgdG8gYmUgZ2VuZXJpYywgaXQgbWF5IGJlIA0KPj4gYmV0dGVyIHRvIGdv
IHdpdGggdGhlIGRlZmluaXRpb24gb2YgWC4xMjUyIHJhdGhlciB0aGFuIE9JREMuDQo+Pg0KPj4g
PW5hdCB2aWEgaVBob25lDQo+Pg0KPj4gRGVjIDI0LCAyMDEyIDI6NDLjgIE9SmVmZkggPEplZmYu
SG9kZ2VzQGtpbmdzbW91bnRhaW4uY29tIA0KPj4gPG1haWx0bzpKZWZmLkhvZGdlc0BraW5nc21v
dW50YWluLmNvbT4+IOOBruODoeODg+OCu+ODvOOCuDoNCj4+DQo+Pj4NCj4+Pj4gVGhhbmtzIGZv
ciB0aGUgcmVwbGllcywgSmVmZi4gIFRoZXkgbWFrZSBzZW5zZS4gIFBhcnRpY3VsYXJseSwgDQo+
Pj4+IHRoYW5rcyBmb3IgdGhlICJKU09OIFRleHQgT2JqZWN0IiBzdWdnZXN0aW9uLg0KPj4+DQo+
Pj4gd2VsY29tZSwgZ2xhZCB0aGV5IG1hZGUgc29tZSBzZW5zZS4NCj4+Pg0KPj4+IHNpbWlsYXJs
eSwgaWYgb25lIGVtcGxveXMgSlNPTiBhcnJheXMsIEknZCBkZWZpbmUgYSAiSlNPTiB0ZXh0IGFy
cmF5Ii4NCj4+Pg0KPj4+DQo+Pj4+IEZvciB0aGUgImNsYWltcyIgZGVmaW5pdGlvbiwgSSdtIGFj
dHVhbGx5IHByb25lIHRvIGdvIHdpdGggDQo+Pj4+IGRlZmluaXRpb25zIGJhc2VkICBvbiB0aG9z
ZSBpbiANCj4+Pj4gaHR0cDovL29wZW5pZC5uZXQvc3BlY3Mvb3BlbmlkLWNvbm5lY3QtbWVzc2Fn
ZXMtMV8wLTEzLmh0bWwjdGVybWlubw0KPj4+PiBsDQo+Pj4+IG9neS0NCj4+Pj4gc3BlY2lmaWNh
bGx5Og0KPj4+Pg0KPj4+PiBDbGFpbQ0KPj4+PiBBIHBpZWNlIG9mIGluZm9ybWF0aW9uIGFib3V0
IGFuIEVudGl0eSB0aGF0IGEgQ2xhaW1zIFByb3ZpZGVyIA0KPj4+PiBhc3NlcnRzIGFib3V0IHRo
YXQgRW50aXR5Lg0KPj4+PiBDbGFpbXMgUHJvdmlkZXINCj4+Pj4gQSBzeXN0ZW0gb3Igc2Vydmlj
ZSB0aGF0IGNhbiByZXR1cm4gQ2xhaW1zIGFib3V0IGFuIEVudGl0eS4NCj4+Pj4gRW5kLVVzZXIN
Cj4+Pj4gQSBodW1hbiB1c2VyIG9mIGEgc3lzdGVtIG9yIHNlcnZpY2UuDQo+Pj4+IEVudGl0eQ0K
Pj4+PiBTb21ldGhpbmcgdGhhdCBoYXMgYSBzZXBhcmF0ZSBhbmQgZGlzdGluY3QgZXhpc3RlbmNl
IGFuZCB0aGF0IGNhbiANCj4+Pj4gYmUgaWRlbnRpZmllZCBpbiBjb250ZXh0LiBBbiBFbmQtVXNl
ciBpcyBvbmUgZXhhbXBsZSBvZiBhbiBFbnRpdHkuDQo+Pj4NCj4+PiB3ZWxsLCBpdCBzZWVtcyB0
byBtZSwgZ2l2ZW4gdGhlIG1hbm5lciBpbiB3aGljaCB0aGUgSldUIHNwZWMgaXMgDQo+Pj4gd3Jp
dHRlbiwgb25lIGNhbiBtYWtlIHRoZSBjYXNlIHRoYXQgSldUIGNsYWltcyBpbiBnZW5lcmFsIGFy
ZW4ndCANCj4+PiBuZWNlc3NhcmlseSBhYm91dCBhbiBFbnRpdHkgKGFzIHRoZSBsYXR0ZXIgdGVy
bSBpcyB1c2VkIGluIHRoZSANCj4+PiBjb250ZXh0IG9mIHRoZSBPcGVuSUQgQ29ubmVjdCBzcGVj
cyksIHJhdGhlciB0aGV5J3JlIGluIGdlbmVyYWwgDQo+Pj4gc2ltcGx5IGFzc2VydGlvbnMgYWJv
dXQgc29tZXRoaW5nKHMpLiB0aGlzIGlzIGJlY2F1c2UgYWxsIA0KPj4+IHByZS1kZWZpbmVkDQo+
PiBKV1QgY2xhaW0gdHlwZXMgYXJlIG9wdGlvbmFsIGFuZCBhbGwgSldUIHNlbWFudGljcyBhcmUg
bGVmdCB1cCB0byANCj4+IHNwZWNzIHRoYXQgcHJvZmlsZSAoYWthIHJlLXVzZSkgdGhlIEpXVCBz
cGVjLg0KPj4+DQo+Pj4gSFRILA0KPj4+DQo+Pj4gPUplZmZIDQo+Pj4NCj4+PiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IE9BdXRoIG1haWxpbmcg
bGlzdA0KPj4+IE9BdXRoQGlldGYub3JnIDxtYWlsdG86T0F1dGhAaWV0Zi5vcmc+IA0KPj4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCj4+DQo+Pg0KPj4NCj4+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBPQXV0
aCBtYWlsaW5nIGxpc3QNCj4+IE9BdXRoQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL29hdXRoDQo+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPiBPQXV0aCBtYWlsaW5nIGxpc3QNCj4gT0F1dGhAaWV0
Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vYXV0aA0KPg0K
DQoNCg==


From d.w.chadwick@kent.ac.uk  Mon Dec 31 02:11:56 2012
Return-Path: 
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DD521F84D8 for ; Mon, 31 Dec 2012 02:11:56 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-fB-UhxJ1Bg for ; Mon, 31 Dec 2012 02:11:55 -0800 (PST)
Received: from mx1.kent.ac.uk (mx1.kent.ac.uk [129.12.21.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5030621F8941 for ; Mon, 31 Dec 2012 02:11:54 -0800 (PST)
Received: from mx0.kent.ac.uk ([129.12.21.32]) by mx1.kent.ac.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TpcLX-0007Vl-8Y; Mon, 31 Dec 2012 10:11:51 +0000
Received: from [31.185.222.175] (helo=[192.168.1.64]) by mx0.kent.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TpcLW-0001Gu-L6; Mon, 31 Dec 2012 10:11:51 +0000
Message-ID: <50E164E5.9010509@kent.ac.uk>
Date: Mon, 31 Dec 2012 10:11:49 +0000
From: David Chadwick 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Anthony Nadalin 
References: <4E1F6AAD24975D4BA5B1680429673943669B0B1F@TK5EX14MBXC283.redmond.corp.microsoft.com> <50DEBAF4.6040700@kent.ac.uk> <517e9248dbf944d2a275b4850609f63c@BY2PR03MB041.namprd03.prod.outlook.com> <50DFF93F.5050906@kent.ac.uk> <586fa0a965614efb86d8f281609ea467@BY2PR03MB041.namprd03.prod.outlook.com>
In-Reply-To: <586fa0a965614efb86d8f281609ea467@BY2PR03MB041.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: IETF oauth WG 
Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 31 Dec 2012 10:11:56 -0000

I think you must have misread my email, since your reply seems to agree 
with mine, that the claim is always in doubt. My comment was about a 
credential

regards

David

On 30/12/2012 16:35, Anthony Nadalin wrote:
> Nope, disagree as a claim is always in doubt thus it has no proof, the proof comes in the verification
>
> -----Original Message-----
> From: David Chadwick [mailto:d.w.chadwick@kent.ac.uk]
> Sent: Sunday, December 30, 2012 12:20 AM
> To: Anthony Nadalin
> Cc: Mike Jones; IETF oauth WG
> Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>
> On 30/12/2012 00:28, Anthony Nadalin wrote:
>> By definition a claim is always in doubt thus it would not call it a
>> credential until it is verified
>
> No this is not correct, since you can have valid and invalid credentials. You present your credentials to the RP, and the RP verifies them based on the proof they contain.
>
> If you present a claim without any proof then it is not a credential and it cannot be verified (since it contains no proof) without the RP obtaining some proof information from elsewhere (such as showing it to the issuer and asking them if it is genuine or not).
>
> So I would say that in Oauth you can present a claim or a credential.
>
> regards
>
> David
>
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of David Chadwick
>> Sent: Saturday, December 29, 2012 1:42 AM
>> To: Mike Jones
>> Cc: IETF oauth WG
>> Subject: Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>>
>> If a claim provides proof then I would call it a credential not a
>> claim
>>
>> David
>>
>> On 29/12/2012 01:11, Mike Jones wrote:
>>> I found the X.1252 definition.  It is:
>>>
>>> *6.18 claim *[b-OED]: To state as being the case, without being able
>>> to give proof.
>>>
>>> That seems both a bit vague, and actually incorrect, as the JWT may
>>> include proof of the veracity of the claim.  Please see the updated
>>> JWT draft for a hopefully more useful “Claim” definition.
>>>
>>>                                                                Best
>>> wishes,
>>>
>>>                                                                -- Mike
>>>
>>> *From:*Mike Jones
>>> *Sent:* Sunday, December 23, 2012 1:03 PM
>>> *To:* Jeff Hodges; Nat Sakimura
>>> *Cc:* IETF oauth WG
>>> *Subject:* RE: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>>>
>>> What is the X.1252 definition?
>>>
>>> -- Mike
>>>
>>> *From:* Nat Sakimura
>>> *Sent:* ‎December‎ ‎23‎, ‎2012 ‎10‎:‎09‎ ‎AM
>>> *To:* =JeffH
>>> *CC:* Mike Jones, IETF oauth WG
>>> *Subject:* Re: [OAUTH-WG] review: draft-ietf-oauth-json-web-token-05
>>>
>>> Re definition of 'claim', as JWT is supposed to be generic, it may be
>>> better to go with the definition of X.1252 rather than OIDC.
>>>
>>> =nat via iPhone
>>>
>>> Dec 24, 2012 2:42、=JeffH >> > のメッセージ:
>>>
>>>>
>>>>> Thanks for the replies, Jeff.  They make sense.  Particularly,
>>>>> thanks for the "JSON Text Object" suggestion.
>>>>
>>>> welcome, glad they made some sense.
>>>>
>>>> similarly, if one employs JSON arrays, I'd define a "JSON text array".
>>>>
>>>>
>>>>> For the "claims" definition, I'm actually prone to go with
>>>>> definitions based  on those in
>>>>> http://openid.net/specs/openid-connect-messages-1_0-13.html#termino
>>>>> l
>>>>> ogy-
>>>>> specifically:
>>>>>
>>>>> Claim
>>>>> A piece of information about an Entity that a Claims Provider
>>>>> asserts about that Entity.
>>>>> Claims Provider
>>>>> A system or service that can return Claims about an Entity.
>>>>> End-User
>>>>> A human user of a system or service.
>>>>> Entity
>>>>> Something that has a separate and distinct existence and that can
>>>>> be identified in context. An End-User is one example of an Entity.
>>>>
>>>> well, it seems to me, given the manner in which the JWT spec is
>>>> written, one can make the case that JWT claims in general aren't
>>>> necessarily about an Entity (as the latter term is used in the
>>>> context of the OpenID Connect specs), rather they're in general
>>>> simply assertions about something(s). this is because all
>>>> pre-defined
>>> JWT claim types are optional and all JWT semantics are left up to
>>> specs that profile (aka re-use) the JWT spec.
>>>>
>>>> HTH,
>>>>
>>>> =JeffH
>>>>
>>>> _______________________________________________
>>>> OAuth mailing 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
>>
>
>

I want to argue to change that.  I think they should be separate and=
 that the full token type definitiuon should be removed, defining only the =
key assertion.  ANY token that needs signing by the client could be an=
 HOK token.

   
 
  
  From: "zhou.sujing@zte.com.cn" <zhou.sujing@zte.com.cn>
 To: William Mills <wmills_92105=
@yahoo.com> 
Cc: "&l=
t;oauth@ietf.org>" <oauth,_oauth-bounces@ietf.org>; SergeyBeryozki=
n <sberyozkin@yahoo.com> 
 S=
ent: Thursday, December 20, 2012 11:46 PM
 Subject: Re: Re: [OAUTH-WG] Few questions ab=
out HOTK
  
 
=0A
=0A
oauth-bounces@ietf.org =E5=86=99=E4=BA=8E 2012-12-21 13:30:08:=

=0A
=0A> MAC and HOTK describe different properties of a token, a=
nd could 
=0A> both be used in the same token.  MAC specifies a =
basic format=0Afor a 
=0A> signed token payload and transaction. &nbs=
p;HOTK defines part of a=0Atoken 
=0A> payload.  HOTK payload ca=
n be carried in a MAC token.=0A
> =0A> -bill=0A
=0A
HOTK and MAC =
are different token types, how can they=0Abe used in the same token?=
=0A
What whould the token type be then? =0A
=0A
MAC and HOTK-SK are really very si=
milar, they are=0Aactually alternative solutions to each other. =0A
The meaning is HOTK is more high level. =0A
> 
=0A> From: Sergey Beryozkin &=
lt;sberyozkin@gmail.com>
=0A> To: "<oauth@ietf.org>" <oau=
th@ietf.org> 
=0A> Sent: Thursday, December 20, 2012 1:49 PM
=
=0A> Subject: [OAUTH-WG] Few questions about HOTK=0A
=
> 
=0A> Hi Hannes, others,
=0A> 
=0A>=
 I'd like to understand what is the difference between HOTK Symmetric
=
=0A> [1] and MAC [2].
=0A> 
=0A> I'm reading about HOTK Symm=
etric and JWS profile and it seems like=0A
=0A> HOTK Symmetric text c=
an support MAC.
=0A> 
=0A> My main question at the moment: does=
 HOTK (Symmetric) offer an 
=0A> alternative to MAC or is HOTK actual=
ly a higher-level token scheme=0A
=0A> which can support different ty=
pes of tokens ?
=0A> 
=0A> thanks, Sergey
=0A> 
=0A>=
; [1] http://tools.ietf.org/html/draft-tschofenig-oauth-hotk-01
=0A> =
[2] http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-02
=0A> _=
______________________________________________
=0A> OAuth mailing lis=
t
=0A> OAuth@ietf.org
=0A> https://www.ietf.org/mailman/listinf=
o/oauth
=0A> 
=0A> ____________________________________________=
___
=0A> OAuth mailing list
=0A> OAuth@ietf.org
=0A> http=
s://www.ietf.org/mailman/listinfo/oauth
=0A=0A


=